Can someone briefly explain the difference between a domain class diagram and a design class diagram?
I found a explanation on Yahoo answers, but I find it quite confusing.
Definition. Class Diagram provides an overview of the target system by describing the objects and classes inside the system and the relationships between them. It provides a wide variety of usages; from modeling the domain-specific data structure to detailed design of the target system.
Class diagrams are the blueprints of your system or subsystem. You can use class diagrams to model the objects that make up the system, to display the relationships between the objects, and to describe what those objects do and the services that they provide. Class diagrams are useful in many stages of system design.
Class diagrams and ERDs both model the structure of a system. Class diagrams represent the dynamic aspects of a system: both the structural and behavioural features. ERDs, depicting only structural features provide a static view of the system. A class is a general concept (represented as a square box).
In the analysis class diagram, associations, aggregations and compositions represented “remembered” information. In the design, all information is stored as attributes. Thus, if we need to remember that object instances are linked, these links must be implemented as stored object references.
A domain model is called conceptual model in database modeling, while a design model is called logical model.
These distinctions are also used in model-driven development, where we have a succession of three types of models:
While system modeling includes both information and process modeling, you seem to be concerned with information modeling only. Here, we can use the terms "domain class diagram" and "design class diagram" for the conceptual information model and the information design model made in the form of UML class diagrams.
The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:
Considering information/class/data modeling we get the following picture:
As an example that illustrates how the derivation chain from concept via design to implementation works, consider the following model of a people/Person concept/class:
Domain models are solution-independent descriptions of a problem domain produced in the analysis phase of a software engineering project. The term "conceptual model" is often used as a synonym of "domain model". A domain model may include both descriptions of the domain’s state structure (in conceptual information models) and descriptions of its processes (in conceptual process models). They are solution-independent, or ‘computation-independent’, in the sense that they are not concerned with making any system design choices or with other computational issues. Rather, they focus on the perspective and language of the subject matter experts for the domain under consideration.
In the design phase, first a platform-independent design model, as a general computational solution to the given software engineering problem, is developed on the basis of the domain model. The same domain model can potentially be used to produce a number of (even radically) different design models representing different design choices. Then, by taking into consideration a number of implementation issues ranging from architectural styles, nonfunctional quality criteria to be maximized (e.g., performance, adaptability) and target technology platforms, one or more platform-specific implementation models are derived from the design model.
See also the Open Access book chapters Information Modeling and Deriving a Table Model from an Information Design Model.
If your focus is on the diagram itself, there are two big differences between diagrams about domain model and diagrams about design model: (At least this is what the Larman book Applying UML and Patterns says)
In UML diagrams which represent domain model, you cannot use arrows. All classes are interlinked with a line, which signifies "relation", and you should use text annotations over the lines to illustrate what relation it exactly is. While in design models, you have to use arrows, all types of arrows: association, inheritance... etc
In design model you have to specify the type of properties and methods etc, while in domain model you only have to write them without anything additional(just like in real world). For example, value: int
in design model will be written as value
in domain model.
Reference: Applying UML and Patterns 3rd Edition Chapter 9 and 16.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With