FORMATO
LECTURA PARA

Lectura 1. Diagramas de paquetes y estructura compuesta

Los diagramas presentados en este documento ofrecen una visión estructural de una
aplicación de software y sus componentes y artefactos, desde una perspectiva que varía en
niveles de complejidad, detalle y cobertura. Sin embargo, utilizados de manera constructiva y
completa, resultan extremadamente útiles cuando se desea comprender cabalmente cuál es
la estructura estática final de un proyecto. Cada uno de ellos contiene y contempla
elementos que resultan complementarios y que reflejan aspectos relevantes del modelo. A
pesar de que puede no resultar necesario siempre, son una herramienta muy ventajosa para
tener en el arsenal de un diseñador de software.

DIAGRAMA DE PAQUETES
El concepto de paquete surge de la necesidad de organizar una ingente cantidad de
elementos a través de una estructura jerárquica que permita encontrar rápidamente lo que se
está buscando, pero que a la vez mantenga un orden de relación entre los elementos
almacenados. UML ofrece los paquetes para suplir esta necesidad. La herramienta puede ser
utilizada en diferentes frentes y con distintos propósitos.
En primera instancia, un paquete puede ser utilizado para organizar los diagramas UML
elaborados en el contexto de un proyecto de software. La estructura aquí es básicamente la
misma que en una estructura jerárquica de directorios, en un sistema de archivos. Un paquete
puede contener cualquier tipo de diagrama e incluso otros paquetes. De esta forma, es
posible organizar los diagramas UML de un proyecto de acuerdo con la estructura que se
requiera. En la figura que se presenta a continuación, se muestra un paquete cumpliendo esta
función:

<<useCasePackage>>
Casos de uso

Figura 1. Paquete conteniendo diagramas UML

En el ejemplo presentado, se utiliza un paquete llamado Casos de uso para organizar los
diferentes diagramas de casos de uso y sus componentes, utilizados en el proyecto de
software. Nótese el texto <<useCasePackage>>. En este contexto, es lo que se conoce
como un estereotipo. Identifica el rol que está cumpliendo el paquete dentro del contexto
del proyecto. En este caso, el estereotipo <<useCasePackage>>, ofrecido por la herramienta
de diseño UML utilizada, identifica el paquete como uno que contiene diagramas de casos
de uso. Sin embargo, ya que el concepto de paquete es tan amplio, es posible pensar en

En alianza con

 
Colombia
 

utilizar prácticamente cualquier estereotipo que sirva para identificar el propósito del
paquete al que se aplique. El objetivo aquí es ser lo más claro posible en términos de para
qué se crea el paquete, y qué contiene.
La segunda forma en que un paquete puede ser utilizado, es para representar un subsistema
dentro de la solución de software. En muchas ocasiones, puede resultar ventajoso tener
organizadas las partes constitutivas de la solución en secciones de acuerdo con su
propósito. De esta manera, podría utilizarse un paquete de la siguiente manera:

Inventario

Figura 2. Paquete representando un subsistema

En este caso, el paquete representa un subconjunto de todo el sistema, cuyas partes
comparten un propósito común. Para diferenciarlo de un paquete normal, la pestaña de este
paquete presenta un símbolo distintivo. Sin embargo, y dependiendo de la herramienta
utilizada o del gusto del diseñador, es posible representar un paquete que modela un
subsistema de la siguiente forma:

<<subsystem>>
Inventario

Figura 3. Representación alternativa de un paquete de tipo subsistema

Esta representación es completamente igual en términos de significado, a la presentada
inicialmente. Lo importante aquí es comprender que un paquete con el estereotipo
<<subsystem>> contiene elementos que trabajan de acuerdo al cumplimiento de un conjunto
común de objetivos dentro de la solución de software. Como consideración adicional, los
elementos dentro de un paquete solamente son visibles para otros elementos dentro del
mismo. Para que un paquete pueda interactuar con el resto del sistema, es necesario que
exista al menos una clase con una interfaz pública.
En tercer lugar, un paquete puede tomar el estereotipo <<model>>. Este estereotipo es similar
a <<subsystem>>, un paquete de este estilo contiene un conjunto de elementos similares
dentro del sistema. Sin embargo, un paquete así estará enfocado a ofrecer información
acerca de un tópico o tipo de comportamiento específico dentro del sistema. En general,
este tipo de paquetes y la información que ofrecen son utilizados dentro de los subsistemas
definidos en otros paquetes. La representación de un paquete de este estilo es:

En alianza con

 
Colombia
 

Tasas de cambio

Figura 4. Paquete con estereotipo <<Model>>

Nótese el triángulo que lo identifica como un paquete con el estereotipo <<model>>. No
obstante, y de manera similar a lo que sucede con el estereotipo <<subsystem>>, es posible
representar el paquete de otra forma, así:

<<model>>
Tasas de cambio

Figura 5. representación alternativa de un paquete con estereotipo <<model>>

Los paquetes por sí solos resultan útiles en términos de organización, pero requieren de otros
elementos para poder ser utilizados en todo su potencial. Estos elementos toman la forma de
relaciones de dependencia entre paquetes. La situación más usual en que se presenta una
relación de dependencia entre paquetes es cuando estos son del tipo <<subsystem>>, pues
en este caso la relación indica que al menos una de las clases de un paquete necesita
comunicarse con al menos una de las clases del otro, todo con el fin de cumplir sus objetivos.
Un ejemplo de este tipo de relación se presenta a continuación:

Inventario Compras

Figura 6. RElación de dependencia entre dos paquetes

En este caso, la relación de dependencia indica que el paquete Inventario depende para
su funcionamiento del paquete Compras. En términos prácticos y como se mencionó con
anterioridad, esto quiere decir que al menos una de las clases del paquete Inventario
requiere comunicarse e interactuar con al menos una de las clases del paquete Compras,
para su correcto funcionamiento. Una relación de dependencia puede ser bidireccional,
indicando que la necesidad existe en ambos paquetes y en ambos sentidos. La
representación de este tipo de relación es:

En alianza con

 
Colombia
 

Inventario Compras

Figura 7. dependencia bidireccional entre paquetes

Ahora bien, para tener más información acerca del tipo de relación de dependencia entre
los paquetes, es posible asignar un estereotipo a la relación. El UML ofrece un conjunto de
estereotipos de dependencia. Sin embargo, dos de los más utilizados e importantes son
<<import>> y <<access>>. En la siguiente figura, por ejemplo:

<<import>>
Inventario Compras

Figura 8. Relacón de dependencia con estereotipo <<import>>

El uso del estereotipo <<import>> implica que el paquete Inventario añade el paquete
Compras en tiempo de ejecución, con el fin de poder utilizar referencias a sus clases y
métodos. Este comportamiento es similar al modelado por el uso de la sentencia import en el
lenguaje de programación Java.
Cuando se utiliza el estereotipo <<access>>, como en la figura siguiente:

<<access>>
Compras Facturacion

Figura 9. Relación de dependencia con el estereotipo <<access>

La situación que se quiere representar es una en la que, en tiempo de ejecución, a pesar de
que el paquete Compras no agregó el paquete Facturación (lo que sí hubiera sucedido si se
hubiera utilizado <<import>>) alguna(s) de las clases de Compras hará invocaciones a la
interfaz pública, ofrecida por el paquete Facturación.
A pesar de que la notación requiera un poco más de atención, que la de los diagramas
vistos hasta el momento, el potencial de un diagrama de paquetes en términos de organizar
los artefactos y componentes de un proyecto de software es altísimo. Bien utilizados, los
diagramas de paquetes ofrecen herramientas para mantener bajo control lo que de otra
manera puede ser un cúmulo enorme de diagramas, clases y componentes.

DIAGRAMA DE ESTRUCTURA COMPUESTA

En ocasiones, los diagramas de los que se dispone, como por ejemplo los diagramas de
clases, no son perfectos para mostrar ciertas características de un sistema de software. Es en

En alianza con

 
Colombia
 

estos casos es cuando es conveniente disponer de otros diagramas que estén más
orientados a representar lo que se necesita. En el caso particular de los diagramas de
estructura compuesta, son diagramas que resultan idóneos para representar las interacciones
y colaboraciones de un conjunto de clases en aras de alcanzar los objetivos planteados por
la solución de software. En general, los diagramas de estructura compuesta pueden ser
utilizados para representar las interacciones que se dan entre las partes internas de una clase
(instancias de otras clases usualmente), para cumplir con las metas planteadas para la misma.

DIAGRAMAS DE ESTRUCTURA COMPUESTA PARA MOSTRAR LA COMPOSICIÓN INTERNA DE UNA CLASE

Hay ocasiones en que los diagramas de clases pueden ofrecer información que, a pesar de
ser formalmente correcta, puede derivar en problemas cuando se implementa y luego se
ejecuta la solución de software correspondiente. Por ejemplo, si se toma en consideración el
siguiente caso:

Curso

1
1

1..*
1

Monitor Estudiante

Figura 10. Diagrama de clases inicial

El diagrama de clases presentado en la figura representa una situación en la cual la clase
Curso tiene una relación de composición con la clase Monitor (un curso tiene un solo monitor
que pertenece, de manera exclusiva, al curso en cuestión), al mismo tiempo que tiene una
relación de agregación con la clase Estudiante (los estudiantes pertenecen al curso, pero no
de manera exclusiva). Podría considerarse que el diagrama está completo y sin embargo, es
necesario tener otras circunstancias en consideración. El monitor debería conocer a los
estudiantes del curso con el fin de ofrecerles sus servicios pero el diagrama no soporta esta
relación, en su estado actual.
La solución en este punto podría parecer relativamente sencilla. Es posible establecer una
relación entre la clase Monitor y la clase Estudiante, de la siguiente forma:

En alianza con

 
Colombia
 

Curso

1
1

1..*
1

Monitor Estudiante

1 1..*

Figura 11. Diagrama de clases corregido

De esta manera, la clase Monitor tiene conocimiento de la clase Estudiante y podría así,
reconocer a los estudiantes a quienes debe prestar ayuda. Sin embargo, y a pesar de que
en papel la solución es clara en tiempo de ejecución no resulta tan evidente que funcione
de manera adecuada. El por qué es muy simple: a pesar de que la clase Monitor conoce a
la clase Estudiante, en tiempo de ejecución, un objeto de tipo Monitor simplemente conoce
un conjunto de objetos de tipo Estudiante. Sin embargo, esto no garantiza que sean sus
estudiantes. Tal como está planteada la estructura de clases, perfectamente podrían ser
estudiantes de otros cursos, sin ninguna relación con él. No hay forma de que un diagrama de
clases ofrezca información y garantías en una situación de este estilo. Sencillamente no es su
propósito. Es aquí donde entran los diagramas de estructura compuesta.
Ahora bien, es posible argumentar que si la persona que hizo el diagrama es la misma que
escribe el código, sería sencillo garantizar que se respete la integridad de las relaciones. O
que podrían elaborarse otros diagramas (de secuencia o actividad por ejemplo) para
garantizar que el proceso de asociación de monitores y estudiantes sea adecuado. Sin
embargo, y a pesar de que esto sea cierto, los diagramas de estructura compuesta ofrecen
una alternativa más simple y directa para documentar este tipo de situaciones. Veamos: la
estructura del diagrama de clases presentado en la Figura 11 puede ser representada desde
el punto de vista de la clase Curso, de la siguiente forma, a través de un diagrama de
estructura compuesta:

Curso

monitorCurso: Monitor[1] estCurso: Estudiante[1..*]

Figura 12. Diagrama de estructura copuesta reflejando el diagrama de clases

Cuando se representa la estructura interna de una clase utilizando un diagrama de estructura

compuesta lo que se representa son sus partes. Cada parte, en este caso, representa una
asociación con una clase del diagrama y se denota con la estructura nombre:
tipo[multiplicidad]. En este ejemplo, la clase Curso tiene dos partes que la construyen: un

En alianza con

 
Colombia
 

monitorCurso, de tipo Monitor¸y una colección de al menos un objeto de tipo Estudiante,

llamada estCurso.
Ahora bien, si se quiere denotar que las partes de la clase Curso pueden comunicarse en
tiempo de ejecución, es posible establecer un conector entre ellas de la siguiente manera:

Curso

monitorCurso: Monitor[1] estCurso: Estudiante[1..*]

1 1..*

Figura 13. Diagrama de estructura compuesta, con un conector entre las partes
En este contexto, un conector entre las dos partes indica que en tiempo de ejecución se
establece un vínculo entre los objetos, de manera que puedan comunicarse. Este vínculo
puede tomar la forma del paso de una de las partes como parámetro o una solución similar
que exista de nuevo, solamente, en tiempo de ejecución. La multiplicidad en los extremos del
conector indica la información usual en términos de cuántas instancias son manejadas en la
relación. De esta manera, es posible asegurar que la relación, en la forma en que se necesita
exista.

En alianza con

 
Colombia