5. Elementos comunes de UML: nombres, relaciones, notas, estereotipos y paquetes

5.1 Introducción

Los diagramas UML tienen símbolos específicos según el tipo de diagrama, pero también comparten elementos generales. Nombres, relaciones, notas, estereotipos y paquetes aparecen en muchos diagramas y ayudan a que el modelo sea más claro, preciso y organizado.

Comprender estos elementos comunes evita que cada diagrama parezca un lenguaje nuevo. Aunque un diagrama de clases, un diagrama de componentes y un diagrama de casos de uso representen cosas distintas, todos necesitan nombrar elementos, conectar conceptos, aclarar restricciones y organizar información.

5.2 Nombres en UML

Todo elemento importante de un diagrama debe tener un nombre claro. El nombre permite reconocer qué representa el elemento y cuál es su función dentro del modelo. Un nombre ambiguo dificulta la lectura y puede provocar interpretaciones diferentes entre las personas que revisan el diagrama.

Los nombres deben ser significativos, consistentes y adecuados al nivel de abstracción. En un diagrama conceptual conviene usar nombres del dominio, como Cliente, Turno, Pedido o Factura. En un diagrama de diseño pueden aparecer nombres más técnicos, como ServicioDePagos, RepositorioDeTurnos o ControladorDeUsuarios.

5.3 Elementos comunes en diagramas UML

En muchos diagramas UML se combinan elementos con nombre, relaciones que los conectan, notas que aclaran restricciones, estereotipos que especializan significados y paquetes que agrupan partes del modelo. Estos recursos permiten construir diagramas más expresivos sin perder organización.

5.4 Relaciones entre elementos

Las relaciones muestran cómo se conectan los elementos de un modelo. Según el tipo de diagrama, una relación puede representar comunicación, dependencia, herencia, composición, asociación, flujo, transición o despliegue.

Una línea en UML no debe agregarse solo porque dos elementos parecen relacionados de alguna manera. La relación debe tener un significado concreto. Por ejemplo, en un diagrama de clases, una asociación entre Cliente y Pedido indica que existe un vínculo estructural entre esos conceptos. En un diagrama de componentes, una dependencia puede indicar que un componente necesita servicios de otro.

5.5 Asociación

La asociación es una relación estructural entre elementos. Se usa especialmente en diagramas de clases para indicar que una clase conoce, usa o mantiene un vínculo con otra. Puede incluir nombres de roles, multiplicidades y navegabilidad.

Por ejemplo, un Cliente puede estar asociado con muchos Pedidos. Esa relación indica que, dentro del modelo, tiene sentido vincular esos conceptos. Más adelante, en los temas de diagramas de clases, veremos cómo representar multiplicidades y otros detalles con precisión.

5.6 Dependencia

La dependencia indica que un elemento necesita a otro para funcionar, compilar, ejecutar una operación o cumplir una responsabilidad. Suele representarse con una línea discontinua y una flecha hacia el elemento del cual se depende.

Es una relación más débil que una asociación estructural permanente. Por ejemplo, una clase puede depender temporalmente de un servicio para validar un pago. Un componente puede depender de una API externa para obtener información.

5.7 Generalización

La generalización representa una relación entre un elemento más general y otro más específico. Es la idea de herencia o especialización. En diagramas de clases, puede indicar que una clase hereda características de otra. En diagramas de casos de uso, puede indicar que un actor o un caso de uso es una variante especializada de otro.

Debe usarse con cuidado. No toda similitud justifica una generalización. Conviene aplicarla cuando existe una relación clara de tipo "es un". Por ejemplo, TarjetaDeCrédito y TransferenciaBancaria podrían ser formas específicas de MedioDePago si comparten una abstracción común válida.

5.8 Agregación y composición

Agregación y composición son relaciones todo-parte. La agregación representa una pertenencia débil, donde la parte puede existir independientemente del todo. La composición representa una pertenencia fuerte, donde la vida de la parte depende del todo.

Por ejemplo, una Biblioteca puede agregar Libros, porque un libro podría existir aunque cambie de biblioteca. En cambio, una Factura puede estar compuesta por DetallesDeFactura, porque esos detalles no tienen sentido independiente fuera de la factura que los contiene.

5.9 Notas

Las notas permiten agregar aclaraciones al diagrama. Se usan para explicar reglas, restricciones, supuestos, decisiones o información que no conviene representar con símbolos principales.

Una nota puede indicar, por ejemplo, que un pago solo puede cancelarse antes de ser confirmado, que una integración externa no está disponible en ciertos horarios o que una relación se simplificó para mejorar la lectura del diagrama.

Las notas no deben reemplazar un modelo mal construido. Si todo necesita aclaración, probablemente el diagrama requiere reorganización.

5.10 Restricciones

Una restricción expresa una condición que debe cumplirse. En UML puede escribirse entre llaves o dentro de una nota, según el caso. Por ejemplo, {edad >= 18} puede indicar una condición obligatoria para cierta operación o relación.

Las restricciones son útiles cuando una regla importante afecta al modelo y no se entiende solo observando los elementos conectados. Conviene redactarlas de manera breve y precisa.

5.11 Estereotipos

Un estereotipo permite especializar el significado de un elemento UML. Se escribe normalmente entre dobles signos menor y mayor, por ejemplo <<interface>>, <<service>>, <<controller>> o <<database>>.

Los estereotipos ayudan a indicar el rol de un elemento dentro del modelo. Por ejemplo, dos clases pueden tener una forma gráfica similar, pero una puede actuar como servicio y otra como repositorio. El estereotipo aclara esa intención.

5.12 Uso responsable de estereotipos

Los estereotipos no deben usarse para decorar el diagrama ni para inventar etiquetas sin significado compartido. Deben aportar información real. Si un equipo usa estereotipos propios, conviene definir qué significa cada uno.

También conviene evitar llenar el diagrama con demasiadas etiquetas. Si todos los elementos tienen varios estereotipos, la lectura se vuelve pesada. El estereotipo debe aclarar, no distraer.

5.13 Paquetes

Los paquetes agrupan elementos relacionados. Pueden contener clases, casos de uso, componentes u otros elementos del modelo. Son útiles para organizar diagramas grandes y para separar áreas funcionales o capas de una solución.

Por ejemplo, un sistema de ventas puede tener paquetes como Usuarios, Catálogo, Pedidos, Pagos y Facturación. En un diseño por capas, podrían existir paquetes como Presentación, Aplicación, Dominio e Infraestructura.

5.14 Dependencias entre paquetes

Además de agrupar elementos, los paquetes pueden relacionarse entre sí. Una dependencia entre paquetes indica que un grupo del modelo usa o necesita elementos de otro. Esto ayuda a analizar acoplamiento y organización general.

Si muchos paquetes dependen de todos los demás, el sistema puede estar demasiado acoplado. Un diagrama de paquetes permite detectar esa situación a tiempo y discutir una separación más ordenada.

5.15 Visibilidad

En algunos diagramas, especialmente en diagramas de clases, UML permite indicar visibilidad. Los símbolos más comunes son + para público, - para privado, # para protegido y ~ para visibilidad de paquete.

No siempre es necesario mostrar visibilidad. En modelos conceptuales puede ser innecesaria. En modelos de diseño puede ser útil para expresar encapsulamiento y responsabilidades.

5.16 Multiplicidad

La multiplicidad indica cuántas instancias de un elemento pueden relacionarse con otro. Por ejemplo, 1, 0..1, 0..* o 1..*. Es muy frecuente en diagramas de clases y permite expresar reglas importantes.

Por ejemplo, un Pedido puede tener uno o más DetallesDePedido, mientras que un DetalleDePedido pertenece a un solo Pedido. Esta información ayuda a evitar interpretaciones incompletas del modelo.

5.17 Cuándo usar cada recurso

5.18 Errores frecuentes

• Usar nombres demasiado genéricos, como Gestor, Proceso o Datos.
• Dibujar relaciones sin conocer su significado.
• Confundir asociación con dependencia.
• Usar composición cuando la parte puede existir independientemente del todo.
• Agregar estereotipos sin definir qué significan.
• Usar notas extensas que vuelven ilegible el diagrama.
• Crear paquetes que no representan una organización real del modelo.

5.19 Qué debes recordar de este tema

• Los nombres, relaciones, notas, estereotipos y paquetes aparecen en muchos diagramas UML.
• Un nombre claro ayuda a comprender la responsabilidad de cada elemento.
• Las relaciones deben tener un significado preciso.
• Las notas sirven para aclarar restricciones, supuestos o decisiones puntuales.
• Los estereotipos especializan el significado de un elemento.
• Los paquetes ayudan a organizar modelos grandes y analizar dependencias.
• La claridad del modelo depende de usar cada recurso con intención.

5.20 Conclusión

Los elementos comunes de UML permiten construir diagramas más expresivos y consistentes. Aunque cada tipo de diagrama tenga símbolos propios, todos necesitan nombres claros, relaciones con significado, aclaraciones cuando sean necesarias y una organización adecuada.

En el próximo tema comenzaremos a trabajar con diagramas de casos de uso como vista general del sistema dentro del conjunto de diagramas UML.