Methodologies and technologies for industrial strength systems engineering

The MATISSE Methodological Handbook is intended to be a convenient reference on systems construction and management methods using the formal constructive approach proposed in the MATISSE Project, through proved refinements. Methods, tools and aids for the management of system development projects based on the formal approach proposed in the MATISSE project are presented here. Although not initially planed in the original project proposal, it was decided to deliver three storyboards threads for the MATISSE Methodological Handbook. This document is therefore composed of three parts: the board level storyboard, project manager's storyboard, and practitioner's storyboard of the Handbook. The recommendations are based on analysis and experiences of the three industrial case studies developed as part of the MATISSE project: - Automatic transportation system - Multi-application smartcard embedded byte-code verifier - Health care control system The document is composed of the above three level storyboards. Each level addresses different audiences and therefore has been written in order to be read independently if required. Nevertheless the three storyboards are composing a unique handbook, which is intended to be yet improved after external review and further internal comments. -Project site: http://www.matisse.qinetiq.com/summary.htm - Future site will be permanently accessible at http://eriscs.esil.univmed.fr/dotclear/public/PAPERS/Matisse_Handbook.pdf

In the MATISSE project a specific tool together with a software development methodology is produced, namely B4Corba, in order for CORBA oriented application to be developed using Atelier B tool and therefore to allow automatic generation of their source code. The B4Corba tool purpose is for the generation of the IDL interfaces (see for instance A. Pope. The CORBA Reference Guide: Understanding the Common Object Request Broker Architecture. Addison-Wesley. 1997). The generation of the code for the clients and the servers, according to the CORBA standard architecture, will be produced by the Atelier B tool using standard code generator embellished with pragmatic clauses to deal with the IDL. The IDL interface definition is independent of programming language, but maps to all of the popular programming languages via OMG standards: OMG has standardized mappings from IDL to C, C++, Java, Cobol, Smalltalk, Ada, Lisp, Python, and IDLscript, etc. This separation of interface from implementation, enabled by OMG IDL, is the essence of CORBA - how it enables interoperability, with all of the transparencies required. The interface to each object is defined very strictly. In contrast, the implementation of an object is hidden from the rest of the system behind a boundary that the client may not cross. Clients access objects only through their advertised interface, invoking only those operations that the object exposes through its IDL interface, with only those parameters (input and output) that are included in the invocation. First of all, the B4Corba tool has to generate automatically the IDL interface from a B abstract machine. It must then distinguish exposed from hidden operations and all the data types involved in the signature of the exposed operations. Our solution is to split the object's abstract machine into two B machines, one containing all exposed operations and data types and the other, all hidden operations and remaining data types. For those two machines to behave correctly, it is sufficient that the exposed machine sees the hidden machine (in the B Method view). The client machine has no special behaviour except that it must see the exposed machine in order to invoke transparently the CORBA exposed operations. In other words, the B4Corba Translator provides a way to transparently connect through an ORB the software components generated by Atelier B. Hence, the generated code remains unmodified and so are the stubs and skeletons that we build by compiling the IDL interfaces.

The extensions of Atelier B are intended to offer: - A support for event driven B, allow using the B language and method for system level modelling. This support is provided by the evt2b tool, which has to be used as an extension of current Atelier B tool. - An improved way to conduct interactive proof and to reduce related workload. This new human-machine interface is available as a xemacs extension.

The healthcare case study is a Fillwell microplate liquid handling workstation that provides features for preparing samples. The system belongs to the class of products for drug discovery and bioresearch. The Fillwell base unit consists of a dispense head dispensing liquid into microplates on a processing table. A gantry moves the dispense head with high precision and speed over the table. The formal specification of the instrument was conducted by the team at Aabo Akademi University, while Wallac developed the instrument informally. A Robot analyser has been developed as a mirror case study to the Fillwell workstation due to the confidential status of the latter in the first year of the MATISSE-project. The Robot analyser analyses samples on a plate that is placed on a movable operating table. In the healthcare case study UML is used as a graphical interface. The functionality and corresponding safety properties of the system are added stepwise. Each step is expressed with UML diagrams, translated to B action systems and proved using the provers of AtelierB. The methodology enables tracing of the requirements of the system all the way to the implementation. UML-diagrams, proved B machines as well as other documentation has been generated for both the Fillwell workstation and the Robot analyser.

The smart card case study is a byte code verifier for Java Card. The verifier is a critical component of the next-generation of smart card systems. With a verifier, there is no need for a cumbersome deployment infrastructure: the card can download new applications in complete autonomy. Each smart card provider now has the possibility to control itself without any external certification authority the validity of the application to be downloaded. The main innovation is in the development process of this security feature. The reliability improvement has not been balanced by a cost increase. This could be applied to any small object with space constraint using a Java Virtual Machine. We have obtained the first prototype of an on card byte code verifier embedded into a smart card.

The transportation case study results provided a methodology to formally develop and validate a large system, using B method and the AtelierB tool. The railway system has been then formally decomposed into subsystem, each of them has been refined, and B software was formally developed for one of these subsystems.

The U2B translator converts UML Class diagrams, including attached state charts, into the B notation. The aim is to use some of the features of UML diagrams to make the process of writing formal specifications easier, or at least more approachable to average programmers. The translation to B relies on precise expression of additional behavioural constraints in the specification of class diagram components and in state charts attached to the classes. These constraints are described in an adapted form of the B 'abstract machine notation'. The resulting UML model is a precise formal specification but in a form which is more friendly to average programmers, especially if they use the same UML notation for their program design work. The UML models may be constructed using a standard UML tool such as Rational Rose or Poseidon. In order to achieve a successful translation to B, restrictions must be placed on the UML models that can be translated and in some cases UML features are assigned particular meanings. These are defined in a UML profile, called BUML that embodies these restrictions and semantics. A UML profile is a specialisation of the UML, which may include the following: -Restriction of the UML notation to a subset. -Imposition of syntactical rules that restrict the models that can be created. -Definition of specialisations using the extension mechanisms of UML (e.g. stereotyping). -Definition of a particular semantics. BUML is a class of models. It is a specialisation of the class of models that use the UML notation. It also inherits from the class of models that use the B notation. The U2B translator reads a BUML model and creates a B model.

Deliverables

Share this page

Download