diagramas de estructura compuesta

Diagrama de Estructura Compuesta UML 2

Diagramas de Estructura CompuestaUn diagrama de estructura compuesta es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción a otras partes del sistema. Esto muestra la configuración y relación de las partes que juntas realizan el comportamiento de clasificador contenido. Los elementos de clase han sido descriptos en gran detalle en la sección en los diagramas de clase. Esta sección describe la forma en que las clases se pueden mostrar como elementos compuestos exponiendo interfaces y conteniendo puertos y partes. Una parte es un elemento que representa un conjunto de una o más instancias que pertenecen a una instancia del clasificador contenida. Por ejemplo, si una instancia de diagrama se apropia de un conjunto de elementos gráficos, luego los elementos gráficos se pueden representar como partes, si fuera útil hacer eso para modelar algún tipo de relación entre ellos. Tener en cuenta que una parte se puede quitar de sus padres antes de que el padre se elimine, para que la parte no se elimine al mismo tiempo. Una parte se muestra como un rectángulo no adornado dentro del cuerpo de una clase o del elemento componente. Una parte se muestra como un rectángulo no adornado dentro del cuerpo de una clase o del elemento componente. Un Puerto se muestra como un rectángulo nombrado en el borde del límite de su clasificador apropiado. Un Puerto se muestra como un rectángulo nombrado en el borde del límite de su clasificador apropiado. Una interfaz es similar a una clase pero con un número de restricciones. Todas las operaciones de la interfaz son públicas y abstractas, y no proveen ninguna implementación predeterminada. Todos los atributos de la interfaz deben ser constantes. Sin embargo, mientras que una clase puede solo heredar de una sola super-clase, puede implementar interfaces múltiples. Una interfaz, cuando esta sola en un diagrama, se muestra como un rectángulo del elemento clase con  la clave «interfaz» y con su nombre en itálica para denotar que es abstracto, o se muestra como un circulo. Una interfaz, cuando esta sola en un diagrama, se muestra como un rectángulo del elemento clase con  la clave «interfaz» y con su nombre en itálica para denotar que es abstracto, o se muestra como un circulo. Una interfaz provista se muestra como una “pelota en un palo” adjuntada al borde de un elemento clasificador. Una interfaz requerida se muestra como una “copa en un palo” adjuntada al borde de un elemento clasificador. Una interfaz provista se muestra como una “pelota en un palo” adjuntada al borde de un elemento clasificador. Una interfaz requerida se muestra como una “copa en un palo” adjuntada al borde de un elemento clasificador. Un conector delegar se usa para definir los trabajos internos de los puertos e interfaces externas del componente. Un conector delegar se muestra como una flecha con un estereotipo «delegar». Esto conecta un contrato externo de un componente como se muestra por sus puertos a la realización interna del comportamiento de la parte del componente. Una colaboración define un conjunto de roles co-operativos usados colectivamente para ilustrar una funcionalidad especifica. Una colaboración debería solo mostrar los roles y los atributos requeridos para lograr sus tareas o funciones definidas. Aislar los roles primarios es un ejercicio de simplificar la estructura y clasificar el comportamiento, y también provee para poder re- usarlo. Un elemento colaboración a menudo implementa un patrón. Un elemento colaboración se muestra como un elipse Un elemento colaboración se muestra como un elipse Un conector enlace de roles se dibuja desde una colaboración a un clasificador que completa el rol. Esto se muestra como una línea de trazos con una punta de flecha y el estereotipo «enlace de roles». Un conector representa se puede dibujar desde una colaboración a un clasificador para mostrar que una colaboración se usa en el clasificador. Se muestra como una línea de trazos con una punta de flecha y el estereotipo «representa». Un conector ocurrencia se puede dibujar desde una colaboración a un clasificador para mostrar que la colaboración representa (sic) el clasificador. Esto se muestra como una línea de trazos y el estereotipo «ocurrencia». Parte Puerto Un Puerto es un elemento escrito que representa una parte visible externa de una instancia del clasificador contenido. Los puertos definen la interacción entre un clasificador y su entorno. Un Puerto puede aparecer en el límite de la parte contenida, una clase o una estructura compuesta. Un Puerto puede especificar los servicios que un clasificador provee así como también los servicios que este requiere de su entorno. Interfaces Tener en cuenta que la notación del círculo no muestra las operaciones de la interfaz. Cuando las interfaces se muestran como si fueran apropiadas por las clases, se refieren a ellas como interfaces expuestas. Una interfaz expuesta se puede definir como provista o requerida. Una interfaz provista es una afirmación que el clasificador contenido provee a las operaciones definidas por el elemento de la interfaz nombrada y se define dibujando un vínculo de realización entre la clase y la interfaz. Una interfaz requerida es un estado que el clasificador puede comunicar con algún otro clasificador que provee operaciones definidas por el elemento de la interfaz nombrada y se define dibujando un vínculo de dependencia entre la clase y la interfaz Delegar Colaboración Enlace de Roles Representa Ocurrencia

• 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.

Este diagrama de estructura compuesta UML 2.0 especifica que las instancias de la clase 'FibonacciSystem' están compuestas de varias partes. La superior de estas partes está identificada como teniendo el clasificador 'FibonacciFunction'. Tres de las partes son identificadas por el rol que ellas juegan dentro de instancias del FibonacciSystem – el rol NMinus2, el rol NMinus1, y el rol N. La quinta parte, identificada por su clasificador Viewer, incluye una especificación de multiplicidad. En tiempo de ejecución puede haber 0 o más instancias de Viewer o de alguna subclase concreta de Viewer.

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 había 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:

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.

Como ejemplo, considere un modo posible de modelar la producción de la Sucesión de Fibonacci.

Diagrama de estructura compuesta UML 2.0

En tiempo de ejecución las instancias de clase que implementan estos tres roles deben proveer los servicios especificados por la interfaz IVar mediante sus puertas var. Una de tales clases es Variable, mostrada sobre el diagrama con una puerta llamada var de tipo Var que realiza la interfaz IVar.
La puerta llamada "view" es una puerta no-pública que puede ser usada por una instancia de FibonacciSystem para acceder a la(s) instancia(s) opcional(es) de Viewer.