EVALUATION D'OUTILS DE VERIFICATION POUR LES
SPECIFICATIONS DE SYSTEMES D'INFORMATION
par
Romain Chossart
Memoire presente au Departement d'informatique
en vue de l'obtention du grade de maitre es sciences (M.Sc.)
FACULTE DES SCIENCES
UNIVERSITE DE SHERBROOKE
1*1
Library and Archives Canada Published Heritage Branch 395 Wellington Street Ottawa ON K1A 0N4 Canada Bibliotheque et Archives Canada Direction du Patrimoine de I'edition 395, rue Wellington Ottawa ON K1A 0N4 CanadaYour file Votre reference ISBN: 978-0-494-61411 -2 Our We Notre reference ISBN: 978-0-494-61411 -2
NOTICE: AVIS:
The author has granted a
non-exclusive license allowing Library and Archives Canada to reproduce, publish, archive, preserve, conserve, communicate to the public by
telecommunication or on the Internet, loan, distribute and sell theses
worldwide, for commercial or non-commercial purposes, in microform, paper, electronic and/or any other formats.
L'auteur a accorde une licence non exclusive permettant a la Bibliotheque et Archives Canada de reproduire, publier, archiver, sauvegarder, conserver, transmettre au public par telecommunication ou par I'lnternet, prefer, distribuer et vendre des theses partout dans le monde, a des fins commerciales ou autres, sur support microforme, papier, electronique et/ou autres formats.
The author retains copyright ownership and moral rights in this thesis. Neither the thesis nor substantial extracts from it may be printed or otherwise reproduced without the author's permission.
L'auteur conserve la propriete du droit d'auteur et des droits moraux qui protege cette these. Ni la these ni des extraits substantiels de celle-ci ne doivent etre imprimes ou autrement
reproduits sans son autorisation.
In compliance with the Canadian Privacy Act some supporting forms may have been removed from this thesis.
Conformement a la loi canadienne sur la protection de la vie privee, quelques
formulaires secondaires ont ete enleves de cette these.
While these forms may be included in the document page count, their removal does not represent any loss of content from the thesis.
Bien que ces formulaires aient inclus dans la pagination, il n'y aura aucun contenu manquant.
1+1
Canada
Sommaire
Ce memoire par article decrit la comparaison de deux verificateurs de modeles pour EB3. L'integration d'un verificateur de modeles a la plateforme APIS permet de verifier que
les specifications des systemes d'information ecrites en EB3 verifient certaines proprietes. Ainsi, nous pourrons affirmer que les systemes d'information generes avec la methode APIS sont valides, c'est-a-dire conformes au cahier des charges formule par le client. Cette etape de validation est importante dans tout projet car elle indique si le concepteur a atteint ses objectifs.
Une analyse du probleme conduit a traduire les specifications EB3 dans un langage ac-cepte par un verificateur de modeles. II convient done de faire le choix d'un verificateur de modeles adapte aux specifications de systemes d'information ecrites en EB3.
Ce memoire compare deux verificateurs de modeles, SPIN et CADP, dans le cadre de la verification de specifications EB3. Pour illustrer ce travail, nous avons modelise un systeme d'information de bibliotheque dans leurs langages respectifs, PROMELA et LOTOS-NT. Les processus de verification ont ete appliques a ces specifications afin de comparer les deux verificateurs de modeles. Notre objectif ultime est de convertir automatiquement les speci-fications EB3 en langage du verificateur de modeles choisi pour reduire au minimum l'inter-vention humaine durant le processus de verification.
Le ler avril 2010
lejury a accepte le memoire de Monsieur Romain Chossart dans sa version finale.
Membres du jury
Professeur Marc Frappier Directeur de recherche Departement d'informatique
Monsieur Benoit Fraikin Codirecteur de recherche Departement d'informatique
Professeur Gerard Berthelot Membre
Ecole nationale superieure d'informatique pour l'industrie et l'entreprise (ENSUE)
Professeur Richard St-Denis President rapporteur Departement d'informatique
Remerciements
Je remercie tout d'abord Marc Frappier, mon directeur de maitrise, qui malgre son emploi du temps charge, arrive a consacrer tout le temps necessaire a ses etudiants. Sa bonne humeur et son etat d'esprit positif sont tres agreables et nous donnent a tous des coups de pouce lorsque nous en avons besoin.
Merci a Benoit Fraikin, mon codirecteur de maitrise, qui est tres proche de ses etu-diants. II a su partager ses connaissances dans de nombreux domaines —en particulier la verification de modeles et l'utilisation d'outils pour la recherche— et m'a donne une grande quantite d'articles et de references que Ton retrouve tout au long de ce memoire.
Merci a Richard St-Denis. Ses questions pertinentes et sa rigueur nous ont ete profitable a tous, en particulier dans les reunions.
Merci a Jeremy Milhau, Pierre Konopacki, Michel Embe Jiague, Medhi Ettouhami et Imade Yassine d'avoir repondu aux nombreuses questions que j'ai posees lors de mes re-cherches, et d'avoir su me supporter en tant que collegue de travail! Je remercie egalement Frederic Gervais pour de nombreuses raisons differentes, mais je citerai surtout les nom-breux conseils et les maintes explications qu'il m'a donnes sur la recherche en general : l'utilisation de bibtex, le fonctionnement de la soumission des articles, la maniere de trou-ver les informations qui nous interessent. Merci a Regine Laleau pour ses conseils avises lors de nos reunions. Sa connaissance generate sur les sujets proches de la verification de modeles ont permis de prendre de bonnes directions lorsqu'il le fallait.
Merci enfin a Kevin Salabert et Mohammed Ouenzar, ainsi qu'a tous les autres membres du laboratoire qui m'ont succede, grace a qui j'ai pu passer de l'autre cote de la ligne en leur faisant partager a mon tour les connaissances que j'ai acquises pendant mes etudes. J'ai appris grace a eux que la recherche permet avant tout de partager nos connaissances avec les autres.
Abreviations
ACTL Action Computational Tree Logic (logique de branchement pour les actions) APIS Automatic Production of Information System (production automatique de systemes
d'information) BD Base de donnees
BDD Binary Decision Diagram (diagramme de decision binaire)
CSP Communicating Sequential Process (processus sequentiel communicant) E2B3 Error messages for EB3 (messages d'erreur pour EB3)
EB3 Entity-Based Black Box (boite noire basee sur les entites) EB3GG EB3 Guard Generator (generateur de gardes pour EB3)
EB3IO EB3 Input and Output (entrees et sorties pour EB3)
EB3PAI EB3 Process Algebra Interpreter (interpreteur d'algebre de processus pour EB3)
EB3TG EB3 Transaction Generator (generateur de transactions pour EB3)
ER Entite-relation
DCI-WEB Description comportementale d'interface web LTL Linear Temporal Logic (logique temporelle lineaire)
UML Unified Modelling Language (langage de modelisation unifie) XTL extended Temporal Logic (logique temporelle etendue)
Table des matieres
Sommaire i
Remerciements ii
Abreviations iii
Table des matieres iv
Liste des figures vi
Liste des programmes vii
Introduction 1
1 Contexte et etat de l'art 4 1.1 LeprojetAPis 4
1.1.1 Presentation de la methode 4
1.1.2 Les outils de la methode APIS 7
1.2 Presentation de la verification de modeles 8 1.2.1 Verificateurs de modeles existants 8
1.2.2 Revue de litterature 9 2 Comparaison de verificateurs de modeles 12
2.1 Introduction . 15 2.2 Related Work 17 2.3 Presentation of the Case Study 19
TABLE DES MATIERES
2.3.1 Context : . . 19
2.3.2 User Requirements of the Library System 21
2.4 An Overview of the Model Checkers 21 2.4.1 An Overview of the Verification Process 23
2.4.2 The Specification Languages 24 2.4.3 The Temporal languages 26 2.4.4 Simulators and Validations Tools •• • 27
2.5 Analysis of the Case Study . . . 28 2.5.1 The Specification Writing 28. 2.5.2 Specification of Properties 33 2.5.3 The Description of the Verification Process 35
2.6 The Ease To Translate From EB3 36
2.7 Conclusion 37
Conclusion 39
Liste des figures
1.1 Diagramme montrant les differentes etapes de la generation de systemes
d'information avec APIS 5
2.1 The overall process of IS generation and validation 16 2.2 Requirement class diagram of the library system 20 2.3 Properties to be verified by the model checker 22
2.4 CADP general verification process 23
2.5 SPIN general verification process 24
2.6 Execution steps of the programme 2.3 and the programme 2.4 33 2.7 Duration in seconds of each step of the process for the library specification . 36
3.1 Requirements properties of sous-section 2.3.2 expressed in LTL for SPIN
model checker (part 1) 52 3.2 Requirements properties of sous-section 2.3.2 expressed in LTL for SPIN
model checker (part 2) 60
3.3 Predicate definition in SPIN 61
Liste des programmes
2.1 An example of Kleene closure in LOTOS-NT 25 2.2 The controller part of the Book process. Functions beginning with "ml_"
are functions on the book's reservation list (a list of members) 30 2.3 PROMELA handshake pattern for a producer/consumer event between two
associations — association Rl 32 2.4 PROMELA handshake pattern for a producer/consumer event between two
associations — association R2 33 3.1 The main behavior of the LOTOS-NT specification 42
3.2 The type definition of the LOTOS-NT specification 42 3.3 The function definition of the LOTOS-NT specification 43 3.4 The behavior of the LOTOS-NT specification (loan and reservation) . . . . 44
3.5 The behavior of the LOTOS-NT specification (member) 45 3.6 The behavior of the LOTOS-NT specification (book, part 1) 46 3.7 The behavior of the LOTOS-NT specification (book, part 2) 47 3.8 Expression of the weak until operator in XTL with their denotational
defi-nition 48 3.9 Expression of the two temporal patterns in XTL 49
3.10 List of XTL properties, part 1 50 3.11 List of XTL properties, part 2 51 3.12 Macro of the pre-post condition of the entities actions in the PROMELA
spe-cification 53 3.13 Macro of the pre-post condition of the association actions in the PROMELA
LlSTE DES PROGRAMMES
3.14 Macro of the pre-post condition of the entities actions in the PROMELA
spe-cification (part 2) 55 3.15 Macro of the pre-post condition of the take action in the PROMELA
specifi-cation 56
3.16 Global variable of the PROMELA specification 57
3.17 Definition of the member process in the PROMELA specification 57 3.18 Definition of the book process in the PROMELA specification 57 3.19 Definition of the loan process in the PROMELA specification 58 3.20 Definition of the reservation process in the PROMELA specification 59
Introduction
Contexte
De nos jours, personne n'imagine vivre dans un monde sans systeme d'information. Leurs applications sont multiples et touchent la majorite des services : banques, telecom-munications, transports, vente en ligne... Les exemples ne manquent pas.
Cependant, la plupart contiennent des erreurs de conception. Certaines n'ont pas d'im-pact majeur sur leur utilisation. D'autres, au contraire, peuvent avoir des repercussions de-sastreuses et causer des pertes humaines ou materielles. On peut citer 1'explosion en plein vol de la fusee Ariane 5 en 1996 ou le defaut des processeurs Intel en 1994. Les methodes formelles visent a reduire ou eliminer ces erreurs en utilisant un processus rigoureux fonde sur des notations mathematiques precises et des techniques de verification exhaustive.
Motivations et problematique
Les methodes formelles servent a prouver que chaque etape de la creation d'un pro-duit est conforme a 1'etape precedente. Les differentes methodes reposent generalement sur un principe commun : 1'utilisation d'un langage formel permettant de se conformer aux besoins du client. A contrario, avec les methodes non formelles utilisant par exemple le langage populaire UML, le produit final risque de ne pas correspondre au cahier des charges.
Pour pallier ce probleme, le laboratoire du GRIL, a l'Universite de Sherbrooke, a cree pour les systemes d'information une methode formelle, APIS [20] (Automatic Production of
Information Systems). Cette methode utilise le langage de specification EB3 pour modeliser les systemes d'information. La syntaxe et la semantique du langage sont deja specifiees.
INTRODUCTION
Plusieurs interpreteurs ont ete developpes. La methode de validation n'a cependant pas ete completee. II est done necessaire de choisir une methode adaptee pour verifier que les specifications EB3 sont conformes aux exigences formulees par le client.
Methodologie
On distingue principalement deux methodes de verification : - celles qui utilisent les preuves, comme la methode B [1];
- celles qui verifient exhaustivement des proprietes temporelles sur chaque etat du sys-teme, appelees verification de modeles.
Nous avons choisi la seconde methode. En effet, EB3 est peu adapte a la verification par preuves qui exige generalement une intervention humaine durant tout le processus ainsi qu'une expertise poussee. Un des avantages majeurs de la verification de modeles sur l'ap-proche par preuve est la facilite a traduire automatiquement la specification EB3 en langage du verificateur de modeles. Cette automatisation permet de se concentrer sur l'ecriture des proprietes qu'on souhaite verifier. De plus, une fois la traduction prouvee formellement, il est assure que le modele cree est bien equivalent a la specification EB3 originale.
L'equipe a envisage la possibility de creer un verificateur de modeles specifique a EB3. Toutefois, cette solution a ete estimee trop couteuse. II valait mieux utiliser un outil existant. Une piste consistant a faire un compilateur vers un systeme a transitions etiquetees a ete exploree. Ce systeme a transitions etiquetees pouvait alors etre v'erifie par un verificateur de modeles existant. Les algorithmes qui optimisent la generation des systemes a transitions etiquetees sont deja implementes dans de nombreux outils. Leur developpement aurait done ete une perte de temps.
Nous avons done decide de traduire les specifications EB3 en langage d'entree d'un verificateur de modeles. L'objectif de ces recherches vise a choisir un verificateur de
mo-deles adapte a la verification de specifications EB3. Ce sujet souleve de nombreuses pro-blematiques car il n'existe a priori aucun verificateur de modeles parfait pour satisfaire cet objectif. Nous voulons choisir une methode qui offre un compromis entre la facilite de traduction depuis EB3, la facilite d'expression des proprietes, le pouvoir d'expression de la logique temporelle et la rapidite du processus de verification.
INTRODUCTION
Resultats
Pour couvrir le plus de criteres de comparaison possibles, nous avons choisi deux veri-ficateurs de modeles complementaires : SPIN et CADP. Le premier est base sur les etats et uti-lise PROMELA, un langage syntaxiquement proche de C. II contient des operateurs simples et peut etre considere comme bas-niveau. Le second est base sur les actions et utilise LOTOS1, un langage proche de CSP [29] fonde sur une algebre de processus. SPIN travaille a la volee et teste des proprietes formulees en logique temporelle lineaire (LTL). CADP, a 1'oppose, passe par une etape de compilation vers un systeme a transitions etiquetees pour verifier des proprietes ecrites en XTL, un langage de parcours de graphes qui fournit entre autres une librairie ACTL. Ces deux verificateurs de modeles ont done permis de regrouper et d'evaluer un grand nombre de criteres pour le choix d'un verificateur de modeles adapte aux specifications EB3.
Structure du memoire
Ce memoire par article est constitue de trois parties. Un etat de 1'art est introduit au chapitre 1. II expose les travaux connexes ainsi que l'utilite du sujet de recherche pour la communaute scientifique. Dans le chapitre 2, un article decrit la comparaison de SPES et CADP pour la verification d'un systeme d'information de bibliotheque. Enfin, les annexes contiennent les sources des deux specifications, ainsi que 1'expression des proprietes testees dans les langages temporels correspondants.
Chapitre 1
Contexte et etat de Fart
1.1 Le projet
APIS1.1.1 Presentation de la methode
Le projet APIS a pour objectif de generer automatiquement des systemes d'information a partir de specifications formelles. Pour cela, APIS a besoin de cinq elements qui sont utilises dans une ou plusieurs phases de la generation automatique. La figure 1.1 montre ces diffe-rentes etapes avec leur enchainement. Celles-ci vont maintenant etre expliquees en detail.
Le diagramme entite-relation
Le diagramme entite-relation (ER) est exprime en UML et contient les attributs et les actions des differentes entites et associations. II permet notamment de generer le schema de la base de donnees et invite l'utilisateur a ecrire les systemes d'information a l'aide de patrons du type producteur-modificateur-consommateur permettant d'accelerer le develop-pement des specifications EB3 dans le cadre de la methode APIS.
La definition des attributs
Les attributs ont des valeurs qui varient lors de l'execution du systeme d'information. Comme on considere qu'une partie suffisante de l'etat du systeme est determinee par la
1.1. L E PROJET APIS IIS Specification ^ Software Engineer IS User ER Diagram! Attribute Definitions M ra Process Expressions —» * Web interface \ Query Programs ijk \ \ 1 ..'" V | ^ '
S
Update Programs i. ^ -A • •*•-i m •*•-i •*•-iBB
DBMS • — • « _ ^ 5 DB Schema cr ^a D B_Jfigure 1.1 - Diagramme montrant les differentes etapes de la generation de systemes d'in-formation avec APIS
1.1. L E PROJET APIS
trace des actions, la definition des attributs prend la forme de fonctions recursives sur la trace. II y a une et une seule fonction par attribut.
Cette methode pose des problemes de complexite, car plus la trace augmente, et plus les attributs prennent de temps a calculer. Ces fonctions sont done implementees differemment a l'aide d'une base de donnees grace a l'outil EB3TG [25], developpe par Frederic Gervais et
Panawe Batanado.
Les regies d'entree-sortie
Cette etape permet de definir les differentes informations qui peuvent etre inserees dans le systeme, ou bien affichees en sortie. Elle fixe notamment la signature des fonctions d'entree-sortie (E/S) afin de definir ce qu'attend l'interpreteur de la part d'un utilisateur. Elle permet egalement d'assurer la validite de 1'expression de processus EB3 vis-a-vis de ces signatures. Couplees au diagramme ER, les regies d'entree-sortie permettent de gene-rer automatiquement les requetes de bases de donnees associees via EB3IO [46], cree par
Imade Yassine.
La specification de l'interface graphique
Cette etape permer de definir clairement l'interface avec 1'utilisateur. Elle donne les possibilites d'actions precises a chaque utilisateur et affiche les informations qui le concer-ned. Deux outils concernant la generation des interfaces graphiques ont ete developpes. DCI-WEB[2] permet de creer un frontal Web et E2B3 genere des messages d'erreur adaptes au
contexte d'execution.
L'expression de processus EB3
EB3 est un langage qui a ete cree pour repondre au besoin precis de la specification formelle de systemes d'information. II permet de definir le comportement des processus du systeme d'information. Inspire de CSP [43, 29], il est base sur une algebre de processus. EB3 contient des operateurs tels que la sequence, le choix et le parallele. Sa syntaxe, voulue tres lisible, est proche des expressions regulieres. Le lecteur peut se referer a [18, 21] pour de plus amples informations sur ce langage.
1.1. L E PROJET APIS
1.1.2 Les outils de la methode
APISPlusieurs outils ont deja ete developpes pour la methode APIS. Cette section presente les fonctionnalites les plus importantes dans ce processus de generation.
EB3PAI est un interpreteur de specifications EB3. II prend en entree une specification et
permet a l'utilisateur d'effectuer des actions. EB3PAI s'occupe de determiner si Taction est
autorisee par le processus. Le cas echeant, il l'effectue; sinon, il revoie une erreur a l'aide de E2B3 [38] indiquant que Taction demandee n'est pas acceptee. Une version en OCaml a
egalement ete creee et se nomme OCAMLPAI.
EB3IO permet de generer les requetes de bases de donnees (BD) correspondant aux regies
E/S. Lorsque l'utilisateur effectue des actions dans le systeme, les requetes associees sont executees dans la BD.
EB3TG s'occupe de creer les transactions qui modifient les entites dans la BD lorsque des
actions sont acceptees par EB3PAI. Cela permet notamment d'optimiser T implementation en
evitant de lire la trace des actions effectuees. En effet, cette derniere est de plus en plus grande au cours de T execution du systeme d'information, ce qui compromet la rapidite de traitement des calculs a partir d'un certain nombre d'actions executees.
DCI-WEB genere Tinterface Web permettant a l'utilisateur d'effectuer des actions dans le systeme d'information. La specification de Tinterface comprend la mise en page des elements, les transitions entre les pages et les donnees relatives a la navigation.
EB3GG [32] sert a analyser les gardes EB3 et a generer des fonctions contenant les
re-quetes de BD correspondantes. Pour evaluer une garde, la fonction associee a la garde est executee. Le resultat de cette derniere determine si la garde s'avere vraie ou fausse.
E2B3 permet de generer des messages d'erreur pour l'utilisateur lorsqu'une action a ete
refusee. II utilise un algorithme qui essaie de detecter la cause du refus afin de donner des informations intelligibles et pertinentes.
On remarque qu'aucun outil n'est disponible concernant la verification de proprietes. Ce memoire a pour objectif de pallier cette lacune.
1.2. PRESENTATION DE LA VERIFICATION DE MODELES
1.2 Presentation de la verification de modeles
On distingue generalement deux approches pour la verification de proprietes. La pre-miere est appelee approche par preuves et consiste a trouver des regies permettant de prou-ver que certaines proprietes (generalement des invariants) sont correctes pour le modele en question. Cette approche est notamment utilisee par la methode B [1], qui a deja servi a prouver de nombreux systemes dans l'industrie, comme celui de la ligne de metro METEOR a Paris. La seconde approche est nominee verification de modeles et consiste a explorer exhaustivement l'espace d'etats du modele arm de verifier que des proprietes de logique temporelles sont correctes. Cette derniere approche a suscite notre interet.
1.2.1 Verificateurs de modeles existants
La verification de modeles est une technique de verification qui a vu le jour il y a environ trente ans. Les premiers verificateurs de modeles ont ete implemented dans les annees 1980. Parmi eux nous pouvons citer SMV [9], SPIN [16], EMC [8] et Caesar [23]. Faisant face au probleme de l'explosion de l'espace d'etats, la verification de modeles ne pouvait pas encore s'appliquer a des cas d'echelle industrielle. Des techniques ont alors ete inventees pour resoudre ce probleme.
Les deux approches principales utilisees actuellement sont la verification de modeles symbolique (parfois appele implicite) et la verification de modeles explicite. La premiere fait generalement une utilisation de diagrammes de decision binaires (BDD) [7] et peuvent utiliser une methode de satisfiabilite [37]. Le principe est de representer le modele sous forme de formules booleennes (a 1'oppose d'un systeme a transitions etiquetees classique) et de tester les proprietes sur cette grande formule. L'approche est appelee verification de modeles symbolique car le systeme de transitions n'est pas represente sous forme explicite, c'est-a-dire sous forme d'etats avec des successeurs. L'utilisation des BDD est limitee par un probleme difficile d'ordonnancement des variables, et malgre l'existence d'heuristiques, certains estiment que les approches utilisant les BDD ne sont pas encore matures. Les ap-proches explicites utilisent des methodes differentes pour eviter l'explosion combinatoire de l'espace d'etats. Elles passent generalement par des representations intermediaires (au-tomates communicants, reseaux de Petri ou representation en structures C). Celles-ci sont construites de sorte a pouvoir minimiser le graphe representant le modele. Selon les
verifi-1.2. PRESENTATION DE LA VERIFICATION DE MODELES
cateurs de modeles, la verification peut se faire a la volee ou non. Proceder par une methode a la volee permet generalement de consommer moins de memoire et evite de generer un modele au complet avant de proceder a la verification. Par contre, elle est parfois plus lente pour tester un grand nombre de proprietes, car un meme LTS precompile et optimise ne peut alors pas etre utilise pour toutes les proprietes.
1.2.2 Revue de litterature
De nombreuses contributions scientifiques concernant la comparaison de techniques ou de verificateurs de modeles ont deja ete faites. Dans ce memoire, nous nous interessons particulierement a la verification de modeles de systemes d'information.
De maniere generate, les questions de la satisfiabilite des proprietes au cours de raffine-ments successifs [6] ou de l'ajout de fonctionnalites [26] sont traitees dans [31] de maniere synthetique. Huth discute egalement sur le fait de faire de bons compromis pour modeli-ser des modeles plus petits que 1'original, mais toujours verifiables vis-a-vis des proprietes voulues. L'article montre que de tels models sont complexes a calculer dans le cas general. Ainsi, nous ne pourrons probablement pas nous permettre d'utiliser ces techniques a priori. Beaucoup de travaux recents sur le verification de modeles concerne les processus d'af-faires. Dans [3], SPIN/PROMELA et CIA/CSP(LP) sont utilises pour modeliser un processus d'affaires d'agence de voyage de taille moyenne. Des proprietes de surete et des interblo-cages ont ete verifies avec succes avec les deux verificateurs de modeles. Aucune propriete d'accessibilite n'a toutefois ete testee. Les auteurs y proposent un langage qui ajoute a CSP la notion de compensation, c'est-a-dire un comportement que doit adopter le systeme en cas d'echec d'un processus. Dans [39] sont presentees des techniques de traduction depuis le langage de processus d'affaires BPEL [22] via SPIN [22] et UPPAAL [13], mais aussi en passant par les reseaux de Petri [14] ou les algebres de processus, comme CSP [29] et LOTOS. Selon Morimoto, les algebres de processus sont particulierement adaptees a la ve-rification de systemes d'information, dans le cas particulier des processus d'affaires. Nous verrons si cette affirmation pourra etre generalisee a tous les types de systemes d'informa-tion.
Des techniques concernant des branches plus particulieres de la verification de modeles ont egalement ete etudiees. Ainsi dans [47], le sujet precis de la modelisation de
transac-1.2. PRESENTATION DE LA VERIFICATION DE MODELES
tions d'affaires interruptibles est presente et traite a l'aide de statecharts [27]. Cette
me-thode est appliquee a un systeme de bibliotheque similaire a celui que nous avons etudie. L'article ne traite toutefois pas de la verification de proprietes temporelles. En outre, dans [12], une etude est faite sur la modelisation d'applications dans le cas particulier de sites Web. Cette methode de synthese permet selon les auteurs de modeliser certains cas reels de sites de commerce electronique. L'utilisation du langage temporel CTL* permet d'ex-primer tous types de proprietes mais le processus de verification associe est trop complexe. Ces etudes ont l'avantage de faire decouvrir des techniques alternatives aux modelisations usuelles. Elles couvrent toutefois deux sujets particuliers et ne sont pas directement appli-cables au cas general des systemes d'information.
II est propose dans [44] une traduction de diagrammes de collaboration vers LOTOS. L'etude porte sur un systeme de reservation de billets de train de petite taille et ne traite pas de la verification de proprietes. De tels diagrammes sont trop peu expressifs pour etre utilises directement dans le cas general des systemes d'information (ils ne permettent no-tamment pas la modelisation de files). Des elements concernant CADP ont permis d'observer une maniere differente d'utiliser ce verificateur de modeles.
Plusieurs comparaisons de verificateurs de modeles ont egalement ete effectuees au-paravant. Dans [10], une etude compare brievement trois verificateurs de modeles : SPIN, FDR2 et Murcp. L'etude porte sur une tres petite specification (la communication d'un mes-sage entre trois entites) et ne teste qu'en partie les trois proprietes proposees (interblocage et surete). Peu de conclusions sont tirees dans 1'article, mais 1'etude fournit une bonne approche preliminaire des trois verificateurs de modeles.
Dans [4], quatre verificateurs de modeles bases sur les etats (USE, Alloy, ZLive and ProZ) sont compares. Le systeme etudie est un systeme d'aflfectation de cours pour des eleves et des professeurs. C'est un modele dont la taille correspond a notre systeme d'infor-mation de bibliotheque. Les proprietes testees sont des proprietes invariantes uniquement. Or, de nombreuses proprietes de systemes d'information concernent l'enchainement des evenements. C'est pourquoi nous preferons etendre la verification aux proprietes tempo-relles en general.
Enfin, dans [40], les auteurs utilisent respectivement CSP et Z pour la specification du comportement et la gestion des donnees de leurs systemes. Une telle approche, similaire a celle utilisee dans ProB [35], est interessante pour pallier l'antagonisme entre les donnees et
1.2. PRESENTATION DE LA VERIFICATION DE MODELES
le comportement d'un modele. Malheureusement, une limitation actuelle de cette methode est l'impossibilite d'utiliser les variables Z avec CSP. De plus, une intervention humaine est toujours necessaire pour une partie des types de donnees en Z.
Beaucoup de recherches ont ete effectuees sur des sous-ensembles de systemes d'in-formation : generation de sites Web, processus d'affaires, processus interruptibles et dia-grammes de collaboration. Notre etude se distingue de toutes ces publications car nous nous interessons a la verification generate de systemes d'information synthetises dans une approche d'ingenierie dirigee par les modeles.
Chapter 2
Comparaison de deux veriflcateurs de
modeles dans le contexte de la generation
automatique de systemes d' information
Resume
L'ingenierie dirigee par les modeles est de plus en plus utilisee pour synthetiser des systemes d'information, mais elle ne fournit generalement pas de methodes formelles pour verifier les systemes crees. Par consequent, ceux-ci sont suscep-tibles de contenir des erreurs difficiles a localiser. Les methodes formelles, et en particulier la verification de modeles, ont pour but de simplifier cette tache en verifiant que le modele genere verifie les proprietes desirees. Ici, SPIN et CADP sont compares lors de la modelisation d'un systeme de librairie. Le but est de voir si la verification de modeles peut etre adaptee a la verification de systemes dans une approche d'ingenierie dirigee par les modeles.
Commentaires
Ma participation a 1'article concerne toutes les parties qui touchent a CADP, ainsi qu'une partie de 1'introduction et de la conclusion. Cet article n'a pas ete publie, mais vise a etre complete afin de comparer quatre autres veriflcateurs de
mo-deles. II sera ensuite soumis a une revue ou une conference sur les specifications formelles.
Model Checking of Information System Specifications: A
Comparative Study
Romain Chossart
Departement d'informatique, Universite de Sherbrooke, Sherbrooke, Quebec, Canada J1K 2R1
romain.chossartOusherbrooke.ca
Benoit Fraikin
b e n o i t . f r a i k i n @ u s h e r b r o o k e . c a
Marc Frappier
marc.frappier@usherbrooke.ca
Keywords: MDE, model checking, comparison, information system, APIS, SPIN, PROMELA, EB3
Abstract
Model driven engineering is more and more used to synthesize information sys-tems. Since model driven engineering does not provide any formal technique to verify the generated systems, the latter can still contain errors that are difficult to locate and correct. Formal verification methods, and in particular model check-ing, aim at simplifying this task. Here, SPIN and CADP are compared against a library specification in order to see if model checkers can be adapted to the verifi-cation of information systems generated with model driven engineering methods.
2.1. INTRODUCTION
2.1 Introduction
Information systems (IS) now play a prominent role in our society to support business processes and share organisational data. Yet, even if they are one of the early application domains of computing science, their development relies mostly upon a manual and informal process. Over the past years, we have worked on the development of a platform called APIS (Automatic Production of Information Systems) to automate the development of IS [20]. It consists of code generation algorithms to synthesize IS from abstract, formal specification languages.
The problem we are addressing in this paper is the validation of IS specifications, that is, to make sure that a formal IS specification properly models user requirements. There are three main ways of validating a specification: i) inspection and walkthrough with the users, ii) animation (execution) of the specification to explore scenarios, which is similar to testing, and iii) formal verification that the IS specification satisfies some properties, for all possible inputs. In this paper, we are addressing the latter. We distinguish two forms of formal verification: theorem proving and model checking. The main pros and cons of each approach are now well-known. Theorem proving ensures that a property holds for all possible inputs, while model checking can only check a property on a bounded state space, although in some particular cases, the model checking of an unbounded space can be reduced to a bounded state space. Theorem proving typically requires assistance from an expert to guide the proof search process. Model checking is more automatic, but it requires specification tuning to bound and optimize the search space. Theorem proving is convenient for safety properties, but more arduous for liveness properties, while model checking is convenient for both.
Given these general characteristics, model checking appears to be an interesting candi-date for IS specification validation for two main reasons: its more automatic process and its ability to easily deal with both safety and liveness. For the vast majority of IS, it is very unlikely that an organisation will have the financial and human resources to conduct proofs, except maybe for mission critical IS, which constitute a very small number of cases. In this paper, we are targeting these non-mission critical IS. In that context, validation must be straightforward, that is, writing down the properties must be simple and checking them must be automatic.
2.1. INTRODUCTION Requirements Properties writing Creation of the specification EB3 Specification Properties to verify in a property specification languctge Automatic translation O Automatic IS generation Specification in the model specification language Information System Automatic x^ verification process V using model checking ,>.,
Manual step - - •»• Automated step , m MDE process — Added « « M I verification process Validation results Product delivery
Figure 2.1: The overall process of IS generation and validation
This problem is of particular interest in model-driven engineering (MDE) and genera-tive programming. These approaches aim at synthesizing an implementation of a system from models (i.e., specifications). Hence, if the synthesis algorithms are correct, one only needs to validate the models to produce correct systems, APIS is an MDE method dedicated to IS. The aim of this study is to find a model checker that can validate IS models in order to make sure that the automatically generated systems satisfy to the requirements. To do so, several methods are possible. IS MDE specification languages usually do not have any dedicated model checker. Since developing a model checker is a long process and since several model checkers already exist, it is simpler to choose an existing tool that is main-tained by a team specialized in the model checking field. In this paper, two of them will be compared: SPIN [30] and CADP [24].
Figure 2.1 presents the integration of a model checker within MDE, in the particular case of APIS. It shows the MDE process along with the verification. In practice, the decision has been made to verify our models with as little work as possible from the specifier. As we can see on the diagram, compared to the original IS generation, the only manual step added in the process is the expression of properties. This method seems adapted for our purpose.
In order to validate it, the EB3 specification is first translated in a specification in the language of the model checker. Since this step must be automated, it is convenient to have
2.2. RELATED WORK
a language easily translatable from EB3. Hence, the translation and the model equivalence proof will be easier to perform. The other input expected from the model checker is the list of properties to be checked on the model. From the requirements, the specifier has to write a list of properties in the temporal logic of the model checker. Since this step is manual, much care is expected from the writer in order to make sure that the temporal properties correspond exactly to the client's requirements. Hence, another important criteria in our study is the ease to express the requirements in the target temporal language . Also, the
expressiveness of the temporal language is of great importance. Every requirement from
the client has to be properly expressed in order to validate the final product. Otherwise other methods will be necessary to formally validate the parts of the IS corresponding to these requirements. It is worth noting that only functional requirements (as opposed to non-functional requirements like execution time) are of interest in this study. The last step is the model checking itself. The result of the verification determines if the IS satisfies the requirements. Model checking of IS is particularly affected by the state-space explosion problem because IS are data-driven.
This paper is structured as follows. Section 2.2 presents a synthesis of related work on model checking of IS. Section 2.3 presents a description of the case study, a library IS. Sec-tion 2.4 provides an overview of SPIN and CADP, comparing relevant points for both model checkers. Then, the model checking results for the case study are presented in Section 2.5. Finally, remarks about the particular case of the translation from EB3 are presented.
2.2 Related Work
There is an extensive literature on model checking. We concentrate in this section on comparative studies of model checkers related to IS.
In [31], Huth summarizes different model checking techniques for formal systems. Sev-eral problems that make the object of current studies are analysed, among which are the satisfaction of properties during successive refinements of a model [6] or during feature addition [26]. He also discusses on how to create a smaller model but still adapted to the specification, and to choose a good trade-off between the cost of computing such a model automatically and the cost savings obtained from model checking the compressed model. Most of these techniques make a link between the synthesis and the checking of the model.
2.2. RELATED WORK
The paper shows that judiciously fine-tuning a model is not an easy task. It is hence prob-ably not a task we can afford in our work, unless it is completely automated.
Model checking has been extensively applied to business process modelling. In [3], a travel agency business process has been modelled with SPIN/PROMELA and CIA/CSP(LP). Safety properties and deadlocks have been uccessfully verified with both model checkers; reachability properties have not been tested. The authors propose an extension of CSP with notion of "compensation" (a behavior to compensate a process failure). In [39], business processes are converted from BPEL to automata (via SPIN [22] or UPPAAL [13]), but also to Petri nets [14] and CSP [29] and LOTOS. According to Morimoto, process algebras are
suitable for verification of the reliability of IS, in the particular case of business process.
In this paper, we analyse if process algebra (LOTOS-NT) are suitable for verification of a larger class of IS.
Yeung covered suspendible business transactions modelling [47] with statecharts [27] and CSP [29]. The suspendible nature of the process consists in letting objects (i.e. entities) being temporarily or definitively unavailable. The paper proposes a specification method for modelling these particular behaviors. It is applied to a library specification similar to the one we studied. However, the paper did not concern the specification of properties. In [12], the authors study the verification of data-driven applications in the particular case of web-based systems using an ASM-like [45] specification language. The latter is a complete method that has been applied to many real case-studies like e-commerce websites. The study focuses particularly on reachability properties, but any type of property can be used for modelling. Indeed, the tool uses CTL*. It has the drawback of having a verification process much more complex than CTL or LTL. Moreover, the modelling process is very complex and demands much expertise. Both,modelling techniques give an insight on what can be done with these subclasses of IS.
In [44], a translation of collaboration diagrams to LOTOS specifications is proposed and is applied to a train ticket booking system. The translation is very promising but unfor-tunately such diagrams are not adapted to general IS specifications since it is for example impossible to use shared variables with it. Properties verification is not treated in this paper. In [10], a short survey comparing three model checkers (SPIN, FDR2 and Mur0) is made. As the study covered only a simple office message passing specification with three simple properties, only few conclusions can be made. According to the author, Mur0 is
2.3. PRESENTATION OF THE CASE STUDY
not adapted to communicating processes. It does not cover the field in details enough for our research, but it gives interesting preliminary information about the languages and the process of these three tools.
Another comparison has been recently made in [4], comparing four state-based model checkers (USE, Alloy, ZLive and ProZ). The study checks invariant properties on a course assignment system. The paper concludes with a very precise comparison of features. Since IS properties usually rely on the chaining of events, our verification has been extended to temporal properties rather than limiting the properties to invariants. Moreover, our work distinguishes from the paper above as we aim at comparing state-based and event-based model checkers.
Finall in [40], CSP and Z are respectively used to synthesize the behavior and the data parts of systems. However, a constraint holds in this tool: Z variables cannot be used in the CSP part. Moreover, the CSP-Z to CSPm translator implementation still requires manual intervention concerning the data types on the Z side. In our case, it is essential to have access to data in the process expression.
Our work distinguishes from all these preceding studies in the sense that it is completely focused on information systems MDE.
2.3 Presentation of the Case Study
We first present an overview of the library system, and then introduce the requirements which will be used for the formal verification of properties.
2.3.1 Context
In order to avoid any confusion, key concepts are first defined. Lending a book means that a user borrows a book without reserving it beforehand. Taking a book means borrowing a book after having reserved it. Borrowing a book denotes either taking or lending it. In the requirement list, a member is a person who has joined (and still not left) library membership. However, in the remaining of the paper, a member will be known as a user of the library system.
2.3. PRESENTATION OF THE CASE STUDY member memberld: MEMBERID category: String Join Leave reservation Reserve Take Cancel * * currentBorrower * loan Lend Renew Return 0..1 book bookld: BOOKID category: String Acquire Discard
Figure 2.2: Requirement class diagram of the library system
attributes are listed in the upper part of each class, while entity actions are listed in the lower part. The library system only contains two entity types: books and members. Members can Join and then Leave library membership whereas books can be Acquired and then Discarded. Members can Lend, Renew several times and Return a book. They can also Reserve a book under certain conditions (e.g. if it cannot be lent at that moment), and then, either Cancel the reservation or Take the book. Hence the library system contains 10 actions. A complete library specification can be found in [19], where the B and EB3 methods are compared.
The library system seems very simple to model but it contains several subtle issues to deal with, like the conditions for reserving and borrowing a book. For example, the library specifier could have omitted the requirement "one may never reserve a book he is already
reserving", which would have let a member reserve a book several times. The former
statement is a typical safety property to be verified with a model checker and is among the requirements that are going to be presented in the sequel.
2.4. AN OVERVIEW OF THE MODEL CHECKERS
2.3.2 User Requirements of the Library System
The expression of the requirements is the first step of the requirement analysis process and does not depend on the verification method. The objective is to express the needs of the clients into a list of properties written in natural language. These requirements should be as comprehensive as possible because they constrain the behavior of the specification. Moreover, they define a contract between the client and the specifier: the final delivery of the project will be considered valid if and only if the requirements are met. Parts of the requirements are listed in Figure 2.3. For the sake of conciseness, only a representative subset has been chosen.
In the context of IS, we usually distinguish two types of properties. The first one is called a liveness property. It represents the fact that the system is still alive, i.e. not stuck in a deadlock (the system is blocked in a single state) or a livelock (the system loops in a subset of states considered as non-evolving). They can also express the fact that an action implies a reaction from the system; the latter is however rarely used in information systems, where actions are usually human-driven (one cannot force a user to trigger specific actions). The first property in Figure 2.3 is a liveness property: the library has the right to acquire the book (under certain conditions). In other terms, it forces the IS to allow the action. The other properties are called safety properties. They usually describe what behavior the system should not have, or what a user is not allowed to do with the system at a given point. Most items in Figure 2.3 are safety properties, it is for example the case for number 2, 6, 7 and 8. A third type of properties is usually distinguished from these two. These are
fairness properties, but as we cannot force some actors (in our case, the members) to do
any action, only workarounds could be used to implement this notion. However, these are not considered in our study.
Note that since the requirements are also the properties that will be checked for the validation, it is an important stage of the process that must be completed with most care.
2.4 An Overview of the Model Checkers
We consider four large families of model checkers. Explicit state model checkers, like CADP, SPIN and FDR, use an explicit representation of the transition system associated to a
2.4. AN OVERVIEW OF THE MODEL CHECKERS
1. A book can always be acquired by the library when it is not currently acquired. 2. A book cannot be acquired by the library if it is already acquired.
3. An acquired book can be discarded only if it is neither lent nor reserved. 4. A person must be a member of the library in order to borrow a book.
5. A book can be reserved only if it has been borrowed or already reserved by another member.
6. A book cannot be reserved by the member who is borrowing it. 7. A book cannot be reserved by a member who is reserving it. 8. A book cannot be lent to a member if it is reserved.
9. A member cannot renew a loan if the book is reserved.
10. A member is allowed to take a reserved book only if he owns the oldest reservation. 11. A book can be taken only if it is not borrowed.
12. Anyone who has reserved a book can cancel the reservation at anytime before he takes it.
13. A member can relinquish library membership only when all his loans have been returned and all his reservations have either been used or canceled.
14. Ultimately, there is always a procedure that enables a member to leave the library. 15. A member cannot borrow more than the loan limit defined at the system level for all
users.
2.4. AN OVERVIEW OF THE MODEL CHECKERS
model specification. This transition system is either computed prior to property verification, as in CADP and FDR, or on-the-fly while checking a property, as in SPIN (also possible in some cases with CADP and FDR). Symbolic model checkers, like nuSMV, represent the transition system as a Boolean formula. Bounded model checkers, like Alloy, consider traces, of a maximal length k, of the transition system and represent them using a Boolean formula. Constraint satisfaction model checkers, like ProB, uses logic programming to verify formulas. In this paper, we focus on explicit state model checkers, represented by CADP and SPIN.
2.4.1 An Overview of the Verification Process
CADP is a rich and modular toolbox. We focus on a subset of it, illustrated in the verification process of Figure 2.4. We selected the XTL model checker, which takes as input a labelled transition system (LTS) encoded in the BCG (Binary Coded Graph) format. A BCG can be generated for a variety of specification languages, including LOTOS, LOTOS-NT, and FSR We use LOTOS-NT, which is a variant of LOTOS that supports states variables, although with some limitations on their usage. A LOTOS-NT specification is translated into an equivalent LOTOS specification using Lnt2Lotos. A LOTOS specification is translated into a BCG using Caesar. This BCG is minimized into a trace equivalent BCG using bcg_min. Finally, properties written in XTL are checked against this BCG using the XTL model checker, CADP offers a variety of tools for simulation and debugging (simulator, bcg_info, exhibitor and bcg_draw).
Miscellaneous tools : - Simulation {simulator) - Informations (bcgjnfo)
• Regex trace finding {exhibitor)
LOTOS NT specification — • •
LOTOS specification
- Graph drawing {bcg_draw) f ~N
— • BCG Graph — • BCG Graph Minimized
1 Results Lotos NT to Lotos LTS Compilation LTS Minimisation Model-checking
translation caesar bcg_min xtl lnt2lotos
Figure 2.4: CADP general verification process
ap-2.4. AN OVERVIEW OF THE MODEL CHECKERS
proach used for LTL model checking. Specifications are written in Promela and properties in LTL. The LTL property is compiled in a Promela never claim, i.e. a Biichi automaton. The property can also be directly written as a never claim. From the specification and the property, SPIN generates the source code of an on-the-fly verifier. The verifier is written in C language. Once compiled, it checks if the property is satisfy by the model. Working on-the-fly means that SPIN avoids the need to preconstruct a global state graph.
Miscellaneous tools (Spin) - Simulation - Informations
Q
Promela specification Spin Spin ;(ltl2ba) Verifier source code Compilation (GCC) • Model CheckingFigure 2.5: SPIN general verification process
Since SPIN explores the transition system on-the-fly, transitions are (re-)computed for each property to verify. Hence, if there are n properties to verify, a transition is poten-tially computed n times. In CADP, the transition system is computed once, and visited n times. However, the model built by SPIN from the PROMELA specification can be optimized depending the property to verify. When a safety property is checked, the verifier can be compiled with a specific option that optimizes the verification process, providing a better execution time and memory handling. In CADP, the reduction of the model is restricted to given equivalence class reduction and manual gate hiding, where hidden actions have to be explicitly given.
2.4.2 The Specification Languages
LOTOS-NT is inspired from LOTOS. A LOTOS-NT specification is divided in two com-plementary parts: an algebraic specification of the abstract data types and a process expres-sion. LOTOS-NT offers traditional process algebra operators like sequence, choice, loops,
2.4. AN OVERVIEW OF THE MODEL CHECKERS
guard and parallel synchronization. It supports state variables, which are local to a process and cannot be referred by another process. Assignment statements can be freely mixed with other process expression constructs. This is an improvement over pure process algebraic languages like LOTOS, CCS and CSP [29], which do not support state variables. To speed up the evaluation of data expressions for the calculation of the BCG, one can provide a concrete implementation of the abstract data types, written in C. Compared to LOTOS, the loop operator makes trivial the modelling of the Kleene closure, which is widely used in IS specifications. Listing 2.1 illustrates the use of a variable and the loop operator in LOTOS-NT. The use of state variables and the loop construct greatly simplify the specification of IS.
type COLOR is
black , white , pink with eq , ne
end type
process painter[PAINT_IN_WHITE , PAINT_IN_PINK , FADE:ANY]() is var current_color : COLOR in
current_color := black ;
loop L00P_1 in select
break L00P_1 []
PAINT_IN_WHITE ; current_color :- white
[] PAINT_IN_PINK ; c u r r e n t _ c o l o r :- pink end s e l e c t end loop ; FADE ; c u r r e n t _ c o l o r := black end process
Listing 2.1: An example of Kleene closure in LOTOS-NT
PROMELA, the model specification language of SPIN, is inspired from C. Hence, it is an imperative language, with constructs to handle concurrent processes. State variables can be global and accessed by any process. PROMELA offers basic types like char, bit, int and arrays of these types. Processes can communicate by writing and reading over a channel, either synchronously using a channel of length 0, or asynchronously, using a channel of length greater than 0. Operator atomic allows a compound statement to be considered as a
2.4. AN OVERVIEW OF THE MODEL CHECKERS
single atomic transition, except when this compound contains a blocking statement, such as a guard or a blocking write or read over a channel, in which case the execution of the atomic construct can be interrupted and control transferred to another process. Statements can be labeled and these labels can be used in LTL formulas. A state of a PROMELA transition system is determined by the values of state variables, which can be referred to in LTL properties.
PROMELA and LOTOS-NT are two orthogonal specification languages: the former is state oriented, while the latter is event oriented. Both languages are Turing-equivalent.
2.4.3 The Temporal languages
XTL [36], the property specification language of CADP, is used to express temporal logic properties. XTL provides low-level operators which can be used to implement various temporal logics like HML [28], CTL [5], ACTL [11], LTAC, as well as the modal mu-calculus [33]. XTL formulas are evaluated on a BCG. XTL allows one to refer to transi-tions (events) and values of their parameters. It also allows one to refer to the BCG state variables, but unfortunately, since our BCG is generated from LOTOS (which does not use state variables), its states do not contain any of them. Note that LOTOS-NT simulates state variables using pure LOTOS constructs. XTL provides basic types (integer, real,
charac-ter and string) and graph-related types (state, edge, label). No LTL library is currently
provided. In this paper, we use the CTL and HML libraries.
Since our BCG does not contain any state variable, the difficult part in writing XTL properties for LOTOS-NT models is to characterize states. Indeed, the specifier can only use action labels to define particular states. The HML library, with its two handy operators
Dia and Box, are used for this purpose. Box(a, p) holds in a given state if and only if
every action matching action pattern a leads to a state matching state pattern p. On the other hand, Dia(a, p) holds for a given state if and only if there exists at least one action matching action pattern a leading to a state matching state pattern p. An XTL formula holds for a BCG if and only if it holds for all states of the BCG.
SPIN uses propositional LTL [41], with its traditional operators always, eventually and
until. The latter is sometimes referred as the "strong until" operator, as opposed to the
2.4. AN OVERVIEW OF THE MODEL CHECKERS
can be used during the model checking. An LTL formula can refer to labels and state variable values of a PROMELA specification. SPIN only considers states; there is no notion of event on a transition. An LTL formula holds for a PROMELA specification if and only if it holds for every possible run of the PROMELA model. A run is an execution trace consisting of the sequence of states visited during execution. It can be infinite.
LTL and CTL are complementary languages. The semantics of LTL formulas is defined on traces of the transition system, while the semantics of CTL formulas is defined on the transition system itself, which allows one to refer to the branching structure of the execu-tion. Some properties can only be expressed in either LTL or CTL. For instance, a reset property, which states that it is always possible to go back to some desired state, cannot be expressed in LTL, since this transition to reset doesn't have to occur in each possible run of the system. Since an LTL formula holds if and only if it holds for every possible run of the system, an LTL property would force this reset transition to occur in every run. Dually, a property of the form "eventually p always holds" cannot be expressed in CTL [34, 17], due to the branching nature of the logic.
The complexity of deciding if a formula (in CTL and LTL) holds in a transition system
M is linear in the size of M (number of states and number of transitions) in each case. It
is also respectively linear in the size of the CTL formula and exponential in the size of the LTL formula. However, the latter is usually not an issue since Biichi automata generated from LTL formulas are typically small (usually less than 10 states) in practice, compared to the size of the transition system M.
2.4.4 Simulators and Validations Tools
CADP provides several valuable tools to validate the model. Basic tools like manual simu-lation and graph drawing are provided. More advanced tools like graph layout editing or gate hiding help in providing a human-readable global view of the model. One can also test for specific sequences of actions using regular expressions1. These are easy to create and very useful for specification testing, CADP can generate various kinds of graphs2, such as chaos automata or FIFO buffers. Several other tools are also available to achieve advanced
'exhibitor - http://www.inrialpes.fr/vasy/cadp/man/exhibitor.htrnl
2.5. ANALYSIS OF THE C A S E STUDY
tasks like simulation of continuous-time Markov chains3 or generation of conformance test suites4 although they have not been used in this study.
SPIN provides classical model checking features, namely, two kinds of simulators to explore the specification model manually or randomly. Also, a failed checking produces a trail (i.e. trace) that can be used to reproduce and locate the error with the simulator.
2.5 Analysis of the Case Study
In this section, we analyse the library system using CADP and SPIN. We present the results of the analysis and compare the effectiveness of each approach. To the best of our knowledge, the two specifications (in LOTOS-NT and PROMELA) describe the same behavior. However, we have not formally proved this equivalence, since this would be a non-trivial task. More-over, since we are targeting an automatic translation between EB3 and these languages, we have used a generic specification style which could potentially be obtained from an auto-matic translation from EB3. Hence, each specification may not be the most optimized one in terms of model checking, but we believe they are not too far. On the other hand, it is unrealistic to expect IS engineers to manually build an optimized IS specification in either PROMELA or LOTOS-NT languages. These languages are not designed to write simple and readable IS specifications.
2.5.1 The Specification Writing
The LOTOS-NT specification of the library system is largely inspired from the EB3 spec-ification of [19]. Since both EB3 and LOTOS-NT are process algebra, the translation of the EB3 process expression is quite straightforward: each EB3 process algebra operator can be easily represented by a corresponding LOTOS-NT operator. However, the handling of state variables is very different. The LOTOS-NT specification is shown on Listing 3.4, Listing 3.5, Listing 3.6 and Listing 3.7.
LOTOS-NT lacks a few syntactic sugars which would streamline the specification of IS. For instance, to model n instances of a book entity, it seems pretty natural to put n
3cunctator - http://www.inrialpes.fr/vasy/cadp/man/cunctator.html 4TGV - http://www.inrialpes.fr/vasy/cadp/man/tgv.html
2.5. ANALYSIS OF THE CASE STUDY
copies of a book process in interleave, something that could be concisely expressible as |||x : \..n : book(x). Since the size of the associated transition system is exponential in
n, n must often be changed during verification experiments. Unfortunately LOTOS-NT
does not provide such a "quantified" version of an interleave operator. This means that one has to hardcode book{\) \\\ ... \\\ book(ri). When k entities are associated in the class diagram, each with its own number of instance n,-, then the number of interleaves to hard code in the specification text grows exponentially in k, making verification experiments a bit cumbersome.
Another issue with IS specifications is the specification of entity attributes. Recall that LOTOS-NT supports state variables, but they cannot be shared between processes. Since each instance i of an entity e is naturally represented by a corresponding process e(i), the attributes of this instance are easily represented by variables in process e(i); however, these attributes cannot be used in process e(j), with i £ j . If an action a{i, j) requires a guard that involves attribute values of e{i) and e{j), this becomes very tricky to specify, since action a cannot be handled in either e(i) or e(j). Luckily, this pattern does not occur in the library case study, but it is not uncommon in IS specification.
Our LOTOS-NT specification of the library system is modularly structured using a pat-tern of the form "nominal/controller", an example of which is given in Listing 3.7. The process of an entity is split in two complementary parts. The first one, named the nominal part, represents the basic behavior of the entity and does not have any state-variable depen-dant restriction. The second one is named the controller and is partly shown in Listing 2.2. The controller process loops on a choice of every action of the nominal part. It contains all the needed state variables and its actions can be guarded and are possibly followed by the update of some variables. The nominal processes and the controller process are syn-chronized on every action, enforcing the evaluation of guards and state variable updates for each entity action. Since the variables are not shared between processes, there is no need for any mutual exclusion construct. Some functions have also been created to manage the reservation queue of the books.
We have considered two styles for the SPIN specification. In the first style, there is only one process which loops over a choice between all actions. It was quickly abandoned, because it blows quite rapidly in terms of number of states. In the second style, there is one process for each instance of each entity and each association. The process describes
2.5. ANALYSIS OF THE CASE STUDY
process bookController
[ACQ, DISC, LEND, TAKE, RENEW, RET, RESERVE, CANCEL:ANY](bid: BOOK_ID) is var is_borrowed: BOOL, reservers_num: NAT, temp_member: MEMBER_ID, current_borrower: MEMBER_ID in res_queue := NIL; is_borrowed := false; reservers_num :- 0; current_borrower := mnil; loop L00P_1 in select ACQ ( Ibid ) [] DISC ( Ibid ) []
LEND ( Ibid, ?current_borrower) where ((reservers_num eq Q) ) ;
is_borrowed :- true
[]
RENEW ( Ibid, ?ANY MEMBER_ID ) where (reservers_num eq 8) []
RET ( Ibid, ?ANY MEMBER.ID ) ; is_borrowed := false
[]
RESERVE ( Ibid, ?temp_member )
where ( (is_borrowed and (temp_member ne current_borrower)) or (not (is_borrowed) and (reservers_num gt 8)) ) ;
reservers_num : = reservers_nura + 1 ;
res_queue := ml_add_reserver(temp_member, res_queue) [ ... ]
end select end loop end var end process
Listing 2.2: The controller part of the Book process. Functions beginning with "ml_" are functions on the book's reservation list (a list of members)
2.5. ANALYSIS OF THE CASE STUDY
the entity (or the association) life cycle. Therefore, the PROMELA specification contains four process definitions, one for each entity (book and member) and one for each association (loan and reservation). Each process definition is instantiated «, times to model n, instances of entity i, and n, * n7 times to model an association between entity i and j .
In [21], Frappier and St-Denis provide useful EB3 patterns to describe entity or associ-ation life cycles. The SPIN specification is partially inspired by this work. The producer-modifier-consumer pattern is the basis of a life cycle for an entity and an association. It can be represented by the following regular expression P.M*.C where P is the producer (e.g. Acquire), M is a modifier and C is a consumer (e.g. Discard). The concatenation operator "." of regular expressions can be represented by a semi-colon ";", the sequential composition operator of PROMELA, or an arrow "->" that denotes the same operator. Some events have a precondition which is not represented in the regular expression. For exam-ple, a book cannot be discarded if it is still borrowed. Consequently the execution of an event is guarded by a precondition. The precondition of a producer is typically true. The precondition of a consumer usually deals with association event ordering constraints. The postcondition updates state variables. When the execution of a producer enables again the execution of the producer, the consumer postcondition ends with a goto statement to a la-bel of the producer. Example of preconditions and postconditions for books and members are provided in Listing 3.12. The processes representing members and books are provided respectively in Listing 3.17 and Listing 3.18. The execution of an event is denoted by a sin-gle print statement, to simplify execution analysis. The atomic construct ensures that the evaluation of the precondition and the execution of the postcondition form a single transi-tion. Associations loan and reservation are represented in a similar manner in Listing 3.19 and Listing 3.20
When a member takes a book he has reserved, two associations are modified: the loan association and the reservation association. This leads us to ensure that both process ex-ecute the take event in an atomic step. It is not obvious and straighforward. To achieve the atomic step, the take event is split into two events: one in the reservation association process (as a consumer) and one in the loan reservation (as a producer). A channel with an empty capacity is used to ensure the handshake. This is a classic strategy in PROMELA. Nev-ertheless, the handshake cannot be made within an atomic instruction. This could break the local atomicity in the sender. However, it could be used at the end of an atomic and at
