Diferencia entre revisiones de «Diagrama de dominio»

De Dos Ideas.
Saltar a: navegación, buscar
(Página creada con '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 ob…')
 
(Analizando entidades)
Línea 16: Línea 16:
 
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.
 
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 secuencia de pasos necesarios para construir un diagrama de dominio que puede servir de guía:
+
Una guía para construir un diagrama de dominio:
  
 
#Listar las clases conceptuales candidatas
 
#Listar las clases conceptuales candidatas

Revisión del 13:51 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