29. Validación del modelo con escenarios, ejemplos y contraejemplos

29.1 Introducción

Un modelo de dominio no es correcto solo porque esté bien dibujado o use nombres elegantes. Debe representar adecuadamente el negocio. Para comprobarlo, necesitamos validarlo con escenarios, ejemplos y contraejemplos.

La validación consiste en probar el modelo contra situaciones concretas. Si el modelo explica correctamente los casos normales, los casos límite y las excepciones importantes, aumenta nuestra confianza. Si falla, el modelo debe corregirse antes de usarlo como base para diseño, pruebas o documentación.

29.2 Imagen conceptual de validación

29.3 Por qué validar el modelo

Durante el análisis es normal trabajar con información incompleta. Los expertos pueden omitir reglas porque les parecen obvias. Los documentos pueden estar desactualizados. Los casos de uso pueden no cubrir excepciones. Los diagramas pueden ocultar ambigüedades.

Validar el modelo permite detectar esos problemas. Un escenario concreto obliga a aplicar conceptos, relaciones, multiplicidades, estados y reglas. Si algo no encaja, aparece una pregunta útil.

29.4 Qué es un escenario

Un escenario describe una situación o secuencia de eventos dentro del dominio. Puede estar relacionado con un caso de uso, una regla de negocio, un proceso o una excepción.

Por ejemplo: "Un paciente reserva un turno con un profesional para el próximo lunes, luego cancela con 48 horas de anticipación y la franja vuelve a estar disponible". Este escenario permite validar conceptos como Paciente, Turno, Profesional, Franja horaria, Cancelación y Disponibilidad.

29.5 Qué es un ejemplo

Un ejemplo es una instancia concreta del modelo. Usa datos específicos para mostrar cómo se comporta el dominio. Por ejemplo, "Ana Pérez reserva un turno con el Dr. Gómez el 12 de junio a las 10:00".

Los ejemplos ayudan a revisar multiplicidades, atributos, asociaciones y estados. También hacen que el modelo sea más comprensible para personas no técnicas.

29.6 Qué es un contraejemplo

Un contraejemplo es una situación que desafía una regla o una interpretación del modelo. Sirve para probar si el modelo es demasiado amplio, demasiado rígido o ambiguo.

Por ejemplo, si el modelo dice que un paciente no puede tener dos turnos pendientes, un contraejemplo podría ser: "¿Qué ocurre si los turnos son para especialidades distintas?". Si esa situación es válida para el negocio, la regla debe ajustarse.

29.7 Validar conceptos

Los ejemplos ayudan a comprobar si los conceptos son correctos. Si un escenario menciona "sobreturno" y el modelo no tiene forma de representarlo, quizá falta un concepto o una regla. Si el modelo contiene "Reserva" pero los expertos hablan siempre de "Turno confirmado", debemos revisar el vocabulario.

Validar conceptos implica preguntar si cada término existe realmente en el negocio, si su significado es claro y si se diferencia de otros conceptos parecidos.

29.8 Validar asociaciones y multiplicidades

Los escenarios concretos permiten revisar relaciones. Si decimos que un Profesional tiene una Agenda, debemos probar casos: ¿qué ocurre si atiende en dos sedes?, ¿puede tener agenda por especialidad?, ¿existen agendas históricas?, ¿una agenda puede existir sin profesional?

Los contraejemplos son especialmente útiles para multiplicidades. Si encontramos un caso válido que contradice 1, 0..1 o 1..*, la multiplicidad debe revisarse.

29.9 Validar reglas de negocio

Una regla debe probarse con casos donde se cumple, casos donde falla y casos límite. Por ejemplo, si la regla dice que una cancelación debe realizarse con 24 horas de anticipación, debemos preguntar: ¿qué ocurre exactamente a las 24 horas?, ¿se cuentan días hábiles?, ¿qué pasa con feriados?, ¿qué zona horaria se usa?

Estas preguntas evitan reglas vagas que luego generan errores en la implementación.

29.10 Validar estados y transiciones

Los escenarios ayudan a comprobar si los estados y transiciones son correctos. Por ejemplo, un turno confirmado puede pasar a atendido, cancelado o ausente. Pero ¿puede volver a reservado?, ¿puede reprogramarse?, ¿qué ocurre si el profesional cancela?, ¿qué pasa si el paciente llega tarde?

Cada respuesta puede agregar una transición, una regla o un evento de dominio.

29.11 Validar agregados e invariantes

Los agregados deben validarse con operaciones que intenten romper sus invariantes. Si Agenda debe evitar franjas superpuestas, debemos probar agregar una franja que se cruza con otra. Si Pedido no puede confirmarse vacío, debemos probar ese caso.

Los contraejemplos muestran si el agregado protege correctamente sus reglas o si el límite de consistencia está mal definido.

29.12 Escenarios normales, alternativos y excepcionales

Para validar bien, no alcanza con escenarios felices. Conviene revisar:

• Escenarios normales: el proceso ocurre como se espera.
• Escenarios alternativos: hay decisiones o caminos válidos distintos.
• Escenarios excepcionales: algo impide continuar o exige una regla especial.
• Casos límite: situaciones en el borde de una regla.
• Contraejemplos: situaciones que ponen en duda una afirmación del modelo.

29.13 Tabla de validación

Una tabla simple puede ayudar a organizar la validación:

29.14 Validación con expertos

La validación debe involucrar expertos del dominio. El equipo técnico puede detectar inconsistencias formales, pero los expertos son quienes saben si el modelo representa correctamente el negocio.

Una buena práctica es revisar escenarios con lenguaje simple, sin obligar a los expertos a interpretar detalles técnicos. Los diagramas, tablas y ejemplos deben servir para conversar, no para impresionar.

29.15 De la validación a las pruebas

Los escenarios, ejemplos y contraejemplos pueden convertirse en casos de prueba. Una regla bien validada puede transformarse luego en pruebas automatizadas o casos de aceptación.

Por ejemplo: "Dado un turno confirmado, cuando se intenta cancelarlo después de haber sido atendido, entonces la cancelación debe rechazarse". Esta formulación conecta modelo de dominio, regla y verificación.

29.16 Preguntas para validar el modelo

Estas preguntas ayudan a organizar una sesión de validación:

• ¿Este escenario ocurre en la realidad?
• ¿El modelo puede representarlo sin contradicciones?
• ¿Qué conceptos participan?
• ¿Qué reglas se aplican?
• ¿Qué estados cambian?
• ¿Qué eventos ocurren?
• ¿Existe algún caso válido que contradiga el modelo?

29.17 Errores frecuentes

Al validar modelos, suelen aparecer estos errores:

• Validar solo el caso normal y olvidar excepciones.
• No usar datos concretos.
• No involucrar expertos del dominio.
• Ignorar contraejemplos porque complican el modelo.
• No actualizar el modelo después de descubrir una regla nueva.
• Confundir validación del modelo con pruebas técnicas de software.
• Usar diagramas demasiado abstractos para discutir situaciones reales.

29.18 Qué debes recordar de este tema

• Un modelo de dominio debe validarse con situaciones concretas.
• Los escenarios muestran secuencias del negocio.
• Los ejemplos usan datos concretos para probar el modelo.
• Los contraejemplos desafían reglas y supuestos.
• La validación ayuda a revisar conceptos, asociaciones, estados, reglas e invariantes.
• Los expertos del dominio son indispensables para validar significado.
• Muchos escenarios validados pueden convertirse luego en pruebas.

29.19 Conclusión

Validar el modelo con escenarios, ejemplos y contraejemplos es una práctica esencial. Permite descubrir reglas ocultas, corregir multiplicidades, ajustar estados y mejorar el vocabulario. Un modelo que resiste casos concretos es mucho más útil que un diagrama que solo parece correcto en abstracto.

En el próximo tema veremos cómo mantener trazabilidad entre modelo de dominio, requerimientos y casos de uso.