- 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
1 includes an implied decision point, a check to see that the forms are filled
out properly, which simplified the diagram by avoiding an additional diamond.
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
3 you 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
3 the ExpenseForm
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
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around.
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.