|
UML
2 activity diagrams are typically used for business process modeling, for
modeling the logic captured by a single
use case or usage scenario, or for modeling the
detailed logic of a
business rule. Although UML activity diagrams could
potentially model the internal logic of a complex
operation it would be far better to simply rewrite the
operation so that it is simple enough that you dont
require an activity diagram. In many ways UML activity
diagrams are the object-oriented equivalent of
flow charts and
data flow diagrams (DFDs) from structured
development.
|
|
Lets start by describing the basic notation (theres
more) that Ive used in Figures 1
and 2:
-
Initial node. The filled
in circle is the starting point of the diagram. An
initial node isnt required although it does make it
significantly easier to read the diagram.
-
Activity final node. The
filled circle with a border is the ending point. An
activity diagram can have zero or more activity final
nodes.
-
Activity. The rounded
rectangles represent activities that occur. An
activity may be physical, such as Inspect Forms,
or electronic, such as Display Create Student
Screen.
-
Flow/edge. The arrows on
the diagram. Although there is a subtle difference
between flows and edges I have never seen a practical
purpose for the difference although I have no doubt
one exists. Ill use the term flow.
-
Fork. A black bar with
one flow going into it and several leaving it. This
denotes the beginning of parallel activity.
-
Join. A black bar with
several flows entering it and one leaving it.
All flows going into the join must reach it before
processing may continue. This
denotes the end of parallel processing.
-
Condition. Text such as
[Incorrect Form] on a flow, defining a guard
which must evaluate to true in order to traverse the
node.
-
Decision. A diamond with
one flow entering and several leaving. The flows
leaving include conditions although some modelers will
not indicate the conditions if it is obvious.
-
Merge. A diamond with
several flows entering and one leaving. The
implication is that one or more incoming flows must
reach this point until processing continues, based
on any guards on the outgoing flow.
- Partition.
Figure 2 is organized into three partitions, also
called swimlanes, indicating who/what is performing
the activities (either the Applicant,
Registrar, or System).
- Sub-activity indicator. The rake in the
bottom corner of an activity, such as in the Apply
to University activity, indicates that the
activity is described by a more finely detailed
activity diagram. In
Figure 2 the Enroll In Seminar activity
includes this symbol.
-
Flow final. The circle
with the X through it. This indicates that the
process stops at this point.
-
Note.
Figure 2 includes a
standard UML note to indicate that the merges does not
require all three flows to arrive before processing
can continue. An alternative way to model this would
have been with an OR constraint between the no
match and applicant not on match list
flows. I prefer notes because stakeholders find them
easier to understand.
-
Use case. In
Figure 1 I indicated that the
Enroll in Seminar use case is invoked as one of
the activities. This is a visual cheat that I use to
indicate that an included use case is being invoked.
To tell you the truth Im not sure if this is official
allowed by the UML but clearly it should be. Another
way to depict this is shown in
Figure 2 via the use
of a normal activity although I dont think this is as
obvious as using a use case.
The activity diagram of
Figure 1 depicts one way to model
the logic of the
Enroll in University use case, a very common use of activity
diagrams because they enable you to depict both the
basic course of action as well as the alternate courses.
Activity diagrams can also be drawn that cross several
use cases, or that address just a small portion of a use
case. You can also use activity diagrams without use
cases being involved at all, for example a pair of
eXtreme Programming (XP) developers (Beck
2000) could draw activity diagrams with their
customer (the XP term for stakeholder) to analyze a user
story or a larger business process that a user story
supports.
Figure 1. UML activity diagram for the Enroll in
University use case.
Figure 1 is
notable for several things:
-
It depicts the notation that
youre likely to use 90% of the time (Ill discuss the
more esoteric notation later).
-
It is incorrect. You can
enter the join but never get out of it. When
you look at the logic, you see that you'll either
Create a Student Record and then enter the join,
or you could enter the join directly from Display
List of Potential Matches when the applicant
is on the list. One but not both of these
things will happen, but both are required for you to
exit the join. I really should have used a
merge (a diamond) instead of a join bar.
Should I update the diagram? No, because agile
models are
just barely good enough to get the job done
(this one is, IMHO) and because agile modelers
follow the practice
update only when it hurts, and there isn't
enough motivation to update this diagram (chances
are very good that once you implemented the logic
contained within it that you'd simply erase it
anyway).
-
The use of diamonds for decisions
and merges is visually wordy but unfortunately all too
common. In Figure 2 I
address this issue by placing conditions on flows
leaving activities instead of introducing additional
diamonds to represent decision points.
-
It uses a fork to indicate
parallel processing, in this case weve decided that
we can perform some of the checks on the applicant in
parallel, something that wasnt easy to indicate using
flow charts.
-
It shows how activity diagrams
can get large very quickly. Even though it models the
logic of a single use case I was forced to have it
wind around the whiteboard because I ran out of
space. Ideally the diagram should be wider, with the
logic going from left-to-right across the board.
Better yet, it would be nice to have more whiteboard
space.
-
It includes a common mistake. At
the very end I applied a decision just before the
Process Payment and Print Receipt processes
to indicate that they can be done in parallel. I
should have used a fork, not a decision, for that. I
should also use a balancing join, instead of a merge,
although either one would be allowed. The join or
merge is required because both processes need to
finish before the overall process ends, without doing
this a race condition effectively exists where the
first process to finish would end things.
Figure
2 depicts the Enroll in University use case
but takes a different approach than. As noted above it avoids the use of
decision points. It also uses the concept of partitions,
also called swim lanes, to indicate who/what is
performing the activity. In this diagram I simply
labeled the partitions with the text Applicant,
Registrar, and System although it is also
common to put actor symbols (stick figures) to make it
very clear that an actor is performing some activities.
Partitions are useful because they provide more
information, but they also elongate the diagram I ran
out of room and was forced to finish the diagram on
another whiteboard (not shown), using a connector (the
circle with the letter A in it), to help show how
the physical separate portions fit together. A common
use of connectors is to avoid a line going from one side
of a diagram to another. Instead you show a flow
entering a connector and a second flow leaving a
similarly labeled connector, e.g. both connectors have
the letter B in them, going into the target
activity. Figure 2
also depicts how to apply a flow final, the circle with
the X through it, as well as a note to indicate a
constraint on a merge, as noted above.
Figure 2. UML activity
diagram with partitions based on actors.
The style of partitions in Figure 2
is often referred to as swim lanes because the
partitions look like the lanes in a swimming pool.
Figure 3 takes a
different approach, I guess you could call the
partitions swim areas. As you can see swim areas take
up less room than swim lanes. Its also interesting to
note that the partitioning strategies between the two
diagrams are different Figure 2
is partition by actor whereas
Figure 3 is partitioned
by courses of action within a use case. As always, my
advice is to use the strategy best suited for your
situation.
Figure 3. UML activity
diagram with partitions based on alternate courses.
Figure
3 uses a notation that we havent seen before, the
five-sided Possible Security Risk signal. This
symbol indicates that an event has occurred, that weve
determined that there is a possible security risk, and
therefore the Perform Security Check use case may
need to be triggered.
Figure 4
depicts a UML activity diagram for the Distribute
Schedules use case, this time Ive used a drawing
tool so you can see a clean example of the notation.
The activity starts when the Schedule Printed signal is
received, this signal would be sent from one or more
other activity diagrams, and its April 1st
(or later). The hour-glass symbol represents time, and
because all of the flows going into a join must occur
before processing can continue the way that you would
read this is that the schedules must be printed and it
has to be at least April 1st. In fact, Ive
chosen to indicate this with a join specification,
basically a constraint associated to a join in the
format {joinSpec = }. In this case the join
specification is completely redundant so there isnt any
value in indicating it other than the fact that I wanted
to show you an example. The only time that I indicate
join specifications is when there is a constraint that
isnt obvious from the incoming flows. For example, if
the schedules needed to be distributed before April 21st
then I would likely indicate this with a join
specification.
Figure 4.
Distributing schedules.
The square on the side of the
Determine Mailing List activity in
Figure 4 is
called a pin, and the one on the side of the Print
Mailing Label activity is a parameter. The circle
on the flow indicates a transformation, in this case the
people on the mailing list are sorted by zip code (the
post office charges less for bulk mailings that are
sorted in this manner) and then each individual is
listed so that a mailing label can then be printed for
each individual.
The Labeled Schedule box is
an example of an object being passed between
activities. I rarely show objects in this manner as I
feel this notation is a little bit goofy. You can
usually read between the lines and determine what is
flowing between activities, for example it is clear that
labels are being passed from the Print Mailing Label
activity to the Attach Labels to Schedules
activity.
Source
This artifact description is excerpted from Chapter 9 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
Translations
Suggested Reading
-
Activity Diagramming Guidelines
-
Artifacts for Agile Modeling: The UML and Beyond
-
Introduction to the Diagrams of UML 2
-
Introduction to Object Orientation (OO) and UML
-
Modeling Style Guidelines
-
Pavel Hruby's UML 2.0 Stencil for Visio
-
Why Extend the UML Beyond Object and Component
Technology?
|
|
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
of the
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
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
|
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
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
elicit requirements,
architect, and then
design your system in an agile manner. |
|
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
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. |
Disclaimer
The notation used in these diagrams, particularly the
hand drawn ones, may not conform perfectly to the
current version of the UML for one or more of reasons:
- The notation may have evolved from when I
originally developed the diagrams. The UML
evolves over time, and I may not have kept the
diagrams up to date.
- I may have gotten it wrong in the first place.
Although these diagrams were thoroughly reviewed for
the book, and have been reviewed by thousands of
people online since then, an error may have gotten
past of us. We're only human.
- I may have chosen to apply the notation in
"non-standard" ways. An agile modeler is more
interested in created models which communicate
effectively than in conforming to notation rules set
by a committee.
- It likely doesn't matter anyway, because the
modeling tool(s) that you're using likely won't
fully support the current version of the UML
notation perfectly anyway. Bottom line is that
you're going to be constrained by your tools anyway.
If you're really concerned about the nuances of
"official" UML notation then read the current version of
the UML
specification.
Let Us Help
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.
|