OCUP Activity Diagram

Activity Diagram⌘

describe the workflow behavior of a system
this diagram focuses on flows

Activity, Action⌘

Activity

describes a sequence of actions based on control models and object flow models
contains edges and activity nodes (e.g. actions)
represented by a rectangle with rounded corners

Action

represents a single step within an activity, that is, one that is not further decomposed within the activity.

Activity ⌘

Activity contains nodes and edges.

Activity Node ⌘

Subtypes of Activity Node

Activity Edge⌘

The edges of an activity
Denoted by a straight line with an open arrowhead

Control Flow⌘

A control flow is an edge that starts an activity node after the previous one is finished

Object Flow⌘

OR

An object flow is an activity edge that can have objects or data passing along it

Objects⌘

Incoming or outgoing objects are parameters
Placed (as rectangles) on the border

Or as small rectangle, called a pin (input or output)

Token⌘

The semantics of an activity is based on a token flow
Control tokens and object tokens flow between nodes over edges

Activity Example⌘

Initial Node⌘

It has outgoing edges but no incoming edges
An activity may have more than one initial node
- Each generates a concurrent flow
An initial node can have more than one outgoing edge
- Semantics: a control token at each outgoing edge
Activity diagrams do not have to have initial nodes
Notation: a filled circle

Final Node⌘

An activity may have more than one activity final node
The first one reached stops all flows in the activity
- Regardless of the number of tokens in activity
At least one incoming edge and no outgoing edges
If several incoming edges only one must carry a token
Activity diagrams do not have to have final nodes
Notation: a filled circle with an outer ring

Decision⌘

is a control node that chooses between outgoing flows
One incoming edge and several outgoing edges
When a token is supplied guards on outgoing edges are evaluated
- Token goes to first true outgoing
Notation: a rhombus

Decision Input⌘

A decision can also define a behavior
Every token passed over the incoming edge is passed to the behavior before guards evaluated
Result of the calculation accessed by the guards
Calculation doesn't need to be repeated for each guard
Notation: a note symbol with keyword «decisionInput»

Decision Input Flow⌘

An additional edge incoming to the decision node that provides a decision input value.
Is a type of ObjectFlow.

Merge⌘

A merge node is a control node that brings together multiple alternate flows
- It is not used to synchronize concurrent flows
Several incoming edges, one outgoing edge
Nothing calculated, nothing expected
Notation: an empty rhombus

Fork, Join⌘

Fork – one incoming edge and multiple outgoing edges
Join – multiple incoming edges and one outgoing edge

Implicit splitting⌘

Once action A terminates

a control token is available at both outgoing edges
actions B and C start concurrently

Implicit synchronization⌘

Action F doesn't start until tokens are available at both incoming edges - actions D and E have to terminate

Implicit split/synchronization - object flow 1⌘

AND semantics for object flows

Once action A terminates it provides two object nodes
Action F doesn't start until object tokens are available at both incoming edges - actions D and E have to terminate

Implicit split/synchronization - object flow 2⌘

OR semantics for object flows

Once action A terminates it provides a single object
- Which edge the object will select is undefined
Action F receives an object from both D and E
- It would be called twice

Questions⌘

What does an action represent?
What are pins?
What kinds of edge are there?
What kinds of activity node are there?
At which outgoing edges are tokens made available when an action terminates
When does the OR semantics apply to object flow?
How many incoming edges can an initial node have?
What do several edges outgoing from one initial node signify?

OCUP Activity Diagram

Contents