Diagrama de clases UML
Relaciones y herramientas de diseño UML
El diagrama de clases sirve para mostrar las relaciones entre las clases que componen el sistema. Un diagrama de clases UML está compuesto por los siguientes elementos:
Las clases de un diagrama se pueden relacionar entre sí de diferentes modos. La manera en la que se relacionan dictamina el modo de implementar el modelo mediante un lenguaje, y además, restringen la existencia de los objetos de una clase.
Se representa mediante una línea que une dos clases. Su sentido es dar información acerca de cómo se relaciona las instancias de una clase con las instancias de otra clase.
Una asociación puede estar calificada con el objetivo de dotar de más expresividad o significado a una relación. Una calificación nos dice mucho más que el de una mera línea.
En esencia, la cardinalidad de las asociaciones deberían escribirse siempre de la siguiente manera: “N..M”, siendo N y M números enteros o un asterisco ‘*’. N restringe el número mínimo de objetos que se pueden relacionar con los objetos de la otra parte de la relación. M restringe a su vez el número máximo.
A modo de ejemplo, en la figura que aquí se representa, podemos sustituir partiendo de la regla general N y M por los siguientes valores:
| Sustituir por | Significado | Explicación |
| 0..1 | de cero a uno | Una instancia de la clase A se relaciona con cero o una instancia de la clase B. |
| 3..5 | de tres a cinco | Una instancia de la clase A se relaciona con tres, cuatro o cinco instancias de la clase B. |
| 6 | seis | Una instancia de la clase A se relaciona con exactamente seis instancias de la clase B. |
| 0..* | de cero a muchos | Una instancia de la clase A se relaciona con cero o n instancias de la clase B. |
| 1..* | de uno a muchos | Una instancia de la clase A se relaciona como mínimo con una instancia de la clase B y como máximo con n. |
| 5..* | de cinco a muchos | Una instancia de la clase A se relaciona como mínimo con cinco instancias de la clase B y como máximo con n. |
| * | de cero a muchos | Lo mismo que 0..* |
Un aspecto que cuesta un poco de asimilar al principio, es que las cardinalidades de una clase en una asociación aparecen en el lado contrario (de la asociación) de clase que está relacionada. A modo de reforzar más aún tanto este concepto como el tema de las cardinalidades en general, vamos a ver un ejemplo:
En este ejemplo, un profesor puede no trabajar (0) en ningún departamento, pero si trabaja en algún departamento trabaja en uno (1) y sólo uno. Por otro lado, desde el punto de vista de los departamentos: un departamento, si existe como tal, está obligado a tener un mínimo de 2 profesores (2) que trabajen en él, y como máximo los profesores que se quieran (*).
En ocasiones, en una relación aparece una flechita. El significado de ésta es que la asociación sólo se puede recorrer en un sentido, es decir, a partir de un objeto de una clase podemos acceder al otro, pero no viceversa.
En este ejemplo, lo que se está dando a entender, es que las cuentas tienen acceso a las transferencias que se han hecho con ellas, pero las transferencias no tienen información acerca de en qué cuentas se han realizado.
Para modelar clases complejas no bastan los tipos de datos básicos que proveen los lenguajes de programación: enteros, reales, secuencias de caracteres, …Cuando se requiere componer objetos a partir de otros aparecen los conceptos de composición (algo está compuesto de) y de agregación (un grupo de …. forman un …).
Todas las instancias de cada una de las clases tienen su ciclo de vida propio. Éste puede verse restringido por las cardinalidades de las relaciones, pero también (y quizás, sobre todo) por las composiciones y por las agregaciones.
Tanto las agregaciones como las composiciones son asociaciones, y quizás la manera de identificarlas tanto a unas como a otras es que la relación entre dos clases se podría traducir como un “A tiene B’s” en el sentido que un objeto contiene a otros.
El objeto contenido puede o no tener consciencia del objeto contenedor, pero lo normal es que no. Es decir, los objetos que componen un todo no tienen porque tener consciencia de qué objetos los contienen, y quizás esta es una recomendación para usar agregaciones y composiciones
Es un tipo de asociación estática y fuerte, en la cual la longevidad del objeto incluido depende del objeto que lo incluye, es decir si este último objeto muere también lo hará el objeto incluido. El objeto compuesto se construye a partir de los objetos incluidos. Si desaparece el objeto compuesto, desaparecen todos los objetos componentes relacionados con él.
Los programas que permiten modelar UML permiten poner cardinalidad en la parte del rombo, aunque en esencia debe de ser 1 (o 0..1 según qué casos).
Se representa con un rombo relleno en la parte de la relación que enlaza al objeto compuesto.
Si desaparece la mesa, desaparecen las patas.
Si desaparece el almacén, desaparecen todas sus cuentas.
Es un tipo de asociación dinámica y débil, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Esto significa que si el objeto que agrega a los demás desaparece no tienen porqué desaparecer los objetos agregados.
Los programas que permiten modelar UML permiten poner cardinalidad en la parte del rombo, aunque en esencia debe de ser *.
Se representa con un rombo sin rellenar en la parte de la relación que enlaza al objeto compuesto.
Si desaparece el almacén, no tiene porqué desaparecer los clientes.
En una asociación entre dos clases la propia asociación puede tener propiedades. Por ejemplo, entre un empleado y una compañía pueden considerarse propiedades como salario, cargo, fecha de alta en la compañía, etc…que realmente no pertenecen al empleado y tampoco a la compañía. En este caso se usa una clase asociación, representada con un símbolo de clase unido por línea discontínua a una asociación. En el siguiente ejemplo la clase asociación Contrato relaciona a una persona con un departamento:
También es llamada generalización/especialización. Se le llama superclase, clase padre o clase base a la clase a partir de la cual heredan otras clases. Las otras clases que heredan de la clase base se les llama clases derivadas, clases hijas o subclase.
En este tipo de relación se indica que una subclase hereda los métodos y atributos especificados por una superclase, por ende la subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles (public, protected y dependiendo del package) de la superclase.
Esta relación se representa mediante una flecha con el fondo blanco que va desde la clase derivada a la clase base.
En cuanto a las interfaces (si es que el sistema que manejemos las soporta), cuando una clase implementa una interfaz, se dice que la realiza. Se representa igual que una herencia sólo que la línea de la flecha es discontinua.
Cuando existe una jerarquía de herencias de clases, estas herencias se pueden clasificar semánticamente en las siguientes:
Total / Parcial: Todos / no todos los objetos pertenecen a una clase especializada. ○ ¿Todos los vehículos son o coches o motos?
Disjunta / Solapada: Los conjuntos especializados son excluyentes / no excluyentes. ○ Un vehículo, ¿puede ser coche y moto a la vez?
Se especifica mediante una flecha discontinua. Es un tipo de relación establece que una clase necesita de otra para poder funcionar, pero que en principio no almacena ninguna referencia a ella. Es algo parecido a un servidor de datos y un cliente de datos. La flecha va desde la clase que necesita algo hacia la clase que lo proporciona.
En una relación que tenga nombre, se puede establecer también un alias para los objetos que participan en esa relación como algo especial.
Son relaciones en las que los objetos de una clase se relacionan con otros objetos de esa misma clase. En este tipo de relaciones es conveniente aportar roles para poder definir lo mejor posible a la relación.
Existen cientos de herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) que soportan el lenguaje UML. A la hora de elegir una herramienta hay que tener claro para qué se va a utilizar y cuál es el objetivo que se propone, porque podemos pensar en utilizar una herramienta para que genere el código de las clases, o simplemente utilizar la herramienta para dibujar modelos y añadirlos a nuestra aplicación.
Modelio es una herramienta UML de código abierto disponible para Windows, Linux y MacOS. La ventaja que nos ofrece Modelio es que nos permite generar código Java a partir del modelo realizado.
PlantUML es una herramienta de código abierto que permite pintar diagramas UML con un lenguaje de código simple sin tener que dibujar el diagrama. Es decir, este software es capaz de leer diagramas en formato de texto y en una ventana dibujarlo por nosotros. A nivel estético está bastante limitado.