Unified Modelling Language (UML) plays a big role in software development, but also in non-software systems throughout many industries, as it’s a way to visually show the behaviour and structure of a system or a process. UML helps showcase potential errors in application structures, system behaviour and other business processes.
UML first came on the scene back in the 1990s thanks to three software engineers – Grady Booch, Ivar Jacobson and James Rumbaugh – because they wanted to develop a less chaotic way to represent increasingly complex software development, while also separating methodology from process. Today, UML is still the standard go-to notation for developers, as well as project managers, business owners, tech entrepreneurs and professionals across industries.
What are the benefits of UML?
- Simplifies complexities
- Keeps lines of communication open
- Automates the production of software and processes
- Helps resolve persistent architectural problems
- Increases quality of work
- Reduces costs and time-to-market
Types of UML diagrams
There are two major types of UML diagrams: structure diagrams and behavioural diagrams (and within those categories lie multiple others). These variations exist to represent the numerous types of scenarios and diagrams that different types of people use.
From customers and project managers to technical authors, designers, analysts, coders and QA testers, each role will utilise a specific diagram to suits their needs. This means that each layout requires a different focus and level of detail. The goal is for UML to visually express diagrams that are easy for everyone to understand.
Let’s take a closer look:
Structural diagrams represent the static structure of software or a system, and they also show different levels of abstraction and implementation. These are used to help you visualise the various structures that make up a system, like a database or an application. They show the hierarchy of components or modules and how they connect and interact with each other. These tools offer guidance and ensure that all parts of a system work as intended in relation to all the other parts.
The focus here is on dynamic aspects of the software system or process. These diagrams show the functionality of a system and emphasise what must happen in the system being modelled.
Let’s take a closer look at the many different types of UML diagrams that fall under each category:
1. Structural UML diagrams
- Class diagram. This diagram, the most common type in software development, is used to depict the logical and physical design of a system and shows its classes. It looks similar to a flow chart because the classes are represented with boxes. This diagram offers a visual of the different classes and how they are interrelated, and each class has three compartments:
- Top section: class name
- Middle section: class attributes
- Bottom section: class methods or operations
- Object diagram. Often, this diagram is used as a way to double check a class diagram for accuracy. In other words, will it work in practice? It shows a system’s objects and their relationships and offers a better view of potential design flaws that need fixing.
- Component diagram. Also known as a component flow diagram, it shows logical groupings of elements and their relationships. In other words, it gives a more simplified view of a complex system by breaking it down into smaller components. Each of the pieces is shown using a rectangular box, with its name written inside. Connectors define the relationship/dependencies between the different components.
- Composite structure diagram. This is seldom used by anyone outside the software development field. Why? While it’s similar to a class diagram, it takes a deeper dive, describing the internal structure of multiple classes and showing the interactions between them. Unless you’re a developer, a top-level view is probably enough information.
- Deployment diagram. This diagram shows hardware (nodes) and software (artifacts) components and their relationships. It offers a visual representation of exactly where each software component is deployed.
- Package diagram. This is used to depict the dependencies between the packages that make up a model. The main goal is to show the relationship between the various large components that form a complex system.
- Profile diagram. This is less like a diagram and more like a language. A profile diagram helps create new properties and semantics for UML diagrams by defining custom stereotypes, tagged values and constraints. These profiles let you customise a UML metamodel for different platforms (e.g. Java Platform, Enterprise Edition (Java EE) or Microsoft .NET Framework) and domains (e.g. business process modelling, service-oriented architecture, medical applications and more).
2. Behavioural UML diagrams:
- Activity diagram. This depicts a step-by-step process with a clear beginning and end. It’s a set of activities that must happen to reach a goal. It shows how each activity leads to the next and how they are all connected. Aside from software development, these can be used in just about any business environment. They are also referred to as business process mapping or modelling.
- Use-case diagram. This describes what a system does but not how it does it. A use case is a set of events that occurs when an “actor” uses a system to complete a process. An actor is defined as anyone or anything that interacts with the system (person, organisation or an application) from outside the system. So, a use case diagram visually describes that set of sequences and represents the functional requirements of the system.
- Interaction overview diagram. Often complex, this diagram is similar to the activity diagram since both show a step-by-step sequence of activities. But an interaction overview diagram is an activity diagram made of different interaction diagrams. They use the same annotations as an activity diagram (initial, final, decision, merge, fork and join nodes) with the addition of elements such as interaction, interaction use, time constraint and duration constraint.
- Timing diagram. When timing takes centre stage, this UML diagram is used. Also known as a sequencing or event diagram, it doesn’t show how objects interact or change each other. Functionally, it shows how objects and actors act along a timeline. The focus here is on how long events take and the changes that occur depending on the duration constraints. The main parts of a timing diagram include:
- Lifeline: individual participant
- State timeline: different states the lifeline goes through within a pipeline
- Duration constraint: time needed for a constraint to be fulfilled
- Time constraint: a time in which something needs to be fulfilled by the participant
- Destruction occurrence: where an object’s lifeline ends. No other occurrence will appear after the destruction occurrence on a lifeline.
- State machine diagram. Also called a state chart, this diagram applies when an object’s behaviour is complex, and detail is of the essence. It helps describe the behaviour of one object (or sometimes an operator) and how it changes based on internal and external events.
- Sequence diagram. Popular beyond just the design community, this visually appealing diagram is good at showing all types of business processes. It simply reveals the structure of a system, showing the sequence of messages and interactions between actors and objects chronologically. Sequence diagrams show simple iteration and branching. It is favourable for multi-tasking.
- Communication diagram. A communication or collaboration diagram is similar to a sequence diagram. However, it emphasises the communication between objects. It shows the organisation of the objects that participate in an interaction and features more complex iteration and branching.
UML has also been gaining popularity as a notation for modelling databases. These models are a great visual tool for brainstorming, free-form diagramming and collaborating on ideas.
While UML does not have specifications for data modelling, it can be a useful tool for diagramming, especially since data from databases can be used in object-orientated programming.
Let’s take a look at the different types of database models you can create:
- Hierarchical database model. An oldie but a goodie, this model’s data is organised in a tree-like structure. The tree is made up of several groups called segments. It uses a one-to-many relationship. The data access is also predictable.
- Network model. This model takes the form of a graph, where relationship types are arcs, and object types are nodes. Unlike other database models, the network model’s schema is not confined to as a lattice or hierarchy.
- Object-orientated database model. This model uses a collection of objects, or reusable software elements, with associated features and methods. For example, a multimedia database could have images that can’t be stored in a relational database. Or a hypertext database allows linking to other objects.
- Relational model. Here, data is structured using relations, or grid-like mathematical structures that have columns and rows. It’s basically a table.
- The object-relational model. As the name implies, this model is a combo of the two mentioned above. It supports objects, classes, inheritance and other object-orientated elements, but also supports data types, tabular structures and more–like in a relational data model.
- Entity-relationship model. This is composed of entity types (people, places or things). It shows relationships that can exist between them. By defining the entities, their attributes and showing the relationships between them, an ER diagram illustrates the logical structure of databases.
- Document model. It’s designed for storing and managing documents or semi-structured data, rather than atomic data. It has a tree structure in which each node is an object representing a part of the document.
- Entity-attribute-value model. EAV or open schema models, data is recorded as three columns:
- The entity (what’s being described)
- The attribute or parameter (e.g. name, description, data type)
- The value of the attribute.
- Star schema. This is the simplest version of a dimensional model, in which data is arranged in dimensions and facts. It’s used in business intelligence and data warehousing since it’s suitable for querying big data sets.
Simplifying with software
Whether you’re creating database models or UML diagrams, using a software tool simplifies and improves the process. Be sure to choose one that lets you:
- Create professional diagrams with ready-made templates and thousands of shapes in a content ecosystem that meets industry standards like UML 2.5, but also BPMN 2.0 and IEEE.
- Bring diagrams to life with data overlay, icons, colours and graphics to make the data easier to digest, including one-step Excel data visualisation.
- Collaborate with others using co-authoring, commenting and annotation.
- Communicate one version of the truth and access diagrams from nearly anywhere in a browser or device applications.
In software development and non-software systems throughout many industries, using visual UML diagrams can play a vital role in the success of building behavioural processes and structures. Learn more about creating UML diagrams with software with this step-by-step guide.