Introduction

This guideline describes, by way of an example, how to derive statechart diagrams from a consistent set of activity and sequence diagrams.  The example is a security system used to grant exit from a facility to authorized users that swipe a valid security card.  The users get three attempts at swiping the card and if the card is not validated by the third attempt exit is denied.  The following input information is available:

• An activity diagram specifying the functional flow for the ConrolExit use case(see Figure 1);
• A sequence diagram illustrating the nominal scenario of the ControlExit use case, in which the user is granted exit (see Figure 2a); and
• A sequence diagram illustrating an exception scenario of the ControlExit use case, in which the user is denied access (see Figure 2b).

Each of these diagrams also have associated pre- and post-conditions.

Figure 1: Use-Case Black-Box Activity Diagram for Uc2 ControlExit

Figure 2a: Nominal Flow of Uc2_Sc1 ControlExit 

 
Figure 2b: Exception Flow of Uc2_Sc2 ControlExit 

To derive a statechart diagram:

Step 1: Identify wait states and action states

1.1 Identify Wait States

In a wait state an object waits for an event to happen i.e. it just consumes time.

From the use-case black-box activity diagram (Figure 1), identify actions with IN actor pins.  From the use-case black-box sequence diagrams (Figure 2a and Figure 2b), identify the messages (receptions) that trigger the selected actions. For each of the identified actions, create a wait state in the statechart diagram named WaitFor<ReceptionName>.

In cases where the use-case black-box sequence diagram shows a timeout event (t_Unlocked in Figure 2a), create a wait state in the statechart diagram with a name that describes the actual system status. The results are shown in Figure 3a, below.

Figure 3a: Wait States of Uc2 ControlExit

1.2 Identify Action States

An action state is a state whose purpose is to execute an entry action, after which it takes a completion transition to another state. It is a kind of dummy state that is useful for organizing state machines into logical structures.

From the use-case black-box activity diagram (Figure 1), identify actions that are followed by a decision node. For each of these actions create an action state in the statechart diagram with the name of the action (naming convention: <ActionName>ing) and allocate the relevant action to it using MOORE syntax.

Note: Besides the output-relevant action, an action-state may also have additional context-related actions allocated to it. The results are shown in Figure 3b, below.

Figure 3b: Action States of Uc2 ControlExit

Step 2: Create a flat statechart

2.1 Identify the Initial State

Identify the initial state by drawing an initial pseudo-state node. If attributes need to be initialized add respective actions to the initial transition. See  /ScFailCount=0; in Figure 4, for example.

2.2 Identify Transitions, Triggering Events, and Associated Actions

The transitions between the states and associated triggering events – including guarded condition(s) - are identified through analysis of the sequence diagrams (Figure 2a and Figure 2b). With regard to the description in the statechart it is recommended to follow MEALY syntax.

Select a use-case scenario. Replicate the scenario in the statechart diagram as follows:

Start from the initial state.

In the sequence diagram identify the event (message) and – if needed – guarded condition(s) that trigger a transition and the associated sequence of actions.

In the statechart diagram identify the target state.

Connect the two states with a transition line.

Label the transition following the statechart notation for labeling transitions: Event [Condition] / Action.

If the target state is an action state, add to the transition label only those actions that are not already allocated to the state.

Proceed in the sequence diagram and repeat the previous steps.

Repeat the replication of scenarios in the statechart for all captured use case scenarios.

Figure 4, below, shows the resulting statechart capturing both scenarios in the example.

2.3 Execute the Statechart

Verify the correctness of the captured state-based behavior through model execution using the input use case scenarios (Figure 2a and Figure 2b) as the basis for respective stimuli.

Figure 4: Flat Statechart of Uc2 ControlExit

Step 3: Re-factor the Statechart with regard to hierarchy

3.1 Identify State Hierarchies Once the flat statechart is verified, look for ways to simplify it by structuring it hierarchically. Identify states that can be aggregated. Grouping criteria could be the following: System modes. System phases. Reuse of state patterns. Also look for situations where the aggregation of state transitions simplifies the statechart. Inspection of the flat statechart in Figure 4 reveals that the following 3 states can be considered sub-states of a composite state called ProcessingSecurityCard: ValidatingSecurityCard. FlagingSecurityCardFailure. WaitFor_req_ReadSecurityCard in the case of a card failure. This is depicted in Figure 5b. As ScFailCount is a local attribute, the initialization is added to the default entry of the composite state. Furthermore, the sub-states FlagingSecurityCardFailure and WaitFor_req_ReadSecurityCard can be aggregated in the composite state ValidationFail, thus denoting the fail mode within the ProcessingSecurityCard state. Note the different descriptions of the transitions out of the composite state. In the case of CardStatus=="Pass" the triggering condition and associated action is captured in the top-level statechart (Figure 5a) as a high-level interrupt. In the case of a third-time failure the respective triggering condition and associated action are captured within the ProcessingSecurityCard state and linked to the top-level statechart via an Exit Point (Fail3Times). States on the flat statechart in Figure 4 that relate to the access point control can be aggregated into a composite state UnlockingAndLockkingAccessPoint, as shown in Figure 5c. This state includes the messages sent to the access point. Furthermore, the wait states WaitFor_evAccessPointUnlocked and WaitFor_evAccessPointLocked are merged to one wait state called WaitForAccessPointFeedback.  The exit out of the composite state is captured in the top-level statechart. Figure 5a shows the final hierarchical statechart of the use case Uc2 ControlExit. 3.2 Execute the Statechart Verify the correctness of the captured state-based behavior through model execution using the black-box use case scenarios as the basis for respective stimuli.

Figure 5a: Hierarchical Statechart of Uc2 ControlExit Figure 5b: Composite ProcessingCardData Figure 5c: Composite State UnlockingAndLockingAccessPoint