Activity Diagrams

in UML
 Definition
Activity diagrams represent the dynamics of the
system.
They are flow charts that are used to show the
workflow of a system.
They show.
The flow of control from activity to activity in the
system,
What activities can be done in parallel.
Alternate paths through the flow.
They can show the flow across use cases or within
a use case.
 Activity Diagram
Core symbol is an activity.
An activity is some task which needs to be
done.
Each activity can be followed by another
activity (sequencing).
Triggers from the activity may be guarded
as in state diagrams.
 Decision Activities
Diamond.
Each trigger coming from it has a guard.
Synchronisation bar. or
All triggers from this attach to activities that can
occur in parallel, with no specific sequence, or
concurrently.
The next synchronisation bar closes the concurrency.
Iteration is represented by a * on the trigger.
Activity Diagrams for Use Cases
They can be used for describing either
Use cases or
Complicated methods
 [no coffee] [no cola]
Find
Beverage
[found coffee]

Put coffee Add water Get

in filter to reservoir cups Get can
of cola
Put filter
in machine

Turn on
machine

Brew
coffee

Pour Drink
coffee Beverage
 Use Case for Order Processing
(Generic system)
When we receive an order, we check each line item on the
order to see if we have the goods in stock. If we do, we
assign the goods to the order. If this assignment sends the
quantity of those goods inn stock below the reorder level,
we reorder the goods. While we are doing this, we check to
see if the payment is OK. If the payment is OK and we
have the goods in stock, we dispatch the order. If the
payment is OK but we dont have the goods, we leave the
order waiting. If the payment isnt OK, we cancel the
order.
 Combining Use Cases
The end point of an activity diagram is the
point at which all triggered activites have
been run and there are no more left to do.
Dead ends (e.g. Reorder item) can occur.
Sometimes dead ends meet up with other
use cases (e.g. Check line item).
 Receiving Supply
When a supply delivery comes in, we look at the
outstanding orders and decide which ones we can fill from
this incoming supply. We then assign each of these to its
appropriate orders. Doing this may release those orders
for dispatching. We put the remaining goods into stock.
 Drawback
Activity diagrams tell you what is
happening, but not who does what.
In domain modeling, this diagram type does
not convey which people or departments are
responsible for each activity.
In programming, it does not convey which
class is responsible for each activity.
 Swimlanes
Arrange activity diagrams into vertical
zones separated by dashed lines.
Each zone represents the responsibilities of
a particular class or department.
 When to Use Activity Diagrams
Do use them for
Analysing Use Cases.
Understanding workflow across many Use
Cases.
Dealing with multi-threaded applications.
Dont use them
to see how objects collaborate.
to see how an object behaves over its lifetime.
 Receive
order
Activity
* for each line
Diagram for
item on order

[failed]
Authorise Check line
item
Receiving an
Payment
Cancel
[in stock]
Order
Order [succeeded] Assign
to Order

[need to Reorder
reorder] item
[stock assigned
to all line items
and payment
authorised]
Dispatch
Order
 Activity Receive
Diagram Supply

for
receiving Choose outstanding
Supply order items
* for each chosen
order item
Assign goods
to order
[all outstanding
order items filled]

Add remainder
Dispatch to stock
Order
 Combined
Receive
Activity
order
Diagram Receive
Supply
* for each line
item on order Choose
Check line outstanding
Authorise item order items
Payment [in stock]
[failed] * for each chosen
[succeeded] Assign order item
Assign goods
Cancel to Order
to order
Order
[need to Reorder
reorder] item
[stock assigned
to all line items [all outstanding
and payment order items filled]
authorised] Dispatch
Add remainder
Order
to stock
 Finance Order Stock
Processing Manager
Receive
order
Receive
Supply
* for each line
item on order Choose
Check line outstanding
Authorise item order items
Payment [in stock]
[failed] * for each chosen
[succeeded] Assign order item
Assign goods
Cancel to Order
to order
Order
[need to Reorder
reorder] item
[stock assigned
to all line items [all outstanding
and payment order items filled]
authorised] Dispatch
Add remainder
Order
to stock
With Swimlanes
 Understanding Workflows
Each activity represents the performance of a group of
actions in a workflow.
Once the activity is complete, the flow of control moves to
the next activity or state through a transition.
If an outgoing transition is not clearly triggered by an
event, then it is triggered by the completion of the
contained actions inside the activity.
A unique activity diagram feature is a swimlane that
defines who or what is responsible for carrying out the
activity or state.
It is also possible to place objects on activity diagrams.
The workflow stops when a transition reaches an end
state.
 Activity Diagram Tools
You can use the following tools on the activity
diagram toolbox to model activity diagrams:
Activities
Decisions
Object
Object Flow
States
Start State
End State
Swimlanes
Synchronizations
Transitions
 Placing an Activity diagram
Where?
You can attach activity diagrams to most model
elements in the use case or logical views.
Activity diagrams cannot reside within the component
view.
Why?
Very effective in illustrating the workflow of various
events in a use-case diagram.
You can use activity diagrams to specify and define
each event in a use-case diagram.
 Creating an activity diagram
Modelling a workflow in an activity diagram
Identify a workflow objective.
Decide the pre and post-conditions of the workflow.
Define all activities and states.
Define any objects that are created or modified.
Decide on responsibility for performing the activities.
Connect all elements on the diagram with transitions.
Place decisions on the diagram.
Evaluate your diagram for concurrent workflows.
Set all actions, triggers and guard conditions in the
specifications of each model element.
Identify a workflow objective.
"What needs to take place or happen by the end
of the workflow? What needs to be
accomplished?
For example, if your activity diagram models
the workflow of ordering a book from an online
bookstore, the goal of the entire workflow
could be getting the book to the customer.
What is the goal in the claims system?
What are the goals in the tennis club?
 2. Workflow pre and post-
conditions
Define pre and post conditions of the workflow
through a start state and an end state.
In most cases, activity diagrams have a flowchart
structure so start and end states are used to designate
the beginning and ending of the workflow.
Start and end states clarify the perimeter of the
workflow.
What is the pre-condition of the main workflow in
The claims system?
The tennis club?
 Define activities and states
Define and recognize all activities and
states that must take place to meet your
objective. Place and name them on the
activity diagram in a logical order.
Are there intermediate states in the claims
/ tennis club systems?
 Identify persistent object
operations
Define and diagram any objects that are
created or modified within your activity
diagram.
Connect the objects and activities with
object flows.
 Add swimlanes
Decide who or what is responsible for performing
the activities and states through swimlanes.
Name each swimlane and place the appropriate
activities and states within each swimlane.
Identify swimlanes for
The tennis club workflow
The claims workflow
 Finish diagram
Connect all elements on the diagram with
transitions.
Place decisions on the diagram where the
workflow may split into an alternate flow.
E.g. based on a Boolean expression, the workflow
could branch to a different workflow.
Evaluate your diagram and see if you have any
concurrent workflows. If so, use synchronizations
to represent forking and joining.
Set all actions, triggers and guard conditions in the
specifications of each model element.