FindBestStuff.

FindBestStuff.com

Google Search
Web

FindBestStuff

com

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

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

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

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

Copyright 2007
FindBestStuff

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

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

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.

The relation (2) would then become, if described

intensionally,
relation

(Bl next-to

Cl).

(5)

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

Compendium

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.

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

1017

/L
%

objects name
parent objects name

indicate objects properties

I
Fig. 1. Representation

of a cross secrion object.

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

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)

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

(b)

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

Compendium

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

1019

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

established between the two components,

required.
5. THE

OF AN XLOG +

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

TO LOGIC AND OBJECTS

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

STRUCTURE

whenever

(7)

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

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

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 +

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

1023

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:

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

(a)

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

!!

:.,..i
q

7
: .,~
i

, - . ..

I._

2.

(4

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

object
rootobject

Compendium

1024

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

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.

AS MESSAGE PASSING

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.

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

Fig. 8. XLOG

of Lecturer(?sal)))

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

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

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

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

(x_momgroc) )

Example 2(b). Denning a procedure associated with

an attached predicate.

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

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))
_)

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

1025

of ?obj

( ?w) )

and

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

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

tyres
attributes

Fig. IO. Example of composite objecr built through an

inheritance approach.

local attributes (non-inherited

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

of

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

Car

(?mat)))

(10)

than with tyres,

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

Compendium

Fig. 11.Object-oriented representations

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

1027

in structural design.

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

struct attribute

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

va ue

if-&an
if-needed

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

attribute.

// Hashed table of attrib.s

// 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. 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*

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;
object lsppend(char*n, lst_str*p=O);
void remove(char *I; // Delete object
// Listing method
void listmetvoidj;
1;

Fig. 15. Table of objects.

1029

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

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

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

Compendium

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

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).

1031

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).

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

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)

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).

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

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

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

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

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).