Unified Modeling Language, or UML, is a visual language that helps software developers visualize and construct new systems. It’s not a programming language — it’s a set of rules specifically for drawing diagrams. Think of it like the software engineer’s version of a blueprint.
History of the Unified Modeling Language
Grady Booch, Ivar Jacobson, and James Rumbaugh created the Unified Modeling Language in 1995 while working at Rational software. In 1997, the Object Management Group adopted UML as a standard for its members, which includes the likes of Hewlett-Packard, IBM, and Apple Computer. With interoperability in mind, this ensured that UML would be a shared visual language for years to come.
In 2005, the language was published by the International Organization for Standardization (ISO) and has since been revised and reviewed to keep it up to date. The most recent version, UML 2.5, was released in 2015.
Today, UML diagrams are less popular because many software teams now work in an Agile environment, but there are certainly reasons to use a UML diagram.
Why Software Engineers Use UML Diagrams
When it comes to building new products or systems, there are two key reasons to add a UML diagram to your toolkit.
1) Better Ideation and Collaboration
Before developers start coding, UML diagrams can help everyone get on the same page. Understanding the system they’re trying to create allows developers to delegate work, identify potential problems before work has started, and work efficiently toward a common goal.
2) Clearer Documentation of Workflow or Project Structure
After code is written, a UML diagram can help developers understand the decisions made and structures developed for the project. This information helps teams as they look to improve upon the project for the future.
Types of UML Diagrams
UML Diagrams fall into three categories: structure diagrams, behavior diagrams, and interaction diagrams. As their names might imply, behavioral diagrams capture the behaviors of a system, structure diagrams describe the static elements of a system, and interaction diagrams model the exchanges of information and interactions between elements in a system.
Some engineers consider interaction diagrams to be a subset of behavioral diagrams, with their distinguishing characteristic being that behavior diagrams will show changes to a system over time or how information flows from one point to another, while interaction diagrams will show more complex relationships. Interaction diagrams capture information exchange between multiple elements in the system.
Types of Behavioral UML Diagrams:
Activity Diagrams: Think of these like a flowchart converted into UML language. Activity diagrams show how a process works so that you can get your whole team on the same page.
Use Case Diagrams: These show how your system’s users or actors interact with what you’ve built. A use case diagram can help you make sure your application or system is easy to use.
State Diagrams: States are the combinations of information that an object can hold, so a state diagram visualizes those possible variations.
Types of UML Interaction Diagrams:
Sequence Diagrams: These diagrams detail the way that objects interact with each other, but more specifically focus on the order of those operations or interactions.
Communication Diagrams: These used to be called collaboration diagrams and focuses on the information shared through interactions.
Timing Diagrams: These show how objects interact with each other during a specific timeframe.
Interaction Overview Diagrams: Similar to activity diagrams, interaction overview diagrams capture the “flow” through a system. But, while activity diagrams show behaviors, these capture the high-level interactions of a system.
Types of Structural UML Diagrams:
Class Diagrams: As the most common type of UML diagram, class diagrams show static structures within a system and help developers plan the name, operations, and attributes of each class.
Object Diagrams: Object diagrams show how data looks within your structure at a specific moment in time. They’re similar to class diagrams, but instead they use an example to exemplify the system.
Package Diagrams: These illustrate the packages in a system as well as the dependencies between them. Packages look like a file folder, and each one can contain multiple classes.
Composite Structure Diagrams: These map out the internal components of hardware—sort of like a blueprint.
Component Diagrams: Like class diagrams, component diagrams show the structure of your system, but they’re specifically used to diagram the relationships and processes between components in a system.
Deployment Diagrams: Deployment diagrams focus on how hardware supports and carries the software your team develops. If you’re a systems engineer, this one will come in handy.
Profile Diagrams: These are used to define stereotypes or tagged values within a platform or domain.
Make Your Own UML Diagram
Now that you know what UML is and what it’s used for, why not give it a go? Check out How To Make a UML Diagram or dive right in to a free trial of Gliffy.