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.
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.
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:
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.
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).
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!!