A Simple Guide to Process Modeling & Optimization with UML Diagrams | Process Street | Checklist, Workflow and SOP Software

Unified Modeling Language (UML) is a way of visualizing a software program using a collection of diagrams. That is one of the simplest ways to define it.

In equally simple terms, it is a modeling language used to analyze, design and implement software-based systems.

However, UML diagrams can be applied to more than just software engineering and development.

There are over a dozen types of UML diagrams that are used for a range of different purposes and have significant variances in complexity.

One of the simplest types, which also happens to be the most suitable diagram for modeling business processes, is called the activity diagram.

This is the diagram we will be focusing most of our attention on in this post, though we will take a quick look at some of the other common types for the sake of context and because you may also find them useful beyond the purpose of process modeling & optimization.

As I mentioned in my UML tutorial, although the language has many advantages including flexibility, an abundance of tools, and the capacity to model systems from both a structural and behavioral perspective, it can be overwhelming due to the sheer complexity and range of capability that is offers.

Despite its complexity, UML does not need to be leveraged in a complicated fashion for it to be useful. In fact, one of the men who created the language believes it should be used rather casually.

So it is important to keep things as simple as possible if you want to model actionable diagrams that can be internalized by your team and evaluated accurately by managers for effective process optimization.

Let’s now go into a brief history of UML, look at the various types of diagrams, provide a step-by-step guide to creating activity diagrams and guidance on how they can be used to optimize processes and improve team performance.

The seeds for a modeling language like UML were being planted way back in the 1960s, when Norweigan computer scientists Ole-Johan Dahl and Kristen Nygaard developed what is generally acknowledged to be the first object-oriented language, Simula-67. This language never had a large following but sparked major inspiration for later languages.

During the 1980s, software engineers were becoming increasingly keen to establish a simplified and more consistent way to model systems, and object-oriented programming languages grew increasingly complex.

Between 1989 and 1994, the number of object-oriented methods increased from fewer than 10 to more than 50.

Ideas really started to materialize in the mid 1990s when Grady Booch, James Rumbaugh, and Ivar Jacobson began to consolidate ideas from each other’s methods, and set out to create a unified modeling language that would allow software engineers to evolve together rather than working on different languages, bring stability to the object-oriented marketplace, and encourage collaboration that would yield further improvements to the language for all users.

The UML effort started officially in October 1994, with the version 0.8 draft being released in October 1995. The Three Amigos, as they are sometimes referred to (Booch, Rumbauch, and Jacobson) had successfully unified semantics and notation, ultimately meaning that users could focus on their own work and worry less about the specifics of a given method.

Throughout the next decade, the language continued to develop, and it soon became clear that several industry-leading organizations including Microsoft, Oracle, and IBM saw UML as critical to their own business development.

From 2000 to 2003, a new and expanded set of partners produced an updated specification of UML, version 2.0. This was officially adopted by the Object Management Group (OMG) in 2005, and is a major revision of UML 1 that includes a large number of additional features.

The most important takeaway when considering the history of UML is that it is the work of a large number of individuals over the course of many decades. Once a fragmented area of software development that had over 50 methods developed by different engineers, the three amigos were able to consolidate them into a unified language that is still being improved and continues to be a critical method for both software and process modeling in the enterprise community.

Structural diagrams are for representing the static aspect of the software system. As the name suggests, they are designed to illustrate the system’s underlying structure. The 4 main types of structural diagrams are:

By far the most commonly used is the class diagram. From a software development perspective, it is one of the most useful UML diagram types because it clearly maps out the structure of a system by modeling its classes, attributes, operations, and relationships between objects.

Below is an example of a class diagram for a hotel management system.

In other words, it provides both a detailed insight and a quick, big-picture overview of a system’s structure, making it the most widely used diagram at the time of system construction.

Behavioral diagrams, on the other hand, visualize, specify, construct, and document the dynamic aspects of a system.

The 5 types of behavioral diagrams are:

A use case diagram is designed to demonstrate how users might interact with a system. Users (also known as actors) include people, organizations, or external systems. Use case diagrams are not intended to be complicated, but rather to give a clear picture of how users are interacting with a particular system and whether or not those interactions are happening as intended.

Sequence diagrams are used to show how objects communicate and in what sequential order. They are perhaps the most commonly used interaction diagram.

Activity diagrams are also very popular, and are just what we need for modeling business processes because they are the only type of UML diagram that accounts for the flow of actions.

Business process modeling is the act of documenting the series of steps and actions taken within a business process. This involves:

The activity diagram, also known as a swim-lane diagram or cross-functional flowchart, describes how a set of activities are coordinated to provide a service.

It is the most suitable diagram for business process modeling as it neatly illustrates the flow of a process from activity to activity. It is essentially an advanced version of a flow chart, making it an ideal tool to represent all kinds of business workflows.

Below is an example of an activity diagram illustrating a typical process for hiring a car. For a 10-step guide to completing a simple activity diagram like this one, check out my tutorial.

A recent study found that just below 20% of completed activity diagrams are actually used.

Once they have been created and reviewed by software engineers and senior management, activity diagrams often fail to be applied to improving current processes. But why waste your time and energy creating a model that ultimately has no impact on business performance?

With a simple business process management tool like Process Street, you can implement your UML diagrams by instilling the process in a checklist. We have hundreds of pre-made templates to choose from to help you get started.

Process Street’s workflow software enables you to easily convert your UML activity diagrams into actionable checklists.

By documenting your workflows in digital checklists, you are instantly creating an actionable workflow in which tasks can be assigned to team members, automated, and monitored in real-time to ensure they are being executed as intended, each and every time.

You can also connect your checklists with other tools in your tech stack through our Zapier integration which connects Process Street with over 1000 other applications.

One of the most important components of an activity diagram is the decision node, and Process Street offers an ideal feature to account for decisions made as your team progress through a checklist.

It’s called conditional logic, and with it you can create truly dynamic checklists that adapt to the unique needs and circumstances of your organization.

As various decisions are made throughout the progress of a certain workflow, the checklist will automatically adapt to the situation and present only relevant tasks.

In the context of UML, when a decision node in your activity diagram is reached, the process will branch out to different activities (tasks) depending on which decision is made.

So, once you’ve got the diagram embedded in a checklist that is being utilized by your team, managers can begin to monitor performance more closely and identify opportunities for process optimization.

However, although process optimization initiatives may seem like a project reserved for managers, it is absolutely essential that employees following the process on a daily basis are involved in the decision-making process when it comes to evaluating and improving workflows.

According to Salesforce research, employees who feel their voice is heard are 4.6 times more likely to feel empowered to perform their best work, while another study indicates that organizations with high employee engagement outperform those with low employee engagement by 202%.

As I mentioned in my article on involving employees in process design, the following points are my top tips for creating a collaborative working environment that yields quality results and maintains a high level of morale throughout the team.

Once you’ve established a solid method for involving your employees and discussing ways to optimize processes, there are a few key questions that should be addressed every time a process is formally reviewed. From a managerial perspective, these questions should be considered every day while overseeing performance.

By discussing these simple questions with team members on a regular basis and formulating clear action items to make adjustments, processes can be continuously optimized so it is well understood by all users and produces the best results possible.

We also have a handy checklist for recording process optimization initiatives that you can immediately add to your checklist library and start using today.

Let me know how you think UML diagrams, in particular the activity diagram, can be best applied to modeling and optimizing business processes. What steps do you and your team take to make sure processes are being executed as efficiently as possible?