Field effect transistor for Ionic Liquid Gating

the driver’s seat or the vehicle’s inside climate. The behavioral models of these components are illustrated in Figure 8.9.

8.4

Applying the selective test generation method after Toast evolution

To check the correctness of the evolved Toast application in a cost effective manner, we have to evolve the test suites by making use of the TestGenApp module. As introduced in Chapter 5, the first step in this module consists in comparing the initial behavioral model and the evolved one.

As output, it generates an Mdiff model that highlights the similarities and difference between

timed automata. It is worthy to note that several cases of evolution are studied in the following.

For each case, the obtained Mdiff model is automatically exported from the UPPAAL model

checker. For that reason, transition and location colors are not observable.

Let us take the example in which the Toast evolves from Case 0 to Case 1. Here, we focus on comparing the old GPS model outlined in Figure 8.2a and the evolved one depicted in Figure 8.3. Applying the model differencing step (see Algorithm 5.1, in Chapter 5), transitions labeled by getTime, Time, getStatus, Status, getAlt and Alt are marked as new transitions and their

corresponding locations are marked as new locations, as well. The obtained GPSdiff model is

highlighted in Figure 8.10.

Figure 8.10: The GPSdiff model from Case 0 to Case 1.

It points out that :

• for each new transition (i.e., colored in Red), the assignment col := col ∗ 0 is added;

• for each unchanged transition (i.e., transition labels as well as their source and target locations are colored in Green), the assignment col := col ∗ 1 is added;

8.4 Applying the selective test generation method after Toast evolution 120

• for each changed transition (i.e., at least its source location or its target location or its

labels are colored in Yellow), the assignment col := col ∗ 2 is added.

Once the model differencing algorithm is applied to each template in the SUT, we look for the old test suite classification. As already mentioned, the old test suite, which is issued from the initial Toast behavioral models, contains three traces. The latter are classified as follows :

• A reusable trace (i.e., covers unimpacted elements in the SUT): deploy! displayData?;

• Two retestable traces (i.e., may cover the impacted elements in the SUT) :

– getLat! Lat? getLong! Long? getHead! Head? getSpeed! Speed?;

– deploy! getLat? Lat! getLong? Long! getHead? Head! getSpeed? Speed! display- Data?;

Four new traces are generated by the UPPAAL CO√ER tool while using our proposed

observer automaton that covers edges in which the col variable is evaluated to zero : New unit tests for the GPS under test are generated :

a. getTime! Time? getStatus! Status?;

b. getLat! Lat? getLong! Long? getAlt! Alt?;

New unit tests for the Emergency Monitor under test are generated :

c. deploy! getTime? Time! getStatus? Status!;

d. deploy! getLat? Lat! getLong? Long! getAlt? Alt!;

Let us study now the evolution from Case 2 to Case 3 while focusing essentially on the GPS component. Tests issued from the old GPS model already illustrated in Figure 8.4 are the following :

a. getTime! TimeErr? getTime! Time?;

b. getLat! LatErr? getLat! Lat?;

c. getTime! Time? getStatus! StatusErr? getStatus! Status?;

d. getLat! Lat? getLong! LongErr? getLong! Long?;

e. getLat! Lat? getLong! Long? getAlt! Alt?;

8.4 Applying the selective test generation method after Toast evolution 121

g. getLat! Lat? getLong! Long? getHead! HeadErr? getHead! Head?;

h. getLat! Lat? getLong! Long? getHead! Head? getSpeed! SpeedErr? getSpeed! Speed?;

As outlined in Figure 8.11, the output of the model differencing module is given in which transitions labeled with Status and getStatus are removed. Moreover, several transition labels are changed since we consider in this case the elevation logging instead of the altitude. Consequently, the transitions impacted by these changes are marked with the assignment col := col ∗ 2.

Figure 8.11: The GPSdiff model from Case 2 to Case 3.

At this stage, the old test classification module is executed. First, it detects an obsolete test

that covers deleted transitions like getStatus and Status (i.e., TOb = {c}). Then, it identifies

some reusable tests which are still valid and unimpacted by these reductive changes (i.e., TRu =

{a, b, d , g, h}). Moreover, it distinguishes other tests that cannot be animated on the new GPS

model. These tests are classified as aborted (i.e., TAb = {e, f }) and need to be adapted as

follows:

• getLat! Lat? getLong! Long? getElev! Elev?;

• getLat! Lat? getLong! Long? getElev! ElevErr? getElev! Elev?;

Consider now the evolution from Case 3 to Case 4. In this scenario, the template Back End is newly added to the Toast architecture. Thus, all transitions in the Back End model are marked as new transitions. Consequently, for each one, the assignment col := col ∗ 0 is added.

It is worthy to note that the GPS component maintains the same behavior illustrated in Case 3. However, the Emergency Monitor is modified in order to send the measured data to the

8.4 Applying the selective test generation method after Toast evolution 122

Back End Component. Therefore, several locations and transitions are newly added and others are impacted by these changes.

Recall that the old test suite issued from the models in Case 3 consists of unit tests for the GPS component, unit tests for the Emergency Monitor and an integration test for their compo- sition. Old tests for the GPS are unimpacted by the change and are automatically classified as reusable tests. Regarding the Emergency Monitor, its old tests are classified as retestable tests

except an obsolete one. A new trace is generated by UPPAAL CO√ER as follows:

deploy! getLat? Lat! getLong? Long! getHead? Head! getSpeed? Speed! sendData? dataReply!.

Once the test generation process is achieved, the transformation of the abstract test sequences to concrete tests should be performed. Following the transformation rules already discussed in Chapter 5 Section 5.7, we illustrate the mapping of a sample unit test case of the Climate Monitor (i.e., InteriorTemp! sendTemp? upHeat! NewTemp? ) via the Listing 8.1.

1 ... 2 template f l o a t I n t e r i o r T e m p :={ d a t a : = 5 . 0 } 3 template f l o a t N e w T e m p :={ d a t a : = ? } 4 function f _ t c 0 () runs on M y P T C T y p e { 5 m t c P o r t .send( I n t e r i o r T e m p ); 6 alt{ 7 [] m t c P o r t .receive( s e n d T e m p ) { 8 setverdict( p a s s );} 9 [] m t c P o r t .receive { 10 setverdict ( f a i l ); stop 11 }}} 12 function f _ t c 1 () runs on M y P T C T y p e { 13 m t c P o r t .send( u p H e a t ); 14 alt { 15 [] m t c P o r t .receive( N e w t e m p ) { 16 setverdict ( p a s s );} 17 [] m t c P o r t .receive { 18 setverdict ( f a i l ); stop 19 }}}

20 testcase t c _ 1 () runs on M y M T C T y p e system s y s t e m T y p e { 21 var M y P T C T y p e ptc0 , p t c 1 ; 22 p t c 0 := M y P T C T y p e .create( p t c 0 ); 23 map( p t c 0 : ptcPort , s y s t e m : s y s t e m P o r t ); 24 p t c 0 .start( f _ t c 0 ( ) ) ; p t c 0 .done; 25 p t c 1 := M y P T C T y p e .create( p t c 1 ); 26 map( p t c 1 : ptcPort , s y s t e m : s y s t e m P o r t ); 27 p t c 1 .start( f _ t c 1 ( ) ) ; p t c 1 .done; 28 } 29 ...