Diferencia entre revisiones de «Diagrama de dominio»
| (No se muestran 3 ediciones intermedias del mismo usuario) | |||
| Línea 22: | Línea 22: | ||
#Añadir las asociaciones necesarias entre entidades | #Añadir las asociaciones necesarias entre entidades | ||
#Definir los atributos necesarios para cada entidad | #Definir los atributos necesarios para cada entidad | ||
| + | |||
=== Listar las clases conceptuales candidatas === | === Listar las clases conceptuales candidatas === | ||
| Línea 45: | Línea 46: | ||
[[Archivo:UML-diagrama de dominio - relaciones.jpg]] | [[Archivo:UML-diagrama de dominio - relaciones.jpg]] | ||
| + | |||
| + | 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: | ||
| + | |||
| + | [[Archivo:UML-diagrama de dominio - especializacion.jpg]] | ||
| + | |||
| + | Esta jerarquía se la conoce con el nombre de generalización-especialización, o simplemente jerarquía de clases en la cual, la superclase representa un concepto más general y la subclase conceptos más especializados. La subclase conceptual es un tipo de la superclase. | ||
| + | |||
| + | Nos conviene identificar estas especializaciones cuando nos vamos a referir a ellas, entonces teniéndolas identificadas gráficamente ayuda a comprenderlas y reducir información repetida. | ||
| + | |||
| + | La relación de generalización se representa con una línea que termina con un triángulo grande en el extremo que apunta a la entidad más general. | ||
| + | |||
| + | == Diagramas UML para entidades == | ||
| + | |||
| + | El diagrama de dominio no puede faltar al momento de modelar las entidades y se puede graficar mediante un diagrama de clases. | ||
| + | |||
| + | La regla general puede ser hacer un diagrama de dominio para cada caso de uso. Si bien parecen situaciones donde un caso de uso no cuenta con demasiado manejo de entidades y se vale de otros casos de uso para describir una funcionalidad, entonces la tendencia es englobar en un único diagrama de dominio esa funcionalidad. Por ejemplo, la funcionalidad para especificar las condiciones comerciales de un cliente está escrita en más un caso de uso y entonces conviene hacer un único diagrama de dominio que muestre las entidades que hacen a las condiciones comerciales del cliente. | ||
| + | |||
| + | La cantidad de entidades puede llegar a ser lo suficientemente amplia para que sea conveniente dividirlas en paquetes que incluyan conceptos fuertemente relacionados. Esto ayuda para mejorar la comprensión y para abordar el trabajo de análisis en paralelo, donde cada analista genera el diagrama de dominio que acompañara al caso de uso. | ||
| + | |||
| + | Al empaquetar las entidades, el diagrama de dominio mostrará el intercambio que hay entre los diferentes paquetes. Veamos en el ejemplo como se visualiza la relación de la factura de venta con los planes: | ||
| + | |||
| + | [[Archivo:UML-diagrama de dominio.jpg]] | ||
| + | |||
| + | Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre analistas que estén haciendo la tarea y los mismos diseñadores que tomen estos diagramas como puerta de entrada. | ||
| + | |||
| + | == Ver también == | ||
| + | * [[Diseño Por Contrato]] | ||
| + | * [[Patrones De Diseño]] | ||
| + | * [[Interfaces De Usuario]] | ||
| + | * [[UML]] | ||
| + | |||
| + | [[Category: Diseño De Software]] | ||
Revisión actual del 15:01 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.
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:
Esta jerarquía se la conoce con el nombre de generalización-especialización, o simplemente jerarquía de clases en la cual, la superclase representa un concepto más general y la subclase conceptos más especializados. La subclase conceptual es un tipo de la superclase.
Nos conviene identificar estas especializaciones cuando nos vamos a referir a ellas, entonces teniéndolas identificadas gráficamente ayuda a comprenderlas y reducir información repetida.
La relación de generalización se representa con una línea que termina con un triángulo grande en el extremo que apunta a la entidad más general.
Diagramas UML para entidades
El diagrama de dominio no puede faltar al momento de modelar las entidades y se puede graficar mediante un diagrama de clases.
La regla general puede ser hacer un diagrama de dominio para cada caso de uso. Si bien parecen situaciones donde un caso de uso no cuenta con demasiado manejo de entidades y se vale de otros casos de uso para describir una funcionalidad, entonces la tendencia es englobar en un único diagrama de dominio esa funcionalidad. Por ejemplo, la funcionalidad para especificar las condiciones comerciales de un cliente está escrita en más un caso de uso y entonces conviene hacer un único diagrama de dominio que muestre las entidades que hacen a las condiciones comerciales del cliente.
La cantidad de entidades puede llegar a ser lo suficientemente amplia para que sea conveniente dividirlas en paquetes que incluyan conceptos fuertemente relacionados. Esto ayuda para mejorar la comprensión y para abordar el trabajo de análisis en paralelo, donde cada analista genera el diagrama de dominio que acompañara al caso de uso.
Al empaquetar las entidades, el diagrama de dominio mostrará el intercambio que hay entre los diferentes paquetes. Veamos en el ejemplo como se visualiza la relación de la factura de venta con los planes:
Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre analistas que estén haciendo la tarea y los mismos diseñadores que tomen estos diagramas como puerta de entrada.
