Capítulo 4. Un estudio a fondo de UML
Las siguientes secciones presentan una vista más detallada al modelado con UML. Un sistema de reserva de aerolíneas simple se va a usar para mostrar los diagramas y técnicas de modelado con UML. Se cubren los siguientes puntos:
Organizando tu sistema con paquetes
Modelando con Casos de Uso, y usándolos para averiguar los requisitos del sistema
Modelando con Diagramas de Secuencia y Colaboración
Analizando y diseñando con el Diagrama de Clase, y extendiendo UML con la técnica de las tarjetas CRC
Modelando comportamiento con Diagramas de Actividad y de Estado
Modelando componentes de software, distribución e implementación
Extendiendo UML con el diseño de Bases de Datos relacionales
Una de las tareas clave para modelar un sistema de sofware de grandes dimensiones es dividirlo primero en áreas manejables. Aunque estas áreas se llaman dominios, categorías o subsistemas, la idea es la misma: dividir el sistema en áreas que tengan competencias parecidas.
UML introduce la noción de un paquete como el ítem universal para agrupar elementos, permitiendo a los modeladores subdividir y categorizar sistemas. Los paquetes pueden ser usados en cualquier nivel, desde el nivel más alto, donde son usados para subdividir el sistema en dominios, hasta el nivel más bajo, donde son usados para agrupar casos de uso individuales, clases, o componentes.
Figura 2: Organizando el sistema mediante el uso de paquetes
4.1. Modelado de Casos de Uso
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML.
El modelo de casos de uso consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que interaccionan con el sistema. Se dibujan como "muñecos" de palo. Actualmente representan el tipo de usuario, no una instancia de usuario. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde un actor. Se dibujan como elipses.
Figura 3: Modelado de Casos de Uso.
Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otras propiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que el escenario comience, y condiciones que existen después de que el escenario se completa. Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. éstos son descritos en una sección posterior de este documento.
4.1.1. Estudiar y descubrir los requisitos
El objetivo final en cualquier diseño de software es satisfacer los requisitos del usuario para el sistema. Estos requisitos pueden ser requisitos de software, requisitos de productos, o requisitos de pruebas. La meta de capturar y comprobar los requisitos del usuario es asegurar que todos los requisitos son completados por el diseño, y que el diseño es acorde con los requisitos especificados.
Muchas veces los requisitos del sistema ya existen en forma de documentos de requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos no existen, modelar el sistema a través de los Casos de Uso, permite el descubrimiento de estos requisitos.
4.1.2. Organización de Diagramas de Casos de Uso
Durante el análisis de negocio (business) del sistema, puedes desarrollar un modelo de caso de uso para este sistema, y construir paquetes para representar los varios dominios de negocio (business) del sistema. Puedes descomponer cada paquete con un Diagrama de Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones de actor.
4.1.3. Un Caso de Uso para cada escenario
El objetivo es construir un Diagrama de Caso de Uso para cada tipo de escenario diferente en el sistema. Cada escenario muestra una secuencia diferente de interacciones entre actores y el sistema, sin condiciones 'or'.
4.1.4. Modelar secuencias alternas a través de la relación "Extiende" (extends)
Típicamente, uno modela cada Caso de Uso con una secuencia normal de acciones. El usuario entonces considera condiciones "que si" para cada paso, y desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las secuencias alternas se modelan en casos de uso separados, los cuales están relacionados con el caso de uso original mediante una relación "Extiende" (extends). Las relacciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original.
4.1.5. Eliminar el modelado redundante a través de la relación "Usa" (uses)
Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios casos de uso, la parte del comportamiento puede ser modelada en un caso de uso separado que está relacionado con los otros casos de uso mediante la relación "Usa" (uses). La relación Usa (uses) se puede pensar como un caso de uso equivalente 'of aggregation'.
Figura 4:: Relación caso de uso Extiende (extends) frente a relación de caso Usa (uses).
4.1.6. Ayuda en casos de uso probando el sistema frente a los requisitos
Los Casos de Uso también se utilizan para constriur scripts de prueba que se usan a su vez para comprobar que la aplicación satisface los requisitos de negocio y de sistema.
Cuando has llegado al caso de uso del nivel más bajo, podrías crear un Diagrama de Secuencia para el Caso de Uso. Con los Diagramas de Secuencia y de Colaboración puedes modelar la implementación del escenario.