CC BY
39
УДК 658.512
A. Malioukov
NON OBJECT-BASED APPROACH TO THE В FORMAL METHOD
1 Introduction
The work presents the В specification and implementation of ACVIS. В is a method for specifying, designing, and coding software systems [I]. ACVIS is A Computerized Visitor Information System. This system assists in managing arrangements for visitors and meetings at a large site.
2 The В Method
Application of formal methods for software engineering is an important issue these days. The formal methods are used in academic research as well as in industrial applications. One of the most promising formalisms is the В-Method. The В-Method is a model-oriented method used in industry to develop safety critical software systems. The В-Method and the Abstract Machine Notation, often abbreviated to AMN, were developed by J-R. Abrial from 1980 onward. AMN is a combination of mathematics and substitution that is used in specification and design in the B-Method [5]. The mathematical framework was provided by using predicate transformers and by extending E.W. Dijkstra's Weakest Precondition Calculus [7]. Work by R-J. Back, J.M. Morris and C.C. Morgan and others had illustrated how Dijkstra's calculus for programs could be extended to cover abstract specification. These extensions inspired the development of B's Generalised Substitution Language (GSL) for use within the В-Method. GSL adds the predicate transformers of pre-conditions and unbounded non-determinism to Dijkstra's notation for guarded commands. During these three years, J-R. Abrial devised most of the features specific to AMN and the В-Method. Discussion with C.C. Morgan and the collective work at the Programming Research Group (PRG) at Oxford University have had a significant influence on this work.
The В method is close to VDM (Vienna Development Method) [12] and to Z [13J. Obviously, many ideas of both these methods can be recognized in B. Z is the result of an effort started by J-R. Abrial around 1975 in Grenoble, and continued in Paris and Oxford. Abrial shared an office with C.B. Jones [] lj during the same period. From him J-R. Abrial learned the idea of program development and the concept of refinement and its practical application, under the form of proof obligations [I].
There are two toolkits supporting the В formalism. The firs); one, the B-Toolkit [2], was released by В-Core (UK) in 1994. The second one, Atelier В [3] has been produced by Steria (Digilog) in collaboration with J-R. Abrial. Both tools have similar facilities and provide support for all development process, syntax, type and static semantics checking, animation, proof obligation generation, automatic and interactive proof, code generation and pretty-printing (in LaTeX and HTML formats). The first significant industrial success in formal development has been achieved in Prance, where the safety critical software of the METEOR system (a new line of metro in Paris) was formally developed with the help of Atelier В by Matra Transport International [15].
The International В Conference Steering Committee (Association de Pilotage des Conferences B - APCB) [8] has as its purpose to support, further and develop the study of the В Method for specification and formal development of software. There is a user group, called the BUG [9], for exchanging and discussing information on B. Every year APCB organizes the International В Conference, supported by the BUG and the ZUG (the Z User Group) [10].
3 Problem Description
We illustrate our approach by the B specification of A Computerized Visitor Informat ion System (ACVIS). ACVIS based on A Computer Aided Visitor Information And Retrieval system (CAVIAR). A formal specification of CAVIAR was given in 1981 by J-R. Abrial and was subsequently specified in Z by B. Flinn and I.H. SOrensen [6]. In 1992, R. Docherty and A. Diller presented CAVIAR in AMN [14].
The following information is initially given: Visitors come to the site to attend meetings. A
visitor may require a hotel reservation. Each meeting is required to take place in a conference room. A
meeting may require the use of a dining room for lunch. Booking a dining room requires lunch information, including the number of places needed.
Some important properties:
1. At any time a conference room may be associated with only one meeting.
2. At any time a meeting may be associated with more than one conference room.
3. At any time a meeting may be associated with only one dining room.
4. At any time participants from several meetings can occupy the same dining room. Each dining room has a maximum capacity and unnumbered seats.
5. At any time a visitor may be associated with only one meeting.
6. At any time a meeting may involve several visitors.
7. At any time a hotel room may be associated with only one visitor.
Remark: We omit the notion of time but it can be added, if needed.
4 Non Object-Based Specification of the ACVIS
The B-Method is a formal model oriented method based on set theory and relies on an extention of the weakest precondition calculus. A program derivation in the B includes such steps as a specification, a number of refinements and an implementation which are represented as abstract machines. The specification is a formal description of a problem domain. By the refinement steps specification can be transformed into the implementation. The implementation can be automatically translated into C-code and it is not allowed to contain any nondeterminism which is usually involves on the specification step.
Abstract Machine Notation (AMN) is using for specifying the operations. Statement in AMN can be a simple substitution (>k := e), a .sfcip-substitution, a precondition substitution (PRE P THEN S END), and/or guarded substitution (SELECT P THEN S END), where P is a predicate, S is a substitution, a; is a variable and e is an expression. Each substitution defined as a predicate transformer which transforms a postcondition Q into the weakest precondition for S to establish Q, wp(S, Q).
The structure of AMN specification will be described on the above example of non objcct-based specification of the ACVIS. The specification is identified by the unique machine name ACVIS-Dining-Room-Capacity is an imput parameter, which should be type of natural numbers or sets. The set of constraints on the parameters usually presented in the CONSTRAINTS clause. In our example, we do not have such clause, because Dining-Room-Capacity is a natural number. CONSTANTS clause introduces constants and PROPERTIES clause gives their definitions.
MACHINE ACVIS (Dining,_Jloor-C'opacity)
VARIABLES
register'-book-j'or'-visitors, hotel-rooms-booking, register -book-for'-meetings, meeting-visits, conference-rooms-booking, dining-rooms-booking
INVARIANT
register-book-for-visitors С PEOPLE JI
hotel-rooms-booking is a set of partial injections from each registered visitor to one hotel room from the set HOTEL-ROOMS (also known as 'one-to-one' relations).
hotel-rooms-booking G register-book-for-visitors h-» HOTEL-ROOMS Jl register-book-for-meetings C MEETINGS JI
meeting-visits is a set of partial functions from some registered visitor to some registered meetings (also known as 'one-to-many' relations).
meeting-visits C register-book-for-visitors -+>• register-book-for-meetings Jl
conference-rooms-booking is a set of partial functions from some conference room from the set CONFERENCE-ROOMS to some registered meetings.
conference-rooms-booking £ CONFERENCE-ROOMS -+>• register-book-for-meetings Jl
dining-rooms-booking is a set of partial functions from some registered meeting to some dining rooms from Ihc set DINING-ROOMS.
dining-rooms-booking 6 register-book-for-meetings -+> DINING ROOMS Jl
V d-r (d-r 6DINING-ROOMS-Acard(JI' t11) ><
Room-Capacity )
initialisation
register-book-for-visitors := {} II hotel-I'ooms-booking := {} |[ register-book-for-meetings '•= {} 11 meeting-visits ’■= {} II conference-rooms-booking '•= {} ^ dining-rooms-booking := {}
OPERATIONS
Create-Meeting Creale-Meeting (meeting)
PRE meeting e MEETINGS JI
meeting * register-book-JOT-meetings hnn^nr~eeti„oS U { meeting } END ;
THEN register-book-for-meetings := reg.ster-boolf or meetings
Cancel-Meeting
Cancel-Meeting (meeting)
PRE meeting £ register'-book-j'or'-meetings JI meeting (/. ran ( meeting-visits ) JI
meeting $? ran ( conference-rooms-booking ) Jl meeting A dom (dining-rooms-booking)
THEN register-book-)'or-meetings : = register-book-]'or-meetings— (meeting) END;
Add-Visitor-To-Meeting
Add-Visitor-To-Meeting (visitor, meeting ) = PRE meeting 6 register-book-for-meetings Jl visitor £ register-book-for-visitors Jl visitor A dom ( meeting-visits ) Jl
Before we add a new visitor to the cunent meeting we want to be sure that there is as minimum one vacant place in the dining rooms that were booked for this meeting.
card ( meeting-visits 'J [ dining-rooms-booking'' [ dining-rooms-booking [ { meeting }]]])< Dining-Room-Capacity THEN meeting-visits := meeting-visits U ( visitor i-> meeting J END;
Remove-Visitor-From-Meeting
Remove- Visitor-From-Meeting( visitor ) PRE visitor £,dom ( meeting-visits ) THEN
The result of this operation will be anli-restriction of meeting-visits by visitor (also known as domain subtraction).
meeting-visits := { visitor } -A meeting-visits END ;
Book-Conference -Room
Book-Conference-Room( meeting, room ) =
PRE meeting 6 register-book-fom-meetings Jl room e CONFERENCE-ROOMS Jl room A dom ( conference-rooms-booking )
THEN conference-rooms-booking: = conference-rooms-booking U { room >-?
meeting } END;
Cancel_Conference_Room
Cancel-Conference-Room( meeting) A
PRE meeting 6 ran ( conference-rooms-booking) THEN
The result of this operation will be anti-co-restriction of meeting by conference-rooms-booking (also known as range subtraction).
conference-rooms-booking: = conference-rooms-booking A { meeting } END ;
Book_Dining_R.oom
Book-Dining-Room( meeting, room ) =
PRE meeting £ register-book-]or-meetings I \ meeting A dom ( dining-rooms-booking) Jl room £ DINING-
ROOMS S\
Before we book Ihe dining room we to want be sure that there arc enough vacant scats for all visitors of the current meeting.
card (meeting-visits'' ( dining-rooms-booking '' [ { room } ] U { meeting } ]) A
Dining-Room-Capacity THEN dining-rooms-booking: - dining-rooms-booking U { meeting i —A room /END;
CanceIJDinmgJR.oom
Concel-Dining-Room(meeting) =
PRE meeting £ dom (dining-rooms-booking )
THEN dining-rooms-booking : = j meeting} -A dining-rooms-booking
END;
Cancel_ MeetingAArrangements
CanceLMeeting-Arrangements* meeting ) =
PRE meeting G reglster-book-jor-meetings
THEN register’-book-jar-meetings := register-book-f or-meetings — { meeting } tt conference-rooms-booking := conference-rooms-booking A> { meeting ) ||
dining-rooms-booking := {meeting } <3 dining-rooms-booking \\ meeting, visits := meeting-visits
A {meeting )
END;
CreateVisitor
Create- Visitor (person )
PRE person 6 PEOPLE J1
person A register'-book-for'-visitors THEN register-book*'orvisitors . = register’-book-j’or -visitors U { person f END ;
Destroy-Visitor
Destroy- Visitor(person)
PRE person £ register-book-for-visitors J1 person A dom ( hoteLrooms-booking) J1 person (f_ dom ( meeting-visits )
THEN register-book-for-visitors . = register-book-for-visitors — {person } END ;
Book-Hotel-Room
B°ok-Hotel-Room{person , room ) =
PRE person £ register-book-for-visitors JI
person j. dom ( hotel-rooms-booking) Jl room G HOTEL-ROOMSn room $? ran (hotel-rooms-booking)
THEN hotel-rooms-booking := hotel-rooms-booking V {person ,-> room } END ;
cancd_Hotel_Room
Cancel-Ilotel-Room(person) =
PRE person 6 dom ( hotel-rooms-booking)
THEN holel-rcoms-booking := {person } -A hotel-rooms-booking END
DEFINITIONS
HOTEL-ROOMS = N ;
PEOPLE = N;
MEETINGS = N;
CONFERENCE-ROOMS = N ;
DINING-ROOMS = N
END
5 Conclusions and Future Work
This paper is a preliminary step. Our main goal is object-based solution of ACVIS (A Computerized Visitor Information System). Here we achieved some results, which we can compare with object-based solution in purpose to find advantages and drawbacks later.
REFERENCES
1. Abrial, J.-R.: The B-Book. Cambridge University Press (1996)
2. B-Core. B-Toolk.it Release 3.2. Manual. Oxford, U.K. (1996)
3. Steria Mediterranee. Atelier B. France (1996)
4. Lano, K.: The B Language and Method. A guide to Practical Formal Development. Springer-Verlag (1996)
5. Wordsworth, J.B.: Software Engineering with B. Addison-Wesley (1996)
6. Flinn, B., SOrensen, I.H.: CAVIAR: a case study in specification. In I.Hayes (editor) Specification Case Studies, Prentice-Hall International (1987)
7. Dijkstra E.: A Discipline of Programming. Prentice-Hall (1976)
8. The International B Conference Steering Comitte Web Site: http://www.sciences.univ-nantes.fr/asso/APCB/
9. The B Formal Method Users Group Web Site: http://estasl.inrets.fr:
8001 /ESTAS/BUG/WWW/BUGhome/BUGhome.html
10. The Z User Group Web Site: httpV/www.comlab.ox.ac.uk/archive/z/zug.html
11 .Jones B.C.: Systematic Software Development using VDM. Second Edition. Prentice-Hall (1990)
12. Bicarregui J., Ritchie B.\ Invariants, frames and postconditions: a comparison of the VDM and B notations. In FME'93 Proceedings, Lecture Notes in Computer Science Vol. 690. Springer-Verlag (1993)
13. Diller, A., Docherty, R.: Z and Abstract Machine Notation: a comparison. Proceedings of 8-th Z User Meeting - ZUM, J. Bowen (Ed.) (1994)
14. Diller, A., Docherty, R.: CAVIAR in AMN. Technical Report CSR-93-3, University of Birmingham, School of Computer Science (1992)
15. Behm, P., Desforges, P., Meynadier, J-M.\ METEOR: An Industrial Success in Formal Development. B'98: Recent Advances in the Development and Use of the B Method. Proceedings of the Second International B Conference, Montpellier, France, April 1998. Didier Bert (Ed). Lecture Notes in Computer Science Vol. 1393. Springer (1998)
