International audienceThis paper reports about our experience with building a simple tool to assist us in the verification of CSP||B specifications. We present the Control Loop Invariant technique to check the consistency of a CSP||B specification. From this, we deduce the requirements of an assistant tool. The tool was developed in Ocaml. We discuss several issues observed during the development

Jacquot, Jean-Pierre

Nguyen, Huu Nghia

HAL Descartes

A tool for checking CSP||B specifications

Hal-Diderot

INRIA a CCSD electronic archive server

HAL Id: inria-00463422https://hal.inria.fr/inria-00463422Submitted on 12 Mar 2010HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.A tool for checking CSP||B specificationsHuu Nghia Nguyen, Jean-Pierre JacquotTo cite this version:Huu Nghia Nguyen, Jean-Pierre Jacquot. A tool for checking CSP||B specifications. Workshop onTool Building in Formal Methods - Held in conjunction with the 2nd International ABZ Conference,Feb 2010, Orford (Québec), Canada. ￿inria-00463422￿A tool for checking CSP||B specifications ⋆Huu Nghia Nguyen, Jean-Pierre JacquotLORIA – Nancy UniversitéCampus Scientifique, BP 239,F-54506, Vandœuvre lès Nancy, France{firstname.lastname}@loria.fr1 IntroductionThis paper reports about our experience with building a simple tool to assist us in theverification of CSP||B specifications.Our primary research goal is methodological: we aim at understanding and mod-eling how people develop formal specifications. Thus, a language and its supportingenvironment is simply a tool that specifiers use for a specific purpose. Tools are alwaysdesigned as a trade-off between range of applicability and efficiency. The most efficienttools often have a narrow purpose. Like carpenters or plumbers, specifiers must carryheavy toolboxes rather than a single do-it-all tool.An important difference between the tools used for hardware and for software isthat, in the latter case, they have very strong and subtle interactions. Actually, theymust often be used together at the same time. One specification may require the useof B for managing some complex data structure, of CSP for maintaining some livenessproperties, and of UML for validation by the stakeholders. “Gluing tools” are needed.In a recent specification, in a context of multi agents system, we used CSP||B tomodel the bevahiors of agents and their communications. While most of the work couldbe done within language specific tools (FDR21 for the CSP part and AtelierB2 for Bpart), the verification of the coherence between B and CSP prompted us to design andimplement a small assistant. We had at least three reasons:– Practical use of formal methods entails a bit of intelligent work and a huge amountof boring stuff which requires an attention to all details. Computers, with the propertools, are good at the second type of work while we human are bad at it; of course,the opposite is true for the first type of work.– The issue of the coherence proofs between CSP and B is quite subtle and needs aprecise understanding. Working on an implementation is a good way to make thefundamental questions pop out.– We believe that even incomplete tools can be useful: they can leave out some of theintelligent part so long as they take care of all the tedious part. Prototyping is thebest way to discover whether there is a real gain.⋆ This work is supported by project TACOS ANR-06-SETI-017 and by project CRISTAL1 http://www.fsel.com/2 http://www.clearsy.com2 Huu Nghia Nguyen, Jean-Pierre Jacquot2 Requirements for the tool2.1 CSP||B and verificationCSP||B is a multi-formalisms specification technique developed in the last 10 years. Itfocuses on the modeling of component-based systems. A component is an entity whichmanages some internal state and which communicates with other components. B is usedto describe the state management part of the component. CSP is used to describe thecommunication part of the system.A component is modeled by two texts: a B machine and a CSP controler. To eachoperation of the B machine is associated a “machine channel” in the CSP controler. Thesemantics is that when a process synchronizes on a machine channel, this correspondsto a “ call” of the machine operation.The theory of the verification of a CSP||B specification has been developed in [1].It is based on a process with three independent steps:– the B machines are verified by the usual B technology: generation of proof obliga-tions and proofs with B provers,– the CSP controlers are verified by standard CSP techniques to assess the absenceof deadlocks or divergences,– the protocol constraints expressed in CSP processes guarantee that the preconditionof an operation holds when it is called through a machine channel synchronization.This last step is a consequence of two implicit assumptions in the preceding steps: Bmachine invariants are maintained only if operations are called when their preconditionholds and CSP synchronizations always happen when they are possible, which is alwaysthe case for “calling” a machine operation through a machine channel synchronization.Hence, CSP||B mandates that operations in machines are coded with preconditionsinstead of guards since the B semantics states that the former are always executable butmay lead to any result if the preconditions do not hold.2.2 Expected functions[1] proposes a verification technique where CSP controlers are translated into B ma-chines. The calling order imposed by the protocol is modeled by a counter. The transla-tion involves two kinds of works. The first is the application of a set of transformationrules, it is the easy but tedious part. The second is the introduction of a Control LoopInvariant (CLI), which is the intelligent part. CLI is such thatCLI = (cb = 1 =⇒ PRE(op1))∧ . . .∧ (cb = n =⇒ PRE(opn))where PRE(opi) is the precondition of the operation called when cb = i. CLI can besimplified by removing some conjuncts after analysis of the structure of the operations.The first and most important requirement is to apply the transformation rules andgenerate files that can be used by AtelierB. The second requirement is to assist specifierswith invention of the CLI. Several strategies have been studied, from making CLI aparameter of the translation program to generating it. We ended up with the idea togenerate the form of the CLI needed by the specification.A tool for checking CSP||B specifications 33 Realization3.1 Architecture and designWe see our tool as a protoytpe and, thus, followed a process based on short and fastcycles. Architecture and design are, in a sense, results of the development.An important decision was the structure of the output of the translation. For eachCSP controler it consists of two controler machines: an abstract machine which intro-duces the counter and a refinement which introduces the calls to the operations of thecontroled B machine. When needed, CLI are introduced in the refinements.The current translation process is a sequence of six semantic steps which follow theparsing of the files containing the CSP controler and the B machine:1. generation of the abstract machine, as a text file,2. removal of non pertinent variables. CSP syntax requires to introduce names whenvalues are passed through a channel. With respect to the verification of coherencebetween B and CSP, only the names associated with machine channel are pertinentand must be translated, all others can be safely ignored,3. removing name conflict. A pertinent variable can lead to a conflict on three cases:it is one letter long, it is identical to a keyword of B, it is identical to an existing Bvariable visible through the include clause,4. type inference. B, contrary to CSP, requires all variables to be typed,5. computation of the CLI form,6. generation of the refinement, as a text file.3.2 Implementation and testAs an implementation language, we used OCaml3. Three reasons motivated this choice:OCaml is a powerful language for symbolic manipulations, it has strong parsing li-braries, and the project Brillant4 provides us with several tools, notably a B parser.The implementation consists in two packages: one for B analysis, around the Bril-lant parser, and one for CSP analysis. A parser for CSP, accepting the syntax used byFDR2, has been implemented.The tool needs two input files: C.mch and C.csp which contain the texts for the Bpart and the CSP controler. Included files in CSP texts are read when needed.A required CLI is indicated by a comment containing the skeleton of the invariant.The program has been tested on three published specifications [2,3,4]. It was usedto verify the extension of [4] which motivated this development.4 ObservationsPicking OCaml for developing the tool has been an excellent choice. Beside the Brillantlibrary, the major advantage is the clarity of the code. Ideas could be implemented very3 http://caml.inria.fr4 https://gna.org/projects/brillant4 Huu Nghia Nguyen, Jean-Pierre Jacquotquickly and the intuitive correctness of the algorithms is easy to assess. In the threemonths of programming, we were able to test several translation strategies.Starting without a firm design is another advantage of fast programming. In fact, we“discovered” the technical problems (typing, name clashes, etc.) as we progressed andprocessed new exemples. Of course, production tools must use much more structureddevelopment processes. However, such processes rely on that, from the outset, the shapeof the solution is well known. Our work only aims at drawing the shape!A problem that we encountered is the paucity of exemples of specifications. Thislimited the territory which our exploratory approach could chart. While we have a rea-sonable confidence in the correctness of our prototype, we do not know how manydifficulties, either technical or theoretical, remain to discover. For instance, we knowthat the generated CLI is pessimistic when operations contain a conditional substitu-tion. Which other traits of the languages could cause a similar phenomenon should bestudied. A library of exemples would be a real bonus here.Another problem is the communication between the tools which should enter thetoolbox of a specifier. In our case, we used the minimum common denominator: textfiles. Inefficiency is not only technical, repeatedly parsing files, it is also conceptual.Parsers are complicated to build and to use, and thus consumme a lot of developer’stime, yet the interesting points are elsewhere. The problems cited above could be bettersolved if we had libraries with “semantic” functions such as the set of variables modifiedby an operation, or read only, etc. Such libraries are much needed.5 ConclusionA question remains about the potential utility of a tool such as ours: do we need it inthe toolbox? Should we invest in the development of a “certified” and stronger version,knowing that it does an incomplete job? We think so. Even for a formal developer,not all tools need be fully formal and complete. Time is short, boring tasks lead toerrors. For the practical developer, there is room in the box for tools which take care ofmundaneness and leave out the smart bits.Our prototype is available to brave users through the Brillant project.References1. Treharne, H.: Combining Control Executives and Software Specifications. PhD thesis, Uni-versity of London (2000)2. Schneider, S., Treharne, H.: Communicating B machines. In Bert, D., Bowen, J.P., Hen-son, M.C., Robinson, K., eds.: Formal specification and development in Z and B (ZB 2002).Volume 2272 of LNCS., Springer Verlag (2002) 416–4353. Treharne, H.E., Schneider, S.A., Bramble, M.: Combining specification with composition. In:ZB2003: International Conference of Z and B Users. Volume 2651 of LNCS., Springer (2003)4. Colin, S., Lanoix, A., Kouchnarenko, O., Souquières, J.: Towards validating a platoon ofcristal vehicles using CSP‖B. In Springer, ed.: 12th International Conference on AlgebraicMethodology and Software Technology (AMAST 2008), France (2008-07) 6 pages

https://hal.inria.fr/inria-00463422/document

A tool for checking CSP||B specifications

Abstract

Similar works

Full text

Available Versions

HAL Descartes

Hal-Diderot

INRIA a CCSD electronic archive server