UMLDiagramas de estructura

Diagramas de paquetes UML

Cómo se agrupa un modelo o una base de código y - la parte que importa - qué grupo puede depender de cuál. El diagrama que convierte una regla de arquitectura en algo comprobable en vez de en una aspiración.

27 de julio de 20266 min de lecturaUML 2.5.124 de 35

La respuesta corta

Las flechas ausentes significan tanto como las dibujadas. Cualquier dependencia del código sin flecha en el diagrama es una violación que puedes nombrar.
Import trae los miembros públicos al espacio de nombres del importador y los reexporta; access los hace utilizables y detiene ahí la dependencia.
Package merge copia el contenido del paquete fusionado en el que fusiona. Muy usado dentro de la especificación de UML, rara vez en modelos corrientes.
Un diagrama de paquetes va de la estructura del código fuente; uno de componentes, de las partes desplegables. No son dos vistas de lo mismo.

Un diagrama de paquetes UML de una arquitectura por capas. El paquete ui y el paquete infrastructure dependen ambos del paquete domain. Los tres - ui, domain e infrastructure - dependen de un paquete shared situado debajo. — Una arquitectura por capas como grafo de dependencias. Cada flecha apunta a algo más estable que su origen, y nada apunta de vuelta hacia arriba.

01Qué muestra#

Un diagrama de paquetes es el índice de un modelo, más una regla sobre quién puede referenciar a quién. La forma de carpeta con pestaña es un espacio de nombres: un grupo de clases, casos de uso, componentes u otros paquetes.

La agrupación por sí sola es moderadamente útil. El valor está en las flechas. Una dependencia de ui a domain dice que la capa de interfaz puede referenciar tipos del dominio. La ausencia de flecha en sentido contrario dice que el dominio no debe saber que la interfaz existe, y esa es una regla de arquitectura que puedes probar, analizar y hacer que tumbe una construcción.

02La notación#

Elemento	Notación	Qué significa
Paquete	carpeta con pestaña	Un espacio de nombres. Su nombre va en la pestaña cuando el cuerpo lleva contenido, y en el cuerpo cuando no.
Dependencia		El origen referencia algo del destino. El caso general, y suele bastar.
«import»		Los miembros públicos del destino se vuelven visibles en el origen y se reexportan desde él.
«access»		Visibles en el origen pero no reexportados. La más estrecha, y normalmente la más exacta, de las dos.
«merge»		El contenido del destino se combina dentro del origen. Raro fuera de los metamodelos; lo leerás más veces de las que lo escribas.
Anidamiento	paquete dentro de un paquete	Contención, escrita `outer::inner`. También se puede dibujar como una línea con una cruz en un círculo del lado del padre.

En la práctica, la flecha de dependencia simple sostiene casi todos los diagramas de paquetes, y la distinción entre «import» y «access» solo se gana su sitio cuando modelas un lenguaje o un framework cuyo sistema de módulos hace real esa diferencia.

03Leer la dirección#

Todo lo interesante de un diagrama de paquetes está en la dirección de las flechas, y hay dos cosas que buscar.

Ciclos. Si puedes empezar en un paquete, seguir flechas y volver al punto de partida, esos paquetes no se pueden construir, probar, entender ni desplegar de forma independiente. Son un solo paquete fingiendo ser varios. Un diagrama de paquetes hace visible un ciclo en unos dos segundos, que es la forma más rápida de encontrar uno si no tienes una herramienta.

Estabilidad. Las dependencias deberían apuntar a cosas que cambian menos a menudo. En el diagrama de arriba, ui e infrastructure apuntan ambos a domain, y los tres apuntan a shared. Esa es la forma de una arquitectura por capas: lo volátil depende de lo estable, nunca al revés. Una flecha de domain a ui sería lo más importante de la página.

Así es también como se detecta un paquete shared o common que se está torciendo. Uno al que apunta todo está bien, siempre que él no apunte a nada. En el momento en que adquiere una flecha saliente, todos los paquetes del sistema dependen transitivamente de ese destino.

04Cuándo dibujar uno#

Úsalo cuando

Establecer o documentar una regla de capas que deba aplicarse
Revisar una base de código en busca de ciclos de dependencia entre módulos
Darle a alguien que acaba de llegar el mapa de un repositorio antes que el detalle
Planificar cómo partir un monolito: las líneas de corte están donde las flechas son finas

Usa otra cosa cuando

Hay tres paquetes y la estructura es obvia desde el árbol de carpetas
Lo interesante son los contratos entre partes: usa un diagrama de componentes
Tendrías que redibujarlo cada vez que se mueve un fichero
La agrupación existe pero no hay ninguna regla sobre dependencias; las flechas serían ruido descriptivo

Los diagramas de paquetes funcionan bien a dos alturas y mal entre ellas: el sistema entero con cinco a nueve paquetes, o un subsistema con granularidad parecida. Un diagrama de cuarenta paquetes es un grafo de dependencias, y un grafo de dependencias lo lee mejor una herramienta que una persona.

En una línea cada uno

01Los paquetes son espacios de nombres; las flechas entre ellos son el contenido real.
02«import» reexporta, «access» no; una dependencia simple suele bastar.
03Sigue las flechas para encontrar ciclos: los paquetes en ciclo son un solo paquete.
04Las dependencias deberían apuntar a lo que menos cambia.
05A un paquete compartido puede apuntarle todo; él no debe apuntar a nada.
06Este es el diagrama UML con más probabilidades de convertirse en una comprobación automática de construcción.

05Preguntas frecuentes#

¿Qué diferencia hay entre import y access en UML?

Ambas son dependencias entre paquetes. Import trae los miembros públicos del paquete importado al espacio de nombres del importador, de modo que pueden nombrarse sin cualificar y se reexportan hacia fuera. Access los hace utilizables pero no los reexporta, así que la dependencia se detiene ahí.

¿Cómo se muestra una arquitectura en capas en UML?

Dibuja un paquete por capa y una flecha de dependencia por cada sentido permitido, todas apuntando igual. El valor está en que las flechas ausentes significan tanto como las dibujadas: cualquier dependencia del código sin flecha en el diagrama es una violación que puedes nombrar.

¿Qué significa package merge?

Merge significa que el contenido del paquete fusionado se copia conceptualmente en el que fusiona y se combina con lo que ya hay allí. Se usa mucho dentro de la propia especificación de UML y rara vez en modelos corrientes.

¿Qué diferencia hay entre un diagrama de paquetes y uno de componentes?

Un diagrama de paquetes agrupa elementos del modelo y muestra dependencias de espacios de nombres, así que trata de cómo está organizado el modelo o la base de código. Uno de componentes muestra unidades reemplazables en ejecución y las interfaces entre ellas. Uno va de la estructura del código fuente, el otro de partes desplegables.

CompartirX LinkedIn

↑ Volver arriba Todos los artículos: UML →

En esta serie

Lecturas relacionadas

Fundamentos
¿Qué es UML?
Diagramas de estructura
Diagramas de componentes
Diagramas de estructura
Diagramas de clases
Diagramas de estructura
Diagramas de despliegue
Práctica del modelado
Dibujar un diagrama de componentes
Diagramas de estructura
Diagramas de perfil

← Todos los artículos