Sie sind auf Seite 1von 19

Coffee Cooking Tips Recipes & Food and Drink Wine & Spirits Elder Care Babies &

Toddler Pregnancy Acne Aerobics & Cardio Alternative Medicine Beauty Tips Depression Diabetes Exercise & Fitness Hair Loss Medicine Meditation Muscle Building & Bodybuilding Nutrition Nutritional Supplements Weight Loss Yoga Martial Arts Finding Happiness Inspirational Breast Cancer Mesothelioma & Cancer Fitness Equipment Nutritional Supplements Weight Loss

Affiliate Revenue Blogging, RSS & Feeds Domain Name E-Book E-commerce Email Marketing Ezine Marketing Ezine Publishing Forums & Boards Internet Marketing Online Auction Search Engine Optimization Spam Blocking Streaming Audio & Online Music Traffic Building Video Streaming Web Design Web Development Web Hosting Web Site Promotion Broadband Internet VOIP Computer Hardware Data Recovery & Backup Internet Security Software

Advertising Branding Business Management Business Ethics Careers, Jobs & Employment Customer Service Marketing Networking Network Marketing Pay-Per-Click Advertising Presentation Public Relations Sales Sales Management Sales Telemarketing Sales Training Small Business Strategic Planning Entrepreneur Negotiation Tips Team Building Top Quick Tips Book Marketing Leadership Positive Attitude Tips Goal Setting Innovation Success Time Management Public Speaking Get Organized - Organization

Credit Currency Trading Debt Consolidation Debt Relief Loan Insurance Investing Mortgage Refinance Personal Finance Real Estate Taxes Stocks & Mutual Fund Structured Settlements Leases & Leasing Wealth Building Home Security

Mobile & Cell Phone Video Conferencing Satellite TV Dating Relationships Game Casino & Gambling Humor & Entertainment Music & MP3 Photography Golf Attraction Motorcycle Fashion & Style Crafts & Hobbies Home Improvement Interior Design & Decorating Landscaping & Gardening Pets Marriage & Wedding Holiday Fishing Aviation & Flying Cruising & Sailing Outdoors Vacation Rental

Book Reviews College & University Psychology Science Articles Religion Personal Technology Humanities Language Philosophy Poetry Book Reviews Medicine Coaching Creativity Dealing with Grief & Loss Motivation Spirituality Stress Management Article Writing Writing Political Copywriting Parenting Divorce

Compurers & StrucruresVol. 63, No. 5, pp. 1015-1032, 1997 0 1997 ElscxierSciena Ltd. All tights reserved

PII: sow-7949(%)00247-7

Printedin Great Britain


0045-7949197 Sl7.Otl-k 0.00

COMPENDIUM ENGINEERING DESIGN KNOWLEDGE REPRESENTATION BASED ON LOGIC AND OBJECTS


J. Bento,t$ B. Feij&@ and D. L. Smitht t Department of Civil Engineering, Instituto Superior TQnico, Technical University of Lisbon, Av.
Rovisco Pais, 1096 Lisboa Codex, Portugal Laboratory, Imperial College of Science, Technology and Medicine, University of London, Imperial College Road, London SW3 2BU, U.K. 5 ICAD-Intelligent CAD Laboratory, Department of Computer Science, Pontificia Universidade Catblica do Rio de Janeiro, Rua Marques de S%o Vicente, 225, CEP 22453, Rio de Janeiro, RJ, Brazil $ Expert
Systems

(Received 4 March 1994)

Abstract-This paper presents a hybrid framework to integrate first-order logic into the object-oriented paradigm for representing engineering design knowledge. The object-oriented nature of engineering design activities are analysed and details of the programming environment are provided. 0 1997 Elsevier Science

Ltd.

1.

INTRODUCIION

The hierarchical o:rganization of structural engineering objects is inherent to the structural engineering design activity. The following object-oriented concepts can be found in this kind of activity: (a) the aggregation of structural engineering objects from other structural engineering objects, i.e. some objects have parts which are themselves other objects-a framed-building has a roof, a system of foundations, walls, etc.; (b) the zsharing of properties amongst a number of similar objects defining classes of objects-all framed-buildings have a number of common properties; and (c) the inheritance of properties from more abstract objects to more concrete ones (e.g. a framed building is a building, that is it inherits all typical building properties). In the context of proposing a framework for building ICAD (intelligent CAD) systems in structural steel design, the present paper proposes a knowledge representation scheme and a programming environment capable of addressing the objectoriented aspects above mentioned. The programming environment incorporates first-order logic into the object-oriented paradigm. The main motivation of the present work is related to the fact that a previous and strict commitment to logic as a programming paradigm, and especially as a knowledge repressentation formalism in a design environment [ 11, has revealed some deficiencies, namely when the explicit representation of design objects is under consideration. Furthermore, it being thoroughly accepted1 that first-order logic provides the most robust and efficient model of deductive thought, it is then indisputable that logical deduction

merely covers one aspect (possibly not even predominant) of human thought. Reference [2], while discoursing about the appropriateness of first-order logic for representing design models, stresses that embracing different aspects of cognitive emulation is a vital nexus to reality and suggests the use of frames in addition to logic. In fact, it is widely accepted, even by strong defendants of logic programming [3], that some features present in object-oriented programming systems, which are of interest to design knowledge representation, are lacking in logic programming languages. Most man-made artifacts are fully or partially of a hierarchical nature (frequently induced by a bottomup construction process), and many types of design automation applications require a data structure which is naturally related with real world objects. This argument is especially important in the presence of CAD systems for architectural, civil or mechanical engineering design, in which geometric modelling is either a main concern or an essential requirement. Furthermore, as previously identified [4], features of object-oriented languages seem to be of value for representing design characteristics in a formal model of the design process. Still in a (structural) design context, other writers seem to have identified a need for object-oriented features to be present in design automation systems. Notably Refs [3] or [5] refer to its use as a vehicle for the inclusion of geometric reasoning features in ICAD systems by incorporating and integrating existing software; a more in-depth treatment is given by Refs [6] and [7] in the solutions they explore for assimiliating geometric reasoning capabilities into

1015

1016

Compendium The relation (2) would then become, if described intensionally,


relation

Extensional descriptions involve a larger number of simpler assertions. In the given example (I), a total of nine assertions making use of as many as eight relations were used to describe the properties of beam Bl; a single relation (4) would be enough to describe the very same piece of knowledge if use were to be made of an intensional description method. Nevertheless, the extra amount of wording of extensional descriptions facilitates an extremely easy procedure for modifying the properties of entities described in that way: adding or deleting properties is just a matter of asserting or retracting facts. Another positive facet of extensional descriptions, 2. KNOWLEDGE ABOUT DESIGN OBJECTS in the context of design knowledge bases, is that In the design process, one often needs to refer to different views of the same design entity may be easily defined by picking only those facts which are of entities characterized by having both physical and relevance for the view in question (e.g. a beam may functional attributes, as well as to relationships among those entities, e.g. structural elements, in a be viewed from a structural analysis perspective or from that of quantity surveying, situations in which structural design process. The basic notational different properties are used to describe the same dilemma in describing those entities and relations entity). Contrarily, in the case where an intensional consists in whether to use an extensional or an description has been used, adding the cross_section intensional description [ 121. If extensionally describproperty requires the complete redefinition of the ing the properties of a beam, say B 1, one could use beam predicate already defined by eqn (4). Furtherthe following representation, borrowing a notational more, providing support for multiple views on the convention from predicate calculus: basis of intensional descriptions of knowledge requires the development of a totally different and beam (Bl) alternative scheme. Nevertheless, is important to span (BL L) stress that the higher flexibility of extensional height (Bl H) representations also bears a performance drawback: width (Bl W) a larger number of assertions have to be processed. material (Bl steel) The same set of reasons explains why the lower left-node (Bl N) flexibility of intensional representations may be right-node (Bl M) compensated by a much better retrieval and greater node (N) computational efficiency. node (M) (1) The authors share the opinion expressed by the group Bart Veth [l l] that logic programming, a If a column entity, say Cl, were to be similarly formalism extremely well adapted to representing defined, one could express extensionally an adjacency knowledge extensionally, is a preferable tool for relationship as follows: describing and manipulating that kind of design knowledge which is expected to be subjected to next-to (Bl Cl) . (2) frequent changes throughout the design process. For the same reasons, objects may be used to describe If, conversely, an intensional description were to be those other pieces of knowledge whose structure is adopted, beams could be represented by means of a less likely to change in the course of the design process, but which may be subjected to changes at an single assertion, attribute value level, e.g. in a structural design context, structural elements, whose components and beam (name span height properties in general are fixed, but have variable width material values. left-node right-node). (3) The flexibility-performance issues raised about the two above-mentioned representation schemes may be which, for the case of Bl, would lead to seen as a notation problem with consequences at a knowledge representation level. It has also been a beam (Bl L H W steel N M). (4) concern of other authors; for example, Charniack

CAD systems. Garrett [8] also explores the use of object-oriented programming in production system as a means to achieve better rule-based inference mechanisms, and the same paradigm is used in developing a data structure which is able to be used by different participants in the design of buildings (e.g. agents related with architectural design, structural design, HVAC design, etc.) [9]. Finally, references are due to the PBASE proposal [lo] and the IDDL concept by the group Bart Veth [l 11,which seek to promote the integration of object-oriented characteristics with predicate logic; they have the specific aim of creating a better representational language for knowledge about entities, attributes of entities and relationships between entities, all present in design processes.

(Bl next-to

Cl).

(5)

Compendium

1017

and McDermott [ 131 adopt a similar approach when describing what they call a slot-assertion notation (extensional) vs an alternative frame or slot-and-filler one (intensional). Again, they claim that frame notations are better (while more efficient) if new pieces of information are not intended to be added or removed very often. In the specific context of logic programming, McCabe [3] also identifies two complementary ways of representing data: by using assertions (the assertional or database view) and by using terms (an alternative for dealing with more structured and homogeneous types of information). One may be tempted to agree with those who argue that the use of lasgic is best suited to organizing knowledge which varies with the evolution of the design process, whereas objects are best for those less flexible entities present in modelling design processes and design objects Ill]. However, it must follow that hybrid solutions are also possible, and probably better, in situations where the above separation is not sufficiently clear. In agreement with that, the authors propose a scheme where flexibility and performance are combined to form what is judged to be a better balanced situation, by employing, in a hybrid environment, pred:icate logic and objects with a variable structure, i e. whose modification-addition, deletion or alteration of properties--does not imply a full redefinition. Making use of the proposed framework, different entities may be represented by using objects, logic or both, whichever shows most appropriateness.

/L
% I Fig. 1. Representation

objects name parent objects name

indicate objects properties

of a cross secrion object.

3. OBJECT-ORIENTED

REPRESENTATIONS

3.1. Basic characteristics A simple definition of objects may involve an abstract data structure in which data and procedures about the entities being modelled are kept together. There are three ksey characteristics inherent in any object-oriented programming environment:
l

area may be defined as a function having the width and the depth as arguments: area(width,depth)= width x depth. A typical feature of most object-oriented programming environments is data abstraction. Data abstraction, or information hiding, is achieved by forbidding external entities to access directly (or even know) the internal structure of an object, i.e. the access to the internal data of an object presumes the invocation of its methods. Moreover, the invocation of a method should not presuppose any further knowledge about the details of its internal implementation. In this context, the set of properties that does not belong to the internal structure of an object is called the public part. Another key characteristic present in object-oriented programming environments relies on the possibility of creating different objects as instances of predefined classes and of accessing those classes data and methods. Furthermore, those instances tiay be specialized by addition of new properties or by overriding existing ones (modifying or removing them). Hence, developing object-oriented applications should start by the definition of general classes-containing attributes, attribute values and methods common to a number of objects-from which such objects may be instantiated and specialized. Figure 2 illustrates an Z_larninated_section prototype/class, as well as an object derived from it: 1PE_550. Subclasses are defined when derived objects themselves contain properties (static attributes and methods) which are common to a number of other objects. Such an approach allows for the establishment of a hierarchy of classes and subclasses, i.e. a

the ability to (define prototypes or classes of objects which have to include their own data (values of attributes) and methods; the ability to create different objects via a comparative method-instances of predefined classes created by specialization of those classes-and of accessing data and methods from them; the ability for sub-classes to inherit data and methods from ancestor classes, extending or restricting them locally.

Figure 1 shows an object that represents the concept of a cross section. In this example, the area is not explicitly stored as a static attribute value and may be computed from other attribute values. Object properties which involve computations are generally referred to as methods. In this context, the property

(a)
Fig. 2. (a) Class-as-prototype;

(b)
(b) derived object.

1018
IWliW

parents name J, Value


attributes

methods

L
Fig. 3. Property inheritance between two objects. child is derived from its ancestor classes. The of descriptions between classes, is clearly increased by providing multiple inheritance. While inheritance of properties from a single direct ancestor (parent) defines a class hierarchy represented by a tree, multiple inheritance, as exemplified above, establishes a class hierarchy representable by a more general graph structure, usually a directed acyclic graph (Fig. 4 may be used for comparing both). This kind of class hierarchy may exhibit an important expressive power, namely in situations where the describing of objects with a component-subcomponent structure is at issue (such as in geometric modelling or structural design knowledge representation, for example). However, multiple inheritance poses some problems, especially at the implementation level. The most relevant problem concerns decision criteria for dealing with an objects attribute when that attribute has not been locally defined (explicitly within the object), but more than one attribute with the same name may have been inherited from different parents. Different implementations have followed from different methodologies for facing multiple inheritance. In some systems, the multiple occurrence of homonymous attributes in different ancestors of an object prevents the possibility of (multiple) inheritance at all [14]; some systems assume that no single criterion for multiple inheritance may reasonably be applied in every situation, imposing therefore that, whenever a multiple inheritance conflict emerges, the

I_luminated_section object of Fig. 2a, from which

IPE_550 is derived, constitutes an example of a subclass of the cross_section class depicted earlier in Fig. 1. One of the most relevant consequences of structuring knowledge using objects is that it leads to a great economy of expression, avoiding redundancy of explicit information, by the use of inheritance as a mechanism for information elision. Accordingly, child classes, as well as derived (child) objects, inherit properties from their ancestors, in terms of attributes, attribute values or methods, with some possible local updating (through addition or modification). Different kinds of inheritance may be propagated independently, such as attribute values, properties and methods (Fig. 3). Another interesting feature about inheritance is that it stands as a vehicle for finding information, even when it is not in the place where information is first looked for [14]. Also, inheritance forms an important vehicle for providing, if not a default reasoning mechanism then at least for the use of default values. 3.2. Multiple inheritance A situation of multiple inheritance is found when an object is derived from more than one direct ancestor. The economy of expression arising from elision through inheritance and consequently sharing

(a)

(b)

Fig. 4. (a) Directed acyclic graph of structural components; (b) equivalent tree representation

Compendium

1019

user must explicitly identify which attribute to use or which method to apply [15, 161; some systems have predefined ancestry graph search criteria which, in the case of the competitive occurrence of inheritable attributes or methods, leads to the choice of the first found by the search procedure [17, 181. Usually the search is then related to the order of declaration of the ancestors. Approaches to multiple inheritance which are not associated with the establishment of an inheritance precedence relation, such as in the case of logic programming languages, are said to lead to less severe situations when this problem arises; this is due to the fact that, in logic programming, backtracking takes care of searching for all possible methods and selecting the appropriate ones [3]. In fact, the authors sustain that also in a logic programming language, the order of declaration of the ancestors, or at least the order in which the ancestors and their attributes and methods are ar,serted, is relevant for this matter: they are caught by the backtracking process in that very same order. Zaniolo [19] seems to corroborate this opinion in his introductory work. The developer of object-oriented knowledge-based systems, which rely on multiple inheritance capabilities, has to carefully address this problem, as unpleasant results may occur due to unexpected consequences resulting from unpredictable inheritance. Some authors even argue that it is often preferable to restrict inheritance to a single source [3, 141. Nevertheless, most situations in which multiple inheritance seems an essential feature are indeed avoidable. In general, directed acyclic graph (DAG) structures may be alternatively associated with simpler ones such as trees. Foley et al. [20] address this problem with describing a part-of hierarchy of robot components in which a DAG is replaced by a tree by actually multiplying the objects with multiple occurrences. This solution, being safer, may also be said to be less elegant; moreover it leads to a duplication of information. In the example of Fig. 4, not only does an extra class need to be defined for the latter case, but also it will contain unnecessarily duplicated explicit information, such as the ultimate_plastic_momerrt, axial-capacity and Eulers_critical_Ioad attributes or methods, which may be already present in either beam or column classes. 3.3. inheritance owrriding (exceptions) Inheritance overriding is an essential ability of object-oriented envi:ronments which aim to represent exceptions (as well as defaults) in a natural manner. A trival though paradigmatic example of this kind of situation is the ostrich (penguin, chicken, etc.tbird problem. It is an acceptable common-sense notion that birds fly besides having feathers, beak, and so on; hence it would seem advisable to include the attribute of flight property in ,a class definition for representing birds. However, ostriches are also birds, despite their

Fig. 5. Birds and ostriches: inheritance overriding.

not being able to fly. An exception handling mechanism then becomes a required feature so that in looking up the properties of ostriches, a wrong conclusion may not be reached about their flying properties, as a consequence of the local absence of a flying attribute, followed by inheritance from the bird class (Fig. 5). Some approaches to object-oriented logic programming have not been able to cope elegantly with the inheritance overriding problem; OBLOG is such an example [21]. However, repeating what has been argued for the case of multiple inheritance, languages which are not prepared to handle inheritance overriding may simply avoid it; that can be achieved by designing alternative taxonomies of classes and objects for the domain of knowledge in question. Typical of such situations is the ostrich-bird example: birds may be divided into two sub-classes-flying-birds and non-flying ones, inheriting properties other than flying from a common superclass. Zaniolo has also chosen a birds example in his introductory work to object-oriented programming in Prolog. Curiously, despite the capability for dealing with inheritance overriding shown by his proposal, he advocates that emphasis in tackling this kind of situation should be placed around the database organization, an opinion which the authors entirely endorse. 3.4. Message passing For an external entity, such as an object or an interactive user, to communicate with another object it is necessary to send it a message. Messages must be understandable to the recipient object, which selects an appropriate method, if any, to answer it. Objects may communicate among each other only by the sending of messages. A simple example of a message is a retrieval command which returns the value of an objects static attribute.
(depth of section_Sl (x)

) ?

(6)

which assumes the existence of a depth property in the object sectionS1; such a property being a static value, the interpretation of the message corresponds to returning the value of the sections depth through the variable x. In the more general case that the objects property referred to by the message is a method, the recipient

1020

Compendium

object responds by performing the procedure it defines; such a response may result in the sending of messages to other subjects. Computation achieved by means of such an inter-object message-passing mechanism, is usually classified as event-driven. Thus object-oriented programming emerges as an ideal programming paradigm to cope with discrete event simulation. As noticed by Garrett [8] such an event-driven nature is difficult to achieve in a monotonic pure rule-based environment. Furthermore, it is interesting to observe that enriching a traditional procedural language with object-oriented characteristics introduces some new inference capabilities through inheritance and valueclass cardinality checking. In that sense, the present work is concerned with increasing the expressive and inferential power of logic through those capabilities.
4. A HYBRID APPROACH TO LOGIC AND OBJECTS

established between the two components, required. 5. THE


STRUCTURE OF AN XLOG +

whenever

OBJECT

An XLOG + object may be recursively defined as being an entity identified by a name, having or not a number of parent objects and containing or not a coherent set of properties defined as attributes (explicit ones if locally described, or implicit ones if inherited); attributes may possibly have a value and two special kinds of annotations called attached predicates, eqn (7). The syntax is the following: {name (parenti, {attributet
parentj,_)

(value), (if-needed), (if-changed)] I, i-1 I (7)

The present work follows an approach aiming at incorporating object-oriented capabilities into an environment based on logic and suitable for representing engineering design knowledge. Although radically different, this approach is in its principles aligned with the kernel idea of Gordons OBLOG proposal: to combine the frame [22] and logic paradigms in order to achieve an even higher order of abstraction in knowledge representation. Contrarily, there is no special commitment to preserving fully the semantics of logic. This attitude is based on the pragmatic assumption that the extra care required in formalizing and using knowledge by means of extra-logical methods may be compensated by the improved efficiency of real object-oriented capabilities, e.g. inheritance built into the objects structure vs inheritance obtained through logical deduction. With respect to general guidelines, the present work also draws on the less formal proposal of Parsaye and Chignell[14]: to develop a system capable of taking advantage of the robustness and natural deductive properties of logic, extending it with the packaging and built-in inheritance capabilities of objects. The proposed approach was built upon XLOG, an environment for programming in logic and for building expert systems [ 1,2,23]. The resulting extended environment, enriched with object-oriented capabilities, will be referred to hereinafter at XLOG + . Objects and first-order logic clauses (non-Horn clauses) coexist in XLOG + . In other words, logical sentences in XLOG programs may include references to XLOG + objects and vice versa. Figure 6 attempts to depict the somewhat independent and yet cooperative presence of first-order logic clauses and objects in the XLOG + hybrid environment: an objects database may be defined in an imaginary orthogonal plane to that of the clauses database; links occurring at the level of issued messages are then

For instance, a roof_beam_A object may be described by the following expression: 1 roof-beam-A {beam, columns {material[(steel,)l}, flength(9.Um)l), c-1, iweightfl 1 I

(8)

Attributes may be described as having a meaning similar to that of slots in the frame theory. As repeatedly mentioned above, they denote object properties. Properties may be formally defined as an association of an attribute with an attribute value, and attributes are, in turn, any characteristic (frequently of a physical nature) to which a value may be assigned, thus defining its state. In conformance with the aforementioned, attributes, as defined in XLOG + objects, should always have a name and a value, their main purpose being to store data. In XLOG + , in addition to working as containers of data, attributes may also have attached to them a specific type of annotation which appears in the form of predicate names referring to so called attached procedures. The main purposes of those procedures are: (1) to behave as functions (methods, in object-oriented terminology); and (2) to define constraints affecting assignment or retrieval of attribute values. In XLOG + , attribute values may be assigned to character strings, as well as to integer or real numbers. For simple examples of attribute values, see Fig. 3. A kind of attribute value which has a deeper significance in XLOG + is a string denoting the name of another object. Attribute values carrying this special meaning are called, in XLOG + , object references. They are used in order to indicate that a

1021

1022

Compendium methods, or through specialization from ancestor objects (prototypes/classes). In the latter situation, explicit declaration of attributes, attribute values or attached predicates is only required for object properties which extend or override properties of their ancestors. As for the common set of properties between a derived object (or class) and its ancestors, they are automatically associated with the object at creation. However, such automatic inheritance behaviour does not imply that objects created through specialization of ancestor classes do actually possess the same local attributes, with values and attached predicates, redundantly multiplying the amount of explicit information and storage space required. In fact, the internal structure of XLOG + objects avoids the explicit storage of inherited properties. This characteristic is not common to other systems for which, as in XLOG + , real classes are not defined [27].
6. INHERITANCE IN XLOG +

particular attribute of an object is itself another object; in other words, it stands as a means to establish part-of relationships and to build composite objects (Section 10). Within XLOG + , because objects are considered as embedded in a general logic programming environment, attached procedures are invoked by means of attached logic predicates. For that reason, they can be understood as a logic interpretation of the meaning of an attribute [21]. Moreover, due to the extra-logical nature of XLOG, in which a hybrid logic/procedural programming environment is available through the use of built-in predicates, computation with attached procedures may also be achieved by means of procedures in imperative programming languages such as C [24]. Property annotation by means of attached predicates is used for the purpose of triggering procedures on variable access, drawing on the style of active values and access-oriented programming techniques [l&25]. Two special types of predicates may be attached to attributes of an XLOG + object: if-needed and if-changed. The obvious meaning of each declaration is linked with the firing timing for its evaluation-execution. In a manner similar to that of frame based programming environments, if-needed predicates are declared to be evaluated before an attribute values is tentatively retrieved. Oppositely, if-changed predicates are defined as goals to be proved in the case of an attribute value being tentatively changed-once more, before assertion of the attribute value takes place. The latter play a role identical to OBLOG and IDDL constrains [21,26]; they behave like watchdogs of the attributes to which they are attached. The use of attached predicates is also of utmost relevance for the implementation of methods in XLOG + , as fully described in Section 8. In XLOG + , there is no clear distinction between classes and objects; it is then unnecessary to define the latter as instances of the former. The term class should be rather understood in the context of XLOG + as prototype, i.e. every object in XLOG + may be interpreted as a typical member of the abstract class it represents. The closest an XLOG + prototype object can come to providing a typical class definition is when it serves to define an aggregation of properties-attributes and methods-for which no values have been associated with. The I_laminated_section of Fig. 2 illustrates an example of such a prototype/class situation. It should be remarked that, as a consequence of the uniform approach undertaken, the creation of such a class or such an object is accomplished in XLOG + by virtue of the same procedure (see Section 11). Prototyping may then be said to drive object creation in XLOG + . As in most other object-oriented environments, XLOG + objects are created either from scratch, i.e. with the explicit creation of its attributes and

In the case of XLOG + , inheritance has to cover attributes names, values and attached predicates (and, through them, methods). In the conceived environment, inheritance of properties is automatically achieved by means of the objects internal structure and, therefore, is not required to be explicitly declared (i.e. programmed). As a consequence, the declaration of an object as a derivation of its ancestor(s)-implicitly defining an is-a relationship--automatically ensures inheritance of their properties. The algorithm implementing the built-in inheritance of XLOG + objects may be generally described by means of a simple example. When a retrieval operation is attempted from an objects attribute (i.e. if a retrieving message is issued, thus firing a retrieval method) the following procedure develops: (i) tnhetexistence of the attribute itself is checked (ii) if an appropriate attribute is locally available and has a value, that value is then retrieved (subject, of course, to the successful logical evaluation of any if-needed predicate attached to the attribute); (iii) in the case of no local availability of such an attribute (or if it has no value), its ancestors are searched (at run time), until either a value is found for the same attribute in one of its ancestors, or the ancestry lattice is unsuccessfully exhausted (Section 5.1 contains more detailed information on the retrieval of attribute values). In the example of Fig. 3, the IPE_550 object inherits the material attribute and value from its parent-I_laminated_section-but the depth at-

Compendium tribute, which is also inherited, has its value defmed locally. It would then suffice to define a local value for depth, width, e:tc., with no mention to material:

1023

The approach undertaken of favouring the firstly declared parents along the search process was based on the assumption that, in most cases of design knowledge representation, objects do not need to rely {IPE_550 (I_laminated_section) upon multiple inheritance; networks of objects will fdepth[(500mm)]), mostly consist, then, of trees of objects with a single (width[(2lOmm)]}, immediate parent (Fig. 7~). Most of the exploratory work preceding the current implementation has f_), 1 (9) confirmed the validity of this hypothesis. Therefore, for the case of knowledge bases containing those As previously discussed (Section 3.1), a situation of expected types of objects, one covers the search space conflict may arise in the presence of multiple better by using a depth-first search criterion inheritance when more than one attribute (or (degenerating to a depth-only one for a situation method) is eligible for inheritance by a child object. allowing only a single parent to be declared). Moreover, because inheritance of attributes and An additional advantage of the adopted approach, although marginal at this stage, is that it facilitates an methods is achieved in XLOG + at runtime and the inheritance process stops as soon as a satisfactory eventual implementation of a precedence list criterion, i.e. one by which objects would be allowed to candidate (attribute or method) is found, a search declare weighted parents, with the heavier ones criterion needs to he enforced in order to establish taking precedence along the inheritance search how to traverse the ancestry lattice, i.e. how to produce ancestors in a topological order. process. Enablement would consist in no more than performing a reordering of the target objects list of The criterion ad.opted in the current implemenparents, by switching the heavier ones to the left-hand tation of XLOG + may be defined as a depth-first/ left-right one: the leftmost parent in the objects list side of the list, keeping the adopted search criterion unaltered. of parents is checked first (step 1 in Fig. 7a), its first Tomiyama [28], while exploring the approriateness parent afterwards (step 2 in Fig. 7a), and so on, until either the attribute/method in question is found or a of object-oriented languages for the development of ICAD systems, has claimed that, among some other root object (an object with no parents) is reached problems, the automatic inheritance of methods and (step 3, Fig. 7a); in that case, search resumes at the variables does not fit the principle of information next leftmost parent of the child of that root object hiding, which is of particular importance in the case (step 4, Fig. 7a), continues through its first parent and of superclasses being mostly alien to subclasses. so on and so forth (Fig. 7a). Nonetheless, in agreement with the indispensability Some alternative search criteria have been considered, either by actual experimentation or by of having means for representing is-a hierarchies he subscribes to the use of a selective inheritance investigating how similar situations have been dealt mechanism such as delegation, a proposal previously with in other systems also supporting multiple formulated in Ref. [7] in the context of design inheritance. Stefik and Bobrow [27] claimed that modelling. Delegation consists basically of an object experimentation with precedence relationships in an inheritance context was an open issue at the time of delegating only within the class it belongs to, i.e. their paper, in the sense that no solution would be automatic inheritance that ceases at the first level above the object in its ancestry tree-lattice; in the case good enough for all situations. The authors believe of an object being also a member of another class, that this remains true, but that preferable solutions such an explicit declaration is required. may, indeed must, be found for specific purposes. A most obvious one would have been first to exhaust However, there is no evidence of the vital importance of data hiding through strict encapsulathe target objects li:st of parents, and only then, if still tion in the context of design knowledge represenrequired, proceed upwards in a breadth-first/lefttation. Moreover, as remarked by Stefik and right manner (Fig. 7b).

9
1 4

!!

:.,..i q

(a)

:zt
:...: : : :.,..: ..

7 : .,~ i

, - . ..
I

2.

I._

(4

object rootobject

Fig. 7. Criteria for search related to multiple inheritance.

1024

Compendium

Bobrow [27], encapsulation, when found to be a fundamental issue, may be made by convention, i.e. the program or knowledge-base developer may restrain objects from directly accessing attribute values of other objects. The authors also endorse their claim that allowing direct access to object variables is a major necessity for knowledge representation purposes, e.g. for comparing two objects or attributes from two different objects. Despite advocating that the corruption of the principle of information hiding is not a major issue in design knowledge bases, the authors have adopted an approach which allows an object not to inherit any particular method or attribute from any of its ancestors. Moreover, the ability to override inheritance is also required for dealing with exceptions. Inheritance is overridden in XLOG + by the explicit local inclusion of a specific method or attribute, with a null or non-null value. Search for a value or method in the ancestry tree is then prevented by the simple local occurrence of the attribute(s)/ method(s) in question.
7. QUERYING AS MESSAGE PASSING

Fig. 8. XLOG

objects store no more of their attached predicates than the names.

Querying the knowledge base by means of the set of built-in predicates which operate upon objects leads to logical deduction with predictable side effect operations upon the objects defined. This draws on the message passing interpretation of logic referred to by McCabe [3] in his class template notation proposal. A sub-set of XLOG + built-in predicates provided to deal specifically with objects is given in Section 11.

Messages are passed to objects in XLOG + by means of direct queries, i.e. messages which are interactively issued to the object as logical queries, or by the inclusion of object or attribute references in clauses of the knowledge base. Messages may then be said to establish links between actions and objects, having also the role of providing the required arguments. The mechanism supporting the issuing of messages in direct assertions, direct queries or during logical deduction, consists of the use of built-in predicates requiring logical evaluation and defining procedures that, as a side effect, operate directly upon the objects structure. Example 1 illustrates two different types of message passing: (1) a query which directly retrieves a value from an object attribute; and (2) a generic clause containing built-in predicates-value, add-valuewhich operate directly upon objects. In this example, value retrieves the value of the attribute salary of the object Lecturer and associates this value with the variable ?sal. ask is the general XLOG predicate that poses a query to the system or, strictly speaking, poses a theorem to be proved. In Example 1, add-value asserts a value ?sal to the attribute salary of the object ?obj. Example 1. Passing messages to objects.

8. METHODS

AS PROCEDURAL

AITACHMENT

Methods in XLOG + are either default ones, and are valid for any object-like methods for assignment or retrieval of attribute values, or may be associated with specific objects, if declared through the use of attached predicates. A procedure enabling the association of a non-default method with an object is required to be defined elsewhere. This procedure is the following: (1) an attribute, preferably with the same name of the method in question, must be created; (2) the procedure associated with the method must be attached to the attribute in the form of a built-in or logic predicate (if-needed or if-changed); (3) the procedure itself must then be defined in predicate form (regardless of whether it is associated with a built-in predicate or with a normal one); (4) the issuing of messages to invoke methods then corresponds to retrieving from, or assigning to, those attributes for which if-needed or ifchanged predicates were defined according to (1) and (2). In XLOG + the body of an attached procedure defined as above does not become part of the object itself. The name of the attached predicate is the only portion of the method definition which is actually stored locally in the object. Attached predicates names behave therefore as pointers to the procedures they define, the latter being added to the knowledge

(1) ask(value(salary (2) check salary

of Lecturer(?sal)))

(?obj ?sal) if valuetsalary of ?obj (?old_sal)) and greater (?sal ?old_sal) and add-value (salary of ?obj (?sal) )

Compendium base by means omfthe available tools for adding clauses. In Example 2(a), a predicate called x_momqroc is attached to an attribute called x_moment_of_inertia of an object named rectangular_shaped_section. The predicate add-if-rtd denotes add as a if-needed procedure. The clause or the set of clauses containing the body of the attached procedure associated with x_mom_proc has to be asserted independently to the knowledge base, as suggested in Example 2(b). Consequently, the object will contain no more of the attached procedure than its name (Fig. 8). Example 2(a). Attaching object. a predicate name to an

1025

may lead to serious difficulties in program debugging, i.e. unpredictable results may follow from changes to the inheritance structure (to which conventional methods are immune).
9. MUTABLE OBJECTS

~add-if-nd(x_Inoment_of_inertia of rectang_shaped_sect >_

(x_momgroc) )

Example 2(b). Denning a procedure associated with an attached predicate.

Objects are considered mutable if their properties may change with the passing of time; otherwise they are considered static ones. In an object-oriented environment, the equivalent concept to a variables value in procedural programming is an objects state. The state of an object is given by the individual values of its properties. Therefore, in order to be able to have a defined state and, notably, in order to be able to effect a required change of state, an object must allow and support the modification of any of its properties (attributes) at any time. The special reference to objects in this perspective is justified by the importance given to such ability in many object-oriented applications, not only because of mutable objects being able to store data in so called local variables (attributes in the case of XLOG + ), but also because the ability to support

> value (flange-width )add (x_momsroc(?obj) if value (depth of ?obj (?h)) and value(flange-thickn of ?obj (?ft)) and and value(web-thickness of ?obj (?wt) ) cub (?h ?hcu:b) and and eval((?Io=?w * ?hcub/l2)) _)

of ?obj

( ?w) )

and

As far as specialization is concerned, XLOG + implements method specialization [27] and improves the level of granularity. A final note about methods in XLOG + concerns the possibility of relaxing the concept of method, in the sense that methods may also be defined externally to the objects they are supposed to belong to. In fact, axioms may be asserted as normal logical sentences, not associated with any particular class or object, but being only applicable within the scope of objects satisfying the preconditions of the procedure/method they declare. The procedural interpretation of those clauses may be faced as the performance of methods defined under the scope of the objects involved. Hence, such methods are bound to objects independently of explicit reference in the object definition, allowing a means of dynamic inheritance of methods. This extended and relaxed concept of methods draws on the ideas of ARTs multi-method [18] or Loops DoMethod [17]. Although it may be seen as a practical and powerful means for combining objects methods or simply attribute values, it also bears the dangers of escaping from the message passing convention of object-oriented programming. In particular, the ,widespread use of this mechanism

mutable objects implies the propagation, or at least the communication, of changes occurring in the mutant object to those other objects which include references to it. Different implementations have dealt with this question in diverse ways. While some have to make use of more or less cumbersome techniques [3], others offer support for an objects state as an inherent property of objects [ 151. This characteristic of objects, extremely important in knowledge representation tasks, is fully achieved in XLOG + by means of attribute values and procedural attachment. In fact, the use of attributes as data storing slots, in conjunction with if-changed predicates used in order to attach broadcast procedures directed at objects related to them, provides a simple enough effective way of implementing to a reasonable extent mutable objects and their functionality.
10. COMPOSITE OBJECB

As previously mentioned, the hierarchical nature of most man-made physical entities-and notably civil/mechanical engineering structures-must be

1026

Compendium the implementation and usage of composite objects, the network of objects of Figure 9, used in the partial description of a Car. This example suggests that a composite object like Car may be organized in terms of information located at the following different sources:
l l

local attributes (non-inherited properties); inherited attributes (possibly from a number different ancestors); properties that are themselves other subjects.

of

Fig. 9. Example of composite object.

taken into account when developing knowledge represenation tools for design. One way of endowing knowledge representation formalisms with these capabilities consists in developing tools that allow the build-up of descriptions of objects as an aggregation of parts which are themselves other objects. By doing so, part-of relations among different objects may be defined. Objects formed in this manner are called, in the scope of this work, composite objects. Conceptually, a recursive definition for composite objects is possible since they may be used as parts for other composite objects and, therefore, part-of hierarchies may be defined. Composite objects form, together with multiple inheritance, the set of instruments provided in XLOG + for combining objects in is-a/part-of hierarchies. Two basic approaches could have been followed to integrate the concept of composite objects into the knowledge representation capabilities of XLOG + . The first would provide a form of describing an object as having parts formed from other objects by using a template containing their description; the composite object would then be instantiated as having all the attributes of these contributory parts directly associated with it, in a way rather resembling (multiple) inheritance. The second would consist in keeping a reference within the composite object of all its parts that are, in fact, other objects. One can consider, for the purpose of illustrating

If the first of the basic approaches above mentioned (rather resembling a special kind of multiple inheritance) had been pursued, all the direct attributes of Car, as well as those of their constituent part-sub-objects would have been aggregated under the same single object. Hence, the Car object in the example above would result in being described as shown in Fig. 10. The most obvious disadvantage of this solution is associated with loss of flexibility and modularity. If, for example, any change were to occur at the level of the Car component tyres (such as the addition of a new attribute), its propagation towards the composite object Car would become extremely difficult to handle. An additional drawback of the inheritance approach to composite objects has implications for the resulting clarity of expression. As an example, one may use a query concerning the material property of the tyres attribute of the Car object: it would lead, if use were made of the above Car description, to a confusing if not misleading query that would associate material with Car, ask(value(materialof rather than with tyres, Car (?mat))) (10)

ask(value(materialoftyresofCar(?mat))) (11) The alternative approach to the implementation of composite objects consists in keeping local pointers within the composite object to the objects defined as parts. An effectively modular approach may then be attainable, in the sense that any kind of alteration, occurring at any time, at the level of the constituent objects, becomes automatically reflected (i.e. propagated) in the composite object. This alternative approach is adopted in XLOG + by simply defining object names as the values of composite objects attributes. Figure 11 illustrates the support for composite objects in XLOG + . From the strict point of view of knowledge based organization, the level of nesting that a part-of hierarchy may support should have no clear limitations. There is, however, an impairment arising from cognitive limitations of human behaviour when

tyres
attributes

Fig. IO. Example of composite objecr built through an inheritance approach.

Compendium

1027

Fig. 11.Object-oriented representations

in structural design.

dealing with such knowledge bases. Indeed, the absence of a limit for nesting part-ofs would turn the use of composite (objects into a source of complexity rather than modularity and clarity. On the other hand, one has also to consider the limitations of humans as users of knowledge so nested: the authors know of no quamified evidence concerning the level of nesting considered tractable. Nonetheless, similar concerns have been raised in the exploration of better criteria for developing geometric solid modellers [29].

11. IMPLEMENTATION

OF XLOG +

The notation used in the present paper denotes compulsory strings and characters in boldface type; references to compulsory user-dependent components are included between ( ) and optional arguments between right brackets [ I. The set of built-ln predicates provided in XLOG + to work specifically with objects may be divided as follows: 0 Creation; l Destruction; l Information/Modification; l Assignment/Retrieval; l Genera1 purpose. These built-in predicates have to be provided with the ability to return true or false values, reflecting success or failure in their evaluations, i.e. in the performance of the procedures they define. It remains a task of the theorem prover to propagate to the user the consequences of the returned true/false values. The most important XLOG + predicates are listed in Table 1 using th.e following notation: characters in boldface denote compulsory strings; references to compulsory user-dependent components are included

between ( ) and optional arguments should be between right brackets [ ]. More details about the syntax of XLOG and XLOG + can be found elsewhere [I, 231. A short illustration is presented in Example 3, where ) denotes the XLOG + prompt and subt(x y z) means x = y - z. XLOG was originally written as a C function; it still is, although the code for supporting object orientation was written in C + + [16]. Because of the layer architecture of XLOG, addition of built-in procedures may occur in a broad sense by adding to a table the names of the predicates and functions with which they are associated and by linking the compiled code of those functions to the XLOG object libraries. The first implementation of the object-oriented features now described must be understood as an experimental one aiming, above all, at developing a rapid prototype to be used as an exploratory tool. l$evertheless, his apparently low key approach seems to be an emerging trend in software engineering, as noticed by others [ 11, 301. For the user who is interested in developing XLOG + facilities on the top of the object orientation approach, access to a few header files is sufficient. These files contain C+ + class definitions of the fundamental data structures supporting XLOG + objects: generic_list.h, other_listsh, attributes.h, 0bjects.h. Also, knowledge about four source files containing the code for their associated member functions may be required. These files are: listsc, attrs.c, 0bjects.c and objtab1e.c. An XLOG + object is internally represented as group of attributes, of the form shown in Fig. 12. Attributes are themselves stored in a symbol table consisting of a vector of linked lists grouped by means of a simple hashing process, ensuring that attributes with the same hash code are linked together. Class tbl_attrs in Fig. 13 defines such a data

1028

Compendium Table 1. Some XLOG + built-in medicates Creation:

add-obj ((object) ( [(parent-i)] [, (parent-i + l>l [_I ) 1 add-attr((attribute) of (object) [((value)) I) add-if-ndi(attribute)of(object)((predicate_name)) 1 add-if-ch((attribute)of(object)((predicate_name))) add((Clause)) Destruction: dal-obj ((object)) del-attr((attribute) of (object)) Information/Modification: list-obj ((n) to (m) [attrl) list-obj(al1 [attrl) list(obj [attrl [vail [attl [pranl) liet((obj) [attrl i-11 [attl [pranl) list-attrs ((obj) [vail [att-oredl) list ((object) [attrl [vail [attl ) is-a((object)(ancestor)) is a( (variable) (variable))
has-a((object) (variable)) has-a((variable) (variable))

has-val((attribute) of (object>)
has-parant((object) (parent))

Assignment/Retrieval: add-value((attr) of (obj) ((val))) put-value((attr) of (obj) ((val)) 1 ask (value((attr)of(obj-ref)((val))) General purpose: readf((file-name)) eave( (file-name)) display((string))

Example 3.
)add-obj (employee) )add-attr(age of employee) )add-if-nd(age of emPloyee(calc_age)) )add( calc_age(?obj) if current_year(?current) and value(year-of-birthof ?obj (?year)) and subt(?AGE ?current ?year) and add-value(age of obj (?AGE))) )add(current_year(1991)) )add-obj(Fernando-Pessoa (employee)) )add-attr(year-of-birth of Fernando-Pessoa(l955)) )ask(value (age of Fernando-Pessoa( ?age)) and dieglay(The age of the employee is ?age))

structure and declares the methods provided for handling it. Finally, the internal structure of XLOG + objects has been defined as a derivation of the above defined

data structures: a table of attributes to which a name, a list of parents, a list of children and a set of associated methods to operate upon it have been added.

class tbl_attrs

// Hashed table of attrib.s

struct attribute

1
char *name; char *value; char *if-changed; char *if-needed attribute *next
va ue

if-&an if-needed

// xlog+ attributes attribute l*is; // Table size int size; public: // COnStrUCtor tbl_attrs(int sz = 20); // Destructor -tbl_attrsO; attribute llook(char *); // lookup attribute*insert(char'.char'.char*,char',chdr*): void listattrs(int, int): // listing

Fig. 12. Code and illustration of the structure of an attribute.

Fig. 13. Definition of a list of attributes.

Compendium
class object : public tbl_attrs friend class obj_tbl: 1 "name; char lst_objs "Parents; lst_objs "Children; *next; object public: object(char*. lst_objs* = 0): -objectO, void updateChildren(object *newChild) ( Children->append(newChild); 1 ask_value(char'); char* add_value(char*. char*); int put_value(char*, char'); int add_if_changed(char*. char*): int al~d_if_needed(char', char*); int object* i';_a(char*, int=l); attribute* has_a(char', int=l): list_my_attrs(int. int); void object* find_child(char*. int=l); gat_if_needed(char*, int=l); char* get_if_changed(char*, int=l): char*

1029

1;
Fig. 14. Header file and graphic XLOG + object. depiction of an

It is worth observing the close relationship between methods available for the object class and the built-in predicates provided in XLOG + for dealing with objects, strongly emphasizing the clarity achieved through programming with an object-oriented philosophy (using C-k +, in this case). Using an object-oriented terminology, XLOG + objects may be said to be groups of attributes for which some new properties-name, parents and children-and several methods have been defined (see Fig. 14). The data structure supporting the implementation of XLOG + objects becomes completely defined by describing the table in which they are stored-a vector of linked lists of objects in which objects with the same names hash code are linked together. The code listed in Fig. 15 is clear enough to avoid the need for further comments.

1:Z. RELATED

WORK

Some of the commercial knowledge engineering frameworks which provide support for objects--such as CommonLoops [31], ART [18], NExpertObject [32], KEE [33, 341, STRATA [35] and many others-are not intended to be primarily used as logic programming too:ls. In fact, in most cases it is not clear to the authors how they embrace logic, if at all,

// Hashed table of objects class obj_tbl ( object l *ol; int ol_size: public: obj_tbl(int sz = MAX_NO_OBJI: // Lookup only object lfind(char*j; sppend(char*n, lst_str*p=O); object l void remove(char *I; // Delete object // Listing method void listmetvoidj; 1;

Fig. 15. Table of objects.

either as a knowledge representation formalism or as a programming paradigm; they seem to be primarily intended for combining objects with production rules, leading to what one may call object-oriented production systems. It must be stressed, however, that the proposed environment may also be used in a perspective similar to that of those systems. In particular, if compared with ART, for example, XLOG + may easily and clearly organize data as objects (schemata) with attributes (slots), allowing attribute inheritance and pattern matching from rules (reasoning) [ 181. A lesser-known commercial system which seems to be closer to the present work is the IntelligenceCompiler package[l4]. It is a frame-based system, implemented in C, and may be used when embedded within a logic programming environment. The authors, however, have no further knowledge about the underlying theoretical foundations of this system nor details of the current stage of implementation. The approaches followed by Kornfeld [36], Shapiro and Takeuchi [37], Zaniolo [19] and McCabe [3] have the common objective of developing new logic programming languages based on Prlong or extensions of it, with support for objects or, at least, some of their functionality. Both Zaniolo and McCabe propose translations between objects and Prolog, while Shapiro effects the implementation of an object-oriented language as a means for attaining concurrent logic programming. A reference is merited by the work of Bowen and Kowalski [38] who have tackled the use of meta language to construct programs. This may be interpreted as an early attempt to relate the object-oriented paradigm to conventional logic programming. Kornfeld proposes a generalization of Prologs unification process in order to include the explicit declaration of equality relations among predicates. Despite the merit of such an early effort towards object-oriented functionality, it has been revealed as rather restricted in practical application. In fact, as noticed in Ref. [19], the symmetric nature of the equality relation renders it virtually useless for representing real inheritance situations, even if trivial. Moreover, no message-passing mechanism is provided in the proposal. Finally, a contradiction which may be found in Kornfelds work (as well as in others) is that, while it may be understood as a means to endow Prolog with a relevant new capacity-and thus presumes a clear propensity for the use of Prolog-it requires a high degree of surgery on existing interpreters and/or compilers, namely at the level of the implementation of the unification algorithm. This is an option rarely acceptable for most users. Zaniolo proposes the implementation of object-oriented features in Prolog and on top of existing Prolog interpreters and/or compilers. This is achieved by the introduction of a number of new infix operators-

1030

Compendium programming, without straying from the semantics of predicate logic. This contribution reveals an interesting and early attempt at enhancing logic programming with object orientation by reinterpreting the frame paradigm. However, OBLOG fails to attend to some important features of object-oriented systems, such as inheritance overriding. Gordon also claims that he would rather have included real functions for representing functional properties of objects, instead of relations acting as functions. As for Shapiros work (and that of his followers), it consists mostly of implementing object-oriented languages in parallel logic programming (Concurrent Prolog in his case). Although his work presents very interesting and often unique features, such as effective non-sequential execution through the use of streams, it clearly aims at objectives radically different from the ones pursued in the conception of XLOG + . Such a diversion from the scope of the present work may be illustrated by the lack of support for an inheritance structure in Concurrent Prolog. Moreover, the contradiction arising from a commitment to Prolog together with major surgery requirements on existing interpreters/compilers is also present; the changes demanded reach the point of eliminating the assert and retract Prolog built-in predicates. The POOL language (Parallel Object-oriented Logic) [6] stands as another proposal along the same line as Shapiros contributions, where parallelism is reached through message-passing between concurrent executing objects synchronized by means of monitorlike constructs. Similarly to most other systems, methods are limited to the sequential execution of first-order Horn clauses. The present paper is not at all concerned with the consideration of parallelism in logic programming. Nonetheless, a final reference is merited by yet another parallel object-oriented logic programming system--OAR (objects and reasoning) (71. In OAR, parallelism is achieved by associative message-passing, i.e. issued messages may be received by more than a single object; in that case, independently parallel worlds are executed, as if the object receiver associated with that world were the only receiver of the original message. The most salient features of OAR are that both the local variables and the executable procedures (methods), which in most other systems are associated with the object, are themselves treated as separate objects; a method is then considered as an objects property that indicates a relationship between the object and a procedural object. Finally, special mention may be made of the use of a delegation mechanism as a means for achieving inheritance; this feature, playing an alternative role to that of inheritance, has been claimed as important [28]. Among the more atypical environments found in the literature with special emphasis on engineering design knowledge, one has reached a working prototype stage: the KBASE tool used in developing

with, is-a and :-which may be used to declare objects and their associated methods (with, :), as well as to build inheritance structures (is-a). Despite its total commitment to Prolog-which has already been dismissed as unnecessary (and even undesirable) for the objectives of the current work-Zaniolos early proposal addresses very elegantly some of the object-oriented programming problems with languages that some subsequent proposals have failed to consider. Such is the case, for example, in the treatment he gives to multiple inheritance and to its overriding. Concerning the latter aspect, however, the solution achieved has some inconsistencies which are a result of the message interpretation algorithm implemented. In particular, a method may be overriden by several local ones, an arguably interesting capability. As a consequence, more than one method may become available for execution during message answering, those methods, being local ones, may not be inherited. It seems that restricting the availability of methods to a single one, or extending it to the full inheritance lattice with the additional use of a selection criterion, would result in a more coherent solution. A very broad statement of McCabes proposal is that labels (with or without variables) are used in order to structure (large) logic programs by associating related groups of clauses under those labels. Such related sets of axioms therefore form objects or classes of objects. An important drawback of the approach followed by McCabe, which also affects Zaniolos work, is that, due to their strong commitment to logic programming, they do not really implement objects with state, i.e. whose attribute values may change throughout some associated process. Another problem with McCabes class template notation is that one is not allowed to add, modify or remove properties of an object, without having to redefine the whole object. As a positive contribution of his work, McCabe claims that the broadcast message mechanism is a unique and original feature which assumes particular importance when physical systems are modelled as a composition of several objects (composite objects). Watson and Chan [lo] put forward a prototypic object-oriented knowledge representation system, based on Prolog, with support for schema evolution, composite objects, declarative methods and version control. Although their declared main purpose is the implementation of an object-oriented database system for engineering applications, They eventually convey that persistency of asserted objects is simplistically ensured by writing Prolog clauses to ASCII text files. The OBLOG proposal by Gordon [21] was developed with the primary aim of representing legal knowledge in a logic system. Gordon starts from the observation that objects are mostly a syntactic variant of logic sentences; and he follows with the proposal of an object-oriented approach to logic

Compendium

1031

the ISTRLJDS intelligent structural design system [39]. The basic idea is, once more, to promote the development of knowledge bases which make use of objects, rules and user-defined functions. However, the resulting tool corresponds to a mere mixture of production rules and frame-like entities. It has extremely severe limitations, both from a programming and a knowledge representation point of view; a remarkable example is the prohibition of the occurrence of variables inside rules. An object-oriented language specially developed with the aim of encoding design knowledge and intelligent computer-aided design systems is the IDDL-integrateId data description language [ 111. IDDL uses the logic programming paradigm in order to express design processes, whereas the object-oriented paradigm is used to represent the design objects those processes manipulate. At a later stage of development, IDDL was still facing some important conceptual problems: one such, raised by its authors, queries when to evaluate terms involving functions to be evaluated during unification [26].
13. CONCLUSION

4. J. P. Bento, B. Feijo and P. J. Dowling, The knowledge based design of steel portal frames for agricultural buildings. Expert Systems Civ. Engng 58, 281-290 (1989). 5. G. Miller, An object-oriented approach to structural analysis and design. Comput. Struct. 40(l), 75-82 (1991). 6. J. F. Koegel, POOL: Parallel object-oriented logic. Proc. of the 1987 Rocky Mountain AI Conf., Boulder, CO (1987). I. F. Arbab, A paradigm for intelligent CAD. In:
Intelligent CAD Systems I: Theoretical and Methodological Aspects (Edited by P. J. W. ten Hagen and T.

Tomiyama), pp. 2(r39. Springer, Berlin (1987). 8. J. H. Garrett, Jr, Knowledge-based expert systems: past, present and future. ZABSE Period. 3, 2140 (1990). 9. J. H. Garrett, Jr, J. Basten, J. Breslin and T. Andersen, An object-oriented model for building design and construction. In: Computer Utilizations in Structural
Engineering, Proc. of the 1989 American Society of Civil Engineering Structures Congress (Edited by K.

Nelson), pp. 332-341, San Francisco, CA, U.S.A. (1989). 10. A. Watson and S. Chan, A Prolog-based object-oriented engineering DBMS. Comput. Struct. 40(l), 1 l-21
(1991).

Engineering design knowledge requires a robust reasoning mechanism which should be aligned with an effective framework for organizing knowledge. First-order logic provides the most robust and efficient model of deductive reasoning and the object-oriented aLpproach is a natural way of organizing engineering knowledge. XLOG + , as a hybrid environment dealing with logic and objects, represents a well-Ibalanced proposal for that kind of knowledge. Future work must be directed towards a deeper analysis of typicall attributes involved in engineering design, such as functional specifications and physical attributes. Furthermore, in this context, one should analyse the evolution of the object network during the design process.
Acknowledgements--The authors would like to thank the Gulbenkian Foundation (Portugal), CNPq (Brazil) and the British Council for their financial support of this work.
REFERENCES

B. Feijo, Fundamental steps towards an intelligent CAD system in structural steel. PhD thesis, Expert Systems Labora tory, Department of Civil Engineering, Imperial College of Science, Technology and Medicine, London (1988). A. A. Oki, Primordial abilities in artificially intelligent systems for civil engineering design. PhD thesis, Expert Systems Laboratory, Department of Civil Engineering, Imperial College of Science, Technology and Medicine, London ( 1990). F. McCabe, Logic and objects: language, application and implementation. PhD thesis, Department of Computing, . __ .. . Imperial _ . College ,_^^^. of Science, Technology and Medlcme, London (IYIJY).

11. Bart Veth, An integrated data description language for coding design knowledge. In: Intelligent CAD Systems I: Theoretical and Methodological Aspects (Edited by P. J. W. ten Hagen and T. Tomiyama), pp. 295-313. Springer, Berlin (1987). 12. T. Tomyiama and P. J. ten Hagen, Representing knowledge in two distinct descriptions: extensional vs intensional. CWI Report No. CS-R8728, Centre for Mathematics and Computer Science, Amsterdam (1987). 13. E. Charniack and D. McDermott, Introduction to Artificial Intellinence. Addison-Weslev. +, Reading. I_ MA (19i5). 14. K. Parsaye and M. Chignell, Expert Systems for Experts. Wiley, New York (1988). 15. A. Goldberg and D. Robson, Smalltalk-80: the Language and its Implementation. Addison-Wesley, Reading, MD (1989). 16. B. Stroustrup, The C+ + Programming Language, 2nd edn. Addison-Wesley, Reading, MA (1991). 17. D. Bobrow and M. Stefik, The loops manual. Technical Report. KB-VLSI-81-13, Knowledge Systems Area, Xerox Palo Alto Research Center, Palo Alto, CA (1981). 18. Inference Corporation, ART Programming Manual, p. 9.1. Inference Corporation, LA (1985). 19. C. Zaniolo, Object-oriented programming m Prolog. In: Proc. Int. Symp. on Logic Programming, Atlantic City, NJ (1989). 20. D. Foley, A. Van Dam, S. Feiner and J. Hughes, Computer Graphics: Principles and Practice, 2nd edn. Addison-Wesley, Reading,- MA (1990). 21. T. F. Gordon, Object-oriented predicate logic and its role in representing legal knowledge. In: Computing Power and Legal Reasoning (Edited by C. Walter), ;;i8~-203. West Publishing Company, New York 22. M. Minsky, A framework for representing knowledge. In: The Psvcholonv of Computer Vision (Edited bv P. Winston), . pp. 2ii-277. I&Graw-Hill, New <ark (1975). 23. J. Bento, Intelligent CAD in structural steel: a cognitive approach. PhD thesis, Expert Systems Laboratory, Department of Civil Engineering, Imperial College of Science, Technology and Medicine, London (1992). 24. B. Kemighan and D. Richie, The C Programming Language. Prentice-Hall, Englewood Cliffs, NJ (1978).

1032

Compendium lisp and object-oriented programming. Intelligent Systems Laboratory Series ISL-85-8, Xerox Palo Alto Research Center, Palo Alto, CA (1985). 32. Neuron Data, Nexpert Object v. 2.@-Users Guide. Neuron Data, Palo Alto, CA (1990). 33. R. Fikes and T. Kehler, The role of frame-based oriented representations in reasoning. Commun. ACM
9(28), 904-920 (1985). 34. Intellicorp, KEE Software Development System Users Manual. Document No. 3.0-U-l. IntelliCorp, Mountain

25. M. Stefik, D. Bobrow and K. Khan, Integrating access-oriented programming in a multi-paradigm environment. IEEE Sofrwure. The Institution of Electrical and Electronic Engineers, NJ (1986). 26. P. Veerkamp, V. Akman, P. Bemus and P. ten Hagen, IDDL: A language for intelligent interactive integrated CAD systems. In: In~eIligeni CAD Systems II-Implementation Issues (Edited by V. Akman, P. J. W. ten Hagen and P. J. Veerkamp), pp. 58-74. Springer, Berlin (1989). 21. M. Stefik and D. Bobrow, Object-oriented programming: themes and variations. AI Mug. 6(4), 4G-62
(1989)

View, CA (1988).
35. GEC Research, An Introduction to the STRATA AI Toolkit. Marconi Research Centre, Great Braddow,

28. Tomiyama, Object-oriented programming paradigm for intelligent CAD svstems. In: Intelligent CAD Systems II-Implementation Issues (Edited by V. Akmau, P. J. W. ten Hagen and P. J. Veerkamp), pp. 3-16. Springer, Berlin (1989). 29. B. Feijo, R. Fischer and M. Dreux, Better criteria for the development of solid modelling software. In: 2nd
Int. Conf. on Reliability and Robustness of Engineering Software, RRES 91, Milano, Italy (1991).

Essex (1987).
36. W. A. Kornfeld, Equality for prolog. Proc. Inr. Joint Conf. on Artificial Intelligence, pp. 514-519, Karlsme,

Germany (1983).
37. E. Shapiro and A. Takeuchi, Object-oriented programming in concurrent Prolog. New Generut. Compur. l(l), 2548 (1983). 38. K. Bowen and R. Kowalski, Amalgamating language

30. G. Kahn and M. Bauer, Prototyping: tools and motivations. In: Topics in Expert Sysrem Design (Edited by G. Guida and C. Tasso), pp. 4768. North-Holland, Amsterdam (1989). 31. D. Bobrow, K. Khan, G. Kiczales, L. Masinter, M. Stefik and F. Zdybel. CommonLoops: merging common

and meta-language in logic programming. In: Logic Programming (Edited by K. Clark and S.-A. Tarnlund). Academic Press, London (1982). 39. C.-K. Soh, A.-K. Soh and K.-Y. Lai, KBASE: A customizable tool for building DBase-compatible knowledge-based systems. Ado. Engng Soffware 3(1 l), 136148 (1989).

Das könnte Ihnen auch gefallen