CC BY
43
УДК 658.512
A. Malioukov AN OBJECT-BASED SOLUTION OF A COMPUTERIZED VISITOR INFORMATION SYSTEM
Abstract
In this work, we describe an approach to the design of distributed systems that integrate object-oriented methods (OOM) and the non object-oriented В formal method. Our goal is to retain some OOM advantages and produce a flexible and reliable specification. Through the use of our example, we show how this is achieved. We prove formally that our design meets its informal specification with the help of В-Toolkit Release 3.4.2. We illustrate the approach by the В specification of A Computerized Visitor Information System (ACVIS). Object Modeling Technique diagrams allows us to make ACVIS more readable and open for changes.
1 Introduction
The work presents the В specification and implementation of ACVIS. В is a method for specifying, designing, and coding software systems [1]. ACVIS is A Computerized Visitor Information System. This system assists in managing arrangements for visitors and meetings at a large site. Our goal is to produce a reusable specification of this system. For this purpose, we use Object-Oriented Methods (OOM). We prove formally that our design meets its specification with the help of B-Toolkit Release 3.4.2 (Copyright В-Core (UK) Ltd. 1985-96) [2]. Although В is non object-oriented in nature, we still hope to retain some OOM advantages. Through the simulation of inheritance and encapsulation we integrate OOM with the not object-oriented formal method В. A В specification is generally constructed from a structure of included abstract machines. Abstract machine is a concept that is very close to certain well-known notions in programming, such as modules, classes or abstract data types [I]. For design and detailed description of ACVIS we use the Object Model Notation of Object Modeling Technique (OMT). These diagrams allow us to make ACVIS more readable and open for changes. The following steps are taken for the formal specification, design and implementation of ACVIS software:
• At an early stage in the analysis it becomes clear that ACVIS consists of several highly independent subsystems. This leads us first to define the manager of our system and then to specify the help machines (the subsystems in isolations).
• We refine the help machines into four special ones. We need to prepare ACVIS for the implementation of a previously used dot notation.
• We implement all specifications that we are using im modeling of the system.
The resulting model is robust, flexible and reliable. There are fewer proof obligations. The given solution can be easily changed to allow new tasks.
2 Objcct-oricnted and Object-Based Development
Superficially the term "object-oriented" (00) means that we organize software as a collection of discrete objects that incorporate both data structure and behavior [7]. 00 development has the following general properties: encapsulation, inheritance, polymorphism and dynamic binding.
• ENCAPSULATION. The property of a software module, such that changes to the implementation of the module that do not alter its abstraction do not affect the use of that module by any other module [19].
• INHERITANCE. The convention by which the definition of a subclass is considered to automatically include all the attributes defined in any of its superclass and to also include any operations defined in any of its superclasses that are not specially redefined [19].
• DYNAMIC BINDING and POLYMORPHISM. Program entities should be permitted to refer to object of more than one class, and operations should be permitted to have different realizations in different classes [20].
At initial glance, objects and В machines have many similarities, such as inheritance or encapsulation. The В-Method and its supporting tools enforce the idea of encapsulation completely [5]. However, as noted in [22] objects are structured in order to model the real world, where machines are structured in order to encapsulate proof obligations. We do not use polymorphism and dy namic binding because they are not supported by В-Toolkit. Thus, in practice, В-Toolkit cannot even give a possibility to exploit any global variables. Nevertheless, it makes sense, because when the tool tries to prove the correctness of a machine nobody can be sure that-simultaneously another machine, using the aforementioned variables has not changed their values. This causes confusion as to the correct variables to use. Finally we can state that the В-Toolkit is not object-oriented but object-based, that is why we name our system as Object-Based AC VIS (OBACVIS).
3 Overview of the Object Modeling Technique
The Object Modeling Technique (OMT) is a methodology for software development, based on a graphical notation for representing object-oriented concept. 00 notation is used to describe classes and relationships throughout their life-circle. The methodology uses three kinds of models to describe a system: object, dynamic and functional models. The object model contains object diagrams and captures the static structure of the objects in a system and their relations. The dynamic model contains state diagrams and describes the aspects of the system that change over time. The functional model contains data flow diagrams and specifies the data value transforma tions. The design of each model consist of optimizing, refining, and extending until the models are detailed enough for implementation phase. The OMT method produces systems that are more stable with respect to changes in requirements than traditional functional-oriented approaches.
The OMT notation is the graphical notation that are used to build the object model, dynamic model, and functional model. A class in the OMT notation is represented by a box with three regions, which contain, from top to bottom: class name, list of attributes, and list of operations. An association describes a group of links with common structure and common semantics. The OMT notation for an association is a line between classes. Associations may be binary, ternary, or higher order.
The Unified Modeling Language (UML) [9] uses similar semantics and notation as OMT, Booch [10], Object-Oriented Software Engineering (OOSE) [11] and the statecharts [12, 13] of David Harel, with minor modifications. It is therefore possible to use this emerging standard modeling language for the description of software systems, instead of OMT notation.
4 Problem Description
We illustrate our approach by the В specification of A Computerized Visitor Information System (ACVIS). AC VIS 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 sub-
sequently specified in Z by B. Flinn and I.H. SOrensen [6]. In 1992, R. Docherty and A. Dillcr presented CAVIAR in AMN [17].
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.
5 From the Problem Description to the Specification
Our goal is to create a object-based specification that meets the ACVIS requirements. As far as OBACVIS is an object-based solution let us start from the object model. For constructing such a model we should do the following steps according to the OMT method [7]:
• Identify classes;
• Identify associations between classes;
• Identify attributes of classes;
• Organize and simplify classes using inheritance.
1. The identification of classes consists of:
• Extraction of all nouns from the problem statement. Presume they are the initial classes. In the OBACVIS example it is: Visitors, Meetings, Hotel reservation, Conference rooms, Participants, Dining rooms, Lunch, Seats, Hotel rooms, Maximal capacity of a dining room, Number of places in a dining room.
• Additional classes that do not appear directly in the statement, but can be identified from our knowledge of the problem domain. For example, People.
• Eliminating unnecessary and incorrect classes according to the following criteria:
Attributes. Names that primarily describe individual objects should be restated as attributes. For example. Maximal capacity of a dining room is a dining room's property.
Operations. For example. Hotel reservation is a sequence of actions and not an object
class.
— Irrelevant. Initial class Lunch has nothing in common with our visitor information system.
CONFERENCE
ROOMS
HOTEL
ROOMS
DINING
ROOMS
Figure 1: Elimination Unnecessary and Incorrect Classes Vague. For example, Seats is vague. In the OBACVIS system, this is a part of Dining
rooms.
- Redundant. If two or more classes express the same information the most descrip tive name should be kept. For instance, Participants and Visitors are redundant.
Removing all spurious classes, we are left with the following classes (Fig. I):
- PEOPLE
- MEETINGS
- CONFERENCE-ROOMS
- DINING-ROOMS
- HOTEL_ROOMS
2. Now we should identify the associations between classes. Any dependency between two or more classes is an association. It can be easily done according to the task description. For example, if one considers the phrase from the problem description "At any time a conference room may be associated with only one meeting", it is obvious that between classes MEETINGS and CONFERENCE-ROOMS should be 'many-to-one' relation. By using such a simple method we find four associations between defined classes. They are designated as meeting.visits, hotel-rooms-booking, dining-rooms-booking, conference-rooms-booking.
3.Now we have the classes and associations between them. We can draw an initial class diagram by using Object Model Notation of OMT. Following the notation, all classes are described by means of rectangles and the associations among classes are defined as named arcs. Fig. 2 shows OBACVIS initial class diagram. The class diagram is an object diagram that describes a class as a schema, pattern, or template for many possible instances of data [7]. We should not forget the difference between classes and objects. Object is a concept, the abstraction, or thing with crisp boundaries and meanings for the problem at hand. Class is a description of a group of objects with similar properties, common behavior, common relationships, and common semantics [7]. In such case, HOTEL-ROOMS is a class but HOTEL-ROOM is an object.
Attributes are properties of individual objects, such as name, weight, velocity, or color. In the OBACVIS we define the following attributes: register-book-for-visitors, register-book-for-meeti'i and Dining-Room-Capacity
PEOPLE MEETINGS dl*iAt-lV04Uj>0(Ai»t DINING JIOOMS
w Ш
.
1ог^гтгт‘г_пнлы^voting
«Racily i км лапу (ten><v mure)
Figure 2: OBACVIS initial class diagram
Actually register'-.book-)'or'-visitors and register-book-for-meetings are sets of names. The meaning of these two attributes can be explained in the following manner: having name of any visitor (meeting) one can check if this item is in the set of visitors (meetings) or not. One can use this information to avoid duplication of the registration. Attribute Dining-Room-Capacity is a maximal number of seats at each dining room. For the simplification of our problem we assume that all the dining rooms have an equal number of seats.
4. The next step is to organize classes by using inheritance. CONFERENCE-ROOMS, DINING-ROOMS and HOTEL_ROOMS have similar structure, except DINING_ROOI which has an attribute Dining-Room-Capacity. We can open a new superclass HM (help machine). Each
subclass (CONFERENCE_ROOMS, DINING-ROOMS and HO-TEL-ROOMS) inherits all properties from the superclass HM.
Fig. 3 is a class diagram of OBACVIS with attributes and inheritance.
6 Specification in B
In the B-Method, specifications, refinements and implementations are presented as Abstract Machines. B is one of the few "formal methods" which has robust, commercially available tool support for the entire development life cycle from specification through to code generation [4]. Further on, we are going to show the B-code and explain the way of system modeling by using the object model of OBACVIS.
We present each class from previously defined object model as a separate abstract machine. Machine OBACVIS is the manager of the whole system. The attributes of the object model we define as two variables [register-book-]'or-visitors and register-hook-j'or-meetings) and one input parameter (Dining-Room-Capacity).
INVARIANT should contain all information about the associations between classes, otherwise one cannot be sure that a machine meets the requirements of the informal specification.
Operations can be generated according to the different scenarios (a scenario is a sequence of operations that occurs during one particular execution of a system, the scope of scenario can
Figure 3: OBACVIS class diagram with attributes and inheritance
• Book-Dining-Room books a free dining room for an arranged meeting. A dining room cannot be booked twice.
• CanceLDining-Room makes free a booked dining room.
• CanceLMeeting-Arrangement quits a meeting with associated conference, dining rooms and all registered visitors.
• Create- Visitor registers a new visitor. A visitor cannot be registered twice.
• Destroy-Visitor removes the name of a registered visitor from the registration list.
• Book-HoteLRoom books a hotel room for a registered visitor. A person cannot book one hotel room twice. Only one person can book one hotel room.
• CanceLHoteLRoom checks out a visitor.
OBACVIS manages each operation of the above-defined classes. Such managing works in the following way: OBACVIS declares the types of input parameters and after that calls the operations from the help machines. They do some actions: an initialization of variables, definition of sets and
INVARIANT, checking preconditions of operations (the INVARIANT should hold for all preconditions), and finally changing sets according to the operation.
There are still some preconditions at the operations of OBACVIS. Mainly these preconditions declare the types of input parameters. That is why B-Toolkit generates only twenty-four proof obligations for the OBACVIS instead of thirty-seven for the non object-based solution AC VIS. Fifteen proof obligations were proved by the Automatic Prover (AutoProof) of B-Toolkit. Others were proved easily.
MACHINE OBACVIS ( Dining-Room-Copacity) INCLUDES HR.HMJ1 CR HM.3.MV HM-2 , DR HM-S
VARIABLES
register-book-for-visitors register J)ookJor-meetings
INVARIANT
register'-book)'or'-visitors is a subset of set PEOPLE. In other words, register'-book-for'-visitors is the list of registered visitors.
register-book-for-visitors C PEOPLE JI
register-book-for-meetings is a subset of set MEETINGS. In other words, register-book-for-meetings is the list of registered meetings.
register-book-for-meetings C MEETINGS JI
The sum of all registered visitors from all registered meetings that associated with each dining
room should be less or equal Dining-Room-Capacity.
V d-r ( d-r £ DINING-ROOMS => card (MV event ^ [DR event[ fd-r ) ] ]) < Dining-Room-Capacity)
INITIALISATION
mgister-book-j'or-visitors '•= QII register-book-for-meetings ••= 0
OPERATIONS
Create-Meeting
Create-Meeting( meeting) -
PRE meeting (= MEETINGS J1
meeting A register-book-for-meetings THEN
register-book-for-meetings: = register-book-for-meetings U { meeting }
END;
Cancel_Meeting
Cancel-Meeting ( meeting)
PRE meeting G register-book-for-meetings JI meeting A ran (AfV . evenA) Jl meeting A ran ((7J1. evenA) Jl
meeting j. dom (flJI. event) THEN
register-book-for-meetings := register-book-for-meetings { meeting }
END;
Add_Visitor_To .Meeting
Add- Visitor-To-Meeting ( visitor, meeting) = PRE meeting £ register-book-for-meetings /1 visitor £ register-book-for-visitors Jl visitor j. dom (A/V event) Jl
Before adding a name of new visitor to the list of participants of the current meeting we want to be sure that there is as minimum one vacant place in the dining room.
card ( MV event -1 [ DR event ~1 [ DR event [ { meeting }]]])<
Dining-Room-Capacity THEN
MV Adding ( visitor, meeting) END ;
Remove -Visit or -FromJVIeeting
Remove- Visitor-From-Meeting{ visitor)
PRE visitor 6 dom (MV event} THEN
MV Cancelation ( visitor) END ;
Book_Conference_R.oom
Book-Conference-Room( meeting, room ) =
PRE meeting 6 register-book-for-meetings J1 room 6 CONFERENCE. ROOMS J1
room $? dom ((7J1. event) THEN
Ch . Adding ( room , meeting) END ;
Cancel-Conference-Room
CanceLConference-Room( meeting) = PRE meeting £ ran ( Ch . event) THEN
C77 Cancelation ( meeting ) END ;
Book_Dinmg_R,oom
Book-Dining-Room( meeting, room ) =
PRE meeting G register-book-for-meetings J1 meeting j. dom (
-OJ1. event) }\ room e DINING-ROOMS JI
Before booking the dining room, we want lo be sure that there are enough vacant seals for all visitors of the current meeting.
card ( MV event [ DR event'' [ / room } ] U { meeting } 1) <
Dining-Room-Capacity THEN DR. Adding ( meeting, room ) END ;
Cancel-Dining-Room
CanceLDmmg-Room(meeting) =
PRE meeting £ dom ( DR. event) THEN DR. Cancelation ( meeting ) END ;
Cancel_Meetmg_A.rrangements
Cancel-Meeting-Arrangementsf meeting ) = PRE meeting 6 register-book-for.meetings THEN register-book-J'or-meetings := register-book-f or-meetings — { meeting } ||
CR. Cancelation ( meeting) ||
J1JI Cancelation (meeting ) ||
A/V . Cancelation ( meeting ) END ;
Create_Visitor
Create- VisitorA person )
PRE person 6 PEOPLE Jl
person A register-book-for-visitors THEN
registerjbook Jor_visitors := register-book-for-visitors U {person } END ;
Destroy-Vlsitor
Destroy^Visitor {person)
PRE person £ register-book-for-visitors Jl person A dom ( JUI. event) Jl
person A dom ( AfY . event) THEN
register-book-for-visitors := register, book-for-visitors — {person ] END ; Book_Hotel_R.oom
Book-Hotel-Room(person , room ) = PRE
person 6 register-hook-]or-. visitors Jl person $? dom (event) Jl
room e HOTEL-ROOMS THEN ?)J1 Adding (person, room)
END;
Cancel-Hotel -Room
CanceLHoteLRoomf person )
PRE
person £ dom ( HR. event )
THEN
HR Cancelation ( person )
END
DEFINITIONS
HOTEL-ROOMS = N ;
PEOPLE = N;
MEETINGS = N;
CONFERENCE-ROOMS = N ;
DINING-ROOMS = N
END
7 Help Machines
We include four help machines into system manager OBACVIS. Actually, there are only three help machines. We make our specification more elegant by using a dot notation. For instance, MV.HM-2 and DR.HM-2 are two machines with an identical structure but with different data. In other words, machines MV.HM 2 and DR.HM 2 inherit all variables and operations from the machine HM_2. If we add one element into machine MV.HM-2, it will be the same as if we would add one element into the set MV event but not into the set DR.event or event. Each help machine has its own INVARIANT.
DR.HM-2 corresponds to the class DINING-ROOMS, CR.HM-3 CONFERENCE-_ROOMS, HR.HM l - HOTEL-ROOMS, MV.HM-2 simulates the process of visitor registra tion. It is easy to note that name of each help machine consists of class name abbreviation and number of help machine's type. We keep a few classes inside the system manager, for instance, PEOPLE and MEETINGS. We would like to emphasize the fact that it is not necessary to define each class as a separate abstract machine.
Each help machine includes operations to create an object (Adding) and to destroy all object instances (Cancelation). It is impossible "to send" from super-machine into sub-machines any notes about the type of operator between variables. Machines HM-1 and HM-2 are absolutely identical but variable event at HM-1 is a set of partial injections (also known as 'one-to-one relation'). Unlike variable event at HM-2 is a set of partial function (also known as 'many-to-one relations'). The difference between HM-3 and HM-1 or HM-2 is that at operation Cancelation of machine HM-2 the result is an anti-restriction (also known as domain subtraction) but at other help machines it is anti-co-restriction (also known as range subtraction).
MACHINE HM-1
VARIABLES
event
INVARIANT
event e XX >Л YY INITIALISATION
event: - {}
OPERATIONS
Adding
Adding( xx yy ) = PRE
xx £ XX A
жа; A dom (event) J1 yyG ГУЛ
t/r/A ran (eAent)
THEN event := event U { xx i-*yy ) END ;
Cancelation
Cancelationf xx) =
PRE Ta £ XX
THEN event r- {xx j <3 event END DEFINITIONS
XX N;
YY N
END
The B-Toolkit generates nine proof obligations for the help machines. All of them can be easily proved by the AutoProof.
8 Conclusions and Future Work
There is an advantage in object-based solution ACVIS (A Computerized Visitor Information System) problem:
• Decrease a quantity of proof obligations. There are 24 proof obligations for the main machine OBACVIS and 9 for the sub-machines. However, about 80 % of the proof obligations are proved by AutoProof.
• The new system is quite flexible. If one needs a new kind of room he (she) should include one of the submachines, which meets the requirements of the selected type, call some operations of this submachine from OBACVIS or if it makes sense, add a new submachine. He (she) should not add any new variables or lines into the INVARIANT.
• An object-based approach produces a clean, well-understood design that is easier to test, maintain, and extend than non-object-based designs because object classes provide a natural unit of modularity.
• A beneficial side effect for practitioners writing such documents is that their understanding of the system in OMT diagrams is greatly helped by the process of constructing formal specifications. Such diagrams can be useful for presentations.
We are also interested in rising the abstraction level from the initial B formalism to UML diagrams. The Unified Modeling Language (UML) is now the standard notation for software architecture and represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems. UML includes the OMT mentioned above. Briefly, our idea is that the modeling design could be done according the following algorithm:
1. design a model of a system on the level of the ULM diagrams;
2. translate the diagrams into B code;
3. generate proof obligations with help of the B-Toolkit or Atelier B;
4. discharge these proof obligations using automatic and interactive provers;
5. put changes into the diagrams, according to the results of the fourth step;
6. repeat all previous five steps until the specification meets needed requirements;
7. implement specification and generate code.
There are many visual modeling tools supporting OMT or/and UML. With the help of such tools user gets possibility of automatic translation of the UML (OMT) diagrams into many 00 computer languages. However, the existing tools which support the B formalism can generate only C/C++ code from the B source. Therefore, if one designs his (her) system using diagrams, it would be possible to interpret the B code not only in C/C++, but in some other computer languages.
If the В formal method will be 00, and at the same time some tool will support the "round trip" between diagram and В code levels, then one would be able to use the В-Toolkit or Atelier В as the syntactical checker. It will dramatically acceleratc the use of the В formal method.
REFERENCES
1. Abrial, J.-R.: The B-Book. Cambridge University Press (1996)
2. В-Соге. В-Toolkit Release 3.2. Manual. Oxford, U.K. (1996)
3. Steria Mediterranee. Atelier B. France (1996)
4. Lano, K.: The В 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) Specifi-
cation Case Studies, Prentice-Hall International (1987)
7. Rumbaugh, J„ Blaha, М., Premerlani, W., Eddy, F., Lorensen W: Object-Oriented Modeling and Design. Prentice-Hall International (1991)
8. UML Web Site: http://www.rational.com/uml
9. Booch, G.: Object-oriented Analysis and Design with Applications, 2nd edition. Benjamin Cummings, Redwood City (1993)
10. Jacobson, /., Christerson, М., Jonsson, P., Overgaard, G.: Object-Oriented Software Engineering. A Use Case Driven Approach. Adison-Wesley (1992)
11. Harel, DStatecharts: A Visual Formalizm for Complex Systems. Science of Computer Programming, (8):231-274 (1987)
12. Harel, D., Gery E.: Executable Object Modeling with Statecharts. Proc. 18-th Int. Conf. Soft. Eng., Berlin, IEEE Press, March: 246-257 (1996)
13. Jones, B.C.: Systematic Software Development using VDM. Second Edition. Prentice-Hall (1990)
14. 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)
15. Diller, A., Docherty, R.: Z and Abstract Machine Notation: a comparison. Proceedings of 8-th Z User Meeting - ZUM, J. Bowen (Ed.) (1994)
16. Diller, A., Docherty, R.: CAVIAR in AMN. Technical Report CSR-93-3, University of Birmingham, School of Computer Science (1992)
17. Behm, P., Desforges, P., Meynadier, J-М.: METEOR: An Industrial Success in Formal Development. B'98: Recent Advances in the Development and Use of the В Method. Proceedings of the Second International В Conference, Montpellier, France, April 1998. Didier Bert (Ed). Lecture Notes in Computer Science Vol. 1393. Springer (1998)
18. Seidewitz, E., Stark., М.: Reliable Object-oriented Software. SIGS Books (1995) [19] Meyer, B.: Object-oriented Software Construction. Prentice-Hall International (1988)
19. Shore, R.: An Object-oriented Approach to B. "First В Conference", Nantes, France, Novem ber, 24-26(1996)
20. Facon, P.: Mapping object diagrams into В specifications. In Methods Integration Workshop (1996)
УДК 658.512
Верба B.A. ИССЛЕДОВАНИЕ СВОЙСТВ ФУНКЦИИ ЭФФЕКТИВНОСТИ
Свойство наблюдаемости состоит в том, что состояние системы в прошлом может быть определено по результатам наблюдений над выходными сигналами системы. Наблюдаемость системы характеризует возможность определить состояние невозбужденной системы по
