Activity Diagram

An activity diagram is a behavior diagram of Unified Modeling Language (UML). It describes precisely one activity. This activity contains actions, control flows and object flows which technically and graphically describe the activity's flow in its entirety.

You can use the established MID modeling tool to create a Activity Diagram.
Test the Innovator Enterprise Modeling Suite for free.

Definition

The activity diagram shows a particular view of the dynamic aspects of the modeled system. An activity diagram graphically displays linking of elementary actions and their relationships with control and data flows and show a particular view of the dynamic aspects of the modeled system.

An activity diagram specifies an activity. The detailed rules as to how tokens flow in to an activity make up the basis of how an activity diagram is interpreted.

An activity diagram normally shows the flow of a use case but can also be used for modeling all activities within one system.

Activity diagrams in UML 2 are similar to Petri nets and are more suited to showing concurrent systems as they integrate asynchronous communication mechanisms (send and receive signals, exception handling).

The icon is of a diagram with an activity in it.

Owner Hierarchy/Prerequisites

An activity diagram shows the contents of precisely one activity
The activity diagram always shows the complete activity
Each activity needs one behaviored classifier; the activity should describe its behavior

Use

The activity diagram can be created in the Model Structure below a behaviored classifier.

Dependencies between actions and elements from other diagrams are shown in the whiteboard diagram.

Elements in the Activity Diagram

The following model elements can be shown as nodes and edges in activity diagrams:

Actions

An action is the base unit of the behavior specification. Actions in an activity are continuous, non-atomic activities. They are the smallest executable element within an activity. An action can be refined with other activities.

Outgoing flows should only be triggered due to the completion of the internal action, and not due to explicit events. If there are several outgoing flows, these must be made dependent on conditions.

An action takes an array of inputs and converts them into an array of results; the input set, output set or both sets can be empty. The interpretation of input and output sets is defined by the semantics for an array of specialized actions.

Table: Action Types
Icon	Element	Brief Description
	Execute instruction	An action; its semantic depends on the respective implementation.
	Call operation	An action which transfers a query from an operation call to the target object; it can then trigger the call of the linked behavior.
	Call behavior	A call action which directly calls a behavior instead of a behavior property; this would indirectly lead to this behavior being triggered.
	Accept event	An action which waits for an event which fulfills the condition given to occur.
	Send signal	An action which creates a signal instance from the input data and transfers it to the target object where a reaction can trigger e.g. firing of transitions in state machines or executing of an activity.
	Send object	An action which transfers an object to the target object where a reaction can trigger e.g. firing of transitions in state machines or executing of an activity.
	BroadcastSignal action	An action which sends a signal to all possible target objects in the system.
	AcceptCall action	An action which represents receiving a synchronous call query.
	Reply action	An action which contains a set of return values and a value which contains the result of a previous AcceptCall action, in turn.
	RaiseException action	An action which triggers an exception.
	ClearAssociation action	An action which destroys all instances of a relationship which a certain object participates in.
	TestIdentity action	An action which returns the "true" value if both input values are identical; otherwise this is the "false" value.
	ReadSelf action	An action which queries an activity's context object.
	ReadStructuralFeature action	An action which identifies a structural property's values.
	CreateObject action	An action which creates a new instance of a classification.
	DestroyObject action	An action which destroys the object at its input pin upon runtime.
	CreateLink action	An action which creates instances of associations or association classes.
	ReadLink action	An action which navigates using association ends to retrieve other objects.
	DestroyLink action	An action which deletes instances of associations or association classes.
	ClearStructuralFeature action	An action which deletes all existing values from a structure property.
	Unmarshall action	An action which breaks down an object of a certain type into individual parts so that their values correspond to one structure property of this object respectively.
	RemoveStructuralFeatureValue action	A writing action which removes values from a structure property.
	AddStructuralFeatureValue action	A writing action which adds to a structure property value or replaces previous values.
	ValueSpecification action	An action which evaluates an expression for a value specification.

Object Node

An object node is a node in the activity diagram which expresses that an instance of a certain classifier is available at a certain point in the activity flow, possibly in a particular state. Object nodes can be used in many different ways regardless of whether object flows go in or out of this node.

Table: Object Node Types
Icon	Element	Brief Description
	Activity parameter	Activity parameter nodes are special object nodes that are directly linked with an activity and describe the activity's interfaces.
	Input pin	The pin notation for object nodes illustrates the relationship between an action and an object node as and input or output parameter of the action. The direction of the edges at the object node sets whether this is an input or output pin.
	Output pin
	Value pin	A value pin is an input pin that provides a value based on a value specification.
	Action pin	An action pin is an input pin that carries out an action to specify the input value for another action.
	Central buffer	Buffers are object nodes that buffer and relay data tokens. Only object node can be linked with a buffer node.
	Data Store	Data stores are special buffer nodes that save persistent object tokens and only relays a copy of the data token to the outgoing edges; this means that all data can always be read and as often as required.

Control structures

Control nodes are used to coordinate object and control flows between other nodes, whereas structure nodes are used for grouping actions within an activity

Table: Control Structure Node Types
Icon	Element	Brief Description
	Initial node	The initial node starts an activity. It only has outgoing and no incoming flows. Tokens are provided for all flows going out of the initial node when an activity is started. Unlike with states, activities can have one, none or multiple initial nodes.
	Decision node	A decision node has one incoming and multiple outgoing flows; it is used to split the control flow into multiple alternatives which can be controlled by conditions. The decision node's token is consumed by the output node which fulfills the global conditions needed.
	Merge node	The merge node rejoins various flows into one control flow. An action node after the merge node can consume a token if there is a token waiting at the merge node's input node.
	Fork node	A fork node splits the control flow into multiple parallel control flows. All outgoing flows are given a token so that all outgoing flows can start an independent subflow.
	Join node	The join node rejoins parallel flows into one control flow. A token is only given to the next node in the flow once all incoming flows have received tokens.
	Flow final node	A final flow node ends one single parallel control flow within an activity.
	Activity final node	An end node completes an activity. It only has incoming and no outgoing flows. As soon as a token reaches an end node, all other tokens are canceled and the activity is shown as completed.
	Vertical or horizontal activity area	An activity region (activity partition) splits an activity into areas with common properties such as responsibility, role, subsystem. There is no semantic change to the activity.
	Structured activity node	On the one hand, a structured activity node can group an activity's elements to give it structure; on the other hand, it can be used as a special, executable node within control flows. Structured activity nodes have the "Expansion Type" property. If "None" is set, then the «structured» keyword appears and pins are shown as squares. Pins are shown as rectangles with separation lines for all other values and indicate a list of elements.
	Interruptible region	An interruptible region surrounds one or more actions and can be identified by an interruptible edge which starts within the interruptible region and has its target outside of this region. If the region is left using the interruptible edge, then all actions and/or flows being executed in the region are canceled by discarding all existing tokens. The flow continues at the interruptible edge's target node.

Edges

Edges in the activity diagram show the control and data flow between the diagram's nodes.

Table: Edge Types
Icon	Element	Brief Description
	Control flow edge	The control flow within an activity is achieved with flows between the actions These flows can either directly lead to the next action or to a wait state, but can also be split and merged again with various connectors. A control flow is a directed edge which starts the activity node at the edge's target once the activity node is completed at the source.
	Object flow edge	An object flow is a directed edge which transports data between object nodes.
	Exception handler	A special edge which transfers the exception to the activity node the exception is handled in.

Example for an Activity Diagram

Further Information

http://www.uml.org/