Componiendo lo Descompuesto - Diagrama de Estructura Compuesta
Por Sergio Orozco

En el mundo real, el mundo de los objetos, algo normal que nos encontramos son objetos que están compuestos por más objetos. UML nos permite modelar dicha información por medio de relaciones de composición entre los objetos contenedores y sus partes.

Dicha relación se muestra tradicionalmente con un diamante relleno en la orilla del contenedor, en una relación entre el contenedor y la parte. En el siguiente diagrama podemos ver que un carro tiene un motor, y dicho motor no puede ser parte de otro carro en un momento determinado en el tiempo.

Pero, modelar en UML composiciones de objetos podía volverse muy complejo en ciertas situaciones. Como en el caso de un carro y un barco que estuvieran compuestos por motor, pero donde para el primero el motor ayudara a mover las ruedas delanteras y en el segundo caso el motor sirviera para mover el propulsor del barco. Habría que realizar un modelo complejo para aclarar (a quien pudiera leer el diagrama), que habia una diferencia entre el motor que tenía el carro y el motor del barco.

El diagrama anterior intenta explicar esto, pero tiene deficiencias, pues aunque aclara con la multiplicidad de las conexiones de carro y barco (0..1) como contenedores del motor, que sólo puede estar la instancia del motor en uno de los dos; por otra parte parece decirnos que el motor del carro puede mover tanto propulsor como llantas. Lo cual es equivocado, pues el motor del barco sólo mueve el propulsor y el del carro sólo mueve sus llantas. Tampoco aclara que las dos llantas que mueve el motor en el carro son las delanteras, y no las dos traseras.

Para modelarlo correctamente en un diagrama de clases tendríamos que elaborar toda una jerarquía de herencia entre clases para distinguir entre los motores de barcos y carros, y entre las llantas delanteras y traseras de un carro, o marcando dependencias entre las relaciones.

Con UML 2 ahora contamos con un nuevo diagrama, llamado diagrama de estructura compuesta, que nos permite contextualizar las partes que componen a una clase. Así podemos armar un diagrama donde aclaremos que el carro tiene un motor que mueve las dos llantas delanteras (pero, no las traseras ni el propulsor), y otro diagrama del mismo tipo que nos permitiría mostrar el barco con un motor que exclusivamente mueve su propulsor (y no las llantas).

El contexto lo define la clase contenedora, que con fines de este ejemplo serían el carro o el barco. Y dentro de dicha clase modelamos las partes que lo componen, como se muestra a continuación. Cada uno de estos diagramas muestra la estructura interna de una instancia de carro y de barco respectivamente.

En este caso nos queda mucho más claro que cada uno tiene un motor, pero que funciona de manera diferente. Incluso es claro que el motor del carro mueve exclusivamente las dos llantas delanteras, y no las dos traseras.

Los elementos que tradicionalmente se muestran en este tipo de diagrama son:

• Clase. Para mostrar la parte de la cual se ilustra su composición interna (ejemplo: carro o Barco)
• Parte. Se muestra con un rectángulo, e indica los objetos que conforman al objeto principal. Ejemplo: el motor y las llantas en el carro, o el motor y el propulsor en el Barco. Si se coloca una parte dentro de una clase significa, en un diagrama de clases, que la clase contenedor tiene una relación de composición con dicho elemento.
• Conector. Indica la relación entre las parte internas de la clase que se analiza.
• Puertos. Se pueden mostrar puertos para indicar la entrada o salida de una parte hacia otra parte. Se muestran como pequeños cuadrados al final de un conector entre dos partes. No son obligatorias, pero son recomendables si se quiere encapsular el funcionamiento de las partes.

Un uso adicional que se puede dar a los diagramas de estructura compuesta es para mostrar las partes que colaboran, por ejemplo, en un caso de uso. Aunque en esta ocasión no explicaremos esta perspectiva, consideramos importante mencionarlo y mostrar un pequeño ejemplo.

En este ejemplo podemos ver que son tres las clases que colaboran en el caso de uso “Participar en curso”: el estudiante, el curso y el seminario. Esta forma nos permitiría modelar patrones de diseño indicando los roles que juega cada clase en la colaboración.

Por Sergio Orozco

Publicado en la revista Software Gurú, en su edición de marzo, 2007.
Reproducido con permiso del autor.


Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML