Statechart and Activity Modeling
In case of Object Oriented Analysis and Design, a system is often abstracted by one or more classes with some well defined behaviour and states. A statechart diagram is a pictorial representation of such a system with all its states and different events that lead transition from one state to another.
To illustrate this, let us consider a computer. Some possible states that it could have are: running, shutdown, and hibernate. A transition from running state to shutdown state occurs when user presses the “Power off” switch, or clicks on the “Shut down” button as displayed by the OS. Here, clicking on the shutdown button or pressing the power off switch act as external events causing the transition. Statechart diagrams are usually drawn to model behaviour of complex systems. For a simple system, it is optional.
Building Blocks of a Statechart Diagram
A state is any “distinct” stage that an object (system) passes through in its lifetime. An object remains in a given state for finite time until “something” happens, which makes it to move to another state. All such states can be broadly categorized into following three types:
- Initial: The state in which an object initially remains when created
- Final: The state from which an object does not move to any other state [optional]
- Intermediate: Any state, which is neither initial nor final
As shown in Figure 1, an initial state is represented by a circle filled with black. An intermediate state is depicted by a rectangle with rounded corners. A final state is represented by a unfilled circle with an inner black-filled circle.
Figure 1: Representation of initial, intermediate, and final states of a statechart diagramIntermediate states usually have two compartments separated by a horizontal line called the name compartment and internal transitions compartment [iv]. They are described below:
- Name compartment: Contains the name of the state, which is a short, simple, and descriptive string
- Internal transitions compartment: Contains a list of internal activities performed as long as the system is in this state
The internal activities are indicated using the following syntax: action-label / action-expression. Action labels can be any condition indicator. There are, however, four special action labels:
- Entry: Indicates activity performed when the system enters this state
- Exit: Indicates activity performed when the system exits this state
- Do: Indicates any activity that is performed while the system remains in this state or until the action expression results in a completed computation
- Include: Indicates invocation of a sub-machine
Any other action label identify the event (internal transition) as a result of which the corresponding action is triggered. Internal transition is almost similar to self transition except that the former does not result in execution of entry and exit actions. That is, the system does not exit or re-enter that state. Figure 2 shows the syntax for representing a typical (intermediate) state
Figure 2: A typical state in a statechart diagramStates can also be classified as simple or composite (a state containing other states). Here, however, we shall deal only with simple states.
Transition is movement from one state to another state in response to an external stimulus (or any internal event). A transition is represented by a solid arrow from the current state to the next state. It is labeled by: event [guard-condition]/[action-expression], where
- Event is a trigger that caused the concerned transition (mandatory) — Written in past tense [iii]
- Guard-condition is (are) precondition(s), which must be true for the transition to happen [optional]
- Action-expression indicate action(s) to be performed as a result of the transition [optional]
It may be noted that if a transition is triggered with one or more guard-condition(s) that evaluate to false, the system will continue to stay in the present state. Also, not all transitions do result in a state change. For example, if a queue is full, any further attempt to append will fail until the delete method is invoked at least once. Thus, the state of the queue does not change in this duration.
As mentioned in [ii], actions represent behaviour of the system. While the system is performing any action for the current event, it does not accept or process any new event. The order in which different actions are executed, is given below:
- Exit actions of the present state
- Actions specified for the transition
- Entry actions of the next state
Figure 3 shows a typical statechart diagram with all its syntaxes.
Figure 3: A statechart diagram showing transition from state A to B
Guidelines for drawing Statechart Diagrams
The following steps can be followed, as suggested in [i], to draw a statechart diagram:
- For the system to developed, identify the distinct states that it passes through
- Identify the events (and any precondition) that cause the state transitions. Often these would be the methods of a class as identified in a class diagram.
- Identify what activities are performed while the system remains in a given state
Activity diagrams fall under the category of behavioural diagrams in Unified Modeling Language. It is a high level diagram used to visually represent the flow of control in a system. It has similarities with traditional flow charts. However, it is more powerful than a simple flow chart since it can represent various other concepts like concurrent activities, their joining, and so on [vii, viii].
Activity diagrams, however, cannot depict the message passing among related objects. As such, it cannnot be directly translated into code. These kind of diagrams are suitable for confirming the logic to be implemented with business users. These diagrams are typically used when the business logic is complex. In simple scenarios it can be avoided entirely [ix].
Components of an Activity Diagram
Below we describe the building blocks of an activity diagram.
An activity denotes a particular action taken in the logical flow of control. This can simply be invocation of a mathematical function, alter an object’s properties, and so on [x]. An activity is represented with a rounded rectangle, as shown in Table 1. A label inside the rectangle identifies the corresponding activity.
There are two special type of activity nodes: initial and final. They are represented with a filled circle and a filled in circle with a border, respectively (Table 1). An initial node represents the starting point of a flow in an activity diagram. There can be multiple initial nodes, which means that invoking that particular activity diagram would initiate multiple flows. A final node represents the end point of all activities. Like an initial node, there can be multiple final nodes. Any transition reaching a final node would stop all activities.
A flow (also termed as edge or transition) is represented with a directed arrow. This is used to depict transfer of control from one activity to another or to other types of components, as we will see below. A flow is often accompanied with a label, called the guard condition, indicating the necessary condition for the transition to happen. The syntax to depict it is [guard condition].
A decision node, represented with a diamond, is a point where a single flow enters and two or more flows leave. The control flow can follow only one of the outgoing paths. The outgoing edges often have guard conditions indicating true-false or if-then-else conditions. However, they can be omitted in obvious cases. The input edge can also have guard conditions. Alternately, a note can be attached to the decision node indicating the condition to be tested.
This is (also) represented with a diamond shape, with two or more flows entering and a single flow leaving out. A merge node represents the point where at least a single control should reach before further processing can continue.
Fork is a point where parallel activities begin. For example, when a student has been registered with a college, he/she can in parallel apply for student ID card and library card. A fork is graphically depicted with a black bar together with a single flow entering and multiple flows leaving out.
A join is depicted with a black bar with multiple input flows, but a ingle output flow. Physically it represents the synchronization of all concurrent activities. Unlike a merge, in case of a join, all of the incoming controls must be completed before any further progress can be made. For example, a sales order is closed only when the customer has received the productand the sales company has received its payment.
UML allows attaching a note to different components of a diagram to present some textual information. The information can simply be a comment or may be some constraint. A note can be attached to a decision point, for example, to indicate the branching criteria.
Different components of an activity diagram can be logically grouped into different areas called partitions or swimlanes. They often correspond to different units of an organization or different actors. The drawing area can be partitioned into multiple compartments using vertical (or horizontal) parallel lines. Partitions in an activity diagram are not mandatory.
The following Table shows commonly used components with a typical activity diagram.
Table 1: Typical components used in an activity diagram
Apart from the above stated components, there are few other components as well (e.g., representing events, sending of signals, and nested activity diagrams), which are not discussed here. The reader is suggested to go through [x], for example, for further details.
A Simple Example
Figure 4 shows a simple activity diagram with two activities. The Figure depicts two stages of a form submission. At first, a form is filled up with relevant and correct information. Once it is verified that there is no error in the form, it is submitted. The two other symbols shown in the Figure are the initial node (dark filled circle) and final node (outer hollow circle with inner filled circle). It may be noted that there can be zero or more final node(s) in an activity diagram [ix].
Figure 4: A simple activity diagram
Guidelines for drawing an Activity Diagram
The following general guidelines could be followed to pictorially represent a complex logic.
- Identify tiny pieces of work being performed by the system
- Identify the next logical activity that should be performed
- Think about all those conditions that should be made, and all those constraints that should be satisfied, before one can move to the next activity
- Put non-trivial guard conditions on the edges to avoid confusion