View
5
Download
0
Category
Preview:
Citation preview
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Recommended