rubensa, algo en qué pensar

Martes, 17 de enero de 2006

Introducción a UML

El Lenguaje Unificado de Modelado se ha convertido rápidamente en el estándar de facto para construir software orientado a objetos. Este breve tutorial proporciona una introducción al UML muy por encima y sugiere algunas lecturas recomendadas adicionales.

Pero primero...¿Que es UML?

La especificación OMG dice:

"El Lenguaje de Modelado Unificado (UML) es un lenguaje gráfico para visualizar, especificar, construir y documentar los elementos de un sistema fundamentalmente software. EL UML ofrece una forma estándar para escribir un plano del sistema, incluyendo cosas conceptuales tales como procesos de negocios y funciones del sistema, así como también cosas concretas tales como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables"

El punto importante para notar aquí es que el UML es un "lenguaje" para especificar y no un método o un proceso. El UML se usa para definir un sistema de software; para detallar los elementos del sistema, para documentar y construir -es el lenguaje en el que está escrito el plano-. El UML se puede usar en una gran variedad de formas para soportar una metodología de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en sí mismo la metodología o proceso.

El UML define la notación y las semánticas para los siguientes dominios:
- El Modelo de Interacción del Usuario o Modelo de Casos de Uso: describe el límite y la interacción entre el sistema y los usuarios. Se corresponde en cierta manera a un modelo de requisitos.
- El Modelo de Interacción o de Colaboración: describe cómo interactuarán los objetos en el sistema entre sí para realizar el trabajo.
- EL Modelo de Estado o Modelo Dinámico: las cartas de estados describen los estados o condiciones que las clases asumen a través del tiempo. Los grafos de actividad describen los flujos de trabajo que implementará el sistema.
- El Modelo Lógico o de Clases: describe las clases y los objetos que conformarán el sistema.
- El Modelo de Componentes Físico: describe el software (y algunas veces los componentes de hardware) que conforman el sistema.
- EL Modelo de Despliegue Físico: describe la arquitectura física y el despliegue de componentes en esa arquitectura de hardware.

El UML también define mecanismos de extensión para extenderlo a fin de cumplir con necesidades específicas (por ejemplo, extensiones de Modelado de Procesos de Negocios).

Entonces... ¿Cómo usar el UML?

El UML típicamente se usa como parte de un proceso de desarrollo de software, con el soporte de una herramienta CASE adecuada, para definir los requisitos, las interacciones y los elementos del sistema de software propuesto. La naturaleza exacta del método depende de la metodología de desarrollo que se use. Un proceso de ejemplo podría ser algo como lo siguiente:
1. Capture un Modelo de Procesos de Negocio. Esto se usará para definir las actividades y procesos de alto nivel que ocurren en una organización y para proveer los fundamentos para el modelo de Casos de Uso. El Modelo de Procesos de Negocio típicamente captura más que lo que implementará un sistema de software (por ejemplo, incluye procesos manuales y otros).
2. Trace un Modelo de Casos de Uso al Modelo de Procesos de Negocio para definir exactamente qué funcionalidad está intentando proveer desde la perspectiva del usuario de negocio. A medida que se agrega cada caso de uso, cree un vínculo trazable desde el proceso de negocio apropiado al caso de uso (por ejemplo, una conexión de realización). Esta traza establece claramente qué funcionalidad proveerá el nuevo sistema para cumplir con los requisitos de negocio descriptos en el modelo de procesos. También asegura que no existirán casos de uso sin un propósito.
3. Refine los casos de uso -incluya requisitos, restricciones, tasas de complejidad, notas y escenarios-. Esta información describe sin ambigüedades qué hace el caso de uso, cómo se ejecuta y las restricciones en su ejecución. Asegúrese de que el caso de uso aún cumple con los requisitos del proceso de negocio. Incluya la definición de las pruebas de sistema para cada caso de uso para definir el criterio de aceptación de cada uno de ellos. Incluya también algunas descripciones de las pruebas de aceptación de los usuarios para definir cómo probará él esta funcionalidad y qué son los criterios de aceptación.
4. Comience a construir un modelo de dominio (objetos de negocio de alto nivel), diagramas de secuencia, diagramas de colaboración y modelos de interfaces de usuario a partir de las entradas y salidas del Modelo de Procesos de Negocio y de los detalles de los casos de uso. Ellos describen las 'cosas' en el Nuevo sistema, la forma en la que tales cosas interactúan y la interfaz que utilizará un usuario para ejecutar los escenarios de los casos de uso.
5. Cree el Modelo de Clases a partir del modelo del dominio, del modelo de interfaz de usuario y de los diagramas de escenario. Es una especificación precisa de los objetos en el sistema, de sus datos o atributos y de su comportamiento u operaciones. Los objetos del dominio se pueden abstraer en jerarquías de clases utilizando herencia. Los mensajes de los diagramas de escenario típicamente pasarán a ser operaciones de clases. Si se va a utilizar un framework existente o patrones de diseño, es posible importar elementos de modelado existentes para usar en el nuevo sistema. Defina pruebas unitarias y de integración para probar a fondo en cada clase: i) que la clase funciona internamente como se especificó y que ii) la clase interactúa como se esperaba con otras clases y componentes relacionados.
6. A medida que se desarrolla, el Modelo de Clases se puede dividir en paquetes y componentes discretos. Un componente representa una porción de software desplegable que contiene el comportamiento y los datos de una o más clases y expone una interfaz estricta a otros consumidores de sus servicios. Entonces se construye un Modelo de Componentes a partir del Modelo de Clases para definir el empaquetamiento lógico de las clases. Defina las pruebas de integración para cada componente para confirmar que su interfaz cumple con la especificación que se dio en su relación con otros elementos de software.
7. Debería haber capturado y documentado requisitos adicionales en forma concurrente con el trabajo que ya hizo. Por ejemplo, requisitos no funcionales, de rendimiento, de seguridad, responsabilidades, planes de entrega. Recopile esto junto con el modelo y manténgalo actualizado a medida que madura el modelo.
8. El Modelo de Despliegue define la arquitectura física del sistema. Este trabajo se puede comenzar en forma temprana para capturar las características físicas del despliegue -qué hardware, sistemas operativos, capacidades de la red, interfaces y software de soporte constituirán el sistema, dónde se desplegará y qué parámetros aplicar para recuperación ante desastres, confiabilidad, copia de seguridad y soporte. La arquitectura física se actualizará a medida que se desarrolla el sistema para reflejar el sistema real que se está proponiendo.
9. Construya el sistema: tome porciones discretas del modelo y asígnelas a un desarrollador o más. En una construcción dirigida por casos de uso esto significará asignar un caso de uso al equipo de desarrollo, haciéndolos construir las pantallas, objetos de negocio, tablas de la base de datos y componentes relacionados necesarios para ejecutar ese caso de uso. A medida que se construye cada caso de uso se lo debería acompañar con pruebas de completitud, de integración y de sistema. Una construcción dirigida por componentes puede ver componentes de software que se asignan para su construcción a equipos de desarrollo.
10. Siga la pista de los defectos que surgen en las fases de prueba en los elementos relacionados del modelo -por ejemplo, los defectos de las pruebas de sistema en los casos de uso, los defectos de las pruebas unitarias en las clases, etc. Siga la pista de cualquier cambio en los elementos de modelado relacionados a fin de administrar el 'avance del alcance'.
11. Actualice y refine el modelo a medida que procede el trabajo -aplicando siempre el impacto de los cambios y del refinamiento del modelo en el trabajo posterior-. Utilice un enfoque iterativo para trabajar en porciones discretas durante el diseño, aplicando siempre a la construcción actual, los requisitos que surjan y cualquier descubrimiento que salga a la luz durante el desarrollo.
12. Entregue el software completo y probado para una prueba en el ambiente de producción. Si se está llevando a cabo una entrega en fases, esta migración desde la prueba a la producción del software que se construyó puede ocurrir muchas veces durante la vida del proyecto.

Nota: Tenga en cuenta que el proceso de arriba es, necesariamente, breve en su descripción, deja muchas cosas sin decir y puede no seguir el procesó que Ud. adoptó. Se dio como un ejemplo de cómo se usa el UML para dar soporte a un proyecto de desarrollo de software.

Por: Rubén Suárez Alvarez | UML | Comentarios (0) | Referencias (0)