research article formal specification based automatic test...

22
Research Article Formal Specification Based Automatic Test Generation for Embedded Network Systems Eun Hye Choi, 1 Hideaki Nishihara, 1 Takahiro Ando, 2 Nguyen Van Tang, 3 Masahiro Aoki, 4 Keiichi Yoshisaka, 4 Osamu Mizuno, 5 and Hitoshi Ohsaki 1 1 National Institute of Advanced Industrial Science and Technology, Japan 2 Kyushu University, Japan 3 Hanoi University of Industry, Vietnam 4 Daikin Industries, Ltd., Japan 5 Kyoto Institute of Technology, Japan Correspondence should be addressed to Eun Hye Choi; [email protected] Received 13 September 2013; Revised 22 November 2013; Accepted 24 November 2013; Published 11 May 2014 Academic Editor: Chin-Yu Huang Copyright © 2014 Eun Hye Choi et al. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Embedded systems have become increasingly connected and communicate with each other, forming large-scaled and complicated network systems. To make their design and testing more reliable and robust, this paper proposes a formal specification language called SENS and a SENS-based automatic test generation tool called TGSENS. Our approach is summarized as follows: (1) A user describes requirements of target embedded network systems by logical property-based constraints using SENS. (2) Given SENS specifications, test cases are automatically generated using a SAT-based solver. Filtering mechanisms to select efficient test cases are also available in our tool. (3) In addition, given a testing goal by the user, test sequences are automatically extracted from exhaustive test cases. We’ve implemented our approach and conducted several experiments on practical case studies. rough the experiments, we confirmed the efficiency of our approach in design and test generation of real embedded air-conditioning network systems. 1. Introduction An embedded network system (ENS) is a system consisting of a number of embedded units that communicate with each other. Nowadays, ENSs are growing rapidly and play- ing an important role in our daily life, such as in-vehicle networking systems, home appliance networks, and building energy management systems. On the other hand, because of the increasing complexity of functionality and growing network scales, as well as the increasing numbers and types of embedded units in ENSs, development of the ENSs has been becoming more and more difficult. Particularly, design and test generation are ones of the most important and cost-consuming phases in reliable ENS development, but many companies still rely on the traditional techniques where system requirements are described in a natural language and test cases are generated based on human experience. However, design and test by manpower may not sufficiently cover enormous numbers of combination to be considered especially for complicated ENSs. During the last decade, numerous formal methods have been proposed to improve soſtware quality. Especially, test generation is an attractive application for mechanized formal methods; the importance of good test cases is universally recognized and so is the high cost of generating them by hand. One of these methods, the model-based test generation, has been extensively studied (e.g., see [14]). One of the advantages of this technique is that each behavior of the system model is described directly, and then test cases can be automatically generated from the models. Note, however, that if test cases are generated from incomplete specifications and models, they suffer from the problem of lacking and low Hindawi Publishing Corporation Journal of Applied Mathematics Volume 2014, Article ID 909762, 21 pages http://dx.doi.org/10.1155/2014/909762

Upload: others

Post on 09-Sep-2020

5 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Research ArticleFormal Specification Based Automatic Test Generation forEmbedded Network Systems

Eun Hye Choi1 Hideaki Nishihara1 Takahiro Ando2 Nguyen Van Tang3 Masahiro Aoki4

Keiichi Yoshisaka4 Osamu Mizuno5 and Hitoshi Ohsaki1

1 National Institute of Advanced Industrial Science and Technology Japan2 Kyushu University Japan3Hanoi University of Industry Vietnam4Daikin Industries Ltd Japan5 Kyoto Institute of Technology Japan

Correspondence should be addressed to Eun Hye Choi echoiaistgojp

Received 13 September 2013 Revised 22 November 2013 Accepted 24 November 2013 Published 11 May 2014

Academic Editor Chin-Yu Huang

Copyright copy 2014 Eun Hye Choi et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Embedded systems have become increasingly connected and communicate with each other forming large-scaled and complicatednetwork systems To make their design and testing more reliable and robust this paper proposes a formal specification languagecalled SENS and a SENS-based automatic test generation tool called TGSENS Our approach is summarized as follows (1) A userdescribes requirements of target embedded network systems by logical property-based constraints using SENS (2) Given SENS

specifications test cases are automatically generated using a SAT-based solver Filtering mechanisms to select efficient test cases arealso available in our tool (3) In addition given a testing goal by the user test sequences are automatically extracted from exhaustivetest casesWersquove implemented our approach and conducted several experiments on practical case studiesThrough the experimentswe confirmed the efficiency of our approach in design and test generation of real embedded air-conditioning network systems

1 Introduction

An embedded network system (ENS) is a system consistingof a number of embedded units that communicate witheach other Nowadays ENSs are growing rapidly and play-ing an important role in our daily life such as in-vehiclenetworking systems home appliance networks and buildingenergy management systems On the other hand becauseof the increasing complexity of functionality and growingnetwork scales as well as the increasing numbers and typesof embedded units in ENSs development of the ENSs hasbeen becoming more and more difficult Particularly designand test generation are ones of the most important andcost-consuming phases in reliable ENS development butmany companies still rely on the traditional techniques wheresystem requirements are described in a natural language

and test cases are generated based on human experienceHowever design and test by manpower may not sufficientlycover enormous numbers of combination to be consideredespecially for complicated ENSs

During the last decade numerous formal methods havebeen proposed to improve software quality Especially testgeneration is an attractive application for mechanized formalmethods the importance of good test cases is universallyrecognized and so is the high cost of generating them byhandOne of thesemethods themodel-based test generationhas been extensively studied (eg see [1ndash4]) One of theadvantages of this technique is that each behavior of thesystem model is described directly and then test cases canbe automatically generated from the models Note howeverthat if test cases are generated from incomplete specificationsand models they suffer from the problem of lacking and low

Hindawi Publishing CorporationJournal of Applied MathematicsVolume 2014 Article ID 909762 21 pageshttpdxdoiorg1011552014909762

2 Journal of Applied Mathematics

quality of test cases Therefore formal specification basedmodeling and test generation for large-scale ENSs are stillchallenges

This paper presents our works gained in a joint project ofAIST DaiKin Industries and Kyoto Institue of TechnoIogyThe ultimate goal of our project is to develop a robustand reliable automatic test generation tool suitable for adevelopment process of air-conditioning network systemsdeveloped by Daikin (We refer to the company as CompanyD in the rest of this paper) The target system consistsof a number of embedded controllers and indooroutdoorair-conditioning equipment for building management Forthis project we have taken an approach of automatic testgeneration based on a formal specification In the followingwe present three main contributions toward our overall goal

(i) Development of a Formal Specification Language Firstwe have developed a specification language for ENSscalled SENS (Specification language for EmbeddedNetwork Systems) SENS is designed under the con-cept of test-oriented object-oriented modular andlightweight description of ENSs In SENS system therequirements are specified using logical constraintsThis logical property rigorously determines a set ofstate transitions that satisfy all constraints and thushelps to get the specification without lacking andinconsistency and clearly obtain an advantage over amanpower design of system and test

(ii) Development of a Test Case Generator Second wehave developed a tool calledTGSENS (Test Generatorbased on SENS) which automatically generates highquality test cases from a given specification writtenin SENS Our tool can find distinct and enormoustest cases quickly that satisfy complex specificationsusing a SAT solver as a core engine Our tool canalso perform filtering to select efficient test casesIn a feasibility study using air-conditioning systemsof Company D given a specification for a certainfunction of the system our tool took only about 12seconds to generate 77700 test cases We expect thatour tool will provide both quality improvement andcost saving for testing target ENSs

(iii) Development of a Test Sequence Generator Third wehave also developed a tool in TGSENS to generatetest sequences that satisfy a given testing goal by auser In an experiment using components of the targetair-conditioning systems our tool generated 156 testsequences in 8 minutes for a given testing goal suchthat the sequence contains 2 milestone states whosedistance is less than 3 state transitions We confirmedthat our tool is helpful for test engineers to design testscenarios efficiently

The rest of this paper is organized as follows In thenext section we briefly introduce the overview of our workand our tool Section 3 describes the features syntax andsemantics of the SENS language In Section 4 we pro-pose the method for generating test cases and sequences

from SENS specifications Section 5 presents experimen-tal results when applying our tool to the air-conditioningsystems of Company D Section 6 discusses related worksFinally we conclude our work and mention future works inSection 7

2 Overview of Our Work

Our target system is an embedded network system (ENS) AnENS can be considered as a concurrent system consisting ofmultiple subsystems with global environments for exampleembedded indoor and outdoor equipment and controllers inan air-conditioning network system as illustrated in Figure 1Each subsystem in an ENS is an event-triggered systemwhose events are communications with other subsystems andwhose operations are constrained by conditions related to itsenvironment and time

The behaviors of an ENS are specified in a hierarchicalway an ENS consists of subsystems a subsystem is con-structed from its functions and each function is constructedfrom a set of functional requirements as described inFigure 1 To enhance the reliability and efficiency of designand testing ENSs we first focus on designing and modelinga formal specification language for ENSs called SENSwhich supports the hierarchy of ENSs and is convenient forour test generation purpose We next achieve an automatictest generation approach based on SENS called TGSENSFigure 2 illustrates the overview of our tool that consists ofthe following 5 steps

(1) Specifying Requirements in SENS A user describessystem requirements of the target ENS using SENSFor the air-conditioning systems of Company Dwe have translated original specification documentswritten in a natural language to formal specificationsin SENS

(2) Translating SENS Specifications to CNF The SENS

translator first performs the syntax and type checkingfor the given SENS specification Next the transla-tor automatically transforms logical requirements ofthe SENS specification to CNF (conjunctive normalform) formulas according to our translation rules

(3) Solving CNF Formulas Using a SAT Solver The CNFformulas obtained in Step (2) are imported as aninput of the solver The solver automatically findsall possible assignments that satisfy the input CNFformulas by iteratively using a SAT solver

(4) Mapping from Assignments to Test Cases The setof possible assignments obtained in Step (3) areautomatically mapped to the set of state transitionscorresponding to one-step test cases

(5) Generating Test Sequences under a Testing GoalWhena user gives a testing goal including remarkable statesand lengths of sequences a set of test sequencesare automatically derived from the test cases (statetransitions) obtained in Step (4)

Journal of Applied Mathematics 3

An air-conditioning system

Environment

Specifying

SENS specification

Import Controller InEquip OutEquipClass mainVar temp double[minus320 955]middot middot middotin1 InEquip(out1)middot middot middot mainspec

Class ControllerClass OutEquip(in InEquip)

Class InEquip(out OutEquip)Var Channel Timer InEquipspec

Bundled InEquipFunction antifreeze

antifreezespec

Systemlevel

Subsystemlevel

Functionlevel

Figure 1 An air-conditioning system and its SENS specification

Testsequence

Test cases

OutputInput

Spec

Testinggoal

translator

TGSENS

CNF

Solver(filtering)

Core engineMiniSAT

Test sequence finder

Assign-ments

Test casetranslator

SENSSENS

Figure 2 An overview of TGSENS

3 SENS Specification

In this section we present a compact formal language calledSENS to specify requirements of embedded network systems(ENSs) In Section 31 we present features of SENS InSections 32 and 33 we briefly describe the syntax andsemantics of SENS

31 Features of SENS The SENS specification is basically aset of requirements represented by logical formulas SENSis based on a quantifier-free predicate modal logic with anext operator where predicate variables are classified intoenvironments systems communication channels and timervariables SENS has the following features

311 Property-Based Property-based logical formulas repre-sent requirements which constrain system behaviors Since apart of the specification less affects the entire specification it

is easy to modify and reuse SENS specifications A require-ment is described in a traditional Hoare triple-like way

⟨119901119903119890 119890V119890119899119905 (119901119900119904119905 119886119888119905119894119900119899)⟩ (1)

where 119901119903119890 (resp 119901119900119904119905) denotes a logical constraint holdingin a prestate (resp poststate) and an 119890V119890119899119905 (resp 119886119888119905119894119900119899)represents a message receiving (resp sending) betweensubsystems This 3-tuple requirement needs to hold for alltransitions of the system model and we call this 3-tuplerequirement a transition requirement

312 Test-Oriented For a testing purpose specifying testedvalues and bounds of variables is available in the variabledeclaration This supports a test-oriented design and anefficient test generation from SENS specifications

313 Object-Oriented A group of subsystems is representedas a parameterized class and each subsystem is defined as an

4 Journal of Applied Mathematics

instance of the class in the main class representing the wholesystemThis representation leads to an efficient description ofa large number of subsystems in an ENS

314 Modular Specifications of an ENS a subsystem and afunction are broken down into specifications of subsystemsfunctions and transition requirements respectively Thismodular construction makes it easy to specify a large-scaledand complicated ENS piece by piece and provide a reusabilityof specifications This also allows a step-wise test generationfrom SENS specifications for unit testing integration testingand system testing

315 Lightweight Description of Time Constraints We con-sider a timer as a component of a subsystem and then specifytime constraints using events and actions with the timerSENS provides a timer variable which is declaredwith a time-value a time-unit and a condition formula for counting upthe timer

32 Syntax of SENS Here we give the brief explanationof SENS description using the following example embeddedsystem

Example 1 Consider an illustrating system in Figure 3Thereare 2 kinds of equipment namely classes 119860 and 119861 Let usconsider a simple ENS consisting of 3 subsystems 119860

1 1198611 and

1198612 where119860

1is an instance of119860 and119861

1and119861

2are instances of

119861 A subsystem of class 119860 sends a message 119898 after 2 minutesfrom starting its operation Each subsystem of class 119861 turnson its lamp when receiving message 119898 This system can bedescribed in the SENS specification of Pseudocode 1

The SENS declarations consist of the following declara-tions (refer to Appendix A for the full syntax of SENS)

(i) Main Class Declaration File ltmainclsgt specifies themain class The main class represents the whole systemconsisting of subsystems and the environment In the fileltmainclsgt of Pseudocode 1 the classes 119860 and 119861 areimported in line 1 and subsystems 119860

1 1198611 and 119861

2are instan-

tiated in lines 6-7 Environment variables are declared in theVar part Data types environment variables and channelsdeclared in themain class are referred in all class declarationsInvariants (logical expressions) for the entire system aredeclared in the main class In the example ltmainclsgtglobal data type onoff status is declared in lines 3-4

(ii) Class Declaration Files ltAclsgt and ltBclsgt ofPseudocode 1 specify classes 119860 and 119861 respectively 119860 classother than the main class specifies a class of subsystemsLocal data types variables channels and timers for thesubsystem are declared in the class declaration In ltAclsgtlocal variable op and timer t are declared in lines 6ndash9 and afunction of the subsystem is declared in lines 11ndash14

For data types variables channels and timers externallydeclared and internally used the files to declare them areimported with the Import statement and their names aredescribed in the Extern part The main class file is imported

ltmainclsgt

(1) Import A B

(2) Class main

(3) Data

(4) onoff status onoff

(5) Var

(6) B1 B2 B(7) A1 A(B1 B2)

ltAclsgt

(1) Import B

(2) Extern

(3) Data

(4) onoff status from main

(5) Class A(arg1 B arg2 B)

(6) Var

(7) op onoff status off

(8) Timer

(9) t 2 min

(10)(11) Function SendingM

(12) Require

(13) sim op==off ampamp op==on null tstart

(14) op==on tring arg1chmarg2chm

ltBclsgt

(1) Extern

(2) Data

(3) onoff status from main

(4) Class B

(5) Data

(6) m type m

(7) Var

(8) op onoff status off

(9) lamp onoff status off

(10) Channel

(11) ch m type

(12)(13) Function Lighting

(14) Require

(15) op==on ampamp lamp==off chmlamp==on

(16) op==off minusgt lamp==off

Pseudocode 1 An example SENS specification

to all class files by default A class can have parameters usedas constants in the class specification In line 1 of ltAclsgtclass 119861 is imported since class 119861 is used in the parameterdeclaration of 119860 In lines 3-4 data type onoff status isdescribed in the Extern part

(iii) Variable and Data Type Declarations A variable isdeclared with its name type initial value and test declaration(values and bounds for testing) in the part following to VarData types are int and doublewith ranges and enumerateddata types are defined in the Data part In the Data parta type is defined as a set of values In SENS only finiteand discrete values are used In the exampleltmainclsgta global data type onoff status which has two elementson and off is declared in lines 3-4 In ltBclsgt a localdata type m type which has the only element m is declared

Journal of Applied Mathematics 5

System

Subsystem A1

Subsystem B1

Subsystem B2

m

m

Figure 3 An example embedded system

in lines 5-6 Using the test declaration beginning with thekeywordtestedwith one can define the specific values ofvariables to be considered in a testing phase For exampleconsider the following variable declaration

Var v1 double [-2 5] 0

testedwith -2 05 (05)

variable v1 is defined as follows its type is double its rangeis minus2 le v1le 5 its initial value 0 and its tested values areminus2 and a number from 0 to 5 in increments of 05 In oursemantics of SENS each variable of a subsystem takes onevalue that is an element of its domain If the declaration ofa variable has a test declaration the domain is defined by thetest declaration Otherwise the domain is defined by the datatype of the variable

(iv) Channel and Timer Declarations Channels are used todescribe communications between subsystems A channelis declared with its name and message type In lines 10-11 of ltBclsgt a channel ch for receiving message m isdeclared A timer is declared with its name time-value unitand conditions (logical formula) for counting up Whenthe condition is omitted the condition is always true Forexample consider the following timer declarations

Timer

t1 5 mint2 5 hour [(v==dry) || (v==cool)]

Timer t1 is declared to count up 5 minutes Timer t2 isdeclared to count up 5 hours but the counting is performedonly when the value of v is dry or cool

The event is a message receiving (channel-nameexpr)or timeout (timer-namering) Similarly the action is amessage sending (channel-nameexpr) timer starting (timer-namestart) or timer reset (timer-nameclear) When spec-ifying a communication between subsystems a messagesending (action) is described using both a recipientrsquos objectname and a channel name while a message receiving (event)is described using only a channel name

(v) Function and Requirement Declarations Functions aredeclared in the class declaration or in individual functiondeclaration files In the function declaration constants datatypes variables and timers can be defined locally A functioncontains a set of requirements

A requirement is an expression representing an invariantor a 3-tuple of a precondition an event and a postconditionorwithwithout actions (More precisely the third part ofthe transition requirement is a postcondition or an action oractions or a postcondition with an action or a postconditionwith actions) We call the 3-tuple requirement a transitionrequirement The BNF description for a transition require-ment is given in Algorithm 1 (Refer to Appendix A4)

The precondition and postcondition are logical expres-sions In the transition requirement declaration the eventpart can contain no more than one event (it can also be nullwhich is a symbol showing that no event occurs) while theaction part can contain multiple actions We assume that atransition requirement contains no more than one event andactions related to the same timer

Expressions are constructed with constants variablesand operators Expressions have logical comparison andarithmetic operators that general programming languagessuch as C have In addition expressions in SENS have thelogical implication operator (ndashgt) and the previous state oper-ator (sim) Especially expression sim v represents the previousvalue of v

33 Semantics of SENS A SENS specification describesrequirements of an ENS consisting of subsystems com-municating each other We model the system specified bySENS using a labeled transition system Figure 4 illustratesour system modeling where time constraints in SENS aremodeled using our timer models that will be shown laterFirst each instance corresponding to a subsystem in thegiven specification ismodeledWhen the class correspondingto the subsystem contains timer variables we compose thesubsystem model and its timer models Next an entire ENSis modeled as a parallel composition of all subsystems Thetransition system modeled from the SENS specification isused for generating test cases and test sequences

In Section 331 we give the modeling of timers InSection 332 we give the modeling of a subsystem andexplain the composition of the subsystem and the timer InSection 333 we explain the composition of subsystems

331 Modeling of Timers A timer is specified in the timerdeclaration with its timer name number (time) unit andconditions for counting up in SENS We consider twokinds of models 119872

1and 119872

2for timers expressed in Figures

5(a) and 5(b) We can use simpler timer model 1198722for

state elimination while we can use timer model 1198721for

considering the relation of a time length between timers (referto Section 332)

Definition 2 (timer model) We model the behavior of eachtimer119879

119894as a labeled transition system (119878

119879119894 Σ119879119894

119877119879119894

)with119877119879119894

sube

119878119879119894

times Σ119879119894

times 119878119879119894 where 119878

119879119894denotes a set of states Σ

119879119894denotes

a set of labels and 119877119879119894denotes a labeled transition for 119879

119894

(119878119879119894

Σ119879119894

119877119879119894

) for 1198721and 119872

2are defined as follows

(i) 119878119879119894

= ready 0 1 max over in 1198721

(ii) 119878119879119894

= ready run over in 1198722

6 Journal of Applied Mathematics

Entire system

Sub-system 1 Sub-system n

Timer 1 Timer m Timer 1 Timer m998400

middot middot middot middot middot middot

middot middot middotmiddot middot middot middot middot middot

Figure 4 A model composition for the entire ENS

requirement-declaration=invariant | transition-requirement

invariant= exprtransition-requirement=

pre-condition ldquordquo event ldquordquo(post-condition | (action (ldquordquo | action)lowast)| (post-condition ldquordquo(action (ldquordquo | action)lowast)))

Algorithm 1 The BNF description for a transition requirement

(iii) Σ119879119894

= start clear ring c in 1198721 1198722

In models 1198721and 119872

2 states ready and over respec-

tively represent states in which timer 119879119894is ready and counted

over In model 1198721 state ldquoℎrdquo (0 le ℎ le max) represents a state

in which timer 119879119894has counted up ℎ times In model 119872

2 we

reduce states 0 max to state run representing a state inwhich timer 119879

119894is running for the state elimination

In both models each state is changed to state readywhen receiving message clear State ready is changed tostate 0 in 119872

1(resp state run in 119872

2) when receiving message

start State max in 1198721(resp state run in 119872

2) is changed

to stateover when sending message ring We define thattransitions labeled with 119904119905119886119903119905 and c occur only if thecondition for the timer holds If the condition is not describedin the timer declaration the condition is considered to beldquotruerdquo

If there aremultiple conditions 119901 119902 119903 we define tran-sitions as represented in Figure 5(c) In the figure transitionslabeled with clear are eliminated for simplicity In thefigure the first second and third transitions labeled with coccur when conditions 119901 119902 and 119903 respectively hold

332 Modeling of Subsystems A subsystem is specified in theclass declaration in SENS For a given specification wemodelthe behavior of each subsystem as a labeled transition systemin two steps First the behavior of a subsystem 119862

119894except

timers is modeled as a labeled transition system 119872(119862119894) Next

the behavior of a subsystem including timers is modeled as

clearclear

clearclear

clear

readystart ring

max overc

0 1c c

middot middot middot

(a) Model1198721clear

clear clear

readystart ring

run over

c

(b) Model1198722

ready

start

start

start

run

run

run

over

c

c

c

ring

ring

ring

p holds(not p and q) holds(not p and not q and and r) holds

(c) Model11987210158402for timers with multiple conditions

Figure 5 Timer Models

119872119879

(119862119894) which is a composition of 119872(119862

119894) and models of the

timers

Definition 3 (subsystem model) We model the behavior of asubsystem 119862

119894 except for its timers as 119872(119862

119894) = (119878

119862119894 Σ119862119894

119877119862119894

)

with 119877119862119894

sube 119878119862119894

times Σ119862119894

times 119878119862119894 Given a SENS specification the

set of states 119878119862119894 the set of labels Σ

119862119894 and the set of transitions

119877119862119894are obtained by Definitions 15 16 and 17 of Appendix B1

Example 4 Consider the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 6 illustrates

the subsystem model for 119862119860

which satisfies thespecification Given SENS specification for class 119860the states are (simop=off op=off) (simop=off op=on)(simop=onop=on) and (simop=on op=off) from variable opand previous state variable simop used in the specification byDefinition 15 By Definition 16 the labels are tstart tringB[1] chm and B[2] chm with the events and actionsused in the specification Each transition in 119872(119862

119860) satisfies

the two conditions in Definition 17 For example 119904 rarr 1199041015840

with 119904 = (simop=offop=off) and 1199041015840 = (simop=onop=off)cannot be a transition of 119872(119862

119860) since it does not hold the

condition for previous state variables that is 119904 ⊨ (op=on) ifand only if 119904

1015840 ⊨ (simop=on) by Definition 17

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 2: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

2 Journal of Applied Mathematics

quality of test cases Therefore formal specification basedmodeling and test generation for large-scale ENSs are stillchallenges

This paper presents our works gained in a joint project ofAIST DaiKin Industries and Kyoto Institue of TechnoIogyThe ultimate goal of our project is to develop a robustand reliable automatic test generation tool suitable for adevelopment process of air-conditioning network systemsdeveloped by Daikin (We refer to the company as CompanyD in the rest of this paper) The target system consistsof a number of embedded controllers and indooroutdoorair-conditioning equipment for building management Forthis project we have taken an approach of automatic testgeneration based on a formal specification In the followingwe present three main contributions toward our overall goal

(i) Development of a Formal Specification Language Firstwe have developed a specification language for ENSscalled SENS (Specification language for EmbeddedNetwork Systems) SENS is designed under the con-cept of test-oriented object-oriented modular andlightweight description of ENSs In SENS system therequirements are specified using logical constraintsThis logical property rigorously determines a set ofstate transitions that satisfy all constraints and thushelps to get the specification without lacking andinconsistency and clearly obtain an advantage over amanpower design of system and test

(ii) Development of a Test Case Generator Second wehave developed a tool calledTGSENS (Test Generatorbased on SENS) which automatically generates highquality test cases from a given specification writtenin SENS Our tool can find distinct and enormoustest cases quickly that satisfy complex specificationsusing a SAT solver as a core engine Our tool canalso perform filtering to select efficient test casesIn a feasibility study using air-conditioning systemsof Company D given a specification for a certainfunction of the system our tool took only about 12seconds to generate 77700 test cases We expect thatour tool will provide both quality improvement andcost saving for testing target ENSs

(iii) Development of a Test Sequence Generator Third wehave also developed a tool in TGSENS to generatetest sequences that satisfy a given testing goal by auser In an experiment using components of the targetair-conditioning systems our tool generated 156 testsequences in 8 minutes for a given testing goal suchthat the sequence contains 2 milestone states whosedistance is less than 3 state transitions We confirmedthat our tool is helpful for test engineers to design testscenarios efficiently

The rest of this paper is organized as follows In thenext section we briefly introduce the overview of our workand our tool Section 3 describes the features syntax andsemantics of the SENS language In Section 4 we pro-pose the method for generating test cases and sequences

from SENS specifications Section 5 presents experimen-tal results when applying our tool to the air-conditioningsystems of Company D Section 6 discusses related worksFinally we conclude our work and mention future works inSection 7

2 Overview of Our Work

Our target system is an embedded network system (ENS) AnENS can be considered as a concurrent system consisting ofmultiple subsystems with global environments for exampleembedded indoor and outdoor equipment and controllers inan air-conditioning network system as illustrated in Figure 1Each subsystem in an ENS is an event-triggered systemwhose events are communications with other subsystems andwhose operations are constrained by conditions related to itsenvironment and time

The behaviors of an ENS are specified in a hierarchicalway an ENS consists of subsystems a subsystem is con-structed from its functions and each function is constructedfrom a set of functional requirements as described inFigure 1 To enhance the reliability and efficiency of designand testing ENSs we first focus on designing and modelinga formal specification language for ENSs called SENSwhich supports the hierarchy of ENSs and is convenient forour test generation purpose We next achieve an automatictest generation approach based on SENS called TGSENSFigure 2 illustrates the overview of our tool that consists ofthe following 5 steps

(1) Specifying Requirements in SENS A user describessystem requirements of the target ENS using SENSFor the air-conditioning systems of Company Dwe have translated original specification documentswritten in a natural language to formal specificationsin SENS

(2) Translating SENS Specifications to CNF The SENS

translator first performs the syntax and type checkingfor the given SENS specification Next the transla-tor automatically transforms logical requirements ofthe SENS specification to CNF (conjunctive normalform) formulas according to our translation rules

(3) Solving CNF Formulas Using a SAT Solver The CNFformulas obtained in Step (2) are imported as aninput of the solver The solver automatically findsall possible assignments that satisfy the input CNFformulas by iteratively using a SAT solver

(4) Mapping from Assignments to Test Cases The setof possible assignments obtained in Step (3) areautomatically mapped to the set of state transitionscorresponding to one-step test cases

(5) Generating Test Sequences under a Testing GoalWhena user gives a testing goal including remarkable statesand lengths of sequences a set of test sequencesare automatically derived from the test cases (statetransitions) obtained in Step (4)

Journal of Applied Mathematics 3

An air-conditioning system

Environment

Specifying

SENS specification

Import Controller InEquip OutEquipClass mainVar temp double[minus320 955]middot middot middotin1 InEquip(out1)middot middot middot mainspec

Class ControllerClass OutEquip(in InEquip)

Class InEquip(out OutEquip)Var Channel Timer InEquipspec

Bundled InEquipFunction antifreeze

antifreezespec

Systemlevel

Subsystemlevel

Functionlevel

Figure 1 An air-conditioning system and its SENS specification

Testsequence

Test cases

OutputInput

Spec

Testinggoal

translator

TGSENS

CNF

Solver(filtering)

Core engineMiniSAT

Test sequence finder

Assign-ments

Test casetranslator

SENSSENS

Figure 2 An overview of TGSENS

3 SENS Specification

In this section we present a compact formal language calledSENS to specify requirements of embedded network systems(ENSs) In Section 31 we present features of SENS InSections 32 and 33 we briefly describe the syntax andsemantics of SENS

31 Features of SENS The SENS specification is basically aset of requirements represented by logical formulas SENSis based on a quantifier-free predicate modal logic with anext operator where predicate variables are classified intoenvironments systems communication channels and timervariables SENS has the following features

311 Property-Based Property-based logical formulas repre-sent requirements which constrain system behaviors Since apart of the specification less affects the entire specification it

is easy to modify and reuse SENS specifications A require-ment is described in a traditional Hoare triple-like way

⟨119901119903119890 119890V119890119899119905 (119901119900119904119905 119886119888119905119894119900119899)⟩ (1)

where 119901119903119890 (resp 119901119900119904119905) denotes a logical constraint holdingin a prestate (resp poststate) and an 119890V119890119899119905 (resp 119886119888119905119894119900119899)represents a message receiving (resp sending) betweensubsystems This 3-tuple requirement needs to hold for alltransitions of the system model and we call this 3-tuplerequirement a transition requirement

312 Test-Oriented For a testing purpose specifying testedvalues and bounds of variables is available in the variabledeclaration This supports a test-oriented design and anefficient test generation from SENS specifications

313 Object-Oriented A group of subsystems is representedas a parameterized class and each subsystem is defined as an

4 Journal of Applied Mathematics

instance of the class in the main class representing the wholesystemThis representation leads to an efficient description ofa large number of subsystems in an ENS

314 Modular Specifications of an ENS a subsystem and afunction are broken down into specifications of subsystemsfunctions and transition requirements respectively Thismodular construction makes it easy to specify a large-scaledand complicated ENS piece by piece and provide a reusabilityof specifications This also allows a step-wise test generationfrom SENS specifications for unit testing integration testingand system testing

315 Lightweight Description of Time Constraints We con-sider a timer as a component of a subsystem and then specifytime constraints using events and actions with the timerSENS provides a timer variable which is declaredwith a time-value a time-unit and a condition formula for counting upthe timer

32 Syntax of SENS Here we give the brief explanationof SENS description using the following example embeddedsystem

Example 1 Consider an illustrating system in Figure 3Thereare 2 kinds of equipment namely classes 119860 and 119861 Let usconsider a simple ENS consisting of 3 subsystems 119860

1 1198611 and

1198612 where119860

1is an instance of119860 and119861

1and119861

2are instances of

119861 A subsystem of class 119860 sends a message 119898 after 2 minutesfrom starting its operation Each subsystem of class 119861 turnson its lamp when receiving message 119898 This system can bedescribed in the SENS specification of Pseudocode 1

The SENS declarations consist of the following declara-tions (refer to Appendix A for the full syntax of SENS)

(i) Main Class Declaration File ltmainclsgt specifies themain class The main class represents the whole systemconsisting of subsystems and the environment In the fileltmainclsgt of Pseudocode 1 the classes 119860 and 119861 areimported in line 1 and subsystems 119860

1 1198611 and 119861

2are instan-

tiated in lines 6-7 Environment variables are declared in theVar part Data types environment variables and channelsdeclared in themain class are referred in all class declarationsInvariants (logical expressions) for the entire system aredeclared in the main class In the example ltmainclsgtglobal data type onoff status is declared in lines 3-4

(ii) Class Declaration Files ltAclsgt and ltBclsgt ofPseudocode 1 specify classes 119860 and 119861 respectively 119860 classother than the main class specifies a class of subsystemsLocal data types variables channels and timers for thesubsystem are declared in the class declaration In ltAclsgtlocal variable op and timer t are declared in lines 6ndash9 and afunction of the subsystem is declared in lines 11ndash14

For data types variables channels and timers externallydeclared and internally used the files to declare them areimported with the Import statement and their names aredescribed in the Extern part The main class file is imported

ltmainclsgt

(1) Import A B

(2) Class main

(3) Data

(4) onoff status onoff

(5) Var

(6) B1 B2 B(7) A1 A(B1 B2)

ltAclsgt

(1) Import B

(2) Extern

(3) Data

(4) onoff status from main

(5) Class A(arg1 B arg2 B)

(6) Var

(7) op onoff status off

(8) Timer

(9) t 2 min

(10)(11) Function SendingM

(12) Require

(13) sim op==off ampamp op==on null tstart

(14) op==on tring arg1chmarg2chm

ltBclsgt

(1) Extern

(2) Data

(3) onoff status from main

(4) Class B

(5) Data

(6) m type m

(7) Var

(8) op onoff status off

(9) lamp onoff status off

(10) Channel

(11) ch m type

(12)(13) Function Lighting

(14) Require

(15) op==on ampamp lamp==off chmlamp==on

(16) op==off minusgt lamp==off

Pseudocode 1 An example SENS specification

to all class files by default A class can have parameters usedas constants in the class specification In line 1 of ltAclsgtclass 119861 is imported since class 119861 is used in the parameterdeclaration of 119860 In lines 3-4 data type onoff status isdescribed in the Extern part

(iii) Variable and Data Type Declarations A variable isdeclared with its name type initial value and test declaration(values and bounds for testing) in the part following to VarData types are int and doublewith ranges and enumerateddata types are defined in the Data part In the Data parta type is defined as a set of values In SENS only finiteand discrete values are used In the exampleltmainclsgta global data type onoff status which has two elementson and off is declared in lines 3-4 In ltBclsgt a localdata type m type which has the only element m is declared

Journal of Applied Mathematics 5

System

Subsystem A1

Subsystem B1

Subsystem B2

m

m

Figure 3 An example embedded system

in lines 5-6 Using the test declaration beginning with thekeywordtestedwith one can define the specific values ofvariables to be considered in a testing phase For exampleconsider the following variable declaration

Var v1 double [-2 5] 0

testedwith -2 05 (05)

variable v1 is defined as follows its type is double its rangeis minus2 le v1le 5 its initial value 0 and its tested values areminus2 and a number from 0 to 5 in increments of 05 In oursemantics of SENS each variable of a subsystem takes onevalue that is an element of its domain If the declaration ofa variable has a test declaration the domain is defined by thetest declaration Otherwise the domain is defined by the datatype of the variable

(iv) Channel and Timer Declarations Channels are used todescribe communications between subsystems A channelis declared with its name and message type In lines 10-11 of ltBclsgt a channel ch for receiving message m isdeclared A timer is declared with its name time-value unitand conditions (logical formula) for counting up Whenthe condition is omitted the condition is always true Forexample consider the following timer declarations

Timer

t1 5 mint2 5 hour [(v==dry) || (v==cool)]

Timer t1 is declared to count up 5 minutes Timer t2 isdeclared to count up 5 hours but the counting is performedonly when the value of v is dry or cool

The event is a message receiving (channel-nameexpr)or timeout (timer-namering) Similarly the action is amessage sending (channel-nameexpr) timer starting (timer-namestart) or timer reset (timer-nameclear) When spec-ifying a communication between subsystems a messagesending (action) is described using both a recipientrsquos objectname and a channel name while a message receiving (event)is described using only a channel name

(v) Function and Requirement Declarations Functions aredeclared in the class declaration or in individual functiondeclaration files In the function declaration constants datatypes variables and timers can be defined locally A functioncontains a set of requirements

A requirement is an expression representing an invariantor a 3-tuple of a precondition an event and a postconditionorwithwithout actions (More precisely the third part ofthe transition requirement is a postcondition or an action oractions or a postcondition with an action or a postconditionwith actions) We call the 3-tuple requirement a transitionrequirement The BNF description for a transition require-ment is given in Algorithm 1 (Refer to Appendix A4)

The precondition and postcondition are logical expres-sions In the transition requirement declaration the eventpart can contain no more than one event (it can also be nullwhich is a symbol showing that no event occurs) while theaction part can contain multiple actions We assume that atransition requirement contains no more than one event andactions related to the same timer

Expressions are constructed with constants variablesand operators Expressions have logical comparison andarithmetic operators that general programming languagessuch as C have In addition expressions in SENS have thelogical implication operator (ndashgt) and the previous state oper-ator (sim) Especially expression sim v represents the previousvalue of v

33 Semantics of SENS A SENS specification describesrequirements of an ENS consisting of subsystems com-municating each other We model the system specified bySENS using a labeled transition system Figure 4 illustratesour system modeling where time constraints in SENS aremodeled using our timer models that will be shown laterFirst each instance corresponding to a subsystem in thegiven specification ismodeledWhen the class correspondingto the subsystem contains timer variables we compose thesubsystem model and its timer models Next an entire ENSis modeled as a parallel composition of all subsystems Thetransition system modeled from the SENS specification isused for generating test cases and test sequences

In Section 331 we give the modeling of timers InSection 332 we give the modeling of a subsystem andexplain the composition of the subsystem and the timer InSection 333 we explain the composition of subsystems

331 Modeling of Timers A timer is specified in the timerdeclaration with its timer name number (time) unit andconditions for counting up in SENS We consider twokinds of models 119872

1and 119872

2for timers expressed in Figures

5(a) and 5(b) We can use simpler timer model 1198722for

state elimination while we can use timer model 1198721for

considering the relation of a time length between timers (referto Section 332)

Definition 2 (timer model) We model the behavior of eachtimer119879

119894as a labeled transition system (119878

119879119894 Σ119879119894

119877119879119894

)with119877119879119894

sube

119878119879119894

times Σ119879119894

times 119878119879119894 where 119878

119879119894denotes a set of states Σ

119879119894denotes

a set of labels and 119877119879119894denotes a labeled transition for 119879

119894

(119878119879119894

Σ119879119894

119877119879119894

) for 1198721and 119872

2are defined as follows

(i) 119878119879119894

= ready 0 1 max over in 1198721

(ii) 119878119879119894

= ready run over in 1198722

6 Journal of Applied Mathematics

Entire system

Sub-system 1 Sub-system n

Timer 1 Timer m Timer 1 Timer m998400

middot middot middot middot middot middot

middot middot middotmiddot middot middot middot middot middot

Figure 4 A model composition for the entire ENS

requirement-declaration=invariant | transition-requirement

invariant= exprtransition-requirement=

pre-condition ldquordquo event ldquordquo(post-condition | (action (ldquordquo | action)lowast)| (post-condition ldquordquo(action (ldquordquo | action)lowast)))

Algorithm 1 The BNF description for a transition requirement

(iii) Σ119879119894

= start clear ring c in 1198721 1198722

In models 1198721and 119872

2 states ready and over respec-

tively represent states in which timer 119879119894is ready and counted

over In model 1198721 state ldquoℎrdquo (0 le ℎ le max) represents a state

in which timer 119879119894has counted up ℎ times In model 119872

2 we

reduce states 0 max to state run representing a state inwhich timer 119879

119894is running for the state elimination

In both models each state is changed to state readywhen receiving message clear State ready is changed tostate 0 in 119872

1(resp state run in 119872

2) when receiving message

start State max in 1198721(resp state run in 119872

2) is changed

to stateover when sending message ring We define thattransitions labeled with 119904119905119886119903119905 and c occur only if thecondition for the timer holds If the condition is not describedin the timer declaration the condition is considered to beldquotruerdquo

If there aremultiple conditions 119901 119902 119903 we define tran-sitions as represented in Figure 5(c) In the figure transitionslabeled with clear are eliminated for simplicity In thefigure the first second and third transitions labeled with coccur when conditions 119901 119902 and 119903 respectively hold

332 Modeling of Subsystems A subsystem is specified in theclass declaration in SENS For a given specification wemodelthe behavior of each subsystem as a labeled transition systemin two steps First the behavior of a subsystem 119862

119894except

timers is modeled as a labeled transition system 119872(119862119894) Next

the behavior of a subsystem including timers is modeled as

clearclear

clearclear

clear

readystart ring

max overc

0 1c c

middot middot middot

(a) Model1198721clear

clear clear

readystart ring

run over

c

(b) Model1198722

ready

start

start

start

run

run

run

over

c

c

c

ring

ring

ring

p holds(not p and q) holds(not p and not q and and r) holds

(c) Model11987210158402for timers with multiple conditions

Figure 5 Timer Models

119872119879

(119862119894) which is a composition of 119872(119862

119894) and models of the

timers

Definition 3 (subsystem model) We model the behavior of asubsystem 119862

119894 except for its timers as 119872(119862

119894) = (119878

119862119894 Σ119862119894

119877119862119894

)

with 119877119862119894

sube 119878119862119894

times Σ119862119894

times 119878119862119894 Given a SENS specification the

set of states 119878119862119894 the set of labels Σ

119862119894 and the set of transitions

119877119862119894are obtained by Definitions 15 16 and 17 of Appendix B1

Example 4 Consider the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 6 illustrates

the subsystem model for 119862119860

which satisfies thespecification Given SENS specification for class 119860the states are (simop=off op=off) (simop=off op=on)(simop=onop=on) and (simop=on op=off) from variable opand previous state variable simop used in the specification byDefinition 15 By Definition 16 the labels are tstart tringB[1] chm and B[2] chm with the events and actionsused in the specification Each transition in 119872(119862

119860) satisfies

the two conditions in Definition 17 For example 119904 rarr 1199041015840

with 119904 = (simop=offop=off) and 1199041015840 = (simop=onop=off)cannot be a transition of 119872(119862

119860) since it does not hold the

condition for previous state variables that is 119904 ⊨ (op=on) ifand only if 119904

1015840 ⊨ (simop=on) by Definition 17

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 3: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 3

An air-conditioning system

Environment

Specifying

SENS specification

Import Controller InEquip OutEquipClass mainVar temp double[minus320 955]middot middot middotin1 InEquip(out1)middot middot middot mainspec

Class ControllerClass OutEquip(in InEquip)

Class InEquip(out OutEquip)Var Channel Timer InEquipspec

Bundled InEquipFunction antifreeze

antifreezespec

Systemlevel

Subsystemlevel

Functionlevel

Figure 1 An air-conditioning system and its SENS specification

Testsequence

Test cases

OutputInput

Spec

Testinggoal

translator

TGSENS

CNF

Solver(filtering)

Core engineMiniSAT

Test sequence finder

Assign-ments

Test casetranslator

SENSSENS

Figure 2 An overview of TGSENS

3 SENS Specification

In this section we present a compact formal language calledSENS to specify requirements of embedded network systems(ENSs) In Section 31 we present features of SENS InSections 32 and 33 we briefly describe the syntax andsemantics of SENS

31 Features of SENS The SENS specification is basically aset of requirements represented by logical formulas SENSis based on a quantifier-free predicate modal logic with anext operator where predicate variables are classified intoenvironments systems communication channels and timervariables SENS has the following features

311 Property-Based Property-based logical formulas repre-sent requirements which constrain system behaviors Since apart of the specification less affects the entire specification it

is easy to modify and reuse SENS specifications A require-ment is described in a traditional Hoare triple-like way

⟨119901119903119890 119890V119890119899119905 (119901119900119904119905 119886119888119905119894119900119899)⟩ (1)

where 119901119903119890 (resp 119901119900119904119905) denotes a logical constraint holdingin a prestate (resp poststate) and an 119890V119890119899119905 (resp 119886119888119905119894119900119899)represents a message receiving (resp sending) betweensubsystems This 3-tuple requirement needs to hold for alltransitions of the system model and we call this 3-tuplerequirement a transition requirement

312 Test-Oriented For a testing purpose specifying testedvalues and bounds of variables is available in the variabledeclaration This supports a test-oriented design and anefficient test generation from SENS specifications

313 Object-Oriented A group of subsystems is representedas a parameterized class and each subsystem is defined as an

4 Journal of Applied Mathematics

instance of the class in the main class representing the wholesystemThis representation leads to an efficient description ofa large number of subsystems in an ENS

314 Modular Specifications of an ENS a subsystem and afunction are broken down into specifications of subsystemsfunctions and transition requirements respectively Thismodular construction makes it easy to specify a large-scaledand complicated ENS piece by piece and provide a reusabilityof specifications This also allows a step-wise test generationfrom SENS specifications for unit testing integration testingand system testing

315 Lightweight Description of Time Constraints We con-sider a timer as a component of a subsystem and then specifytime constraints using events and actions with the timerSENS provides a timer variable which is declaredwith a time-value a time-unit and a condition formula for counting upthe timer

32 Syntax of SENS Here we give the brief explanationof SENS description using the following example embeddedsystem

Example 1 Consider an illustrating system in Figure 3Thereare 2 kinds of equipment namely classes 119860 and 119861 Let usconsider a simple ENS consisting of 3 subsystems 119860

1 1198611 and

1198612 where119860

1is an instance of119860 and119861

1and119861

2are instances of

119861 A subsystem of class 119860 sends a message 119898 after 2 minutesfrom starting its operation Each subsystem of class 119861 turnson its lamp when receiving message 119898 This system can bedescribed in the SENS specification of Pseudocode 1

The SENS declarations consist of the following declara-tions (refer to Appendix A for the full syntax of SENS)

(i) Main Class Declaration File ltmainclsgt specifies themain class The main class represents the whole systemconsisting of subsystems and the environment In the fileltmainclsgt of Pseudocode 1 the classes 119860 and 119861 areimported in line 1 and subsystems 119860

1 1198611 and 119861

2are instan-

tiated in lines 6-7 Environment variables are declared in theVar part Data types environment variables and channelsdeclared in themain class are referred in all class declarationsInvariants (logical expressions) for the entire system aredeclared in the main class In the example ltmainclsgtglobal data type onoff status is declared in lines 3-4

(ii) Class Declaration Files ltAclsgt and ltBclsgt ofPseudocode 1 specify classes 119860 and 119861 respectively 119860 classother than the main class specifies a class of subsystemsLocal data types variables channels and timers for thesubsystem are declared in the class declaration In ltAclsgtlocal variable op and timer t are declared in lines 6ndash9 and afunction of the subsystem is declared in lines 11ndash14

For data types variables channels and timers externallydeclared and internally used the files to declare them areimported with the Import statement and their names aredescribed in the Extern part The main class file is imported

ltmainclsgt

(1) Import A B

(2) Class main

(3) Data

(4) onoff status onoff

(5) Var

(6) B1 B2 B(7) A1 A(B1 B2)

ltAclsgt

(1) Import B

(2) Extern

(3) Data

(4) onoff status from main

(5) Class A(arg1 B arg2 B)

(6) Var

(7) op onoff status off

(8) Timer

(9) t 2 min

(10)(11) Function SendingM

(12) Require

(13) sim op==off ampamp op==on null tstart

(14) op==on tring arg1chmarg2chm

ltBclsgt

(1) Extern

(2) Data

(3) onoff status from main

(4) Class B

(5) Data

(6) m type m

(7) Var

(8) op onoff status off

(9) lamp onoff status off

(10) Channel

(11) ch m type

(12)(13) Function Lighting

(14) Require

(15) op==on ampamp lamp==off chmlamp==on

(16) op==off minusgt lamp==off

Pseudocode 1 An example SENS specification

to all class files by default A class can have parameters usedas constants in the class specification In line 1 of ltAclsgtclass 119861 is imported since class 119861 is used in the parameterdeclaration of 119860 In lines 3-4 data type onoff status isdescribed in the Extern part

(iii) Variable and Data Type Declarations A variable isdeclared with its name type initial value and test declaration(values and bounds for testing) in the part following to VarData types are int and doublewith ranges and enumerateddata types are defined in the Data part In the Data parta type is defined as a set of values In SENS only finiteand discrete values are used In the exampleltmainclsgta global data type onoff status which has two elementson and off is declared in lines 3-4 In ltBclsgt a localdata type m type which has the only element m is declared

Journal of Applied Mathematics 5

System

Subsystem A1

Subsystem B1

Subsystem B2

m

m

Figure 3 An example embedded system

in lines 5-6 Using the test declaration beginning with thekeywordtestedwith one can define the specific values ofvariables to be considered in a testing phase For exampleconsider the following variable declaration

Var v1 double [-2 5] 0

testedwith -2 05 (05)

variable v1 is defined as follows its type is double its rangeis minus2 le v1le 5 its initial value 0 and its tested values areminus2 and a number from 0 to 5 in increments of 05 In oursemantics of SENS each variable of a subsystem takes onevalue that is an element of its domain If the declaration ofa variable has a test declaration the domain is defined by thetest declaration Otherwise the domain is defined by the datatype of the variable

(iv) Channel and Timer Declarations Channels are used todescribe communications between subsystems A channelis declared with its name and message type In lines 10-11 of ltBclsgt a channel ch for receiving message m isdeclared A timer is declared with its name time-value unitand conditions (logical formula) for counting up Whenthe condition is omitted the condition is always true Forexample consider the following timer declarations

Timer

t1 5 mint2 5 hour [(v==dry) || (v==cool)]

Timer t1 is declared to count up 5 minutes Timer t2 isdeclared to count up 5 hours but the counting is performedonly when the value of v is dry or cool

The event is a message receiving (channel-nameexpr)or timeout (timer-namering) Similarly the action is amessage sending (channel-nameexpr) timer starting (timer-namestart) or timer reset (timer-nameclear) When spec-ifying a communication between subsystems a messagesending (action) is described using both a recipientrsquos objectname and a channel name while a message receiving (event)is described using only a channel name

(v) Function and Requirement Declarations Functions aredeclared in the class declaration or in individual functiondeclaration files In the function declaration constants datatypes variables and timers can be defined locally A functioncontains a set of requirements

A requirement is an expression representing an invariantor a 3-tuple of a precondition an event and a postconditionorwithwithout actions (More precisely the third part ofthe transition requirement is a postcondition or an action oractions or a postcondition with an action or a postconditionwith actions) We call the 3-tuple requirement a transitionrequirement The BNF description for a transition require-ment is given in Algorithm 1 (Refer to Appendix A4)

The precondition and postcondition are logical expres-sions In the transition requirement declaration the eventpart can contain no more than one event (it can also be nullwhich is a symbol showing that no event occurs) while theaction part can contain multiple actions We assume that atransition requirement contains no more than one event andactions related to the same timer

Expressions are constructed with constants variablesand operators Expressions have logical comparison andarithmetic operators that general programming languagessuch as C have In addition expressions in SENS have thelogical implication operator (ndashgt) and the previous state oper-ator (sim) Especially expression sim v represents the previousvalue of v

33 Semantics of SENS A SENS specification describesrequirements of an ENS consisting of subsystems com-municating each other We model the system specified bySENS using a labeled transition system Figure 4 illustratesour system modeling where time constraints in SENS aremodeled using our timer models that will be shown laterFirst each instance corresponding to a subsystem in thegiven specification ismodeledWhen the class correspondingto the subsystem contains timer variables we compose thesubsystem model and its timer models Next an entire ENSis modeled as a parallel composition of all subsystems Thetransition system modeled from the SENS specification isused for generating test cases and test sequences

In Section 331 we give the modeling of timers InSection 332 we give the modeling of a subsystem andexplain the composition of the subsystem and the timer InSection 333 we explain the composition of subsystems

331 Modeling of Timers A timer is specified in the timerdeclaration with its timer name number (time) unit andconditions for counting up in SENS We consider twokinds of models 119872

1and 119872

2for timers expressed in Figures

5(a) and 5(b) We can use simpler timer model 1198722for

state elimination while we can use timer model 1198721for

considering the relation of a time length between timers (referto Section 332)

Definition 2 (timer model) We model the behavior of eachtimer119879

119894as a labeled transition system (119878

119879119894 Σ119879119894

119877119879119894

)with119877119879119894

sube

119878119879119894

times Σ119879119894

times 119878119879119894 where 119878

119879119894denotes a set of states Σ

119879119894denotes

a set of labels and 119877119879119894denotes a labeled transition for 119879

119894

(119878119879119894

Σ119879119894

119877119879119894

) for 1198721and 119872

2are defined as follows

(i) 119878119879119894

= ready 0 1 max over in 1198721

(ii) 119878119879119894

= ready run over in 1198722

6 Journal of Applied Mathematics

Entire system

Sub-system 1 Sub-system n

Timer 1 Timer m Timer 1 Timer m998400

middot middot middot middot middot middot

middot middot middotmiddot middot middot middot middot middot

Figure 4 A model composition for the entire ENS

requirement-declaration=invariant | transition-requirement

invariant= exprtransition-requirement=

pre-condition ldquordquo event ldquordquo(post-condition | (action (ldquordquo | action)lowast)| (post-condition ldquordquo(action (ldquordquo | action)lowast)))

Algorithm 1 The BNF description for a transition requirement

(iii) Σ119879119894

= start clear ring c in 1198721 1198722

In models 1198721and 119872

2 states ready and over respec-

tively represent states in which timer 119879119894is ready and counted

over In model 1198721 state ldquoℎrdquo (0 le ℎ le max) represents a state

in which timer 119879119894has counted up ℎ times In model 119872

2 we

reduce states 0 max to state run representing a state inwhich timer 119879

119894is running for the state elimination

In both models each state is changed to state readywhen receiving message clear State ready is changed tostate 0 in 119872

1(resp state run in 119872

2) when receiving message

start State max in 1198721(resp state run in 119872

2) is changed

to stateover when sending message ring We define thattransitions labeled with 119904119905119886119903119905 and c occur only if thecondition for the timer holds If the condition is not describedin the timer declaration the condition is considered to beldquotruerdquo

If there aremultiple conditions 119901 119902 119903 we define tran-sitions as represented in Figure 5(c) In the figure transitionslabeled with clear are eliminated for simplicity In thefigure the first second and third transitions labeled with coccur when conditions 119901 119902 and 119903 respectively hold

332 Modeling of Subsystems A subsystem is specified in theclass declaration in SENS For a given specification wemodelthe behavior of each subsystem as a labeled transition systemin two steps First the behavior of a subsystem 119862

119894except

timers is modeled as a labeled transition system 119872(119862119894) Next

the behavior of a subsystem including timers is modeled as

clearclear

clearclear

clear

readystart ring

max overc

0 1c c

middot middot middot

(a) Model1198721clear

clear clear

readystart ring

run over

c

(b) Model1198722

ready

start

start

start

run

run

run

over

c

c

c

ring

ring

ring

p holds(not p and q) holds(not p and not q and and r) holds

(c) Model11987210158402for timers with multiple conditions

Figure 5 Timer Models

119872119879

(119862119894) which is a composition of 119872(119862

119894) and models of the

timers

Definition 3 (subsystem model) We model the behavior of asubsystem 119862

119894 except for its timers as 119872(119862

119894) = (119878

119862119894 Σ119862119894

119877119862119894

)

with 119877119862119894

sube 119878119862119894

times Σ119862119894

times 119878119862119894 Given a SENS specification the

set of states 119878119862119894 the set of labels Σ

119862119894 and the set of transitions

119877119862119894are obtained by Definitions 15 16 and 17 of Appendix B1

Example 4 Consider the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 6 illustrates

the subsystem model for 119862119860

which satisfies thespecification Given SENS specification for class 119860the states are (simop=off op=off) (simop=off op=on)(simop=onop=on) and (simop=on op=off) from variable opand previous state variable simop used in the specification byDefinition 15 By Definition 16 the labels are tstart tringB[1] chm and B[2] chm with the events and actionsused in the specification Each transition in 119872(119862

119860) satisfies

the two conditions in Definition 17 For example 119904 rarr 1199041015840

with 119904 = (simop=offop=off) and 1199041015840 = (simop=onop=off)cannot be a transition of 119872(119862

119860) since it does not hold the

condition for previous state variables that is 119904 ⊨ (op=on) ifand only if 119904

1015840 ⊨ (simop=on) by Definition 17

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 4: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

4 Journal of Applied Mathematics

instance of the class in the main class representing the wholesystemThis representation leads to an efficient description ofa large number of subsystems in an ENS

314 Modular Specifications of an ENS a subsystem and afunction are broken down into specifications of subsystemsfunctions and transition requirements respectively Thismodular construction makes it easy to specify a large-scaledand complicated ENS piece by piece and provide a reusabilityof specifications This also allows a step-wise test generationfrom SENS specifications for unit testing integration testingand system testing

315 Lightweight Description of Time Constraints We con-sider a timer as a component of a subsystem and then specifytime constraints using events and actions with the timerSENS provides a timer variable which is declaredwith a time-value a time-unit and a condition formula for counting upthe timer

32 Syntax of SENS Here we give the brief explanationof SENS description using the following example embeddedsystem

Example 1 Consider an illustrating system in Figure 3Thereare 2 kinds of equipment namely classes 119860 and 119861 Let usconsider a simple ENS consisting of 3 subsystems 119860

1 1198611 and

1198612 where119860

1is an instance of119860 and119861

1and119861

2are instances of

119861 A subsystem of class 119860 sends a message 119898 after 2 minutesfrom starting its operation Each subsystem of class 119861 turnson its lamp when receiving message 119898 This system can bedescribed in the SENS specification of Pseudocode 1

The SENS declarations consist of the following declara-tions (refer to Appendix A for the full syntax of SENS)

(i) Main Class Declaration File ltmainclsgt specifies themain class The main class represents the whole systemconsisting of subsystems and the environment In the fileltmainclsgt of Pseudocode 1 the classes 119860 and 119861 areimported in line 1 and subsystems 119860

1 1198611 and 119861

2are instan-

tiated in lines 6-7 Environment variables are declared in theVar part Data types environment variables and channelsdeclared in themain class are referred in all class declarationsInvariants (logical expressions) for the entire system aredeclared in the main class In the example ltmainclsgtglobal data type onoff status is declared in lines 3-4

(ii) Class Declaration Files ltAclsgt and ltBclsgt ofPseudocode 1 specify classes 119860 and 119861 respectively 119860 classother than the main class specifies a class of subsystemsLocal data types variables channels and timers for thesubsystem are declared in the class declaration In ltAclsgtlocal variable op and timer t are declared in lines 6ndash9 and afunction of the subsystem is declared in lines 11ndash14

For data types variables channels and timers externallydeclared and internally used the files to declare them areimported with the Import statement and their names aredescribed in the Extern part The main class file is imported

ltmainclsgt

(1) Import A B

(2) Class main

(3) Data

(4) onoff status onoff

(5) Var

(6) B1 B2 B(7) A1 A(B1 B2)

ltAclsgt

(1) Import B

(2) Extern

(3) Data

(4) onoff status from main

(5) Class A(arg1 B arg2 B)

(6) Var

(7) op onoff status off

(8) Timer

(9) t 2 min

(10)(11) Function SendingM

(12) Require

(13) sim op==off ampamp op==on null tstart

(14) op==on tring arg1chmarg2chm

ltBclsgt

(1) Extern

(2) Data

(3) onoff status from main

(4) Class B

(5) Data

(6) m type m

(7) Var

(8) op onoff status off

(9) lamp onoff status off

(10) Channel

(11) ch m type

(12)(13) Function Lighting

(14) Require

(15) op==on ampamp lamp==off chmlamp==on

(16) op==off minusgt lamp==off

Pseudocode 1 An example SENS specification

to all class files by default A class can have parameters usedas constants in the class specification In line 1 of ltAclsgtclass 119861 is imported since class 119861 is used in the parameterdeclaration of 119860 In lines 3-4 data type onoff status isdescribed in the Extern part

(iii) Variable and Data Type Declarations A variable isdeclared with its name type initial value and test declaration(values and bounds for testing) in the part following to VarData types are int and doublewith ranges and enumerateddata types are defined in the Data part In the Data parta type is defined as a set of values In SENS only finiteand discrete values are used In the exampleltmainclsgta global data type onoff status which has two elementson and off is declared in lines 3-4 In ltBclsgt a localdata type m type which has the only element m is declared

Journal of Applied Mathematics 5

System

Subsystem A1

Subsystem B1

Subsystem B2

m

m

Figure 3 An example embedded system

in lines 5-6 Using the test declaration beginning with thekeywordtestedwith one can define the specific values ofvariables to be considered in a testing phase For exampleconsider the following variable declaration

Var v1 double [-2 5] 0

testedwith -2 05 (05)

variable v1 is defined as follows its type is double its rangeis minus2 le v1le 5 its initial value 0 and its tested values areminus2 and a number from 0 to 5 in increments of 05 In oursemantics of SENS each variable of a subsystem takes onevalue that is an element of its domain If the declaration ofa variable has a test declaration the domain is defined by thetest declaration Otherwise the domain is defined by the datatype of the variable

(iv) Channel and Timer Declarations Channels are used todescribe communications between subsystems A channelis declared with its name and message type In lines 10-11 of ltBclsgt a channel ch for receiving message m isdeclared A timer is declared with its name time-value unitand conditions (logical formula) for counting up Whenthe condition is omitted the condition is always true Forexample consider the following timer declarations

Timer

t1 5 mint2 5 hour [(v==dry) || (v==cool)]

Timer t1 is declared to count up 5 minutes Timer t2 isdeclared to count up 5 hours but the counting is performedonly when the value of v is dry or cool

The event is a message receiving (channel-nameexpr)or timeout (timer-namering) Similarly the action is amessage sending (channel-nameexpr) timer starting (timer-namestart) or timer reset (timer-nameclear) When spec-ifying a communication between subsystems a messagesending (action) is described using both a recipientrsquos objectname and a channel name while a message receiving (event)is described using only a channel name

(v) Function and Requirement Declarations Functions aredeclared in the class declaration or in individual functiondeclaration files In the function declaration constants datatypes variables and timers can be defined locally A functioncontains a set of requirements

A requirement is an expression representing an invariantor a 3-tuple of a precondition an event and a postconditionorwithwithout actions (More precisely the third part ofthe transition requirement is a postcondition or an action oractions or a postcondition with an action or a postconditionwith actions) We call the 3-tuple requirement a transitionrequirement The BNF description for a transition require-ment is given in Algorithm 1 (Refer to Appendix A4)

The precondition and postcondition are logical expres-sions In the transition requirement declaration the eventpart can contain no more than one event (it can also be nullwhich is a symbol showing that no event occurs) while theaction part can contain multiple actions We assume that atransition requirement contains no more than one event andactions related to the same timer

Expressions are constructed with constants variablesand operators Expressions have logical comparison andarithmetic operators that general programming languagessuch as C have In addition expressions in SENS have thelogical implication operator (ndashgt) and the previous state oper-ator (sim) Especially expression sim v represents the previousvalue of v

33 Semantics of SENS A SENS specification describesrequirements of an ENS consisting of subsystems com-municating each other We model the system specified bySENS using a labeled transition system Figure 4 illustratesour system modeling where time constraints in SENS aremodeled using our timer models that will be shown laterFirst each instance corresponding to a subsystem in thegiven specification ismodeledWhen the class correspondingto the subsystem contains timer variables we compose thesubsystem model and its timer models Next an entire ENSis modeled as a parallel composition of all subsystems Thetransition system modeled from the SENS specification isused for generating test cases and test sequences

In Section 331 we give the modeling of timers InSection 332 we give the modeling of a subsystem andexplain the composition of the subsystem and the timer InSection 333 we explain the composition of subsystems

331 Modeling of Timers A timer is specified in the timerdeclaration with its timer name number (time) unit andconditions for counting up in SENS We consider twokinds of models 119872

1and 119872

2for timers expressed in Figures

5(a) and 5(b) We can use simpler timer model 1198722for

state elimination while we can use timer model 1198721for

considering the relation of a time length between timers (referto Section 332)

Definition 2 (timer model) We model the behavior of eachtimer119879

119894as a labeled transition system (119878

119879119894 Σ119879119894

119877119879119894

)with119877119879119894

sube

119878119879119894

times Σ119879119894

times 119878119879119894 where 119878

119879119894denotes a set of states Σ

119879119894denotes

a set of labels and 119877119879119894denotes a labeled transition for 119879

119894

(119878119879119894

Σ119879119894

119877119879119894

) for 1198721and 119872

2are defined as follows

(i) 119878119879119894

= ready 0 1 max over in 1198721

(ii) 119878119879119894

= ready run over in 1198722

6 Journal of Applied Mathematics

Entire system

Sub-system 1 Sub-system n

Timer 1 Timer m Timer 1 Timer m998400

middot middot middot middot middot middot

middot middot middotmiddot middot middot middot middot middot

Figure 4 A model composition for the entire ENS

requirement-declaration=invariant | transition-requirement

invariant= exprtransition-requirement=

pre-condition ldquordquo event ldquordquo(post-condition | (action (ldquordquo | action)lowast)| (post-condition ldquordquo(action (ldquordquo | action)lowast)))

Algorithm 1 The BNF description for a transition requirement

(iii) Σ119879119894

= start clear ring c in 1198721 1198722

In models 1198721and 119872

2 states ready and over respec-

tively represent states in which timer 119879119894is ready and counted

over In model 1198721 state ldquoℎrdquo (0 le ℎ le max) represents a state

in which timer 119879119894has counted up ℎ times In model 119872

2 we

reduce states 0 max to state run representing a state inwhich timer 119879

119894is running for the state elimination

In both models each state is changed to state readywhen receiving message clear State ready is changed tostate 0 in 119872

1(resp state run in 119872

2) when receiving message

start State max in 1198721(resp state run in 119872

2) is changed

to stateover when sending message ring We define thattransitions labeled with 119904119905119886119903119905 and c occur only if thecondition for the timer holds If the condition is not describedin the timer declaration the condition is considered to beldquotruerdquo

If there aremultiple conditions 119901 119902 119903 we define tran-sitions as represented in Figure 5(c) In the figure transitionslabeled with clear are eliminated for simplicity In thefigure the first second and third transitions labeled with coccur when conditions 119901 119902 and 119903 respectively hold

332 Modeling of Subsystems A subsystem is specified in theclass declaration in SENS For a given specification wemodelthe behavior of each subsystem as a labeled transition systemin two steps First the behavior of a subsystem 119862

119894except

timers is modeled as a labeled transition system 119872(119862119894) Next

the behavior of a subsystem including timers is modeled as

clearclear

clearclear

clear

readystart ring

max overc

0 1c c

middot middot middot

(a) Model1198721clear

clear clear

readystart ring

run over

c

(b) Model1198722

ready

start

start

start

run

run

run

over

c

c

c

ring

ring

ring

p holds(not p and q) holds(not p and not q and and r) holds

(c) Model11987210158402for timers with multiple conditions

Figure 5 Timer Models

119872119879

(119862119894) which is a composition of 119872(119862

119894) and models of the

timers

Definition 3 (subsystem model) We model the behavior of asubsystem 119862

119894 except for its timers as 119872(119862

119894) = (119878

119862119894 Σ119862119894

119877119862119894

)

with 119877119862119894

sube 119878119862119894

times Σ119862119894

times 119878119862119894 Given a SENS specification the

set of states 119878119862119894 the set of labels Σ

119862119894 and the set of transitions

119877119862119894are obtained by Definitions 15 16 and 17 of Appendix B1

Example 4 Consider the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 6 illustrates

the subsystem model for 119862119860

which satisfies thespecification Given SENS specification for class 119860the states are (simop=off op=off) (simop=off op=on)(simop=onop=on) and (simop=on op=off) from variable opand previous state variable simop used in the specification byDefinition 15 By Definition 16 the labels are tstart tringB[1] chm and B[2] chm with the events and actionsused in the specification Each transition in 119872(119862

119860) satisfies

the two conditions in Definition 17 For example 119904 rarr 1199041015840

with 119904 = (simop=offop=off) and 1199041015840 = (simop=onop=off)cannot be a transition of 119872(119862

119860) since it does not hold the

condition for previous state variables that is 119904 ⊨ (op=on) ifand only if 119904

1015840 ⊨ (simop=on) by Definition 17

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 5: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 5

System

Subsystem A1

Subsystem B1

Subsystem B2

m

m

Figure 3 An example embedded system

in lines 5-6 Using the test declaration beginning with thekeywordtestedwith one can define the specific values ofvariables to be considered in a testing phase For exampleconsider the following variable declaration

Var v1 double [-2 5] 0

testedwith -2 05 (05)

variable v1 is defined as follows its type is double its rangeis minus2 le v1le 5 its initial value 0 and its tested values areminus2 and a number from 0 to 5 in increments of 05 In oursemantics of SENS each variable of a subsystem takes onevalue that is an element of its domain If the declaration ofa variable has a test declaration the domain is defined by thetest declaration Otherwise the domain is defined by the datatype of the variable

(iv) Channel and Timer Declarations Channels are used todescribe communications between subsystems A channelis declared with its name and message type In lines 10-11 of ltBclsgt a channel ch for receiving message m isdeclared A timer is declared with its name time-value unitand conditions (logical formula) for counting up Whenthe condition is omitted the condition is always true Forexample consider the following timer declarations

Timer

t1 5 mint2 5 hour [(v==dry) || (v==cool)]

Timer t1 is declared to count up 5 minutes Timer t2 isdeclared to count up 5 hours but the counting is performedonly when the value of v is dry or cool

The event is a message receiving (channel-nameexpr)or timeout (timer-namering) Similarly the action is amessage sending (channel-nameexpr) timer starting (timer-namestart) or timer reset (timer-nameclear) When spec-ifying a communication between subsystems a messagesending (action) is described using both a recipientrsquos objectname and a channel name while a message receiving (event)is described using only a channel name

(v) Function and Requirement Declarations Functions aredeclared in the class declaration or in individual functiondeclaration files In the function declaration constants datatypes variables and timers can be defined locally A functioncontains a set of requirements

A requirement is an expression representing an invariantor a 3-tuple of a precondition an event and a postconditionorwithwithout actions (More precisely the third part ofthe transition requirement is a postcondition or an action oractions or a postcondition with an action or a postconditionwith actions) We call the 3-tuple requirement a transitionrequirement The BNF description for a transition require-ment is given in Algorithm 1 (Refer to Appendix A4)

The precondition and postcondition are logical expres-sions In the transition requirement declaration the eventpart can contain no more than one event (it can also be nullwhich is a symbol showing that no event occurs) while theaction part can contain multiple actions We assume that atransition requirement contains no more than one event andactions related to the same timer

Expressions are constructed with constants variablesand operators Expressions have logical comparison andarithmetic operators that general programming languagessuch as C have In addition expressions in SENS have thelogical implication operator (ndashgt) and the previous state oper-ator (sim) Especially expression sim v represents the previousvalue of v

33 Semantics of SENS A SENS specification describesrequirements of an ENS consisting of subsystems com-municating each other We model the system specified bySENS using a labeled transition system Figure 4 illustratesour system modeling where time constraints in SENS aremodeled using our timer models that will be shown laterFirst each instance corresponding to a subsystem in thegiven specification ismodeledWhen the class correspondingto the subsystem contains timer variables we compose thesubsystem model and its timer models Next an entire ENSis modeled as a parallel composition of all subsystems Thetransition system modeled from the SENS specification isused for generating test cases and test sequences

In Section 331 we give the modeling of timers InSection 332 we give the modeling of a subsystem andexplain the composition of the subsystem and the timer InSection 333 we explain the composition of subsystems

331 Modeling of Timers A timer is specified in the timerdeclaration with its timer name number (time) unit andconditions for counting up in SENS We consider twokinds of models 119872

1and 119872

2for timers expressed in Figures

5(a) and 5(b) We can use simpler timer model 1198722for

state elimination while we can use timer model 1198721for

considering the relation of a time length between timers (referto Section 332)

Definition 2 (timer model) We model the behavior of eachtimer119879

119894as a labeled transition system (119878

119879119894 Σ119879119894

119877119879119894

)with119877119879119894

sube

119878119879119894

times Σ119879119894

times 119878119879119894 where 119878

119879119894denotes a set of states Σ

119879119894denotes

a set of labels and 119877119879119894denotes a labeled transition for 119879

119894

(119878119879119894

Σ119879119894

119877119879119894

) for 1198721and 119872

2are defined as follows

(i) 119878119879119894

= ready 0 1 max over in 1198721

(ii) 119878119879119894

= ready run over in 1198722

6 Journal of Applied Mathematics

Entire system

Sub-system 1 Sub-system n

Timer 1 Timer m Timer 1 Timer m998400

middot middot middot middot middot middot

middot middot middotmiddot middot middot middot middot middot

Figure 4 A model composition for the entire ENS

requirement-declaration=invariant | transition-requirement

invariant= exprtransition-requirement=

pre-condition ldquordquo event ldquordquo(post-condition | (action (ldquordquo | action)lowast)| (post-condition ldquordquo(action (ldquordquo | action)lowast)))

Algorithm 1 The BNF description for a transition requirement

(iii) Σ119879119894

= start clear ring c in 1198721 1198722

In models 1198721and 119872

2 states ready and over respec-

tively represent states in which timer 119879119894is ready and counted

over In model 1198721 state ldquoℎrdquo (0 le ℎ le max) represents a state

in which timer 119879119894has counted up ℎ times In model 119872

2 we

reduce states 0 max to state run representing a state inwhich timer 119879

119894is running for the state elimination

In both models each state is changed to state readywhen receiving message clear State ready is changed tostate 0 in 119872

1(resp state run in 119872

2) when receiving message

start State max in 1198721(resp state run in 119872

2) is changed

to stateover when sending message ring We define thattransitions labeled with 119904119905119886119903119905 and c occur only if thecondition for the timer holds If the condition is not describedin the timer declaration the condition is considered to beldquotruerdquo

If there aremultiple conditions 119901 119902 119903 we define tran-sitions as represented in Figure 5(c) In the figure transitionslabeled with clear are eliminated for simplicity In thefigure the first second and third transitions labeled with coccur when conditions 119901 119902 and 119903 respectively hold

332 Modeling of Subsystems A subsystem is specified in theclass declaration in SENS For a given specification wemodelthe behavior of each subsystem as a labeled transition systemin two steps First the behavior of a subsystem 119862

119894except

timers is modeled as a labeled transition system 119872(119862119894) Next

the behavior of a subsystem including timers is modeled as

clearclear

clearclear

clear

readystart ring

max overc

0 1c c

middot middot middot

(a) Model1198721clear

clear clear

readystart ring

run over

c

(b) Model1198722

ready

start

start

start

run

run

run

over

c

c

c

ring

ring

ring

p holds(not p and q) holds(not p and not q and and r) holds

(c) Model11987210158402for timers with multiple conditions

Figure 5 Timer Models

119872119879

(119862119894) which is a composition of 119872(119862

119894) and models of the

timers

Definition 3 (subsystem model) We model the behavior of asubsystem 119862

119894 except for its timers as 119872(119862

119894) = (119878

119862119894 Σ119862119894

119877119862119894

)

with 119877119862119894

sube 119878119862119894

times Σ119862119894

times 119878119862119894 Given a SENS specification the

set of states 119878119862119894 the set of labels Σ

119862119894 and the set of transitions

119877119862119894are obtained by Definitions 15 16 and 17 of Appendix B1

Example 4 Consider the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 6 illustrates

the subsystem model for 119862119860

which satisfies thespecification Given SENS specification for class 119860the states are (simop=off op=off) (simop=off op=on)(simop=onop=on) and (simop=on op=off) from variable opand previous state variable simop used in the specification byDefinition 15 By Definition 16 the labels are tstart tringB[1] chm and B[2] chm with the events and actionsused in the specification Each transition in 119872(119862

119860) satisfies

the two conditions in Definition 17 For example 119904 rarr 1199041015840

with 119904 = (simop=offop=off) and 1199041015840 = (simop=onop=off)cannot be a transition of 119872(119862

119860) since it does not hold the

condition for previous state variables that is 119904 ⊨ (op=on) ifand only if 119904

1015840 ⊨ (simop=on) by Definition 17

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 6: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

6 Journal of Applied Mathematics

Entire system

Sub-system 1 Sub-system n

Timer 1 Timer m Timer 1 Timer m998400

middot middot middot middot middot middot

middot middot middotmiddot middot middot middot middot middot

Figure 4 A model composition for the entire ENS

requirement-declaration=invariant | transition-requirement

invariant= exprtransition-requirement=

pre-condition ldquordquo event ldquordquo(post-condition | (action (ldquordquo | action)lowast)| (post-condition ldquordquo(action (ldquordquo | action)lowast)))

Algorithm 1 The BNF description for a transition requirement

(iii) Σ119879119894

= start clear ring c in 1198721 1198722

In models 1198721and 119872

2 states ready and over respec-

tively represent states in which timer 119879119894is ready and counted

over In model 1198721 state ldquoℎrdquo (0 le ℎ le max) represents a state

in which timer 119879119894has counted up ℎ times In model 119872

2 we

reduce states 0 max to state run representing a state inwhich timer 119879

119894is running for the state elimination

In both models each state is changed to state readywhen receiving message clear State ready is changed tostate 0 in 119872

1(resp state run in 119872

2) when receiving message

start State max in 1198721(resp state run in 119872

2) is changed

to stateover when sending message ring We define thattransitions labeled with 119904119905119886119903119905 and c occur only if thecondition for the timer holds If the condition is not describedin the timer declaration the condition is considered to beldquotruerdquo

If there aremultiple conditions 119901 119902 119903 we define tran-sitions as represented in Figure 5(c) In the figure transitionslabeled with clear are eliminated for simplicity In thefigure the first second and third transitions labeled with coccur when conditions 119901 119902 and 119903 respectively hold

332 Modeling of Subsystems A subsystem is specified in theclass declaration in SENS For a given specification wemodelthe behavior of each subsystem as a labeled transition systemin two steps First the behavior of a subsystem 119862

119894except

timers is modeled as a labeled transition system 119872(119862119894) Next

the behavior of a subsystem including timers is modeled as

clearclear

clearclear

clear

readystart ring

max overc

0 1c c

middot middot middot

(a) Model1198721clear

clear clear

readystart ring

run over

c

(b) Model1198722

ready

start

start

start

run

run

run

over

c

c

c

ring

ring

ring

p holds(not p and q) holds(not p and not q and and r) holds

(c) Model11987210158402for timers with multiple conditions

Figure 5 Timer Models

119872119879

(119862119894) which is a composition of 119872(119862

119894) and models of the

timers

Definition 3 (subsystem model) We model the behavior of asubsystem 119862

119894 except for its timers as 119872(119862

119894) = (119878

119862119894 Σ119862119894

119877119862119894

)

with 119877119862119894

sube 119878119862119894

times Σ119862119894

times 119878119862119894 Given a SENS specification the

set of states 119878119862119894 the set of labels Σ

119862119894 and the set of transitions

119877119862119894are obtained by Definitions 15 16 and 17 of Appendix B1

Example 4 Consider the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 6 illustrates

the subsystem model for 119862119860

which satisfies thespecification Given SENS specification for class 119860the states are (simop=off op=off) (simop=off op=on)(simop=onop=on) and (simop=on op=off) from variable opand previous state variable simop used in the specification byDefinition 15 By Definition 16 the labels are tstart tringB[1] chm and B[2] chm with the events and actionsused in the specification Each transition in 119872(119862

119860) satisfies

the two conditions in Definition 17 For example 119904 rarr 1199041015840

with 119904 = (simop=offop=off) and 1199041015840 = (simop=onop=off)cannot be a transition of 119872(119862

119860) since it does not hold the

condition for previous state variables that is 119904 ⊨ (op=on) ifand only if 119904

1015840 ⊨ (simop=on) by Definition 17

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 7: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 7

simop=off

simop=off

op=offsimop=on

simop=on

op=off

op=onop=ontstart

tringC B[1]chmC B[2]chm

Figure 6 An example model for system 119862119860

We model the behavior of a subsystem 119862119894with its

timers 1198791 1198792 119879

119898as an interleaving composition of the

subsystem model and timer models as follows

119872119879

(119862119894) = 119872 (119862

119894) 119872 (119879

1) 119872 (119879

2) sdot sdot sdot 119872 (119879

119898) (2)

where 119872(119862119894) denote the subsystem model explained in

Definition 3 and 119872(119879119895) denotes the model for timer 119879

119895(1 le

119895 le 119898) explained in Section 331 We inductively define theabove model composition that is

(1) 119872(119862119894) 119872(119879

119895) in Definition 18

(2) 119872(119862119879119894) 119872(119879

119896) in Definition 19 where 119872(119862119879

119894) =

119872(119862119894) 119872(119879

1) sdot sdot sdot 119872(119879

119895) with 119895 lt 119896

And the composition rule is defined in Definitions 18 and 19of Appendix B2

Example 5 Consider again the example specification ofsubsystem 119862

119860in Pseudocode 1 Figure 7 shows a part of the

composed model of 119872(119862119860

) in Figure 6 and timer model1198722for timer 119905 The transitions labeled with 119905 start and

119905 ring correspond to rules (a1) and (a2) in Definition 18 thatis message synchronization The transition labeled with ccorresponds to rule (a4) in Definition 18

333 System Model Now we explain the model for theentire system Assume that the entire system consists of 119896

subsystems We define the model for the system as the par-allel synchronized composition of labeled transition systems119872119879

(119862119894) representing all subsystems 119862

119894(1 le 119894 le 119896) The

composition of two subsystems is defined in Definition 20and the entire system model 119872

119879(1198621) sdot sdot sdot 119872

119879(119862119899) is

obtained by an inductive composition (When a transitionof a subsystem has multiple message sending we assumethat its composition is synchronously performed in ourmodeling) The composition rule is defined in the definitionof Appendix B3

Example 6 Consider the example specifications of subsys-tems119862

119860and119862

119861[1] in Pseudocode 1 Figure 8 shows an exam-

ple composition of transitions in 119872119879

(119862119860

) and 119872119879

(119862119861

[1])

simop=offop=on

simop=on simop=onop=offop=on

t start t ringC B[1]chmC B[2]chm

t=ready t=run t=over

C

middot middot middot

Figure 7 An example model for system 119862119860with a timer

t ringC B[1]chmC B[2]chm

C Aop=onC At=run

C B[1]op=onC B[1]lamp=off

C At ring

C Aop=off

C B[1]op=onC B[1]lamp=off

C AC B[1]ch mC B[2]chm

C Aop=offC At=over

C At=over

C B[1]op=onC B[1]lamp=on

C Asimop=on

C Asimop=on

C Asimop=on

simop=on

simop=onop=off

op=ont=run

t=over

chm

op=on

lamp=off

op=on

lamp=on

|| =

C A C B[1]

C A||C B[1]

Figure 8 An example transition composition for 119862119860and 119862

119861[1]

4 Automatic Test Generation fromthe SENS Specification

In this section we present the methods for a given SENS

specification to automatically generate test cases and testsequences in Sections 41 and 42 respectively

41 Test Case Generation

411 Concept In our approach we find all test cases byusing a SAT solver A SAT solver is a tool to solve the SAT(satisfiability) problem which determines whether there isa value assignment to satisfy a given Boolean formula inCNF (conjunctive normal form) Although this problem isan NP-complete problem there have been very high-speedSAT solvers (eg MiniSAT [5]) for practical sized problemsUsing a SAT solver we can find distinct and enormous testcases quickly that satisfy SENS specifications

412 Test Cases Given a SENS specification that describes atarget system every transition of the system model satisfiesall requirements in the given specification as mentioned inthe previous section Therefore we can consider that eachtransition 119905 of the system model corresponds to a one-steptest caseThat is the prestate (resp events) of 119905 is a valid inputstate (resp system inputs) of a test case and the poststate(resp action) of 119905 is a valid output state (resp system output)of the test case We formally define a test case as follows

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 8: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

8 Journal of Applied Mathematics

Definition 7 (test case) Consider a given specification S Atest case is a tuple

(119894119899119901119906119905 119890V119890119899119905 119886119888119905119894119900119899 119900119906119905119901119906119905) (3)

corresponding to a transition of the system model 119872 suchthat 119872 ⊨ S In other words a test case is an assignment thatmakes every transition requirement of S hold

Note that if the given specification is for a subsystemmodule subsystems and an entire ENS derived test casesare respectively used for unit testing integration testing andsystem testing

413 Translation of SENS to CNF For generating test caseswe first translate all the requirements in the given SENS

specification to a CNF formula which becomes an input ofa SAT solver Since the SENS specification is a set of logicalconstraint formulas we can translate it to CNF according tothe semantics of SENS

There are 3 main steps of the translation procedure asfollows First we introduce fresh propositional variables toconstruct the state space of the system model Second tran-sition requirements and invariants in the SENS specificationare translated into logical formulas Third we collect all ofthe constraints presented in logical formulasThe constraintsare connected with conjunction and the result is convertedto CNF (Every propositional logic formula can be convertedinto an equivalent formula that is in CNF However by naivealgorithms where the transformation is based on rules of DeMorganrsquos laws and the distributive law the size of CNF can beexponentially increased To get a compact CNF formula weused the Tseitin-transformation [6] after translating SENS

to a propositional logic formula) Due to space limitation thedetails of all translation rules are given in Appendix C

414 Generating Test Cases Once we obtain the CNF for-mula from the given SENS specification we apply a SATsolver to the CNF formula to find an assignment As men-tioned above the assignment that makes requirements of theSENS specification true corresponds to a test case

Algorithm 2 describes our method for generating testcases We use a SAT solver iteratively to find all possibleassignments and convert them to test cases that cover allpossible transitions of the system model

415 Filtering The proposed method can generate all possi-ble test cases with 100 coverage for requirements of a givenspecification On the other hand the number of complete testcases can be very huge In order to extract efficient test caseswe also give several filtering mechanisms in our methodIn the current version of our tool a user can select testcases satisfying a precondition of transition requirementstest cases containing a communication label and test caseswhose timer label isring which means the test cases relatedto a time constraint

Example 8 Consider again the example specification of sub-system 119862

119860in Pseudocode 1 Each transition of the model for

system 119862119860in Figure 7 corresponds to a test case Especially

((simop=offop=on) 0 tstart (simop=onop=on)) corre-spond to a test case satisfying a precondition of the tran-sition requirement ltsimop==offampampop==onnulltstartgt

in line 13 of the specification On the other hand((simop=onop=on)tring C B[1]chmC B[2]chm(simop=onop=off)) correspond to a test case containingtimer label ring and communication labels

As shown in Table 3 the number of all test cases for 119862119860

is 176 Among them test cases satisfying a precondition are10 which is less than 6 of the entire test cases Moreoveramong them 2 test cases can be extracted respectively witha communication label and timer label ring

42 Test Sequence Generation

421 Concept As mentioned in Section 41 our test gener-ator can generate all possible test cases for a given SENS

specification Since the number of complete test cases can bevery huge it is hard to run tests by inputting all the test casesseparately Therefore it is practical to extract test sequencesand focus on specific variables interested for testing To dealwith this problem we propose a test sequence generator forappropriate testing goals given by users

422 Test Sequences and Testing Goals In our method wegenerate test sequences from two inputs given a SENS spec-ification and a testing goal First we define a test sequence asfollows

Definition 9 (test sequence) A test sequence is a sequence oftest cases whose adjacent output and input are the sameThismeans that a test sequence is a sequence

⟨(1198941198991199011199061199051 119890V119890119899119905

1 119886119888119905119894119900119899

1 119900119906119905119901119906119905

1)

(119894119899119901119906119905119899 119890V119890119899119905

119899 119886119888119905119894119900119899

119899 119900119906119905119901119906119905

119899)⟩

(4)

where 119900119906119905119901119906119905119894

= 119894119899119901119906119905119894+1 for 119894 = 1 119899 minus 1

Next a ldquotesting goalrdquo is a key feature that helps to generateappropriate test sequences This also allows us to reducethe size of space and time for searching test sequencesIn the current version of our method a user can specifythe following 3 features as a testing goal ldquokey variablesrdquofor a testing purpose a list of ldquomilestonerdquo states forming abackbone of the sequence and a ldquomaximum lengthrdquo betweentwo adjacent milestones We formally define a testing goal asfollows

Definition 10 (testing goals) Given a SENS specification atesting goal 119866 = ⟨119881 119878 119871119904⟩ where 119881 is a set of key variables 119878

is a list ofmilestone states and 119871119904 is a list ofmaximum lengthssuch that

(1) 119886 ldquokey variablerdquo is a variable that we focus on testingin the given specification

(2) 119886 ldquomilestonerdquo is a state that wewant each test sequenceto pass through

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 9: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 9

Data A SENS specificationResult A Set of test cases

(1) begin(2) Translate the given SENS specification to a logical formula 119891 in conjunctive normal form (CNF)

based on translation rules in Appendix C(3) Input 119891 to a SAT solver(4) if119891 is satisfiable then(5) The SAT solver outputs a solution 119898 (value assignment) corresponding to one test case(6) Add the solution 119898 to a set of solutions(7) Let 119891 larr 119891 and not119898 and return Step 2 to search for another solution(8) else(9) The SAT solver declares 119891 is unsatisfiable(10) Then there are no more solutions(11) Translate previous solutions to test cases and stop(12) return The set of test cases

Algorithm 2 Our algorithm of test case generation

(3) 119886 ldquomaximum lengthrdquo max of a run from a milestone119904 isin 119878 to the next milestone 1199041015840 isin 119878 denoted by 119904

lemax997888997888997888997888rarr

1199041015840 is the maximum number of transitions needed forthe run

We say that a test sequence ⟨(1198941 1198901 1198861 1199001)

(119894119899 119890119899 119886119899 119900119899)⟩ satisfies a testing goal 119866 = ⟨119881 119878 =

⟨1199041 119904

119896⟩ 119871119904⟩ if and only if (1) the first input state 119894

1

and the last output state 119900119899of the test sequence respectively

are equal to the first milestone 1199041and the last milestone 119904

119896 (2)

all other milestone states exist in the input states of the testsequence in order and (3) the length between the milestonestates in the test sequence is less than the maximum lengthdefined in 119871119904 In addition value assignments only for the keyvariables appear in the generated test sequences satisfyingthe testing goal

Example 11 If the list of milestones is ⟨1199041 1199042 1199043⟩ then we can

specify the maximum length in total as thelemax1997888997888997888997888997888rarr sdot

lemax2997888997888997888997888997888rarr

where max1is the maximum of transitions which can be

taken to go through from themilestone 1199041to themilestone 119904

2

and max2is the maximum of transitions which can be taken

to go through from the milestone 1199042to the milestone 119904

3

Let us consider the simple example specification of system119861 in Pseudocode 1 Assume a testing goal whose key variables119881 = oplamp milestones 119878 = ⟨119904

1= (op=offlamp=off)

1199042= (op=onlamp=on) ⟩ and 119904

1

le2

997888rarr 1199042 Then

⟨((op=offlamp=off) 0 0 (op=onlamp=off))((op=onlamp=off) chm 0 (op=onlamp=on))⟩

is a test sequence satisfying the testing goal

423 Generating Test Sequences Our approach for testsequence generation has three main steps First from agiven SENS specification we first generate all test cases byour method in Algorithm 2 Then the obtained test casescorrespond to all transitions of the target system model

Second we synthesize all the transitions into a transitionsystem (graph) Each state of this transition system is a tupleof variable assignments Each edge is a transition relationfrom a prestate to a poststate and a label of each edge is anevent that makes the transition occur The transition systemof the specification is stored in a file while the testing goal isstored in a separate file

Third given the transition system and the testing goal intwo files we compute all possible desired test sequences thatsatisfy the testing goal that is we search the set of sequencesstarting from a given milestone state to another milestonestatewhose distance is less than the givenmaximum length bytree searching algorithms including exhaustive BFS (breathfirst search) and DFS (depth first search) algorithms Eachresulting test sequence is treated as a test scenario In ourtest sequence generation we reduce the searching state spaceof the system model by an equivalence partitioning basedon the key variables of the given testing goal and search thesequences containing milestone states

In our TGSENS test sequences can be generated fromboth the original transition system and the filtered testcases In the test sequence generation from the originaltransition system the obtained test sequences obviously keepthe transition relation of the original system model In thetest sequence generation from the filtered test cases testsequences including transitions eliminated by filtering are notgenerated However since the filtering is defined by formalrules the effect by filtering is clear for users who recognizethat test sequences with filtering options will be obtained Forthis reason we believe that it does not affect the main resultsof our research in other words generations of reliable testcasessequences

5 Implementation and Experiments

51 Implementation We implemented our approach ofSENS-based automatic test generation in the tool calledTGSENS The tool TGSENS consists of the following fourparts as illustrated in Figure 2 (1) The first part translates

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 10: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

10 Journal of Applied Mathematics

the specification written in SENS into a CNF formula (2)The second part searches and collects all assignments thatsatisfy the CNF formula by using a SAT solver as its coreengine (3)The third part translates the obtained assignmentsinto test cases which are expressed with variables used in theoriginal SENS specification (4) The forth part searches thetest sequences from the output file of the third part and giventesting goals The resulting test sequences can be viewed bytwo ways a textual format or a graphical figure using a dotfile viewer

Currently for the function level (corresponding to thefunction declaration in SENS) and the subsystem level(corresponding to the class declaration in SENS) we havecompleted the implementation of the first part in TGSENS

but not yet for the system level That means that the imple-mentation for the composition of subsystems for the entiresystem level is our future work Hence the current version ofour tool can perform the test generation for unit testing

Our tool was implemented on Windows XP for bothtimes86 and times64 environments The first third and forth partswere implemented with a Java language The second partwas implemented based on MiniSAT [5] with C++ The sizeof the implemented programs is totally about 20000 linesrespectively 16 000 3 000 500 and 340 lines for each part

We also implemented the user interface (in Japanese) ofTGSENS given in Figure 9 Given an input SENS specifica-tion our tool has execution options to generate output filesof exhaustive test cases filtered test cases and test sequencesunder a given testing goal TGSENS also has a function tocheck a reachability of states and generate path sequencesamong the input states

52 Experiments Specification in SENS We applied SENS tospecify system requirements of real air-conditioning systemsby Company D In general there are specifications withdifferent levels In Company D specifications are dividedinto ldquoinstruction manualsrdquo ldquofunctional specificationsrdquo andldquodetailed specificationsrdquo and each specification is brokeninto functions For example as to specifications of certainindoor equipment an instruction manual consists of about10 functions with 30 pages and a functional specificationand a detailed specification respectively consist of about 80functions with 400 pages

We translated several specifications in a natural languagewith tables and figures to SENS specifications The targetspecifications were for two modules 119865

ℎand 119865

119894in an instruc-

tion manual and one function 119865119895in a detailed specification

of an indoor equipment one function 119865119897in a functional

specification of an air-cleaning system and three functions119865119898 119865119899 and 119865

119900in a functional specification of a controller

For all specifications this translation needed 1 or 2 daysby one person who is one of our SENS developers Almost all(70ndash80) of the translation time was for understanding thereal specifications and confirming whether the SENS spec-ifications are valid with industrial engineers while the restof the time (several hours) was for the actual description Inaddition we held a one-day seminar for industrial engineersto explain how to describe the SENS specifications and we

Input file

Output folder

Test case Reachability check Test sequence

FilteringSatisfying

pre-conditions

Containingcommunication

labels

Containing timerlabel ldquoringrdquo

(a) The main interface for generating test cases

Test sequenceGenerating a

graphical result

Setting for a testing goal

(b) The interface for generating test sequences

Figure 9 The GUI interface of TGSENS

confirmed that after the one-day seminar the engineers wereeasily able to use SENS to specify embedded systems bythemselves

Example 12 We show a part of an example SENS specifica-tion for function 119865

119897in Pseudocode 2 119865

119897is a mode change

function for an air-cleaning system by Company D Theoriginal specification of this function was written in Japanesewith 119860

4sized 4 pages and includes 5 tables and 4 transition

diagramsWe transformed this document into about 100 linesof a SENS specification The SENS specification consists of 8variables (including 6 global variables 1 local variable and 1channel) 20 invariants and 8 transition specifications Lines16ndash18 specify invariants and lines 20ndash22 specify transitionspecifications All 8 variables have discrete values and thedetails of variables and their ranges are given in Table 1

Table 2 shows the scale of the SENS specifications forfunction 119865

ℎ-119865119900 the number of lines except comments and

blank lines the number of declared variables and channelsand the number of requirements including invariants andtransition requirements As to the specification of 119865

119900 the size

of requirements was relatively long since variables of the array

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 11: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 11

ltACclsgt

(1) Class AC

(2) Data

(3) Type opMode Off Auto Turbo Pollen Calm Normal

(4) Type humidMode Off Auto Cont High

(5) Type airVolume W0 W1 W2 W3 W4 W5 W6

(6) Type airPurity KTY1 KTY2 KTY3 KTY4 KTY5

(7) Type Brightness Normal Dark Off

(8) Type switch On

(9) Var

(10) Mode A Type opMode Mode of operation

(11) Mode B Type humidMode Mode of humidity

(12) AV Type airVolume Actual air volume

(13) AP Type airPurity Air purity

(14) BM Type Brightness Brightness for monitor LED

(15) BO Type Brightness Brightness for other LED

(16) Channel

(17) C Type switch Indicating pushing a button

(18) sdot sdot sdot

ltMode Changefuncgt

(1) Bundled AC

(2) Extern

(3) Data

(4) Type opMode Type humidMode

(5) Type airVolume Type airPurity

(6) Type Brightness Type switch

(7) Var

(8) Mode A Mode B AV AP BM BO

(9) Channel

(10) C

(11)(12) Function Mode Change

(13) Var

(14) BU Type Brightness User-defined brightness

(15) Require

(16) Mode A==Auto minusgt (AV==W1 || AV==W2 || AV==W3 || AV==W4 || AV==W5)

(17) Mode A==Auto ampamp Mode B==Off ampamp AP==KTY1 minusgt AV==W1

(18) Mode A==Calm minusgt AV==W1

(19) sdot sdot sdot

(20) Mode A=Off ampamp BU==Normal COn BU==Dark

(21) Mode A=Off ampamp BU==Dark COn BU==Off

(22) true COn Mode A== sim Mode A

(23) sdot sdot sdot

Pseudocode 2 An example SENS specification for an air-cleaning system

type with a big size are used In the future our SENS descrip-tion could be more compact by preparing for-statement orwhile-statement descriptions For comparison we also showthe number of pages of the original specifications in a naturallanguage in Table 2

Although we here showed the experimental resultsonly for air-conditioning systems we also have other casestudies applying SENS to specify embedded systems suchas an electric pot and an automatic dispenser For instancewe applied SENS to describe a requirement specificationfor an electric pot (httpwwwsessamejpworkinggroupWorkingGroup2POT Specificationhtm) which has beenopenly used as an example embedded system by SESSAME

(httpwwwsessamejp) (Society of Embedded Software SkillAcquisition for Managers and Engineers) of Japan Theoriginal requirement specification was written in Japaneseincluding state transition diagrams with 14 pages and con-sisting of 14 functions We described approximately 1100lines of the SENS specifications for all the functions whichinclude 28 variables 5 timers and 7 channels in the classspecification and totally 386 requirements for all functionspecifications Through our case studies we confirmed thatSENS is efficiently applicable to not only the air-conditioningsystems but also other general embedded systems

In addition by describing the specifications in SENS wefound several undefined and under-specified requirements

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 12: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

12 Journal of Applied Mathematics

Table 1 Variables in the example specification for function 119865119897

Variable Variable description RangeMode A Mode of operation 6Mode B Mode of humidity 4AV Actual air volume 7AP Air purity 5BM Brightness for monitor LED 3BO Brightness for other LED 3BU User-defined brightness 3C Channel for indicating pushing a button 3

in the original specifications for the target air-conditioningsystem Through the feasibility study we could confirm boththe description ability and facility of SENS Engineers inCompany D plan to use our tool in real development pro-cesses We anticipate that using SENS increases the quality ofspecifications by preventing the undefinition the ambiguityand the inconsistency in the specifications

53 Experiments Test Generation In this section wedescribe several case studies of generating test cases andtest sequences from given example specifications ltAclsgt

and ltBclsgt in Pseudocode 1 and 119865119894 119865119895 119865119896 and 119865

119897 using

our tool TGSENS 119865119896is a specification whose variable range

is reduced from that of 119865119895for testing The experiment was

performed in the following environments Intel Core 2 DuoP8600 24GHz 30GB Memory Microsoft Windows XPSP3 and Sun Java Runtime Environment 160 24

Table 3 describes the result of applying TGSENS to testcase generation In the table we show the size of SENS

specifications the size of CNF the number of test cases andthe execution times to generate test cases for each part ofTGSENS For the size of a SENS specification we representthe number of states and the number of transition labels inthe table Here the number of states indicates the one of thestate space constructed by all possible variable assignmentsin the specificationThe number of transition labels indicatesthe number of labels in the system model constructed fromthe specification

Example 13 Consider the case of 119865119897 The number of possible

states (including states not satisfying the specification) for 119865119897

is 6 times 4 times 7 times 5 times 33 = 68040 from Table 1 The number oftransition labels is 2 as shown in Table 3 Then the numberof all possible state transitions (those that do not satisfy thespecification are included) is 68040 times 2 times 68040 asymp 93 times 109From such a large number of transitions TGSENS figuredout 77700 transitions satisfying the given specification astest cases within 12 seconds For instance as for the filteringoption of including a communication labelTGSENS selected8100 test cases (asymp105 of all the test cases) within 1 second

For 119865119895(resp 119865

119896) TGSENS took only about 26 (resp 1)

minutes to generate approximately 900000 (resp 160000)test cases For example the specification of 119865

119895has 13 variables

including 3 previous state variables and those value ranges are

3 5 5 4 5 5 2 35 35 3 3 3 and 3Then the number of statesfor 119865119895is 2 times 315 times 4 times 54 = 71744535000 asymp 72 times 1010 On the

other hand the numbers of states for119865119896and 119865119897are 45000 and

68040 respectively 119865119895has a feature of including variables

whose range are large like 35 and thus the number of statesis excessively large compared to those of other specificationsThe execution result of 119865

119895indicates that the specification has

71744535000 asymp 72 times 1010 states and 30 transition labels

Then the number of all possible state transitions for 119865119895is

71744535000 times 30 times 71744535000 asymp 15 times 1023 Since thenumber of state transitions for 119865

119895is much larger than those

for 119865119896and 119865

119897 the CNF size for 119865

119895is much larger than those

for 119865119896and 119865

119897 Accordingly 119865

119895needed much execution time

to search test cases Although with such a huge amount ofstate space it is very impossible tomanually check all cases byhuman TGSENS can correctly do that and takes only about26 minutes

We next describe the result of applying TGSENS to testsequence generation Table 4 shows the results using theSENS specification for function 119865

119897with 3 example testing

goals G1ndashG3 In the table for each testing goal we show thenumber of milestone states the maximum lengths betweenmilestones the number of key variables of the given testinggoal the number of test sequences and the execution time togenerate test sequences

Example 14 Pseudocode 3 shows the input file to specifythe testing goal G3 in TGSENS We can also set the testinggoal directly in the GUI interface of TGSENS shown inFigure 9(b) The testing goal G3 specifies the following

(i) key variables (declared in lines 25ndash28) three varia-bles Mode A Mode B and AV in the specifi cation

(ii) The list of milestones (declared in lines 4ndash19)⟨1199041 1199042 1199043⟩ where 119904

1is a state in which Mode A=Auto

1199042is a state in which Mode A=Off and 119904

3is a state in

which Mode A=Auto(iii) maximum lengths between milestones (declared in

lines 22-23) 1199041

le2

997888997888rarr 1199042and 1199042

le2

997888997888rarr 1199043

When the specification for 119865119897and the testing goal G3 are

given a transition system of this function is first obtainedfrom the result of test case generation Then TGSENS

automatically searches desired test sequences satisfying thetesting goal from the transition system Pseudocode 4 showsa part of the generated test sequences

The resulting transition system for 119865119897has 1800 states

and 77700 transitions From the transition system TGSENSfigured out 28 (resp 32) sequences from 119904

1to 1199042(resp 119904

2to

1199043) and thus totally 896 (=28 times 32) test sequences satisfying

the testing goal only in 3 minutes

6 Related Work

Model-based testing technique has been an attractiveresearch area in software engineering field recently [7ndash9]Model-based testing is a technique that derives a desired testcase from amodel or a specification of a system Asmodeling

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 13: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 13

Table 2 Scales of example SENS specifications

System Function SENS Spec Original specNumber of lines Number of variables Number of req Number of pages

Indoor equip 119865ℎ

12 5 7 1Indoor equip 119865

11989422 4 6 1

Indoor equip 119865119895

71 6 22 2Air cleaner 119865

119897101 7 28 4

Controller 119865119898

77 6 22 3Controller 119865

11989952 6 4 4

Controller 119865119900

428 10 47 4

Table 3 Experiment results for test case generation

Systemfunction

SENS Spec CNF Test cases Execution times (sec)Number of

statesNumber oftrans labels

Number ofliterals

Number ofclauses

Number oftest cases

SENS toCNF

Search allassignments

Translate to testcases

119860 12 17 25 68 176 0044 0031 0056119861 4 3 11 19 19 0050 0006 0013119865119894

12 36 36 141 1330 0069 0053 0125119865119895 asymp 72 times 1010 30 620 62845 893155 0175 156590 5657

119865119896

45 times 104 30 102 406 157874 0078 6224 2177119865119897

asymp 68 times 104 3 91 715 77700 0151 9609 1929

(1) [AllTransitionFileName]

(2) mode op2csv

(3)(4) Milestone List

(5) [MilestoneList]

(6) first Milestone

(7) ACMode AAuto

(8) ACAVW3(9) ACAPKTY3(10) ACMode BAuto

(11) ACMode ChangeBU Normal

(12) ACBMNormal(13) ACBONormal(14)(15) second Milestone

(16) ACMode AOff

(17)(18) third Milestone

(19) ACMode AAuto

(20)(21) maximum lengths between two milestones

(22) [StepNumList]

(23) 22

(24)(25) [SelectVarNameList]

(26) ACMode A

(27) ACAV(28) ACMode B

Pseudocode 3 An example testing goal

Table 4 Experiment results for test sequence generation

Number of sequences Exe time(1) (2) (3)

G1 1 2 sdotle2

997888997888rarr sdot 25 13 secG2 1 2 sdot

le3

997888997888rarr sdot 156 8minG3 3 3 sdot

le2

997888997888rarr sdotle2

997888997888rarr sdot 896 3min(1) Number of key variables (2) number of milestones and (3) Maximumlengths

makes it possible to refine or check functionality of targetsystems we can expect to obtain correct test cases generatedfrom valid models in earlier phases of development Thusmodel-based test generation has been attracting the attentionof model-driven software development approaches Model-based testing has two technical issues modeling targetsystems appropriately and generating test cases effectively

As for the modeling many techniques have been pro-posed even if we focus on formal modeling only Mod-els are described based on contracts abstract data typesprocess algebras labeled transition systems data flow andso on These concepts are implemented using specificationlanguages in tools like VDM [7] Z [10] B [11] Spec [12]and JML [13] With most modeling languages a user has tospecify the systemsrsquo behaviors individually

Test case generations frommodels have been proposed inseveral ways Here test cases include arguments to executespecific functions pairs of possible inputs and expected

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 14: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

14 Journal of Applied Mathematics

[Trace 0]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW1]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 1]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW3]

[ACMode BHigh ACMode AAuto ACAVW1]

[Trace 2]

[ACMode BAuto ACMode AAuto ACAVW3]

[ACMode BCont ACMode AAuto ACAVW1]

[ACMode BOff ACMode AOff ACAVW0]

[ACMode BOff ACMode AAuto ACAVW2]

[ACMode BHigh ACMode AAuto ACAVW1]

sdot sdot sdot

Pseudocode 4 An example output Test sequences

outputs or event sequences Test cases are searched by tracingexecutions of models selecting random values with filteringor generating candidates with some algorithms

Here we describe previous works on model-based test-ing Spec Explorer [9] generates test cases by state explorationbased on multiple strategies from contract-like specificationsSpec on a Microsoft NET framework In TGV [8] byINRIA as a part of the CADP (Construction and Analysisof Distributed Processes) package test graphs are generatedfrom labeled transition systems Uppaal-Tron [14] generatestest sequences for real-time systems using the model checkerUPPAAL and an industrial case study of Uppaal-Tron tar-geted an electronic refrigerator controller T-VEC [15] is acoverage-based test generation tool of SimulinkMathWorkswhich has been used to identify a fault in the Mars PolarLander

Somemodel-based test generators use constraints solvingto generate test cases In [16] a test generator based onautofocus is proposed Autofocus [17] is a graphical toolfor model-based development of distributed systems Bytranslating a specification into a constraint logic programthis generator can deal with all the possible execution tracesof the model TestEra [18] is a test generation frameworkfor Java programs By considering pre-postconditions forexecutingmethods as constraints TestEra generates test caseswith SAT-solvers Exhaustive generation is available throughcertain options

Most previous studies targeted the testing of programsor protocols Although TGV has case studies for small-sized embedded applications there are only a few studies onthe large-scale embedded network systems targeted in ourproposed project Different from other works we have pro-posed the original specification language SENS focusing

on property-based specifications and the tool TGSENS toautomatically generate test cases and sequences focusing ontesting goals for embedded network systems

7 Conclusion

In this paper we have proposed a method to automaticallygenerate test cases and sequences based on the specificationof embedded networked systems (ENSs) We first proposeda formal specification language SENS whose features are(1) property-based (2) test-oriented (3) object-oriented(4) modular description and (5) lightweight description oftime constraints By the ldquoproperty-basedrdquo feature such thatrequirements are property-based constraints holding in theentire ENS logical properties for the system specificationare clear and modifications and reuse of the specificationsare easy since a part of specifications less affect the entirespecifications Thus SENS has an advantage on the effi-cient description and reuse of specifications for large andcomplicated ENSs The ldquoobject-orientedrdquo and ldquomodularrdquofeature enables SENS to structurally describe requirementspecifications of ENSs consisting of a number of embeddedsubsystemsequipmentThe ldquolightweightrdquo feature on descrip-tion of time constraints leads to readily specify embeddedsystems sensitive to time requirements In addition the ldquotest-orientedrdquo feature is helpful for automatic test generationfrom SENS specifications To the best of our knowledgethere has been no other formal specification language havingall the above features for ENSs Using SENS we can effi-ciently describe the requirements of ENSs

We next proposed the methods for automatic test gener-ation in the tool TGSENS whose features are summarized as

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 15: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 15

follows (1)TGSENS takes specifications of an ENS writtenin SENS as its input and automatically generates test casesand test sequences (2) the test case generation problem istranslated into a satisfiability problem and test cases aregenerated by iteratively using a SAT solver (3) the testsequences are also automatically obtained based on a testinggoal that is key variables milestone states and a desiredmaximum length of test sequences given by a user Wefinally applied TGSENS to generate tests for the real air-conditioning systems and our tool rapidly succeeded ingenerating about 900000 test cases in 30minutes and extract28 test sequences in 3 minutes

We expect that using TGSENS can improve the quality oftest cases and thus enhance the quality of ENSs Previously inindustrial fields test cases have often been designed in aman-ual way Such the test design depending on testing engineersrsquoskills seldom covers all the requirements of the complicatedENSs On the other hand TGSENS can automatically andmechanically generate test cases from given formal SENSspecifications Both the description of formal specificationsand the automatic test generation lead to improving thequality of test cases Actually we found several undefinedand under-specified requirements by describing the SENSspecifications for real industrial embedded systems as notedin Section 52 In addition TGSENS can generate test caseswith 100 coverage for requirements of the given SENS

specification by an exhaustive search using a SAT-basedsolverTGSENS also supports feasible test generation by user-specified test filtering and test sequence generation

The successive work of our project is the improvementof our test generator in order to deal with the compositionof subsystems One of the most important aspects of testgeneration based on formal specifications and models forindustrial systems is ldquoscalabilityrdquo To overcome this problemwe plan to tackle a higher-speed and more scalable testgeneration using parallel computing We also plan to find aconstructive way of generating test suites of the whole systemfrom test suites of subsystems as a futureworkWe also plan toapply the model checking technique to generate more target-specific test cases and sequences

Appendices

A Syntax of SENS

A1 Main Class Declaration See Pseudocode 5

A2 Class Declaration See Pseudocode 6

A3 Variable Channel and Timer Declarations See Pseudo-code 7

A4 Function and Requirement Declarations See Pseudo-code 8

A5 Expression See Pseudocode 9

B Semantics of SENS

B1 Modeling of Subsystems

States For 119872(119862119894) Let 119881

119862119894= V1 V

119899 denote a set of all

variables used in the SENS specification for the subsystem119862119894 That is 119881

119862119894is a set of all variables declared in the

variable declaration of the class declaration for 119862119894 and the

extern declaration of the class-file-declaration for119862119894 For each

variable V119894(1 le 119894 le 119899) let 119889(V

119894) denote a set of all values of V

119894

declared in the specification When considering a test modellet 119889(V

119894) be a set of all values in the test declaration for V

119894

In addition we also define a set of variables with previousstate operator ldquosimrdquo Let 1198811015840

119862119894= V10158401 V1015840

1198991015840 (sube 119881

119862119894) denote a set

of every variable V1015840119894

isin 119881119862119894whose previous state variable sim V1015840

119894

is used in the specification

Definition 15 (states of 119872(119862119894)) 119878119862119894is a set of all states 119904 such

that(i) 119904 is an (119899 + 1198991015840)-tuple of value assignments for all

variables in 119881119862119894and 1198811015840

119862119894 that is 119904 = (V

1= 1198861 V

119899=

119886119899 sim V10158401

= 11988610158401 sim V1015840

1198991015840 = 11988610158401198991015840) 119886119895

isin 119889(V119895) (1 le 119895 le 119899)

1198861015840119895

isin 119889(V1015840119895) (1 le 119895 le 1198991015840)

(ii) 119904 satisfies all conditions specified as invariants in therequirement declaration of the class declaration for119862

119894

and the invariant declaration

Hereafter we denote 119904 ⊨ (V119894

= 119886119894) if the value for V

119894is

assigned to 119886119894at state 119904 Otherwise 119904 ⊭ (V

119894= 119886119894) and thus

119904 ⊨ (V119894

= 119886119894) since each variable is assigned to one value at the

same time

Labels For 119872(119862119894) Let 119871(119862

119894) be a set of all events and actions

declared in the class declaration and the class-file-declarationfor subsystem 119862

119894 There are three kinds of labels input labels

corresponding events output labels corresponding actionsand label 120591

(i) Input labels are channel-nameexpr and timer-namering and represent message receiving

(ii) Output labels are channel-nameexpr timer-namestart and timer-nameclear and representmessage sending

(iii) Label 120591 means an internal transition with no messagereceiving and sending

Definition 16 (labels of 119872(119862119894)) Σ119862119894is a set of labels such that

Σ119862119894

= 119871 | 119871 isin P (119871 (119862119894)) |in (119871)| le 1 (B1)

where in(119871) denotes a set of input labels in 119871Each 119871 (isin Σ

119862119894) is a set of labels in a transition and we

call 119871 a transition label Note that each transition label cancontain at most one input label and multiple output labelsby the syntax of SENS Transition label 0 in Σ

119862119894corresponds

to 120591

Transitions For 119872(119862119894) Consider a transition requirement

⟨119875 119890 119876 119860⟩ where 119875 is precondition 119890 is event 119876 is

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 16: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

16 Journal of Applied Mathematics

main-class-file-declaration = import-declaration main-class-declarationimport-declaration = ldquoImportrdquo (lsquordquorsquofile-namelsquordquorsquo ldquordquo)+ ldquordquomain-class-declaration = ldquoClass mainrdquo

(constant-declaration | data-declaration| env-instance-declaration| channel-declaration | timer-declaration)+(invariant-declaration)

env-instance-declaration = ldquoVarrdquo (env-variable-declaration | instance-declaration)+env-variable-declaration =

env-variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquoldquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| env-variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[ldquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalueldquordquo) (test-declaration) ldquordquo| env-variable-name ldquo[ldquonumber ldquordquo numberldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)

(ldquo[rdquomin-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquoinstance-declaration=

object-name ldquordquo class-name (ldquo(rdquo parameter-value (ldquordquo parameter-value)lowast ldquo)rdquo) ldquordquo| object-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo class-name(ldquordquo ldquo(rdquovalue (ldquordquo value)lowast ldquo)rdquo (ldquordquo ldquo(rdquo value (ldquordquo value)lowast ldquo)rdquo)lowast ldquordquo) ldquordquo

invariant-declaration= ldquoInvrdquo (expr ldquordquo)+

Pseudocode 5 BNF for main class declaration

class-file-declaration= class-declaration(import-declaration | extern-declaration)

class-declaration= ldquoClassrdquo name (parameter-declaration)(constant-declaration | data-declaration | variable-declaration| channel-declaration | timer-declaration)+(function-declaration | invariant-declaration)+

extern-declaration= ldquoExternrdquo(ldquoConstrdquo const-name (ldquordquo const-name)lowast ldquordquo| ldquoDatardquo type-name (ldquordquo type-name)lowast ldquordquo| ldquoVarrdquo variable-name (ldquordquo variable-name)lowast ldquordquo| ldquoTimerrdquo timer-name (ldquordquo timer-name)lowast ldquordquo| ldquoChannelrdquo channel-name (ldquordquo channel-name)lowast ldquordquo)+

parameter-declaration = ldquo(rdquo parameter-name ldquordquo type-name (ldquordquo parameter-name (ldquordquo type-name)lowast ldquo)rdquoconstant-declaration= ldquoConstrdquo (const-name expr ldquordquo)+

Pseudocode 6 BNF for class declaration

data-declaration= ldquoDatardquo (type-name ldquordquo value (ldquordquovalue)lowast ldquordquovariable-declaration=ldquoVarrdquo

(variable-name ldquordquo type-name (ldquordquo value ldquordquo) (test-declaration) ldquordquo| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name (ldquordquo value (ldquordquo value)lowast ldquordquo) (test-declaration) ldquordquo| variable-name ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquo value ldquordquo) (test-declaration) ldquordquo

| variable-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo (ldquointrdquo | ldquodoublerdquo)(ldquo[rdquo min-value ldquordquo max-value ldquo]rdquo) (ldquordquovalue (ldquordquo value)lowastldquordquo) (test-declaration) ldquordquo

)+test-declaration= ldquotestedwithrdquo ldquordquo (number | number ldquordquo number (ldquo(rdquo number ldquo)rdquo))

(ldquordquo (number | number ldquordquo number (ldquo(ldquo number ldquo)rdquo)) )lowast ldquordquochannel-declaration= ldquoChannelrdquo (channel-name ldquordquo type-name ldquordquo

| (channel-name ldquo[rdquo number ldquordquo number ldquo]rdquo ldquordquo type-name ldquordquo) +timer-declaration =

ldquoTimerrdquo (timer-name number unit ldquo[rdquo predicate ldquo] ldquordquo|timer-name (number unit ldquo[rdquo predicate ldquo]rdquo)lowastnumber unit ldquo[rdquo predicate ldquo]rdquo) ldquordquo)+

unit= ldquomsecrdquo | ldquosecrdquo | ldquominrdquo | ldquohourrdquo | ldquodayrdquo

Pseudocode 7 BNF for variable channel and timer declarations

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 17: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 17

function-file-declaration= ldquoBundledrdquo class-name extern-declaration function-declarationfunction-declaration=

ldquoFunctionrdquo function-name(constant-declaration | data-declaration | variable-declaration | timer-declaration)lowastldquoRequirerdquo (requirement-declaration ldquordquo)+

requirement-declaration= invariant | transition-requirementinvariant= exprtransition-requirement= pre-condition ldquordquo event ldquordquo

(post-condition | (action (ldquordquo | action)lowast) | (post-condition ldquordquo (action (ldquordquo | action)lowast)))precondition= exprpostcondition= exprevent= channel-name ldquordquo expr | timer-name ldquordquo ldquooverrdquo | ldquonullrdquoaction= channel-name ldquordquo expr | timer-name ldquordquo ldquoclearrdquo | timer-name ldquordquo ldquostartrdquo

Pseudocode 8 BNF for function and requirement declerations

expr= expr ldquominus gtrdquo expr | expr ldquo||rdquo expr | expr ldquoampamprdquo expr | expr ldquo == rdquo expr | expr expr ldquo = rdquo expr| expr ldquoltrdquo expr | expr ldquolt=rdquo expr | expr ldquogtrdquo expr | expr ldquogt=rdquo expr | expr ldquo+rdquo expr | expr ldquominusrdquo expr| expr ldquolowastrdquo expr | expr ldquordquo expr | expr ldquordquo expr | ldquo+rdquo expr | ldquominusrdquo expr | ldquordquo expr| number | const | variable | ldquosimrdquo variable | ldquotruerdquo | ldquofalserdquo | ldquo (rdquoexprldquo)rdquo

Pseudocode 9 BNF for expression declaration

postcondition and 119860 is actions We say that a transition 119904119897

997888rarr

1199041015840 satisfies a transition requirement ⟨119875 119890 119876 119860⟩ if and onlyif the following holds

(119904 ⊨ 119875) and (119890 isin 119897) 997888rarr (1199041015840

⊨ 119876) and (119860 sube 119897) (B2)

that is if state 119904 satisfies the precondition 119875 and event 119890

is an input label of 119897 then next state 1199041015840 should satisfy thepostcondition 119876 and actions 119860 should be output labels of 119897Hereafter 119904

119897

997888rarr 1199041015840 denotes a labeled transition (119904 119897 1199041015840)

Definition 17 (transitions of119872(119862119894)) 119877119862119894is a set of all 119904

119897

997888rarr 1199041015840 isin

119878119888119894

times Σ119888119894

times 119878119888119894that satisfies the following two conditions (we

say that such a transition satisfies the given specification)(i) for each state variable sim V

119894isin 1199041015840 1199041015840 ⊨ (sim V

119894= 119886119894) if and

only if 119904 ⊨ (V119894

= 119886119894)

(ii) 119904119897

997888rarr 1199041015840 satisfies all the transition requirements of therequirement declaration in the class declaration forsubsystem 119862

119894

B2 Modeling of Subsystems with Timers

Definition 18 (composition of a subsystem and a timer)119872(119862119894) 119872(119879

119895) is defined as follows Hereafter let 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and let 119901119895denote the condition for timer

119879119895(i) states (119904 119905) isin 119878

119862119894times 119878119879119895

(ii) labels 119871 sube (119871(119862119894) minus Σ119879119895

cup 119888 119879119895

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119895

the following transitions exist

(a1) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)

if 119897119878

ni 119879119895119898119892 and 119897

119879=119898119892

(a2) (119904 119905)119897119878minus119879119895119898119892cup119879119895 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119895119898 and 119897

119879=119898119892

(a3) (119904 119905)119897119878

997888rarr (1199041015840 119905)

if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 and 119897

119879= 119888

(a4) (119904 119905)119888

997888rarr (119904 1199051015840)if 119897119878

cap 119879119895119898119892 119879

119895119898119892 = 0 119897

119879= 119888 and 119904 ⊨ 119901

119895

that is the condition for timer 119879119895holds at state

119904

The transitions of rules (a1) and (a2) represent thecomposition of message synchronization The transitions ofrules (a3) and (a4) represent the interleaving composition oftransitions of subsystem 119862

119894and timer 119879

119895 respectively By this

interleaving composition with a subsystem and a timer thecomposed model can cover all combinations of time lengthin the model

Definition 19 (composition of a subsystem and timers)119872(119862119879

119894) 119872(119879

119896) with 119872(119862119879

119894) = 119872(119862

119894) 119872(119879

1)

sdot sdot sdot 119872(119879119895) is defined as follows Note that 119898119892 isin

119888119897119890119886119903 119904119905119886119903119905 119903119894119899119892 and 119901119896denotes the condition for timer119879

119896

(i) states (119904 119905) isin 119878119862119879119894

times 119878119879119896

(ii) labels 119871 sube (Σ119862119894

minus Σ119879119896

cup 119888 119879119896

119898119892) |in(119871)| le 1

(iii) transitions for each 119904119897119878

997888rarr 1199041015840 isin 119877119862119894and 119905

119897119879

997888rarr 1199051015840 isin 119877119879119896

the following transitions exist

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 18: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

18 Journal of Applied Mathematics

(b1) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b2) (119904 119905)119897119878minus119879119896119898119892cup119879119896 119898119892

997888997888997888997888997888997888997888997888997888997888997888997888997888997888997888rarr (1199041015840 1199051015840)if 119897119878

ni 119879119896119898119892 and 119897

119879=119898119892

(b3) (119904 119905)119897119878

997888rarr (1199041015840 119905)if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 and 119897

119879= 119888

(b4) (119904 119905)119888

997888rarr (119904 1199051015840)

if 119897119878

cap 119879119896119898119892 119879

119896119898119892 119888 = 0 119897

119879= 119888 119904 ⊨ 119901

119896 and

119904 ⊭ 1199011

or sdot sdot sdot or 119901119895

(b5) (119904 119905)119888

997888rarr (1199041015840 1199051015840)if 119897119878

= 119888 119897119879

= 119888 and 119904 ⊨ 119901119896

The transitions of rules (b1) and (b2) represent thecomposition of message synchronization The transitions ofrules (b3) and (b4) represent the interleaving compositionof transitions of subsystem 119862119879

119894and timer 119879

119896 respectively

Transition of rule (b5) represents the synchronization ofcounting up timers Therefore the length relation of timerscan be modeled by using timer model 119872

1in Section 331

B3 Composition of Subsystems

Definition 20 (composition of subsystem models) 119872119879

(119862119894)

119872119879

(119862119895) for subsystems 119862

119894and 119862

119895is defined as follows

(i) states (119904 t) isin 119878119862119879119894

times 119878119862119879119895

where 119878119862119879119894

(119878119862119879119895

) is the setof states of 119872

119879(119862119894)(119872119879

(119862119895))

(ii) labels for each 119871119894(isin Σ119862119879119894

) and 119871119895(isin Σ119862119879119895

)

119871 sube 119871119894

cup 119871119895

minus 119888ℎ119898119892 119888ℎ119898119892 119888 cup 119888ℎ 119898119892 (B3)

where 119888ℎ119898119892 and 119888ℎ119898119892 are respectively input andoutput labels representing receiving and sendingmas-sage 119898119892 with communication channel 119888ℎ betweensystem 119862

119894and 119862

119895 Here 119888ℎ 119898119892 denotes a label after

composing input and output labels with the samename

(iii) transitions let 119871119862

= 119888ℎ119898119892 119888ℎ119898119892|119888ℎ be a com-munication channel between 119862

119894and 119862

119895 and 119871

119873=

119888ℎ119898119892 119888ℎ119898119892|119888ℎ is not a communication channelbetween 119862

119894and 119862

119895 in(119871) and out(119871) respectively

denote a set of input labels and output labels in 119871 The

following transitions exist for each 119904119897119894

997888rarr 1199041015840 isin 119877119862119879119894

and

119906119897119895

997888rarr 1199061015840 isin 119877119862119879119895

(c1) (119904 119906)120591

997888rarr (1199041015840 1199061015840) if 119897119894 119897119895

sub 120591 119888

(c2) (119904 119906)119897119894

997888rarr (1199041015840 119906) if 119897119894

sube 119871119873

(c3) (119904 119906)119897119895

997888rarr (119904 1199061015840) if 119897119895

sube 119871119873

(c4) (119904 119906)119897

997888rarr (1199041015840 119906) if 119897 = in(119897119894) sub 119871119862

(c5) (119904 119906)119897

997888rarr (119904 1199061015840) if 119897 = in(119897119895) sub 119871119862

(c6) (119904 1199061015840)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119894) = 119888ℎ119898119892 out(119897

119895) ni 119888ℎ119898119892

(ii) out(119897119894) cap 119871119862

= 0(iii) (out(119897

119895) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

(c7) (1199041015840 119906)119897

997888rarr (1199041015840 1199061015840) if

(i) in(119897119895) = 119888ℎ119898119892 out(119897

119894) ni 119888ℎ119898119892

(ii) out(119897119895) cap 119871119862

= 0(iii) (out(119897

119894) minus 119888ℎ119898119892) cap 119871

119862= 0

(iv) 119897 = out(119897119894) cup out(119897

119895) cup 119888ℎ 119898119892 minus 119888ℎ119898119892

The transition of rule (c1) represents the compositionof internal transitions labeled with 120591 and 119888 The transitionsof rules (c2) and (c3) represent the composition of internaltransitions labeled with external communication channelsThe transitions of rules (c4)ndash(c7) are for the compositionof two transitions including message synchronization Inthe composition we interpret the meaning of a transitionwith input and output labels of subsystems as illustrated

in Figure 10 In the figure transition (119904 119906)11989721015840

997888997888rarr (119904 1199061015840)

corresponds to rule (c4) where 11989721015840

= in(1198972) Transition(119904 1199061015840)

1198981198973

997888997888997888rarr (1199041015840 1199061015840) corresponds to rule (c6) where 1198973 = 1198971cup1198972

C Translating SENS to Propositional Logic

Here we explain how to translate given a SENS specificationto a propositional logic formula

C1 Variable Declaration For each variable v and its valuet in the SENS specification we introduce two auxiliarypropositional variables representing the value of v in thecurrent state as t (denoted by vt) and the value ofv inthe next state as t (denoted by vt) In addition if thevariable v appears in an expression in the form simv then wealso introduce two auxiliary propositional variables such assimvt and simvtThe value t of v is an element in the domainof v the domain is defined by test declaration or the type ofthe variable

All variables of the SENS specification have the followingtwo constraints (1) a variable must take a value in its domainat any time and (2) a variable cannot take two values at thesame time Moreover if a variable with sim operator appears inan expression the variable has the following constraint thevalue of a variable with sim operator in the next state equals thevalue of the variable without simoperator in the current state

In this translation we need to represent these constraintsas logical formulas by using auxiliary propositional vari-ables For example consider variable op of ltAclsgt inPseudocode 1 The constraints to variable op are as follows

(i) (oponor opoff) and (oponor opoff)

(ii) (notoponor notopoff)and (notoponor notopoff)

(iii) (simoponhArropon)and(simopoffhArropoff)

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 19: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 19

s

s998400

u

u998400

l9984002

m

l1

l9984002

s

s998400 u998400

s998400

u

u998400

m l1

s u

s u998400

s998400 u998400

m l3

m l9984009984002

m l2|| =

Figure 10 A transition composition of subsystems

C2 Timer Declaration We translate the timer declarationstep-by-step considering the three parts a subsystem sidea timer side and a composition of the subsystem and thetimers

First on the subsystem side we prepare four kinds ofpropositional variables as follows

(i) SubCountUp a counting up event occurring in asubsystem is prepared there exists only one variableof this kind for each subsystem

(ii) tring a subsystem receives a counting over eventfrom its timer t

(iii) tclear a subsystem does an action by sending areset message to its timer t

(iv) tstart a subsystem does an action by sending astartup message to its timer t

We assume that no more than one event or action relatedto the same timer t occurs at the same timeWe represent thisconstraint as follows

(i) (nottring or nottclear) and (nottring or nottstart)

and(nottclear or nottstart)

and(nottring or notSubCountUp)

and(nottclear or notSubCountUp)

and(nottstart or notSubCountUp)

Next on the timer side we introduce auxiliary propo-sitional variables for two events an action a counting-upevent and the states of each timerThepropositional variablesprepared for timer t are as follows

(i) tcleartstart for resetstart-up event from thesubsystem

(ii) tring an action of sending the counting overmessage

(iii) tCountUp a counting-up event of the timer(iv) treadytruntover the current timer state(v) treadytruntover the next timer state

Timer t in the subsystem has the following constraintsandwe represent themusing prepared propositional variablesas follows

(i) the events and action of timer t do not occur at thesame time

(a) (nottclear or nottstart)

and(nottclear or nottring)

and(nottstart or nottring)

and(nottclear or nottCountUp)

and(nottstart or nottCountUp)

and(nottring or nottCountUp)

(ii) at any time the state of a timer is one of three statesready run and over

(a) (tready or trun or tover)

and(treadyor trunor tover)

(b) (nottready or nottrun)

and(nottreadyor nottover)

and(nottrunor nottover)

and(nottreadyornottrun)

and(nottreadyornottover)

and(nottrunornottover)

(iii) the transition relation of the timer models is the sameas the one in Figure 5

(a) tclearrarr tready

(b) tstarthArr(treadyand trun)

(c) tringhArr(trunandtover)

(d) tCountUprarr (trunand trun)

(e) (treadyandnottclearandnottstartrarrtready)

and(trun and nottclear and nottring

andnottCountUprarr trun)

and(toverand nottclearrarr tover)

(iv) when the timer declaration has a condition for count-ing up that is a logical formula cond the followingtwo formulas are added

(a) tstart rarr cond

(b) tCountUp rarr cond

Finally we describe constraints of composition betweena subsystem and timers

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 20: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

20 Journal of Applied Mathematics

(i) Events and actions of a subsystem are associated withactions and events of each timer t

(a) tclear hArr tclear

(b) tstart hArr tstart

(c) tring hArr tring

(ii) For timers of each subsystem all the timers satisfyingtheir counting up conditions count up at the sametime

(a) (t1CountUp rarr SubCountUp)

and(t2CountUp rarr SubCountUp)

and sdot sdot sdot and (tnCountUp rarr SubCountUp)

(b) SubCountUp rarr (t1CountUp or t2CountUp

or sdot sdot sdot or tnCountUp)

(c) SubCountUp rarr ((condt1) rarr t1CountUp)

and(condt2) rarr t2CountUp)

and sdot sdot sdot and (condtn) rarr tnCountUp)

where condti is the counting up condition oftimer ti

(iii) The counting up of timers in a subsystem and achange of the values of variables in the subsystemdo not occur at the same time Consider variableop of ltAclsgt in Pseudocode 1 This constraint isrepresented by the following formula

(a) (SubCountUp and op on rarr op on)

and(SubCountUp and op off rarr op off)

C3 Channel Declaration For events through a channelwe prepare propositional variables A variable denoted bycm shows that the event of receiving message m throughchannel c occurs In addition for each subsystem prepareone propositional variable representing that no event occurs(denoted by nulltrue)

No more than one event occurs at the same time in asubsystem where we consider the counting over of a timerand the counting up of a subsystem as events We need torepresent this constraint of event as logical formulas by usingprepared variables For example consider the subsystemltAclsgt in Pseudocode 1 The subsystem has two eventsa timer-over event and a counting up the timer So theconstraint of events in ltAclsgt is translated as follows

(i) tring or SubCountUp or nulltrue

(ii) (nottring or notSubCountUp)

and(nottring or notnulltrue)

and(notSubCountUp or notnulltrue)

For actions as well as events we prepare propositionalvariables A variable denoted by objcm shows that asubsystem takes the action of sending message m to a districtsubsystem obj througha receiverrsquos channel c

There is a constraint that a subsystem cannot take anyaction if its counting-up event occurs For example considerthe subsystem ltAclsgt Since it has two actions the con-straint of actions is expressed by the following formula

(i) (notarg1chmornotSubCountUp)and(notarg2chmornotSubCountUp)

C4 Requirements Basically in the translation of require-ments of a SENS specification we only have to replace therequirements with logical formulas using the propositionalvariables prepared above A requirement represented as alogical expression in SENS should be satisfied both in thecurrent state and in the next state Therefore we translate therequirement into two logical formulas one for the currentstate and the other for the next state

The transition requirement of SENS specifications ldquoP e(Q a)rdquo represents a logical implication ldquo(Pande) rarr (Qanda)rdquoThe postcondition Q is a constraint for the next state sowe translate the condition into a logical formula usingpropositional variables for the next state

For example consider the two requirements of ltBclsgt

in Pseudocode 1 They are translated as follows

(i) (oponandlampoffandchm)rarr (lampon)

(ii) opoffrarr lampoff opoffrarr lampoff

All the variables ofSENS including variables of numericaltypes take only a finite number of values We start explainingthe translation using the following examples

Var a int [02] b int [02]

(i) comparison between a variable of SENS and a numer-ical value

(a) the equation a==0 is denoted by a propositionalvariable a0 and the inequation a=0 is denotedby a literal nota0

(b) the inequality alt2 is translated to a logicalformula a0ora1

(ii) comparison between variables

(a) the equation a==b is translated to a formula(a0and b0)or(a1and b1) or (a2and b2)

(b) the inequation a=b is translated to a formulanot((a0and b0) or (a1and b1)

or (a2andb2))(c) the inequality altb is translated to a formula

(a0and (b1or b2)) or (a1 and b2)

For general numerical comparison we translate therequirement inductively In particular let exp

1sim exp

2be

a general numerical comparison in SENS where simisin le ge

= = and exp1 exp2are expressions We transform this

requirement to logical formula as follows First we introducetwo auxiliary variables V

1and V

2 these variables represent

exp1and exp

2 respectively The requirement exp

1sim exp

2

is reduced to V1

sim V2 Second based on the domain of

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 21: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Journal of Applied Mathematics 21

input variables we can compute the domain (lower and uppervalues) of V

1and V2 Assume that V

1isin [1198971 1199061] and V

2isin [1198972 1199062]

The requirement V1

sim V2is translated to logical formula by a

similar way as in the example above

Conflict of Interests

The authors declare that they have no conflict of interests

Acknowledgments

The authors thank Takao Sonoda Shouichi HasuikeMunekazu Huruichi Keiichi Shimatani and Hayato ShikataofDaiKin Industries for their great contribution in their jointproject This paper was partly supported by the JSPS-VASTbilateral research project

References

[1] I Craggs M Sardis and T Heuillard ldquoAGEDIS case studiesmodel-based testing in industryrdquo in Proceedings of the 1stEuropeanConference onModel-Driven Software Engineering pp106ndash117 Nuremburg Germany 2003

[2] A Gargantini and C L Heitmeyer ldquoUsing model checking togenerate tests from requirements specificationsrdquo in SoftwareEngineering O Nierstrasz and M Lemoine Eds vol 1687 ofLecture Notes in Computer Science pp 146ndash162 Springer BerlinGermany 1999 Proceedings of the 7th European SoftwareEngineering Conference Held Jointly with the 7th ACM SIG-SOFT International Symposium on Foundations of SoftwareEngineering

[3] G Hamon L De Moura and J Rushby ldquoGenerating efficienttest sets with a model checkerrdquo in Proceedings of the 2nd IEEEInternational Conference on Software Engineering and FormalMethods (SEFM rsquo04) pp 261ndash270 Beijing China September2004

[4] H S Hong S D Cha I Lee O Sokolsky and H Ural ldquoDataflow testing as model checkingrdquo in Proceedings of the 25thInternational Conference on Software Engineering (ICSE rsquo03) pp232ndash242 Portland Ore USA May 2003

[5] N Een and N Sorensson ldquoAn extensible SAT-solverrdquo inTheoryand Applications of Satisfiability Testing E Giunchiglia and ATacchella Eds vol 2919 of Lecture Notes in Computer Sciencepp 502ndash518 Springer Berlin Germany 2004

[6] G Tseitin ldquoOn the complexity of derivation in propositionalcalculusrdquo in Structures in Constructive Mathematics and Math-ematical Logic A O Silenko Ed part 2 pp 115ndash125 1968

[7] C B Jones Systematic Software Development Using VDMPrentice-Hall International Series in Computer Science Pren-tice Hall Upper Saddle River NJ USA 2nd edition 1990

[8] C Jard and T Jeron ldquoTGV theory principles and algorithms atool for the automatic synthesis of conformance test cases fornon-deterministic reactive systemsrdquo International Journal onSoftware Tools for Technology Transfer vol 7 no 4 pp 297ndash3152005

[9] M Veanes C Campbell W Grieskamp W Schulte N Till-mann and L Nachmanson ldquoModel-based testing of object-oriented reactive systems with spec explorerrdquo in Formal Meth-ods and Testing R M Hierons J P Bowen and M HarmanEds vol 4949 of Lecture Notes in Computer Science pp 39ndash76Springer Berlin Germany 2008

[10] B Potter D Till and J Sinclair An Introduction to FormalSpecification and Z Prentice Hall New York NY USA 1996

[11] A Hoare P Chapron and J R Abrial The B-Book AssigningPrograms to Meanings Cambridge University Press New YorkNY USA 1996

[12] M Barnett K Rustan M Leino and W Schulte ldquoThe Specprogramming system an overviewrdquo in Construction and Anal-ysis of Safe Secure and Interoperable Smart Devices G BartheL Burdy M Huisman J-L Lanet and T Muntean Eds vol3362 of Lecture Notes in Computer Science pp 49ndash69 SpringerBerlin Germany 2004

[13] L Burdy Y Cheon D R Cok et al ldquoAn overview of JML toolsand applicationsrdquo International Journal on Software Tools forTechnology Transfer vol 7 no 3 pp 212ndash232 2005

[14] K G Larsen M Mikucionis B Nielsen and A Skou ldquoTestingreal-time embedded software using UPPAAL-TRON an indus-trial case studyrdquo in Proceedings of the 5th ACM InternationalConference on Embedded Software (EMSOFT rsquo05) pp 299ndash306Jersey City NJ USA September 2005

[15] M R Blackburn andRD Busser ldquoT-VEC a tool for developingcritical systemsrdquo in Proceedings of the 11th Annual Conferenceon Computer Assurance (COMPASS rsquo96) pp 237ndash249 Gaithers-burg Md USA June 1996

[16] J Philipps A Pretschner O Slotosch E Aiglstorfer S Kriebeland K Scholl ldquoModel-based test case generation for smartcardsrdquo Electronic Notes inTheoretical Computer Science vol 80pp 170ndash184 2003

[17] F Huber B Schatz and G Einert ldquoConsistent graphicalspecification of distributed systemsrdquo in Industrial Applicationsand Strengthened Foundations of Formal Methods J FitzgeraldC B Jones and P Lucas Eds vol 1313 of Lecture Notes inComputer Science pp 122ndash141 Springer Berlin Germany 1997

[18] S Khurshid and D Marinov ldquoTestEra specification-basedtesting of java programs using SATrdquo Automated Software Engi-neering vol 11 no 4 pp 403ndash434 2004

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Page 22: Research Article Formal Specification Based Automatic Test ...downloads.hindawi.com/journals/jam/2014/909762.pdfResearch Article Formal Specification Based Automatic Test Generation

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of