Diagrama de dominio - Historial de revisiones

Cblatter en 15:01 4 nov 2010

2010-11-04T15:01:55Z

Cblatter en 15:00 4 nov 2010

2010-11-04T15:00:45Z

Cblatter en 14:59 4 nov 2010

2010-11-04T14:59:32Z

Cblatter en 14:53 4 nov 2010

2010-11-04T14:53:50Z

Cblatter en 14:49 4 nov 2010

2010-11-04T14:49:02Z

201.251.185.130 en 14:47 4 nov 2010

2010-11-04T14:47:28Z

201.251.182.130: /* Analizando entidades */

2010-11-04T13:51:53Z

‎Analizando entidades

201.251.182.130: 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…'

2010-11-04T13:50:51Z

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…'

Página nueva

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 secuencia de pasos necesarios para construir un diagrama de dominio que puede servir de guía:

#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

← Revisión anterior		Revisión del 15:01 4 nov 2010
Línea 88:		Línea 88:

	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.		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]]

@@ Línea 84: / Línea 84: @@
 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.

@@ Línea 11: / Línea 11: @@
 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.
@@ Línea 23: / Línea 22: @@
 #Añadir las asociaciones necesarias entre entidades
 #Definir los atributos necesarios para cada entidad
 === Listar las clases conceptuales candidatas ===
@@ Línea 68: / Línea 68: @@
 [[Archivo:UML-diagrama de dominio - especializacion.jpg]]

@@ Línea 11: / Línea 11: @@
 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.
@@ Línea 45: / Línea 46: @@
 [[Archivo:UML-diagrama de dominio - relaciones.jpg]]

← Revisión anterior		Revisión del 14:49 4 nov 2010
Línea 43:		Línea 43:

	Las asociaciones se representan con una línea entre entidades y con un nombre de asociación:		Las asociaciones se representan con una línea entre entidades y con un nombre de asociación:
		+
		+	[[Archivo:UML-diagrama de dominio - relaciones.jpg]]

← Revisión anterior		Revisión del 14:47 4 nov 2010
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 ===
		+
		+	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:

@@ 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.
-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