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.Figure
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.Figure
2is 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.
A decision point is modeled as a diamond on a UML Activity
Decision Points Should Reflect the Previous Activity. In
1you 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
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.
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 Simplyand 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
1 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.
Avoid Superfluous Forks.
2depicts 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.
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