Activity
diagrams are often used to model business processes. They simply and quite
plainly show how things work, and so function as a good
aid to discussions of aspects of the workflow with the domain experts. These
are less abstract than the often used object-oriented
state diagrams.
The following example shows an activity diagram that depicts the rules and the process of paying
an order. In the following example, Softsale will not
accept an order if you have overdue payments open, will only allow payment
by invoice if your e-mail and home address have been verified, and a few other
rules. Take a closer look for yourself in order to become more familiar with
the notation.
Initial
States and
Final
States. These indicate the beginning and end of the observed process.
Action
States. These are the particular activities of which the process consists
that have to be executed in a specified chronological order. Sometimes you
may want to split the sequence. Therefore, you have two different possibilities:
Branches (choice) and Forks (concurrency).
Branches.
These divide the sequence into several alternatives specified by different
conditions (guards).
Forks
and
Joins. Forks
also divide the sequence but into concurrent sub-sequences, which are merged
again by Joins.
Synchronization
States. These are used in concurrent sub-sequences to synchronize producer-consumer
relations, so that a consumer can only use a resource which has been produced
in the corresponding amount.
Transitions.
Transitions are the ingredient that keep states active and the model elements
together. Each transition can be given guards
, triggers
,
and actions
as
properties to describe its behavioral details.
Object
Flow States. In activity diagrams it is possible to model an Object Flow.
Objects are inputs or outputs of activities and are accordingly connected
by transitions to them.
Dependencies.
These are always possible between any model elements.