uml - sencillos - ¿Cuál es la diferencia entre un diagrama de clase de dominio y un diagrama de clase de diseño?
diagrama de secuencia uml (3)
¿Puede alguien explicar brevemente la diferencia entre un diagrama de clase de dominio y un diagrama de clase de diseño?
Encontré una explicación en las respuestas de Yahoo , pero me parece bastante confusa.
Si su enfoque está en el diagrama en sí, hay dos grandes diferencias entre los diagramas sobre el modelo de dominio y los diagramas sobre el modelo de diseño: (al menos esto es lo que dice el libro de Larman Aplicando UML y patrones )
En los diagramas UML que representan el modelo de dominio, no puede usar flechas. Todas las clases están interconectadas con una línea, lo que significa "relación", y debe usar anotaciones de texto sobre las líneas para ilustrar qué relación es exactamente. Mientras que en los modelos de diseño, tiene que usar flechas, todos los tipos de flechas: asociación, herencia ... etc.
En el modelo de diseño, debe especificar el tipo de propiedades y métodos, etc., mientras que en el modelo de dominio solo tiene que escribirlos sin nada adicional (como en el mundo real). Por ejemplo,
value: int
en el modelo de diseño se escribirá comovalue
en el modelo de dominio.
Referencia: Aplicación de UML y Patrones 3ª Edición Capítulo 9 y 16.
UML NO tiene tales diagramas
Enterprise Architect tiene Modelo de Dominio - mira wiki .
En cuanto al "diagrama de diseño de clase", es simplemente desconocido por EA, VP UML o UML. Creo que, el diagrama de clase habitual de la UML está destinado.
Un modelo de dominio se llama modelo conceptual en el modelado de base de datos, mientras que un modelo de diseño se llama modelo lógico .
Estas distinciones también se utilizan en el desarrollo guiado por modelos, donde tenemos una sucesión de tres tipos de modelos:
- Modelos de dominio (independientes de la solución) resultantes de la ingeniería de dominio / requisitos en el análisis del sistema, o fase inicial, de un proyecto de desarrollo
- Modelos de diseño (independientes de la plataforma) resultantes de las actividades de diseño del sistema en la fase de elaboración.
- Modelos de implementación (específicos de la plataforma), que se derivan de un modelo de diseño.
Si bien el modelado del sistema incluye tanto la información como el modelado de procesos, parece que solo le preocupa el modelado de la información. Aquí, podemos usar los términos "diagrama de clase de dominio" y "diagrama de clase de diseño" para el modelo de información conceptual y el modelo de diseño de información realizado en forma de diagramas de clase UML.
[El siguiente texto / diagramas se agregaron más tarde, en septiembre de 2016]
Las relaciones de uno a muchos entre los modelos conceptuales y los modelos de diseño, y entre los modelos de diseño y los modelos de implementación se ilustran en la siguiente Figura:
Como ejemplo que ilustra cómo funciona la cadena de derivación desde el concepto a través del diseño hasta la implementación, considere el siguiente modelo de concepto / clase persona / persona:
Los modelos de dominio son descripciones independientes de la solución de un dominio de problema producido en la fase de análisis de un proyecto de ingeniería de software. El término "modelo conceptual" se usa a menudo como sinónimo de "modelo de dominio". Un modelo de dominio puede incluir tanto descripciones de la estructura de estado del dominio (en modelos de información conceptual) como descripciones de sus procesos (en modelos de procesos conceptuales). Son independientes de la solución, o "independientes de la computación", en el sentido de que no están preocupados por hacer ninguna elección de diseño del sistema o por otros problemas computacionales. Más bien, se centran en la perspectiva y el lenguaje de los expertos en la materia para el dominio en cuestión.
En la fase de diseño, primero se desarrolla un modelo de diseño independiente de la plataforma, como una solución computacional general para el problema de ingeniería de software dado, sobre la base del modelo de dominio. El mismo modelo de dominio se puede usar potencialmente para producir una serie de (incluso radicalmente) diferentes modelos de diseño que representan diferentes opciones de diseño. Luego, al tomar en consideración una serie de problemas de implementación que van desde los estilos arquitectónicos, los criterios de calidad no funcionales que deben maximizarse (por ejemplo, rendimiento, adaptabilidad) y las plataformas de tecnología objetivo, uno o más modelos de implementación específicos de la plataforma se derivan del modelo de diseño.
Véase también http://web-engineering.info/book/WebApp1/ch05s03.html