This article was originally published on Medium.

In my line of work, I’m often using UML diagrams. Daily, I daresay. Regardless, I never understood the subtlety of the diagram’s components. When to use a full arrow and when hollow, the line should be solid or dashed and which direction it should point. I’m done living in ignorance. So, here I am, about to start the UML diagrams series of articles.
...

Briefly about UML

UML (Unified Modeling Language) is a common software engineering modeling language that is used to solve a wide variety of problems. It’s a “the Common Tongue” of Westeros, for Game of Thrones fans. It helps you specify, visualize, and document models of software systems, including their structure and design, before coding (with an emphasis on “before”). As the old proverb says: “The carpenter measures twice and cuts once”.

There are several types of UML diagrams and each one of them serves a different purpose. The two most broad categories that encompass all other types are Structural and Behavioral diagrams.

Structural (or Static) diagram visualizes the system’s static structure through objects, attributes, operations, and relationships. I have a cat, Lola. She has some stuff, such as a food bowl, claw sharpener, and the poop-house. So, the static aspects of Lola encompass the existence of her stuff. By the way, Lola herself will be described as an object (from an object-oriented view, right?).

The Structural diagrams are: Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, Deployment Diagram, and Profile Diagram.

Behavioral (or Dynamic) diagrams are used to visualize the dynamic aspects of a system. The Behavioral category includes a few general types of behavior, specifically the Use Case Diagram, Activity Diagram, and State Machine Diagram; and types that represent the different aspects of interaction (aka “Interaction Diagrams”) — Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
In other words, it shows how the system interacts with external entities and users, how it responds to input or events, and what constraints it operates under. Just an example of an interaction between me and my cat. Lola hysterically meows. It triggers me to put food in her bowl. She eats while keeping the “thank hers”.

Not all of the 14 different types of UML diagrams are used regularly when documenting systems and/or architectures. I’m about to write about the most useful diagrams, in my humble opinion, and will start the series with Class Diagrams.
...

Class Diagram

Since most software being created nowadays is still based on the object-oriented programming paradigm, using Class diagrams to document the software turns out to be a common-sense solution. A Class Diagram describes the structure of a system by showing it’s classes, their attributes, methods, and the relations between them. It’s a vocabulary of the system, a common language between all members of the team.

Structural features (attributes) define what objects of the class “know”. Cat knows her eye color, coat, weight range and is acutely aware of her superiority.

Behavioral features (operations, aka methods) define what objects of the class “can do”. A cat can meow, eat, and poop (a very superficial idea of what a cat can do).

Classes are described as boxes in a Class Diagram. Each box has a title that represents the name of the class. Under the title, there are two sections:

The middle part of the box includes attributes. An attribute notation is attribute:type = defaultValue (optional)

The bottom part includes operations. An operation notation is operation(params):returnType

Following notations allow to specify the visibility of a class member (i.e. any attribute or operation):

We are cool? This is a Cat Class example. Let’s take a look at what we have here:

• “Cat” is a class name (title).
• The Cat has some public attributes, such as “eyes color” of type enum with default value “Yellow” (let’s say), and value object “coat” of type Coat.
• Cats can meow and eat treats in public, however, they prefer to defecate in privacy (operations).

When you create a class diagram, omit not required details. I mean, try to keep the diagram clean, by showing only relevant details. Class diagrams get cluttered really fast. Take a look at the middle part of the box, the displayed attributes are marked as public. It means that other classes have access to these parameters. As a notation, it saves me the need to indicate the obvious getters and setters we’d expect here. Verstehen?
...

Relationships Between Classes

A relationship is a general term covering the types of logical connections found on class and object diagrams. A class may be involved in one or more relationships with other classes or instances.
...

The class-level relationships cover the object-oriented paradigm key-factors: interface implementation (realization) and inheritance (generalization).

Realization (Interface implementation)

In UML modeling, the realization is a relationship between two model elements, in which one model element (the client) implements the behavior that the other model element (the supplier) specifies.

Now, the same stuff in human language. The Cat is a domestic species of the Felidae family. I could say, Cat is a realization of Felidae. Or, in an object-oriented language, Cat is a specific implementation of the Felidae interface.

Note that the interface box has only one part under the title, which includes the operations, which have various implementations.

Class “Cat” implements the “Felidae” interface. We can recognize it by the connecting line between their boxes. The dashed line with a hollow arrow pointing back to the interface that’s being implemented.

Notice that in the Cat box, we are not showing any operations that are part of “Felidae”. Cat implements these operations, no need to duplicate them (keep diagrams as clean as possible, remember?).

Generalization (Inheritance)

Generalization represents a “IS A’’ relationship between a general class (Cat) and a more specific implementation of this class (Cat Breed). Russian Blue is a cat breed, while each specific cat breed acquires all the attributes and operations of a Cat, but also can have it’s own. For, example, cats of the Scottish Fold breed can stand up on their hind legs.

The generalization relationship notated in UML by a solid line with an enclosed hollow arrow, pointing back to the general (base) class.

Another couple of items to keep in mind here is the concept of Abstract and Concrete Classes.

An abstract class is a class that we will never instantiate. In UML, this class’s name should be italicized.

A concrete class is a class that we actually instantiate. It’s a default class, without any special decorations of its title.

...
The next thing we want to look at in our Class Diagram is modeling relationships.

Basic Relationship (Association)

This association relationship is usually described as a “HAS A” relationship. It indicates that at least one of two related classes refers to each other. This relationship is represented simply by a solid line (without an arrow) that connects two classes.

Now, often, it’s important to understand how many items on each side of a relationship can exist, which we call “cardinality”. The cardinality is expressed in terms of: “one to one”, “one to many” and “many to many”. In UML it’s notated as follows:

Take a look at this diagram:

In the current example, a cat has a human (the chosen one, right). The human has few cats (of both Russian Blue (wannabe) and Scottish Fold breeds. True story). It’s a “many to one” relationship.

Aggregation Relationship

Aggregation is a variant of the “HAS A” relationship, however, it’s more specific than an association. Aggregation represents a one-way association, called a “PART-WHOLE” relationship. I mean, one entity works as an owner (a whole) of another (a part of the whole), but the owned classes do not have a strong lifecycle dependency on the owner.

Back to our Cat. Each cat must have a poop-house. So, the implied relationship between “Cat” and “Poop-House” will be a “HAS A” type relationship. But the reverse may not be true. Each poop-house doesn’t need to be contained by any cat. Now it easy to recognize that Cat is an owner entity and this is an aggregation relationship.

In UML, the connecting line has a hollow diamond, pointing to the owner class. Poop-House is strongly related to the Cat.

Composition Relationship

The composition is a “PART OF” relationship, a special type of aggregation, where parts don’t stand on their own so much. The owner class here is a kind of container, and related entities are its contents. All entities are interdependent of each other for example “litter box and clumping litter is part of poop-house”. The house can not exist without the box or the litter, doesn’t it?

Here we have a solid line with a filled diamond, pointing to the owner class.

Uses Relationship (Dependency)

Uses relationship is a little bit softer tied between the classes. This relationship indicates that one class depends on another because it uses it at some point in time.

For example, other family members can communicate with the Cat and the Human (that is not welcomed much by the Cat).

Uses relationship notation is a dashed line with an open arrow, pointing to the used classes. It helps us to understand that changes in Cat or Human can affect Other Family Members, and so we should be careful. We’re good?
...
We are done. Now, let’s check the completed overall view of the basic Class Diagram.

That’s all.

To look at some of the other UML diagrams I wrote about, head on over to my profile.