Diferencia entre revisiones de «Diagrama de dominio»

Revisión del 14:49 4 nov 2010

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.

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:

1. Listar las clases conceptuales candidatas
2. Definir el nombre para cada entidad
3. Añadir las asociaciones necesarias entre entidades
4. 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: