Composing Variable Structure Models
A Revision of COMO
Alexander Steiniger and Adelinde M. Uhrmacher
Modeling and Simulation Chair, University of Rostock, Albert-Einstein-Str. 22, Rostock, Germany
Keywords:
Component-based Modeling, Variable Structure Models, Variable Interfaces, Intensional Couplings.
Abstract:
Component-based approaches aim at facilitating the storage, exchange, and reuse of components and their
compositions. For this, components provide interfaces that formulate contracts composition can be based
upon. Variable structure models imply the change of compositions, couplings, and even interfaces in terms of
ports. Thus, combining variable structure models with a component-based approach poses specific challenges.
We present a revision of the model composition framework COMO taking the specifics of variable structure
models into account, e.g., by specifying interfaces as sets of parameters and supersets of ports, defining cou-
plings intensionally, and introducing supersets of components as part of the compositional description. As
target for generating executable simulation models the formalism ML-DEVS has been selected.
1 INTRODUCTION
Typically, complex systems, e.g., technical, social,
or biological systems, comprise many different and
often heterogeneous entities concurrently communi-
cating and interacting with each other. Thus, many
formalisms, aiming at modeling such systems, sup-
port constructing models by parallel composition
of smaller model units (“components”) intrinsically,
e.g., DEVS (Zeigler et al., 2000). or process algebras
(Bergstra and Klop, 1989). Thereby, individual com-
ponents advance in parallel (concurrently). Going one
step further, component-based modeling approaches
emphasize the notion of self-contained model com-
ponents and foster their reuse (Verbraeck, 2004), also
by third parties. However, to be usable in unforeseen
contexts and for different purposes, a model com-
ponent needs to announce its functionality by well-
defined interfaces (R
¨
ohl and Uhrmacher, 2008).
Moreover, a variable structure characterizes many
complex systems, i.e., their composition, the inter-
action between their components, and the compo-
nents’ behavior patterns change over time (Uhrma-
cher, 2001). Diverse modeling languages and for-
malisms have been developed to address this vari-
ability: either by extending existing modeling for-
malisms, e.g., variants of DEVS like (Barros, 1995), or
by offering dynamic structure as salient feature from
the outset, e.g., the π-calculus (Milner, 1999). All
of those support a kind of sequential composition, as
they provide structure in the temporal dimension, i.e.,
they determine which model incarnation replaces an-
other under which circumstances and at which time.
Both types of composition seem to be at odd with
each other. Model components are self-contained
building blocks that have a well-defined interface and
encapsulate certain aspects of the simulated system,
whereas variable structure models can change their
structure and behavior. Those changes occur dur-
ing model execution (runtime), whereas assembling
model components to simulation models is done be-
forehand (at configuration time) and separately from
the execution of the composed simulation model
(Petty and Weisel, 2003). To explore possibilities
to support both, “classic” and sequential composi-
tion, we chose as starting points: (i) the interface and
composition description that is the basis of the model
composition framework COMO (R
¨
ohl and Uhrmacher,
2008) and (ii) the modular, hierarchical modeling for-
malism ML-DEVS (Steiniger et al., 2012).
2 EXAMPLE: RNA FOLDING
To illustrate our approach, we use the RNA fold-
ing model presented in (Maus, 2008) and specified
in the formalism ML-DEVS (Steiniger et al., 2012).
The model is a composition itself comprising a cou-
pled model, which represents the RNA molecule, and
286
Steiniger A. and Uhrmacher A..
Composing Variable Structure Models - A Revision of COMO.
DOI: 10.5220/0004486302860293
In Proceedings of the 3rd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH-2013),
pages 286-293
ISBN: 978-989-8565-69-3
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
the molecule’s components, the nucleotides. Each
nucleotide is an instance of the atomic model Nu-
cleotide, which can be of type A, C, G, or U refer-
ring to its bound nucleobase. In the folding model,
nucleotides are connected via ports according to their
primary structure in a linear sequence (bond). Those
ports represent the 3’ and 5’ carbon atoms, which are
linked. In addition, a secondary structure will be es-
tablished by dynamically adding connections between
eligible nucleotides. For this, a nucleotide signalizes
a binding request to the RNA molecule (macro model),
which selects a potential partner according to differ-
ent strategies, e.g., considering entropy. If the partner
is able to bind, both nucleotides will announce addi-
tional ports for the connection and the macro model
will connect those ports. The communication and in-
teraction between the molecule and nucleotides is re-
alized through up- and downward causation as pro-
vided by the formalism ML-DEVS.
3 COMPOSITION OF VARIABLE
STRUCTURE MODELS
We chose the model composition framework COMO
(R
¨
ohl and Uhrmacher, 2006) as starting point for
a component-based model design. Its underlying
description language allows specifying interfaces of
model components and their compositions explicitly
in a platform independent manner and separately from
the actual implementation of the associated models.
The description language is set-theoretically defined
and represented by XML schema definitions (R
¨
ohl and
Uhrmacher, 2008). Thus, composition specifications
consist of XML documents, which can be stored in
and retrieved from a repository. COMO can also an-
alyze the syntactic correctness of compositions and
transform them into executable simulation models in
a certain target formalism. The execution of derived
models (simulation) is not carried out by COMO, as
it does not provide an execution engine. However,
COMO can be added as an additional specification and
analysis layer on top of a simulation system, which is
then used for the execution. Figure 1 shows the rela-
tion between the description units of COMO and illus-
trates schematically the steps to derive an executable
simulation model from a composition specification.
So far, similar to other component-based ap-
proaches, such as COST (Chen and Szymanski, 2002)
or CODES (Szabo and Teo, 2007), COMO is not ad-
dressing variable interfaces and structures, i.e., se-
quential composition (composition over time), but as-
sumes static compositions instead. The question is
now, how variability can be reflected at the specifi-
Implementation Layer
Specification Layer (COMO)
Components
B B
A
Component Instances
b1:B b2:B
a:A
Executable Model
b1 b2
a
Simulation
Interfaces
A
B
implement
configure &
instantiate
Interfaces
A
B
analyse &
transform
refine
refer
COMO
Repository
Modeler /
Experimenter
evaluate
retrieve / compose
parameterize
retrieve
store store
Figure 1: The derivation of an executable simulation model
from a composition specification in COMO (specification
layer) and model implementations in certain source for-
malisms (implementation layer). First, a given componen-
t/composition is configured and instantiated according to
specified parameter values. Afterwards, the component in-
stances are analyzed and transformed into an executable
model that can then be executed.
cation and analysis level while maintaining the sep-
aration of composition, implementation, and execu-
tion. To cope with and support structural changes, we
started to revise and extend COMO. Basically, our ap-
proach embraces the following three steps:
1. Adapt the interface and composition description,
COMO is based on, to cope with the shift from
static to variable interfaces and structures.
2. Choose an appropriate modeling formalism that
allows expressing variable structures to show the
applicability of the approach.
3. Revise and adapt the existing consistency checks
of COMO.
3.1 Revision of COMO
Our first revision refers to the adaption and general-
ization of interfaces, the fundamental constructs in
COMO. Although variable structures do not imply dy-
namic interfaces, some systems, as can be found in
the biological domain, are characterized by the plas-
ticity of their interfaces (Uhrmacher et al., 2007).
Specifying an interface with a static set of ports
is straightforward. In case of variable interfaces, a
concrete manifestation of ports depends on the com-
ponent’s state and external events, and may change
during simulation. Thus, different incarnations of an
interface can exist. Specifying all incarnations seems
to be not practically. If we do not allow generating
new names during execution, we can assume the su-
perset of those variable ports, i.e., all potential ports a
ComposingVariableStructureModels-ARevisionofCOMO
287
Nucleotide
3':PosThreeBind
base:Nucleobase
5':PosFiveBind
pos:Int
pair:SecBind
Figure 2: Interface of the component Nucleotide with three
composite ports and two parameters.
model can exhibit, to be known before the execution.
Definition 1. An interface is a tuple (id, Ports,
Params) with a unique identifier id ∈ QName, a fi-
nite superset of composite ports Ports, and a finite set
of parameter declarations Params. Ports and param-
eters must be unambiguous.
In contrast to (R
¨
ohl and Uhrmacher, 2008), an in-
terface definition does not refer to a component that
implements the interface. Several components can
now implement the same interface. The superset of
ports is encoded by declaring all potential compos-
ite ports in Ports. Composite ports have a name and
role assigned to them
1
. Roles are defined by an id
and a list of event ports. An event port consists of
a name, message type, and direction (in- or output
port). A parameter declaration has a unique name
and a reference to a type. Figure 2 shows the interface
of the component Nucleotide comprising three com-
posite ports (white boxes) that reflect the three bind-
ing sites, which establish the primary and secondary
structure, and two parameters (gray boxes) defining
the nucleotide’s base (base) and position in the pri-
mary structure (pos). All port and parameter labels
consist of port and parameter names and references to
roles and types, respectively, separated by ‘:’.
Interfaces serve as contracts between model com-
ponents, whose implementations need to adhere to
those contracts. Therefore, ports at the interface level
must be related to concrete model ports in the im-
plementations unambiguously. This can be done ex-
plicitly via bindings. If no binding is defined, COMO
binds an event port to an implementation port whose
names equals those of the event port.
Definition 2. B is a finite set of bindings of a com-
ponent c. Each binding b ∈ B is a tuple (port, decl,
impl), where port ∈ String is the name of a compos-
ite port, decl ∈ String is the name of an event port
(declared port), and impl ∈ String is the the name
of the assigned model port (implementation port). It
holds that ∀b, b
0
∈ B : ((b.port = b
0
.port ∧ b.decl =
b
0
.decl) ⇒ (b = b
0
)).
1
We distinguish between identifiers and names. The for-
mer are given as qualified names and used to identify and
refer to other description units unambiguously, whereas the
latter are used within definitions as variable names.
Nucleotide
3':PosThreeBind
5':PosFiveBind
Nucleodite
Model
from3
pair:SecBind
PosFiveBind
toFive
fromFive
SecBind
toPartnerfromPartner
PosThreeBind
toThreefromThree
toPartner
to3
fromPartner
toPartner
to5
from5
Figure 3: Relations between composite ports, roles, event
ports, and implementation ports.
We write b.port etc. to access the corresponding
elements of a given definition (tuple). The function
impl returns the name of a model port for a given com-
posite and event port name and a binding set:
impl(cpn, epn, B) =
(
b.impl if ∃b ∈ B: cpn = b.port ∧ epn = b.decl,
epn otherwise.
Figure 3 illustrates the relation between composi-
te ports, roles, event ports, and implementation ports.
The implemented model (gray rhomboid) exhibits
ports (white rhombuses whit arrows) that are bound
to event ports (dashed lines). Event ports are struc-
tured into roles, which describes complex interaction
capabilities. Finally, roles are referenced by compos-
ite ports of the interface (dotted lines).
A component definition relates an interface to a
given model definition (implementation) in a certain
formalism (source formalism). We adapt the defi-
nition by introducing loose connections to deal with
variable interfaces and structures.
Definition 3. A component is a tuple (id, if , k, µ,
B, Sub, LCon) with a unique identifier id ∈ QName,
a reference to an interface definition if ∈ QName, a
configuration function k, a model definition µ (im-
plementation), a finite binding set B, a set of sub-
components Sub, and a set of loose connections LCon.
Sub consists of tuples (name, iid, cid, Params) with a
name ∈ String, interface reference iid ∈ QName, com-
ponent reference cid ∈ QName, and a set of parame-
ter assignments Params. Each parameter assignment
comprise a name and value. In case of an atomic
component, Sub and LCon will be empty.
Loose connections extend the idea of multi-
couplings (Uhrmacher et al., 2007; Steiniger et al.,
2012). They are defined at the level of interfaces, i.e.,
composite ports.
Definition 4. A loose connection lc of a component
c, i.e., lc ∈ c.LCon, is defined as partial function:
Sub × Sub 2
{(start,end)∈String×String}
, where Sub is
SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand
Applications
288
defined as in Definition 3 and start, end are names
of the composite ports that shall be connected. The
domain of lc can be specified by a relation R
lc
⊆
Sub × Sub.
Example 1. Let lc be a loose connection that links
the 3’ and 5’ carbon atoms of all pairs of con-
secutive nucleotides within a backbone bond, i.e.,
the primary structure: lc(s, s
0
) equals {(3
0
, 5
0
)} if
(s, s
0
) ∈ R
lc
or ⊥ otherwise, with R
lc
= {(s, s
0
) ∈
Sub × Sub |∃p ∈ s.Params, p
0
∈ s
0
.Params: p.name =
p
0
.name = “pos” ∧ p
0
.value = p.value + 1 ∧ s 6= s
0
∧
s.iid = s
0
.iid = “Nucleotide”}.
For instantiating components, the configuration
function or configurator k plays a crucial role. It al-
lows changing the component’s internal structure and
determines the initially available sub-components,
loose connections, and composite ports according to
given parameter values.
Definition 5. A configurator k is a function that maps
the tuple (Params, Sub, LCon, B) onto the tuple
(Sub
0
, LCon
0
, B
0
, Sub
i
, LCon
i
, Ports
i
, Params
0
).
An implementation of k has to evaluate given pa-
rameter values and delegate them to sub-components
if necessary. Given a configuration (name, iid, cid,
Params) that refers to a concrete component and its
context, we now adapt the central function instC(.)
to return a fully instantiated composition. For this,
the compositional hierarchy is traversed, starting from
the referenced component, and the specified configu-
ration functions are applied successively. Algorithm 1
shows the instantiation, where C is the set of all com-
ponent definitions.
Algorithm 1: Instantiation of a component definition.
name: instC
input: name, interface reference cid, component reference iid, parameter
values Params
output: instantiated composition ci
1 //get component definition
2 if ∃c
0
∈ C with c
0
.id = cid then c = c
0
else c = ⊥
3 //check if c valid
4 if c 6= ⊥ and c.if = iid then
5 //apply configurator of current component
6 Sub, LCon, B, Sub
i
, LCon
i
, Ports
i
, Params
0
7 = c.k(Params, c.Sub, c.LCon, c.B)
8 //instantiate recursively
9 ci = (name, c.id, c.if , c.µ,
S
s∈Sub
{instC(s)}, LCon,
10 B, Com
i
, LCon
i
, Ports
i
, Params
0
)
11 with ci.Com
i
=
S
s∈Sub
i
{ci
0
∈ ci.Com|ci
0
.name = s.name}
12 //return instantiated composition
13 return ci
14 else
15 return ⊥
In our revision, a component can have several in-
stances sharing the same component definition. We
introduce the definition of a component instance rep-
resenting a component in a concrete context, i.e., with
a concrete parameterization and initial structure.
Definition 6. A component instance is a tuple (name,
cid, iid, µ, Com, LCon, B, Com
i
, LCon
i
, Ports
i
,
Params) with a unique name ∈ String, a reference to
a component definition cid ∈ QName, a reference to a
interface definition iid ∈ QName, a model definition
µ, a set of (sub-)component instances Com, a set of
loose connections LCon, a set of bindings B, and the
sets Com
i
⊆ Com, LCon
i
⊆ LCon, and Ports
i
⊆ String
that reflect the initial structure. Params is a set of pa-
rameter assignments.
Figure 4 shows the instantiation and initializa-
tion of a composite component mRNA (ride side) ac-
cording to the given parameter values, i.e., the RNA
molecule should contain 38 nucleotides with varying
nucleobases. On the left side, only the initial struc-
ture and ports of the model and its components are
depicted.
3.2 Incorporation of Multi-Level-DEVS
The modeling formalism ML-DEVS supports vari-
able ports and structures, intensional couplings, and
provides additional mechanisms for up- and down-
ward causation between different levels of behavior
(Steiniger et al., 2012). Moreover, ML-DEVS has been
and is currently used in different application domains,
from demography (Zinn, 2011) to smart environments
(Kr
¨
uger et al., 2012). Therefore, we chose ML-DEVS
as target formalism. For a thorough introduction to
ML-DEVS please refer to (Steiniger et al., 2012).
In COMO, the function model(.) transforms com-
ponent instances and their implementations into ex-
ecutable simulation models. For this purpose, meta-
models of the source formalism(s) and target formal-
ism are needed that describe how models are specified
in those formalisms. To use ML-DEVS as target, the
transformation function, returning ML-DEVS models,
is defined as follows:
Definition 7. Let ci be a component instance,
mm
source
be the meta-model of an arbitrary source
formalism, mm
mldevs
be the meta-model of ML-DEVS,
and the function metamodel(µ) return the meta-model
of the formalism in which the given model µ is defined.
Then, the transformation is defined by:
model(cid, mm
source
, mm
mldevs
) =
(
micro(cid, metamodel(ci.µ)) if ci.Com = ∅,
macro(cid, metamodel(ci.µ)) otherwise.
ComposingVariableStructureModels-ARevisionofCOMO
289
Macro:mRNA
C1:Nucleotide A2:Nucleotide
3' 5'5'
G38:Nucleotide
5'3' 3'
...
mRNA
Nucleotide
base:Nucleobase
pos:Int
3'5'
pair
#nucleotides:Int
addNT
Instantiation &
Initialization
addNT codon
codon
pos = 1base = C pos = 2base = A pos = 38base = G
#nucleotides = 38
Figure 4: Instantiation and initialization of the component mRNA and its sub-components, i.e., nucleotides.
So, the transformation into ML-DEVS consists of
two different functions: micro(.) and macro(.). The
former maps atomic components onto MICRO-DEVS
models, whereas the latter maps composite compo-
nents onto MACRO-DEVS models. Both functions
share similar functionality, as MACRO-DEVS models
have also a state and behavior. Additionally, macro(.)
is responsible for transforming the sub-components of
a composite component and synthesizes the commu-
nication structure from the given descriptions:
C =
[
c∈ci.Com
{model(c, mm
source
, mm
mldevs
)},
with mm
source
= metamodel(c.µ)
MC = multiCouplings(ci).
For our prototype we also chose ML-DEVS as source
formalism, which makes the implementation of the
transformation straightforward. If formalisms differ-
ent from the actual target formalism shall be used
to implement components, a similar approach as in
(de Lara and Vangheluwe, 2002) can be exploited.
The mapping from loose connections onto multi-
couplings of the target ML-DEVS is done by an aux-
iliary function, called multiCouplings(.). Please note
that the generic multi-couplings in ML-DEVS are de-
fined intensionally based on port names. If ports with
those names exist during execution, an extensional
coupling, as known from other DEVS variants, is in-
stalled (Steiniger et al., 2012). A reference imple-
mentation of the mapping is shown in Algorithm 2.
For each loose connection lc it is checked whether
or not a combination of sub-components (including
the composite component) is in the domain of lc (line
15). If so, all values returned by lc, i.e., pairs of
composite port names, are iterated and the referenced
roles
2
(lines 15 to 24) are matched (lines 26 to 29)
similarly as done when resolving composition con-
nections (cf. (R
¨
ohl and Uhrmacher, 2008)). For this,
matches(r, r
0
) is defined as follows:
Definition 8. Let r, r
0
be role definitions, then
matches(r, r
0
) ⇔ {(f , t) ∈ String × String |∃e ∈
r.EP, e
0
∈ r
0
.EP: f = e.name ∧ t = e
0
.name ∧ e.inp 6=
2
The functions drefI(.), drefR(.), and drefT(.) retrieve
corresponding definitions based on a given identifier.
e
0
.inp ∧ (e.inp ⇒ drefT(e
0
.tid) v drefT(e.tid)) ∧
(e
0
.inp ⇒ drefT(e.tid) v drefT(e
0
.tid))}.
Algorithm 2: Construction of multi-couplings.
name: multiCouplings
input: instance of composite component ci
output: set of multi couplings MC
1 MC = ∅
2 for each lc ∈ ci.LCon do
3 //iterate all component pairings
4 for each s ∈ ci.Com ∪ {ci} do
5 for each s
0
∈ ci.Com ∪ {ci} do
6 //prevent direct feedback loops
7 if s = s
0
then co nt in u e with ne x t pai r
8 //get and check interfaces
9 if (i = drefI(s.if )) = ⊥ then //error
10 if (i
0
= drefI(s
0
.if )) = ⊥ then //error
11 //build interface instances
12 sub = (s.name, i.id , s.cid, s.Params)
13 sub
0
= (s
0
.name, i
0
.id, s
0
.cid, s
0
.Params)
14 //iterate all potential port name pairs
15 for each (start, end) ∈ lc(sub, sub
0
) with
lc(sub, sub
0
) 6= ⊥ do
16 //get ports and roles
17 if ∃port ∈ s.Ports with port.name = start
18 then p = port
19 else co nt in u e with ne x t por t p air
20 if ∃port ∈ s
0
.Ports with port.name = end
21 then p
0
= port
22 else co nt in u e with ne x t por t p air
23 if (r = drefR(p.rid)) = ⊥ then \\ e rro r
24 if (r
0
= drefR(p
0
.rid)) = ⊥ then \\ e rro r
25 //match event ports of connected roles
26 M = ∅
27 if s = c then M = matches(r, r
0
)
28 else if s
0
= c then M = matches(r, r
0
)
29 else M = matches(r, r
0
)
30 //iterate all event port matches
31 for each (from, to) ∈ M do
32 //get names of implementation ports
33 ip = impl(p.name, from, s.B)
34 ip
0
= impl(p
0
.name, to, s
0
.B)
35 //check orientation of model coupling
36 e = dp with dp ∈ r.EP. dp.name = from
37 if (s = c ∧ e.inp) or (s 6= c ∧ ¬e.inp)
38 then MC += (ip, ip
0
) //keep orientation
39 else if (s 6= c ∧ e.inp) or (s = c ∧ ¬e.inp)
40 then MC += (ip
0
, ip) //invert orientation
41 else do no th i ng
42 return MC
SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand
Applications
290
The relation t v t
0
indicates that type t is
a sub-type of t
0
. Furthermore, r indicates that
the direction of all event ports declared in role
r are inverted, so r := (⊥, r.EP) with r.EP =
{(e.name, e.tid, ¬e.inp) | (e.name, e.tid, e.inp) ∈
r.EP}. Finally, for each match, the names of the
bound implementation ports are retrieved (lines 33
to 34) and a multi-coupling between those names
is added to the returning coupling set, considering
the event port’s direction (lines 36 to 41). The algo-
rithm ignores all matches that result in inconsistent
multi-couplings, such as direct feedback loops by
connecting ports of the same component (line 7).
One difference between the previous composition
connections and the novel loose connections is: the
former are resolved into concrete, extensional model
couplings, whereas the latter are resolved into inten-
sional multi-couplings. Those intensional couplings
have to be resolved into concrete, extensional model
couplings in a second step during the execution of the
derived simulation model. This resolution cannot be
done by COMO, but has to be done by the simulator of
ML-DEVS. The impact of using intensional couplings
on consistency checked are discussed in the next sec-
tion.
3.3 Analysis
Assuring correctness by construction by analyzing
components and compositions merely based on con-
ceptual specifications, such that the function model(.)
construct a proper simulation model, is another moti-
vation of COMO (R
¨
ohl and Uhrmacher, 2008). How-
ever, the components’ implementations have to be
considered as well for checking some properties. So
far, correctness is checked at the syntactic level, in
terms of syntactic composability as defined in (Petty
and Weisel, 2003; Szabo and Teo, 2007).
When checking the consistency of (parallel) com-
positions, the compatibility of interfaces and in par-
ticular the compatibility of the connected composite
ports is of interest. Composite ports are compatible
if their roles are compatible, denoted by r ∼ r
0
, i.e., if
for each event port declared in r a counterpart with the
opposite direction and a suitable message type (sub-
type relation must hold) in r
0
exists and vice versa.
Although we are now dealing with variable ports and
structures, knowing the supersets of ports and sub-
components allows us to check whether or not a loose
connection is well-defined in general, similarly as it
was done for composite connections.
Definition 9. A loose connection lc is well-
defined for a component instance ci, denoted by
welldefined
ci
(lc), if there exist s, s
0
∈ Sub, with s 6=
s
0
and lc(s, s
0
) 6= ⊥, for which hold ∀(start, end) ∈
lc(s, s
0
)∃p ∈ i.Ports, p
0
∈ i
0
.Ports: p.name = start ∧
p
0
.name = end ∧ ((s = ci ⇒
r ∼ r
0
) ∧ (s
0
= ci ⇒ r ∼
r
0
) ∧ ((s 6= ci ∧ s
0
6= ci) ⇒ r ∼ r
0
)), where Sub =
S
c∈ci.Com∪{ci}
{(c.name, c.iid, c.cid, c.Params)}, i =
drefI(s.iid), i
0
= drefI(s
0
.iid), r = drefR(p.rid), and
r
0
= drefR(p
0
.rid).
However, except for the initial state, we cannot
make assumptions at the specification layer on the
actual existence of concrete model couplings, into
which loose connections are resolved during execu-
tion. Please note, due to the intensional definition
some inconsistencies can no longer occur, as explic-
itly (current) properties of interfaces are taken into ac-
count. In contrast, before it could have happened that
connections had been defined based on ports that did
not exist during execution.
Based on the above definition, we can check the
completeness of a given component instance, which
may be the root of a composition, i.e., we analyze the
consistency of the specification:
Definition 10. A component instance ci is complete,
denoted by complete(ci), if:
1. all referenced types, interfaces, roles, and compo-
nents exist,
2. ∀p ∈ ci.Params ∃p
0
∈ i.Params : p.name =
p
0
.name ∧ p.value ∈ t.Car with t = drefT(p
0
.tid),
3. ∀lc ∈ ci.LCon: wellformed
ci
(lc),
4. the initial structure state is valid, i.e., ci.Com
i
⊆
ci.Com, ci.LCon
i
⊆ ci.LCon, and ci.Ports
i
⊆
S
p∈i.Ports
{p.name} with i = drefI(ci.if ),
5. all names of sub-components are unique,
6. ∀c ∈ ci.Com: complete(c).
As we cannot decide whether or not ports will be
connected during execution and a component may use
ports to signalize state changes to its parent, we, in
contrast to (R
¨
ohl and Uhrmacher, 2008), do not re-
quire that composite ports have to be connected.
Although the implementation of a model compo-
nent (model definition) is decoupled from its interface
definition, both have to relate to each other. Hence,
COMO checks whether the model definition refines
the specified interface and vice versa based on bind-
ings. As composite ports have no longer a connectiv-
ity range, we adapt the definition given in (R
¨
ohl and
Uhrmacher, 2008) as follows:
Definition 11. A model definition µ and a set of bind-
ings B are a preserving refinement for an inter-
face i, denoted by i
p
(µ, B), if ∀p ∈ i.Ports∀e ∈
r.EP : ip ∈ µ
0
.Ports ∧ t.Car = range
ip
(µ
0
.XY) with
r = drefR(p.rid), ip = impl(p.name, e.name, B), µ
0
=
model(µ), and t = drefT(e.tid).
In COMO we distinguish between in- and output
ComposingVariableStructureModels-ARevisionofCOMO
291
ports, but during the transformation into executable
ML-DEVS models the direction of ports will be ig-
nored, as ML-DEVS does not make this distinction.
Complementing the preserving refinement, the re-
flecting refinement assures that all requirements of
the model definition, i.e., required ports, are reflected
in the interface and an analysis of a composition
solely based on interfaces is possible in the first place.
Therefore, all required ports, denoted by required(µ),
that a model may use to communicate messages or
signalize state changes to its surroundings should be
reflected in the model’s interface.
Definition 12. A model definition µ and a set of bind-
ings B are a reflecting refinement for an interface
i, denoted by i
r
(µ, B), if ∀ip ∈ required(µ
0
)∃p ∈
i.Ports∃e ∈ r.EP: ip = impl(p.name, e.name, B) with
µ
0
= mldevs(µ) and r = drefR(p.rid).
However, the question remains, how to retrieve the
set required(µ) from a given model definition. So
far, the modeler has to define the set. Combining
both refinements yields full refinement, denoted by
i (µ, B) ⇔ i
p
(µ, B) ∧ i
r
(µ, B), assuring that
an interface definition captures all requirements of a
model definition and vice versa (R
¨
ohl and Uhrmacher,
2008).
Finally, we adapt the definition of the correctness
of a component instance as follows:
Definition 13. A component instance ci is correct,
denoted by correct(ci), if
1. i (ci.µ, ci.B) with i = drefI(ci.if ),
2. complete(ci),
3. ∀c ∈ ci.Com: correct(c),
4. no sub-component of ci refers to ci (acyclic com-
positions).
A correct component instance can be deployed
and transformed into a proper simulation model. In
contrast to (R
¨
ohl and Uhrmacher, 2008), we check
completeness and correctness at the level of compo-
nent instances.
4 DISCUSSION AND
CONCLUSIONS
The overall promise of a component-based design
with a strict separation of interface and model is that
models can be stored and composed more easily and
compositions can be analyzed mostly independent of
implementation details. To exploit these capabilities
for models with variable interfaces and structures, we
revised the existing model composition framework
COMO.
We adapted how components and their composi-
tions are specified in COMO. Now we distinguish
more clearly between components and their instances.
We generalized interfaces so that different compo-
nents can refer to the same interface, which is more
in line with the usual meaning of interfaces (see also
(Tolk and Muguira, 2003) for the role of interfaces).
This also implies that the modeler is responsible to
assure that a component implements a specific inter-
face. To take variable ports into account, the inter-
face definition includes supersets of ports. We re-
placed the existing extensional couplings by a loose
coupling scheme, which defines and constrains cou-
plings intensionally based on properties of the sub-
components’ interfaces and their concrete manifes-
tations during execution. For this, a highly flexible
and yet expressive scheme for defining couplings has
been realized. In addition, this revision allowed us to
get rid of some burden that COMO had been carrying
around.
In the analysis phase, a compositional descrip-
tion is checked by COMO for being complete and cor-
rect. Therefore, different properties of the composi-
tion are of interest: (i) the direction and consistency
of types of ports that should be connected accord-
ing to the intensional couplings, (ii) the initial struc-
ture of the model (its components and couplings) that
should relate to the overall definition, and (iii) the
refinement relation between implemented model and
component instance. COMO is independent of model-
ing formalisms. However, it requires meta models of
modeling formalisms and transformation functions to
translate models from a source formalism into a target
formalism. For our prototypical realization we chose
the same source and target formalism for our models,
ML-DEVS. The formalism supports variable ports and
structures and employs intensional couplings. How-
ever, the revised COMO would also work for models
with a static structure and the old target formalism, P-
DEVS (Chow and Zeigler, 1994).
Several avenues for further research exist: For
instance, it would be interesting to see how COMO
can be mapped into other suitable target formalisms,
e.g., Beta binders (Priami and Quaglia, 2005). Also
the transformation of models into the target formal-
ism based on suitable meta-models offers an entire
field of research. So far, we also have not exploited
one fundamental characteristic of ML-DEVS, its mulit-
levelness (relating macro and micro levels). Here,
it would be interesting to examine the demands of
multi-level modeling beyond classic hierarchical de-
composition on component interfaces and coupling
schemes. However, to come up with a not too ML-
DEVS-specific solution, other multi-level modeling
SIMULTECH2013-3rdInternationalConferenceonSimulationandModelingMethodologies,Technologiesand
Applications
292
approaches need to be inspected as well, such as
(Oury and Plotkin, 2011).
ACKNOWLEDGEMENTS
This research is supported by the German Research
Foundation (DFG) within the context of the project
MuSAMA (Multimodal Smart Appliance Ensembles
for Mobile Applications).
REFERENCES
Barros, F. J. (1995). Dynamic Structure Discrete Event Sys-
tem Specification: A New Formalism for Dynamic
Structure Modeling and Simulation. In Alexopoulos,
C., Kang, K., Lilegdon, W. R., and Goldsman, D., edi-
tors, Proceedings of the 1995 Winter Simulation Con-
ference, pages 781–785. IEEE Computer Society.
Bergstra, J. A. and Klop, J. W. (1989). ACT
τ
: A Univer-
sal Axiom System for Process Specification. In Wirs-
ing, M. and Bergstra, J. A., editors, Algebraic Meth-
ods: Theory, Tools and Applications, volume 394 of
Lecture Notes in Computer Science, pages 447–463.
Springer-Verlag.
Chen, G. and Szymanski, B. K. (2002). COST: A
Component-Oriented Discrete Event Simulator. In
Y
¨
ucesan, E., Chen, C.-H., Snowdon, J. L., and
Charnes, J. M., editors, Proceedings of the 2002
Winter Simulation Conference, pages 776–782. IEEE
Computer Society.
Chow, A. C. and Zeigler, B. P. (1994). Parallel DEVS:
A parallel, hierarchical, modular modeling formalism.
In Tew, J. D., S., M., Sadowski, D. A., and Seila, A.,
editors, Proceedings of the 1994 Winter Simulation
Conference, pages 716–722. IEEE Computer Society.
de Lara, J. and Vangheluwe, H. L. M. (2002). AToM3:
A Tool for Multi-formalism and Meta-modelling. In
Kutsche, R.-D. and Weber, H., editors, Fundamental
Approaches to Software Engineering, volume 2306 of
Lecture Notes in Computer Science, pages 174–188.
Springer-Verlag.
Kr
¨
uger, F., Steiniger, A., Bader, S., and Kirste, T. (2012).
Evaluating the robustness of activity recognition using
computational causal behavior models. In Dey, A. K.,
Chu, H.-H., and Hayes, G., editors, Proceedings of
the 2012 ACM Conference on Ubiquitous Computing,
pages 1066–1074. ACM Press.
Maus, C. (2008). Component-Based Modelling of RNA
Structure Folding. In Heiner, M. and Uhrmacher,
A. M., editors, Computational Methods in Systems Bi-
ology, volume 5307 of Lecture Notes in Computer Sci-
ence, pages 44–62. Springer-Verlag.
Milner, R. (1999). Communicating and Mobile Systems: the
π-calculus. Cambridge University Press, 1st edition.
Oury, N. and Plotkin, G. D. (2011). Coloured Stochastic
Multilevel Multiset Rewriting. In Fages, F., editor,
Computational Methods in Systems Biology, pages
171–181. ACM Press.
Petty, M. D. and Weisel, E. W. (2003). A Composability
Lexicon. In Proceedings of the Spring 2003 Simula-
tion Interoperability Workshop, pages 181–187.
Priami, C. and Quaglia, P. (2005). Beta Binders for Bio-
logical Interactions. In Danos, V. and Schachter, V.,
editors, Computational Methods in Systems Biology,
volume 3082 of Lecture Notes in Computer Science,
pages 20–33. Springer-Verlag.
R
¨
ohl, M. and Uhrmacher, A. M. (2006). Composing Sim-
ulations from XML-Specified Model Components. In
Perrone, L. F., Wieland, F. P., Liu, J., Lawson, B. G.,
Nicol, D. M., and Fujimoto, R. M., editors, Proceed-
ings of the 2006 Winter Simulation Conference, pages
1083–1090. IEEE Computer Society.
R
¨
ohl, M. and Uhrmacher, A. M. (2008). Definition
and Analysis of Composition Structures for Discrete-
Event Models. In Mason, S. J., Hill, R. R., M
¨
onch, L.,
Rose, O., Jefferson, T., and Fowler, J. W., editors, Pro-
ceedings of the 2008 Winter Simulation Conference,
pages 942–950. IEEE Computer Society.
Steiniger, A., Kr
¨
uger, F., and Uhrmacher, A. M. (2012).
Modeling Agents and their Environment in Multi-
Level-DEVS. In Laroque, C., Himmelspach, J., Pa-
supathy, R., Rose, O., and Uhrmacher, A. M., editors,
Proceedings of the 2012 Winter Simulation Confer-
ence. IEEE Computer Society. Article No. 233.
Szabo, C. and Teo, Y. M. (2007). On Syntactic Compos-
ability and Model Reuse. In Al-Dabass, D., Zobel, R.,
Abraham, A., and Turner, S., editors, Proceedings of
the First Asia International Conference on Modelling
& Simulation, pages 230–237. IEEE.
Tolk, A. and Muguira, J. A. (2003). The Level of Concep-
tual Interoperability Model. In Fall Simulation Inter-
operability Workshop.
Uhrmacher, A. M. (2001). Dynamic Structures in Mod-
eling and Simulation: A Reflective Approach. ACM
Transactions on Modeling and Computer Simulation,
11(2):206–232.
Uhrmacher, A. M., Ewald, R., John, M., Maus, C., Jeschke,
M., and Biermann, S. (2007). Combining Micro and
Macro-Modeling in DEVS for Computational Biol-
ogy. In Henderson, S. G., Biller, B., Hsieh, M.-H.,
Shortle, J., Tew, J. D., and Barton, R. R., editors, Pro-
ceedings of the 2007 Winter Simulation Conference,
pages 871–880. IEEE Computer Society.
Verbraeck, A. (2004). Component-based Distributed Sim-
ulations. The Way Forward? In Proceedings of the
18th Workshop on Parallel and Distributed Simula-
tion, pages 141–148. IEEE Computer Society.
Zeigler, B. P., Praehofer, H., and Kim, T. G. (2000). Theory
of Modeling and Simulation. Academic Press, 2nd
edition.
Zinn, S. (2011). A Continuous-Time Microsimulation and
First Steps Towards a Multi-Level Approach in De-
mography. Dissertation, University of Rostock, Ro-
stock, Germany.
ComposingVariableStructureModels-ARevisionofCOMO
293
