UML Activity Diagram: Elevate Your Process Flows

Dan Hughes
February 7, 2022
Person-in-the-mountains

I have covered some high-level solution architecture diagrams in prior articles - Solution User Diagram for Rapid Scoping, Master the Conceptual Solution Architecture Diagram, and Information Flow Diagram: Go with the Flow!

I am now going to start my journey into some more design diagrams, starting with my go-to for process flow diagrams: a UML Activity Diagram. I "lean in" to standard notations for all our more detailed solution architecture views.

Why use UML?

If you follow our blog, you will be aware that I am a proponent of aligning with industry standards. The Unified Modeling Language (UML) is our standard of choice when it comes to diagrams. The UML standard is a general-purpose modeling language used in software engineering.

There are many benefits to selecting an industry-standard diagramming notation like UML.

  1. Decades of research and "test and learn" have refined and optimized the approach.
  2. You can find plenty of training, books, and google-able knowledge related to it.
  3. It is a skill that exists in the marketplace, which means you bump into people who already know it (which is unlikely with your DIY notation). Plus, there is a market value to you learning it.
  4. There is a rich set of available tools for modeling and diagramming using it

What is a UML Activity Diagram?

UML-activity-diagram

One of the great things UML does is separate concerns into fit-for-purpose diagrams, resulting in a set of notations. Each is best suited for a particular purpose. The UML Activity Diagram is a behavior diagram notation that puts just the right amount of formality into a flowchart-like view. Solution architects use it to:

  • Understand the business processes related to a solution that they are designing
  • Facilitate future state process design as part of a new solution architecture
  • Figure out and document system processing activities within or across systems
  • Explain the processes related to solution design (e.g., the design of the design process)

UML Activity Diagram Notation

A UML activity diagram depicts workflows of stepwise activities and actions, including support for choice, iteration, and concurrency.

Initial Node. (aka. BEGIN) The initial node is where the flow starts when performing the activity. Every UML Activity Diagram must have 1, and only one, of these. This enables your readers to identify where your flow begins.

Activity Final Node. (aka. END) The final node is where the activity ends. I call it the "donut" when introducing new readers to the diagram notation. Every UML Activity Diagram must have 1, and only one, of these. Like the initial node, this enables your readers to identify where your flow begins. Having a single entry and exit point also makes it possible to next one activity within another; we will cover that in the advanced class.

Action. The belle of the ball. Describes the step that is being performed using a verb + a domain-specific noun (aka. ”Use Case naming convention “, like “Open Account”).

Control Flow. This directional line connects nodes, actions, decisions, forks, and joins to indicate the order of performing the actions. The arrow indicates the direction of the flow. Your reader starts at the solid circle (initial node) then follows the arrows from action to action until they arrive at the donut.

Decision. Formally called a “Decision Activity.” A single flow enters, and two flows exit. You label the exit flows with bracketed “guards.” If a guard is false, the flow shall not pass! Thus, the flow continues only through the guard that is true.

A decision can only have 2 exits. This forces every decision to be binary, with each path being the logical opposite of the other. This approach avoids flows that break due to incomplete logic. If you are deciding based on color and have "red" and "not red," then even green has someplace to go ("not red"). The process breaks if you have "red" and "blue" and the color is green. Hence the value of binary paths!

Merge. A flow splits at a decision is rejoined with a “merge.” Which looks exactly like a decision, except two flows enter and one exits.

Note. Pretty self-explanatory. Used during drafting to capture open questions and when publishing to provide clarifications. It should be used very sparingly on completed diagrams. Too many notes on a complete diagram either means that you aren't really done or that you need a different or additional diagram.

Flow Final Node. A final flow node is where a flow ends. Consider it an “early exit” or exception for the activity. Don't use these when you are too lazy to re-layout your diagram so no lines cross. Use it when an exception case causes an early exit from the flow. I told a bit of a fib above. Your reader may also end up at a flow final node when following the arrows. Although not very often, because you shouldn't be using them very often.

UML Activity Diagram Tips

  1. Always start with the title. If you follow my diagramming series, you are probably tired of hearing it. For the amount of effort it takes, the title brings substantial value! Check Tip #1 of my 5 Tips for Better Solution Architecture Diagrams for details.
  2. Align your actions (including decisions and merges) horizontally and vertically as much as possible. It just looks cleaner.
  3. Keep your action labels short (2-3 words) and use use case naming convention, as described above.
  4. The binary nature of decisions means that you may have to stack decisions if you have more than two outcomes to a decision. It may seem awkward at first but it results in some excellent precision in your flow logic. So remember, one in, two out for decisions and two in, one out for merges! Your finished diagram should always have the same number of decisions and merges.
UML-Activity-Diagram-decision-and-merge-sample

My Activity Final Node

My overview of the ends here, although I have not exhausted everything I wanted to share so, worry not, the UML Activity diagram shall return! Sometimes solution architects wonder what they should be concerned with process, so I figured I'd wrap this up by sharing some activity diagramming I have done in just the past week (not including the fine samples in this article).

  • Some diagrams of a commercial lending process so I can understand the client's process before designing a solution
  • An onboarding process for managing applications in an enterprise architecture repository
  • Processing logic for a complex MDM (Master Data Management) design to clarify some concerns related to customer matching

As with all diagram notations, once you get a few diagrams under your belt you can shift your focus from the diagram to the process you are diagramming and the diagram becomes a great thought tool. So get going!!

Dan is the founder of Wittij Consulting. Prior to founding Wittij, he spent a decade in software development before moving into IT architecture, where he created an Open Group recognized architecture method and led delivery of all services for a company specializing in enterprise and solution architecture for 15 years. He is an energetic, thoughtful leader with an ability to engage and motivate people, and has been called a “force multiplier” for his ability to not only deliver great value, but also increase the value and capability of the people around him. Dan is a strong facilitator, able to understand and resolve complex disagreements with diplomacy. He comprehends and communicates clearly both at the detail level and the boardroom summary level to both business and technical audiences. His knowledge of enterprise techniques and technologies is broad and deep, and includes industry expertise in manufacturing, financial services, banking, health care, insurance, regulatory compliance, and NGOs.
Copyright © 2024 Wittij Inc.
crossmenu linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram