Forking and Joining
- Forks are used for showing parallel execution of activities
- A fork may have one incoming transition and two or more outgoing transitions each of which represents an independent flow of control A fork represents the splitting of a single flow of control into two or more concurrent flows of control
- Below the fork, the activities associated with each of these paths continues in parallel
- A join may have two or more incoming transitions and one outgoing transition
- Above the join, the activities associated with each of these paths continues in parallel
- At the join, the concurrent flows synchronize, meaning that each waits until all incoming flows have reached the join, at which point one flow of control continues on below the join
- The forking and joining of the parallel flows of control are specified by a synchronization bar
- A synchronization bar is rendered as a thick horizontal or vertical line
Swimlanes
- Swimlanes partitions activity diagrams into groups having activity states where each group represents the entity responsible for those activities
- Each swimlane has a name unique within its diagram
- Swimlane represents a high-level responsibility for part of the overall activity of an activity diagram
- Each swimlane is implemented by one or more classes
Object flow
- Object flow indicates the participation of an object in a flow of control. It shows the objects created as a result of an activity, and in which activities those objects are used
- It is represented with the help of dependency relationships
Activity diagram is used:
- To model a workflow
- To model an operation
