4.4. Análisis y Diseño con el Diagrama de Clase
El Diagrama de Clase es el el diagrama principal de diseño y análisis para un sistema. En él, la estrucutra de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones.
4.4.1. Desarrollo de Diagramas de Clase durante el análisis
4.4.1.1. Aproximación a un Caso de Uso guiado
En una aproximación a un Caso de Uso guiado hacia el análisis orientado a objetos, el diagrama de clases se desarrolla a través de información obtenida en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboración. Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.
Figura 7: Diagrama de Clase durante la fase de análisis
4.4.1.2. Extensión guiada por la responsabilidad
La técnica de la tarjeta CRC se usa a veces como una extensión a UML para análisis guiados por la responsabilidad. Las definiciones de clase son refinadas basándose en las responsabilidades de clase y en otras clases con las que colabora para completar sus responsabilidades.
Cada clase se representa en una tarjeta índice (index card), y los diseñadores establecen los papeles (roles) de las clases en el sistema para definir su trabajo, y con qué otras necesitan colaborar para completar sus responsabilidades. Esta información se pasa directamente a un diagrama de clase; las responsabilidades coinciden con los métodos de clase, las colaboraciones se traducen en asociaciones entre clases.
Figura 8: Extensión informal de UML -- Tarjetas CRC para análisis guiados por la responsabilidad.
4.4.2. Diseño del sistema con Diagramas de Clase
Durante el diseño, el Diagrama de Clase se elabora para tener en cuenta los detalles concretos de la implementación del sistema.
4.4.2.1. Arquitecturas Multicapas
Una vez concienciados del diseño, estableceremos la arquitectura del sistema. Esto incluye establecer si será un sistema simple diseñado para correr en una sola máquina, un sistema 'two-tiered' consistente en un cliente y un servidor, o un sistema 'multi-tiered' con objetos interfaz de usuario separados de los objetos 'business', separado de la base de datos, cada uno corriendo en plataformas distintas.
Una aproximación a dirigir el diagrama de clase para un sistema complejo es separar el diagrama en seccionesque muestren la lógica de la aplicación, el diseño de la interfaz de usuario, y las clases implicadas con el almacenamiento de los datos. Esto se puede hacer físicamente segmentando el diagrama de clase, usando diagramas separados para cada sección, o simplemente añadiendo una propiedad a cada clase que 'tracks' cada 'tier' al cual pertenece.
4.4.2.2. Diseño de Componentes
Un componente es un grupo de objetos o componentes más pequeños que interaccionan entre ellos y se combinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios del componente se especifican por su interface o interfaces, sin ofrecer concimiento del diseño e implementación internas del componente. El desarrollo basado en componentes es el proceso de ensamblar la combinación correcta de componentes en la configuración correcta para llevar acabo la funcionalidad deseada para un sistema. Los componenetes se representan en el diagrama de clases de UML especificando la interfaz de una clase o paquete. Hay dos notaciones para mostrar una interfaz - una es mostrar la interfaz como una 'regular class symbol' con el estereotipo "interfz", con una lista de operaciones soportadas por esta interfaz, detalladas en el 'operation department' (departamento de operación). 'The alternate, shortcut notation' es mostrar la interfaz como un circulo pequeño junto con la clase con una línea sólida, con el nombre de la interfaz en el círculo.
El ejemplo de la Figura 9 muestra que la clase 'Pasajero' ofrece la operación move(x coord, y coord) para su apariencia en un GUI, a través de su interfaz 'Displayable'. Ambas notaciones UML de interfaz, se muestran en la figura. Además, la clase Pasajero también ofrece una opción save(store at) a través de su interfaz Persistente. Una clase de o componente para conectar con una base de datos podría usar esta interfaz.
Figura 9: Diseño de Componentes: Especificando la Interfaz de la Clase
4.4.2.3. Análisis y diseño 'Iterative'
El diagrama de clase se puede desarrollar en una 'iterative fashion', a través de un ciclo repetido de análisis, diseño e implementación, y después vuelta al análisis, para empezar el ciclo de nuevo. Este proceso se suele llamar 'round-trip engineering'. El modelado de herramientas como System Architect 2001 puede facilitar este proceso permitiéndote implementar el diseño en un lenguaje como C++ o Java, y después traer de vuelta al código a al diagrama de clase, automáticamente actualizando la información contenida en el diagrama y en el 'underlying repository'.
Figura 10: Análisis, diseño y documentación 'Iterative' con el Diagrama de Clase