Tutorial UML - Parte 2


En la primer parte hemos establecido que UML es un lenguaje para especificar los artefactos y las interacciones de un sistema de software. También hemos visto que trata con 6 dominios principales – desde modelos de Casos Uso, a través de modelos dinámicos y lógicos hasta el modelo de despliegue físico final – y que los mecanismos de extensión se han incluido para permitir las adiciones especializadas a la notación del modelo.

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

El UML se usa normalmente como una parte de un proceso de desarrollo de software, con el soporte de la herramienta CASE apropiada, para definir los requisitos, las interacciones y los elementos del sistema de software propuesto. La naturaleza exacta del proceso depende de la metodología del desarrollo usada. El siguiente es un ejemplo del siguiente proceso

1. Captura un Modelo del Proceso de Negocio. Este se usará para definir las actividades y procesos de alto nivel que ocurren en una organización y proveen una base para el modelo de Casos de Uso. El Modelo del Proceso de Negocios normalmente capturará más de lo que implementaría un sistema de software (Es decir, este incluye procesos manuales y otros).
2. Traza un Modelo de Casos de Uso al Modelo del Proceso de Negocio para definir exactamente que funcionalidad intenta proveer desde la perspectiva del usuario de negocios. Mientras cada Caso de Uso se agrega, crea un vínculo trazable desde los procesos de negocios apropiados al Caso de Uso (es decir, una conexión de realización). Este trazado claramente establece que funcionalidad proveerá el nuevo sistema para cumplir con los requisitos del negocio establecido en el modelo del proceso. Este también asegura que no existe ningún Caso de Uso sin un propósito.
3. Refine los Casos de Uso – incluye requisitos, restricciones, clasificación de complejidad, notas y escenarios. Esta información ambiguamente describe lo que hace el Caso de Uso, como se ejecuta y las restricciones en esta ejecución. Se asegura de que el Caso de Uso todavía reúne los requisitos del proceso de negocio. Incluye la definición de las pruebas del sistema para cada Caso de Uso y así definir el criterio de aceptación para cada Caso de Uso. También incluye algunos scripts de pruebas de aceptación del usuario para definir como el usuario probará esta funcionalidad y cuales son los criterios de aceptación.
4. Desde las entradas y las salidas del Modelo del Proceso de Negocio y los detalles de los casos de uso, comienza a estructurar un modelo de dominio (objetos de negocio de alto nivel), diagrama de secuencia, diagrama de colaboración y los modelos de la interfaz de usuario. Estos describen las “cosas” en el nuevo sistema, la manera en que esas partes interactúan y la interfaz que un usuario usará para ejecutar los escenarios de los casos de uso.
5. Desde el modelo de dominio, el modelo de la interfaz de usuario y los diagramas del escenario crean el Modelo de Clase. Esta es una especificación precisa de los objetos en el sistema, sus datos o atributos y su comportamiento u operaciones. Los objetos del dominio se pueden abstraer en las jerarquías de la clase usando herencias. Los mensajes del diagrama del escenario normalmente trazarán las operaciones de la clase. Si se usa un marco existente o patrón del diseño, es posible importar elementos del modelo existentes para usarlos en el nuevo sistema. Para cada clase define pruebas de unidad y pruebas de integración para probar completamente i) que la clase funciona como se especifican internamente y que ii) la clase interactúe con otras clases relacionadas y los componentes como se espera.
6. Mientras la clase del modelo se desarrolla, se puede fraccionar en paquetes y componentes discretos. Un componente representa una porción despegable del software que recolecta el comportamiento y datos de una o más clases, y expone una interfaz estricta a otros consumidores de sus servicios.  Así un Modelo del Componente se compila para definir el empaquetamiento lógico de las clases. Para cada componente define pruebas de integración para confirmar que la interfaz del componente reúne la especificación dada en relación con otros elementos del software.
7. Concurrentemente con el trabajo que ya realizó, se deberían capturar y documentar requisitos adicionales. Por ejemplo – los requisitos funcionales, requisitos de desempeño, requisitos de seguridad, responsabilidades, liberar planos y más. Colecta estos dentro del modelo y los mantiene al día mientras madura el modelo.
8. El Modelo de Despliegue define la arquitectura física del sistema. Este trabajo puede comenzar tempranamente para capturar las características de despliegue físico – que hardware, sistemas operativos, capacidades de la red, software de interfaces y soporte conformarán el nuevo sistema, donde se desplegará y que parámetros aplica para recuperarse de los desastres, confiabilidad, copias de seguridad y soporte. Mientras el modelo se desarrolla la arquitectura física se actualizará para reflejar el sistema actual propuesto.
9. Construye el sistema: Toma piezas discretas del modelo y asigna uno o más desarrolladores. En una compilación dirigida por Casos de Uso, esto significará asignar un Caso de Uso a un equipo de desarrollo, y hacer que ellos construyan pantallas, objetos de negocio, tablas de base de datos, y los componentes relacionados necesarios para ejecutar ese Caso de Uso. Mientras cada Caso de Uso se construye, éste debería estar acompañado por pruebas de sistema, integración y unidad completas. Una construcción dirigida del componente puede ver componentes del software discretos asignados a los equipos de desarrollo para su construcción.
10. Rastrea los defectos que emergen en la fase de pruebas contra los elementos del modelo relacionados – ej. Defectos de prueba del sistema contra los Casos de Uso, defectos de prueba de unidad contra las clases etc. Rastrea cualquier cambio contra los elementos del modelo relacionado para administrar “scope creep”.
11. Actualiza y refine el modelo mientras procede el trabajo – siempre evaluando el impacto de cambios y mejoras del modelo en trabajos posteriores. Usa una aproximación iterativa para trabajar a través del diseño en fragmentos discretos, siempre evaluando la compilación actual, los requisitos posteriores y cualquier descubrimiento que aparece durante el desarrollo.
12. Entrega del software completo a un proceso de prueba y al entorno de producción. Si se realiza una entrega en fases, luego ésta migración del software de construcción desde la prueba a la producción puede ocurrir varias veces en la vida del producto.

Tener en cuenta que el proceso anterior es necesariamente corto en descripción, deja mucho sin decir y puede ser que no corresponda a su forma de trabajo y que no siga el proceso que ha adoptado. Esto se ha proporcionado como un ejemplo de como se puede usar UML para soportar un proyecto de desarrollo de software.