What is the Unified Modeling Language?

The Unified Modeling Language (UML) is an approach we use to represent and document complex software systems visually. UML diagrams are valuable for developers to document their complete designs. They are especially useful when the codebase of a project is huge, and developers must keep track of all the relationships and hierarchies within that system.

Other than developers, system architects and business analysts also use UML diagrams.

Types of UML diagrams

There are many types of UML diagrams, each with a different purpose. The two major categories of UML diagrams that cover all the other kinds are behavioral and structural. 

Behavioral UML diagrams

These UML diagrams depict the behavior of the system and the way it interacts with other systems. They show the relationships between objects that describe the system's functionality.

The following diagrams are behavioral:

• Activity diagrams

• Sequence diagrams

• Use case diagrams

• State diagrams

• Communication diagrams

• Timing diagrams

Let's take a brief look at each one of them:

Activity diagrams

Activity diagrams illustrate the flow of one activity from another. The operation flow is sequential or branched, and supports concurrent flows. An activity diagram has the notion of object-oriented development and concurrency. Let's look at an example of a log-in system: 

Note: An activity diagram resembles a flowchart, so we must be careful not to confuse the two.

Sequence diagrams

Sequence diagrams show interactions between objects in sequential order. Developers and business analysts primarily use them to understand the project and its requirements. They illustrate how different parts of a system interact with each other, and in what order.

Here's how we make a sequence diagram of a log-in system.

Use case diagrams

Use case diagrams model the functionality of the system, and shows us how users interact in terms of actors and use cases.

Here's a simple description of a use case diagram:

The system or application is marked red, the people or organizations involved in the system's interaction are marked yellow, and the basic flow of the system in terms of use cases is marked green.

We take three things into account when we make a use case diagram:

• Functional requirements: We show these as use cases. Usually, we use verbs to describe the actions.

• Actors: These interact with the system. An actor can be a person, an organization, or another system.

• Relationships: These are between actors and use cases. We represent them using straight arrows or dotted lines.

State diagrams

State diagrams represent the system's condition, or a part of the system at finite instances of time. They illustrate the behavior using finite state transitions. They also show how an entity reacts to various events moving from one state to another. We often use state diagrams to describe the state-dependent behavior of an object. A state diagram is also known as a state machine diagram or a statechart diagram.

Communication diagrams

Communication diagrams, formerly known as collaboration diagrams, are similar to sequence diagrams in nature. Still, they model the messages that pass between objects or roles that deliver the functionality of the use cases within the system.

Timing diagrams

Timing diagrams show us the behavior of objects over a given time frame. Their primary purpose is to indicate the intervals between the state changes of objects. They focus on conditions changing within and among the lifelines along the time axis.

Structural UML diagrams

Structural UML diagrams, as the name suggests, show how the system is structured. They show how the elements of a system relate to each other in terms of classes, objects, components, and so on, and the different relationships between them.

The following diagrams are structural:

• Class diagrams

• Component diagrams

• Deployment diagrams

• Object diagrams

• Package diagrams

• Composite diagrams

Let's take a brief look at each one of them:

Class diagrams

Class diagrams show the system's structure in terms of its classes, attributes, and method. They also show us the relationships that exist among the classes. They were primarily made for developers to understand software requirements and describe detailed designs.

For example, during the analysis and design parts of the development cycle, we can create class diagrams to help us capture the class structure and define the relationships between classes and classifiers.

Component diagrams

Component diagrams represent the physical aspects of object-oriented systems that help us visualize and document component-based systems. These are similar to class diagrams as they focus on the system components used to model a system's static implementation view. Component diagrams break down the system into various functional components, with each responsible for one goal.

Deployment diagrams

Deployment diagrams illustrate the configuration of runtime processing and the components used. They show the physical aspects of the system and the ways of communication. They also show how each part of the system is deployed.

Object diagrams

Object diagrams capture a snapshot of the detailed state of the system, object, and relationships. They are similar to class and component diagrams, except they illustrate a diagram of the instances of classes in the system.

Package diagrams

Package diagrams let us group related elements and visualize the dependencies between them. They help us structure high-level system elements.

Composite structure diagrams

Composite structure diagrams contain interfaces, classes, packages, and their relationships. They are similar to class diagrams, except they let us see the details of the internal structure of the various classes and their relationships.

Wrapping up

The UML is a great way to visualize a project before we start. It can help teams evaluate their workflow process, or see if they can add or remove anything from the system.

The downside of UML diagrams is that it may be difficult for some people to draw them, or to decide which type of diagram best suits their project.