Qué Diagramas Usar?

En un foro virtual reciente sobre Metodologías de Desarrollo de Sistemas, me decía un Analista novel en el mundo del modelado, cuyo equipo de trabajo había adoptado RUP como la metodología para realizar proyectos, que uno de los miembros del equipo le había recomendado usar diagramas de Actividad para el desarrollo del software. Puesto que el equipo apenas ingresaba al universo RUP, él quería que alguien lo ayudara a dar los primeros pasos y me aclaró que también había leído que los Casos de Uso eran muy importantes.

Antes de clonar aquí la respuesta que le di entonces, creo que es necesario aclarar a ustedes, amigos de la Asociación, que RUP es una metodología, un Proceso Unificado para realizar el modelado del negocio, el estudio de requerimientos, el análisis y el diseño de un sistema, lo mismo que la programación, las pruebas, la documentación, la gerencia del proyecto, el manejo del entorno y el control de cambios. Es un proceso probado con éxito en cientos de proyectos en todo el mundo, sin embargo, es un proceso exigente en cuanto al talento requerido para ejecutarlo. Hoy día RUP se combina con procesos ágiles (Agile Software) para producir metodologías más adecuadas para todo tipo de proyectos heterogéneos. Pero esta columna no versará más sobre RUP, ese será tema de un extenso artículo en preparación.

Bueno, le dije a este personaje del cuento que los diagramas de Actividad encajaban mejor en el modelado de procesos de alto nivel, como aquellos en los que una organización muestra la forma de ejecutar sus funciones. Estos diagramas son muy fáciles de entender por los usuarios del negocio puesto que ellos mismos los usan para describir sus procesos. También agregué que los Casos de Uso eran la base de cualquier proceso de desarrollo Orientado a Objetos (aún si el nuevo sistema tiene software legado involucrado en el proceso que signifique, por ejemplo, integración con bases de datos o aplicaciones propietarias), especialmente, y que son precisamente los casos de uso los que conducen casi cualquier actividad en ese proceso.

Pero si miramos más de cerca los diagramas de actividad, le dije, encontraremos que ellos describen el flujo procedimental entre dos o más objetos que procesan una actividad (esto es definición RUP), de tal forma que pueden ser el flujo principal de un caso de uso o parte del mismo o de una secuencia alternativa de ese caso de uso.

En este punto lo invité (los invito) a que le den (vuelvan a dar) un vistazo a mis artículos introductorios sobre UML que se encuentran publicados en: http://b.1asphost.com/LuchoSalazar/GazafatonarioIT/Prolegmenos%20Sobre%20el%20Lenguaje%20de%20Modelado%20Unificado.pdf. Allí encontrarán las definiciones y las características principales de estos y de los demás diagramas de UML.

De vuelta al tema central le expresé mi opinión de que debería usar los diagramas de Actividad para documentar los procesos del negocio pero que tuviera en cuenta que el objetivo final era desarrollar modelos de casos de uso a partir de esos procesos. Usar diagramas de Actividad en la construcción del software (en la programación) no es muy útil realmente, puesto que estos diagramas son menos técnicos que los diagramas de colaboración, por ejemplo.

En un plano más general, continué mi explicación, todas las técnicas y elementos en RUP tienen, frecuentemente, múltiples propósitos. Realmente, no hay una “forma corta”, acoté, de aprender la intención y decidir lo que es apropiado en cada situación. La forma más rápida que he encontrado para “adivinar” el objetivo de los artefactos es mirar la lista de actividades que producen y usan cada uno.

Están, por ejemplo, los diagramas de Clase, que presentan una vista estática del sistema, útiles además para construir el diagrama E-R (que no es de UML) a partir de las clases Entidad, un tema que será tratado en sendo artículo futuro. También los diagramas de Secuencia, si queremos tener una vista del comportamiento externo del sistema. Pero ninguno de estos diagramas es obligatorio; siempre debemos partir del hecho de que modelamos para entender un sistema y, desde esta perspectiva, un conjunto de trazos con significado en un tablero podrían decirnos más que una docena de diagramas y documentos “rupizados” altamente elaborados, sobre todo para la mayoría de proyectos que enfrentamos a diario.

Como recomendación adicional le dije que esperaba que él hallara útil traer a bordo a alguien con buen conocimiento de RUP para que lo ayudara a encontrar el sentido de todos esos Gigabytes de información proporcionada con el proceso y que lo guiara hasta los bits que él necesitaba justo ahora que comenzaba el proyecto. Por experiencia propia sé que este es el mejor camino cuando se trata de enfrentar una metodología como esta, porque muchas (casi todas) las situaciones que encontramos en nuestros proyectos no están escritas en los libros ni en los diversos tratados que se han elaborado sobre el tema.

¿Y libros?, me preguntó, recomiéndame algunos. Bueno, eso no tiene problema, un magnifico libro para iniciar es el de Martin Fowler, UML Gota a Gota, que presenta un muy buen compendio del uso que le podemos dar a cada diagrama de UML, lo mismo que sus rasgos importantes y definiciones. Para ir más allá, un poco, está el libro de Graig Larman, UML y Patrones, que además introduce este espinoso tema de los Patrones de Diseño, bastante desconocido en nuestro medio.

Eso fue todo, espero que le haya sido de utilidad mis recomendaciones, lo mismo que a ustedes, amigos lectores.

Comparte tus impresiones conmigo y con todos en la Web sobre este y otros temas. Puedes escribirme a mailto:luchosalazar@usa.net.

Luis Antonio Salazar Caraballo

Medellín, agosto 11 de 2003

El Fantasma de los Navegadores: Adiós a Netscape

Unos ocho o nueve años atrás (que para la Informática podrían sonar como 80 millones de años), una noche cualquiera de verano, conectado vía Gopher con un MODEM de 28.800 baudios, de alguna manera mágica (mítica quizás para ese entonces) logré “bajar” de Internet (quizás la tercera o cuarta vez que me conectaba) la primera versión beta de Netscape Navigator de la que en ese entonces era Mosaic Communications Corp.

Nunca nada volvió a ser igual, excepto la histeria femenil de quienes nos acompañan en la dimensión del amor (amigas, novias, esposas, amantes…). El universo se volvió del tamaño de mi PC de entonces, un flamante 80486-100 MHz con 8 MB RAM y ese maravilloso aparatito llamado MODEM.

Internet, que desde siempre fue nada más que una colección de protocolos, un racimo de computadores inter-conectados, un conjunto de poderosas innovaciones de negocio, una nueva forma de distribuir contenido o un canal de comunicación, había llegado al “nuevo mundo”, mi mundo, nuestro mundo.

Era el fin de “las vacas sagradas” de la tecnología, esos personajes introvertidos pero muy inteligentes que manejaban los departamentos de informática de las empresas y universidades del país y del mundo entero. Hasta ese momento, ellos, de alguna forma misteriosa eran los únicos que poseían información privilegiada, mucho antes de que esta fuera difundida vía malas traducciones mediante libros que a la postre terminaron haciendo parte de la obsoleta biblioteca de tecnología que muchos de nosotros poseemos pero que nunca más hemos vuelto a desempolvar.

Cosas como esta ocurrían cada cierto tiempo, como la radio o la prensa escrita, que reinaron durante un siglo, que fueron interesantes por un tiempo, un largo tiempo, pero que luego se perdieron para siempre en los laberintos de nuestros recuerdos. Internet, por supuesto, es mucho más que eso, es la clase de evento que nos va a permitir dejar un legado a nuestros muy lejanos nietos, los que habitarán la tierra en mil años, en cincuenta mil años.

Sí, hubo inicios de Internet antes de Netscape, hubo navegadores antes de Mosaic, existía una Internet antes de la Web. Pero esa llamada versión beta de Netscape, el navegador, transformó nuestro entorno.

Lo que ocurrió después es historia, todos lo sabemos. La pregunta era, estos nuevos seres que crecieron, se multiplicaron, se transformaron (los Navegadores), cuanto iban a reinar sobre la faz de la tierra, sobre el vacío del universo.

Portales, chats, software libre (o pirata?), EMails, el tenebroso Spam, sexo virtual, religión, videos, viajes virtuales, e-books, amigos virtuales, amantes virtuales, páginas, páginas, miles de ellas, millones de ellas…, el maremagnum de información que encapotó nuestra cordura, inimaginable hasta por quienes en la década de los 60s tuvieron la iniciativa de conectar un grupo de computadores en lo que llamaron ArpaNet para compartir datos clasificados. Eso fue lo que empezamos a vivir.

Netscape, el Navegador, lo hizo posible! Pero Netscape, la compañía, casi mató a Netscape, el producto. Los intentos de AOL de sacarlo del coma infausto en que quedó luego de la avalancha indubitable que generó el fenómeno Microsoft se vieron truncados cuando un coletazo de esa epidemia universal giró U$750 millones a la cuenta del grupo Time Warner. No había duda, Explorer (de Microsoft) era y es el líder absoluto del mercado y, sin titubeo, un mejor producto (prueba de ello es que esta raza de Navegador de la aldea Microsoft se ha extendido hasta el 96% de los PCs del Planeta.)

Netscape se extinguió para siempre, Requiescat In Peace, como hace 65 millones de años se extinguieron los dinosaurios; será recordado por quienes navegamos con el a muy baja velocidad, por quienes bajamos con el un nuevo y tímido navegador llamado Explorer, por quienes aprendimos con el que Internet sería nuestra herramienta de trabajo más poderosa, pero también el arma aniquiladora más peligrosa de todos los tiempos, inclusive mucho más que el propio ser humano.

Comparte tus impresiones conmigo y con todos en la Web sobre este y otros temas. Puedes escribirme a lucho.salazar@gmail.com.

Luis Antonio Salazar Caraballo

Medellín, julio 24 de 2003

El Papel del Modelado en la Transformación de los Requisitos en Software

No nos digamos mentiras: desarrollar software es notoriamente difícil e impredecible. Muchos proyectos de software son cancelados, terminan tarde y sobre-presupuestados o tienen una calidad bastante deplorable.

Para justificar los continuos errores que cometemos proyecto tras proyecto en materia de calidad, de entrega a tiempo y de presupuesto establecido (Recursos + Talento Humano), muchos de nosotros nos amparamos en el hecho de que la Ingeniería de Software es una ciencia muy nueva, si la comparamos con ciencias milenarias como la medicina o la arquitectura, y nos decimos a nosotros mismos y a los demás que esto del desarrollo de software es un “arte” más que una ciencia o una disciplina.

Pero y hasta cuándo vamos a esperar para convertir nuestro trabajo de “artistas” en trabajo de profesionales del desarrollo de software?

Precisamente, para que el Desarrollo de Software se convierta en una disciplina de la Ingeniería del Software debe saltar por encima de un conjunto de paradigmas que ha justificado la mediocridad patibularia en la que nos hemos postrado desde siempre.

Uno de ellos es el del Modelado. Si bien es cierto que el producto primordial de un proyecto no son artefactos como documentos de todo tipo, formateados, coloreados, estandarizados, ni consignas de grandeza o empuje (El Trabajo Dignifica al Ser Humano!), ni miles de líneas de código en el lenguaje más rebuscado o de moda, sino un magnífico fruto de software que plasme las necesidades muchas veces caprichosas (léase cambiantes) de los usuarios, el modelado de software constituye una pieza fundamental de todo ese engranaje que es el ciclo de vida del desarrollo, puesto que nos guía por un camino más o menos correcto hacía la generación de un buen sistema de información y es el que permite producir los accesorios correctos (documentos, código fuente, etc.)

Hoy día estamos gastando mucho más tiempo en corregir código que no funciona o presenta un mal comportamiento porque se hizo sin haber adquirido el conocimiento del sistema en construcción, en vez de gastar ese mismo tiempo en entenderlo a través de modelos que nos hubieran permitido además visualizar y controlar no solo la arquitectura de ese sistema, sino los mayores riesgos potenciales, los componentes a reutilizar y, en general, la funcionalidad del software, el objetivo final.

Y a todas estas, ¿qué es un modelo? Algunos de ustedes creerán que los estoy tomando del pelo, pero si les cuento que durante quince años he hecho esa pregunta en conferencias y cursos “especializados” en materia de desarrollo de software y que las respuestas que he recibido de mis estudiantes son bastante imprecisas (a veces son totalmente mudas…), aceptarán que no estoy bromeando.

Pues bien, un modelo es una representación (simple) de la realidad. Representación en el sentido de grafía, forma. Simple en el sentido de escueto, desnudo. Realidad en el sentido de contexto, situación.

Aquí la palabra clave es “simple”. Si la realidad, los requisitos establecidos por nuestros usuarios, es compleja, deberíamos abordar el modelado dividiendo el conjunto de requisitos en subconjuntos de requisitos más simples (los subconjuntos, no los requisitos) y si todavía tenemos “conjunticos” complejos, seguiremos fragmentándolos hasta obtener los agregados (“humanamente”) más simples.

¿Qué les explique cómo es el asunto? Bueno, el problema que encontramos a diario quienes nos hemos atrevido a “modelar” (software) es que tratamos de modelar todos los requisitos al tiempo, o una gran porción de ellos; sin embargo, en los últimos tiempos he encontrado que manejar estos requisitos por raciones más asequibles al conocimiento “humano” trae mejores beneficios, construimos entonces esos modelos más simples, modelos que a su vez son sistemas, sistemas que a su vez cumplen con los requisitos de los usuarios, ¡el ciclo vital! (Tengo que confesarlo, eso se lo debo también al excelente equipo de desarrolladores y arquitectos de software con los que he tenido la oportunidad de compartir proyectos durante estos años).

Y puesto que un modelo es un sistema, todo sistema se caracteriza por determinados parámetros que le aportan una descripción dimensional bien definida. Estos parámetros son:

1. Entrada o insumo o impulso (“input”).

2. Salida o producto o resultado (“output”).

3. Procesamiento o procesador o transformador (“throughput”).

4. Retroalimentación o retroinformación (“feedback”) o alimentación de retorno.

5. Ambiente.

El detalle de cada una de estas características está por fuera del alcance de este ensayo. Lo que sí puedo decirles es que estos parámetros son el pilar cardinal de lo que se ha dado en llamar “Primer Principio de Desarrollo de Software”, principio que, a la postre, si todos lo seguimos, transformará de arte en disciplina al desarrollo de software, un principio con el que podamos definir muy pronto un “patrón de diseño universal” que nos guíe a través del diseño de software y que le dé a los modelos el papel y la importancia que realmente tienen y no el de “irrelevante” como muchos creíamos hasta hoy.

Ahora bien, muchos pensamos que el estudio del modelado empezaba con conocer a fondo un lenguaje de modelado como UML (en Gazafatonario IT ya inicié una labor de publicación de artículos sobre el tema, y estos finalmente servirán para profundizar y entender mejor lo que aquí expongo), no obstante, primero era necesario saber que es un modelo y para qué sirve; teníamos un escenario enfermizo.

Bueno, este es un intento por aliviar esa situación.

Luis Antonio Salazar Caraballo

Medellín, julio 15 de 2003

Visiones

Gazafatonario IT

Visiones

“En primer lugar existió el Caos. Después Gea (Tierra), la de amplio pecho, sede siempre segura de todos los Inmortales que habitaban la nevada cumbre del Olimpo. En el fondo de la tierra de anchos caminos existió el tenebroso Tártaro (infierno griego). Por último, Eros (dios del amor), el más hermoso entre los dioses inmortales, que afloja los miembros y cambia de todos los dioses y todos los hombres el corazón y la sensata voluntad en sus pechos.”

El Origen del Universo Según la Mitología Griega

Parece irónico echar una mirada al pasado, aunque sea un pasado de fábula, para hablar de las visiones que tengo de un futuro probable. Aunque es cierto que nadie puede inventar el futuro, podemos, desde el punto de vista de la tecnología y la ciencia, tratar de saber cómo será el universo que habitaremos en 20 años, en 50 años, en mil años. Al menos, podemos imaginar como será, podemos crear la mitología del futuro.

¿Hacía dónde nos llevará la tecnología? Especialmente la Tecnología Informática. ¿Podremos esperar, a largo plazo, que el PC desaparezca y que el acceso a la informática esté en todas partes? ¿Podremos esperar que los computadores, en vez de convertirse en los demonios rapaces que aparecen en películas como Terminator, se conviertan en elementos tan pequeños, omnipresentes y tan poderosos que desaparezcan de la vista humana?

Algunos seres, humanos por supuesto, de esos que tienen el don poco frecuente de combinar la capacidad técnica en bruto con el virtuosismo artístico y creativo, como Mark Weiser, célebre director del Xerox PARC, padre de la Computación Ubicua y que muriera en 1999, creen que así será la vida en el futuro cercano. Weiser se basó en la teoría de que la desaparición es una consecuencia fundamental no de la tecnología sino de la psicología humana; siempre que la gente aprende algo suficientemente bien, deja de ser consciente de ello. ¿Tendría Weiser la razón? El tiempo nos lo dirá.

Entre tanto, el resto de los no tan Inmortales habitantes de la Tierra (de esa Gea que nos enseñaron los antiguos griegos), debemos prepararnos para abordar ese futuro complejo y lleno de dilemas a partir del mejor uso de la tecnología. Hoy vivimos para la tecnología, la estamos creando. Mañana, deberemos ser capaces de usarla, de ser mejores personas cada vez. Sí, quizás dejemos de ser, sin hacer ningún ruido, los seres más brillantes de esta Tierra, pero quizás también, podremos ser capaces de desencadenar poderosas fuerzas que podrían elevar nuestra civilización hacía el siguiente estado de la vida, uno en el que todas las culturas confluyan y donde la comunicación sea el pilar de la existencia. Hablo de una comunicación que sea comprendida por unos y por otros (seres humanos), una en la que, como dijo Einstein, la mayor parte de las ideas fundamentales de la ciencia sean esencialmente sencillas y por regla general puedan ser expresadas en un lenguaje comprensible para todos (quizás entonces pueda responder a mi hija Pamela, hoy de tan solo 6 años, la pregunta que me hizo sobre si clonar el Tilacino era lo mismo que clonar un computador, refiriéndose a un programa de TV que vimos juntos acerca de las posibilidades de clonación del Tigre de Tasmania y de su computador Clon con el que juega ávidamente a escaparse de Dursley junto a Harry Potter).

Seguramente habrá más intentos de configurar el mundo y modificar la personalidad humana, tal como hoy lo hacemos con la Interfaz Gráfica de nuestro PC, para crear un modelo de vida autoelegido, y eso entrañará muchas consecuencias inexploradas. También, como hoy, el destino humano continuará siendo una empresa aventurada y, en algún instante impredecible la naturaleza contraatacará, volviéndonos a recordar que desde siempre vivimos en un hogar configurado por ella.

Sin embargo, más allá de toda ciencia y tecnología, más allá de toda concepción filosófica o dogmática (o mitológica) que trate de ofrecer una respuesta a la trama humana, nuestro espíritu seguirá inquieto… y expectante.

Estas son algunas de mis visiones, quería compartirlas con ustedes. Ahora volvamos a temas más terrenales.

Pero ustedes también pueden compartir sus propias visiones escribiéndome a lucho.salazar@gmail.com.

Luis Antonio Salazar Caraballo

Medellín, junio 27 de 2003