UML Activity Diagram from a Business Analysts Perspective

The UML Activity Diagram from a Business Analysis perspective

The UML (which stands for Unified Modeling Language) Activity Diagram is a way to depict in a diagrammatic way the sequential flow of the activities that a particular process performs. In the context of Business Analysis it is mostly used to show workflow and design level flow of activities based around business process requirements or business requirements. In some situations these diagrams are used to help describe what is required in terms of business process flow when describing the current or future business processes. In a more technical sense, the UML Activity diagram is part of the design artifacts included in functional specification documents.
How do you draw a UML Activity Diagram?
If you are very new to Business Analysis and have not mapped many business processes before it is easiest to look at some examples (like the one described here) to get a feeling for how to draw the UML Activity Diagram. From a very simplistic point of view you should consider each individual step of a process and identify those as the activities, decisions and parallel activities (things that can be done at the same time!) to be included in your diagram.
Also keep your process you want to draw as an UML Activity Diagram quite small and contained – don’t draw the whole business areas process necessarily on one UML Activity Diagram.
Decide what business process you want to map out as a UML Activity Diagram
Things for you to consider before you start is that you should not try and map out the entire business process in one diagram especially if it is large and complex. Break down your business process into manageable chunks. In the context of this example we chose to create a UML Activity Diagram for the “Submit Time sheet” activities. This means that instead of attempting to map the complete time sheet system’s processing, validation and financial activities all on one map we chose to start with the high level process of submitting and approving the time sheet of an employee. We can choose to also create the other related processes and more detailed levels of UML Activity Diagram but for the purposes of this example we just cover part of it. You will find that as you gain more experience as a Business Analyst that you will learn what level to pitch your UML Activity Diagram at – it largely depends on the reason why you need to create the diagram in the first place. If you want to illustrate the flow of activities at higher or conceptual level, then the example here is a good example. If you need to create an UML Activity Diagram for the technical teams to use for their software build tasks, then you may need to include more detailed level steps.
Let’s now look at the different notation components of the UML Activity Diagram:
uml activity diagram
Start
Each UML Activity Diagram must have a start point. This is always shown as a colored in circle. Please look at the example diagram to see how this should look.
Arrows (Flow)
The flow of activities or steps in the process must be shown with an arrow from one symbol (such as the “Start” dot to the first “Activity” box).
Rounded Rectangle
The Activity is shown with a rounded cornered rectangle. A few points when creating an activity:

  • It must only cover one specific activity in each activity rectangle on the diagram.
  • Ideally you should avoid generic terms such as ‘manage’ or ‘process’ when you describe your activity.
  • Each UML Activity Diagram should only have approximately 7 – 10 different activities on the diagram. If you need more, consider whether you should have a separate diagram instead.

Diamond (Decision)
As you progress through a UML Activity flow you are bound to hit a point where there is a decision point or a certain condition which has two alternatives. This is indicated with a diamond shape. You can choose to describe the decision in the diamond box or alternatively outside the diamond shape. We chose in the example to show it within the diamond box.
Fork / Joins
The Fork symbol is a horizontal line (for a portrait diagram starting top left and going down sequentially to the right hand corner) which means that the two (or more) activities that follows can be performed at the same time and have no dependency on each other. If you look at the example you will see how notifying the Agency of the approved time sheet and Saving the Time sheet to the ERP system has no dependency on each other. Both these activities can be performed at the same time and roughly at the same point in the flow of the diagram.
The Join symbol is where the activities which were performed in parallel come together again to fall into the remainder of the sequential flow. It is again shown as another horizontal line to show where the activities come together again. See the example diagram which brings all activities together to then execute the “Close Time-sheet Cycle” activity
Termination or End
Every UML Activity Diagram must have a termination point in the format as shown in the example where a coloured circle is outlined. There can be more than one termination point on a UML Activity Diagram.
Some other important things to keep in mind when you create a UML Activity Diagram:

  • Each activity on your Activity Diagram must have at least one input (in flowing arrow) and one output (out flowing arrow).
  • Remember to label your diagram appropriately.
  • Consider numbering your activities if you are planning to create supporting documentation.

Although not covered in this outline, keep in mind that the UML Activity diagram can also have roles shown on the diagram in the form of what we refer to as: Swim-lanes and pools. This will be covered in another article blog when we talk about BPMN process mapping. The roles work exactly the same on both types of diagrams.