Conceptual Modeling of Complex Systems Using an RM-ODP
Based Ontology
Alain Wegmann, Andrey Naumenko
Institute for computer Communications and Applications
Swiss Federal Institute of Technology – Lausanne
EPFL-DSC-ICA
CH-1015 Lausanne, Switzerland
{alain.wegmann, andrey.naumenko}@epfl.ch
Abstract
The development of business and information systems
requires a significant amount of modeling. The current
modeling languages and tools have difficulties
supporting the modeling of systems spanning through
multiple organizational levels. The use of inadequate
modeling abstractions is one of the important causes for
these difficulties. This paper proposes an ontology that
defines the concepts needed for object-oriented modeling
and gives a graphical example. The ontology is based on
RM-ODP and relies on Constructivism and System
Theory. The proposed ontology allows the definition of
development methods, modeling languages and tools
that are applicable to complex systems. This can lead to
significant productivity improvements in the business
and software development communities.
1. Introduction
The e-economy (e.g. development of the business to
customer or business to business applications) and the
latest evolution in information technologies (e.g. business
protocols, components,...) strongly affect the way
enterprises are organized and how information systems
are developed and used. To adapt themselves to these new
requirements, the enterprises need to re-engineer their
overall operations. This re-engineering effort can span
through multiple organizational levels such as, for
example: the market level (e.g. supply chain), the
company level (e.g. business processes), the information
system level (e.g. system integration), the software
application level (e.g. component-based application), and
the software component level (e.g. a Java developed
component). We use the term “complex system” to
designate the set of all interacting entities found in these
various organizational levels [16, 7]. In most development
projects, each organizational level is addressed by a
different group of professionals each with their own
discipline (working methods, terminology, etc). The
challenge posed to these communities of professionals is
to develop more competitive companies faster. Our
overall research goals address the discovery and
development of modeling abstractions, tools and methods
that target this challenge. To improve the way
professionals develop complex systems, it is important to
be able to have an adequate representation of the subject
of interest (i.e. the complex system). We call this
representation the “model”. It represents what the
developer defines as the system of interest that she
perceives in her reality. The developer manipulates the
model through views that are abstractions of the model
made for a specific purpose. These views correspond to
the artifacts usually present in the development processes.
Examples of these artifacts are UML diagrams [19].
To be able to build our model, we need a precise
ontology that defines the modeling constructs. As was
noted in [15], there are multiple examples of domain
specific or even application specific ontologies that are
used for e-commerce and web-based applications. An
ontology should define a vocabulary of basic terms, a
precise specification of their meaning and relations
between them [20]. In our approach, we define an
ontology applicable for modeling any kind of system. We
base our work on the ISO/ITU standard “Reference
Model for Open Distributed Processing” (RM-ODP) [10].
The vocabulary defined by RM-ODP is sufficient
however incomplete: some terms are missing, some
definitions, those defining relationships between concepts
in particular, can be improved. This is what this paper
presents. As our goal is to model complex systems, we
also include in our approach the principles issued from
“Constructivism” and “System Theory”. These two
theories are an important corpus of knowledge describing
the key principles needed for modeling systems. These
theories were developed in the 1950s by multi-
disciplinary teams who were studying living and artificial
systems.
As a result, this paper presents an ontology that can be
used for system modeling in the development of any kind
of application (e. g. business, software, system science,
etc). Comparing it to other work, an advantage of our
solution is that it is based on the RM-ODP ISO/ITU
standard. This standard has demonstrated its usefulness
for the modeling of distributed systems.
We can also compare our work with [21]. They base
their ontological foundations on the works of Bunge [4,
5]. Their approach is interesting and has many similarities
with our results. But they omit several issues, such as the
relation between what they call “entities” (“concrete
things” in reality) and “conceptual things (i.e.
mathematical concepts such as sets and functions)”. The
fact they omit these relationships can be explained by the
absence of their formal definitions (in the form of
predicates that can be compared).
By adopting our ontology, which is based on
Constructivism and System Theory, the development
community could (1) improve the definition of the
existing modeling languages such as UML, (2) develop
tools that truly supports the modeling of complex systems,
and (3) can tightly link the methods to the tools and the
notation. This can lead to significant productivity
improvements for the software community.
This paper is structured as following: Section 2 –
development method and theoretical foundations, Section
3 – interpretation and extension of RM-ODP, Section 4 –
application of the ontology, Section 5 – impacts, Section
6 - Conclusions.
2. Theoretical Foundations
The main “theory” that we use as foundation in our
work comes from computer science. It is the “Reference
Model - Open Distributed Processing” (RM-ODP) [10].
RM-ODP is an ISO/ITU standard approved in 1996. It
provides the definitions and relations between concepts
useful to describe object-oriented distributed systems. It
positions itself as a “meta-standard” for object-oriented
modeling standards. The Object Management Group
community adopted in 1998 this standard as a base for
describing CORBA systems.
To be able to interpret RM-ODP in the context of
complex system modeling, we base our work on
Constructivism and on System Theory.
Constructivism [12] is an epistemology (i.e. “the study
of the nature of knowledge” [1]). It was developed in the
20th century. Constructivism takes its roots in Kant's
belief that intuition is an essential part of human
understanding. By taking a constructivist approach, we
acknowledge the fact that models are valid in the context
of the people or systems that develop or use them. The
consequence of this fact is the coexistence of multiple
models of the same universe of discourse. In practice, for
each system of interest, we define a sub-model that
represents its corresponding view of the universe of
discourse. The model that represents the complex system
is actually an assembly of sub-models (one per system of
interest). In summary, in line with Constructivism, we put
an emphasis on making explicit the context of the views
used by the developer. In addition, we allow the
developer to capture relationships between the sub-
models.
Systems theory was initially developed in the middle
of the 20th century [2]. It is a “trans-disciplinary study of
the abstract organization of phenomena, independent of
their substance, type, or spatial/temporal scale of
existence. It investigates both the principles common to
all complex entities and the models that can be used to
describe them” [1]. System Theory is a constructivist
theory. By including the System Theory in our approach,
we recognize the commonalities between the various
organizational levels and the fact that each organizational
level depends on each other. In addition, we leverage on
the principles identified in living systems to understand
how to structure software and business systems in a better
way. One of the principles we found especially useful is
the “teleological operation principle”. This principle
states “all phenomena (which can be modeled) are
perceived as teleologic actions (i.e. actions aimed at
achieving a project or a goal)” [12]. An example of the
application of this principle is the fact that the model is
developed to achieve a specific goal (i.e. the project’s
goal). If a different goal needs to be achieved, a different
model might have to be developed. As a consequence, the
tools should support these model variations.
RM-ODP was developed for modeling distributed
systems. Even though RM-ODP does not refer to System
Theory and Constructivism, the existing RM-ODP
definitions are compatible with the principles defined in
these two theories. By making explicit the relationships
between System Theory, Constructivism and RM-ODP,
we can better understand how to interpret and use the
standard.
3. RM-ODP as ontology for object-oriented
modeling
The RM-ODP standard [10] is composed of four parts.
Part 1 is an overview of RM-ODP and is non-normative.
Part 2 defines the fundamental concepts needed for
modeling of ODP systems. Part 3 presents an application
of part 2 for particular specification languages. Part 4 is
an attempt for formalization of the previous parts done in
Lotos [13], ACT ONE, SDL-92, Z and ESTELLE
languages. We focus our research on part 2 and we will
make few references to part 3. Parts 1 and 4 are not in the
scope of this work.
Part 2 of RM-ODP has 15 sections. The sections 1 to 4
introduce the context, references and abbreviations.
Section 5 introduces the categorization of ODP concepts.
This section is needed to understand how all the following
sections relate to each other. The sections 6 (“basic
interpretation concepts”), 8 (“basic modeling concepts), 9
(“specification concepts”) are central to our work and are
discussed in this document. The sections 7 and 10 to 15
define supplementary concepts that are beyond the scope
of this work (with exception of few concepts found in 11
(“contract”) and 13 (“client” and “server”)).
3.1. Basic Interpretation Concepts
The section 6 of part 2 “basic interpretation concepts”
introduces the concepts needed for the interpretation of
the concepts defined in the sections 8 (“basic modeling
concepts”) and 9 (“specification concepts”). The section 6
defines the concepts of:
· “universe of discourse” that corresponds to what is
perceived as being reality by the developer.
· “entity: any concrete or abstract thing of interest”
[clause 6.1].
· “proposition: an observable fact or state of affairs
involving one or more entities, of which it is possible
to assert or deny that it holds for those entities.”
[clause 6.2].
The section 6 defines also “system: something of
interest as a whole or as comprised of parts” [clause 6.5].
The notion of system allows the developer to consider a
group of entities either as one entity or as multiple related
entities. If a component of a system is itself a system, it is
called a “sub-system” of the system in which it is a
component
1
.
When modeling, the developer represents what she
finds interesting in the universe of discourse. To explain
this representation, we define the following terms:
· “model”: representation of the universe of discourse
made for a specific purpose.
· “model element”: in the model the representation of
an entity from the universe of discourse.
· “quality”: in the model the representation of a
proposition from the universe of discourse.
The Fig. 1 illustrates the relationships between the
universe of discourse and the model. Fig. 1 also illustrates
the model views (or artifacts) that represent what a
development tool shows to the developer. The model
1
We call the system, in which a subsystem is a component, a “supra-
system”. This term is not defined in RM-ODP and we take it from [16].
views are abstractions of the model made using a
modeling language. They represent the entities and their
qualities in a given context. Note that a quality in the
model is a predicate that characterizes a model element.
Similarly a proposition in the universe of discourse is a
predicate characterizing an entity. For example, a quality
such as “object” or “environment” characterizes a model
element as the predicate for its being a “model of an
entity”; “action” characterizes a model element for its
being “something that happens”.
Model
elements
Universe of discourse
Model
Entities
Model View 1 Model View 2
B
A
C
do X
H
H
Figure 1.
Relationships among what is found in the
universe of discourse, in the model and
in the model views.
3.2. Basic modeling concepts
The section 8 of part 2 “basic modeling concepts”
defines the concepts needed to describe in the model the
propositions about the entities of interest found in the
universe of discourse.
An entity can be modeled either as an object, or as part
of an object (if the object represents a system), or as part
of an object’s environment. RM-ODP defines:
· “object: a model of an entity…” [clause 8.1].
· “environment (of an object): the part of the model
which is not part of that object” [clause 8.2].
It is important to understand these two definitions from a
constructivist standpoint. An object always interacts with
its environment (and never directly with another object).
By stating this, we acknowledge the fact that each object
has its own model of its environment and that the
environment mediates the communication between the
different objects. Note that, as explained in Section 2, we
call “sub-model” the model describing an object. The
“model”, representing the overall complex system, is
composed of many “sub-models”.
RM-ODP gives additional precisions on what is an
object. It states that an object is “characterized by its
behavior and, dually by its state” [clause 8.1]. Note that
using our interpretation we can also state that the
environment is characterized by its behavior and dually its
state. To characterize an object or its environment, we
have defined two kinds of information [18]:
· “behavioral information” describing the behavior
· “structural information” describing the state
The behavioral information and the structural information
are a partition of the information on the object.
Information is defined in RM-ODP as “any kind of
knowledge, that is exchangeable amongst users, about
things, facts, concepts and so on, in a universe of
discourse” [clause 3.2.5].
RM-ODP defines the following behavioral information
elements:
· “behavior: a collection of actions, with a set of
constraints on when they may occur” [clause 8.6],
· “action: something which happens.” [clause 8.3].
RM-ODP further defines the concept of action by stating
“the set of actions associated with an object can be
partitioned into internal actions and interactions. An
internal action always takes place without the
participation of the environment of the object. An
interaction takes place with the participation of the
environment of the object.” [clause 8.3]
RM-ODP puts a great deal of emphasis on the
behavioral information. However, they put fewer
considerations on the structural information and they do
not define how the structural information is structured.
The only definition they have is:
· “state: at a given instant of time, the condition of an
object that determines the set of all sequences of
actions in which the object can take part”. [clause
8.7]
Our goal is to have the same level of details in the
structural information as in the behavioral information.
For this reason, it is necessary to add two concepts,
belonging to the structural information, and which are
dual to actions and behavioral constraints. These concepts
are:
· “structural information element”: at a given instant
in time something perceived by an object or its
environment or exchanged between the object and its
environment. The set of structural information
elements associated with the object or the
environment can be partitioned into attributes and
parameters. Attributes are accessed by internal
actions. Parameters are accessed or modified
exclusively within interactions.
· “structural constraint”: relationship between two or
more structural elements. Constraints might include,
for example, reference between structural elements or
existence within the life cycle of another structural
element.
The proposed definitions, by formulating that information
elements can be within objects (as attributes) and the
corresponding information can be exchanged between
objects and their environment (through parameters in
interactions), allow describing the information flow
between objects.
To be able to precisely model the exchanges between
an object and its environment (and thus between objects),
we need to explicitly add the concepts of:
· “client interaction: interaction initiated by an object
towards its environment.”
· “server interaction: interaction initiated by the
environment towards an object”.
With the client interaction, the object externalizes
information. At the beginning of the client interaction, the
values of a given collection of attributes are copied in the
corresponding parameters. With the server interaction, the
object internalizes information. In that case, when the
server interaction completes, the values of the parameters
are copied in the corresponding attributes. The concepts
of “client” and “server” are defined in the section 13 of
part 2.
The classification of the concept of role, initially
defined as a Specification Concept, raises an issue. RM-
ODP defines role as an identifier of a behavior [clause
9.14]. In our interpretation [9] roles and interfaces are two
kinds of behavior abstractions (role is a subset of actions
and behavioral constraints of an object participating to a
collective behavior; interface is a subset of interactions
and behavioral constraints of an object). For this reason,
we believe that role and interface should be in the same
category. We suggest putting both concepts in the basic
modeling concepts (where interface is currently defined).
This is justified by both concepts being the specializations
of a behavior. Such classification has the advantage of
allowing an application of the specification concepts to
the role and to the interface (thus allowing, for example,
the definition of role instance and role type).
It is important to note the role of time in the definition
of the basic modeling concept. Time is needed to define
state (information at a specific time). Note the state for a
moment in time will be different from the state in the
previous moment in time even if no structural element has
changed comparing with the state of the previous moment
in time (this allows modeling of “null” actions – i.e.
actions performing no changes). Time is also needed to
define actions (difference of state at different moments of
time), and interaction (information exchanged between an
object and its environment between the beginning of the
interaction and its completion).
3.3. Specification concepts
The section 9 of part 2 “specification concepts”
defines the means to be used by a developer to describe in
the model the propositions about the propositions
describing the entities of interest from the universe of
discourse.
For our discussion, we classify the specification
concepts in three categories to reflect their role in the
modeling task. (1) The “generic specification concepts”
used mainly to represent the creation/destruction and the
classification of model elements. Such concepts include
type, instance, and class. (2) The “abstraction/refinement
specification concepts” used mainly to relate groups of
model elements at different levels of detail. Such concepts
include composition and decomposition. (3) The
“schemas” that define the set of predicates needed to
define a model element.
3.3.1 Generic Specification Concepts
The generic specification concepts include type, class,
subtype / supertype, subclass / superclass, template,
instantiation (of a template), introduction, creation,
deletion, instance, template type, template class, derived
class/base class) [clauses 9.7 - 9.21].
The main specification concepts are:
· “type: a predicate characterizing a collection of
<X>” [clause 9.7],
· “instance: an <X> that satisfies a type” [clause 9.18],
· “class: the set of all <X> satisfying a type” [clause
9.8].
· “template”: the specification of the common features
of a collection of <X>s in sufficient details that an
<X> can be instantiated using it.” [clause 9.11]
The use of these terms is illustrated in the following
example: A behavior instance defines an actual
occurrence of a behavior. A behavior class defines a set of
behavior instances that share common characteristics. A
behavior type defines the common characteristics of the
behavior occurrences that belong to the behavior class. A
behavior template defines the features of a behavior in a
way that allows its instantiation. These concepts are
presented in more details in [8].
Basic modeling concepts and generic specification
concepts are defined by RM-ODP as two independent
conceptual categories. Essentially, they are two qualitative
dimensions that are necessary for defining model elements
that correspond to entities from the universe of discourse
with the prepositions defining them. This is why we
consider them as orthogonal as illustrated in Fig. 2.
instance
class
Specification
Concepts
Basic Modelling
Concepts
Action
Constraint
...
Model
elements
action type 1 action type 2
action class 1
AI 1 AI 2 AI 3
action class 2
type
N
CI 1 CI 2 CI 3 CI 4 CI 5 CI 6
AI 4
Figure 2. Illustration of use of the basic modeling
concepts and the specification concepts for definition of
model elements.
The example on Fig. 2 shows several model elements
that are defined either as different action types, classes
and instances, or as different constraint instances.
Applying the RM-ODP definition for behavior (“a
collection of actions with a set of constraints on when
they may occur” [clause 8.6]), we see, for example, that
the action instances AI1, AI2, AI3 with the constraint
instance CI3 represent an instance of a behavior type and
the action instances A3, A4 with the constraint instances
CI3, CI5, CI6 represent another instance of another
behavior type.
3.3.2 Abstraction/Refinement Specification Concepts
With our interpretation of RM-ODP, we consider that
model elements at various levels of details coexist in the
model. In addition, we consider that the relationships
between these levels of details are formally established
only in the model (and not in the universe of discourse).
This means that the developer ultimately has the
responsibility to establish these relationships. For this
reason, we consider it important for the specification
concepts to include:
· “refinement: the process of transforming one
specification into a more detailed specification.”
[clause 9.5], and
· “abstraction: the process of suppressing irrelevant
detail to establish a simplified model, or the result of
that process”. [clause 6.3]
Currently, “abstraction” is defined as a basic
interpretation concept. As both concepts define
complementary modifications that can be applied to a
model: both concepts should be defined together and both
