11. Multiplicidad y opcionalidad: uno, muchos, ninguno y restricciones de cantidad

11.1 Introducción

Después de identificar conceptos y asociaciones, necesitamos expresar cuántas instancias pueden participar en cada relación. Esa información se conoce como multiplicidad. Además, debemos indicar si una relación es obligatoria u opcional, es decir, si puede existir cero, una o varias instancias relacionadas.

La multiplicidad ayuda a descubrir reglas importantes del negocio. No es lo mismo decir que un Paciente puede tener muchos Turnos que decir que debe tener exactamente uno. Tampoco es lo mismo decir que un Profesional tiene una Agenda que decir que puede tener varias agendas con vigencias distintas.

11.2 Imagen conceptual de multiplicidad

11.3 Qué es la multiplicidad

La multiplicidad indica cuántas instancias de un concepto pueden estar asociadas con una instancia de otro concepto. En UML y en modelos conceptuales se usan expresiones como 1, 0..1, 0..*, 1..* o rangos más específicos.

Por ejemplo, si decimos que una Agenda contiene muchas Franjas horarias, estamos expresando una multiplicidad. Si decimos que un Turno corresponde a una sola Franja horaria, también estamos expresando una restricción de cantidad.

11.4 Notaciones frecuentes

Las multiplicidades más comunes son:

• 1: exactamente una instancia relacionada.
• 0..1: ninguna o una instancia relacionada.
• 0..*: ninguna, una o muchas instancias relacionadas.
• 1..*: una o muchas instancias relacionadas, al menos una.
• n..m: una cantidad mínima y máxima específica.

Estas notaciones deben usarse con cuidado. Si el equipo no sabe cuál es la multiplicidad real, conviene preguntar y validar con ejemplos.

11.5 Opcionalidad

La opcionalidad indica si una relación puede no existir. Una multiplicidad que empieza en 0 expresa opcionalidad. Por ejemplo, 0..1 significa que puede no haber relación o puede haber una. 0..* significa que puede no haber ninguna o puede haber muchas.

En un sistema de turnos, un Turno puede tener 0..1 Cancelación: si nunca fue cancelado, no tiene cancelación; si fue cancelado, tiene una. En cambio, un Turno reservado probablemente debe tener exactamente un Paciente asociado.

11.6 Uno a uno

Una asociación uno a uno indica que una instancia se relaciona con exactamente una instancia del otro concepto. Por ejemplo, si el dominio establece que cada Profesional tiene una única Matrícula profesional activa y cada Matrícula pertenece a un único Profesional, se podría modelar una relación 1 a 1.

Las relaciones uno a uno deben revisarse con cuidado, porque a veces esconden un concepto que podría integrarse como atributo u objeto de valor. Otras veces son correctas porque ambos conceptos tienen identidad, reglas o ciclos de vida diferentes.

11.7 Uno a muchos

Una asociación uno a muchos indica que una instancia de un concepto puede relacionarse con varias instancias de otro. Por ejemplo, un Paciente puede tener muchos Turnos a lo largo del tiempo. Un Profesional puede tener muchas Franjas horarias disponibles en su agenda.

La pregunta importante es si la cantidad puede ser cero, una o muchas. Un Paciente recién registrado podría no tener turnos todavía. Por eso, desde Paciente hacia Turno podría ser 0..*. En cambio, cada Turno reservado puede requerir exactamente un Paciente.

11.8 Muchos a muchos

Una asociación muchos a muchos indica que muchas instancias de un concepto pueden relacionarse con muchas instancias de otro. Por ejemplo, un Profesional puede atender varias Especialidades y una Especialidad puede ser atendida por varios Profesionales.

Este tipo de relación suele requerir análisis adicional. Si la asociación tiene información propia, como fecha de habilitación, duración habitual del turno o estado de autorización, puede convenir modelar un concepto intermedio, por ejemplo Habilitación profesional o Prestación.

11.9 Cantidades mínimas y máximas

Algunas reglas del negocio establecen límites concretos. Por ejemplo, una promoción puede requerir al menos dos productos y como máximo cinco. Una agenda puede permitir como máximo cierta cantidad de sobreturnos por día. Un paciente puede tener como máximo un turno pendiente por especialidad.

Cuando existen límites de cantidad, el modelo debe registrarlos. A veces se expresan con multiplicidades, y otras veces como reglas de negocio adicionales porque dependen de condiciones, estados o períodos.

11.10 Multiplicidad no siempre es constante

En algunos dominios, la multiplicidad depende del estado o del contexto. Un Turno disponible puede no tener Paciente, pero un Turno reservado debe tener uno. Una Agenda en borrador puede no tener franjas, pero una Agenda publicada debe tener al menos una. Un Pedido creado puede no tener pago, pero un Pedido confirmado puede requerirlo.

Cuando la cantidad permitida depende del estado, la multiplicidad del diagrama puede no ser suficiente. Conviene agregar reglas textuales o diagramas de estados para aclararlo.

11.11 Multiplicidad y reglas de negocio

Muchas reglas de negocio son reglas de multiplicidad. "Un paciente no puede tener más de un turno pendiente para la misma especialidad" es una restricción de cantidad. "Cada turno reservado debe tener un paciente" también lo es. "Una factura debe tener al menos un ítem" es otra regla típica.

Estas reglas deben validarse con ejemplos. Puede haber excepciones, como turnos grupales, reservas familiares, sobreturnos o profesionales con agendas múltiples.

11.12 Ejemplos en sistema de turnos

La siguiente tabla muestra multiplicidades posibles:

11.13 Cómo descubrir multiplicidades

Para descubrir multiplicidades conviene preguntar por cantidades concretas:

• ¿Puede existir este concepto sin estar relacionado con el otro?
• ¿Debe haber exactamente uno?
• ¿Puede haber varios?
• ¿Existe un máximo permitido?
• ¿La cantidad depende del estado del objeto?
• ¿Hay excepciones o casos especiales?
• ¿La regla cambia según sede, período, tipo de usuario o política del negocio?

11.14 Validar con ejemplos y contraejemplos

Las multiplicidades se validan mejor con ejemplos. Si el modelo dice que un Profesional tiene una sola Agenda, podemos preguntar: ¿qué ocurre si atiende en dos sedes?, ¿qué pasa si cambia de horario por temporada?, ¿puede tener agenda de consultas y agenda de estudios?, ¿existen agendas históricas?

Los contraejemplos ayudan a descubrir multiplicidades incorrectas. Si encontramos un caso válido que contradice la cantidad indicada, el modelo debe ajustarse o la excepción debe documentarse como regla.

11.15 Errores frecuentes

Al modelar multiplicidad y opcionalidad, suelen aparecer estos errores:

• Usar 1 cuando en realidad la relación puede ser opcional.
• Usar muchos como respuesta genérica sin investigar límites reales.
• No diferenciar entre cantidad actual y cantidad histórica.
• Olvidar que la multiplicidad puede depender del estado.
• No registrar límites máximos importantes del negocio.
• Tratar relaciones muchos a muchos sin revisar si existe un concepto intermedio.
• No validar cantidades con ejemplos reales y excepciones.

11.16 Qué debes recordar de este tema

• La multiplicidad indica cuántas instancias pueden participar en una asociación.
• La opcionalidad indica si una relación puede no existir.
• Las notaciones comunes son 1, 0..1, 0..*, 1..* y rangos específicos.
• Muchas reglas de negocio son restricciones de cantidad.
• La multiplicidad puede depender del estado o del contexto.
• Las relaciones muchos a muchos pueden esconder conceptos intermedios.
• Las cantidades deben validarse con expertos, ejemplos y contraejemplos.

11.17 Conclusión

La multiplicidad y la opcionalidad hacen que las asociaciones del modelo de dominio sean más precisas. Permiten expresar si una relación es obligatoria, opcional, única, múltiple o limitada por reglas específicas. Sin esta información, el modelo puede parecer correcto pero dejar abiertas dudas importantes.

En el próximo tema estudiaremos agregación y composición conceptual, dos formas de analizar relaciones entre un todo y sus partes.