UML diagrams guide

The more complex a system, the more important it is to represent it visually. The process of physically mapping out components makes it clearer what’s working, what’s not, and where there are opportunities for improvement. And using a common language, like UML diagrams, helps teams collaborate on these issues.

This guide will introduce you to the Unified Modeling Language and the diagrams that represent it. In no time, you and your team can utilize UML diagrams for your projects.

This guide is useful for:

  • Anyone interested in visualizing a complex system,
  • System architects, software engineers, and software developers looking for an introduction to UML diagrams, and
  • People wanting to brush up on the fundamentals of UML and updates to UML 2.5.

We have broken things up into three parts.

An overview

What is modeling?

Modeling is a way to visualize your software application design and check it against requirements before your team starts to code.

In the same way an architect creates a blueprint before starting construction on a skyscraper, a developer can use modeling diagrams to solidify and test what they are going to create before they start coding.

Mapping out a plan is the first step to any project, and modeling is an essential part of any software project, small or large. For an application to function well, it must be architected to enable scalability, security, and execution.

Using Unified Modeling Language (UML) diagrams, you can visualize and verify the designs of your software systems before code implementation makes changes difficult and expensive to execute.

What is the UML?

According to the Scope of the latest version of UML 2.5’s specification documentation, “the objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.”

UML itself is not a programming language, though there are tools that can generate code using UML diagrams. UML is a modeling language for designing systems. It was created by combining several object-oriented notations—Object-Oriented Design (i.e., Booch), Object Modeling Technique (OMT), and Object-Oriented Software Engineering (OOSE)—making it a natural fit for object-oriented languages and environments like C++, Java, and C#; however, you can also use it to model non-OO applications in languages like Fortran, VB, or COBOL.

Because UML establishes a standard semantic and syntactic structure, you can use it to model almost any type of application, regardless of your hardware, operating system, programming language, or network. UML allows you to specify, visualize, and document models of software systems both structurally and behaviorally before coding.

History

UML was developed by Grady Booch, Ivar Jacobson, and James Rumbaugh (aka ‘The Three Amigos’) in the mid-90’s. The initial versions of UML were created by integrating three of the leading object-oriented methods—namely Booch, OMT, and OOSE developed by UML’s founders, respectively. It also incorporated best-practices from modeling language design, object-oriented programming, and architectural description languages. The result of their efforts led to the release of UML 0.9 and 0.91.

In 1996, The Three Amigos led a consortium called the UML Partners to complete the UML specification. The partnership included several important individuals and organizations, including HP, DEC, IBM, and Microsoft. The resulting UML 1.1 was proposed to the Object Management Group (OMG) for standardization and adopted in November 1997. OMG has managed the language ever since.

With the help of an even larger consortium, UML 2.0 was introduced in 2005 and published as an approved standard by the International Organization for Standardization (ISO). After the release of several more versions, the current version, UML 2.5, was released in October 2012 as an “In process” version that was officially released in June 2015.

You can download the complete UML 2.5 document here.

Benefits

Modeling your software before you build it provides a number of benefits to teams. For one, it helps establish a logical order of a team’s activities. Knowing what artifacts need to be developed helps define the tasks that teams will need to complete. And modeling helps your team establish criteria for monitoring and measuring a project’s products and activities.

While some people might worry that using UML diagrams could lock them into a waterfall style of software development, that isn’t necessarily true. UML diagrams can be created and used at various stages of development, and they can be continuously updated and iterated on.

Other key benefits include:

  • Reducing redundancies. Diagrams make it easier for programmers to see redundant code and reuse portions of code that already exist rather than rewriting those functions.
  • Simplifying changes. Making changes to diagrams at the start is much easier than reprogramming code later. It saves your team valuable time and money.
  • Clarifying ambiguity. You can only go so far with design documentation. In the long run, you’ll need it to communicate with new or far away developers unfamiliar with the history of your product.

Why UML?

UML is the most widely used and understood modeling language. UML is, by far, the most popular modeling language used today. That ubiquity is itself a benefit because most developers, regardless of their specialties or work history, will be familiar with at least some UML diagrams. And because they are meant to be understood by any type of programmer, they don’t require the ability to read a certain programming language to be useful.

Three of the most popular UML diagrams will cover most of your modeling needs. Though there are 14 different types of UML diagrams for modeling applications, in practice, developers only use a few to document their software systems. The most common UML diagrams you’ll see and use are class diagrams, sequence diagrams, and use case diagrams. That means knowing how to create and read only 20% of this language will suffice for most of your projects.

Types

As of UML 2.5, there are now fourteen officially recognized UML diagrams which are split into two main types:

1. Structure diagrams show how the static parts of a system relate to each other. Each element represents a particular concept and may include abstract, real-world, and implementation factors.

2. Behavior diagrams show the dynamic behavior of all objects in a system, including changes to the system over time. Interaction diagrams can be thought of as a subset of behavior diagrams.

UML 2.5 Diagrams

 

Structure diagrams

There are seven structure diagrams in UML 2.5:

  1. Class diagrams show the structure of a system as related classes and interfaces with their features, constraints, and relationships.
  2. Component diagrams show components and the dependencies between them.
  3. Composite structure diagrams show the internal structure of a classifier and the behavior of collaborations the structure makes possible.
  4. Deployment diagrams show a system’s various hardware and the software deployed on it.
  5. Object diagrams show a real-world example of a structure at a specific time.
  6. Package diagrams show packages and the dependencies between those packages.
  7. Profile diagrams show custom stereotypes, tagged values, and constraints.

Behavior diagrams

There are also seven behavior diagrams, the last four of which fall under the interaction diagram subset:

  1. Activity diagrams show business or operational workflows of components in a system.
  2. Use Case diagrams show how functionalities relate under particular actors.
  3. State machine diagrams show the states and state transitions of a system.
  4. Communication diagrams* show the interactions between objects in terms of sequenced messages.
  5. Interaction overview diagrams* show an overview of the flow of control with nodes that represent interactions or interactions uses.
  6. Sequence diagrams* show how objects communicate and the sequence of their messages.
  7. Timing diagrams* show timing constraints of a system in a given time frame.

*Interaction diagrams

Creating UML diagrams

As we mentioned in the previous section, though there are 14 different types of UML diagrams, developers typically use just a few to cover most of their modeling needs. In this section, we’ll discuss how to create activity diagrams, class diagrams, sequence diagrams, and use case diagrams.

Templates and shapes for these and more UML diagram types are available in Cacoo.

Activity diagrams

Actions are tasks performed by a user, the system, or both in collaboration.

Connectors link the actions in sequence.

Nodes indicate the start or end of an activity. They can also indicate a fork or merge.

Activity Diagram

 

How to create an Activity Diagram in Cacoo:

  1. In the Cacoo editor, go to Templates and select the Activity Diagram template.
  2. Use round-edged rectangles to represent each action.
  3. Use lines to demonstrate the flow of actions from one to another.
  4. Use a circle to indicate the end of an activity.
  5. Optionally, arrange actions into swimlanes corresponding to different objects or business roles that perform the actions.
  6. Save your diagram.

Class diagrams

Classes represent data or object types. They are visualized using a rectangular shape with the class name as the top section.

Attributes are the named values that every instance of a type can have. They are listed under the class name.

Methods are the functions that instances of a type can perform. They are listed below attributes.

Class Diagram

How to create a Class Diagram in Cacoo:

  1. In the Cacoo editor, go to templates and select the Class Diagram template.
  2. Add all classes, attributes, and methods.
  3. Add new class shapes as necessary to fit your data.
  4. Use lines to draw any associations, inheritances, or dependencies between types. Your notation style will determine the styling of these lines.
  5. Save your diagram.

Sequence diagrams

Classes represent data or object types. They are visualized using a rectangular shape.

Lifelines are vertical lines that represent the sequence of events that occur to a participant as time progresses. This participant can be an instance of a class, component, or actor.

Messages are represented by lines between objects.

Sequence Diagram_1 Sequence Diagram_2

How to create a Sequence Diagram in Cacoo:

  1. In the Cacoo editor, go to Templates and select the Sequence Diagram template.
  2. Use rectangular boxes to indicate class instance names, class names, or objects.
  3. Use vertical lifelines to show sequences of messages in chronological order and horizontal elements to show object instances as messages are relayed.
  4. Draw lines to represent the sender and receiver of messages. Use solid arrowheads to symbolize synchronous messages, open arrowheads for asynchronous messages, and dashed lines for callback messages.
  5. Save your diagram.

Use case diagrams

Actors represent users, organizations, or external systems that interact with your application or system. An actor is a kind of type.

Use Cases represent the actions performed by one or more actors in the pursuit of a particular goal. A use case is a kind of type.

Associations indicate where an actor takes part in a use case.

Use Case Diagram_1 Use Case Diagram_2

How to create a Use Case Diagram in Cacoo:

  1. In the Cacoo editor, go to Templates and select the Use Case Diagram template.
  2. Label your actors with stick figures (which can be found under Stencils > Software > UML) or other relevant illustrations.
  3. Use ovals to label your use cases.
  4. Use lines to model the relationships between actors and use cases.
  5. Save your diagram.

Custom templates & shapes

While creating UML diagrams from scratch is easy with Cacoo, using templates can greatly speed up your diagramming process.

There are many different types of UML diagram templates to choose from in Cacoo. Simply open the editor, choose a template to get you started, and begin customizing it to your flow.

If you create a diagram you think you’ll want to replicate, save it as a new template or stencil. With custom templates and stencils, you can recreate your best work again and again.

Advanced tips & tricks

Best-practices

When sharing your diagrams with others, you want to make sure they’re easy to understand, clean, and follow consistent rules. These factors won’t change your actual model, but they will greatly improve your ability to communicate your system and goals to your team.

Keep fonts & colors to a minimum

Readability is important for understanding. When viewing your diagram, all text should be large enough to be legible. If the text can only be read when zoomed in, your diagram has too much information or is too complicated.

Also, don’t try to get too fancy with fonts. Generally, you can stick to one font type. If you feel confident in your typography skills, you can venture into two or even three, but never add fonts just for the sake of looks. If your designs aren’t adding to the readability of your diagram, they’re taking away from it.

Colors can be a great way to show differentiation in your diagram. It can increase readability and make your diagrams look more professional. However, when taken too far, color can distract your reader from the information at hand or even confuse the reader if not applied uniformly. When using color, think sparingly. Try to stick to the least number of colors necessary to bring clarity to your diagram. It can also be useful to provide a key or legend for colors.

Less information is more useful

Diagrams should focus on just a few key elements with a limited perspective. If you try to include too many elements in your diagrams, they can quickly grow so large and complex that they become too difficult for anyone to actually read.

Large diagrams don’t convey more information; they create more confusion. For complex systems, split information up into smaller, more easily digestible diagrams.

When thinking about how much information to include or exclude, imagine what your diagram would look like printed out on a standard sheet of paper. If it would be too difficult to read, scale back and try again.

You also don’t have to name every attribute, association, or constraint contained within a diagram. Only display items that are relevant to the current perspective of the diagram. That information can be elaborated on within a separate diagram.

Lines should never cross

No two lines in your diagram should cross. This is important not only for clarity but to ensure that your system does not contain a design flaw.

If you are unable to uncross two or more lines on your diagram, you either have:

  1. Too much information in one diagram. Maybe you’re trying to combine two different perspectives, or you’re just trying to go too in-depth for a single diagram. Remember, less information is often more useful.
  2. A design flaw in your model. The worst case scenario is that your system contains a design flaw, but it’s better to figure that out now than later. All working systems can be displayed without crossing lines. If you’re finding it a challenge to visualize your system, try figuring out if there’s an element you’ve overlooked.

 

Use right angles

All lines in your diagrams should run either horizontal or vertical. All angles should be right angles. Straightening out your lines will instantly add clarity to your diagrams.

The only exception to this rule is use cases, which sometimes use angled lines to represent relations.

Parents over children

When drawing hierarchies on a diagram, always place parent elements higher than child elements so that arrows will always point upwards.

Most follow this rule without even learning it, but every once in awhile, someone tries to flip their hierarchies upside down. For consistency’s sake, always put parents first. Your reader shouldn’t have to orient themselves to new rules to understand your flow.

If you have multiple elements descending from the same parent, use a vertical tree style to demonstrate your hierarchy.

Keep it consistent

Consistency extends beyond fonts and colors. When you’re done with your diagram, run a quick check to make sure you’ve treated every element equally.

  • Always double check to make sure your elements are aligned, either by one side or by their centers.
  • Make sure elements of the same type are the same size, when possible.

UML diagrams are only as useful as they are readable. If your audience doesn’t understand them, you’ve wasted everyone’s time. Following these rules will ensure that you’re delivering organized, clean diagrams that any team member can pick up and understand.

Why choose Cacoo?

Cacoo is simple to use, easy to learn, and built with collaboration in mind.

Using our cloud-based editor, your team can collaborate on diagrams in real-time. With in-app comments right on diagrams and our presentation mode, you can get easy feedback to refine your work. Shared folders give your team gets access to all the diagrams they need. And sharing diagrams with important stakeholders takes seconds (no downloading or account creation required on their part).

You can create all kinds of professional diagrams; not just UML diagrams, but wireframes, sitemaps, network diagrams, flowcharts, and more.

Our Team plan gives you:

  • Advanced exporting options (PNG, PDF, PPT, PostScript, or SVG)
  • Revision history (see what changes were made and when)
  • Full access to integrations (including Google Drive, Dropbox, Adobe Creative Cloud, and more)
  • Team management (invite people to your Organization, create groups, and assign roles)
  • Advanced security (manage access to diagrams, so you know exactly who’s seeing them)

Try it out for yourself with our 14-day free trial. No credit card required.

We also offer a Plus plan for those who don’t need our more advanced collaboration features but are still interested in the joining the 2.5 million users who depend on Cacoo for their diagramming needs.

Ready to start wireframing?

Join the 2,500,000 users who choose Cacoo

Get Started