Semantic links in integrated modelling frameworks
1Rizzoli, A.E, 2M. Donatelli, 1I. Athanasiadis, 3F. Villa, 4R. Muetzelfeldt, and 5D. Huber
1IDSIA-USI/SUPSI, 2CRA, UVM, 4Simulistics, 5AntOptima, E-Mail: andrea@idsia.ch
Keywords: Integrated modelling frameworks; Ontologies; Model linking; Model reuse.

EXTENDED ABSTRACT
It is commonly accepted that modelling frame-
works offer a powerful tool for modellers, re-
searchers and decision makers, since they allow
the management, re-use and integration of models
from various disciplines and at different spatial
and temporal scales.
However, the actual re-usability of models de-
pends on a number of factors such as the accessi-
bility of the source code, the compatibility of dif-
ferent binary platforms, and often it is left to the
modellers’ own discipline and responsibility to
structure a complex model in such a way that it is
decomposed in smaller ‘re-usable’ sub-
components. What reusable and interchangeable
means is also somewhat vague; although several
approaches to build modelling frameworks have
been developed, little attention has been dedicated
to the intrinsic re-usability of components.
In this paper we focus on how models can be
linked together to build complex integrated mod-
els. We review and investigate the various ap-
proaches to model linking adopted by a number of
Integrated Modelling Frameworks and we aim at
describing the advantages and disadvantages of
each approach.
We stress that even if a model component inter-
face is clear and reusable in software terms, this is
not a sufficient condition for reusing a component
across different Integrated Modelling Frame-
works. This remark reveals the need for adding
rich semantics in model interfaces; we do such an
attempt through the use of domain classes and
ontologies.
A domain class can be considered as an abstract
data structure for defining a set of a model vari-
ables and their attributes (Rizzoli et al. 1998). A
model interface (in terms of inputs, outputs, states
and parameters) can be defined using a domain
class, providing some advantages: first of all, an
instance of a domain class can be accessed at run-
time to supply the model component with the ap-
propriate data. Secondly, it annotates model vari-
ables with attributes that can be used for pre-post
condition checks. Thirdly, it supports compliance
with the requirement that asks for model compo-
nents to be separated from their data structures.
And, last but not least, it provides an easy way for
linking model components at a higher level. This
practice uses shared domain classes for interchang-
ing data across models, taking full advantage of
component-based software engineering primitives.
Then, we present an approach based on the formali-
sation of ontologies to describe models’ interfaces
and relationships. The use of ontologies is advan-
tageous as it (a) supports the automatic generation
of code templates for models and domain classes in
different Integrated Modelling Frameworks, (b) it
facilitates the application of a reasoner (inference
engine) on the structured knowledge, which can
detect abnormalities or conflicts in model inter-
faces, and (c) it supports model linking in a content-
enriched way, which can be proven valuable for
avoiding common problems related to poor seman-
tics of model interfaces.
Finally, this paper presents a working example of
an ontology formalisation developed for the Seam-
less project1. This ontology (called SeamAg) aims
to formally describe biophysical models related to
agronomic and environmental domain to be devel-
oped by a large community of modellers within the
Seamless project. Modellers’ knowledge, related to
model subsystems, variables and interfaces, is kept
separated from the actual implementation. The use
of the SeamAg ontology for storing model inter-
faces supports the independence of software design
choices from modelling knowledge, which be easily
reused, integrated in different environments, or
shared with third parties. The potentials of extend-
ing the presented ontology-driven approach is dis-
cussed not only for model linking, but also in the
context of building model component workflows
using web services.

1 http://www.seamless-ip.org
704

1. INTRODUCTION
Since System Theory introduced the concept of
modular and hierarchical decomposition of models
(Padulo and Arbib, 1974), researchers were quick
in porting this concept into the implementations of
their models, which were mostly done in FOR-
TRAN. Subroutines were the logical counterpart
to submodels, and function parameters were used
to represent model inputs and outputs in the source
code implementations. The use of global variables
for passing values between submodels was still
very common, but this was (and in some cases still
is) a very bad programming habit, which has been
spotted quite early by Parnas (1972): good modu-
lar programs must have subroutines which display
a strong cohesion (lots of internal references to
variables in the local scope), but that are loosely
connected (very few data exchanges among sub-
routines, well defined by the subroutine signatures,
i.e. their parameters).
Procedural programming has been used to write
good implementations of mathematical models.
This programming paradigm was well suited to
representing modelling problems, where the de-
composition of a system in simpler functions
comes natural. Yet, the software designers were
missing more powerful programming concepts,
which could better support the representation of
data, and not only their flow in the program.
The advent of object-oriented programming an-
swered to the issue of organising and structuring
model data. The programming language, together
with inheritance, encapsulation and polymorphism,
finally supported the concept of abstract data
types.
Abstract data types allowed the programmer to
define a closer matching between the concept of a
system and its software representation, as shown
by Zeigler (1991). A system component, e.g. a
population in an ecosystem, was described as a
data type (a class) with attributes such as its bio-
mass, and with methods implementing the state
transitions and output transformations. Thanks to
inheritance it was possible to create taxonomies of
models, facilitating both the structuring of model-
ling knowledge and also the reuse of existing
knowledge, by overriding methods in child classes
(Del Furia et al. 1995). The concept of encapsula-
tion allowed to clearly define the interface of the
abstract data type, clearly facilitating the imple-
mentation of Parnas’ ideas of strong cohesion
(what is behind the interface) and loose connection
(the interface exposed to other abstract data types.
Finally polymorphism allowed implementing dif-
ferent behaviours behind a common interface. The
simulation of a composite model could be as sim-
ple as calling the same update() method on a
list containing all the submodels.
Nevertheless, after an initial hype, the relevance of
object-orientation to writing good modelling sys-
tems has been considerably re-dimensioned (We-
hie, 1997). For instance, despite the object-
oriented formalism, it was still possible to build
monolithic models. A monolithic model is a mod-
elling system where everything depends on every-
thing: the model is interspersed with data, with the
numerical integration, calibration, optimisation
algorithms, with graphical display and everything
is entangled. Most object-oriented modelling sys-
tems have been developed as monolithic models.
A paradigm shift was needed once again. Such a
shift did not require a major rethinking from the
software engineering point of view, but it was sim-
ply the acknowledgement that software should be
built as any complex piece of engineering, by reus-
ing simpler and robust (in the sense of their
quality) components.
2. COMPONENT-ORIENTED SOFTWARE
ENGINEERING IN MODELLING
FRAMEWORKS
Component-oriented software engineering is a
current trend, which places the concept of software
component at the centre of the development proc-
ess. Rewording Szyperski et al. (2002), software
components are software units, which can be de-
ployed independently, they can be easily re-used
by third parties and they do not have an externally
observable state. These properties enforce the
concept of a component as something different
from an object, which has a unique identity (com-
ponents should be externally undistinguishable),
and it has an externally observable state.
Implementing models as components has some
clear advantages. Reusability is facilitated by the
simplicity of the interface and the limited scope of
dependencies from other components. While it is
still possible to build components with lots of de-
pendencies and a complex interface, this would fail
the first requirement of independent deployment,
that is, the ability to deliver components, which are
well separated from their environment and other
components.
Adopting a well-behaved approach to component-
oriented software engineering also reduces the risk
of building monolithic applications: your own
components should be easy to integrate with third
party components. This principle, when applied to
705