Accesorios, válvulas y tuberías

As elaborated in the previous section, Statecharts fulfil the requirements as modelling notation for the reusable test modules and behaviour models. However, not all aspects of the notation are required to create formal models in order to specify the behaviour of a

value-added service. The relevant components and aspects of Statecharts are described in the following.

Similar to other state machine-based notations, a Statechart is a finite set of states and transitions. According to (Harel, 1996) and (Harel and Kugler, 2004), there are two different types of states in a Statechart definition, basic states and hierarchical states.

Basic States

Basic states are not composed of other states and are therefore the lowest in the state hierarchy. Each state contains a set of transitions that define how the state reacts to events. In contrast to other state machine notations (such as EFSM-based approaches), a Statecharts basic state includes different action types, so-called entry and exit actions. They can appear associated with the entrance to or exit from a state. Figure 6.2 illustrates an initial state that is connected to a basic state (“State A”) by means of a default transition. The basic state itself is then connected to an end state, again through a default transition. Default transitions differ from standard transitions (which are connecting basic states and hierarchical states) in a way that they do not contain any information, such as events, actions or conditions (Chattopadhyay, 2013).

Figure 6.2: Statecharts basic state example State A entry: id = x+y; exit: timeout(); default_transition default_transition Initial state Basic state End state

6.1 Notation for Behaviour Modelling

Figure 6.2 also shows what kinds of actions can be defined within a basic state. These can either be arithmetic operations of given variables known in the model (e.g. “id=x+y”) or the invocation of known functions (e.g. “timeout()”).

Hierarchical States

Statecharts also allow the modelling of hierarchical states. In principle, hierarchical states are states that are able to contain other states. The Statecharts definition according to (Harel, 1996) makes a distinction between hierarchical OR-states and hierarchical AND- states. OR-states have substates related to each other by “exclusive or”. So, if an OR-state is active, only one of the internal substates will be active. The following Figure 6.3 illustrates the concept of OR-states.

Figure 6.3: Hierarchical OR-state example

The example Statechart shows two initial states. The rule regarding initial states is that every Statechart model contains at least one initial state. Each hierarchical state within the Statechart has its own initial state to determine the initial entry point. The hierarchical OR-state contains a finite number of substates that are connected through transitions. In order to leave the OR-state, both standard transitions (e.g. “t4”) as well as inter-level transitions (e.g. “t5”) can be used. The standard outgoing transitions of a hierarchical state signify that the outer state can be reached from every substate within the hierarchical

OR-State State A State B State C t1 t2 t3 t4 State D State E t5

state. In the example, “State D” is reachable from “State A”, “State B” and “State C” through transition “t4”. In contrast, the inter-level transitions to an outer state can only be reached from the originating substate within the hierarchical state. So, only if “State B” is active, the hierarchical state can be left through “t5” to “State E”.

The second type of hierarchical states, the AND-states, enable the specification of concurrent behaviour (Chattopadhyay, 2013). Figure 6.4 displays an example illustration.

Figure 6.4: Hierarchical AND-state example

The hierarchical “AND-State” encompasses two substates, each of which is a hierarchical OR-state (“OR1” and “OR2”). Thus, the system can be simultaneously in one of the basic states {State A, State B} for the first subsystem, and in one of {State C, State D} for the second subsystem. The concurrent substates are left as soon as an event occurs that leads to an outer state of the hierarchical AND-state. In this example, the occurrence of an event specified in the transition “t3” leads to the outer basic state “State E”.

Transitions

The most important part of Statecharts besides basic states and hierarchical states are the connectors of states, the so-called transitions. In principle, transitions define the

AND-State State A State B t1 t3 State E State C State D t2 OR1 OR2

6.1 Notation for Behaviour Modelling

conditions under which Statecharts can move between states. Figure 6.5 shows the labelling of transitions.

Figure 6.5: Labelling of transitions

The two states related by the transition are called source (“State A”) and destination (“State B”) states. The Event indicates the trigger that forces the transition to be activated. The condition, also known as Guard, is a boolean expression which decides whether the state transition actually occurs. Finally, the Action is executed if and when the transition is taken. A special form of transition is the so-called “self transition”. It implies that source and destination state of a transition is identical (Harel, 1996).

Timers

The integration of time within behaviour modelling is very relevant. In Statecharts, time contraints are expressed by using implicit timers and timeouts. The implicit timer generates the timeout event after a specified number of time units has elapsed. Timers are associated with states and transitions through events (Chattopadhyay, 2013). The corresponding Statecharts notation to define a timeout is illustrated in Figure 6.6.

State A

Figure 6.6: Specification of timeouts

The shown example states that if an event “Event_A” does not occur within the next three seconds, a timeout will take place and “State B” will be reached. This standard description is vague as there is no information given about the origin of the timer. Regarding the final notation, some enhancements will be done and presented in section 6.2.4.

Formal description (SCXML)

As mentioned in the previous section, SCXML can be applied to describe Statecharts in a formal structure. It is a “general-purpose event-based state machine language that combines concepts from Call Control eXtensible Markup Language (CCXML) and Harel State Tables.” (W3C, 2015) and its main goal is to “combine Harel semantics with an XML syntax” (W3C, 2015). In September 2015, SCXML became a W3C recommendation (W3C, 2015). All introduced features within this section are supported by SCXML. In the following, an example Statechart will be demonstrated in order to show how the components of a Statechart are described with SCXML language (see Figure 6.7). State A < 3 sec timeout State B State C Event_A

6.1 Notation for Behaviour Modelling

Figure 6.7: Light Switch Statechart example

The shown example contains a hierarchical OR-state (“OK”) which represents the possible states a light switch can have when it works properly (“OFF” and “ON”). If an error occurs, the light switch will be moved into the “Error” mode (“device.error”) and the number of error occurences are counted (“errorCount”). After a reset (“device.reset”), the light switch should work properly again. The corresponding SCXML description for this example Statechart is illustrated in the following Figure 6.8.

<?xml version="1.0" encoding="UTF-8"?> <scxml

xmlns="http://www.w3.org/2005/07/scxml" version="1.0" name="LightSwitch" datamodel="ecmascript" initial="OK">

<datamodel>

<data id="errorCount" expr="0"/> </datamodel>

<state id="OK"> <initial>

<transition target="OFF"/> </initial>

<transition event="device.error" target="Error">

<assign location="errorCount" expr="errorCount + 1"/> </transition>

<state id="OFF">

<transition event="device.turnOn" target="ON"/> </state>

<state id="ON">

<transition event="device.turnOff" target="OFF"/> </state>

</state>

<state id="Error">

<transition event="device.reset" target="OK"/> </state>

</scxml>

Figure 6.8: SCXML representation of Light Switch Statechart OK

Error _{OFF ON}

device.error / errorCount := errorCount+1

device.turnOn

device.turnOff device.reset

The main element in Figure 6.8 is the root element <scxml> which encompasses all elements of the description. Within the <datamodel> element, possible used variables within the Statechart descriptions are initialised (here: “errorCount”). The other elements are either <state> or <transition> elements. An important aspect is that every outgoing transition from a source state is represented as a state’s child within the XML-based structure. The destination state of the transition is then determined by the target attribute of the <transition> element. A hierarchical state, both OR-state and AND-state, is represented as a parent-child relationship in SCXML. The <initial> element refers to the initial state and its default transition. Figure 6.7 also determines the starting point of the overall Statechart example, the “OK” state. In the SCXML representation, this is set through the attribute initial of the <scxml> element.

To sum up, the Statecharts notation is a powerful modelling notation in order to specify behaviour and also includes features such as timer integration, concurrency and an underlying formal description. In the following section, it has to be specified how the Statecharts notation can be applied to describe the behaviour of value-added telecommunication services.