Activity Diagram
Elements of Activity Diagram:
Initial Activity: This is first activity of the flow. It is shown as filled circle. Place the initial activity in the top-left corner.
Final Activity: The end of activity diagram is shown as bull's eye symbol. This is also called as a final activity. The final activity is optional. Some times an activity is simply a dead end, but if this is the case then there is no harm in indicating that the only transition is to an ending point. When someone else reads your diagram, they know that you have considered how to exit these activities.
Figure 4.1
Figure 4.1 Notations for initial and final activities
Activity States: Activity state is a state that represents the execution of an atomic action, typically the invocation of an operation or transaction. Activity state depicted as a rectangle with straight top and bottom and with convex arcs on the two sides. Text in the activity box represents an activity (the activity name). State names should reflect the lifecycle stage of an action object.
A activity has transitions into it but there no transition to other activity. Such activity is called as black hole activity. A black hole activity typically indicates either you have missed one or more transitions. As noted previously if an activity is in fact the final activity in the process you are modeling you should consider adding a transition out of it to an end point. A miracle activity is one that has transitions out of it but none into it, something that should be true only of start points. Once again, this is an indication that you have missed one or more transitions.
Figure 4.2
Figure 4.2 Activity State
Composite Activity State: A concurrent substate that can be held simultaneously with other substates contained in the same composite state. This can be represented by drawing two parallel transaction lines from super activity state to concurrent activities.
Ensure that exit transition guards and activity invariants must form a complete set. An activity invariant is a condition that is always true when your system is processing an activity. Clearly the conditions that are true while processing an activity must not overlap with its exit conditions and the invariants & exit conditions must "adds up" to a complete set.
Branching: A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also use guard to one of the paths "else." The guards, depicted using the format [description], on the transitions leaving the decision point also help to describe the decision point. Avoid superfluous decision points by naming the activity such that it may include implied decision. To ensure that you have thought through all possibilities for a decision point, each transition leaving a decision point must have a guard. The guards on the transitions leaving a decision point, or an activity, must be consistent with one another. For example guards such as x <0, x = 0, and x > 0 are consistent whereas guard such as x <= 0 and x >= 0 are not consistent because they overlap – it isn’t clear what should happen when x is 0. Once you have reached a decision point it must always be possible to leave it, therefore the guards on its exit transitions must be complete. For example, guards such as x < 0 and x >0 are not complete because it isn’t clear what happens when x is 0.
Figure 4.3
Figure 4.2 Branching or decision box
Use a [otherwise] guard for "Fall through" logic. This enables you to avoid a very wordy guards and simplifies the diagram.
Signal: When an activity sends or receives a message, that activity is called a signal. Signals are of two types: Input signal (Receiving message activity) and Output signal (Message sending activity). Input signal is depicted as a concave polygon and output signal is shown as a convex polygon.
Figure 4.4
Figure 4.4 Signals
Synchronization: Some activities occur simultaneously or in parallel. Such activities are called concurrent activities. When there are concurrent event(s) triggering an activity or activities then a horizontal synchronization bar is drawn between event and activity. Synchronization is also called forking and joining. Ensure that every fork have join. In general, for every start (fork) there is an end (join).
Figure 4.5
Figure 4.5 Forking and Joining
Transition: Transitions shows what activity state follows after another. This type of transition can be referred to as a completion transition. A solid arrow represents the path between different states of an object. An event is triggered by an activity. It is specification of a significant occurrence that has a location in time and space. Labels are used to show the transition with the event that triggered it and the action that results from it.
Using guards is optional. It is very common for a transition to not include a guard, even when an activity includes several exit transitions. When a UML activity diagram is used to model a software a process or business process often represent sharing or movement of information and objects between activities, a situation where guards often make less sense.
Figure 4.6
Figure 4.6 Transition
Object Flow: Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object.
Figure 4.7
Figure 4.7 Object flow
Swimlanes: The contents of an activity diagram may be organized into partitions (swimlanes) using solid vertical lines. A partition does not have a formal semantic interpretation, but is, in business modeling, often used to represent an organizational unit of some kind.
A good rule of thumb is that swimlanes are best applied to linear processes, where the logic proceeds from one activity to another. Although there are no semantics behind the ordering of swimlanes, ensure ordering of swimlanes in a logical manner. A disadvantage of swimlanes is that they reduce your freedom to arrange activities in a space-effective manner, often increasing the size of your diagrams. When a diagram has a small number of swimlanes there is less chance that this problem will occur.
Figure 4.8
Figure 4.8 Swimlanes


Previous     Content       Next