Learn UML Class Diagram to Become a Better Software Developer
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”— Abraham Lincoln
I believe this quote applies well to software developers as well. By modeling, you sharpen your axe by considering what you’re going to build, how you’re going to get feedback, and where you’re going to improve. It reduces the likelihood of failure by preparing you for building the real thing.
A model can save you many lines of code because it helps you see the big picture. Software modeling has been around for decades, and UML has become the most widely adopted standard.
A picture is worth a thousand words — UML
The development of software is rarely an isolated process. As developers, our job is to work with other developers, designers, project managers, and customers to produce products everyone will like.
It’s easy to miscommunicate when there are so many stakeholders, and in a field where small details matter, communication is vital to keeping projects on track. Sometimes even developers find themselves in long technical conversations only to realize that they were not talking about the same thing at all.
Object Management Group maintains the Unified Modeling Language as a diagramming standard, and it is an approved standard by the International Organization for Standardization. A standard for diagramming eliminates miscommunication over different diagramming styles.
Class Diagram
A class diagram represents the types of objects in a system, as well as the relationships among them. They also represent the lowest level of abstraction, for example, classes and interfaces. Models of this type are the most commonly used, showing a static view of the system, and they are often created by developers as part of the design process.
Let’s now examine the key elements of a class diagram. There are three groups of elements that make up class diagrams: classifiers, features, and relationships.
- Classifiers — Classifiers represent the types of entities in your system. Imagine a classifier as a super type of thing, such as abstract or concrete classes, interfaces, enumerations, generic classes, and so on. A classifier is identified as a box with three compartments, with a name in the top compartment. The bottom two compartments list the structural and behavioral features of the classifier.
- Features — Features provide the structural and behavioral characteristics of classifiers. The structural features are nothing more than the properties, or attributes, mentioned in the middle of the classifier notation, and the behavioral features are the operations or methods that go at the bottom.
- Relationships — Relationships show how these entities are related. This makes the system work by connecting all classifiers together. Relationships, for example, show classes that depend on each other, inherit from each other or implement interfaces. Relationships of this type can be divided into three categories: associations, generalizations, and dependencies.
How do we identify classifiers, features, and relationships for a system?
To derive a class diagram from the specification:
- As a first step, identify all nouns, since they are potential classifiers. They are the entities that will be included in the system.
- Next, identify the attributes of the classifiers.
- Finally, identify any verbs that indicate a relationship between these classifiers. They model the behaviors of the classifiers.
Now that we have identified these key elements, we can create the class diagram using UML notations.
Classifiers
A classifier is a common abstraction for different types of objects such as classes and interfaces. There are six types of classifiers.
When you begin modeling your classifiers, everything starts as a regular class. During that time, it is difficult to decide whether it should be an abstract class, an interface, or something else. Once you have developed some parts of your system, you will begin to see the possibility of applying some design patterns that could enhance the quality of your design. Those patterns will then inspire the use of various types of classifiers.
Let’s examine these six classifiers:
Concrete classes, abstract classes, and interfaces, the most common types, have a common notation of a box with three compartments, the top compartment containing the classifier’s name.
The class name is just written in a regular font.
The name of abstract classes is italicized, stereotyped, or both. Stereotyping is nothing more than putting the type abstract within double angle brackets. This is something UML offers for additional classification of various things over and above what standard UML notations offer.
As an interface, you can use a stereotype or just an I, or you can use the lollipop notation, as shown below, in which interface is drawn as a circle attached to the implementing class.
Likewise, enumeration can be shown with a stereotype, or just with the letter E.
A generic class uses a template parameter, shown as a small rectangle in the top right corner.
Active classes are represented by rectangles with bars on both sides. The notation depicts a class that runs autonomously in its own thread.
Features
In class diagrams, a second key element identifies the structural and behavioral characteristics of a classifier. In a class, structural features are attributes, and behavioral features are methods.
While you can write just the basics of attributes, such as their name and their data type, UML gives you some useful notations to help you add more details to them.
Attributes — Structural Features
This long string shows different aspects of the attribute.
visibility attribute-name: type multiplicity = default-value {property-modifier}
Example:
+ studentId: string [1]{id, readonly}
Visibility
private : –
protected : #
package: ~
public: +
This is followed by the attribute’s name, followed by its data type.
Multiplicity
It indicates how many instances of values will this attribute hold:
zero or more: *
one or more: 1..*
exactly one: 1
between m and n: m..n
Default-value
If the attribute has a default-value, then you can put that after an equal sign.
Property-modifier
Within the curly braces, you can provide modifiers for the property like readOnly, unique etc.
Methods — Behavioural Features
Behavioral properties are operations, or methods, and are modeled in a way similar to attributes.
visibility method-name (parameter-list): return-type {property-modifier}
Example:
+attendSession(in event: EventClass):void
Visibility
private : –
protected : #
package: ~
public: +
This is followed by the name, followed by parameters within parentheses.
Parameter-list
The parameters have direction that can be in, out, inout, or return.
direction name:type = default-value
It means that the parameter value is just coming in, out means it is a carrier to carry the value back to the caller, inout means both.
Return-type
It will be sent back to the caller as return-value.
Property-modifier
Within the curly braces, you can provide modifiers like ordered, unique etc.
Relationships
Relationships are the third key element in a class diagram. There is a variety of relationships, possibly between any two classifiers.
They can be divided into association, generalization, and dependency.
Association
There are two ways in which associations can be expressed, association links and association classes. Additionally, association links can be compositions or aggregations.
Association link
An association link is created when one class, the source, uses an instance of another class, the target, in some way. The association is at the instance level. Note that the source refers to some attribute of the target, which indicates that it refers to an instance of the target. It is easier to understand the relationship when the arrow is labeled, and the labels star and one indicate multiplicity.
Aggregation and Composition
The association can be an aggregation if the source instance contains one or more target instances. It is shown with a hollow diamond notation on the source site of the link whereas in a composition it’s shown as a filled-in diamond on the link.
The difference between an aggregation and a composition is that an aggregation contains a target class, but the target may also belong to other sources and they have separate lifetimes, while in a composition, ownership is not shared between other sources and the target lifetime is same as that of source.
Association Class
It is better to create an association class that models the relationship between two classes that are mutually dependent. An association class helps decouple two mutually interdependent classes by bringing their dependencies into a third class.
Generalization
The second type of relationship among classifiers is generalization, which is simply our good old inheritance relationship between two classes or interfaces. A solid arrow leads from the child class to the parent class with a hollow arrowhead. The generalization relationship indicates that the child inherits them implicitly.
Dependency
The third type of relationship is a dependency between classifiers, where one classifier acts as a client and another acts as a supplier for its specification and implementation. This is a compiled time relationship. A simple example of this is the relationship between a class and an interface. If a class implements an interface, then it is a client of the interface.
Additionally, there are other ways in which the client can be dependent on the supplier, such as the supplier type being one of the parameters or the client having a method that returns the supplier type. Dependencies are shown with dotted or dashed arrows going from the client to the supplier.
