27. Representación con diagramas de clases conceptuales de UML

27.1 Introducción

Los diagramas de clases conceptuales de UML son una de las formas más usadas para representar modelos de dominio. Permiten mostrar conceptos importantes, atributos relevantes, asociaciones, roles, multiplicidades y algunas restricciones del negocio.

La palabra "conceptual" es clave. En este contexto, una clase no representa necesariamente una clase de programación. Representa un concepto del dominio, como Paciente, Turno, Agenda, Profesional o Especialidad. El objetivo es comprender el negocio, no diseñar todavía la estructura exacta del código.

27.2 Imagen conceptual del diagrama

27.3 Para qué sirve un diagrama conceptual

Un diagrama conceptual sirve para visualizar la estructura del dominio. Muestra qué conceptos existen y cómo se relacionan. Ayuda a validar vocabulario, encontrar ambigüedades, discutir multiplicidades y detectar reglas que todavía no están claras.

También facilita la conversación con expertos del negocio, siempre que el diagrama se mantenga simple y use nombres comprensibles. Si el diagrama se llena de detalles técnicos, pierde su valor como herramienta de análisis.

27.4 Clases conceptuales

Una clase conceptual representa un concepto relevante del dominio. Puede ser una entidad, un objeto de valor, una relación con información propia, un catálogo o una estructura importante para el negocio.

Por ejemplo, en un sistema de turnos pueden aparecer Paciente, Profesional, Especialidad, Agenda, Franja horaria, Turno, Reserva y Cancelación. Cada uno debe estar en el diagrama solo si aporta significado al análisis.

27.5 Atributos en clases conceptuales

Los atributos representan datos relevantes del dominio. No es necesario incluir todos los campos posibles. Conviene mostrar solo aquellos que ayudan a comprender reglas, identidad, estados o diferencias importantes.

Por ejemplo, en Turno puede ser útil mostrar fecha, estado o duración. En Paciente puede ser útil mostrar documento o historia clínica. Pero no hace falta incluir detalles de interfaz, campos técnicos, marcas internas o información irrelevante para el objetivo del diagrama.

27.6 Asociaciones

Las asociaciones muestran vínculos entre conceptos. Deben poder leerse como frases del dominio: Paciente reserva Turno, Profesional posee Agenda, Agenda contiene Franja horaria, Profesional atiende Especialidad.

Nombrar asociaciones ayuda a evitar líneas ambiguas. Si no sabemos qué significa una relación, probablemente necesitamos conversar más con expertos del dominio.

27.7 Multiplicidades

Las multiplicidades indican cuántas instancias pueden participar en una asociación. Por ejemplo, un Paciente puede tener 0..* Turnos, mientras que un Turno reservado puede tener 1 Paciente. Una Agenda puede contener 1..* Franjas horarias si está publicada.

Las multiplicidades deben expresar reglas reales, no suposiciones del modelador. Cuando no se conocen, conviene marcar la duda y validarla.

27.8 Roles y dirección de lectura

Los roles aclaran qué papel cumple un concepto dentro de una asociación. La dirección de lectura ayuda a interpretar el nombre de la relación. Por ejemplo, Paciente reserva Turno se lee desde Paciente hacia Turno.

Esto no significa que en el código una clase deba tener referencia directa a la otra. En análisis conceptual, la dirección de lectura es una ayuda para comunicar significado.

27.9 Generalización

UML permite representar generalización y especialización. Puede ser útil cuando un concepto general y sus variantes tienen significado claro en el dominio. Por ejemplo, Persona podría generalizar Paciente y Profesional si el negocio reconoce esa abstracción.

No conviene usar herencia conceptual solo para evitar repetir atributos. Debe representar una diferencia real y validada del dominio.

27.10 Agregación y composición

UML también permite representar relaciones todo-parte con agregación y composición. En diagramas conceptuales deben usarse con criterio, explicando qué significa la pertenencia en el negocio.

Por ejemplo, Pedido puede estar compuesto por Ítems de pedido. Agenda puede contener Franjas horarias si estas no tienen sentido fuera de esa agenda. Pero no debemos usar composición solo porque algo aparece visualmente dentro de otra cosa.

27.11 Notas y restricciones

Algunas reglas no se expresan cómodamente con clases y asociaciones. UML permite agregar notas o restricciones textuales. Por ejemplo: "Las franjas de una misma agenda no pueden superponerse" o "Un turno atendido no puede cancelarse".

Estas notas son muy útiles porque evitan que el diagrama oculte reglas importantes. No todo debe convertirse en símbolo.

27.12 Ejemplo textual: sistema de turnos

Un diagrama conceptual inicial podría incluir:

• Paciente reserva Turno.
• Turno pertenece a Agenda.
• Agenda contiene Franja horaria.
• Profesional posee Agenda.
• Profesional atiende Especialidad.
• Turno puede tener Cancelación.

Luego se agregan multiplicidades y reglas según lo que se valide con expertos.

27.13 Qué evitar en un diagrama conceptual

En un diagrama conceptual conviene evitar:

• Clases técnicas como ControladorTurno, TurnoDTO o TablaTurnos.
• Métodos de programación que no aportan al análisis del dominio.
• Campos de base de datos sin significado para el negocio.
• Detalles de interfaz como botones, formularios o pantallas.
• Exceso de atributos que dificulta leer el modelo.
• Relaciones sin nombre ni significado claro.

27.14 Diferencia con diagrama de clases de diseño

Un diagrama conceptual representa el dominio. Un diagrama de diseño representa decisiones técnicas del software. En diseño pueden aparecer clases de servicio, repositorios, controladores, interfaces, patrones de implementación y métodos concretos.

Ambos diagramas pueden usar notación UML, pero tienen objetivos distintos. Mezclarlos demasiado pronto produce confusión.

27.15 Tabla de elementos

La siguiente tabla resume elementos habituales:

27.16 Preguntas para revisar el diagrama

Estas preguntas ayudan a revisar un diagrama conceptual:

• ¿Los nombres pertenecen al lenguaje ubicuo?
• ¿Cada clase representa un concepto del dominio?
• ¿Las asociaciones se pueden leer como frases claras?
• ¿Las multiplicidades expresan reglas validadas?
• ¿Faltan reglas importantes como notas o restricciones?
• ¿Hay elementos técnicos que deberían eliminarse?
• ¿El diagrama es comprensible para expertos del negocio?

27.17 Errores frecuentes

Al representar modelos con diagramas conceptuales, suelen aparecer estos errores:

• Confundir clases conceptuales con clases de programación.
• Incluir detalles de base de datos o interfaz.
• Agregar todos los atributos posibles sin criterio.
• Usar asociaciones sin nombre ni multiplicidad.
• Representar herencias innecesarias.
• Olvidar reglas que no caben en la estructura visual.
• Hacer diagramas demasiado grandes para ser discutidos.

27.18 Qué debes recordar de este tema

• Un diagrama de clases conceptual representa conceptos del dominio, no clases técnicas.
• Debe mostrar conceptos, atributos relevantes, asociaciones y multiplicidades.
• Las notas ayudan a expresar reglas que no se ven en las líneas del diagrama.
• La notación UML debe servir a la comunicación, no complicarla.
• Los nombres deben seguir el lenguaje ubicuo.
• No conviene mezclar análisis conceptual con diseño de implementación.
• Un buen diagrama conceptual debe ser claro, validable y enfocado.

27.19 Conclusión

Los diagramas de clases conceptuales de UML son una herramienta valiosa para representar modelos de dominio. Permiten visualizar conceptos, relaciones y restricciones, siempre que se mantenga claro el objetivo: comprender el negocio y validar significados.

En el próximo tema veremos cómo complementar esta representación con diagramas de estados, actividades y objetos.