Evaluation of Potential Modelling Notations

With regard to “Model-Based Testing” described in section 3.2.4, behavioural aspects of a system or service can be specified by means of modelling notations. According to (ETSI ES 202 951, 2011), such a modelling notation has to provide basic means for algorithmic design and data manipulation. The ETSI standard lists further general requirements that have to be fulfilled by potential modelling notations. The most relevant aspects are mentioned in the following (ETSI ES 202 951, 2011):

6.1 Notation for Behaviour Modelling

• The notation shall be based on unambiguous operational semantics.

• The notation shall support diverse simple data types such as boolean, integer and

character strings.

• The notation shall support user-defined abstract data types.

• The notation shall support basic control structures like variables, assignment and

conditional statements.

• The notation shall support advanced control constructs such as loops.

Considering these general requirements, the authors of (ETSI ES 202 951, 2011) point out that modelling notations for the specification of behaviour are limited to rule-based notations, process-oriented notations and Statecharts (Harel and Politi, 1998). Whereas Statecharts are clearly defined as a special presentation form for finite-state machines, rule-based notations and process-oriented notations each represent a group of more or less well-known modelling notations. Rule-based notations are “textual modelling notations where state transition rules describe the behaviour of the system” (ETSI ES 202 951, 2011). They can be referred to as extended finite state machines (EFSM) (Cheng and Krishakumar, 1993) or abstract state machines (ASM) (Börger and Stärk, 2003). In contrast, process-oriented notations focus on describing the activity of a system as a sequential process (or thread). During its lifetime, the process listens to inputs from its environment and also produces outputs. A well-known representative is the Business Process Execution Language (BPEL) (OASIS, 2007).

In order to find the appropriate modelling notations, further specific requirements have been determined. These requirements take the general requirements on the TCF (see section 3.4) as well as the properties of value-added services into consideration:

• The notation shall allow the definition of reusable test modules. • The notation shall enable the composition of reusable test modules. • The notation shall support the description of concurrent behaviour. • The notation shall support temporal logic (e.g. timer integration). • The notation shall deliver a standardised formal description.

First of all, the aspect of reusability is a major requirement a modelling notation has to fulfil. Reusability shall be provided by so-called reusable test modules. The characteristics of these reusable test modules and further information regarding their identification is discussed in section 6.2. As part of the modelling notation, a reusable test module shall exist in the form of a formal model which describes recurring behaviour. With regard to value-added services in the telecommunication domain, recurring behaviour can be for instance the sending or receiving of instant messages or the initiation and termination of audio or video calls. Such behaviour has to be specified in a generalised manner within a reusable test module. As soon as such a behaviour becomes relevant within a value-added service, the appropriate reusable test modules can be chosen and adapted to the given scenario, e.g. through parameterisation. All of the mentioned types of modelling notations enable the definition of reusable test modules although not all support the principle from scratch. In a rule-based approach with EFSMs, for instance, the concept of reusability has not been considered. However, behaviour of a test module can be defined within one state machine. This state machine can be stored and be reused as part of another state machine later on. As the EFSM-based state machines include variables, parameterisations at a given point can be performed. BPEL as representative for process-oriented notations also includes a concept of reusability (through so-called

6.1 Notation for Behaviour Modelling

specified and be reused in any other BPEL process. The final notation, Statecharts, explicitly supports modularity through the defined concept of hierarchical states. Within such a hierarchical state, the behaviour of one reusable test module can be specified.

The next requirement is directly connected with the previous one, however, it refers to the composability of reusable test modules. It has to be clarified, if a modelling notation allows the integration of a test module at any given point within the overall model. It might also be relevant to modify the internal behaviour of a test module. In principle, EFSM-based approaches support the composability of test modules. Every state and every transition within a formal EFSM model describing the behaviour of a test module is visible and accessible. Therefore, any new transition can be included and a composition is supported. Although the BPEL process supports reusability in principle, a reused module in form of BPEL processes is treated like a black box. Only the input parameters of the test modules can be specified, no changes can be done within the behaviour definition of a reusable test module based on BPEL. As the syntax of Statecharts is very similar to EFSMs, the composability of test modules is also supported.

The next requirement is highly relevant for the implementation and test of value-added services, because especially message flows (e.g. SIP messages) are usually not exchanged in a fixed sequential order. For instance, if a value-added service sends two SIP INVITE requests directly one after the other to two different participants in order to instantiate a Third party call control (3PCC) call (IETF RFC 3725, 2004), the sequence of received messages such as “200 OK” response and ACK request cannot be determined. In fact, the sequence of messages can differ from one execution to the other. This aspect requires a modelling notation that supports the definition of concurrent behaviour. EFSM-based

approaches do not support concurrency. BPEL contains a special “Flow” element that enables the definition of parallel processes. Statecharts support concurrency through so- called concurrent hierarchical states. Within such a concurrent hierarchical state, it can be more than one state executing simultaneously.

The next requirement concerns the integration of timers. Within the specified behaviour, it shall be possible to determine that a timer has started or that a timeout occurred. Originally, EFSMs do not support timer integration. However, some EFSM-based approaches included the starting of timers within states and the timeouts as events on transitions (Wacht et al., 2011a) or both as transition actions (Ernits et al., 2006). BPEL supports timers through a special “onAlarm” element that corresponds to a timer-based alarm. Finally, Statecharts support timers the same way it has been described for the EFSM-based approach in (Wacht et al., 2011a). As soon as a state is reached, a specific timer can be started. The timeout is then specified on a transition as an event.

Modelling notations such as EFSM, BPEL and Statecharts are mainly described graphically. For further processing of the underlying models, a formal description is required. This requirement on a modelling notation is essential for the proposed TCF and has to be fulfilled because of two reasons. Firstly, the reusable test modules have to be stored persistently in order to be selectable from the Test Module Repository. This can be done if a formal and textual representation of the modelling notation exists. Secondly, the generation of the behaviour models also requires a formal and parsable representation. Particularly the EFSM-based approaches lack standardised formal descriptions as there are many different notations. In contrast, BPEL processes can be serialised in a standardised XML-based language (OASIS, 2007). There is also a grammar-based

6.1 Notation for Behaviour Modelling

scheme defined which specifies the exact structure of the XML presentation. For the Statecharts approach, there is also a formal language called State Chart extensible Markup Language (SCXML) (W3C, 2015) exists which has been defined as World Wide Web Consortium (W3C) recommendation.

The analysis of the diverse modelling notations resulted in the following Table 6.1. It demonstrates an evaluation based on a rating scale that has been applied in Table 5.10.

Table 6.1: Comparison of potential modelling notations Requirements Modelling notations

EFSM (Rule-based notation)

BPEL (Process- oriented notation)

Statecharts

Definition of reusable test

modules o + +

Composition of reusable

test modules + - +

Support for concurrency - + +

Support for timer

integration o + +

Existing standardised

formal description - + +

To sum up, Statecharts are the modelling notation of choice regarding the formal description of the reusable test modules and the behaviour models.