Buscar en Gazafatonario IT

martes, febrero 08, 2005

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

No hay comentarios.:

Publicar un comentario