Lesson 5 - UML - Class Diagram

In the previous lesson, UML - Domain Model, we created a domain model and introduced the basic notation of classes in UML as well as the basic relationships between them. The domain model was a simplified version of the class model (diagram). In today's UML tutorial, we're gonna show some other relationships and create a class diagram.

Class Diagram

The class diagram is a diagram of implementation. This is the difference over the domain model, which was rather a sketch of the system. The class diagram is real and therefore it must be complete. When the programmer implements in into code, the code must work. So all the classes of the application will be there. The classes will have all the attributes and methods. The diagram is platform specific, that is, specific for a particular programming language. It also means that no other characters than of the basic English alphabet are used in the identifiers. Attributes have language-specific data types, and so on.

Diagram Meaning

The class diagram is a manual for the programmer. With our diagram, they should no longer solve any fundamental questions or problems, their work should be (maybe unfortunately ) routine. Experienced programmers and analysts are in charge of designing the system. Thanks to the design, programming the system itself can then be passed on to less experienced programmers, who are often cheaper. However, it's a good practice to create a diagram of the classes, even if we write the system for ourselves. This will force us to first think in the context of the whole system and then program it. This prevents such problems when we write half of the system and then find out that it won't work this way. Complex information systems can no longer be created without designing them first, and team work cannot be done without good design. The class diagram will also serve as documentation for further development.

Let's show the graphical notation of the class in UML one more time, now complete:

The first part of the rectangle holds the name of the class again.

In the second part, there are attributes and their data types. The access modifier is placed before each attribute. We have 4 options:

• - (minus) - Private attribute.
• + (plus) - Public attribute.
• # (hash cross) - Protected attribute.
• ~ (tilde) - Attribute visible from within the package.

We definitely know the meaning of the first three modifiers from the object-oriented programming. A package attribute is an attribute visible across the whole class package (namespace).

We write a colon between attribute names and their data types.

The methods in the last rectangle are written in the similar way. It's possible to specify several more symbols, but we won't use them in practice much and therefore we'll omit them.

Relationships

Apart from the domain model, we can use two more relationships here.

Interface Realization

The realization relationship is between an interface and a class that implements this interface. The class representing the interface has a so-called stereotype. We write stereotypes enclosed in double angle quotes. We've already seen it with the <<include>> relationship in the use case diagram. Stereotypes allow us to change the meaning of a given element in a diagram. Now we're changing the class symbol to represent an interface. The class implementing the interface is connected to the interface by an inheritance-like relationship, only the line is rendered as interrupted.

Association class

Association class is a class that mediates the relationship between two entities. The advantage of such a relationship is that the association class can carry some extra attributes of the relationship. Person and Tour are often mentioned as an example, where the Participation association class assigns a person to a trip and adds details such as whether the person paid for a lunch or when the person registered to the trip. Person and Hotel could be another example. The hotel sets no fixed time of arrival and is ordered by a particular person. A similar class could, for example, be between an employee and a firm to carry the employee's salary. Another use may be to create the M:N (many to many) relationship, similar to the one used in databases. The association class would hold a collection of references in this case. However, using an association class can be sometimes misleading, and if you're not sure, avoid it.

Class Diagram example

Let's proceed to the example and create a class diagram of ICT.social. Of course, it'll be based on the previous domain model.

We can see that as opposed to the domain model, there are also service classes together with entity classes. We can see managers providing functionality related to some entities and holding the important instances of these entities such as the current article and the current user. It's always a good practice to detach such login into separated managers than to pollute entity classes with it. The domain model only mapped important entities from the business perspective and thus we didn't even think about how the system will actually work inside. With the transition from the domain model to the class diagram, the number of classes will always increase.

Notice the comment symbol on the left, saying that the class represents a registered user. We can comment any UML entity like this to provide additional information to improve communication. We should also mention the ArticleState enumeration type, which is drawn here as a class, and changed to the enumeration type using the <<enumerable>> stereotype. We've already described the rest of the diagram, so let's take a look at it. As with all diagrams, it's just one possible way to design the system. There are other possibilities out there, and many of them would be also correct.

Next time, in the lesson UML - State Machine Diagram, we'll focus on class description and show an even more complex and practical example of the class diagram.