Only this week 80 % discount on e-learning courses of C# .NET
Get up to 60 % extra points for free! More info
C# week

Lesson 4 - UML - Domain Model

In the previous lesson, UML - Use Case Specification, we finished the use case diagram. We're getting to the domain model. The domain model as well as the Use Case diagram is created in the initial phase of software development. It's a form of the class diagram. I assume I don't have to mention that our system will be programmed in the object-oriented manners and therefore designed using the object-oriented approach. The basic entity is a class.

However, classes of the domain model are very simplified. They have only important attributes and no methods. If your language uses any special accent characters, feel free to use them in the names of classes, attributes, and other identifiers of this diagram. The domain model is a sketch of the elementary entities of the system and the relationships between them. It is platform independent (not intended for any specific programming language) and attributes do not have data types.

When creating a domain model, we base it on the client's requirements. We can later identify the key entities and relationships between them clearly from this diagram. We draw these entities in the model as classes.

The graphical notation of a class is a rectangle divided horizontally into 3 parts.

Notace třídy v doménovém diagramu

The first part holds the name of the class, the second one contains the attributes, and we list the methods in the third part. In the domain model, we'll use only a simplified class notation with the class name and its attributes. We'll draw complete classes further in the class diagram.

The classes are connected to each other by relationships.


UML provides several types of relationships. Let's list the fundamental ones.


An association is the basic relationship between two entities. These entities can exist independently of each other. We draw it as a simple solid line.

Let's take an example of Car and Driver as a simple association between two entities. The relationship would be drawn as follows:

The UML notation of the association relationship between domain model classes

The association is bi-directional by default. That means that the first entity has a reference to the other, and the other to the first. We can change this behavior by adding a simple arrow specifying the direction of the relationship. Only the instance from which the arrow points stores the reference to the other entity in these cases.

It's possible to create an association even among three classes, but we won't bother with this now.


Aggregation represents the relationship between a whole and its parts. We draw it as a solid line with an empty diamond shape. The diamond is drawn at the class representing the whole (e.g. an article section). From the implementation point of view, this is the entity that holds the item collection. An entity representing the part can exist independently and be part of other collections.

A section containing articles mentioned above could be an example of aggregation. The numbers at each end of the line specify the multiplicity. It this case, that the section contains any number of articles and the article belongs to at least 1 section.

The UML notation of the aggregation relationship between domain diagram classes

We'll focus on multiplicity further in this article.


A composition is similar to aggregation, but it represents a stronger relationship. The entity representing the part has no sense without the entity representing the whole. If the entity representing the whole is removed, its parts are automatically removed as well.

We draw the composition relationship like the aggregation, but the diamond shape is filled. The multiplicity of the entity representing the whole must always be 1. This relationship is confusing and I'd rather avoid it and replace it with aggregation.

Order and Order Item could be an example of composition. While an article without a section from the previous example would still have some meaning, an order item does not make any sense without its order. Therefore, the composition is used in this case.

The UML notation of the composition relationship between domain model classes


The last relationship, we'll mention here, is generalization. In terms of implementation, it represents inheritance. One entity inherits the properties and behavior from another entity. We've already seen this kind of relationship in the use case diagram.

We draw the generalization as a solid line with an empty arrow on one side (a triangle if you like). The arrow is on the side of the entity from which it's inherited.

The Shape class can be an example. The Square and Circle classes could inherit from Shape.

UML notace vztahu generalizace mezi třídami v doménovém diagramu


Let's get back to multiplicity. We can specify the multiplicity for association, aggregation, and composition (for composition on one side only). Let's go back to the example with a section and an article: We read the multiplicity here as follows: A section can contain any number of articles (this is shown by the asterisk at the Article class). An Article belongs to 1 or more sections (it's shown by 1..* at the Section). Let's list available multiplicity syntax:

  • 1 (number) - Indicates a specific value (1 in this example).
  • * (asterisk) - Indicates any number (even 0). Instead of an asterisk, we can find the N symbol in some diagrams.
  • 1..* (interval) - We can specify an interval with 2 dots. Then we use the symbols we already known, such as: 2..6 or 1..* or 0..1.

We can even mix different syntax, e.g. as: 1, 2, 3, 7..*. This would indicate numbers 1, 2, 3, or 7, or greater.

If the multiplicity is not specified, it indicates the default value of 1.


Let's continue with designing our own network. We'll think about the elementary entities and connect them with proper relationships. We could end with a result as follows (I provided attributes as well, but it's not necessary):

A CMS domain model in UML

Note that in the domain diagram, we add descriptions to the relationships. We do not usually do it in the class diagram.

Next time, in the lesson UML - Class Diagram, we will talk about the class diagram.


Previous article
UML - Use Case Specification
All articles in this section
Article has been written for you by David Capka
Do you like this article?
1 votes
The author is a programmer, who likes web technologies and being the lead/chief article writer at He shares his knowledge with the community and is always looking to improve. He believes that anyone can do what they set their mind to.
Unicorn university David learned IT at the Unicorn University - a prestigious college providing education on IT and economics.




Nilesh gopnarayan:13. April 12:20

Is written by - which type of relation is this

13. April 12:20
David Capka team
Replies to Nilesh gopnarayan
David Capka:16. April 14:40

A simple arrow is always association (a reference to an instance).

16. April 14:40
You can walk through a storm and feel the wind but you know you are not the wind.
To maintain the quality of discussion, we only allow registered members to comment. Sign in. If you're new, Sign up, it's free.

2 messages from 2 displayed.