In many ways
UML Activity diagrams
are the object-oriented equivalent of
flow charts and
(DFDs). They are used to explore the logic of:
A complex operation
A complex business rule
A single use case
Several use cases
A business process
- General Guidelines
- Decision Points
- Parallel Activities
- Action Objects
Figure 1. Modeling a business
process with a UML Activity Diagram.
- Place The Start Point In The Top-Left Corner. A start point is modeled with a filled in circle, using the
same notation that UML State Chart diagrams use. Every UML Activity Diagram should have a starting point, and
placing it in the top-left corner reflects the way that people in Western
cultures begin reading.
1, which models the business process of enrolling in a university, takes
- Always Include an Ending Point. An ending point is modeled with a filled in circle with a
border around it, using the same notation that UML State Chart diagrams use.
2 is interesting because it does not include an end point because it
describes a continuous process - sometimes the guidelines don't apply.
- Flowcharting Operations Implies the Need to Simplify. A good rule of thumb is that if an operation is so complex
you need to develop a UML Activity diagram to understand it that you should
consider refactoring it.
An activity, also known as an activity state, on a UML
Activity diagram typically represents the invocation of an operation, a step in
a business process, or an entire business process.
- Question "Black Hole" Activities. A black hole activity is one that has transitions into it
but none out, typically indicating that you have either missed one or more
- Question "Miracle" Activities. A miracle activity is one that has transitions out of it
but none into it, something that should be true only of start points.
A decision point is modeled as a diamond on a UML Activity
- Decision Points Should Reflect the Previous Activity. In
1 you see that there is no label on the decision point, unlike traditional
flowcharts which would include text describing the actual decision being made,
you need to imply that the decision concerns whether the person was enrolled in
the university based on the activity that the decision point follows. The guards, depicted using the format
on the transitions leaving the decision point also help to describe the decision
- Avoid Superfluous Decision Points. The
Out Enrollment Forms activity in
A guard is a condition that must be true in order to
traverse a transition.
- Each Transition Leaving a Decision Point Must Have a Guard
- Guards Should Not Overlap. For example guards such as x <0, x = 0, and x > 0 are
consistent whereas guard such as x <= 0 and x >= 0 are not consistent
because they overlap - it isn't clear what should happen when x is 0.
- Guards on Decision Points Must Form a Complete Set. For example, guards such as x < 0 and x >0 are not complete
because it isn't clear what happens when x is 0.
- Exit Transition Guards and Activity Invariants Must Form a Complete Set. An activity invariant is a condition that is always true
when your system is processing an activity.
- Apply a [Otherwise] Guard for "Fall Through" Logic.
- Guards Are Optional
. It is very common for a transition to not include a guard,
even when an activity includes several exit transitions.
Modeling (AM)'s principle of
Models Simply and only indicate a guard on a transition if it adds
It is possible to show that activities can occur in
parallel, as you see in Figure
depicted using two parallel bars. The
first bar is called a fork, it has one transition entering it and two or more
transitions leaving it. The second
bar is a join, with two or more transitions entering it and only one leaving it.
- A Fork Should Have a Corresponding Join. In general, for every start (fork) there is an end (join).
In UML 2 it is not required to have a join, but it usually makes sense.
- Forks Have One Entry Transition.
- Joins Have One Exit Transition
Avoid Superfluous Forks.
2 depicts a simplified description of the software process of enterprise
architectural modeling, a part of the
Unified Process (EUP). There is
significant opportunity for parallelism in this process, in fact all of these
activities could happen in parallel, but forks were not introduced because they
would only have cluttered the diagram.
A swimlane is a way to group activities performed by the
same actor on an activity diagram or to group activities in a single thread. Figure
2 includes three swimlanes, one for each actor.
Figure 2. A UML activity diagram
for the enterprise architectural modeling (simplified).
Figure 3. Submitting expenses.
- Order Swimlanes in a Logical Manner.
- Apply Swim Lanes To Linear Processes. A good rule of thumb is that swimlanes are best applied to
linear processes, unlike the one depicted in
- Have Less Than Five Swimlanes.
- Consider Swimareas For Complex Diagrams.
- Swimareas Suggest The Need to
Reorganize Into Smaller Activity Diagrams.
- Consider Horizontal Swimlanes
for Business Processes. In
3you see that the swimlanes are drawn horizontally, going against common
convention of drawing them vertically.
Activities act on objects, In the strict object-oriented
sense of the term an action object is a system object, a software construct. In the looser, and much more useful for business application modeling,
sense of the term an action object is any sort of item. For example in Figure
action object is likely a paper form.
- Place Shared Action Objects on Swimlane Separators
- When An Object Appears Several Time Apply State Names
- State Names Should Reflect the Lifecycle Stage of an Action Object
- Show Only Critical Inputs and Outputs
- Depict Action Objects As Smaller Than Activities