Visual Case
Tool - UML Tutorial
5.
Activity and State Diagrams
Previously we saw how interaction
diagrams demonstrate the behaviour of several
objects when executing a single use case.
When you want to show the sequence of events on a
broader scale use activity and state diagrams.
Activity
Diagram
An
activity is the execution of a task
whether it be a physical activity or the execution
of code. Simply put, the
activity diagram
shows the sequence of activities. Like the
simple flow chart, activity diagrams have support
for conditional behaviour, but has added support
for parallel execution as well.
Start:
each activity diagram has one start
(above) at which the sequence of actions begins.
End:
each activity diagram has one finish at which the
sequence of actions ends
Activity:
activities are connected together by
transitions.
Transitions are directed arrows flowing
from the previous activity to the next activity.
They are optionally accompanied by a textual label
of the form:
[guard]
label
The guard
is a conditional expression that when true
indicates that the transition is taken. The
label is also
optional and is freeform.
To show
conditional behaviour use a branch and a merge.
The top diamond is a branch and has only one
transition flowing into it and any number of
mutually exclusive transitions flowing out.
That is, the guards on the outgoing transitions
must resolve themselves so that only one is
followed. The merge
is used to end the conditional behaviour.
There can be any number of incoming, and only one
outgoing transition.
To show parallel behaviour use
a fork and a join. The
fork (top) has one transition
entering and any number of transitions exiting,
all of which will be taken. The
join (bottom)
represents the end of the parallel behaviour and
has any number of transitions entering, and only
one leaving.
State
Diagram
The state
diagram shows the change of an object
through time. Based upon events that occur,
the state diagram shows how the object changes
from start to finish.
States
are represented as a rounded rectangle with the
name of the state shown. Optionally you can
include an activity
that represents a longer running task during that
state.
Connecting states together are
transitions.
These represent the
events that cause the object to change
from one state to another. The
guard clause
of the label is again mutually exclusive and must
resolve itself to be either
true or
false.
Actions represent tasks that run
causing the transitions.
Actions are different from
activities in that actions cannot be interrupted,
while an activity can be interrupted by an
incoming event. Both ultimately represent an
operation on the object being studied. For
example, an operation that sets an attribute would
be considered an action, while a long calculation
might be an activity. The specific
separation between the two depends on the object
and the system being studied.
Like activity diagrams, state
diagrams have one start
and one end
from at which the state transitions start and end
respectively.
Putting
it all Together
Activity diagrams are used to show
workflow in parallel and conditionally. They
are useful when working out the order and
concurrency of a sequential algorithm, when
analyzing the steps in a business process and when
working with threads.
State diagrams show the change of
an object over time and are useful when an object
exhibits interesting or unusual behaviour - such
as that of a user interface component.
As always, use these diagrams only
when they serve a purpose. Don't feel that
you have to draw a state diagram for every object
in your system and an activity diagram for every
process. Use them where they add to your
design. You may not even include these
diagrams in your design, and your work may still
be complete and useful. The purpose of
Visual Case and of the diagrams is to help you do
your job, when the diagram becomes too complicated
and pedantic, you and those working with you will
lose focus on the task at hand.
