Translating TTask into Promela

Model checking is a promising technique for test case generation. The main advantage is that one can use the advanced algorithms that are already imple- mented in a model checker. Hence, the eort shifts from the implementation of a test case generator to nding the best test selection criteria. Another advantage is that model checkers enable the simulation of their input models

5.2 Translating TTask into Promela 59 which provides the ability to validate the test model by simulation. Further- more, it is possible to verify the correctness of the test model with respect to requirements that are specied in the form of LTL formulas.

There are many dierent model checkers, each with specic advantages and disadvantages. In the following we describe the implementation of TTask mod- els with Promela, the input language of the model checker SPIN [Hol97]. We use SPIN for three main reasons:

ˆ Mature tool support: The model checker SPIN, which is based on Promela, has rst been introduced 1995 and has been continuously de- veloped since then.

ˆ Support for simulation and verication: SPIN supports the verica- tion of closed models, which is required for test case generation. Further- more, it supports the simulation of open models, which we use to simulate TTask models. Using SPIN for both simulation and verication guarantees that both obey the same semantics.

ˆ Easy transformation of TTask to Promela The semantics of TTask can be easily expressed with Promela, which enable a straightforward im- plementation of TTask in Promela.

A Promela model is constructed from three basic types of object: processes, data objects and message channels. Processes communicate via message chan- nels and share data via global data objects. Promela supports asynchronous and synchronous (called rendezvous in Promela) communication. A compre- hensive introduction into the syntax and semantics of Promela can be found in [Hol97].

The mapping of TTask to Promela is a straightforward implementation of the semantics introduced in the previous chapter. The task model state is implemented by a set of global data objects that store the current mode for each task. Task specic mode changes are implemented in separate processes in Promela. Each of these processes have an input channel through which it receives events that trigger its mode change. Task dependencies are realized by messages that are sent between the task-specic processes. For example, the Play process sends enable to the Stop process. Figure 5.1 shows the map- ping of a TTask model to the corresponding Promela model. Figure 5.1(a) shows a task model for a simplied CD player and Figure 5.1(b) shows the corresponding processes with the message channels and the messages that are sent between the processes. Figure 5.1(b) also shows the executor as a separate process that is responsible for starting and stopping atomic tasks. The composite tasks are started and stopped by their subtasks. When a task is started or stopped, it changes its mode and sends messages to dependent tasks corresponding to their temporal dependencies.

Listing 5.1 shows the initialization of a TTask model in Promela. Firstly, the dierent task modes and task signals are initialized using Mtypes. These enable the denition of symbolic names for numeric constants. Secondly, the message channels are initialized: each task has a separate incoming message channel. Finally the data objects that track the task states are initialized. The

Play CD* enable Play Stop (a) TTask. System Composite Tasks Atomic Tasks Environment Executor !start, !stop Stop Play !start, !stop !start !enable Play CD !stop !enable inStop inPlay inPlayCD

Process channel !message

!enable

(b) Promela.

Fig. 5.1. Mapping between TTask and Promela.

task modes are initialized with the initial task mode as dened in the task model.

// dene all modes and signals

mtype= { Enabled, Disabled, Active, Suspended, SuspendedEnabled, DisabledSuspended, Resume, Suspend, Enable, Disable, Start, Stop}; // rendezvous channel

chaninStop = [0] of {mtype};

chaninPlay = [0] of {mtype};

chaninCDPlay = [0] of {mtype}; // set initial task modes

mtypeStopMode = Disabled;

mtypePlayMode = Enabled;

mtypeCDPlayMode = Enabled;

Listing 5.1. Task mode and message channel initialization in Promela. In order to perform a verication in SPIN, the Promela model must be closed which means that the model does not depend on any external inputs. To ac- complish this, we have to encapsulate all external inputs in a separate process. External inputs are the start and stop signals for atomic tasks. This process corresponds to the Executor in Figure 5.1(b). The implementation of the Ex- ecutor is shown in Listing 5.2. The Executor process is the only process that is always active. The process loops innitely, starting and stopping enabled tasks non-deterministically. If a task's mode is enabled, the Executor starts the corresponding task process and sends the start signal. When the message is sent, the Executor waits until all task mode changes have been performed. This is realized by the timeout statement that evaluates to true if and only if there are no executable statements in any of the concurrently running pro-

5.2 Translating TTask into Promela 61 cesses. This is true, when all task mode changes have been performed. After the timeout statement evaluates to true, the executor stops the started tasks and waits until the model is ready to start the next task. SPIN supports the simulation of Promela models as well. In this case the executor is replaced by the user who can manually start and stop tasks.

activeproctypeExecutor() {

// non deterministic loop

do

:: PlayMode == Enabled −> // start Play

runPlay(); inPlay!Start;

// wait until Play is nished

timeout; // stop Play

runPlay(); inPlay!Stop;

// wait until Play is nished

timeout; :: StopMode == Enabled −> // start Stop ... :: else −> skip; od; }

Listing 5.2. Promela process for the Environment.

Listing 5.3 shows the implementation of a task in Promela. When a task is started, it waits for a new message to arrive via its message channel. De- pending on the incoming signal (start, stop, enable,...) and the current task mode, the process changes its corresponding task's mode. Then it starts the processes for its subtasks and its related tasks and sends signals depending on the incoming signal. For example, when a process receives a start signal, it subsequently sends a disable signal to all processes that implement tasks that are related by the disable dependency. After all task processes are notied, the task process ends.

The execution order of statements in dierent processes in SPIN is not deter- ministic due to SPIN's interleaving semantic. However, in our TTask imple- mentation in Promela there is always only one process active. Therefore we avoid the interleaving semantics in order to restrict the number of possible paths in the Promela model. This is achieved by using the rendezvous com- munication between all processes in combination with the denition of atomic sequences that are non-interleaved with other processes. Atomic sequences begin with the atomic statement and are surrounded by curly braces.

proctypePlay() {

atomic{

mtypenew;

inPlay?new −>

if

:: new == Start && PlayMode == Enabled −> // reveiced start

if

// if the parent is not active send start :: PlayCD != Active −>

runPlayCD(); PlayCD!Start; :: else −> skip;

;

// set task active PlayMode = Active; // received stop

:: new == Stop && PlayMode == Active −> // set task disabled

PlayMode = Disabled; // run Stop task process

runStop();

// send enable to the Stop task inStop!Enable; // receive enable ... :: else −> skip; ; } }

Listing 5.3. Promela process for the Task Play.

Environment Play PlayCD Stop

Start Start Active Active Stop Disabled Enabled Start Active Stop Disabled Stop Disabled Enable

5.3 Task Sequence Generation 63