The object-oriented paradigm

Citation for published version (APA):

America, P. H. M., Kammen, van der, M., Nederpelt, R. P., Roosmalen, van, O. S., & Swart, de, H. C. M. (1994).
The object-oriented paradigm. (Computing science notes; Vol. 9401). Technische Universiteit Eindhoven.

Document status and date:

Published: 01/01/1994

Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be
important differences between the submitted version and the official published version of record. People
interested in the research are advised to contact the author for the final version of the publication, or visit the
DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page
numbers.
Link to publication

General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please
follow below link for the End User Agreement:
www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at:
[email protected]
providing details and we will investigate your claim.

Download date: 10. Dec. 2021

 Eindhoven University of Technology

Department of Mathematics and Computing Science

The object -oriented paradigm

by

P. America, M. van der Kammen, R.P. NederpeJt,

O.S. van Roosmalen and H.C.M. de Swart
94/01

Computing Science Note 94/01

Eindhoven, January 1994
 The object-oriented paradigm*
P. America' M. van der Kammcn R.P. Nederpelt** o.S. van Roosmalen **
H.C.M. de Swart!

Decem ber 24, 1993

Abstract
In this paper we discuss the fundamental concepts present in the object-oriented
methodology.
First we concentrate on the notion of an object, the key concept in this approach.
A (software) object is the abstract representation of a physical or conceptual object. It
consists of a name, a specified set of data-elements and methods. Data-elements can have
values attached to them.
Data-hiding is the feature that certain data and methods can be kept invisible (=
hidden) for the outside of an object, thus facilitating its description. Only knowledge on
the nature of the visible data-elements and methods is required to make proper use of the
object. This is called data-abstraction. A related concept is encapsulation, a technique
for achieving both data-hiding and data-abstraction.
A class is a template for a number of similar objects. Classes do not prescribe values
for the data-elements nor fixed implementations for their methods. A class can be seen as
a set of objects that satisfy the same specification for data-elements and method-behavior.
An alternative grouping of objects may take place by means of object types, as we
will describe. A type is a set of objects that satisfy the same ezternai specification, i.e.,
specification of the visible data-elements and methods. Thus, a classification via types
differs from an ordering into classes, as we shall explain. The notion of type brings along
a notion of subtyping.
We also discuss different forms of inheritance between classes. By means of inheritance
a class can use data- and method-descriptions from another class. We describe, among
other things, single inheritance, multiple inheritance and overriding. We also discuss
mUltiple preferred inheritance and runtime inheritance.
Finally, we show how actual programming can take place in an object oriented ap-
proach. For that we need a description of inter-object communication by means of mes-
sages. Relevant aspects are: synchronous and asynchronous message passing, scheduling
and delegation.
The paper concludes with an overview and a number of summarizing remarks.

"'This paper originates from Marc van der Kammen's master's thesis "The logic of objects; object oriented
programming in a logical perspective". It is the revised version of his chapter 0, which contains an overview
of the most important basic notions concerning object-oriented programming.
tphilips Research, Eindhoven, The Netherlands
"Department of Mathematics and Computing Science, Eindhoven University of Technology, Eindhoven, the
Netherlands
tDepartment of Philosophy, Tilburg University, Tilburg, the Netherlands

1
1 Introduction
Recently, there has developed a growing interest in object-oriented programming, both in
research a.nd in t.he industry. It. is mol'c t.he name of a methodology t.han a collection of
language features.
Languages can support this methodology, just like PASCAL suppo1'ls structured program-
ming. But, naturally, there is no language that enforces this approach t.o such an extend that
one is gua.ranteed to develop 'propel" object-oriented systems.
Unfortunately, it is not easy to say what features are required in an object oriented language,
although there is a growing consensus on the minimal set of features that must be present to
call it object-oriented. This consensus ca.uses a convergence in the features offered by popular
object-orient.ed languages.
In this paper we shall discuss t.he most. import.ant. a.spect. of object-orient.at.ion. The central
concept is, of course, that of an object. We sha.ll give an idea of what a.n object is and what
can be it.s values (or states). By lIleans of object.s we can encapsulate data and code. Related
concepts arc classes and t.ypes.
When the concept. of an object. has been made sufficiently clear, we will ta.ke a look at
inter-object relations. We will explain the idea of inheritance, as both an inter-class and an
inter-object relat.ion. Next we will discuss ",.essage passing between objects. Together with
inheritance we will treat subtyping, whidl ha.s been taken as a means of implementing and
describing inheritance by some anthors.
Finally, we will give an overview of 0111' presentation and we dra.w a Humber of conclusions.

2 Objects and values

In the seventies, St1"ucf.Ul'Cd progl'a1nm.iny was one of the keywords used in the prograInluing
community ([Dahl et al. 72]). The ra.tionale behind this a.pproach was the growing conviction
tha.t the best solut.ion for a realist.ic problem could be found in the use of a methodology that
takes the logical structure into account. Structured programming is now genera.lIy accepted
as a proper way of programming.
Object-oriented programlIling is based on the idea that t.he physica.1 and conceptual objects in
a problem domain can be used as a template to structure programs: First., reality is modelled
a.s a set. of objects, including object-properties and relations, tha.t are relevant. to the problem
to be solved. Thus a problem is structured into sma.ll units that turn out to be relatively
independent, of ea.ch other. Second, the unit.s t.hus obta.ined a.re directly mapped onto the
program.
Na.turally the modelling of reality is not a.I1 ea.sy process. The a.ctual partitioning that one
obtains depends on many factors, t.he most. importa.nt one being the way one perceives reality.
Thus, on t.he one hand t.he approach offers int.uit.ive mea.ns to support. the analysis and design-
process, on the other hand it puts a higher burden on the power of abstraction and creativity
of the softwa.re-engineer.
The independent pieces of reality tha.t one is looking for can be found by esta.blishing the
aspects that one considers of importance to the problem a.t ha.nd. For example, for the
modeling of an old-fashioned ala.rlll-clock we could consider t.he following aspects a.s relevant.:
the time it is indicating (the current t.ime); the point of time at. which it is supposed to
sound (the wa.ke-up t.ime); the litt.le switches OIl t.he ba.ck with which t.he alarm t.ime ca.n be

2
changed; and the mechanisms it uses to operate. There are also t.hings of lesser importance
in this exa.mple, such as the substance the clock is made of. It follows that one usually
considers only a. small part of reality t.o be interest.ing. These interesting aspects can be
further divided: the little wheels inside the alarm-clock are things that we do not take into
consideration immediately, the direct cancel'll is to be awoken at t.he proper time. Thus a
distinction is made between externally observable aspect.s and internal ones.

Reality Abstract model

Object
Nrune
my_alarm
Daia-elcntent"
my_alarm (the real thing) current_time
wake_up_t ime
Mel.hods
set_currant_time
set _wake_up_t ime

Figure 1: The introduction of the abstract model.

The step to the abstract model is now very easy. We int.roduce for this purpose the notion
of objects, that are tuples of data-clements and methods 1. The data-elements of an object
represent the modeled aspects, like the time the clock indicates, or the time it is set to sound.
The methods of a.n object represent t.he j.ra.nsfOl'mations which ca.n be performed on the data-
elements. For example, we ca.n change t.he time the alarm-clock is set to sound by tUl'Iling
the appropriate switch on the back. /
An object can be seen ([America. a.nd Rutten 89]) as a black box which can store some data
a.nd ad upon it.. An object can only change it.s own dat.a, and not. that of another object.
Other objects are involved in realizing an object's behavior, e.g. the wheels of the clock that
implement its mecha.nism. The required coopera.tion is ma.de possible through inter-object
communication. This communicat.ion can be done in several wa.ys a.s will be explained later.
Objects can be created and destroyed. This crea.t.es a dyna.mic structure: the part of reality
that the model is supposed to describe can change in t.he process.
An object-oriented program in execution will be called a system. Such a syst.em can be
thought. of as being a va.rying set. of cOllllllunica.ting objects.
In figure 1, we show a.n abstra.ct model of a.n ala.rm-clock in tI,e form of an object. Note that
this object is itl(lecd an abstra.ct.ioll of fcalitYl i.e. we c<w do morc with a real ala.rm-clock
than only setting the current t.ime a.nd t.he wake_up_t.ime (even if the clock is not intended

lDifferent authors use different terminology. In e.g. [Madsen and M~ler-Pdsn 88J these are called
attribute6 and action", respectively. One also often reads about variable.! and procedure".
to be used for other purposes). It. is our persona.I choice (in accordance with our aims) to
disregard all features of the alarm-clock that are not modeled.
The data-elements in a.n object ha.ve, a.pa.rt from their na.me, a cert.aill value. If it is nine
o'clock PM, the va.1ue of the data-element current_time is supposed to reflect this, e.g. as
the number 21 :00.
In [MacLennan 82] the va.1ues of the data-elements in an abstract model have the following
four properties:
- abstraction: Va.1ues are abstractions from real values.
- changeability: Va.1ues do not change, they are constant and static. We cannot change the
value 21: 00; the only thing that can cbange is the current. time.
- state: Va.Iues do not have a state; because they are constant, they represent only one rea.1
value.
- referential transparency: If a. data-clement has a va.Iue n, and the va.Iue n equals the value
b, then the data-element has a.Iso va.Iu€ b.
About the last-mentioned property, we note the following. In general, a model bas referentia.1
transparency if and only if equa.I values can be substituted for each other, without affecting
tbe model. This is clearly the case with va.Iues: values cannot be duplicated, they are unique.
Therefore there is referential transparency in t.he abstract model at va.1ue-level.
This is not so trivia.I as it seems; suppose we know that "The number of inhabitants of
Amsterdam decreases" and that "The number ofinhabitant.s of Amsterdam equals the number
of inhabitants of Rotterdam". We do not necessarily also know t.hen tha.t "The number of
inhabitants of Rotterdam decreases".
Here we encount.er the difference between the in/.ension and the e,,/.ension of a notion. The
number of inhabitants of Amsterdam is only equal to the number of inhabitants of Rotterdam
in an extensional sense. It is in fa.ct. the extension, viz. t.he value of the number of inha.bi-
tants of Amsterdam, that equa.1s the value of the number of inhabitants of Rotterdam. Now
the number of inhabitants (the inte1lsion) can decrease, hut. t.he value of that llmnber (the
extension) cannot. (See [Dowty et a!. 81].)
Values of data-elements can be used to characterize an object. The state of an object in
the abstract model, at a particular 1ll0l1lent, consists of the values of t.he data-elements (at
that moment). We do not t.ake met.hods a.s ent.ries in the state. The reason is that the
set of methods of a.n object does not cha.nge in t.ime. Hence, the st.ate of an object at. any
moment consists exclusively of values of data-elements. It changes in discrete steps, and not
continuously. Moreover, an object. is (ill our a.bst.ra.ction) fully cha.racterized by its state.
Of course, methods have their effect all the data.-elements of an object. In order to guarantee
that methods do not interfere, we assume that. at any aile moment, in any object, only one
met.hod ca.n be active.
Suppose that an object contains other data-elements than the ones that actua.1ly occur in the
methods of the object. Then these dat.a-elements do not. cont.ribut.e t.o the intuitive meaning of
the object, since they will never change, nor do t.hey ha.ve an effect. on any method. Therefore,
we lua.y consider not. to inc1ude them in the state.
In the example depicted in figure 2, where x and yare the only dat.a-elements occurring in
the methods rno a.nd m" t.he usefulness of z could be questioned. As there is no method which
makes usc of or challges the value of z, it is ina.ccessible.

4
 Object
Name
a
Data-elements
x
y
z
Methods
mo = ... x . ..
ml = ... x .. . y . ..

Figure 2: Too many data-elements.

Slight variations on these gencra,] principles for objects can be found in the literature. For
example, in the language POOL ([America and R.utten 89]), objccts do not only have data-
elements and methods acting on these data-clements, but also a body, which is a process that
starts executing upon creation of the object.. In this fashion concurrency is introduccd in
POOL.
Another variation is proposeo by [Goguen and Meseguer 87]. Objects are there seen as de-
scriptions of rea.Jity using only equa.tions. There is no distinction between data-elements and
methods. Every object is mea.nt t.o embody a. relation between properties.
There is a clear distinction betwcen objects and va,]ues (which is not a.Jways ma.de in liter-
ature). Just like in real life, where t.he perception of a. certain entity will change, objects
- which represent this entity in t.he ahstra.ct model - ca.n change too. If for example time
changes (which continually happens), the current.time of my.alarm will get a different value.
(We are not interested here in the question wllcthcr we ha.ve a continuum of values for the
current_time, 01' that we only have a. discrete set of values.)
Its original valuc, of course, does not change (as values arc unchangeable), and neither does
its ncw value. Only the data-clcment changes (see above; recall that a data-element is a pair
of a. name a.nd a. valne).
It is further possible to have two a,]ann-clocks which a.re simila.r. If two a.Jarm-clocks look
very much alike, we are very soon inclined to say that they a.re equal. In our abstract model,
it is therefore possible that two identical objects exist apart frol1l each other: they form two
instances of the same kind (see also section 4). We are then inclined to say that the two
objects have thc sal1le state.
Of course, this equality can change. When one of the ala.rm-clocks is set, to sound at a different
time, its state changes and with that its equality to the other alarm-clock, which will still
sound a.t the original time.
Concluding, we list some properties of all object. as follows:
- abstraction: Objects arc abstractions from pieces of reality.
- changeability: Objects are subject. to change in time: they ca.n be created, change their
state and disappear.
- state: At anyone moment in time, objects have exactly one state; this state is composed
of the momentary value of all data.-element.s the object contajns.

5
- referential transparency: Objects can have duplicates, which can act independently; two
ohjects that have the same state (are "equal") at a certain moment can be different the next
I1101nent.

From our discussion above it is clear that. there is no referential transparency at object level.
This causes problenls, for exalnple with aliasiIlg 2 .
Objects can, as is clear from the above, be used to represent (sets of) values. The interested
reader is encouraged to read [America a.]1(1 Rutten 89], where this is actually done.

3 Data-hiding, data-abstraction and encapsulation

The description of reality by mea.ns of objects gives a. uniform view. Objects are seen as
modules which consist of data aud methods. For the object itself, it is very important how
the methods change the data, but for a nser of the object, this is of no interest. The mere
fact that the data. change is enough for the user, and no more.
Let's take the alarm-clock as an example again. The fact tha.t its current time changes is
something aJl observer sees. The observer notices that. the h"nds of the alarm-clock move.
But what t.he observer does not need (or want!) t.o know, is which wheels inside the alarm-
clock do work. However, if the alarm-clock wouldn't know how to change the position of its
ha.nds, it would be useless. Therefore, the method turn..hands should be known to the object
my.alarm, but need not be visible to any other object.

Reality Abstract model

Object
l"/fllne
my.alarm
Data-clements
current_time
\lake.up.time
my.alarm (the real thing) Hidden data-elements
tick.count
!IIet.lwds
set_current_time
set_wake_up_time
TTidden methorl8
turn..hands

Figure 3: Hidden object. feat.ures ill t.he abstract. model.

2We talk of alia$ing whenever we have two names for the same thing, and use one of these names to change
it; one of the mentioned problems is that one often forgets that it has also changed when we use this thing
with the other name.

6
As we may infer from this example, the concept of datn-hiding appears to be very important
in object oriented approaches. Data-hiding is a way to keep irrelevant information away from
the observer.
This idea is closely related t.o the mod ular approach of programming. A natural conse-
quence of a modular approach is that set.s of related methods and t.he data t.hey manipulate
are put together in one module; this facilit.ates t.he hiding of unimportant information (see
[Stroustrup 87]). Actually, the term 'data-hiding' does not fully cover its load; we had better
talk about data- and method-hiding (or infonnation-hiding), as from the example given above
it is already clear tha.t methods are also in I,he same module. In figure 3 we have inserted
examples of a hidden data-element and a hidden method in the abstract model.
In order to use a certain module, we need to have some kind of description of the module.
There are two aspects of interest in this rega.rd.
First, the description needs to tell which data-clements and methods are visible to the outside
of the module and which are not.. Second, it. needs to give us a, description of the possible
values of visible data-elements and hehavior of visihle methods. In order to use a module, we
need to know what it does and how we should use it in order t.o achieve a certain effect. This
manner of describing a module as out.lined ahove, is called riata-abstmction.
The above description of a module is often called an external intel/ace. The part of the
description that tells us the behavior of I,he visible pa,rts of the module is called the external
specification of the module. Naturally, also an intemal specification exists.
The concepts of data-hiding and data-abstraction arc importa,nt aspects of the encapsulation
technique (see [Snyder 86]):

"Encapsulation £8 (l. technique for 111:mitn£::Ul(J inte1'flcpendenc£es among sepa-

rately writlen modules by defining strict external interfaces. The external interface
of a module serves as a contrru:/, between the module and its clients, and thus be-
tween the dcsigne'f' of the m.odule and ot.her designel's. If clienl.s depend only on t.he
external interface, the morlu.le can be l'C£mpie712Cnted w£tlwut affecting any clients,
as long as the new £mplemental£on supports t.he same (01' an upward compatible)
external interface. Thus, the effects of compatible changes can be confined."

Generally, encapsulation is considered one of the llIa,ill featnres of object-oriented program-

ming. It provides the designer of programs with an easy way of re-using previously developed
modules, and therefore offers an efficient (and clean) way of program development. However,
reuse is St.illlllla.t.ed by eqllaU,V import.anl, ot.her lIlccha,llisms in object-oriented progranlIning
languages, such as inheritance and genericity. These features distinguish object-oriented lan-
guages from other languages that support 11l0dularit.y (e.g. Ada, Modula-2). According to
some estimations regarding the development of large software projects, up to 80% of the code
can be re-used ([van Ginderen 90]).
An object has data-abstraction if it has an external interface which gives a certain interpreta-
tion of the externaHy visible data-clements a,nd accolllpanying methods (or in other words, if
it has a,n external specification)3. We are not interested in exactly what is inside the module,
but we only want to know what it mei:tllS a.nd how we can use it.
3The objects in our abstract model can be seen as the abstract data objects of [Snyder 86J. The external
behaviour of an object is fully defined by a set of abstract operations on the data of the object.

7
If an object has data-abstraction, we have the freedom to change the internal structure of
the object, as long as we do not change the external interface that forms the interpretation
of the data and methods. In [Stefik and Bobrow 86]' data-abstraction is explained as the
principle that modules should not make assumptions about implementations and internal
representations of the modules t.hey are USillg.

4 Classes
We are sOluetilnes inclined to sa,y t.ha.t certa.iu pieces of rea.lity are very siluilar (of the "same
kind"). Although the alarm-clock we have in mind may differ a lot from the one you have in
mind, we all say that. it is an alann-c1ock.
To formalize the intuit.ive notion of t.his type of similarity in realit.y, we need some classifi-
cat.ion. Two pieces are of the same kind if and only if they have the same relevant aspects.
Using t.his not.ion, anything t.hat. ticks, that. has hands indica.t.ing t.he current. t.ime, on which
the current time and the alarm time can he set, will be known as a.n alarm-clock.
Similarity is reflect.ed in t.he abstract model by means of the notion of class. A class is meant
to serve as a. specificat.ion for object.s. Any ohject which matches t.he specification belongs to
the class. No distinction is made here bet.weell the visible and hidden feat.ures. A class gives
intel'llal specifications for methods (sec below) and a pattern of dat.a for object.s of the same
kind. It is not an object itself. However, given a class, objects of this class can be creat.ed.
In figure 4 we illustrate t.he llotion of class wit.h our example of the ala.]'Jn-clock.
A class is a set of method- and data-descriptions. The difference bet.ween classes and objects
lies in this word description. Objects ha.ve values for t.heir da.t.a-element.s. Classes have de-
script.ions for their dat.a-elements (thiuk of information on type, etc.). Also,objects-met.hods
a.re fully deta,iled, whereas classes have possibly pa.rtial descriptions for their methods: ob-
jects belonging t.o t.he same class may have diferent. implementation of their met.hods (see the
discussion on illherita.nce and polymorpldslll further on).
Cla.sses are descriptions of objects, alld therefore consist of descript.ions of data-elclnents and
methods.
A description of a da.t.a-element. consist.s of a name aud a value-domain. There may also be
restrictions on the combined values of dat.a-elements, as expressed in so called class-invariants.
A descript.ion of a method consists of its name, pre- and post-conditions, and often a default
implement.at.ion which we will call t.he internal specification of the met.hod.
To point out the difference between description a.nd definition, we use the symbol':' for the
descriptions in classes, and '=' foJ' t.he definit.ions in objects. See figure .5 for an example. We
give the method-descript.ion by Ill,,"ns of a. Hoarc-triple ({ time=T}, set_time(t),{ time=t}).
Its mea.ning is: starting in a sta.te in which the pre-condition time=T is satisfied, the execution
of method seLtime (t), if terlllinat.ing, wiillead to a. st.at.e in which the post-condition time=t
is sat.isfied'. Note that a. description is given for the visible as well as the hidden dat.a and
met.hods of the class. Although a USCI' of the corresponding objects requires only information
on the visible aspect.s, the class descript.ion limits t.he way in which the externally observed
behavior can int.ernally be realized.
"In this simple case - contrary to the general situation - the pre-condition has no connection with
the method or the post-condition: the original value of the time (T) has no consequences for the method
set-time(t) or the new time t.

8
 Reality Abstract model

Object
Name
my_alarm
Class-Name
alarm
Da/.a-elel1l€nt8
current_time
my_alarm (the real thing) wake_up_time
Hidden data-clements
tick_count
Methods
set_currant_time
set_wake_up_time
Hidden methods
turn-.hands

Class
Name
alarm
Data descriptions
current_time
wake_up_time
alarm (the real kind) lIidden-dala descriptions
tick_count
Method dese,-iptions
set_currant_time
seLwake_up_time
Hidden-method dese,-iptions
turn-.hands

Figure 4: Classes and objects in the abstract model for alarm-clocks_

9
 Class
Name Object
alarm Name
Data descriptions my _alarm
time:Int*Int Class-Name
Hidden-data descriptions alarm
ticks:Int Data-elements
Method des(Tiptions time = 11: 10
{time=T } Hidden data-elements
set_time(t:Int*Int):[time:=t] ticks= ..
{time=t } Methods
Hidden-method descriptions seLtime(t) = [time: =t]
{time=T } Hidden methods
turnJiands turnJiands= [ .. ]
{time= .. }

Figure 5: Classes and objects.

A class is often seen as a set of objects (sec [Halbert and O'Brien 87]), where every object
represents a different "va.lnc". This idea. of value is of course not. the same a.s the previous
one. Here the "value" of an object is coltlpletely characterized by its state.

5 Types
Tn the previous section, we have grouped ohject.s on thcba,is of thc description of their data-
elements and the internal spccificatioH of their methods. This ga.ve rise to the notion of a
class.
In this section, we will group objects in a.n altcrlIativc way, thercby creating types. In this
a.pproach, objects a.re grouped OIl the basis of t.heir external beha.viour; i.e., wha.t is visible
from the outside (cf. [America a.nd Ruttcll 89]).
A type is detcrmined by the external speciiication of a.n object., i.e. the specif,eation of the
nilmes and types of the visiblc data-elemcnts, types of method-arguments and names and
returned results of methods, and the specification of the behavior of the methods. Two
objects have the same type if their externa.l specifications coincide.
The essence of the difference betwee1l class and type ca.1I be phra.sed a.s follows: a. class groups
together objects that are built in the sanll' way while a type is a collection of objects that
can be used in the same wa.y.
In programming la.nguages we do not always have types. Looking at pure PROLOG, there
is no typing on the domain of the terms. Bill. looking at PASCAL, we ha.ve a very strict
notion of typing. :F'o1' C thillgS arc difrercll{. aga.in. Tllere, a.utomatic t.ype conversion plays
an important role.
The use of types has various advantages, like the possibility of static type checking, resulting
in a larger efficiency and a larger chance of correctness for programs, because there is less
need for run-time checks. Another adva.ntage is that domains for functions ca.n be given as

[0
types; for all function applications one then may check beforehand whether the argument of
the function has the proper type, i.e., whether it fits in the domain.
Type compatibility is one of the main issues of typing. It. is based upon an ordering on types,
thus introducing notions like sub- and supertype. An assignment x := E is allowed only if
the type of E is a subtype of the t.ype of,t. In some la.lIguages that support types, we can
instruct the compiler to check the types, thus preventing execution of the code if the types
are not compatible.
Porting this idea of subt.yping to our abstract model, we arrive a.t wha.t is described in the
following.
By the very definition of class it is not possible tha.t objects of the same class have different
types (or external specification). This fact. enables us to talk ahout the type of a class, instead
of a.bout the type of an object". \Vit.h allY class, exact.ly one t.ype can be associated.
We say that a type A is a subtype of a type lJ (and write A %::typo B) iff adherence to the
external specification A implies adherence t.o the ext.emal specification B. This means, that
any visible beha.vior of an object wit.h type A is in a.ccordance wit.h the specification B.

Class
Name
STACK
Hiddell data descr·iptiollS
n ~ integer
s : array of integer
Method descr·ipliollS
{s=W 1\ n=N}
push(x)
{s=WI s [NJ=x 1\ n=N+l}

{s=W 1\ n=N}
pop
{s=W 1\ pop=s [N-l] 1\ n=N-l}

Figure G: The class STACK.

In ftgure 6 we can see the cla.ss STACK a!ld the specification of methods push, pop and the
data-elements sand n. The array s is llsed to contain tIle elements of the stack. Pushing is
done from the bottom-up in this a.lTay. An object. of class STACK represents a stack with the
operations push a.nd pop, specified a., given in fignre 6. \Ve ca.n see tha.t a.ll da.ta-elements
of objects of class STACK are hidden. Only the method, can he seen from the outside. The
external behavior a.s produced by t.he methods push a.nd pop is completely determined by the
external specification: pop (push (stack. x» = x, stating that a pop delivers the last element
pushed onto the sta.ck.
In order to create a subtype of STACK, we need to look a.t it.s external specifica.tion. Important
aWe are aware of the fact that we introduce some limitations, which may restrict the usefulness.

11
is that a subtype can at least "do" everything tha.t STACK ca.n, and possibly more. Consider
the following class XSTACK (see figure 7).

Class
Name
XSTACK
Hidden data descriptions
m: integer
t: array of integer
Method descriptions
{t=W A m=N}
push(x)
{t=Wlt[M]=x A m=N-l}

{t=W A m=N}
pop
{t=W A pop=t [N+l] A m=N+l}

{t=W A m=M}
empty
{t=W A m=O}

Figure 7: The class XSTACK.

The specification of class XSTACK differs from the one of STACK. There is not only an additional
method empty in XSTACK, but also a different internal representation: the array is built from
the top down. This contrasts with STACK where the array is bllilt bottom-ups. Also, the
data-elements have different names. Nevertheless, XSTACK <'ype STACK since if we restrict
ourselves to the use of the operations offered by both classes the same behavior is externally
observed for objects of either class.

6 Inheritance
Typing is something ext.ra., something t.o ensure correct, ness, to improve efficiency, which is not
necessa.rily present in a progra1l1ming language. Inherit.ance is something typical for object
oriented programming and therefore is essential for a.ny programming language which claims
to support object-oriented design.
Many authors do not distinguish between the notions of subtyping and inheritance, e.g. in
[Bruce and Wegner 86] we can find a very nice theory which describes inheritance nsing a
subtyping relation. However, our point of view is that typing should not be used for other
purposes than the ones given above. Inheritance is something typica.! for object-oriented
approaches and if we use typing to describe it, its power is somewhat limited ([Cook et al. 90]).
6Note that m is of type integer and therefore can be negative. The method empty permits to start with an
empty stack, initializing m to zero.

12
In the following, we will describe inheritance, starting in a very simple form, and then ex-
tending it to a general form. Many other forms exist, but we will limit ourselves to the most
important ones.
Inheritance can be described as a. mechanism through which classes obtain data- and method-
descriptions frolll other classes. Of course, our a.bstract model is supposed to be able to express
this property. Therefore, we have a linking Ju.nction hetween two classes.
We will use V A and MA for the set of dat~eln-s respectively the set of method-
names for any class A. It will be the case that V An MA = 0 for any class A. Moreover,
we use fA for a.ll entries in V AU MA. Hence, fA contains a.ll da.ta-element-names and all
method-names of class A.

Definition 1 Linking Junction.

Given two cla.sses A and B, we call r a linking function from H to A iff

r E fB ~ fA
such that 7 r(VB) <;; VA and r(MB) <;; MA.
With ~ we denote a partial function.

We use a linking function to express the way we inherit a. data-description or method-

description from another class ( note th at the Ii 1I ki lIg fu n ction i m pli ci tly con sists of two distinct
parts, one for data-descriptions and one for met.hod-descriptions). The idea is that the linking
function t.ransfers some dat.~ or method-descriptions of class .4 to another data- or method-
description of class B. If reb) = a., then f/. is inherited from class A in class B under the name
b.
In the most simple form of inheritance, there are hasica.lly only two classes A and B involved,
ano B inherit.s everything that A ha.s. This lIleans, tha.t every data.- a.nd met,hod-description
from A is also in B. The linking function will there be used ill order to find the origin of the
description of a method or data.-element.
This 1110St. basic form of iIdlCrit.ance w(' will call complelc inho'it.ancc.

Definition 2 Complete inhel·itancc.

Given two classes A a.nd B and a. linking funct.ion r from n to A, we say that
B <~pl A (B inherits complete from A) ifr
(for all a E fA : (there is abE fB : (r(b) = a)))
We say that the elements of fA a.re inherited from A by n.

For an example, see figure 8. The linkiug function from ALARM to CLOCK can be expressed
as the following set of pairs: {(current_time,time),(set_current_time,set_time)}. In the
following, we will use this notation in order to express the linking fUHction.
All data.- and method-descriptions from CLOCK a.re inherited by ALARM under a. different name.
This will complicate our discussion furt.her on and therefore we will simplify this by giving
the inherited items their original Ha.mc. This mea.ns, that instead of having current_time
and set_current_time in ALARM, we now ha.ve time and set_time, which ha.ve the same
description. The linking function now becomes trivial and our class is slightly changed (see
figure 9).
1We do not consider the option available in e.g. Eiffel ([Meyer 88]) to redefine a method as a data-element.

13
 Class
Name
CLOCK
Da/f/. descriptions
time : ...
Me/hod dese,·ipt.ions
set_time : ...

Class
Name
ALARM
Data dcscriplion8
wake_up_time : ...
current_time : time(from CLOCK)
Method description.';
set_"ake_up_time : ...
set_currant_time : set_time (from CLOCK)

Figure 8: Complete inherita.nce.

Note that it is not necessary to explicitly specify in the list of da.ta-elements and methods
of ALARM that we also have time a.nd set-time. This information can be extracted from
the complete inheritance of the cla.ss ALARM from the class CLOCK. Moreover, the method
set-"ake_up_time described in ALARM mily usc both set-time and time.
Class CLOCK itself can of conrse inherit frolll another class. 'rhis way a chain is formed along
which complete inherita.nce takes place. For an example of SUell "Ut inheritallce cha.in, see
figure 10. This possibility of chaining of inheritance is ca.J1ed linea,/·ily.
In order to find the description of set_time of class ALARM in the situation of figure 10, we
use functional composition of the linking functions along the chain. In t.his case, we have a
linking function TCLOMEHDS~A and a linking function TALRM~COKJ1EHDS, which
are both quit.e trivial. Funct.ional composition gives a linking function TALRM~COK.J) We
can compute the values of these functions by starting a.t. the end of t.he chain, at the point
where the data-elements and ITlethods are a.ctlla.J1y described.
Therefore, we Illust require that t.hese chains do indeed end. E.g., we must prevent to have
that A inherits from Band B inherits from C and ... inherits from A. Checking on the
presence of circula.r inherita.nce relations Det.wpen classes is obviously the t.a.sk of a language
compiler.
Another problem that requires attention io the fol1owillg. Suppose that the class ALARM
in figure 9 has a method-description set_time in it. As class CLOCK, which is completely
inherited by ALARM, also has a. method-descript.ion set-time in it., it is not clear which of the
methods (set_time) is mea.nt when Olle t.alks of set_time in A-1ALARM. This problem of so
cal1ed name-clashes will be discussed lat.er.
SOBle generalizat.ions of t.he notion of complete illhcr1tance have been int.roduced. The first

14
 Class
Name
CLOCK
Inheritance
none
J)ata-descl'ipl£01l8
time : ...
M cthod-desc7"iplions
set_time : ...

Class
Name
ALARM
lnher£tance
complete from CLOCK
Do la-ric8Cl'iplio11S
wake_up_time : ...
M ethod-dcscripl.ion8
seLwake _up _t ime : ...

Figure 9: COlllplet.e inheritance (silllplified).

extension we will consider here is the one towards in.complete in.hel·itance. The idea behind
incomplete inheritance is that not all da.ta.-elements or methods are inherited from another
class.

Definition 3 Incomplete inhcl·itance.

Given two classes A and B ami linking runction T frolll B t.o A, we say tha.t
B <;noPI A (B inherits incomplete frolll A) iff
(there is a a E [A : (there is abE [B : (T(b) = a)))
We say that the elements of FA n t-B 8 arc inlwrit.ed frolll A by lJ.

Note that from this definition it follows that

In the case of incomplete inheritance, the linking function is not necessarily surjective, as not
all data-element- or method-descriptions of class A need to be inherited from A by B. An
example of this can be fOllnd ill figure 11, where we have ret.ained the name of the inherited
items from CLOCK in ALARM. The linking function is obvious from the figure.
Similarly to t.he previous case, in the situation of figme 11 we can make t.he observation that
DALARM = {wake_up_time,time} and MALARM = {seLwake_up_time,set_time}. Of course it
is possible that class CLOCK, in its turn, inherits the description time from another class. This
8w hich are data-descriptions in V An Vn or method-descriptions in MA n Mn

15
 Class
Name
CLOCK-DATA
Inheritance
none
Data-de8cription"
time : ...
M cthod-description"

Class
Name
CLOCK..METHODS
Inheritance
complete from CLOCK-DATA
Data-riesc1'iptions

M elhod-descriplions
set_time : ...

Class
Name
ALARM
inheritance
complete from CLOCK...METHODS
Data-descriptions
wake_up_time : ...
M eihod-descriplions
set_wake_up_time : ...

Figure 10: Complete inheritance (linear).

could even he the description wake_up_time from class ALARM!. nut in the last-mentioned
case, one would not. a.llow that. wake_up_time inherits from time. Hence, also incomplete
inheritance must ohey some form of lineari ty.
The use of incomplete inherita.nce as described above, is problematic. The reason is that
set_time might lise the data-element. duaLtime. Not inheril.ing t.his data-dement renders
set_time in ALARM useless. The programmer or compiler must check on the occurence of
such illconsiRtent. incomplet.e illheritanc(' chains. Also from a 11I0re formal sta.ndpoint there
is a drawhack: incomplet.e inheritance no longer implies subtyping, e.g. if not all visible
methods and da.ta-elements arc inherited. Therefore it will not be a surprise that inCOlnplete
inheritance ha.rdly ever occurs.
Another gelleraJiza.t.ion of complete inheritance is mulhple complete inheritance. Data-elernent-
descriptions and method-descriptions may be inherited from more than one class. In this case,

16
 Class
Name
CLOCK
Inheritance
none
Do la-descriptions
time : ...
duaLtime : ...
M ethod-descl'ipti01/.S
set_time : ...

Class
j\lame
ALARM
Inheritance
time, set_time from CLOCK
Data-de sCl'iptions
\lake_up_time : ...
M ethad-descript.ions
set_wake_up_time : ...

Figure 11: Incomplet.e inheritance (simplified).

our linking function should not. only express which name is mapped to whieh name, but also
from which cla.ss it stems. \Ve create t.he c:t:lcndcd linkin.g function:

Definition 4 E"lended linkin!] IUIle/.iall.

Given a class Band a. set. S of classes with t.he propert.y t.hat B 'I S, we caU T an extended
linking function from B to S iff

T E ([B -", U [{A} * [A])

AES

The ext.ended linking function gives us for each of the inherited dat.a-element.s and methods
a tuple which contains the class-name (as a label) and t.he dat.a-clement- or method-name to
which it is mapped. Mult.iple cOlllplet.e inherit.ance call 1I0W be defined as follows:

Definition 5 Multiple complete inhel·itance.

Given a class B, a set S of classes with 1J 'I S, and an extended linking function T from B to
S, we say that
E <:"p, ep' S (E inherits multiple complet.e from S) iff
(for all A E S : B <::, A), whl'l'e TA is t.he projection of T all A (with t.he class-label A
omitted).
We say t.hat. t.he elelllent.s of UAES [A an' inherited by B from S.

17
 Class Class Class
Name Name Nanw
SILVER-BELL CLOCK GOLDEN-BELL
Data descriptions Data descriptions Data descriptions
time : .. . time : ... weight : ...
Method descriptions color : ... M et.hod dese'riptions
set : ... Method descriptions set : . ..
reset : ... set_time : ... reset : ...

Class
Name
ALARM
Data deSC1'iptions
time : ...
duaLtime : time (from SILVER-BELL)
wake_up_t ime : time (from CLOCK)
background_color : color (from CLOCK)
gross_weight : weight (from GOLDEN-BELL)
Method riescriphons
set : set (from SILVER-BELL)
reset : reset (from SILVER-BELL)
set_wake_up_time : set_time (from CLOCK)
set-llros s_we ight : set (from GOLDEN-BELL)
reset-llross_weight : reset (from GOLDEN-BELL)
ring : ...

Figure 12: Multiple complete illlleritance.

In this definition, the surjective property for the extcuded linking function means that for
every class A E .') we have that for every data-element and met.hod of A, there is a data-
element resp. lllethod in B that is lllapped t.o that one. An exalllple t.hat illust.rates multiple
complete inheritance is given in figure 12. The extended linking function belonging to this
example is:
{( duaLtime,(SILVER-BELL,time)), (wake_up_time,( CLOCK,time)),
(background_color ,(CLOCK,color)), (gross_weight,( GOLDEN-BELL,weight)),
(set,(SILVER-BELL,set)), (reset,(SILVER-BELL,reset)),
(set_wake_up_time,( CLOCK,set_time)), (set-llross_weight,( GOLDEN-BELL,set )),
(res et-llross _we ight ,( GOLDEN-BELL ,res et )) }.
As before one ca.n run into the problem of na.me-clashes: l'Cfering to two methods or two
data.-eleulents with the same namC'. For exa.mple: in t.he a.bove inheritance scheme, we cannot
inherit the description of time under this name from both class SILVER-BELL and class CLOCK
wit.hout introducing an ambiguity. The solut.ion uscd iu tile figure is to perform an appropriate
renaming 9. We will discuss some alterna.tive solutions.
9This, however, does not solve the problem entirely. Consider, e.g., the case where duaLtime and

18
 Class
Name
ALARM
inheritance
multiple preferred:
SILVERJ3ELL -<p.t CLOCK -<p.t GOLDENJ3ELL
Data-descriptions
time : ...
M elhod-desc7'iptions
ring : ...

Figure 13: The preference relation for mult.iple incomplete inherit.ance.

The 1Il0st obvious solution t.o na.me-cla.shes is 1.0 demand t.ha.t. all names be different:

[for all A"A 2 : A, E 5 II A2 E 5 II A, # A2 : EAl n EA, = 0J.

However, this places quite a burden upon the designer of the classes and it violates the
principle of modularity. E.g., t.he designer of a new cla.ss A should not be concerned about
names of possibly even hidden data-elements of another class B, just. because at some later
point. in time someone may decide to int.roduce a class that inherits form both A and B.
Therefore, this solution is ina.ppropriate. It. is remarkable, however, that this solution is
nevertheless chosen in some existing object-oriented languages.
A second alternative ta.kes us from multiple complete inhcrita.nce t.o a special form of multiple
incomplete inheritance. We a.dd a. linear orderi ng (a. so-called preference relation) to the set
{B}US. In this ma.nner we crea.te a chain, frolll which t.he first. cla.ss is the most. preferred one,
and the last class t.he least. preferred. The pnrpose of t.his cha.in is t.o introduce a. priorit.y: in
case of all ambiguity for a. reference of a. data-clement or met,hod, we take the most preferred
class.
This obviously requires tha.t B is alwa.ys t.he first. class in the chain (note t.hat if we find the
descript.ion t.here, it. is act.ually not. a case of inherit.ance, but just. description-lookup). In
the da.ss under consideration, we only list the chain from t.he second element. onwards, as we
know that t.he class itself is always the first clement.
In the above example, we could have t.lle followiug ordering (from most to least preferred):
SILVERJ3ELL -<p.c CLOCK -<p.t GOLDENJ3ELL. Class ALARM (a more simple one than the one in
figure 12) could look like the Olle in figure l~.
The inherit.ance relat.ion in t.hat example implies that VALARM = {time, color, weight} and
that MALAM = {set, reset, set_time, ring}. The description of data-elernent. time is obvi-
ously in class ALARM (as being t.he most. preferred), for color ill class CLOCK and for weight
it can be found in class GOLDENJ3ELL. 1"01' t.he met.hods set and reset the description is in
wake_up_time are derived from a single data-element of a common ancestor class. If in this so called repatd~
inheritance situation an object is an instance of the class ALARM the ambiguity in the selection of implementation
remains if the data-element is addressed as an element of the common ancestor. We refer here to the mecha-
nism of dynamic binding which is not further discussed in this paper. A more extensive treatment of this issue
can be found in [Meyer 88].

19
 Class
Name
GOLDEN-BELL
Inheritance
none
Data- descriptions
time : ...
Method-descriptions
set : ...
Class
Class
Name
Na me
BELL
CL OCK
Inheritance
Inher itance
multiple preferred:
no ne
GOLDEN -BELL
Data-des criptions
Data-descriptions
time
color : ...
Method-d escriptions
Method-descriptions
set_tim e :
set : ...
Class
Name
ALARM
Inheritance
multiple preferred:
BELL -<pri CLOCK
Data-descriptions
weight: ...
Method-descriptions
reset : ...

Figure 14: Linearity ill multiple preferred inheritance.

SILVER-BELL (being preferred above GOLDEN-BELL), for set_time in class CLOCK, and ring is
described in class ALARM itself.
There are some drawbacks in this solution, however, which can be seen in the example. (1)
Suppose we would want to use set of class SILVER-BELL a.nd reset of cla.ss GOLDEN-BELL.
There is no preference relatioll that lets ALARM inherit both of these methods. (2) The prefer-
ence rela.tion has an effect which is kllOWli a.s overriding. A dat.a-element or method (J from
a class C overrides the data-element or method with the same name from another class D
only if C is more preferred thall D. The preference mechanism therefore destroys the relation
between inherita.nce and suhtypillg: if A iuherits from B this no longer implies that A is a
subtype of B.
The multiple inheritance as described, with preference relation, we call multiple p"eferred
inheritance. We will denote it by <;:'''pl pri' An exact definition we consider outside the
scope of this pa.per.
Of course, also in the ca.se of multiple preferred inherita.nce, we desire linea.rity. Any class

20
 I/eight; reset (ALARM)

-------- ----------
color; set (BELL) time; set_time (CLOCK)
I
time; set (GOLDENJlELL)

Figure 15: The tree of the preference relation.

Ai E S can inherit multiply preferred from a set of other classes. Therefore preference can
be no longer interpreted as a chain. It is more like a tree, or even a graph, in which case we
should be very careful with our inheritance. An example of this is given in figure 14. In this
example, class ALARM inherits color from BELL, set from BELL and set_time from CLOCK.
But what about time'! Where cioes that come from'! There a.re two basically ciifferent ways
to resolve the conflict, corresponding to a br-eadlh-first resp. a depth-first search strategy in
the tree of the preference relation. Using the breadth-first a.pproa.ch, we get time from CLOCK,
with depth-first we get it from GOLDENJlELL, via BELL I".
Most approaches choose this depth-first strategy, and therefore we will also do so. The tree
for the example looks like the one in figme 15.
From this example it will be clear that it is quite hard for a programmer to keep track of the
inheritance structure. Therefore, it should be used with lots of care.
One could consider other forms of inheritance. Most of these, however, can be classified
among the a.bove. As we mentioned before, incomplet.e inheritance is not frequently used.
Complete a.nd multiple preferred inheritance are the most popular forms.
The way we have descrihed inherit.ance thusfar does not give us a flexible mechanism at
runtime. During execut.ion of a. progra.m, objects h<'!,vc a. fixed set of data-elements and
methods. In recent research (sec [Shriver and Wegner 87]), however, there is more emphasis
on having a flexible set. Especially with methods it seems llseful to be able to change, add
or subtract some definitions from this set. Following this approach, inheritance is taken
from class-level to object-level. No d~scripton are inherited, but definitions (actual code).
Therefore, we call this form runtime inheritance. (See [Hailpern and Nguyen 87].)
A Inajar problem that a.rises in this respect is tha.t. of consistency with class-level inheritance.
The restriction that all objects of the same class inherit data-elements and methods from
one or more cla.sses is no longer a requirement. Objects of the same class can therefore have
different sets of dat.a-elemclIts and methods. Or, seen otherwise, lIew classes can be created
at runtime a.nd objects can change their class!
A second problem is that inherit.ance is not [rom classes, but from objects. As objects of
the same class can now have different. sets of data-elements and methods, it is not possible
to choose an a.rbitrary object of a. cla.ss t.o inherit from. A solution often encountered is the
use of prototypes (see [Lieberma.n 86]). For every class, aile object is designated as the object
lOWith data-hiding in mind, we note the following. In the lastmentioned case, the class ALARM does not
know that it inherits time from GOLDEN..BELL. It only knows that it inherits the description from BELL (which
in turn gets it from GOLDEN...BELL).

21
from which inheritance takes place. A mechanism known as delegation (see further on) is then
frequently used to implement the inherit.a.nce. Prolog++ (see [Prolog++ 90]) is an example
of a language which uses this solutioll.

7 Inter-object communication: messages

Up to now, we have only discussed individual objects, classes and relat.ions between them.
We have intentionally left out. the discussion on programming. In this section we will show
how object-orientation is related to programming.
Thus fa.r, a. progl'anl consisted of a set or dasses, with which we were a.ble t.o crea.te objects in
the system. But this is not enough, as object.s are unable to perform any action without being
triggered (remember that our object.s do not have bodies, i.e. processes that get executed upon
creation of the object; cf. Section 2). A st.at.ic set of objects merely forms a description, but
is unable of performing a.ny a.ction. Objects should be able to comHlllllicate in order to create
a dynamic structure.
ComlIlUllication in object-orient.ed languages is performed by the aid of messages. Messages
can be sent from any object to a.ny other ohject. to which it holds a reference. The receipt of a
message triggers that object. t.o perform an action, provided that the external interface of the
object "recognizes" the message. A message therefore can be seen as a. package containing the
names of a sender-object and a receiver-ohject, plus a. met.hod to be invoked in the receiver,
with a. nOll-negative Humber of arguments for the method.
Objects can be active or inactive. In a system, the only active objects at anyone moment
are those that have been triggered by t.he receipt. of a message, but have not yet finished the
execution of the method invoked. All ot.her object.s are inact.ive.
There a.re two distinct ways of cOllllllllnicatioIl between objects. vV(' can have synchronous or
asynchronous message passing. The diI1{'rcllce is described in [America and RutJ,en 89], and
ca.n be explained in short a.s follows.
';Yith synchronous communicatioll, the SPilde)' wait.s for a. ret.urn value once a message has
been sent (a kind of hand-shaking mecha.llism). This signals the completion of the method.
During this wait the sending object is inactive. It becollles active again (it was active before
sending the message) after the receipt. of the return value.
It can easily be seen t.hat. using t.his way of wllllllunica.t.ion, we always have exactly one object
which is active (we assume that initially we have one active object).
Actually, we can spea.k of two different fOl'1I1s of messa.ge-passing, namely implicit. and explicit
messa.ge passing.
IInplicit Inessa.ges are messa.ges which are sent by t.he communica.tion protocol - like the
inheritance lllCcha,nislll ~- 01' c01llpletion lllessa.ges. No object has code for these messa.ges;
there is no such thing as a send cOllulla.nd fo1' implicit messages.
\iVith explicit messages t.his is different. These arc t.he messages t.hat a.re evoked on t.he request
of the user of the progra.m. Therefore tlwse messages must be explicitly coded.
The return value of synchronous cOllllllunica.tion is sent as a. so-called completion message; this
is a.n example of an implicit messa.ge. It evokes a. special code which handles "completion".
With a.synchronous cOlllll111nicatioll, we do not require the sender 1.0 waH for the completion
of a. method. Upon sending a messa.,ge, the sender stays act.ive and proceeds with the next

22
operation. This way, we can have multiple objects active at the same time. Obviously, we
introduce some parallelism.
Moreover, we introduce a problem known as scheduling. Suppose we ha.ve an object which at
the same moment receives two messages invoking the same method. Which message should
be given priority, or should both Illessages be granted access a.\ the same time, and what is
then the effect? Or suppose that the object which receives the messages is already executing
the requested method, because it received an ea.rlier message for it. What happens then?
This scheduling problem is not related to a.synchronicity, but more to parallelism. Therefore,
we will not attempt to solve all the above-ment.ioned problems. On t.he ot.her hand, we do feel
that objects, independent as they are, should he allowed to execute their methods in parallel
whenever possible.
In reality, it is impossible to ha.ve a. 1llccha,nislll which schedules messa.ges and guara.ntees that
a message sent will eventually be processed unless the method invoked aborts or ends up in
an infinite loop. Individual starvation can be prevented by guarantees on the language level,
hut the prevention of deadlocks is a task for the programmer.
II is clear that an object can send a message which conta.ins a reference to itself as an argument.
In most languages, for this purpose the reserved word SELF is used in the description of the
method. Especially when used with delegation (see helow), a. lot of attention should be paid
to the question which objects arc supposed to receive a completion message.
Data-elements are global to all Illethods of t.he object,. Therefore, if we ha.ve a message
sent to the object itself, the activated method acts upon the same data-elements as the
sending method does. In fact, we have some kind of ill/01lt pamm,ctc,. passing. When we use
asynchronous communication, this leads t.o problems. We will demonstrate this by means of
an example; sec figure 16. The sCll(ling of messages is execut.ed there by the (built-in) method
send.

Object
Name
alpha
Class-Name
A
Da/.a-elements
n
Me/hod"
run = { if n:::;l0 ...., n:=n+l ;
send(SELF,run);
n:=n-l j
print(n)
0 n=ll ...., skip
fi
}

Figure Hi: The printillg of some lIat.uralnulllbers.

The idea. of the example is to prillt. t.he Humbers () ... 10 ill decreasing order. Method

23
run is used for this purpose. Suppose that n has initial value O. If we use synchronous
communication, the following is happening. Upon activation, the object increases the value
of n, creates a new invocation of t.he method run and makes t.he old invocat.ion inactive. This
process repeats it.self for n = 0 up to 10. That is to say: the object keeps on sending messages
to itself until n reaches the value of 11. This is the "first round".
In the second round, each invocation becomes reactivated by a completion message from the
invocation it crea.ted. This (re- )a.ct.ivatioH t.a.kes pla.ce ill the reverse order. In each step,
starting with n, the method does nothing but. sending a completion message to the object, in
response t.o which the object. decreases n by 1 ami prints the number obt.ained. In a stack-like
fashion we now will get the numbers O ... 10 in decreasing order.
However, if we use asynchronous communication in this example, we can get completely
different results. After the ftrst message from object alpha to itself, it is not gua.ranteed that
the next. event. in time will be the sending of another message. As the sender of the first
message does not. wait. for the completion of a met.hod, it. ca.1I very well be t.hat the first print
statement is execut.ed before the first message is even received. In that case, the first number
printed can be O.
An interesting application of nlessage pa.ssing is delegation, which is a manner to simulate
inheritance. With delegation, one supposes that. every object. tries first. to answer a message
itself. But if it fails to do so, it should forward the message to another object. l l that is of
the class from which it was originally intended to inherit. Most languages allow objects to
be created dynamicaUy (at runtime). In order to determine the set of data-elements and
methods of such a created object, one may lise the prototype of t.he class to which the new
object will belong. If no prototypes are available, objects ca.n be created as copies of others.
Some approaches even allow morc flexibility in object creation, and allow the programmer
to define (parts of) the set. of dat.a-elcmcllt.s and methods. This way, cla.ss-less objects can
be created. Or equivalently, neW classes can be created at runtime. We feel that too much
flexibiHt.y in object. crea.tion, just like 1.00 1IIuch f1exibilit.y iJl inherit.a.nec st.ruct.ure, is harmful
to a language, because it places too high a burden on the programmer to ensure that the
correct comhination of data. elements a,nd methods is present.

8 Overview
In this paper, we ha.ve tried to build a model for the object-oriented approach. Not all the
details of the model have been worked out.. Ou t.he other hand, we sketched several directions
in which the model can be elahorated.
In the introduction of the model we described how to a.bstract from reality into an abstract
model. The basic modules in the model are called objects. A program in the model consists
of a number of objects. We added the concepts of data-hiding and data-abstraction to our
model, thereby creat.ing classes. These classes were meant to group objects together, based on
internal specification. An alternative way of grouping objects, based on external specification,
was introduced in the form of the concept of type.
Next, we introduced inheritance in several forms, in order to show the possibility for modular
dcveloplllent. of progrmlls. Inheritance is genera.lly cOllsidered to be one of t.he main features

llThe prototype mentioned before.

24
of object-oriented programming. Therefore we treated this notion extensively. Inheritance in
our view is a relation between classes. There arc alternatives 1ike runtime inheritance, which
has also been discussed. We mentioned t.lla.t. too milch flexibility in inheritance structure can
be harmful to a language, as programmers cannot easily keep the inheritance tree in mind.
Finally, we noted that a static model is not very interesting, nor representative for reality.
Therefore we provided programs in our model with a message-passing mechanism. Messages
can be sent from any object to any ot.her object. Two distinct ways were discussed, namely
synchronous and asynchronous message passing. We mentioned the problem of scheduling
and how to use message-passing in implellleuting inherita.ncc, a. technique known as delega-
tion. The lnessage passing mechanism itself was not treated extensively. In fact, this is an
implementation issue that we are not dealing with here.
In short, we have given a lllOdel for object-oriented programming, based on several notions
and interpretations that can be found in t.he literature. Part of this literature is mentioned
in our list of references. W'e have tried t.o synthesize the best parts and create a useful
reference for anyone looking for ii. basic and genera.l introduction to the majn concepts in
object-oriented programming. Our discussion might. a.lso be useful if one tries to establish
what object-oriented feat.ures one desires to he part of a language that is to be used in a
soft.ware project.

9 Conclusions
This paper discusses the main problems concerning the nature of object oriented program-
ming. What does it mean if a program is called object. oriented, what features should then
be present?
In the litera.tnre, several aspects of object.-oriclIted progralllming arc treated in different ver-
sions. There is no complete a.greelllent, not. even with respect to the lIIost fundamental
concepts.
We have tried to compose an overview of \vlt<-l.t are considered the import.ant aspects of object.-
oriented programming. We have t.ried to point. Ollt. the st.rengt.h and weakness of each aspect.
Exist.ing object-orient.ed languages usua.lly olfer a subset, of t.hese possibilities.
We sumlnarize the results of our investigations:
• Inheritance should be used with care
A complicated inherita.nce tree makes it. very hard for a designer to determine the data-
element- and method-descriptions present. iu a class, and a.lso ma.kes it hard to re-use them,
as the insertion of a new class in the tree may change a lot. Incomplete inheritance is even
lIlorc dangerous, as the inheritance of <}, 111<-'t.hod docs not. guarantee that it can be executed
(suppose it uses a.nother method which is not. initerited). Furt.her, we feel tha.t inheritance is
a compile-t.ime issue, at descript.ion level. However, some la.nguagcs promote it. to runtime,
and t.reat classes as objects. Here it becomes very hard t.o reason about. a program. Herewith
one introduces a. kind of self modifying code, a.s objects ca.n change their set of data.-elements
and methods .
• Object-orientedness is not a programming language feature but a design feature

25
We have modeled reality into an abstract Illodei. This abstract model has the object-oriented
features like objects and classes. A programming language can offer or enforce object-
orielltedness by offering ways to illlplcmellt. these objects and classes. But a.s a program
is the solution of a problem existing in reality, the process .of designing the program should
be object-oriented, not (only) the programllling language .
• Object-oriented programming is inherently imperative
In object-oriented approaches, some of the main aspects are messages a.nd states. Eliminating
the states abolishes classes, lea.ving out messages makes computation impossible. Both are
basic a.spects, and the result of a Itlessage depends on the st.ate of t.he object that receives it.
As states change in time, due to transformations of the object, and since the system is fully
determined by the states of all objects, object-oriented programming is imperative.

References
[America and Rutten 89J P.H.M. America., .T.J.M.M. Rutten, A pamllel object-oriented lan-
yu.age: design and semanticfo1lndations, in .T.W. de Bakker (ed.): Lang1lagcsfor Parallel
Ar'chitectm'£s, Wiley, 1989, pp. 1 - 4~).

(America 90] P.H.:rvL America, A behav£ouml app1vach 1.0 sublyping in. o~ject-l'ind pro-
gmmming languages, ill Inheritance lfieml'chics in j{nowlerige RcprC8crltation and Pro-
gmmrning Languagcs, Wiley, 1991, Pl'. 17:l - 190.
[Bruce a.nd Wegner 86J K.B. Bruce, P. Weguer, An algeb1'O.ic model of subtypes zn object-
oriented languages, in SIGP/,AN Notices, Vol. 21, No. 10, Oct 1986.

[Cook et a1. 90J W.R. Cook, W.L. Hill, r.s. Ca.nning, Inheritance i8 not subtyping, in Pro-
ceedings of the l1h Annual ACM Sy1nposiwn on Principles of Programming Languages,
ACM-Press, January 1990.

[Dahl et. a1. 72J O-J. Dahl, E. W. Dijkst.ra, C.A. R. Hoare, Structmcd P1'Ogm.mming, Academic
Press, New York, 1972.

[Dowty et al. 81J D.R.. Dowt.y, R.E. Wall, S. Pet.ers, Intmriuction to Montague Semantics,
Reidel, 1981.

[Goguen and Mesegucr 87J .l.A. Goguen, .1. l\1eseguer, Unifying Func/.ional, O~iect-rnd
and Relational F1'Ogmmming wi!.h. Logical Sem,,,,!.ics, Report. CSLI-87-93, Center for the
Study of Language and Informa.t.ion, St.a.nford University, Palo Alto, 1987.

[Hailpern a.nd Nguyen 87J Hailpel'1l, B. and Nguyen, V., A model for object-based inheri-
tance, in: B. Shriver, P. vVegllcr, eds., Research Directions in Objccl-01'1:ented Progmm-
ming, MIT-Press, 1987.
[Halbert and O'Brien 87J D.C. Halbert., P.D. O'Brien, Using types and Inheritance in Object-
Or·ient.ed Languages, ill Proceedings of /.he 1't Bumpea" Confer'enee on Object-Oriented
Programming, BCOOP87, Springer Lecture Notes in Computer Science 276, 1987.
[Lieberman 86J H. Lieberma.n, Using prototypical objects to implement shared behavior In
object-oriented systems, in OOPSLA '86, Conference Proceedings, ACM-SIGPLAN, Vol.
21, No. 11, Nov. 1986.

26
[MacLennan 82] B.J. MacLennan, Values and objects m programming languages, in SIC-
P LA N Notices, Dec. 1982.

[Madsen and M¢ller-Pederscn 88] L.L. Madsen, B. M¢ller-Pedersen, What object-oriented

programming may be - and what it does not have to be, in Proceedings of the 2nd Euro-
pe,m Conference on Object-Or'iented Progmmminy, ECOOP88, Springer Lectnre Notes
in Compnter Science 322, 1988.

[Meyer 88] B. Meyer, Object-oriented Software Construction, Prentice Hall, 1988.

[Nygaard 86] K. Nygaard, Basic Concepts in Object Oriented Programming, in SIGPLAN

Notices, Vol. 21, No. 10, Oct. 1986.

[Prolog++ 90] Prolog++, Progmmmin!J lIeference Manual, Version 1.0, Logic Programming
Associates Ltd., London 1990.

[Shriver and Wegner 87] B. Shriver, P. Wegner, eds., ResEal'eil Direcl.ions in ObJect-ol'iented
Programming, MIT-Press, 1987.

[Snyder 86] A. Snyder, Encapsulation and Inheritance in Object-Oriented Programming Lan-

guages, in OOPSLA '86, Confercnce Proceedings, ACM-SIGPLAN, Vol. 21, No. 11, Nov.
1986.

[Stefik and Bobrow 86] M. St.efik, D.G. Bobrow, Object-Oriented Programming: Themes and
Variations, in The AI Magazine, §, no. 4, J 986.

[Stroustrup 87] B. Stroustrup, What is "Object-Oriented Ptogmmming"?, in Proceedings of

the 1,t EU1'opean Conference on Ob.icc!.-Oricntcd Progral/1.1/1ing, ECOOP87, Springer Lec-
ture Notes iII C0111puter Science 27G, 1987.

[van del' Kallllnen 91) 11. van del' l\a,lllllWll, The logic of objects; objccl-01'icllted P7v[JTU1Tl1ning
in (l logical perspective, Master's Thesis, Eindhoven University of Technology, Dept. of
Math. a.nd Compo Scicllce, Einrlhoven, 1991.

[van Ginderen 90] B. van Ginderen, An ob.iect oriented hypertc"t systemforlear'ning, Master's
thesis, Eindhoven University of Technology, Open Univcrsiteit. Heerlen, 1990.

27
Index
abstract model, 3 extended, 17
abstraction, 4, 5 message, 22
asynchronous message passing, 22 completion, 22
body, 5 message passing,
changeability, 4, 5 asynchronous, 22
class, 8 explicit, 22
communication, 22 implicit, 22
complete inheritance, 13 synchronous, 22
multiple, 16, 19 method, 3
completion message, 22 model,
data-abstraction, 7 abstract 3,
data-element, 3 multiple complete inheritance, 16, 19
data-hiding, 7 multiple preferred inheritance, 20
delegation, 22, 24 object, 3
description, 8 overriding, 20
encapsulation, 7 preference relation, 19
enforce, 2 preferred inheritance,
explicit message passing, 22 multiple, 20
extended linking function, 17 prototype, 21
external interface, 7 referential transparency, 4, 6
external specification, 7 relation,
hiding, preference, 19
information, 7 runtime inheritance, 21
implicit message passing, 22 scheduling, 23
incomplete inheritance, 15 SELF, 23
information hiding, 7 specification,
inheritance, 12 external, 7
complete, 13 internal, 8
incomplete, 15 state, 4, 5
multiple complete, 16, 19 subtype, 11
multiple preferred, 20 support, 2
runtime, 21 synchronous message passing, 22
interface, system, 3
external, 7 transparency,
internal specification, 8 referential 4, 6
linearity, 14 type, 10
linking function, 13 value, 4

28
In this series appeared:

91/01 D. Alstein Dynamic Reconfiguration in Distributed Hard Real-Time

Systems. p. 14.

91/02 R.P. Nederpelt Implication. A survey of the different logical analyses

H.C.M. de Swart "if....then ... ". p. 26.

91/03 J.P. Katoen Parallel Programs for the Recognition of P-invariant

L.A.M. Schoenmakers Segments, p. 16.

91/04 E. v.d. Sluis Performance Analysis of VLSI Programs, p. 31.

A.F. v.d. Stappen

91/05 D. de Reus An Implementation Model for GOOD, p. 18.

91/06 KM. van Hee SPECIFICATIEMETHODEN. een overzicht, p. 20.

91/07 E.Poll CPO-models for second order lambda calculus with

recursive types and subtyping. p. 49.

91/08 H. Schepers Terminology and Paradigms for Fault Tolerance. p. 25.

91/09 W.M.P.v.d.Aalst Interval Timed Petri Nets and their analysis, p.53.

91/10 R.C.Backhouse POLYNOMIAL RELATORS, p. 52.

PJ. de Bruin
P. Hoogendijk
G. Malcolm
E. Voermans
I. v.d. Woude

91/11 R.c. Backhouse Relational Catamorphism. p. 31.

P.I. de Bruin
G.Malcolm
E.Voermans
J. van der Woude

91/12 E. van der Sluis A parallel local search algorithm for the travelling
salesman problem, p. 12.

91/13 F. Rietman A note on Extensionality. p. 21.

91/14 P. Lemmens The PDB Hypermedia Package. Why and how it was
built. p. 63.

91/15 A.T.M. Aerts Eldorado: Architecture of a Functional Database

KM. van Hee Management System, p. 19.

91/16 A.J.J.M. Marcelis An example of proving attribute grammars correct:

the representation of arithmetical expressions by DAGs,
p. 25.

91/17 A.T.M. Aerts Transforming Functional Database Schemes to Relational

P.M.E. de Bra Representations, p. 21.
KM. van Hee
91/18 Rik van Geldrop Transformational Query Solving, p. 35.

91/19 Erik Poll Some categorical properties for a model for second order
lambda calculus with subtyping, p. 21.

91/20 A.E. Eiben Knowledge Base Systems, a Formal Model, p. 21.

R.V. Schuwer

91/21 J. Coenen Assertional Data Reification Proofs: Survey and

W.-P. de Roever Perspective, p. 18.
J.Zwiers

91/22 G. Wolf Schedule Management: an Object Oriented Approach, p.

26.

91/23 K.M. van Hee Z and high level Petri nets, p. 16.
LJ. Somers
M. Voorhoeve

91/24 A.T.M. Aerts Formal semantics for BRM with examples, p. 25.
D. de Reus

91/25 P. Zhou A compositional proof system for real-time systems based

J. Hooman on explicit clock temporal logic: soundness and complete
R. Kuiper ness, p. 52.

91/26 P. de Bra The GOOD based hypertext reference model, p. 12.

GJ. Houben
J. Paredaens

91/27 F. de Boer Embedding as a tool for language comparison: On the

C. Palamidessi CSP hierarchy, p. 17.

91/28 F. de Boer A compositional proof system for dynamic proces

creation, p. 24.

91/29 H. Ten Eikelder Correctness of Acceptor Schemes for Regular Languages,

R. van Geldrop p. 31.

91/30 J.C.M. Baeten An Algebra for Process Creation, p. 29.

F.W. Vaandrager

91/31 H. ten Eikelder Some algorithms to decide the equivalence of recursive

types, p. 26.

91/32 P. Struik Techniques for designing efficient parallel programs, p.

14.

91/33 W. v.d. Aalst The modelling and analysis of queueing systems with
QNM-ExSpect, p. 23.

91/34 J. Coenen Specifying fault tolerant programs in deontic logic,

p. 15.

91/35 F.S. de Boer Asynchronous communication in process algebra, p. 20.

J.W. Klop
C. Palamidessi
92/01 I. Coenen A note on compositional refinement, p. 27.
I. Zwiers
W.-P. de Roever

92/02 I. Coenen A compositional semantics for fault tolerant real-time

I. Hooman systems, p. 18.

92/03 1.C.M. Baeten Real space process algebra, p. 42.

1.A. Bergstra

92/04 I.P.H.W.v.d.Eijnde Program derivation in acyclic graphs and related

problems, p. 90.

92/05 I.P.B. W. v .d.Eijnde Conservative fixpoint functions on a graph, p. 25.

92/06 I.C.M. Baeten Discrete time process algebra, p.45.

I.A. Bergstra

92/07 R.P. Nederpelt The finc-structure of lambda calculus, p. 110.

92/08 R.P. Nederpelt On stepwise explicit substitution, p. 30.

F. Kamareddine

92/09 R.C. Backhouse Calculating the Warshall/Aoyd path algorithm, p. 14.

92/10 P.M.P. Rambags Composition and decomposition in a CPN model, p. 55.

92/11 R.C. Backhouse Demonic operators and monotype factors, p. 29.

I.S.C.P.v.d.Woude

92/12 F. Kamareddine Set theory and nominalisation, Part I, p.26.

92/13 F. Kamareddine Set theory and nominalisation, Part II, p.22.

92/14 1.C.M. Baeten The total order assumption, p. 10.

92/15 F. Kamareddine A system at the cross-roads of functional and logic

programming, p.36.

92/16 R.R. Seljee Integrity checking in deductive databases; an exposition,

p.32.

92/17 W.M.P. van der Aalst Interval timed coloured Petri nets and their analysis, p.
20.

92/18 R.Nederpelt A unified approach to Type Theory through a refined

F. Kamareddine lambda-calculus, p. 30.

92/19 J.C.M.Baeten Axiomatizing Probabilistic Processes:

1.A.Bergstra ACP with Generative Probabilities, p. 36.
S.A.Smolka

92/20 F.Kamareddine Are Types for Natural Language? P. 32.

92/21 F.Kamareddine Non well-foundedness and type freeness can unify the
interpretation of functional application, p. 16.

;:f
92122 R. Nederpelt A useful lambda notation, p. 17.
F.Kamareddine

92/23 F.Kamareddine Nominalization, Predication and Type Containment, p. 40.

E.Klein

92124 M.Codish Bottum-up Abstract Interpretation of Logic Programs,

D.Dams p. 33.
Eyal Yardeni

92125 E.Poll A Programming Logic for Fro, p. 15.

92126 T.H.W.Bcelen A modelling method using MOVIE and SimCon/ExSpect,

W.J.J.Stut p. 15.
P.A.C.Verkoulen

92/27 B. Watson A taxonomy of keyword pattern matching algorithms,

G. Zwaan p.50.

93/01 R. van Geldrop Deriving the Aho-Corasick algorithms: a case study into
the synergy of programming methods, p. 36.

93/02 T. Verhoeff A continuous version of the Prisoner's Dilemma, p. 17

93/03 T. Verhoeff Quicksort for linked lists, p. 8.

93/04 E.H.L. Aarts Detenninistic and randomized local search, p. 78.

J.H.M. Korst
P.J. Zwietering

93/05 J.CM. Baeten A congruence theorem for structured operational

C. Verhoef semantics with predicates, p. 18.

93/06 J.P. Veltkamp On the unavoidability of metastable behaviour, p. 29

93/07 P.O. Moerland Exercises in Multiprogramming, p. 97

93/08 J. Verhoosel A Fonnal Detenninistic Scheduling Model for Hard Real-

Time Executions in DEDOS, p. 32.

93/09 K.M. van Hee Systems Engineering: a Fonnal Approach

Part I: System Concepts, p. 72.

93/10 K.M. van Hee Systems Engineering: a Fonnal Approach

Part II: Frameworks, p. 44.

93/11 K.M. van Hee Systems Engineering: a Fonnal Approach

Part III: Modeling Methods, p. 101.

93/12 K.M. van Hee Systems Engineering: a Fonnal Approach

Part IV: Analysis Methods, p. 63.

93/13 K.M. van Hee Systems Engineering: a Fonnal Approach

Part V: Specification Language, p. 89.

93/14 J.CM. Baeten On Sequential Composition, Action Prefixes and

J.A. Bergstra Process Prefix, p. 21.
93/15 J.C.M. Baeten A Real-Time Process Logic, p. 31.
J.A. Bergstra
R.N. Bol

93/16 H. Schepers A Trace-Based Compositional Proof Theory for

J. Hooman Fault Tolerant Distributed Systems, p. 27

93/17 D. Alstein Hard Real-Time Reliable Multicast in the DEDOS system,

P. van der Stok p. 19.

93/18 C. Verhoef A congruence theorem for structured operational

semantics with predicates and negative premises, p. 22.

93/19 G-J. Houben The Design of an Online Help Facility for ExSpect, p.21.

93/20 F.S. de Boer A Process Algebra of Concurrent Constraint Program-

ming, p. IS.

93/21 M. Codish Freeness Analysis for Logic Programs - And Correct-

D. Dams ness?, p. 24.
G. File
M. Bruynooghe

93/22 E. Poll A Typechecker for Bijective Pure Type Systems, p. 28.

93/23 E. de Kogel Relational Algebra and Equational Proofs, p. 23.

93/24 E. Poll and Paula Severi Pure Type Systems with Definitions, p. 38.

93/25 H. Schepers and R. Gerth A Compositional Proof Theory for Fault Tolerant Real-
Time Distributed Systems, p. 31.

93/26 W.M.P. van der Aalst Multi-dimensional Petri nets, p. 25.

93/27 T. Kloks and D. Kratsch Finding all minimal separators of a graph, p. II.

93/28 F. Kamareddine and A Semantics for a fine A-calculus with de Bruijn indices,
R. Nederpelt p.49.

93/29 R. Post and P. De Bra GOLD, a Graph Oriented Language for Databases, p. 42.

93/30 J. Deogun On Vertex Ranking for Permutation and Other Graphs,

T. Kloks p. 11.
D. Kratsch
H. Millier

93/31 W. Korver Derivation of delay insensitive and speed independent

CMOS circuits, using directed commands and
production rule sets, p. 40.

93/32 H. ten Eikelder and On the Correctness of some Algorithms to generate Finite
H. van Geldrop Automata for Regular Expressions, p. 17.

93/33 L. Loyens and J. Moonen !LlAS, a sequential language for parallel matrix
computations, p. 20.
93/34 J.C.M. Baeten and Real Time Process Algebra with Infinitesimals, p.39.
J.A. Bergstra

93/35 W. Ferrer and Abstract Reduction and Topology, p. 28.

P. Severi

93/36 J.C.M. Baeten and Non Interleaving Process Algebra, p. 17.

J.A. Bergstra

93/37 J. Brunekreef Design and Analysis of

J-P. Katoen Dynamic Leader Election Protocols
R. Koymans in Broadcast Networks, p. 73.
S. Mauw

93/38 C. Verhoef A general conservative extension theorem in process

algebra, p. 17.

93/39 W.P.M. Nuijten Job Shop Scheduling by Constraint Satisfaction, p. 22.

E.H.L. Aarts
D.A.A. van Erp Taalman Kip
K.M. van Hee

93/40 P.D.V. van der Stok A Hierarchical Membership Protocol for Synchronous
M.M.M.P.J. Claessen Distributed Systems, p. 43.
D. Alstein

93/41 A. Bijlsma Temporal operators viewed as predicate transformers,

p. II.

93/42 P.M.P. Rambags Automatic Verification of Regular Protocols in PIT Nets,

p. 23.

93/43 B.W. Watson A taxomomy of finite automata construction algorithms,

p. 87.

93/44 B.W. Watson A taxonomy of finite automata minimization algorithms,

p. 23.

93/45 E.J. Luit A precise clock synchronization protocol,p.

J.M.M. Martin

93/46 T. Kloks Treewidth and Patwidth of Cocomparability graphs of

D. Kratsch Bounded Dimension, p. 14.
J. Spinrad

93/47 W. v.d. Aalst Browsing Semantics in the "Tower" Model, p. 19.

P. De Bra
G.J. Houben
Y. Komatzky

93/48 R. Gerth Verifying Sequentially Consistent Memory using Interface

Refinement, p. 20.