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.