Lesson 4 - UML - Domain Model

Software design UML 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.

Relationships

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

Association

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

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.

Composition

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

Generalization

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

Multiplicity

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.

Example

Let's continue with designing our own ICT.social 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.


 

 

Article has been written for you by David Capka
Avatar
Do you like this article?
No one has rated this quite yet, be the first one!
The author is a programmer, who likes web technologies and being the lead/chief article writer at ICT.social. 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 College The author learned IT at the Unicorn College - a prestigious college providing education on IT and economics.
Thumbnail
Previous article
UML - Use Case Specification
Thumbnail
All articles in this section
UML
Thumbnail
Next article
UML - Class Diagram
Activities (2)

 

 

Comments

To maintain the quality of discussion, we only allow registered members to comment. Sign in. If you're new, Sign up, it's free.

No one has commented yet - be the first!