Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.
An Activity organizes and specifies the participation of subordinate behaviors, such as sub-Activities or Actions, to reflect the control and data flow of a process. Activities are used in Activity diagrams for various modeling purposes, from procedural-type application development for system design, to business process modeling of organizational structures or workflow.
This simple diagram of an Activity contains Action elements and includes input parameters and output parameters.
You can define an Activity as a composite element, either during creation or during later edits. When creating a composite Activity element, it is simpler to apply the mechanism for creating Structured Activity elements, which reduces the number of steps to work through. If converting an existing Activity element, right-click on the element and select the 'New Child Diagram | Composite Structure Diagram' option.
Certain properties can be graphically depicted on an Activity. The Actions in an Activity can be further organized by Activity Partitions.
An Activity can also be depicted as an Expansion Node to indicate that the Activity consists of an Expansion Region.
If you have defined a Decision Table for the Activity element, you can select options on the element's context menu to render the element on a diagram as the Decision Table, showing the rules as either rows or columns. You can also return the element to its normal element shape.
- Activity Notation
- Activity Parameter Nodes
- Activity Partition
- Object Node
- Activity Diagram
- Composite Element
- Structured Activity
- Expansion Node
- Expansion Region
- Decision Models
- Element Context Menu Operations
OMG UML Specification
The OMG UML specification (UML Superstructure Specification, v2.1.1, p.318) 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 that is implemented by an activity containing actions that execute before the call action completes.