Diagrama de dominio
Los diagramas de dominio se utilizan para analizar orientado a objetos. Si bien los casos de uso son un elemento importante en el análisis de requisitos, no son orientados a objetos. Para orientarnos a objetos, necesitamos modelar entidades, cómo ? Necesitamos acompañar el caso de uso con un diagrama de dominio.
Contenido
La importancia de modelar las Entidades en el análisis
Las entidades contienen la lógica del negocio, y en ellas termina resolviéndose el sistema. Una diferencia esencial entre el análisis orientado a objetos y el estructurado es la división por clases conceptuales (entidades) en lugar de la división por funciones. Por lo tanto, la principal tarea del análisis es identificar diferentes conceptos en el dominio del problema y documentar el resultado en diagramas de dominio. Los casos de uso describen procesos por sobre el dominio. En adelante hablaremos de diagrama de dominio y no de modelo de dominio. El diagrama es solo una parte del modelo, y el modelo de dominio es el conjunto de diagramas de dominio.
Analizando entidades
Los casos de uso muestran el análisis de requisitos del nuevo sistema, así que no podemos modelar las entidades sin antes tener los casos de uso. Ahora que pasa cuando estamos haciendo reingeniería, donde los casos de uso surgen de algún sistema existente? No hay una receta que diga si primero el caso de uso o primero el diagrama de dominio, pero nos ha ayudado bastante hacer el diagrama de dominio a medida que escribimos el caso de uso y vamos trayendo a escena conceptos del negocio.
Al momento de modelar las entidades que participan en una funcionalidad, conviene pensar de a un escenario por vez. En un proceso iterativo podemos analizar los escenarios del caso de uso a través del tiempo, entonces, modelar de entrada todas las entidades, puede generar confusiones a la hora de hacer entregas parciales del caso de uso.
Los diagramas de dominio se expresan en el lenguaje del usuario o cliente, no depende de ningún entorno informático y no considera restricciones de implementación.
Una guía para construir un diagrama de dominio:
- Listar las clases conceptuales candidatas
- Definir el nombre para cada entidad
- Añadir las asociaciones necesarias entre entidades
- Definir los atributos necesarios para cada entidad
Listar las clases conceptuales candidatas
Los casos de uso son la fuente a explorar para identificar frases nominales y el diagrama de dominio debe verse como un mapa de conceptos. Pero tampoco es la idea mostrar conceptos que no hacen a la funcionalidad que se está describiendo. Cuando conocemos o sabemos más del negocio, podemos caer en el vicio de querer modelar todo lo conocido, pero es mejor modelar todo lo realmente necesario para graficar el caso de uso.
Definir el nombre de cada entidad
Las entidades se crean con un elemento de tipo clase.
Añadir las asociaciones necesarias entre las entidades
Es más importante encontrar las entidades que las asociaciones entre entidades. La mayoría del tiempo dedicado a la creación del diagrama de dominio debería emplearse en la identificación de las entidades, y no en las asociaciones.
Una asociación es una relación entre entidades que indica alguna conexión significativa e interesante.
En un diagrama de dominio con una determinada cantidad de entidades, puede ocurrir que haya muchas relaciones entre las diferentes entidades. No es conveniente dibujar todas las relaciones posibles, eso genera mucho “ruido” en la interpretación del dominio. Una buena práctica es repasar el proceso que se describe en el caso de uso y solo mostrar las relaciones que se necesitan en el proceso.
Es importante, particularmente en esta etapa, tener en claro qué es una entidad, para evitar querer crear entidades a partir de tablas del modelo de datos. Recordemos que las entidades no son una representación del modelo de datos!
Las asociaciones se representan con una línea entre entidades y con un nombre de asociación:
A diferencia de los diagramas de diseño, en el análisis, las asociaciones entre entidades son bidireccionales, opcionalmente se puede utilizar una “flecha de dirección de lectura” que no tiene significado en términos del modelo, sólo es una ayuda para el lector del diagrama. Si la “flecha de dirección de lectura” no está presente, existe una convención de leer la asociación de izquierda a derecha o de arriba hacia abajo.
Definir los atributos de las entidades
Teniendo entonces ya las entidades con sus nombres, podremos incorporarle los atributos que contendrán. Al igual que con las relaciones, resulta útil identificar aquellos atributos necesarios para satisfacer los requisitos del escenario que se está analizando.
Un atributo no debería ser un concepto complejo sino que deberían ser cosas simples o tipos de datos. Por ejemplo: fecha, hora, número, color, número, código, descripción, cantidad.
Cuando algo está compuesto de más de un elemento, da la idea de estar frente a una entidad y no un atributo. Por ejemplo, la dirección puede resultar un concepto simple pero en realidad está formada por calle, altura, etc.
Si una entidad puede tener muchos valores simultáneos para un mismo atributo, ese atributo debería ser otra entidad. Por ejemplo, una persona puede tener muchos números de teléfono, entonces número de teléfono es una entidad con una asociación de 1 a muchos con la persona.
Una regla importante a tener en cuenta es relacionar las entidades con una asociación y no a través de un atributo.
No existe un único diagrama de dominio correcto, todos serán una aproximación del dominio que estamos intentando entender. Un buen diagrama captura las abstracciones y da la información necesaria para entender el contexto.
Entidades de especialización
En algunas situaciones, nos ha resultado una práctica sumamente útil identificar una entidad que represente un concepto de modo general y luego identificar entidades de ese concepto de modo especializado. Veamos un ejemplo:
