Activity Diagram

Return to Introduction  Previous page  Next page

Activity diagrams are used to model the behaviors of a system, and the way in which these behaviors are related in an overall flow of the system. The logical paths a process follows, based on various conditions, concurrent processing, data access, interruptions and other logical path distinctions, are all used to construct a process, system or procedure. 

Note: You can create Analysis diagrams (Simplified Activity), containing the elements most useful for business process modeling, using the New Diagram dialog.

Example Diagram

The diagram below illustrates some of the features of Activity diagrams, including Activities, Actions, Start Nodes, End Nodes and Decision points.

Activity - Main1

Toolbox Elements and Connectors

Select Activity diagram elements and connectors from the Activity pages of the Enterprise Architect UML Toolbox.

Tip: Click on the elements and connectors below for more information.

Activity Diagram Elements

Activity Diagram Connectors

e_Activity

c_ForkJoinAcross

e_SubActivity

c_ForkJoinUp

e_Action

c_ControlFlow

e_Partition

c_ObjectFlow

e_Object

c_InterruptFlow

e_central_buffer_node

 

e_Datastore

 

e_Decision

 

e_merge

 

e_Send

 

e_Receive

 

e_Synch

 

e_Initial

 

e_Final

 

e_FlowFinal

 

e_Region

 

e_Exception

 

OMG UML Specification

The OMG UML specification (UML Superstructure Specification, v2.0, p. 284) states:

"An activity specifies the coordination of executions of subordinate behaviors, using a control and data flow model. The subordinate behaviors coordinated by these models may be initiated because other behaviors in the model finish executing, because objects and data become available, or because events occur external to the flow. The flow of execution is modeled as activity nodes connected by activity edges. A node can be the execution of a subordinate behavior, such as an arithmetic computation, a call to an operation, or manipulation of object contents. Activity nodes also include flow-of-control  constructs, such as synchronization, decision, and concurrency control. Activities may form invocation hierarchies invoking other activities, ultimately resolving to individual actions. In an object-oriented model, activities are usually invoked indirectly as methods bound to operations that are directly invoked.

"Activities may describe procedural computation. In this context, they are the methods corresponding to operations on classes. Activities may be applied to organizational modeling for business process engineering and workflow. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call. Activities can also be used for information system modeling to specify system level processes.

"Activities may contain actions of various kinds:

·occurrences of primitive functions, such as arithmetic functions.
·invocations of behavior, such as activities.
·communication actions, such as sending of signals.
·manipulations of objects, such as reading or writing attributes or associations.

"Actions have no further decomposition in the activity containing them. However, the execution of a single action may induce the execution of many other actions. For example, a call action invokes an operation which is implemented by an activity containing actions that execute before the call action completes."