Activity Modeling Technique
Rule001 - Activity Modeling Notation
Rule002 - Model a Workflow with an Activity Diagram
Rule003 - Model an Operation with an Activity Diagram
Guideline001 - Activities and Events
Guideline002 - Activity Modeling Problems and Pitfalls
Guideline003 - Activity Diagrams and Event Dependency Diagrams
Details
Activity modeling is a method used to describe the activities and events of the dynamic aspects of a system. The dynamic aspects of a system include all behavior-related components, i.e., the sequence of steps and the events affecting that sequence of steps. UML activity diagrams are used to visually represent the sequence of events that trigger the behavior.
A behavior component can be one of the following:
- The entire business
- A business process
- A package of objects or a component
- A use case (internal behavior)
- An operation
Whereas interaction diagrams focus on the flow of control from object to object (the messaging), activity diagrams focus on the flow of control from activity to activity and the events that trigger the transition from one activity to another. Activities eventually produce some action that causes a change of state in the system. Ultimately all activity diagrams can be seen as state transition diagrams.
Activity diagrams can represent both action states and activity states. The difference is that an action state is atomic and cannot be further decomposed into more granular actions, whereas an activity state represents a state in which activities can occur. In an activity state there can be several actions: entry actions, exit actions and actions that are continuous. An activity of an activity diagram can itself be modeled with a lower level activity model. Thus, activity models can be nested.
State transition diagrams can be used as an alternative to activity diagrams when the activity is the behavior of a single class. Use case diagrams are not an alternative to activity diagrams, because a use case represents the interface between a business process, its actors, and their sub-use cases. The internal details of a use case can be modeled by an activity diagram or by a state transition diagram.
The two most common uses of an activity diagram are:
- To represent the details of a workflow.
- To represent the details of an operation.
Workflows most often represent business processes and are used to visualize and document those business processes. Each behavior component of a business process workflow will be broken down into activities triggered by external events generated by the context of the system. The occurrence of the events will trigger transitions from one activity state to another. When modeling workflow, actors can be modeled as "swim lanes" (a swim lane is a layer of the activity diagram in which the actor performs many actions over time). Workflow modeling is a macro-usage of activity diagrams.
Operations often represent the details of a computation formerly represented by a flowchart. Modeling the details of an operation with an activity diagram is similar to the older technique of flowcharting, with the difference that an operation operates on a specific object and the operation will often change the state of that object. Modeling operations is a micro-usage of activity diagrams.
UML activity diagrams replace the older event dependency diagrams and achieve the same results. Activity diagrams can be used to model all forms of processes from the macro to the micro level. An activity diagram will accompany most use cases.