When to use Activity Diagram?
- Represent business workflows
- Identify candidate use cases, through the examination of business workflows
- Identify pre- and post-conditions (the context) for use cases
- Model workflows between/within use cases
- Model complex workflows in operations on objects
- Model in detail complex activities in a high level activity Diagram
Basic Model Elements
The activity diagram’s notation is very similar to that of a statechart diagram. In fact, according to the UML specification, an activity diagram is a variation of a statechart diagram.
Action is a named element which represents a single atomic step within activity i.e. that is not further decomposed within the activity.
Activity represents a behavior that is composed of individual elements that are activity nodes which could be:
- control flow
A Control Flow represents a transfer of execution control from one action to another action.
It is drawn as a solid line with a line-arrow at one end pointing to the next action.
When the Fill Order action is ended, the execution control is transferred to the Ship Order action.
Start and Final
They represent the starting point and the ending point of an action execution sequence within an activity. Start Notation and Final Notation are also called Initial State notation and Final State.
- A Start element is drawn as a small solid circle.
- A Final element is drawn as a small solid circle enclosed in an outer circle.
It represents a decision action that evaluates certain conditions and decides which action path to continue the execution.
A Decision Notation is drawn as a small diamond shape with one incoming control flow and multiple outgoing control flows.
Each outgoing control flow should be labeled with the condition that leads to this flow.
The decision action performed after the Receive Order action to check the stock can be drawn in the diagram as shown below:
It represents a merge point where multiple alternate execution paths will meet and continue.
It is drawn as a small diamond shape with multiple incoming control flows and on outgoing control flow.
The merge point where Ship Order and Hold Order meet can be drawn in the diagram as a Merge Notation as shown below:
It represents a fork action that splits a single execution flow into multiple concurrent execution flows.
It is drawn as a short solid line with one incoming control flow on one side and multiple outgoing control flows on the other side.
The fork action performed after the Receive Order action to start Ship Order action and Send Invoice action concurrently can be drawn in the diagram as shown below:
It represents a join action that waits for multiple concurrent execution flows to finish.
It is drawn as a short solid line with multiple incoming control flows on one side and one outgoing control flows on the other side.
Join action performed before the Close Order action to wait for both Ship Order action and Send Invoice action to finish can be drawn as in the diagram as shown below:
It represents an object which could be an input and/or an output of an action. An object in this case is considered as an instance of a class in a given state.
It is represented by a rectangle with its name placed inside.
It can also be qualified by a state written within brackets below the name.
Order [Filled] object generated from the Fill Order action will be consumed by the Ship Order action. This object can be drawn as an Object Notation in a UML activity diagram as shown below:
Different notations with same semantics:
Signal and Event
It represents a signal action that sends a signal to outside of the activity. The send signal action does not wait for any responses from the receiver of the signal. It ends itself and passes the execution control to the next action.
It is drawn as a convex pentagon with its name placed inside.
The Notify Customer send signal action in an order processing activity can be drawn as a Send Signal Notation in a UML activity diagram as shown below:
Swimlane and Partition
- Partition presents a group of actions and objects that share some common properties.
- It is drawn as two parallel lines with the partition name as one end.
- Any actions and objects that are located within the two lines are considered to be in the group.
- If an action or object may located on the border of multiple partitions, is considered to be in multiple groups.
- Partitions can be nested to form a hierarchy of partitions.
Actions and objects in an order processing activity can be divided into 3 groups:
- Order Department action group
- Accounting Department action group
- Customer action group, based on action ownerships
These groups can be drawn as Partition Notations in a UML activity diagram as shown below:
An Activity Parameter Activity accepts input to an Activity or provides output from an Activity.
Activity parameters are displayed on the border and listed below the activity name as: parameter-name: parameter-type.
The following example depicts two entry parameters and one output parameter defined for the Activity.
It is used in a UML Activity Diagram to provide a boundary to enclose all actions and objects of the activity.
It is drawn as a large rectangle with rounded corners. The activity name, input parameters and output parameters are written near the top left corner of the rectangle.
Object Notations representing input parameters and output parameters can be placed on edges of the rectangle.
Example: Activity Diagram – Notations
Example: Activity Diagram – Process Order
Example: Activity Diagram – Create Shipment
Example: Activity Diagram Swimlane