On Interactions in the RM-ODP
Guy Genilloud, Gonzalo Génova
Departamento de Informática, Universidad Carlos III de Madrid,avda. Universidad, 30 – 28911 Leganés, Madrid, Spain
guy.genilloud@ie.inf.uc3m.es, ggenova@inf.uc3m.es
Abstract
The RM-ODP definition of interaction is subtle anddifficult to understand. On closer inspection, we find that
it is in fact invalid. We then attempt to establish theauthor’s original intentions for this concept, and toprovide an effective definition. Our investigations lead us
to discover some fundamental flaws in the definitions ofinterface and of behaviour of an object.

1. Introduction
ISO has performed excellent work with the RM-ODP
Foundations [1]. Unfortunately, this work has failed toinfluence the most popular object-oriented modelling
techniques and languages (UML being a case in point),
and methodologies. Their creators have either ignored the
RM-ODP, or failed to understand it. To their credit, somedefinitions are excessively subtle or obscure, and the RMODP lacks explanations, and references to relevant
literature.
In this paper, we analyse one of these subtle definitions:that of the concept of interaction. This definition isdependent on that of environment (of an object). Whileboth definitions may seem crisp and clear on a first read,they turn out to be meaningless since based on anapparent circularity. We then investigate whether new
definitions, making use of the concept of role, would
work. Having hopefully understood, through our analysis,
the intentions of the RM-ODP authors, we provide an
explanation for the concept of interaction. This analysis
allows us to propose alternate definitions. Finally, armed
with our new understanding that interactions have roles,
we find fundamental flaws in two RM-ODP definitions,those of interface and behaviour (of an object).

2. The Environment of an Object
The RM-ODP foundations provide this definition:
8.2 Environment (of an object): the part of themodel which is not part of that object.
NOTE - In many specification languages, theenvironment can be considered to include at least

one object which is able to participate without
constraint in all possible interactions (see 8.3),
representing the process of observation. [1]While its note is unlikely to be helpful to most readers,
this definition seems at first to be straightforward. But
now, consider the 4th note in the very next definition in
the standard, that of action:
8.3 Action: Something which happens.
Every action of interest for modelling purposes is
associated with at least one object.
The set of actions associated with an object ispartitioned into internal actions and interactions.
An internal action always takes place without theparticipation of the environment of the object. An
interaction takes place with the participation of theenvironment of the object.
NOTES
1 - "Action" means "action occurrence".
Depending on context, a specification may express
that an action has occurred, is occurring or may
occur.
2 - The granularity of actions is a design
choice. An action need not be instantaneous.
Actions may overlap in time.
3 - Interactions may be labelled in terms ofcause and effect relationships between theparticipating objects. The concepts that support thisare discussed in 13.3
4 - An object may interact with itself, in whichcase it is considered to play at least two roles in theinteraction, and may be considered, in this context,
as being a part of its own environment.
5 - Involvement of the environment represents
observability. Thus, interactions are observable
whereas internal actions are not observable,
because of object encapsulation. [1]We have 2 contradictory statements: the environment ofan object is “the part of the model which is not part ofthat object,” and “an object can be a part of its own
environment.” We assume that it is the second statement,of minor status since in a note, which is incorrect. Peter
Linington, one of the fathers of the RM-ODP, confirmed
to us that the idea of an object being part of its own

environment is metaphorical (as suggested by the phrase“in this context”). Therefore, an object cannot actually bea part of its own environment.
This metaphorical note is unfortunate, not only because it
can confuse readers of the standard, but also because it
hides the fact that the concept of interaction is ill-defined.
If taking place with the participation of the environment
is not a discriminator of an interaction (vs. an internal
action), then what is an interaction of an object? We will
investigate this question in Section 3.
As for the notion of environment, we believe that it
requires further explanations, as we discuss below.

2.1. Observability.
Studying the standard, it is clear that observability was
the main concern, if not the only concern, for introducing
the notion of environment (“Involvement of theenvironment [in an action] represents observability.” [1,Definition 8.3 Action, Note 5]). But why does the RMODP speak of observability, and not of observation?
A possible answer could be that the readers of a
specification do not know whether an observer object inthe environment actually does observe the action. That is,they do not have full knowledge of the environment of an
object – there might be objects in the environment theyknow nothing about.
But what about specification techniques, such as classical
UML [2], in which at most two objects may participate in
an interaction? When an object interacts only with itself,
no other object may observe this interaction. So why does
ODP consider such an action as observable, when in fact
it actually cannot be observed?

2.2. Asynchronous interactions.
In a recent paper [3], Peter F. Linington mentions anotherconcern for the environment of an object. As he explains,
the RM-ODP enables objects to interact either in asynchronous way (the objects are simultaneously in theinteraction, as if they were shaking hands1), or in an
asynchronous way (e.g., the exchange of a message
consists of a sequence of synchronous interactions,
initiated by the submission of the message, andterminated by its delivery). The notion of environment
plays a key role in achieving this capability:
Interactions in ODP are synchronous2, but are
defined between an object and its environment. If
1

The notion of synchronicity discussed here has nothing to dowith the notion of synchronicity in remote procedure calls.
2 P. F. Linington probably meant to write that atomic
interactions are synchronous. Otherwise, the communicationof a message, a composite action, could not be considered to
be an interaction…

we then constrain the way objects are composed sothat each object binds directly to another object inits environment, the resulting communication is
synchronous, but if objects bind to link ends in theirenvironment, the resulting communication is
asynchronous. [3]Such explanations would be interesting and very helpful
to the many object-modellers who consider that objects
only interact by exchanging messages (the authors of
UML among them). Unfortunately, there is not even ahint about this idea in the RM-ODP Foundations. There is
not even an explanation that communication links exist ina model (as binding objects), even though they are notspecified explicitly (e.g., UML and ESTELLE [4]).

2.3. Are all communications observable?
The idea of asynchronous communication via (implicit)
communication links suggests that all asynchronous
communications are observable (if an object sends a
message to itself, this composite action would beobserved by communication links in its environment).
However, was this the RM-ODP authors intention?. We
are not so sure.
The notion of observation of actions is important withrespect to behavioural compatibility3 [1, definition 9.4]: if
an object’s behavioural specification is substituted foranother, would some environment be able to notice thedifference? However, since implicit (unspecified)communication links are unable to tell other objects any
differences they may notice, should they count as
observers? We think not.
The actions of submitting a message, or delivering it,
would then never be (directly) observable (even thoughasynchronous communications may or may not be
observable). Therefore, we would have some actions(e.g., sending a message) which involve participation of
the environment, but which are neverthelessunobservable. Or perhaps, the definition of theenvironment of an object needs being revisited?
The RM-ODP definition of environment is therefore
deceivingly simple, and perhaps even misleading. The
following is a list of questions, which we think thestandard should answer:• Is the environment of an object the same thing as all
the other objects in the model?
• Are all the other objects in a model necessarily
known to a specifier?
• If an object sends a message to itself, using implicit
communication links, is that necessarily anobservable action?
3

The RM-ODP should make this point clear, as soon as
introduces the notion that some actions are observable.

3. Interactions
3.1. Which actions are interactions?
Intuitively, one would define an interaction as an actionin which more than one object participates, and aninternal action as an action in which a single object
participates. However, this is not the idea that was
retained for the RM-ODP. Instead, the participation of theenvironment was elected to be the discriminating
criterion:“An internal action always takes place without theparticipation of the environment of the object. An
interaction takes place with the participation of theenvironment of the object.” [1, Definition 8.3
Action].
This definition is unsatisfactory, for at least two reasons:1) Environment is not a crisp and clear concept, as wehave seen.
2) An object may interact with itself, without theparticipation of its environment (assuming that an
object cannot be part of its own environment).
Regarding the second point, we suppose that the authors’
intention was to classify some actions as interactions,
independently of the actual involvement of theenvironment. So, for example, when a Java runtime
object invokes one of its own methods, ODP would
categorize this action as an interaction rather than as aninternal action (because other objects may also invoke thesame method). The fact that the RM-ODP considers
interactions to be those actions that are observable [1,Definition 8.3 Action, Note 1], rather than those that are
actually observed, comforts us in this interpretation.
Involvement of the environment is therefore not anecessary criterion for an action to be considered aninteraction of an object4.

now examine if such a classification based on roles isindeed possible.
In fact, the 4th note of the RM-ODP definition of action
already makes a reference to the concept of role: “anobject may interact with itself, in which case it isconsidered to play at least two roles in the interaction”).
This yields an interesting observation: an interaction has
multiple roles. And indeed, it seems true that every
interaction has multiple roles:
1) In classical object-orientation, there is only one typeof interaction between objects: the exchange of amessage between two objects. This is a composite
interaction5 with two roles, which we may call thesender and the receiver. An object may send amessage to itself, in which case it is both the senderand the receiver of that composite interaction.
2) A rendezvous between two objects is an example ofa synchronous interaction. Such an action serves the
purpose of synchronising two activities, therendezvous being a common action in bothactivities. There are two roles because two activities
are required (otherwise, the rendezvous action
would be pointless). Generally, two different objects
will participate in a rendezvous, but it is also
possible for a single object to play both roles in therendezvous.
For every interaction type that we may conceive, it seems
indeed possible and natural to consider that it has multiple
roles. So, we may consider that an action with multiple
roles is an interaction, and that an action with just one
role, or with no role at all, is an internal action.
However, the question that we must answer is not, given
an action, whether this action is an interaction of some
object(s). Rather, the question is, given an object and oneof its actions, whether this action is an interaction of that
object, or one of its internal actions. Answering thissecond question is not straightforward, because as we will
now see, an object can be a composite object.

3.2. Roles in interactions
3.3. Interactions of composite objects
As we have seen, the RM-ODP authors deliberately
attempted to classify some unobserved actions asinteractions (observable) rather than as internal actions(unobservable). However, they failed in their attempt ofdefining a classification.
When being presented with these contradictions, Peter
Linington and Jean-Bernard Stefani, two of the mostprominent authors of the RM-ODP, proposed todiscriminate between interactions and internal actions byreferring to the notion of role [5, 6]. However, they did
not elaborate much on their respective answers. We will4

In the RM-ODP Overview, Section 7.1.2, it is said explicitly“Note that these interactions do not necessarily occur withother objects: an object can interact with itself.”

In the RM-ODP, an object can be a composite object,expressed as the composition of more elementary objects.
9.1 Composition:a) (of objects) A combination of two or moreobjects yielding a new object, at a different level ofabstraction. The characteristics of the new object
are determined by the objects being combined andby the way they are combined. The behaviour of acomposite object is the corresponding compositionof the behaviour of the component objects. [1]5This interaction is composite since composed of sub-actions,among them submitting the message onto the implicit
communications channel, and the message delivery.

Considering the behaviour obtained by pure composition(i.e., without applying any abstraction6), all the actions of
the component objects are also actions of the composite.
Obviously, any action internal to one of the components
is an internal action of the composite. And any interactionof a component object with the environment of thecomposite is an interaction of the composite. But what
about the interactions of component objects among
themselves? Are they interactions of the composite withitself, or are they internal to it?
If we were to use the criterion that an interaction hasroles, we would conclude that all the interactions among
the components are interactions of the composite. But thisconclusion would not reflect what happens in practice.
For example, most systems have communications among
their components that are not observable by external
entities.
But note that definition 9.1 says explicitly that acomposite object is defined not only by which objects
compose it, but also by how they are combined. Some
specification languages enable a specifier to declare, witha hide operator, that some interactions among thecomponent objects will be internal actions of thecomposite (therefore hiding them to the environment of
the composite; no actions are suppressed). A similareffect can be obtained by using devices such as
interceptors that make it impossible for an external object
to access some components of the composite object. In
the ODP computational language [7], the behaviour ofcomponents might be such that some interface references
are not communicated outside of the composite, making it
impossible for external objects to have interactions at
those interfaces: all interactions at such interfaces shalltherefore be considered to be internal actions of thecomposite.
In [3], Peter Linington explains that the identification ofinterfaces is a design activity. That is, it is design
decisions that allocate interactions to interfaces. The sameidea applies with respect to deciding whether aninteraction among components is an interaction of thecomposite, or one of its internal actions. Note that thedesign decision may not be left entirely to the specifier; italso depends on the specification language that he or she
uses.

4. Interactions: an explanation
We have no doubts at all that the RM-ODP authors tried
to define interactions and internal actions in a sensible
and useful way. It is no accident that they did not defineinteraction in the straightforward way, that is, as an actionin which two or more objects participate. But they failed
to provide clear and unambiguous definitions. Even moreannoyingly, we do not even know what were the authors’
intentions.
What the authors should have done was to explain thedefinitions they wrote, and in particular the intentions
behind the non-straightforward definitions. We will now
try, given our analysis and understanding of the issue, toprovide these missing explanations.
We suppose that the RM-ODP authors were very muchconcerned with the problem of writing behaviouralspecifications for objects. We also know that some ODP
authors are not always coherent with the standard, as they
entertain confusion between a term and the model
element to which it refers. In particular, they incorrectly
speak of “actions in a specification” (see for example [8]),which does not make sense since an action is “somethingwhich happens.” And of course, a specification is a static
entity in which nothing may happen. An “action in a
specification” may be explained as a term for an action ina model7. Or more precisely, it is a term for one or moreactions, as a same term can be interpreted again andagain, each time referring to a different action.
In [3], Peter F. Linington provides an example of thissituation in the context of ODP. He observes that an
object can theoretically participate in infinitely manyactions. As he explains, “most objects will have a
behaviour that allows arbitrary repetition of smaller
fragments of behaviour associated with some sort ofthread or session.” We would say instead that the term
for a fragment of behaviour (itself composed of terms foractions) can be interpreted again and again to refer todifferent fragments of behaviour8. This property isessential for enabling an object to have an infinite
behaviour, since a specification can only have a finite
number of terms. More pragmatically, this property isalso very important for writing specifications ofreasonable length, as any programmer could testify.
Thus, a term of an action generally refers to many actions.
Now, consider a term of an action that is related to actions
in which it is always the case that only one object
participates. ODP authors (we suppose) would consider
all these actions to be internal actions of this object.
Consider another term, which in general refers to an
action in which this object plays just one role, but which
may refer to an action in which this very same object
plays all the roles. ODP authors (we suppose) would
consider all these actions to be interactions of this object.
7

6

We do not understand why the RM-ODP pretends that acomposite object is necessarily at a more abstract level ofabstraction than its component objects. Surely, composition
enables abstraction, but does it always include it?

As we announced in Section 1, we use the term “model” in its
ODP meaning, and not in its UML meaning.
8 Strictly speaking, Linington’s sentence is incorrect, since afragment of behaviour, being a collection of actions(occurrences), cannot be repeated.

Our explanation is compatible with [1, definition 8.3], inwhich it is said that “An internal action always takes
place …” Since an action takes place only once, why did
the authors of the RM-ODP wrote “always takes place”?
We suppose that they were thinking about the term of theaction.

4.1. What it means to be observable
In the RM-ODP foundations, the notion of observability(of actions) is important in the context of another notion,that of behavioural compatibility (between objects):
9.4 Behavioural compatibility: An object isbehaviourally compatible with a second object withrespect to a set of criteria (see notes) if the firstobject can replace the second object without theenvironment being able to notice the difference inthe objects' behaviour on the basis of the set ofcriteria. [1]Since an ODP object is “the model of an entity” [1], it
servers no purpose to consider two objects, and to wonder
whether or not they are behaviourally compatible. The
question of behavioural compatibility is in fact about
object specifications, on whether one is compatible withthe other9. More precisely, the problem is to knowwhether an object’s environment (i.e., the environment of
the object in some model) would be able to find out
which of two possible specifications applies to this object.
Nothing is known about the object’s environment, besides
some assumptions (derived from the set of criteria in theabove definition). For the environment to observeanything about the object, it must participate ininteractions with it.
Therefore, we are talking here about many actions inmany models. What we really want to classify is not theactions of an object, but the terms of its actions in a
specification. An action term is said to be “observable” if
it refers to at least one action, in some model, which may
be observed by the environment of the object. Unless anaction term can be proven to always refer to unobserved
actions of an object, it is to be considered an “observable”
action term of the object specification10.
Thus, our explanation is that ODP considers an action to
be observable if it is referred to by an “observable” action
Whereas object is a basic modelling concept in the RM-ODP,
behavioural compatibility is a specification concept.
10 It is in general an undecidable problem to determine which
action terms of an object specification may refer to (in someinterpretation) an observed action. For that reason, theprinciple of precaution applies: in case of doubt, an action
term of an object specification is considered to be“observable.” This matters, for example, when trying todetermine whether an object specification is equivalent toanother.
9term; otherwise it is non-observable. And the name“interaction” is a synonym for “observable action”.
Thus, in a given model, some interactions of an object are
observed while others are not. But they are all considered
to be observable, in this particular ODP sense. This is thecase even though the environment, in this given model,
cannot in fact observe them. On the other hand, nointernal actions of the object are ever observed, in any
model, and they are therefore non-observable.

4.2. An alternative explanation
In a recent private communication, Peter Linington
provided us with an interesting explanation of what itmeans for an object to interact with itself, and to be insuch context a part of its own environment:“The text about an object contributing to its own
environment is in a note and is clearly not thedefining occurrence. In fact the phrase "in thiscontext" is a strong hint that the usage ismetaphorical. The point being made here is thatwhen an object interacts with itself, there is adegree of decoupling, so that the constraints on theinteraction arise from the object playing two roles,
and for each role the actions of the other are as if
from the environment. This implies that static
analysis of the behaviour of an object as aconfiguration component may indicates livenessthat is not guaranteed if the two roles are closely
coupled by the internal behaviour of the object; thesituation goes from possible liveness to necessary
deadlock.”
We do agree with the above explanation, but we are notsure that it is sufficient. We therefore choose to stick to
our own explanations, until convinced otherwise.

5. Proposed new definitions
Having (hopefully) understood the original ODP authors’
intentions, we are now in a position to propose somealternate definitions of the concepts of environment andinteraction. But first of all, we would like to stress thatwhat matters first and foremost is the message we want tocommunicate to the readers of the standard. It would bebetter to leave the RM-ODP Foundations with its current
deficient definitions, but to add proper explanations, thanto provide revised but obscure (or excessively subtle)
definitions. And after all, the new definitions might prove
be defective again, in which case the explanations would
be sorely missing.

5.1. Environment, and communications

5.2. Interactions

The following is our proposed revised definition for theenvironment of an object:
8.2 Environment (of an object): all the objects inthe model which are not part of that object.
NOTES
0- An object is never a part of its own environment.
1 - In many specification languages, theenvironment can be considered to include at least
one object which is able to participate without
constraint in all possible interactions (see 8.3),
representing the process of observation.
2- In some specification languages, an object can beconsidered to include, as parts of itself, outbox andinbox objects, even though those are not explicitly
specified. An internal outbox object enables asender object to submit a communication (see 8.9)
with its environment, without that action being
observed directly (the communication as a whole isobserved, but not its initiation). Likewise, aninternal inbox object enables the delivery of acommunication, without that action being observedby the environment of the receiver object.
Note 0 is provided here to stress the change in this new
definition from what is said in the original RM-ODP
Foundations standard.
Note 1 may need to be suppressed or amended, since it
explains the process of observation in a narrow way, valid
only in the case of some specification languages. But it
has the merit to introduce a reference to the notions ofinteraction and observation, which are the very reasons
behind the definition of environment. And they also help
with Note 2. But whether or not this not remains, it isessential for the revised standard to explain the very
reasons behind the concepts of environment andobservability.
Note 2 may need to refer to complementary explanations
regarding the exchange of asynchronous communications
between objects. In particular that a communications
channel consists of a configuration of objects, among
which an outbox object (or inbox object) which is part ofthe object itself, and other binding objects which are partsof the object’s environment. The standard should explainthat inbox and outbox objects are internal to an object forreasons of evaluating whether two object specifications
are behaviourally compatible or not. Since implicit
communication channels are beyond the control of any
specifier, it is not necessary, but preferable, to consider
that submitting a communication or receiving it areinternal actions of the sender and the receiver,respectively.

We do not see a way to define interaction without
referring to specifications and terms. We first need thisdefinition:
Observable action term (of an object): An action
term is observable in an object specification, if itrefers to at least one action, in some model, which
may be observed by the environment of the object.
Otherwise, this action term is non-observable.
NOTE: In case of doubt, an action term isobservable: if an action term cannot be proven to be
non-observable, it is to be considered as being
observable.
Internal action (of an object): an action of an
object which is referred to by a non-observableaction term in the specification of that object.
NOTE: Not a single internal action of an object isobserved by its environment.
Interaction (of an object): an action of an object
which is referred to by an observable action term inthe specification of that object.
NOTES:
1- An object may play all the roles of an interaction,in which case this action is unobserved (by thisobject’s environment). This action is still
categorized as an interaction of this object because
it is referred to by an observable action term in theobject’s specification.
2- Some specification techniques are such that anaction is referred to by several action terms. In thiscase, it is sufficient for one of these action terms to
be deemed observable for the action to be aninteraction.
Since observable in ODP has a non-obvious, counterintuitive meaning, we propose to deprecate the use of thephrase “observable action”.

6. Other issues in the RM-ODP
In our investigation, we have realized that interactions arecharacterized by having multiple roles. This fact was nottaken into account when writing some of the definitionsof the RM-ODP Foundations, which as a result areflawed.

6.1. Interface
The definition of interface needs revisiting:
8.4 Interface: An abstraction of the behaviour of an
object that consists of a subset of the interactions ofthat object together with a set of constraints onwhen they may occur.
Each interaction of an object belongs to a uniqueinterface. Thus the interfaces of an object form apartition of the interactions of that object.
NOTES
1 - An interface constitutes the part of an object
behaviour that is obtained by considering only theinteractions of that interface and by hiding all otherinteractions. Hiding interactions of other interfaces
will generally introduce non-determinism as far as
the interface being considered is concerned.
2 - The phrase "an interface between objects" isused to refer to the binding (see 13.4.2) between
interfaces of the objects concerned.[1]The second paragraph, which associates an interaction toa single interface, is wrong. It would be true in the ANSA
architecture [9], in which a binding establishes a sharedinterface between several objects. The RM-ODP waslargely inspired from ANSA, but its concept of interface
is different: an ODP interface belongs to a single object,
and an ODP binding binds two or more interfaces (see [1,definition 13.4.2] and [7, clause 7.2.3.2]). Therefore, each
ODP interaction is necessarily associated with two or
more interfaces.
It is also wrong to pretend that an interaction isnecessarily associated with a single interface of aparticipant object. Applied in the context of the ODP
computational language, such a statement would disallow
an object to bind two of its own interfaces, client andserver, and therefore to interact with itself. Peter
Linington and Jean-Bernard Stefani confirmed that these
two statements do not reflect the RM-ODP authors’
intention [5, 6].
We propose to rewrite these two statements as follows:“Each interaction role played by an object belongs to aunique interface of that object. Thus the interfaces of an
object form a partition of the interaction roles played bythat object.” The first note of the definition would need tobe revised accordingly, since the roles at other interfaces
must be hidden as well.

Knowing which role an object plays in an interaction is
critical to knowing its behaviour. For example, asking aquestion is not quite the same thing as answering it. But
the current definition of behaviour implies that it issufficient to say that an object participates in aninterrogation...

7. Summary and conclusions
In writing this paper, we spent a lot of time and efforts
trying to understand just one concept, that of interaction.
We indeed discovered that it was not really defined in the
RM-ODP. In doing so, we had to go past some subtle
statements and metaphors, and second-guess the author’s
original intentions behind them. Our work would havebeen much simpler, and more effective, had these
intentions been documented in the standard itself, or in acompanion document.
Our investigations lead us to discover some fundamental
flaws in the definitions of Interface and of Behaviour ofan object. These flaws have remained unnoticed (or atleast unreported) for more than ten years. However, when
one is armed with the understanding that interactions
have roles, these flaws are fairly obvious.
While performing our research, we came to better
appreciate the considerable difficulty of writing the RMODP Foundations: the definitions must be notation
independent (even syntax independent), grounded insemantics, very general and widely applicable, and yet
precise. Compared with other works of the same nature,
ISO has performed excellent work. Unfortunately for theobject and software engineering communities, the RMODP Foundations have not had yet the impact that they
deserve. One reason is that the standard lacks proper
explanations and references. We invite ISO experts toprovide these missing explanations, rather than just fix
the flawed definitions. After all, the new definitions mightprove be defective again, in which case the explanations
would be sorely missing.

8. References
6.2. Behaviour
Interaction roles are not mentioned at all in the definitionof behaviour in the RM-ODP, of which we reproduce
here its first sentences:
8.6 Behaviour (of an object): A collection ofactions with a set of constraints on when they may
occur.
The specification language in use determines theconstraints which may be expressed. Constraints
may include for example sequentiality, nondeterminism, concurrency or real-time constraints.
[1][1] ISO/IEC and ITU-T, "Open Distributed Processing Basic Reference Model - Part 2: Foundations,"in Standard 10746-2, Recommendation X.902,
1995.
[2] OMG, "OMG Unified Modeling Language
Specification v. 1.5," OMG, OMG Standard
March 2003.
[3] P. F. Linington, "What Foundations does the RMODP Need?," presented at Workshop on ODP
for Enterprise Computing (WODPEC 2004),
Monterey, California, 2004.

[4] ISO/IEC, "Information processing systems - Opensystems interconnection - Estelle : a formal
description technique based on an extended statetransition model," in Standard 9074, 1989.
[5] P. F. Linington, "Personal email communication,
Aug. 31," 2000.
[6] J.-B. Stefani, "Personal email communication, Sept.
22," 2000.
[7] ISO/IEC and ITU-T, "Open Distributed Processing Basic Reference Model - Part 3: Architecture,"in Standard 10746-3, Recommendation X.903,
1995.
[8] P. F. Linington and W. F. Frank, "Specification and
Implementation in ODP," presented at 1st
Workshop on Open Distributed Processing:
Enterprise, Computation, Knowledge,
Engineering and Realisation(WOODPECKER'2001), Setubal, Portugal,
2001.
[9] A. J. Herbert, "An ANSA Overview," IEEE
Network, pp. 18--23, 1994.