Using SyncBars for fork and join in Activity diagram
Activity diagrams are one of several ways you can model the dynamics of a system. An Activity diagram is basically a flow chart that describes the flow of control from one activity to the next. You can show sequential and/or concurrent steps of a process, model business workflows, model the flow control of an operation, or the flow of an object as it passes though different states at different points in a process. Unlike interaction diagrams (Sequence, Collaboration) that emphasize the flow of control between objects, Activity diagrams emphasize the flow of control between activities.
An activity can be described as "an ongoing, nonatomic execution within a state machine" * and the ultimate result is some action that affects the state of the system or returns some value.
If you need to learn how to create new diagrams in a project, or the techniques for placing elements and drawing links, consult the User's Guide topics found under " Working with Diagrams: Basic Diagram Techniques" in the Table of Contents. See Related Topics below.
The content of an Activity diagram can vary depending upon what kind of control flow you are modeling and what level of detail you choose to provide. Activity diagrams most commonly contain:
Activities, representing activity states and action states
Transitions, which can show events and actions
Objects
Activity diagrams in Together can also show:
Decision points for branching flows
SyncBars for
concurrent flows
Swimlanes to
show responsibility for activities
Signal sends and receives, and object flows for objects
Activities are atomic actions that cannot be further decomposed. For example, in an airline reservation system, "Request a reservation", the activity representing a customer's request, cannot be broken down further.
Use Activity for both action states and activity states-- graphically there is no distinction. Use Notes with Note Links if you need to differentiate.
These enable you to partition activities into groups based on responsibility for carrying out the activities. You could have swimlanes for different objects if modeling operation workflows, or different business entities if modeling business process workflows. For example, in an airline reservation context, you might have separate swimlanes for Customer and Ticket Agent.
Swimlanes normally have a vertical orientation. The flow of activity runs from top to bottom. Transitions between activities will cross swimlanes left-to-right ore vice versa as the responsibility for carrying out activities changes.
Transition links show the path of the flow control from one action or activity state to the next. Together provides two types of transition links:
Transition:
used to show flow control between Activities or States.
Object Flow: used to show flow control when modeling flow control of objects.
Several properties of Transition links can be used to convey important information about what's happening in the diagram.
Event: Optionally specify an event that triggers the transition. For example, a Transition between the Start State and an activity Check Flights might be an event TicketAgentRequest. If modeling an object work flow, you might specify an actual system event and use the next property event arguments.
Action: optionally specify an action that causes the transition. This could be a user action in business process, or a computation that results in a state change in the process.
Condition: optionally specify a condition to be satisfied for a branching transition to take place (see Decision below.)
Decisions show branching and specify alternate flows based on the evaluation of some Boolean expression. The Decision icon icon itself has only one property Name. You show the relevant information about the decision in the properties of the Transitions that represent the different branches. For example, specify the Boolean expression for each branch in the Condition property of the Transition link for each branch.
In an airline reservation context, the decision you want to show might be "is space available on this flight". So you could name the Decision "isSpaceAvailable", and one branch's condition property could be "Available" and the other "Not Available".
Use these to model flows that are concurrent. For example, an activity "Check Customer Info" might check a customer's purchase history and current credit card information concurrently.
There are two Fork/Join controls available on the Activity diagram toolbar: one for showing concurrency with a vertical orientation and one for horizontal orientation. The same functionality is found in the SyncBar of State diagrams, and in fact the default name for both horizontal and vertical variants of this element is "SyncBarn" (where n is an incrementing integer).
When representing a "fork" where flow becomes concurrent, the SyncBar typically has has one Transition coming in, and two or more going out. When representing "join" where flow is no longer concurrent, the SyncBar typically has has two or more Transitions coming in, and one going out.
|
|
|
Using SyncBars for fork and join in Activity diagram |
Two icons are provided to enable explicit symbols for certain kinds of information that can be specified on transitions: signal receipt and signal send. You will probably not use these in Activity diagrams that model business process workflows... they are rather more useful in the context of object control flows.
Non-trivial systems will probably require many activity diagrams to capture the dynamics of a workflow or operation. Use the Clone feature to create new diagrams with identical content in the same package.
UsingAdd Existing command on the diagram's context menu, you can reuse any already created elements in other Activity diagrams. Note: Elements imported this way are independent copies of the existing ones.
Begin by modeling the main flow. Secondarily, cover branching, concurrent flows, and object flows. Use separate diagrams as needed and hyperlink them for easy browsing later on.
You can find detailed information on modeling workflows and operations in Chapter 19 of the UML User's Guide.