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.
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 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.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 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 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 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 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 Swimlanes
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 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 Activity State
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.2 Branching or decision box
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 Signals
Figure 4.5 Forking and Joining
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 Transition
Figure 4.7 Object flow
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 Swimlanes