9. Multiplicidad, navegabilidad, roles y restricciones en diagramas de clases

9.1 Introducción

En un diagrama de clases, no alcanza con dibujar una relación entre dos clases. Muchas veces es necesario precisar cuántos objetos pueden participar, desde qué lado se necesita acceder, qué papel cumple cada extremo y qué condiciones deben respetarse. Para eso UML ofrece multiplicidad, navegabilidad, roles y restricciones.

Estos recursos hacen que el modelo sea más exacto. Una asociación entre Cliente y Pedido no dice por sí sola si un cliente puede tener cero, uno o muchos pedidos. Tampoco indica si desde Pedido se necesita conocer al Cliente, si desde Cliente se navega hacia sus pedidos o qué regla limita esa relación.

9.2 Por qué conviene precisar las asociaciones

Las asociaciones demasiado generales pueden generar interpretaciones distintas. Una persona puede entender que cada pedido pertenece obligatoriamente a un cliente; otra puede pensar que existen pedidos anónimos. Una persona puede asumir que un pedido tiene muchas líneas; otra puede no notar esa restricción.

La multiplicidad, la navegabilidad, los roles y las restricciones reducen estas ambigüedades. Permiten que el diagrama exprese reglas importantes sin necesidad de escribir largas explicaciones en cada caso.

9.3 Detalles de una asociación UML

Una asociación puede enriquecerse con multiplicidades en sus extremos, flechas de navegabilidad, nombres de rol y restricciones. La multiplicidad responde cuántos objetos pueden participar. La navegabilidad indica desde qué lado se puede acceder. El rol aclara qué papel cumple cada extremo. La restricción expresa una condición que debe cumplirse.

9.4 Multiplicidad

La multiplicidad indica cuántas instancias de una clase pueden relacionarse con una instancia de otra clase. Se escribe cerca de los extremos de una asociación. Es uno de los recursos más importantes para expresar reglas estructurales.

Por ejemplo, si un Cliente puede tener muchos Pedidos, en el extremo de Pedido puede aparecer 0..*. Si cada Pedido debe pertenecer a un Cliente, en el extremo de Cliente puede aparecer 1.

9.5 Valores frecuentes de multiplicidad

9.6 Cómo leer la multiplicidad

Una dificultad frecuente es leer la multiplicidad desde el extremo correcto. La multiplicidad ubicada cerca de una clase indica cuántas instancias de esa clase pueden relacionarse con una instancia de la clase opuesta.

Si entre Cliente y Pedido aparece 1 junto a Cliente y 0..* junto a Pedido, se interpreta así: cada Pedido pertenece a un Cliente, y cada Cliente puede tener cero o muchos Pedidos.

9.7 Multiplicidad y reglas del negocio

La multiplicidad no es solo una decisión gráfica. Muchas veces representa reglas del negocio. Si un Pedido debe tener al menos una LíneaDePedido, eso afecta validaciones, interfaz, pruebas y persistencia. Si un Usuario puede no tener foto de perfil, el sistema debe soportar esa ausencia.

Por eso, antes de colocar multiplicidades, conviene comprender qué reglas reales existen. No se trata de adivinar cantidades, sino de expresar restricciones relevantes del dominio o del diseño.

9.8 Navegabilidad

La navegabilidad indica si desde una clase se puede acceder a otra a través de una asociación. Se representa con una flecha en el extremo hacia el que se navega. En modelos conceptuales muchas veces se omite. En modelos de diseño puede ser importante.

Por ejemplo, si Pedido necesita conocer a Cliente para obtener sus datos, puede existir navegabilidad desde Pedido hacia Cliente. Si Cliente no necesita conservar una colección de pedidos, no hace falta indicar navegabilidad en sentido contrario.

9.9 Navegabilidad no es flujo de ejecución

Un error frecuente es confundir navegabilidad con dirección de proceso. Una flecha de navegabilidad no indica que una operación empieza en una clase y termina en otra. Solo indica posibilidad de acceso estructural.

Si se necesita mostrar el orden de mensajes durante un escenario, corresponde usar un diagrama de secuencia. El diagrama de clases muestra estructura, no ejecución temporal.

9.10 Roles en una asociación

El nombre de rol describe el papel que cumple una clase en el extremo de una asociación. Es útil cuando el nombre de la clase no alcanza para entender su función en ese vínculo.

Por ejemplo, una clase Usuario puede estar relacionada con Documento en dos roles diferentes: autor y revisor. Sin nombres de rol, la relación puede quedar ambigua. Con roles, se entiende mejor qué papel cumple cada objeto en el contexto de la asociación.

9.11 Nombre de asociación

Además de roles en los extremos, una asociación puede tener un nombre. El nombre explica la relación entre las clases. Por ejemplo, Cliente realiza Pedido, Profesional atiende Turno o Usuario crea Solicitud.

No siempre es necesario nombrar la asociación. Si las clases, roles y multiplicidades ya comunican la idea con claridad, se puede omitir. Si hay riesgo de ambigüedad, el nombre puede ayudar.

9.12 Restricciones

Una restricción expresa una condición que debe cumplirse y que no queda completamente representada por la multiplicidad o la relación. En UML suele escribirse entre llaves o en una nota asociada al elemento correspondiente.

Por ejemplo, una restricción puede indicar {fechaFin > fechaInicio}, {un turno no puede cancelarse después de ser atendido} o {el importe total debe ser mayor que cero}.

9.13 Restricciones simples y comprensibles

Las restricciones deben ser breves y claras. Si la regla es compleja, puede convenir documentarla en texto aparte y dejar en el diagrama solo una referencia. Un diagrama lleno de restricciones largas pierde legibilidad.

La restricción debe aportar información que el diagrama no comunica por sí solo. Si repite algo evidente, no agrega valor.

9.14 Asociación calificada

Una asociación calificada permite indicar que una relación se accede mediante una clave o calificador. Por ejemplo, una Agenda puede acceder a Turnos mediante una fecha y hora. El calificador ayuda a expresar cómo se identifica un elemento dentro de una colección relacionada.

No es uno de los recursos más usados al comenzar, pero puede ser útil cuando una asociación depende de una clave clara.

9.15 Asociación reflexiva

Una asociación reflexiva ocurre cuando una clase se relaciona consigo misma. Por ejemplo, un Empleado puede supervisar a otros Empleados, o una Categoría puede contener subcategorías.

En estos casos, los nombres de rol son especialmente importantes. Sin roles como supervisor y subordinado, o categoríaPadre y subcategoría, la relación puede resultar confusa.

9.16 Ejemplo: pedidos y líneas de pedido

Supongamos un sistema de ventas. Un Cliente puede realizar cero o muchos Pedidos. Cada Pedido pertenece a exactamente un Cliente. Además, cada Pedido está compuesto por una o más LíneasDePedido. Cada LíneaDePedido pertenece a un único Pedido y se refiere a un Producto.

Este pequeño conjunto de relaciones ya expresa reglas importantes: no existe una línea de pedido sin pedido, un pedido no puede estar vacío y cada pedido tiene un cliente asociado.

9.17 Criterios de revisión

• ¿Las multiplicidades expresan reglas reales del modelo?
• ¿Se leen correctamente desde el extremo opuesto?
• ¿La navegabilidad es necesaria para el nivel del diagrama?
• ¿Los roles aclaran relaciones ambiguas?
• ¿Las restricciones son breves y comprensibles?
• ¿El diagrama evita confundir estructura con flujo de ejecución?
• ¿Las reglas importantes quedan visibles sin saturar el modelo?

9.18 Errores frecuentes

• Colocar multiplicidades sin validar las reglas del negocio.
• Leer la multiplicidad desde el extremo incorrecto.
• Usar flechas de navegabilidad como si fueran dirección de proceso.
• Omitir roles cuando una clase participa más de una vez o con significados distintos.
• Agregar restricciones largas que hacen difícil leer el diagrama.
• Usar siempre 0..* por comodidad, aunque la regla sea más precisa.
• Mostrar detalles de diseño cuando el diagrama solo pretende ser conceptual.

9.19 Qué debes recordar de este tema

• La multiplicidad indica cuántas instancias pueden participar en una relación.
• La navegabilidad indica posibilidad de acceso, no orden de ejecución.
• Los roles aclaran el papel de cada extremo de una asociación.
• Las restricciones expresan condiciones que deben cumplirse.
• Estos recursos ayudan a que las asociaciones sean menos ambiguas.
• El nivel de detalle debe ser coherente con el propósito del diagrama.

9.20 Conclusión

Multiplicidad, navegabilidad, roles y restricciones permiten enriquecer las asociaciones en diagramas de clases. Usados correctamente, convierten una relación genérica en una representación precisa de reglas estructurales importantes.

En el próximo tema veremos diagramas de objetos, que permiten representar instancias concretas y ejemplos específicos del modelo.