3. Relación entre requerimientos, casos de uso, UML y modelo de dominio
3.1 Introducción
En el desarrollo de software no alcanza con producir documentos separados. Los requerimientos, los casos de uso, los diagramas UML y el modelo de dominio deben conectarse entre sí para formar una comprensión coherente del problema. Cada artefacto responde preguntas distintas, pero todos deberían hablar del mismo sistema y usar un vocabulario compatible.
Los requerimientos expresan necesidades y condiciones. Los casos de uso describen objetivos de actores y escenarios de interacción. UML ofrece diagramas para representar estructura, comportamiento e interacción. El modelo de dominio organiza los conceptos, relaciones y reglas del negocio. Cuando estos elementos se trabajan de forma coordinada, el equipo reduce ambigüedad y puede tomar mejores decisiones.
3.2 Una visión de conjunto
La relación puede entenderse como un proceso de refinamiento. Primero se descubren necesidades del negocio. Luego esas necesidades se expresan como requerimientos. Después se describen interacciones mediante casos de uso. A partir de allí se identifican conceptos del dominio, reglas y relaciones. Finalmente, algunos diagramas UML ayudan a representar y validar partes del modelo.
Este flujo no siempre es lineal. En la práctica, el equipo suele avanzar y retroceder: un caso de uso puede revelar una regla nueva, una regla puede modificar un requerimiento y un diagrama puede mostrar una inconsistencia que obliga a revisar el vocabulario del dominio.
3.3 Qué aportan los requerimientos
Los requerimientos indican qué se espera del sistema. Pueden describir funcionalidades, restricciones, reglas, condiciones de calidad, límites operativos o necesidades de información. Son una fuente principal para iniciar el modelado de dominio porque contienen términos del negocio y expectativas que el sistema deberá respetar.
Por ejemplo, el requerimiento "El paciente debe poder cancelar un turno con al menos 24 horas de anticipación" permite identificar conceptos como Paciente, Turno y Cancelación. También revela una regla: la cancelación depende del tiempo restante antes del turno.
3.4 Qué aportan los casos de uso
Los casos de uso muestran cómo un actor interactúa con el sistema para alcanzar un objetivo. Son especialmente útiles porque presentan el dominio en acción. No solo nombran conceptos, sino que muestran cuándo aparecen, quién los utiliza, qué decisiones se toman y qué excepciones pueden ocurrir.
En un caso de uso llamado "Reservar turno", el flujo principal puede mencionar que el paciente elige una especialidad, selecciona un profesional, consulta horarios disponibles y confirma una reserva. Los flujos alternativos pueden indicar que no hay disponibilidad, que el paciente ya tiene un turno pendiente o que el profesional no atiende en determinada fecha.
Cada paso puede sugerir conceptos, estados, relaciones o reglas que deben incorporarse al modelo de dominio.
3.5 Qué aporta UML
UML aporta una forma visual de representar conocimiento. No reemplaza al análisis, pero ayuda a ordenar y comunicar lo que se descubrió. En modelado de dominio, los diagramas más frecuentes son los diagramas de clases conceptuales, diagramas de objetos, diagramas de estados y, en algunos casos, diagramas de actividades.
Un diagrama de clases conceptual puede mostrar que un Paciente reserva Turnos, que un Profesional tiene una Agenda y que una Agenda contiene Franjas horarias. Un diagrama de estados puede mostrar que un Turno pasa de disponible a reservado, cancelado, atendido o ausente. Un diagrama de objetos puede mostrar un ejemplo concreto con datos ficticios para validar si el modelo tiene sentido.
La utilidad de UML depende de que el diagrama responda una pregunta real. Un diagrama claro puede revelar ambigüedades que el texto no mostraba.
3.6 Qué aporta el modelo de dominio
El modelo de dominio integra el conocimiento conceptual del negocio. Toma información de requerimientos, casos de uso, entrevistas, documentos, reglas existentes y conversaciones con expertos, y la organiza en conceptos, relaciones, restricciones, estados y eventos.
Su aporte principal es estabilizar el significado. Si los requerimientos mencionan "paciente", "usuario" y "cliente", el modelo obliga a definir si son el mismo concepto o conceptos distintos. Si un caso de uso habla de "cancelar un turno", el modelo ayuda a decidir qué ocurre con el estado del turno, qué reglas se aplican y qué consecuencias produce.
El modelo de dominio funciona como una base conceptual para revisar lo que el sistema debe entender.
3.7 Cómo se alimentan entre sí
Estos artefactos no deberían crearse como documentos independientes. Se alimentan entre sí continuamente:
- Un requerimiento puede revelar un concepto o una regla del dominio.
- Un caso de uso puede mostrar escenarios donde esa regla se aplica o falla.
- Un diagrama UML puede hacer visible una relación confusa o una multiplicidad incorrecta.
- El modelo de dominio puede mostrar que un requerimiento usa un término ambiguo.
- Un nuevo concepto del dominio puede obligar a actualizar casos de uso y requerimientos.
La calidad del análisis mejora cuando cada artefacto ayuda a revisar a los demás.
3.8 Ejemplo integrado: reserva de turno
Veamos un ejemplo simple en un sistema de turnos. Un requerimiento funcional podría decir: "El sistema debe permitir que un paciente reserve un turno con un profesional disponible".
Un caso de uso derivado podría llamarse "Reservar turno" y tener como actor principal al Paciente. El flujo principal indicaría que el paciente selecciona una especialidad, elige un profesional, revisa horarios disponibles y confirma el turno. Un flujo alternativo podría indicar que no existen horarios disponibles.
El modelo de dominio podría identificar Paciente, Profesional, Especialidad, Agenda, Franja horaria, Turno y Reserva. Además, podría establecer que una reserva ocupa una franja horaria y que una franja ocupada no puede ser reservada nuevamente.
UML podría representar esa información con un diagrama de clases conceptual y un diagrama de estados para Turno. Así, cada artefacto aporta una vista diferente del mismo problema.
3.9 Trazabilidad entre artefactos
La trazabilidad consiste en poder seguir la relación entre una necesidad, un requerimiento, un caso de uso, un elemento del modelo de dominio, una regla, una prueba o una decisión de diseño. No siempre hace falta una trazabilidad formal y pesada, pero sí conviene conservar conexiones claras.
Por ejemplo, si existe una regla de dominio que dice "un turno no puede reservarse si la franja horaria ya está ocupada", debería ser posible identificar de qué requerimiento o caso de uso surge, en qué escenarios se valida y qué parte del diseño la implementa.
La trazabilidad ayuda especialmente cuando el sistema evoluciona. Si cambia una regla, el equipo puede encontrar qué casos de uso, pruebas, pantallas o componentes podrían verse afectados.
3.10 Riesgos de trabajar los artefactos por separado
Cuando requerimientos, casos de uso, UML y modelo de dominio se trabajan sin conexión, aparecen problemas frecuentes:
- El mismo concepto se nombra de distintas formas en distintos documentos.
- Un caso de uso describe pasos que no tienen respaldo en el modelo de dominio.
- Un diagrama muestra relaciones que no aparecen en los requerimientos.
- Una regla importante queda escrita en texto, pero no se refleja en el modelo ni en las pruebas.
- Los cambios se aplican en un artefacto pero no en los demás.
- El equipo pierde confianza en la documentación porque no sabe cuál versión representa la realidad actual.
3.11 Orden práctico de trabajo
No existe un único orden válido, pero en muchos proyectos resulta útil seguir una secuencia como la siguiente:
- Reunir información inicial mediante entrevistas, documentos y observación del trabajo real.
- Identificar requerimientos funcionales y reglas principales.
- Describir casos de uso para los objetivos más importantes de los actores.
- Extraer conceptos, relaciones y restricciones del dominio.
- Representar partes del modelo con diagramas UML cuando aporten claridad.
- Validar el modelo con ejemplos, contraejemplos y expertos del dominio.
- Actualizar requerimientos, casos de uso y diagramas cuando aparezcan nuevos aprendizajes.
Lo importante no es completar una etapa y olvidarla, sino mantener una revisión continua.
3.12 Cómo validar la coherencia
Para revisar si los artefactos están alineados, conviene hacer preguntas concretas:
- ¿Los nombres usados en requerimientos aparecen igual en el modelo de dominio?
- ¿Cada caso de uso importante involucra conceptos del dominio claramente definidos?
- ¿Las reglas del negocio aparecen en algún lugar verificable del modelo?
- ¿Los diagramas UML muestran el mismo significado que el texto?
- ¿Las multiplicidades y estados coinciden con los escenarios de los casos de uso?
- ¿Los expertos del dominio reconocen el modelo como una representación válida de su trabajo?
3.13 Qué debes recordar de este tema
- Los requerimientos expresan necesidades y condiciones que el sistema debe cumplir.
- Los casos de uso muestran objetivos de actores y escenarios de interacción.
- UML permite representar visualmente estructura, comportamiento e interacción.
- El modelo de dominio organiza conceptos, relaciones, reglas, estados y eventos del negocio.
- Estos artefactos deben mantenerse conectados y usar vocabulario coherente.
- La trazabilidad ayuda a entender de dónde surge una regla y qué partes se ven afectadas si cambia.
- Un buen análisis permite que cada artefacto revise, complete y corrija a los demás.
3.14 Conclusión
Requerimientos, casos de uso, UML y modelo de dominio no compiten entre sí. Cada uno aporta una mirada distinta del sistema y, cuando se conectan adecuadamente, permiten comprender mejor el problema. Los requerimientos dicen qué se necesita, los casos de uso muestran cómo se alcanzan objetivos, UML ayuda a visualizar y el modelo de dominio estabiliza el significado del negocio.
En este tema vimos cómo se relacionan estos artefactos y por qué conviene mantenerlos coherentes. En el próximo tema estudiaremos el lenguaje ubicuo, una práctica clave para construir un vocabulario común con los expertos del negocio.