Componiendo lo Descompuesto: Diagrama de Estructura Compuesta

En el mundo real –el mundo de los objetos–, es muy común encontrarnos con 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�Tal relación se muestra tradicionalmente como una asociación entre el contenedor y la parte, con un diamante relleno en la orilla del contenedor. En el siguiente diagrama de la Figura 1 podemos ver que, un carro tiene un motor, y el motor no puede ser parte de otro carro en un momento determinado en el tiempo.

Figura 1.

Modelar de esta forma la composición de objetos puede ser complejo en ciertas situaciones, como en el caso de un carro, y un barco compuestos por un motor; 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. Para lo que habría que realizar un modelo complejo para aclarar que había una diferencia entre el motor que tenía el carro y el motor del barco.

Figura 2.

El diagrama anterior de la Figura 2 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. Esto se muestra en la figura 3.

Figura 3.

Agregando contexto en UML 2
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 en la Figura 4. Cada uno de estos diagramas muestra la estructura interna de una instancia de carro y de barco, respectivamente.

Figura 4.

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 dicha perspectiva, consideramos importante mencionarlo, y mostrar una pequeña muestra.

En el ejemplo de la Figura 5 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.

Figura 5.

Acerca del autor
Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, PM y orientación a objetos.  Milestone Consulting es la primer empresa mexicana miembro de la OMG, además de REP del PMI.   info@milestone.com.mx    www.milestone.com.mx