Accepted paper in Integrated Design and Process Technology conference, IDPT-2003 Conference cancelled due to the SARS virus, June, 2003
The B method and the component-based approach Dorian Petit1 , Vincent Poirriez1 , Georges Mariano2 ´ Universite´ de Valenciennes et du Hainaut Cambresis LAMIH/ROI F-59313 Valenciennes Cedex 9, France [dorian.petit,vincent.poirriez]@univ-valenciennes.fr ´ Institut National de REcherche sur les Transport et leur Securi e´ ESTAS, ´ ee ´ Reclus 20, rue Elis F-59650 VILLENEUVE D’ASCQ - France,
[email protected] 1
2
ABSTRACT: The aim of this paper is to merge two approaches of software development: the component approach and the formal development approach. Developping software components is now a technique widely used by the software industry. These two approaches are not so distant if we consider Bertrand Meyer’s opinion: it is more complicated to reuse a component without contracts. One of the difficulties with the design by contract approach is to find the contracts. This difficulty can be removed by the use of the B method. In the B method, the software properties (the contracts) are expressed in the specifications. We present in this paper an approach to generate code in the spirit of the component approach from B specifications. I. I NTRODUCTION The component-based approach is now widely used in software engineering. A difficulty in the development of software component is the production of trusted component. These difficulties are exposed by the trusted components initiative [Meyer et al., 1998]. They propose some technologies for building components that you can trust. In this paper we will present a technique to build components using a formal method, the B one. The benefits of using formal methods have already been discussed in the literature (see [Hinchey and Bowen, 1995] and [Hall, 1990] for example). But the application domains of formal method are restricted to domains where development costs are not the main preoccupation – when human lifes are concerned in transportation or nuclear domain or in financial domain where money can be lost. The B method is a formal method that was used in industrial contexts: [Behm et al., 1999], [Sabatier and Lartigue, 1999] and [Lanet, 1998] for example. Our work aims to provide a code generator that can enlarge the target languages of the B method that are reduced to C, C++ and Ada in the current industrial tools. In formal methods, not considering only the B method,
the notion of components seems natural considering the recommendations (commandments) of Bowen and Hinchey in [?]. The second commandment: “Thou shalt formalize but not over-formalize” expresses that it is “both unnecessary and costly” to apply formal methods to all parts of a system. The authors also speak about the “components of the system that will benefit from a formal treatment” . So we have investigated the way of producing components from B specifications. Another recommendation (the ninth commandment) in [?] is: “Thou shalt test, test, and test again”. Even if a formal method is used to develop all the system, it is necessary to test. An approach in software development is the “design by contract”. This approach is based on adding assertions in the software. In his book Object-Oriented Software Construction ([Meyer, 1997]), Bertrand Meyer mentions that an assertion expresses what the software should do and the code how it does. This approach is a step towards formal development. Assertions are a valuable contribution to the quality of the software because: they help in the production of more correct and more robust software they help to document the code they help to test the code they serve as the basis for exception handling The main goal of components is to reuse them. A conclusion of [J´ez´equel and Meyer, 1997] -article on the lessons of the Ariane 5 crash- is that “reuse without a precise specification mechanism is a disastrous risk”. B. Meyer recommends to use the design by contract approach to avoid such problems. To summarize, the approaches -component-based development and design by contract- are complementary. The formal approach is not so distant because in specifications, you have to express the properties of the system you want to develop. The B method is not currently adapted to mix the three approaches. The aim of the present work is to develop
2
an experiment to merge these three approaches to generate trusted components with their contracts from B specifications. A preliminary version of this work was presented in the component based workshop ([Petit et al., 2002b]). To illustrate what we propose, we use a toy example (but not without interest): the bounded stack. A bounded stack is a stack with a limited number of items. The article is organised as follows. We begin with the definition of the term component we consider in section II. In section III, we briefly present the B method and the algorithm we use to transform the B specifications into a format allowing us to generate the code (section IV). In section V, we discuss the advantage of the mixing on the B development process. II. C OMPONENTS
AND THEIR CONTRACTS
What is a software component ? There seems to be no widely accepted definition, and one can found zillions of meanings for these two words. Here is addressed the clientoriented software meaning. In other words, a component is a piece of software intended to be used by other softwares, the clients. The component’s authors have no relations with the client’s authors who just use what they found on their shelves. In a more detailed programming description, software components are defined in [Crnkovic and Larsson, 2002] as:
III. T HE B METHOD B ([Abrial, 1996]) is a formal development method used in the industry to product software for safety-critical systems. This method covers the entire development process: from abstract specifications to implementations. This is the first advantage of the method. Another advantage is that the Set theory is used to express the software. This theory is well known and easier to use than other higher theory. A. Refinement in B One of the mechanisms used in B is the refinement. It is used to transform step by step an abstract specification into a concrete representation (see Figure 1). The refinement process is also used to bring in the specifications all the properties that are expressed in the informal specification (see [Dehbonei and Mejia, 1995] or [Behm et al., 1999] for details on the specification of the METEOR system). At each refinement step, you have to prove that the refinement is correct with its abstraction.
A set of interfaces provided, or required from, the environment An executable code, which can be coupled to the code of other components via interfaces
At this point, arises a major aspect of this client-oriented software: can the client’s authors put their confidence in the components they find on their shelves? How is described the specification of what should do this piece of software? The CORBA or COM Interfacing Description Language (IDL) are a way to provide this specification.The main parts of these interfaces describe type informations for the inputs and the outputs of the component. The design by contract approach proposed by B.Meyer in [Meyer, 1997] is a way to ensure trust in the components. Roughly, it consists in plugin some assertions describing the logical properties (as pre and post-conditions and invariants) in the interfaces. For example, this allows to include the component in tests and thus to improve the confidence in “it does what it announces it does”. The client’s authors are then required to use the component in such a way that the pre-conditions are fulfilled. While originally proposed in Eiffel, this design by contract approach is know available in other programming languages (e.g. C, Java, Caml,. . . ). Some recent studies are done to try to extract contracts of components whose authors did not provide any ([Arnout, 2002]).
Fig. 1. Development by refinement steps
This concrete representation, called implementation in the B terminology, can be translated into a programming language (currently C, C++ and Ada). The concrete specifications use a language called B0. This language is made with basic imperative constructs and without nondeterminism that you can use in more abstract specifications. To give a simple example of what a refinement is, Figure 2 presents a specification of the push operation of the bounded stack. push(addval) = PRE stack top stack size addval THEN stack top := stack top + 1 the stack(stack top + 1) := addval END;
class stack : int object val is empty : unit int unit val push : int val pop : unit unit val top : unit int end
> > >
>
Fig. 7. Interface of the bounded stack
V. I MPACT A. Impact on the B development process To explain the impact the present approach can have, one should remind some basis of the B development process. The B development consists in translating the informal specifications into formal abstract ones. Then, these specifications are refined and decomposed. The UML activity diagram in Figure 8 illustrates the development process. This activity diagram is divided in three swimlanes: the middle one (called specification) represents the specification activity. This activity is the transformation of the requirements into the B specifications and the development of them (by refinement steps). The right swimlane (called validation) is devoted to the validation of the specification. This activity concerns the work required to prove that the specifications are correct (in the B method meaning -see the BBook [Abrial, 1996]). In few words, this step aims to prove that the refinement steps are correct w.r.t. the abstract model. The left swimlane (called verification) is devoted to the additions we make in the development process. At the beginning the specification team writes the specifications and develops them. The validation team waits for the specifications and then they can start the formal validation. It generates the proof obligations and discharges them if possible. If all the proof obligations are discharged, and if all the specifications are validated then it is the end of the validation process and the code can be generated. If there remain some specifications to be validated, the validation
5
process restarts. It is possible that some proof obligations can not be discharged. That is due to mistakes in the specifications. The specification team should work again the specifications (a part of them) to solve the problem. And then, the validation process restarts (not all the validation process, only on the modified specifications). During a B development, this validation part is the longest one. Even if the toolkits (the B toolkit from B-Core1 or the Atelier B from ClearSy 2 ) can discharged automatically about 80-90 percents of the proof obligations, there are some lemmas that should be proved interactively. You can see [Behm et al., 1999] for more metrics on the use of the Atelier B for the METEOR development. The preservation of the logical properties in the generated code can be included in the classical B development process without disturbing it. Moreover, this can help the validation step. The presence of assertions in the generated code can be used to run tests and eventually prove that some of them are false, which denotes some problems of the specification. This way may be easier than a manual proof of the inconsistence of some assertions. Classical validation techniques to test the generated (and annotated) code are usable as tools based on approaches like: [Leino, 2001], [Cheon and Leavens, 2002] or [Evans and Larochelle, 2002]. This approach follows the same way as J. Rushby in [Rushby, 2000]: “Disappearing Formal Methods” or the fifth commandment of [?] “Thou shalt not abandon thy traditional development methods”. The software industry has developed and used mechanisms to validate/test their software. It will be unpopular and prejudicial to totally forget their knowledges, especially if our solution is (or seems to be) more difficult. B. Impact on the integration of the generated code The component softwares developed usually with the B method are not always the whole part of the software. They often have to be integrated with pieces of software developed with different methods. While the B produced components are trustable, due to the B methodology, they do not bring with them their specifications. Let illustrate with the dictionary example, a dictionary is a table of elements identified by a string used as a key. Assume that the two tasks of the component dictionary is to insert a certain element x, given its key, in a dictionary of bounded capacity and to retrieve the information associated with a certain key. Their is no way in the classical B methodology to document the produced code to precise that the key associated to the element to insert should not be empty. However, this specification was present at some points of 1 http://www.b-core.com/btoolkit.html 2 http://www.atelierb.societe.com/index uk.html
the B development. The preservation of this information in the form of an assertion as proposed here provides this useful information in the produced code and/or in its interface, depending of the target language. C. Impact on the component with contract approach It is not sufficient to provide the contract of a component to be sure that the contract is fulfilled. Assume that the insertion task of the dictionary is specified by insert (x: ELEMENT; key: STRING) require count
