Selçuk J. Appl. Math. Selçuk Journal of Vol. 5. No.2. pp. 57-71, 2004 Applied Mathematics
Intelligent Case for Semiotic Systems Vadim N. Vagin1and Novruz Allahverdi2
1Department of Applied Mathematics, Moscow Power Engineering Institute,
Kras-nokazarmennya 14, 111250, Moscow Russia; e-mail:vagin@ apm sun.m p ei.ac.ru
2Department of Electronics and Computer Education, Selçuk University,Campus, 42031,
Konya Turkey;
e-mail:noval@ selcuk.edu.tr
Received : October 20, 2004
Summary.An approach to designing dynamic decision support systems (DDSS) referring to semiotic ones and based on CASE (Computer-Aided Software Engi-neering) technology is considered. The semiotic model of a production type for such systems is given. The architecture of an intelligent repository and the hy-brid problem domain model of CASE systems are viewed. One can distinguish two stages of building a hybrid model of a CASE problem domain: designing a conceptual model of a problem domain and developing a formal model of a problem domain. Thus, a new approach to designing semiotic systems based on paradigms of "program engineering" and "knowledge engineering" was pro-posed.
Key words: Dynamic decision support system, CASE, semiotic system, in-telligent repository, knowledge base, hybrid problem domain model, conceptual model, formal model, multilayer logic.
1. Introduction
One of the approaches on creating the new technologies for automating soft-ware design is the CASE (Computer-Aided Softsoft-ware Engineering) approach. The most important aspects of the CASE approach are in automating all stages of the software life cycle, …rst of all, the initial stages, in separating software design from the coding stage, as well as in hiding from a designer the details of environment of developing and functioning [1, 2].
There are two generations of CASE development support tools. So-called "tools" that are intended for automating software design at individual stages of the development process belong to the …rst generation. These tools are divided into “higher level” tools which support the stages of planning, analysis and de-velopment in the software life cycle, and "low level" tools which support the programming and testing stages. The …rst generation of CASE tools is referred to as the Toolkit [3,4]. The second generation contains integrated systems in-tended for automating the entire software life cycle. These tools are referred to as the CASE WorkBench or Environment [4].
Rapidly growing complexity of objects and management processes with si-multaneous time reduction causes the necessity of designing dynamic decision support systems (DDSS) which refer to semiotic ones.
According to up-to-date classi…cation of software, DDSS are a class of inte-grated intelligent (expert) systems of a semiotic type, combining exact mathe-matical decision search methods with inexact, heuristic methods based on expert knowledge [5, 6].
Semiotic systems are applied for open (or incomplete and inconsistent) and dynamic problem domains, knowledge representation and decision making mod-els of which can be changed and corrected. For example, production rules (frag-ments of special semantic networks) can be added or deleted, the values of plausibility, certainty or probability factors may be also altered.
One of the basic problems at designing the semiotic systems is a choice of the suitable formal apparatus for description of a decision support process and a construction on its base of an adequate (correct) decision making model. As such apparatus the production systems are commonly used.
The semiotic model of a production type is formally de…ned by the collection of
< A; P; ST; P0; ST0; R1; R2; R; F >;
where A- the alphabet used for the description of states (state sets) of a problem domain;
P the initial (current) set of the production rules used for conversion of states;
ST the initial (current) set of the strategies of decision search on the basis of rules P ;
P0; ST0 the sets usable for updating the sets Pand ST;respectively; R1 the rules for selecting a decision strategy sti from ST ;
R2; R3 the rules for modi…cation of sets Pand ST during decision search,respectively; F - the rules for modi…cation of the semiotic model itself (extension of the
We consider that a semiotic type knowledge representation model is adequate to a problem domain (semantic correctness) if any state from an acceptable initial state set S0 is translated into a state from a goal state set Sg and the process of state conversion is …nite. Thus, the objective of this paper is to develop an intelligent repository and a hybrid model of a problem domain for semiotic systems based on two types of the paradigm: the knowledge engineering paradigm and the program engineering one.
The rest sections of the paper span the issues of peculiarities of intelligent CASE systems, the architecture of an intelligent repository and the hybrid prob-lem domain model of a CASE system. Peculiarities of intelligent CASE systems (Section 2) deal with issues of developing an intelligent repository of a CASE system that facilitates a process of creating up-to-date software in semiotic sys-tems. The architecture of an intelligent repository (Section 3) presents the principal components, the main of which is a knowledge base storing all infor-mation about software to be developed. The hybrid problem domain model of a CASE system (Section 4) focuses on developing a conceptual model and a formal one of a CASE problem domain. As a formal model there was proposed a logical model based on multilayer logic.
2. Peculiarities of Intelligent CASE Systems
The central unit of a CASE system is a repository (information base of a project), where information on existing software at all stages of its life cycle from the stage of a technical objective to that of maintenance is kept. The repository must support storage not only of existing program products but also di¤erent versions of these products or of changes that have been introduced.
At present there is a necessity of developing an intelligent repository that facilitates a process of creating up-to-date software in semiotic systems. The building of the intelligent repository has a number of advantages in comparison with the traditional approach to the repository development of both databases and database management systems, among which we can distinguish the follow-ing:
the opportunity to represent knowledge that constitutes a generalization of the experience accumulated in the course of software design and access to this knowledge in the course of software development;
the creation of new knowledge about existing software from knowledge represented in the repository which can help to a designer in building the repository;
the opportunity to obtain answers to questions relating to the states of existing software (for example, which software components have been de-signed and which have not, what kinds of errors have occurred etc.) and its environment (what kinds of failures have occurred in the hardware and software products, what kinds of emergencies etc.) which facilitates the software design procedure;
the opportunity to forecast the results of design operations;
the opportunity to "compress" the extensional component of the repos-itory as a result of obtaining extensions of relations and attributes by means of logical inference and procedures.
Let us consider the basic functions and components of an intelligent repos-itory [7]. The intelligent reposrepos-itory is a complex multifunctional component of a CASE system, functions of which are the following:
1) storing information about software to be designed at all stages of its life cycle;
2) updating information storing in a repository; 3) logical veri…cation of information consistency;
4) obtaining answers to questions about software at the process of its de-signing;
5) "intelligent adviser";
6) grouping and joint using descriptions on each applied system; 7) access control to information by means of names and passwords; 8) supporting versions of an applied systems;
9) generating reports.
In an intelligent repository there are functions that are absent in a traditional one. Such functions are 3, 4, 5 (marked by asterisk).
The function of logical veri…cation of information consistency must be im-plemented for any stage of software designing. Consistency assumes verifying an admissibility of entered data values and information compatibility in a repos-itory.
Function 4 is assigned to obtain answers to diverse types of queries at the process of software designing.
The function of an "intelligent adviser" is also used at the process of software designing namely under installation of a distributed CASE system for choosing its con…guration, satisfying requirements of software designers and under emer-gency situations to choose a new con…guration of a CASE system. When using this function at the process of software designing, one can distinguish the fol-lowing subfunctions:
predicting the results of project operations, i.e. an answer to a question "What will be if a current project operator is applied to some state of software to be developed?";
planning the project operations (a chain of project operations must being distinguished and its application to an original state of software to be developed leads to achieving a demanded project result);
control by a design process of software (this subfunction de…nes a queue of applying the operations and jobs under designing software, for example: "If the project operations i and j are executed then to execute the project operation k ".
These repository functions can be implemented in the result of applying project operations and jobs in a production model using forward, backward or mixed inference.
3. Architecture of an Intelligent Repository
Let us view the components of an intelligent repository. These components are a knowledge base (KB), an intelligent information search system (IISS), a help subsystem under software designing and auxiliary components.
For implementing functions of “an intelligent adviser” there is IISS in a repository structure. This structure contains also CASE knowledge about itself. A help component contains two subsystems: help in management by a process of software designing and supporting knowledge about software to be designed. Auxiliary components of an intelligent repository are: a subsystem of sup-porting di¤erent versions of program components, a subsystem of generating reports and project documentation and KB of repeatedly used program com-ponents satisfying the given requirements.
One of the central components of an intelligent repository is a KB, the structure of which is represented in Fig.1.
In the foundation of KB there is a formal model of the CASE problem domain. All formalized information about software to be developed is presented in a problem domain model of the CASE system.
For example, the problem domain of the CASE system for creating DDSS, in particular, the system of operative-dispatching monitoring and management of a nuclear station power block, consists of the following models: a model of software to be designed, a model of the user organization, a model of the observable (external) object and a monitoring system.
To maintain a problem domain model of a CASE system, there are a subsys-tem of modeling a problem domain and a subsyssubsys-tem of supporting data integrity and knowledge consistency. The subsystem of modeling a problem domain of a CASE system must provide updating/eliciting of information containing in a problem domain model, i.e. to add new objects (object classes, relations, at-tributes, axioms and inference rules), to delete obsolete ones, to change current ones, and to elicit information from a model at the design process of software.
A subsystem of supporting data integrity and knowledge consistency pro-vides a logical veri…cation of data and knowledge at each stage of the software life cycle.
A CASE repository contains hybrid information representation forms such as text, table, graphic, sound, video ones which can not be always formalized in a problem domain model.
To update/elicit such information there is used a subsystem of maintaining a non-formalized component of a problem domain of a CASE system that contains di¤erent forms of the object representation of a CASE problem domain.
4. Hybrid Problem Domain Model of a CASE System
Let us view the stages of building a hybrid model of a CASE problem domain. One can distinguish the following stages:
developing a conceptual model of a problem domain containing object classes, class representatives, di¤erent hierarchical structures, relations between object classes, attributes of object classes, diverse descriptions; developing a formal model of a problem domain containing a description of a conceptual model of a problem domain in the chosen language of knowl-edge representation, general laws (axioms) and mechanisms of knowlknowl-edge processing.
4.1 The Conceptual Model of a CASE Problem Domain
This model is multilayer one, each layer of which is to represent information needed for producing jobs at the corresponding stage of a software life cycle. The …rst layer of a conceptual model of a CASE problem domain stores information about software to be designed obtained at the analysis stage (analysis model ).
The second one stores information obtained at the design stage (design model ), the third layer - at the code stage and autonomous debugging (code model ), the fourth one - at the stage of complexing and testing (testing model ). At last, the …fth and sixth layers of a model store information needed to perform jobs connected with installation and maintenance of a system (installation and maintenance models).
For successful producing jobs at the whole stages of a software life cycle in a problem domain model of a CASE system there is the zero layer where information to control by a project (project management model ) is stored.
Brie‡y consider models of each layer for the CASE system of designing DDSS (CASE/DDSS) [2, 6, 8].
The analysis model consists of two submodels.
a) An user model containing a description of a problem domain of a program system to be designed and initial requirements to it. It is loaded jointly by soft-ware designers and users. A model contains object classes, class representatives, attributes and relations between classes.
b) An analyzer model in which system requirements to the system are set up. In this model there is de…ned "What" the system must make, there is described a partition of the system into logical components and there is set up interconnections between these components.
A design model is to present the program system to be developed at the second stage of a software life cycle. It contains the hierarchies of inheritance (IS-A) and subordination (Part-of) of object classes, a structure and interfaces of object classes, re…ned diagrams, designed information objects, their screen forms, tables of correspondence of information objects and screen forms.
A code model and autonomous debugging of program components of a system contains a list of errors that were discovered in a debugging process, test set, veri…cation methods.
A testing model includes testing methods.
Models of installation and maintenance contain the installation guid-ance, the user and operator ones, test examples.
In submodels of each layer three components are: intensional, extensional and procedure components of a CASE problem domain.
The intensional component of submodels contains information in the form of general laws and production rules that is used to design DDSS, for example,
the system of operative-dispatching monitoring and management of a nuclear station power block.
The extensional component of submodels contains the individual objects and relations between them, where the "Part of" structure relation may form a Part-of hierarchy on representatives of the classes.
The procedure component of submodels contains functions for computing the attributes, de…nitions of the extensions of relations and procedures that imple-ment operations on objects (relations and object classes), inference schemes and decision making algorithms.
4.2. The Formal Model of a CASE Problem Domain
The analysis and design stages of a conceptual model of a CASE problem domain are the most important ones since a price of errors at these stages is very great and the success of the whole software development depends on a correct performing of jobs at these stages. Therefore a formal model of a problem domain of the CASE system must be convenient to represent needed information obtained at the stages of analysis and design.
As a formal model of a CASE problem domain there is chosen a hybrid model that combines the "program engineering" paradigm and the "knowledge engineering" one [1, 2, 7, 8], i.e. an object-oriented approach and procedures, and a model for representing knowledge about a problem domain should be used in order to represent the formal description of the problem domain in the repository of the CASE system [7, 9].
We have been proposed that a logical model based on multilayer logic (MLL) developed by S.Ohsuga and H.Yamauchi should be used as a formalism for representing knowledge about a CASE problem domain [10, 11], since MML may be considered as the object-oriented, …rst-order predicate calculus that describes knowledge structuring and aggregation. On the other hand MLL may be viewed as an extension of multisorted logic (MSL) where the method of structuring sorts in the syntax and semantics of the logical language is introduced and the universe U is extended up to U [ 2U [10]. By means of such a structuring of sorts, it is possible to reduce the de…nition domain of a term and thereby, to increase the e¢ ciency of deductive inference.
Let us consider the basic relations that are speci…ed in MLL. Braces will be used as a metasymbol to represent an object set. So, d = fa1; a2; :::; ang is a set and bi= fa1i; a2i; :::; aimig is a subset of d. The following relations may be declared as basic ones [10] :
1)"Element-of" denotes x 2 X and it is the means of specifying the relation “element-set” asserting the following: the object x is an element of the set X.
2)"Power-set-of" is denoted by Y = X and it is the means of expressing the fact that Y is a set of subsets of the set X (not including the empty set). For example, if d = f1; 2; 3g, then d = ff1g; f2g; f3g; f1; 2g; f1; 3g; f2; 3g; f1; 2; 3gg. The cardinality j dj = 2N 1 where jdj = N. Since d is a set, the subset set of order 2 of d may be de…ned as ( d). This is denoted by2d. Thus, the subset set of order n;nd, is de…ned as ((n 1)
d). 3) "Product-set-of" is denoted by Y = X1 X2 ::: Xm or Y = m Y i=1 Xi and it is the means of expressing the fact that Y is the Cartesian product of X1; X2; :::; Xm.
4) "Component-of" is denoted by Y B X and expresses the fact that X is a component of Y . If Y contains several components, i.e. Y B X1; Y B X2; :::; Y B Xs, the special metasymbol < > is used as follows: < Y >= fX1; X2; :::; Xsg. Informally, Xi; i = 1; 2; :::; s ; constitutes a subset of elements of the same sort, each of which is a part of Y .
The basic relations (2) and (3) are special operators for generating new sorts from given ones .
Certain other relations may be de…ned through the composition of the basic relations, thus:
10) "Subset-of" is denoted by X Y and asserts that X is a subset of Y . This relation is a composition of the following two relations: Z= Y and X 2 Z, i.e. = 2 . The set-theoretic relation "subset-of" speci…es an IS-A hierarchy on the class set of objects of an application domain.
20) "Part of" is denoted by Y x and asserts that x is a part of Y . This relation is a composition of two relations: "Element-of" and "Component-of", i.e. =2 B. The relation "Part-of "is used to specify the "Part-of" hierarchy on a class set of objects of an application domain.
The hierarchical abstraction corresponding to the relation “Part-of”may be represented as shown in Fig.2. Such a representation of hierarchical abstraction is said to be the hierarchical structure [10] used to specify the “Part-of”hierarchy of representatives of classes in the extensional component of the repository.
Such representation of a hierarchical structure is a standard form in MLL. This structure consists of several layers. As in the hierarchical abstraction, the concept of a layer is based on the inheritance of properties. Object classes in a relation that inherit properties are arranged on di¤erent layers. So, object classes and their representatives linked together by the relation “Element-of”
are arranged on di¤erent layers, while object classes that are linked together by the relation “Component-of”are all on the same layer, since they do not exhibit any property inheritance.
The graphical forms for representing hierarchical abstraction and a hierar-chical structure are shown in Fig. 3 and Fig. 4, respectively. Fig. 3 shows the hierarchical abstraction corresponding to the IS-A hierarchy of object classes which is speci…ed in the intensional component of a repository whose lower layer corresponds to class representatives that are contained in the extensional component of the repository (database).
Fig.4. displays the hierarchical abstraction and hierarchical structure corre-sponding to the "Part-of" hierarchy of object classes and class representatives, which are speci…ed in the intensional and extensional components, respectively, of the repository.
The essential di¤erence between MLL and multisorted logic (MSL) lies in the way in which hierarchical abstraction and a hierarchical structure are repre-sented by the tools of a well-formed formula (WFF) set. MSL describes explicitly the relation “element-set” between objects in the WFF pre…x in the form x=d where x is an element of the set (sort) d.
To specify the hierarchical abstraction corresponding to the IS-A hierarchy in an application domain, MLL employs an extension of WFF representation. So, using MLL it is possible to work with sorts that constitute structured units, domain elements of which can be sets, subset sets and so on.
The tools of MSL are not su¢ cient to describe the hierarchical abstraction and the hierarchical structure corresponding to the Part-of hierarchy of object classes and the Part-of hierarchy of class representatives since this hierarchy constitutes an interaction of di¤erent sorts in the description of an application domain, whereas MSL treats sorts as individual, independent units. Moreover, MSL lacks tools, other than predicates, by means of which interaction between sorts could be described. Using the predicates to describe interaction between sorts complicates and encumbers the description of the application domain and reduces the e¢ ciency of deductive inference. Three types of special slash sym-bols have been introduced to specify the Part-of hierarchy in MLL [10].
A slash is called some delimiter used in the formula pre…x. So, the simple slash (Qx=X) is used to denote x is an element of the set X (x 2 X), the simple “bold” slash (Qx=X) designates x is de…ned on a set whose elements are the components of the object X (XB x), while the double slash (Qx==X) denotes x is de…ned on a set whose elements are parts of the object (Xx):
If an object Y has as a component an object X then, in order to de…ne the properties of an object x(x 2 X), we may write the following formula: (Q x:== # Y )G(x), where # denotes a constant; Q is either 8 or 9; G(x) is a predicate that describes the properties x or is an attribute. It is a standard form for MLL. If an object Y has several objects as components, as shown in Fig. 2, then in order to specify a desired component X of Y , a selector which is represented by the predicate F (X; Y ) [10], must be used. In this case, to determine the proper-ties of an element x 2 X that is a part of an object Y we may write the following formula: (9X=#Y )(Qx=X)[F (X; Y )&G(x)], which may be transformed to the standard form, thus: (Qx==#Y )[F (x; Y )&G(x)]:
By means of the formalism of specifying the structure relations in a formula pre…x, a selector that is represented by a predicate may be replaced by a pre…x composition, which may be considered as further development of this formal-ism. Since the selector is used to de…ne the required component Xiof an object Y , where < Y >= fX1; X2; : : : ; Xng, and since we may associate with every component Xi the domain (sort) to which, in turn, an object class of an appli-cation domain corresponds, the "class-subclass" relation between a component Xi and an object class of an application domain may be used to specify the component Xi. The "class-subclass" relation uniquely de…nes this component and is speci…ed in the formula pre…x by means of a simple slash. Let us view how to specify the structure relations with the help of an example.
The axiom set of a CASE application domain contains the assertion of the following type: "If the system x processes information concerning an object y, there exists a message ‡ow z1 that contains the class of messages z such that z describes y".
We may represent this assertion in the form of an MLL formula in the following way:
(8x=system)(8y=object)P rocesses_information(x; y) ! [(9z1=message_f low)(9z==z1)Describes(z; y)]:
The extended MLL syntax is represented [7,9,10]. This syntax extension concerns to the rule F 3(4) of designing WFF [9] (see below).
Alphabet:
1)a; b; c; : : :(constants) and X; Y; Z; : : :(constant sets); 2)variables:x; y; z; : : : ;
4)predicate symbols: P; Q; R; : : : ; 5)quanti…ers: 8; 9;
6)logical connectives: :; &; _; !;
7)auxiliary symbols: #; ; =; I; ==; f; g; (; ): Terms:
1)Any constant and any variable are terms.
2)If f is a n-ary functional symbol and t1; t2; : : : ; tnare terms, then f (t1; t2; : : : ; tn) is a term.
3)All terms are obtained by using (1) and (2).
The rules of designing WFF for extended MLL syntax are de…ned recur-sively as follows.
F 1: If P is a n-ary predicate symbol and t1; t2; : : : ; tnare terms,P (t1; t2; : : : ; tn) is a WFF.
F 2: If F and G are WFF, :F , F & G, F _ G, F ! G are WFF. F 3: If F is a WFF and x is an object variable then:
1)(8x=y)F and (9x=y)F are WFF where y is a constant or a variable (here = is an ordinary slash);
2)(8xIy)F and (9xIy)F are WFF where y is a constant or a variable (here I is a bold slash);
3) (8x==y)F and (9x==y)F are WFF where y is a constant or a variable (here // is a double slash);
4) (8(x=Z)==y)F and (9(x=Z)==y)F are WFF where y is a constant or a variable, Z is a constant set.
F 4. All WFF are obtained by applying F 1, F 2 and F 3.
One of the basic operations that must be implemented in the repository of an intelligent CASE system is deductive inference. It allows to de…ne the inde…-nite components of the intensional and extensional parts of the repository and to invoke components from a procedure part for determining the computable pred-icates. As the deductive inference engine must operate in an open application domain, it is necessary to foresee updating the system knowledge by:
entering new object classes; entering new relations;
entering new axioms and procedure components.
The inference algorithm for extended MLL syntax based on input linear resolution has been developed [7, 9, 10, 12].
5.Conclusions
We have considered a new approach to designing semiotic systems based on paradigms of "program engineering" and "knowledge engineering". As a proto-type of the semiotic system there was developed DDSS for operative dispatching monitoring and management of a nuclear station power block and, in particular, its subsystems for monitoring and management of the main circulating pump, capacitor and ejector plant [6].
This prototype was implemented on the basis of the tools G2+GDA (GDA-G2 Diagnostic Assistant) [13, 14]. The choice of this tools is caused by inte-gration in it of basic high-performance technologies of complex program prod-uct development: object-oriented programming; open system technology and client-server one; the active object graphics; structured natural language and hypertext for information representation; dynamic (imitative) models; parallel ful…llment in real time of independent processes; the friendly interface with var-ious types of the users. Using intelligent CASE technology allowed to automate the stages of software designing, especially, the initial stages of the software life cycle: analysis and design stages.
The structure of base tools G2+GDA consists of the interactive editor, tools of the graphic interface with an user, object-oriented graphics, graphic real-time monitoring windows and animation tools for display of connections between ob-jects, interaction with external environment, imitative modeling and processing, tools for messages and explanations.
References
1. Peter A. Ng, Raymond T. Yeh. Van-Nostrand Reinholds (1990): Modern Software Engineering. Foundation and Current Perspectives, New York, 591 p.
2. J.E.Cooling.(1991): Software Design for Real-time Systems., Chapman and Hall (University and Professional Division), 505 p.
3. Hakkrainen K., Ihme T., Metcalfe M. Prospex (1989): Knowledge-Based CASE Tool, Scandinavian Conference on Arti…cial Intelligence-89: Proceedings of the SCAI’89, pp.255-266.
5. Vagin V.N., Yeremeyev A.P.(1997): Implementing a Conception of Distributed Arti…cial Intelligence and Multiagent Systems in Decision Support Systems Based on the Tools G2+GDA, Proc. of the Intern.Workshop "Distributed Arti…cial Intelligence and Multi-Agent Systems", DAIMAS’97, June 15-18, St.Petersburg, Russia, pp. 262-268.
6. Vagin V.N., Yeremeyev A.P. (1999): Designing the Dynamic Decision Support Systems of a Semiotic Type. Proc. of the 1999 IEEE International Symposium on Intelligent Control Systems / Intelligent Systems and Semiotics. Cambridge MA, Sept. 15-17, pp. 296-301.
7. Vagin V.N., Viktorova N.P., Golovrina E.Yu.(1995): Multilayer Logic as a Knowl-edge Representation Model in the CASE System., Journal of Computer and Systems Sciences International, vol.33, No3, pp. 72-83.
8. Harel D.(1990): et al. Statemate: A Working Environment for the Development of Complex Reactive Systems., IEEE Transactions on Software Engineering, vol.16, No 4, April, pp.403-413.
9. Vagin V.N., Golovina E. Yu. (1997): Knowledge Representation Language in Semiotic Systems., Proceedings of the 1997 International Conference on Intelligent Systems and Semiotics: A Learning Perspective, ISA’97. Gaithersburg, MD. Sept.22-25, pp.50-53.
10. Ohsuga S.Yamauchi H. (1985): Multi-layer Logic- a Predicate Logic Including Data Structure as Knowledge Representation Language, New Generation Computing, vol.3 No 4, pp.451-485.
11. Ohsuga S. (1989): Toward Intelligent CAD Systems. Computer Aided Design, Vol.21, No 5, pp.315-337.
12. Vagin V.N (1988): Deduction and Generalization in Decision Making Systems, Nauka, Moscow,363 p. (in Russian)
13. G2 Reference Manual Version 4.0 (1993): Gensym Corp., Cambridge, Massa-chusetts, 1451 p.
14. GDA Reference Manual Version 4.0 (1993): Gensym Corp., Cambridge, Massa-chusetts, 467 p.
