CC BY
64
взаимоотношений между подразделениями предприятия, а также детально описать документооборот.
Одним из основных требований, выставляемых к данному этапу, является использование известных CASE-средств при формировании визуальной модели пред, , повседневной работе используют такие инструментальные средства как BPWin, Rational Rose и т.п.
Данный этап можно назвать заключительным, но он является заключительным для нашего инструментального средства, а на самом деле только с этой точки и начинается непосредственное проектирование информационной системы: оптимизация модели «как есть» в модель «как надо»; разбиение на модули и подсистемы и т.д.
Заключение. Таким образом, предлагаемая концепция охватывает этапы от сбора первичной информации о предприятии до построения математической модели. Конечным результатом является подготовленный материал для проектирования структуры информационной сети предприятия, а также визуальная модель
- « ». -тодики специальные инструментальные средства могут значительно облегчить , -, ,
, .
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Смирнова Г.Н. и др. Проектирование экономических информационных систем: учебник. - М.: Финансы и статистика, 2002.
2. Данилевский ЮТ. и др. Информационная технология в промышленности. - J1.: Машиностроение, 1988.
3. Вен дров A.M. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.
4. Черняк ЮМ. Системный анализ в у правлении экономикой. - М.: Экономика, 1975.
5. Экономическая информатика. Учебник для вузов под редакцией В.В. Евдокимова. -СПб.: Питер, 1997. - 592с.
6. Свиридов А.С. Методика проведения предпроектного обследования с целью проектирования информационной сети предприятия. - М.: Телекоммуникации, 2003.
7. Системы связи ^ч^)ное пособие для ВУЗов / Васильев В.И., Буркин АП., Свириденко В А. -М.: Высш. школа, 1987.
УДК 007:861.518.2
A.S. Maliukov, V.V. Kureychik, S.P. Maliukov
THE B METHOD AND THE OBJECT MODELING TECHNIQUE*
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 applica-
* Работа выполнена при поддержке РФФИ, грант № 12388 03-01-00336
tions. One of the most promising formalisms is the B-Method. The B-Method is a model-oriented method used in industry to develop safety critical software systems. The B-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 [1]. The mathematical framework was provided by using predicate transformers and by extending E.W. Dijkstra's Weakest Precondition Calculus [2]. 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 Generalized Substitution Language (GSL) for use within the B-Method. GSL adds the predicate transformers of preconditions and unbounded non-determinism to Dijkstra's notation for guarded commands. During three years, J-R. Abrial devised most of the features specific to AMN and the B-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 B method is close to VDM (Vienna Development Method) [3] and to Z [4]. Obviously, many ideas from both of these methods can be recognized in B. Z is the result of an effort by J-R. Abrial who started working on it around 1975 in Grenoble, and continued this work in Paris and Oxford. Abrial shared an office with C.B. Jones [5] during the same period. Prom 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 [6].
There are two toolkits supporting the B formalism. The first one, the B-Toolkit [7], was released by B-Core (UK) in 1994. The second one, Atelier B [8] 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 was achieved in France, where the safety critical software of the METEOR system (a new line of metro in Paris) was formally developed with the help of Atelier B by Matra Transport International [9].
The International B Conference Steering Committee (Association de Pilotage des Conferences B - APCB) [10] has as its purpose to support, further and develop the study of the B Method for specification and formal development of software. There is a user group, called the BUG [11], for exchanging and discussing information on B. Every year APCB organizes the International B Conference, supported by the BUG and the ZUG (the Z User Group) [12].
At initial glance, objects and B machines have many similarities, such as inheritance or encapsulation. The B-Method and its supporting tools completely enforce the idea of encapsulation [1]. However, as noted in [13] objects are structured in order to model the real world, where machines are structured in order to encapsulate proof obligations. Polymorphism and dynamic binding are not supported by B-Toolkit. The B-Toolkit is not object-oriented but object-based.
Superficially the term "object-oriented" (OO) means that we organize software as a collection of discrete objects that incorporate both data structure and behavior [14]. OO 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 [15].
- 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 [15].
- 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 [16].
The Object Modeling Technique (OMT) is a methodology for software development, based on a graphical notation for representing object-oriented concept. A methodology for software development is a process for the organized production of software, using a collection of predefined techniques and notational conventions. The OMT organizes a system around objects that exist in the user's view of the real world. It makes the design more resilient to change, extensible and intuitive. The complete software life cycle spans from initial formulation of the problem, through analysis, design, implementation and testing of the software. The OMT methodology supports the entire software life cycle. The analysis should not contain any implementation decisions. The analysis model is pure abstraction of what the target system must do, but not how it will be done. During system design, the desired system is organized into subsystems. Object design extends the analysis model with specific implementation decisions and additional internal classes, attributes, associations and operations, which, in its turn, translated into a particular computer language during implementation stage.
The OMT methodology uses three kinds of models to describe a system: object, dynamic and functional models. OMT modeling regards the object model as the most important one, before 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 transformations. 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 is 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) [17] is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. UML [18] uses similar semantics and notation as OMT, Booch [19], Object-Oriented Software Engineering (OOSE) and the statecharts 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.
1. Problem Description. We illustrate our approach by the B specification of A Computerized Visitor Information System (AC VIS). AC VIS is 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 [20]. In 1992, R. Docherty and A. Diller presented CAVIAR in AMN.
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.
Figure 1: Elimination of Unnecessary and Incorrect Classes
2. From Problem Description to Specification.Our goal is to create an object-based specification that meets the ACVIS requirements. We prove formally that our design meets its specification with the help of B-Toolkit Release 3.4.2. We name our system as Object-Based ACVIS (OBACVIS) and start from the object model. For constructing such a model we should take the following steps according to the OMT method [14]:
- Identify classes. Class is a description for a set of objects that share similar properties, common behavior, common relationships and common semantics. Object is a concept, discrete entity with a well-defined boundary and identity that encapsulates state and behaviour; an instance of a class.
- Identify associations between classes. Any dependency between two or more classes is an association.
- Identify attributes of classes. Attributes are properties of individual objects, such as name, weight, velocity or color.
- Organize and simplify classes using inheritance.
1. The identification of relevant object classes in the problem domain consists of:
• Extraction of all nouns from the problem statement since classes often correspond to nouns. 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.
Figure 2: OB AC VIS initial class diagram
• 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.
- 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 descriptive name should be kept. For instance, Participants and Visitors are redundant.
Removing all spurious classes, we are left with the following classes (Fig. 1):
- PEOPLE
- MEETINGS
- CONFERENCE_ROOMS
- DINING_ROOMS
- HOTEL_ROOMS
2. Now we should identify the associations between classes. 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, hotelroomsbooking, diningroomsbooking, confe-renceroomsbooking.
Since 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 [14].
Figure 3: OBACVIS class diagram with attributes and inheritance
3. According to the attribute definition we specify the following attributes: regis-ter_book_or_visitors, register-book-for-meetings and Dining_Room_Capacity.
Actually register_book_for_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 DiningRoomCapacity is the maximal number of seats at each dining room. To prevent the usage of extra variable, we assume that all the dining rooms have an equal number of seats.
4. The next step is to organize classes by using inheritance. CONFERENCEJROOMS, DINING_ROOMS and HOTEL_ROOMS have similar structure, except DINING_ROOMS which has an attribute Dining Room Capacity. We can open a new superclass HM (help machine). Each subclass (CONFERENCE_ROOMS, DINING_ROOMS and HOTEL_ROOMS) inherits all properties from the superclass HM.
Fig. 3 is a class diagram of OBACVIS with attributes and inheritance.
We are interested in raising the abstraction level from the initial B formalism to OMT diagrams and vice versa. An object-based approach produces a clean, well-understood design that is easier to test, maintain and extend than non-object based B-code, because object classes provide a natural unit of modularity. Correctness of the B-code, in its turn, might be proven with the help of the B-Toolkit.
REFERENCES
1. Wordsworth, J.B.: Software Engineering with B. Addison-Wesley (1996).
2. Dijkstra, E.: A Discipline of Programming. Prentice-Hall (1976).
3. 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).
4. Diller, A., Docherty, R.: Z and Abstract Machine Notation: a comparison. Proceedings of 8-th Z User Meeting - ZUM, J. Bowen (Ed.) (1994).
5. Jones, B.C.: Systematic Software Development using VDM. Second Edition. Prentice-Hall (1990).
6. Abrial, J.-R.: The B-Book. Cambridge University Press (1996).
7. B-Core. B-Toolkit Release 3.2. Manual. Oxford, U.K. (1996)
8. Steria Mediterranee. Atelier B. France (1996).
9. 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).
10. The International B Conference Steering Comitte Web Site: http://www.sciences.univ-nantes .fr/asso/APCB/
11. The B Formal Method Users Group Web Site: http://estasl.inrets.fr:8001/
ESTAS/BUG/WWW/BUGhome/BUGhome.html
12. The Z User Group Web Site: http://www.comlab.ox.ac.Uk/archive/z/zug.html
13. Facon, P.: Mapping object diagrams into B specifications. In Methods Integration Workshop (1996).
14. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen W.: Object-Oriented Modeling and Design. Prentice-Hall International (1991).
15. Seidewitz, E., Stark., M.: Reliable Object-Oriented Software. SIGS Books (1995).
16. Meyer, B.: Object-oriented Software Construction. Prentice-Hall International (1988).
17. Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Modeling Language Reference Manual. Adison-Wesley (1999).
18. Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object-Oriented Software Engineering. A Use Case Driven Approach. Adison-Wesley (1992).
19. Booch, G.: Object-oriented Analysis and Design with Applications. 2nd edition. Benjamin Cummings, Redwood City (1993).
20. Diller, A., Docherty, R.: CAVIAR in AMN. Technical Report CSR-93-3, University of Birmingham, School of Computer Science (1992).
УДК 681.3.06
Э.М. Котов, А.Н. Целых
ИСПОЛЬЗОВАНИЕ МЕР БЛИЗОСТИ ДЛЯ ПОИСКА РЕЛЕВАНТНЫХ
ДОКУМЕНТОВ
До появления сети Интернет, когда размеры документальных баз данных были небольшими, а сами базы документов управляемы, частота появления слова и близость слов в документе были практически единственными критериями оценки соответствия запросу, или по другому релевантности. С приходом поисковых систем в Интернет в области информационного поиска открылись новые перспек-, , , большим количеством документов.
Когда пришло понимание того факта, что булевский поиск не отвечает потребностям рядовых пользователей, был разработан механизм нечеткого поиска. В его основе лежит отыскание документов, содержащих хотя бы одно ключевое слово запроса (его грамматическую форму, однокоренное слово либо синоним) и ранжирование найденных документов. К критериям оценки релевантности документа запросу добавляется еще один - количество слов запроса (точнее суммарный ), . качестве стратегии обработки запроса "по умолчанию", например, системами Альтависта и Лайкос.
, ,
, " " . -
зователь просматривает только первые несколько страниц, он редко попадает на страницы с нечеткими несоответствиями запросу, особенно если выборка объемная. Современные поисковые машины, например Яндекс, учитывают эту особенность и используют нечеткий поиск далеко не всегда, в основном, ограничиваясь
