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.

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

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.

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.

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):

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.