=Paper=
{{Paper
|id=Vol-1463/paper1
|storemode=property
|title=Challenges for Model-Integrating Components
|pdfUrl=https://ceur-ws.org/Vol-1463/paper1.pdf
|volume=Vol-1463
|dblpUrl=https://dblp.org/rec/conf/models/Derakhshanmanesh15a
}}
==Challenges for Model-Integrating Components==
https://ceur-ws.org/Vol-1463/paper1.pdf
Challenges for Model-Integrating Components
Mahdi Derakhshanmanesh Jürgen Ebert Marvin Grieger
University of Koblenz-Landau University of Koblenz-Landau University of Paderborn
Institute for Software Technology Institute for Software Technology Department of Computer Science
Koblenz, Germany Koblenz, Germany Paderborn, Germany
Email: manesh@uni-koblenz.de Email: ebert@uni-koblenz.de Email: marvin.grieger@uni-paderborn.de
Abstract—Model-Integrating Software Components (MoCos) «component»
MoCo
use models at runtime as first class entities within components «delegate»
to build flexible and adaptive software systems. Building such
systems requires to design and implement the required domain- IModelState IModelState
PFunction
specific modeling languages. Insufficient design and realization of
«port»
modeling languages raises the risk that they may not be optimized
ICodeState ICodeState
for their later use. Although various works on the use of models at
«module»
Mediator
«module» «module»
runtime exist, they do not address the engineering of modeling MoCoCode MoCoModel
IInterpret IInterpret
languages to be used in software components at runtime. In
PManage
«port»
this paper, we introduce the idea of Comprehensive Language
Models (CLMs) which explicitly considers modeling language IAction IAction
engineering as a part of the development of component based
software systems. This is achieved by extending the modeling «delegate»
language specification, e.g., by a set of interfaces for models
which are used for accessing models at runtime. We illustrate an
initial solution concept along an insurance sales app case study Fig. 1. Internal View on the MoCo Template (see [1])
on Android based on which we derive a set of key challenges for
the community.
are used on the code side, e.g., Java, and different – poten-
I. I NTRODUCTION tially integrated – DSMLs are used on the model side. Both
Models are no longer just used to design software but can constituents of a MoCo are encapsulated using interfaces.
become an integrated part of it, i.e., (executable) models and Optionally, a smart Mediator can manage any redirection
code coexist at runtime with equal rights. In previous works from and to the MoCo’s ports as well as communication
[1], [2], we proposed Model-Integrating Software Components between the model and code parts.
(MoCos) as a concept for the design and development of such The expected advantages of the MoCo approach are: (i) en-
model-integrating software systems. Software engineers can hanced flexibility because the system and its individual compo-
choose to realize some parts of a system programmatically nents can be observed using model queries, can be modified by
in code, while other parts are kept as models. No code is adapting models using an editor or model transformations and
generated from the models but they are used at runtime. This can be executed using model interpreters [3], (ii) support of
concept yields flexible well-performing software that can be separation of concerns because each model targets a concern,
easily and systematically monitored, analyzed and modified. (iii) understandability and maintainability because models are
assumed to be easier to understand and easier to handle
The MoCo-approach combines models described using arbi-
than code, (iv) self-documentation because a well designed
trary Domain-Specific Modeling Languages (DSMLs) and em-
modeling language is assumed to be a documentation and
beds them within software components following a tailorable
(v) no synchronization problem because there is no redundancy
component design pattern that guides software engineers:
between model and code unless it is introduced willfully, e.g.,
the MoCo Template. It is depicted in Figure 1 and briefly
to realize reflection.
introduced, next.
B. Research Problem
A. Model-Integrating Software Components An essential difference between component-based and
Each MoCo can have ports (PFunction, PManage) that model-integrating software is the use of various models at
are wired to the internal implementation, which is either runtime (not just reflective models@run.time [4]). There-
encoded by a programming language (MoCoCode) or by a fore, developing model-integrating software systems includes
modeling language (MoCoModel). Conceptually, there may choosing existing modeling languages or designing and im-
be sets of languages used on either side. In practice, a base plementing adequate DSMLs. In fact, it must be possible to
technology such as the Java Virtual Machine (JVM) and its introduce new DSMLs easily and quickly to realize certain
byte code format acts as a unifier. Programming languages parts of a system as a model. In turn, the use of models of a
given DSML requires support for the following core activities:
integrate
(i) building models, e.g., using an application programming LComputation LGUI
interface or an editor, (ii) binding models into components
use use
as building blocks, e.g., following the MoCo Template and
(iii) using models, e.g., querying, transforming and interpreting «moco»
IsaCarProduct1
them. These activities can only be supported if there is a
powerful technological space [5] for modeling languages and
models, which provides all relevant capabilities needed. In the «moco»
IsaConfig
context of MoCos, such a technological space needs to work
together with the respective component execution platform [6] use
or even be part of it.
LFeatureTrees
There are examples for such technological spaces like the
Eclipse Modeling Framework (EMF) [7] or JGraLab [8] that
deliver acceptable support for language design, especially for Model-Integrating «moco»
integrate
Component IsaCarProduct1
syntax and constraints. Additionally, many research works use
Modeling
models at runtime in various ways and this specific topic is Language
LComputation use
still a very relevant research area [9].
While different approaches and solutions for modeling and Fig. 2. MoCo-based ISA Client App and an Architecture Excerpt
models at runtime already exist in isolation, we observe that
they do not comprehensively address the required capabilities
for designing new modeling languages that shall be an inte- is dynamically extensible at the component level and single
grated part of a software system. Moreover, the challenges components’ internals can be also monitored and modified
associated with designing DSMLs that support the symbiosis at runtime. For example, insurance fee formulas are adapted,
of models at runtime and code within software components based on the current physical location of a customer. A
have to be inspected. screenshot of ISA is shown in Figure 2 (left), illustrating one
This paper tackles the following research problems and their of the views of the Graphical User Interface (GUI) specific to
associated challenges: the car insurance product.
(Q1) How to specify modeling languages comprehensively for ISA’s architecture consists of a mix of pure Java libraries
generating adequate runtime support for them? and MoCos, i.e., a certain part of the running software is en-
(Q2) What are challenges for modeling languages in the coded in models that are used at runtime, e.g., by querying and
context of MoCos? transforming them. An excerpt is depicted in Figure 2 (right).
The specific modeling languages used represent (i) feature
C. Contributions trees (Lf ) for architectural reconfiguration, (ii) computation
In answering Q1, we propose that the introduction of a new (Lc ) for insurance fee formulas and (iii) graphical user
DSML requires a Comprehensive Language Model (CLM), interfaces (Lg ) for data presentation and user input capturing.
i.e., a specification of a modeling language to such an extent Regarding implementation, all MoCos conform to the struc-
that all required activities on models are supported. We claim ture proposed by the MoCo Template. For components, we
that each CLM should at least specify the following parts of used OSGi’s [11] dynamic component technology, code was
DSML: (i) syntax (metamodel and constraints), (ii) semantics written in Java and models were developed in JGraLab [8].
(dynamic state, constraints, state transitions) and (iii) prag- The base execution platform is the Java Virtual Machine.
matics (at least facades [10]). We assume that a realization of
a modeling language Li will be derived from a CLMi . A. Comprehensive Language Model for Lc
In answering Q2, we provide a description of selected As a clarification for what exactly a Comprehensive Lan-
challenges related to the seamless integration of models and guage Model (CLM) is, we give an example in the context of
code in software components, based on the Insurance Sales the ISA case study. More concretely, we describe the CLM
App (ISA) case study [1]. All in all, we aim to raise awareness for Lc in the following and sketch how it relates to Lg . This
for this topic and to initiate a fruitful discussion. background knowledge is required to understand some of the
challenges described later in this paper.
II. RUNNING E XAMPLE : I NSURANCE S ALES A PP CLMc , i.e., the CLM that fully specifies the modeling
The Insurance Sales App (ISA) is a prototypical application language Lc , is depicted in Figure 3. It consists of three major
for Google’s Android mobile operating system. It has been parts: syntax, semantics and pragmatics.
developed to evaluate the feasibility of MoCos [1], [2]. It 1) Syntax Specification: Lc ’s syntax is specified using a
also serves as a running example throughout the rest of this UML-style metamodel and mostly represents the static struc-
paper. From the user’s perspective, ISA’s primary purpose ture. The language represents programs (Prog) consisting
is to support field staff in the insurance domain with their of statements (Stmt). There are special statements such as
daily sales tasks. The system is built with MoCos, thus it conditional (If), an assignment (Ass) and further specific
CLM
Computation
Syntax Semantics Pragmatics
A Note on Semantics, Version 0.1
then {ordered}
Stmt Prog
else Jürgen Ebert class ComputationModel
{
/∗ constructor that reads a
[[Stmt]] : (Var !Double) ! (Var ! Double)
8 a : Ass [[a]](s) = s {a.left 7! a.right.val } formula from a file ∗/
If Ass Store Load
8 i : If [[i ]](s) = if isTrue(i .cond .val ) then [[i .then]](s) else [[i .else]](s) end ComputationModel (String fileID);
[[Expr ]] : Expr ! Double /∗ reads the value of a variable ∗/
8 c : Const [[c]] = c.val Double getVariable (String varID);
8 v : Var [[v ]] = v .val
right
cond 8 b : Bin [[b]] = case b.op of
’+’: b.left.val + b.right.val ; /∗ sets the value of a variable ∗/
left Expr
’-’: b.left.val b.right.val ; void setVariable (String varID, Double val);
right ’*’: b.left.val ⇤ b.right.val ;
val : Double
’/’: b.left.val /b.right.val ; /∗ evaluates an expression according to the
left var var end current values of the variables ∗/
8 l : Load Double evaluate (String progID);
[[l ]](sc ,sg ) : (sc {l .var !l .loadValFrom.value}, sg ) }
Bin Const Var
8 st : Store
op : Char [[st]](sc ,sg ) : (sc , sg {st.storeValIn !st.var .val })
Fig. 3. CLMc Comprising the Specification of Syntax (Dynamic Metamodel), Semantics (Dynamic Metamodel + State Transitions) and Pragmatics (Facade)
statements for loading (Load) and saving (Store) vari- B. Integration of Lc and Lg
ables (Var). Variables and constants (Const) are expressions
(Expr). Expressions have a value (val) as well as a left and Besides the use of single modeling languages, it is particu-
right side of a specified binary operator (Bin). larly interesting when multiple languages are used together.1 In
2) Semantics Specification: Lc ’s semantics is specified the context of ISA, each insurance product MoCo carries the
(i) by extending the metamodel with information about the insurance fee formula (an instance of Lc ) and its correspond-
dynamic state and (ii) by adding a description of state transi- ing representation of the graphical user interface (an instance
tions by following Plotkin’s Structured Operational Semantics of Lg ). The two modeling languages had to be integrated.
(SOS) approach [12]. This was an ad-hoc, pragmatic choice. For this purpose, additional associations (loadValFrom and
Like in Dynamic Metamodeling [13], Lc ’s metamodel ele- storeValIn roles) were introduced A Note and the specification
on Semantics, Version 0.1
ments depicted in Figure 3 also cover the dynamic state of its of state transitions in CLMc was extended to encode the
set of conforming models. The dynamic state is part of the semantics of loading values from the GUI (Load) Jürgen and Ebert
storing
semantics specification of Lc which is an essential part of any values from a formula in the GUI’s TextView (Load). In
[[Stmt]] : (Var !Double) ! (Var ! Double)
CLM. The attribute val belonging to the dynamic state can Figure 4, the corresponding integration
8 a : Ass via= sadditive
[[a]](s) extension
{a.left 7! a.right.val }
8 i : If [[i ]](s) = if isTrue(i .cond .val ) then [[i .then]](s) else [[i .else
be changed during model execution. of two CLMs is given.
[[Expr ]] : Expr ! Double
In terms of encoding the allowed state transitions in the 8 c : Const [[c]] = c.val
dynamic state, we chose Plotkin’s approach as a technology- 8 v : Var [[v ]] = v .val
CLMGUI CLMComputation
8 b : Bin [[b]] = case b.op of
independent precise and comprehensible formalism. For ex- ’+’: b.left.val + b.right.val ;
’-’: b.left.val b.right.val ;
ample, as shown in Figure 3, the semantics of a Stmt in Syntax Syntax Semantics
’*’: b.left.val ⇤ b.right.val ;
’/’: b.left.val /b.right.val ;
Lc is that a given variable’s value is replaced with another loadValFrom end
(potentially the same) value. Load
8 l : Load
3) Pragmatics Specification: Lc ’s pragmatics is specified Textview [[l ]](sc ,sg ) : (sc {l .var !l .loadValFrom.value}, sg )
using a facade, e.g., using a notation similar to Java classes value : String 8 st : Store
[[st]](sc ,sg ) : (sc , sg {st.storeValIn !st.var .val })
as illustrated in Figure 3. This approach facilitates the use of Store
storeValIn
models similar to code objects. Moreover, the specification of
available services on models of a given language, here Lc , sup-
ports communication between modeling language designers,
Fig. 4. Integration of two Comprehensive Language Models
software architects and software engineers. We use the term
services on models to denote capabilities and functionalities
specific to a modeling language that facilitate the use of CLMs support the specification and design of modeling
models. These services are realized as facades. languages to be used within model-integrating software com-
For example, the ComputationModel facade allows to ponents as described. However, there are still many open
load a model from a file, to get and set a value for a variable challenges that need to be tackled.
and, importantly, to evaluate a model (e.g., representing an
insurance fee formula in ISA) by starting model execution at 1 The GEMOC initiative (http://gemoc.org/) provides related work on the
a certain Prog element. coordinated use of heterogeneous modeling languages.
TABLE I functionality dictates a clean separation of concerns between
I NITIAL L IST OF C HALLENGES FOR M ODELING L ANGUAGES IN M O C OS the various MoCos. As in any other component-based software
systems, MoCos are connected with each other via provided
ID Challenge Description
and required interfaces. While separation of concerns has
Syntax
C1 How to modularize metamodels?
many well-known advantages, it has one major disadvantage
C2 How to integrate two metamodels? in the context of MoCos: the flexibility that comes with
C3 How to establish links between different models? the ability to query and transform a single (possibly large)
C4 How to provide a context-dependent view on sets of models?
interconnected model can no longer be leveraged if single
Semantics models are distributed and encapsulated across individual
C5 How to specify model semantics?
C6 How to realize model execution?
MoCos (C3). There are no associations between them on the
C6.1 How to manage the dynamic state of a model? model-level. The ability to establish links and to access these
C6.2 How to reuse model interpreters? distributed models is especially helpful to debug MoCos and
C6.3 How to support the interplay of different model interpreters?
C7 How to support variants of semantics for the same modeling
their interdependencies. In ISA for example, it is interesting
language? to know the available insurance fee formulas (contained in
Pragmatics IsaCarProduct1) for a specific feature configuration (con-
C8 How to establish control and data flow between models and code? tained in IsaConfig).
C9 How to design language-specific and usage-specific services on 4) Context-Dependent Views on Models: Modeling lan-
models?
C10 How to control access to models? guages and their metamodels are only partly used, i.e., the
available expressiveness is not required and a restricted meta-
model will be sufficient. Moreover, only some data may be
III. C HALLENGES relevant for a certain use case and MoCo. The ability to
define an adequate and context-specific view on sets of models
Building on the use of CLMs, we elaborate on an initial list (C4) helps to reduce complexity and supports ease of use of
of challenges for modeling languages in the context of MoCos DSMLs. In fact, a view can be seen as a specification for the
using the ISA running example. For readability, we formulate model parts that can be used by another MoCo. In ISA for
each challenge as a question and cluster them according to example, an adaptation manager MoCo may need to control
(i) syntax, (ii) semantics and (iii) pragmatics as summarized certain location-dependent variables of the insurance fees and
in Table I. A detailed description follows subsequently. their associated GUI elements. These parts could be encoded
by a special adaptation view.
A. Syntax Challenges
1) Modularization of Metamodels: Software architects fol- B. Semantics Challenges
low a divide-and-conquer approach and split larger systems 1) Specification of Model Semantics: The models in MoCos
in smaller pieces, e.g., into software components and con- are not only used as pure data (similar to databases) but
nectors. A standardized approach for the modularization of some are also executed. Therefore, the semantics of modeling
modeling languages is missing, though. A main part of any languages needs to be precisely specified (C5). There is a
DSML’s definition is the specification of its syntax with a multitude of options available and one can choose between a
metamodel. While package-structures and import mechanisms spectrum of rather informal and very formal approaches [14].
are available, depending on the concrete modeling technology, It is important to choose a formalism that is both sufficiently
the modeling language designer cannot orchestrate modeling formal but also adequately practical for software engineers
languages and their metamodels in a black-box fashion (C1). and modeling language designers. In ISA for example, all
In ISA for example, feature models (Lf ) are managed and used three modeling languages are executable: Lf is interpreted for
by a MoCo called IsaConfig and insurance fees models architectural reconfiguration, Lc is interpreted to compute an
(Lc ) as well as GUI models (Lg ) are managed and used by insurance fee and Lg is interpreted to create and synchronize
insurance products like the IsaCarProduct1 MoCo. an Android-specific graphical user interface for each insurance
2) Integration of Metamodels: Integration means that at product represented by a single MoCo.
least two existing modeling languages shall be merged. In 2) Realization of Model Execution: Given a specification of
contrast to distributed, potentially not connected models con- semantics for a modeling language, this specification needs to
forming to different metamodels, this approach conveniently be implemented (C6) and related decisions need to be taken
enables full access, e.g., via model queries, to the conforming carefully. In general, there has been no commonly accepted
models of this integrated modeling language (C2). In ISA proposal for the realization of model semantics/model inter-
for example, insurance fee models and GUI models are preters, yet. Besides the development of stand-alone inter-
used tightly together within the IsaCarProduct1 MoCo, preters and model interpreters embedded into the metamodel,
e.g., values from computed fees are directly associated with code generation is another option. Each approach has its ad-
elements of the user interface. vantages and disadvantages, e.g., with regards to performance,
3) Links between Different Models: In a MoCo-based complexity and reusability. In ISA for example, there is at least
software system, the architectural decomposition based on one model interpreter for each modeling language.
One sub-challenge that is critical in the case of interpretation Template already defines a pattern with its Mediator and
is the way to deal with the parts of a model that may change sketched interfaces. We deem it important to further stan-
during interpretation (C6.1). We refer to them as the model’s dardize these interfaces and to provide realization guidelines,
dynamic state, in contrast to the rest of the model, the static e.g., in the scope of our reference implementation (MoCo
structure. While these parts can be regarded as the execution API) [1]. The design and development of language-specific
context of a stand-alone model interpreter, it can be also seen facades encapsulating required services as a part of a CLM
as a part of the actual model. In ISA for example, models needs to be researched. In ISA for example, there is code
of the kind of Lf , i.e., feature configurations, are used for for sending an email report in the MoCoCode module of
runtime reconfiguration. This implies that the state of a feature the IsaCarProduct1 MoCo that receives data from the
(selected or not selected) varies. This information can be MoCoModel module (insurance fee model, GUI model).
stored separately by the model interpreter (e.g., technically as a 2) Services on Models: When talking about services on
hashmap) or it can be a Boolean attribute in the Lf metamodel. models, two categories need to be distinguished: (i) foreseen
A second sub-challenge is related to the reuse of model in- services that are provided by the modeling language designer
terpreters (C6.2). In this specific case, one needs to distinguish and (ii) unforeseen services that are specific to a certain
between (i) reuse of model interpreter implementations and user of a modeling language (e.g., a system or a compo-
(ii) their instances at runtime. Depending on the chosen type of nent). Moreover, modeling languages – especially DSMLs
implementation, the reuse potential varies. In ISA for example, as primarily used in MoCos – need to be compact and
the same feature model can be interpreted by different model adequately expressive. A strategy and a set of mechanisms is
interpreters concurrently if the dynamic state, i.e., the feature required to specify context-specific services, realize them and
selection flag, is stored by the model interpreters themselves. to manage the resulting variability (C9). In ISA for example,
On the contrary, if the dynamic state is part of each model different insurance products, i.e., different MoCos, require
but needs to be different per semantics, then the model needs similar special services, like email reporting. This particular
to be duplicated or an embedded model interpreter needs to service was not initially foreseen when developing Lc and Lg .
instantiate the dynamic state multiple times. Therefore, it was first developed as a part of the respective
A third sub-challenge is related to the interdependencies MoCoCode module, resulting in clones across the different
of semantics and, hence, the interplay of model interpreters insurance product MoCos. To solve such issues, often required
(C6.3). Ideally, each modeling language comes with its own and DSML-specific services need to be offered by a facade as
set of model interpreters. In case that two modeling languages a part of the CLM.
need to be used together, it is required that not only their 3) Access Control for Models: Given the power of models
metamodels are integrated (see C2) but it is also necessary in the MoCo concept, any kind of analysis or manipulation
that their semantics fit. In the simplest form, one model needs to be controlled (C10). Models need to be accessible
interpreter invokes another model interpreter, which asks for a only in predefined authorized, i.e., safe and secure, ways. It
more sophisticated management of dependencies – especially needs to be decided whether models can be accessed using the
if these shall be dynamic. In ISA for example, each insurance MoCos’ interfaces only or if there is a more powerful role that
product MoCo encapsulates an insurance fee formula model can inspect everything, i.e., all models within all MoCos across
and a GUI model. Given that their metamodels were previously the system architecture. Indeed, there is a tradeoff between
integrated, the model interpreter of Lc (i) may access meta- flexibility and encapsulation. In ISA for example, obviously
classes of Lg and operate on them (e.g., store a computed insurance fee formulas should not be editable by anyone, even
insurance fee in a text field), or (ii) may invoke the model though this is technically possible at any time using model
interpreter of Lg to perform the task. transformations. An adaptation manager MoCo that adjusts the
3) Variants of Semantics: We experienced that while for fee formulas according to the geolocation of the sales person
some modeling language (especially general-purpose model- and potential customer requires exactly this ability, though.
ing languages) a single semantics specification is sufficient,
in the case of DSMLs, multiple semantics for the same IV. R ELATED W ORK
modeling language need to be supported (C7). Therefore, in While there are works that deal with individual challenges
this context, a modeling language becomes a software product described in this paper, we observe that a comprehensive
line. Reuse is critical to deal with complexity and to avoid solution approach is missing. The work on Model-Integrated
redundancy and duplication. In ISA for example, there may Computing, initiated by Sztipanovits and Karsai [15], targets
be behavioral semantics (dynamic reconfiguration), constraint similar issues but lacks the runtime aspect. Due to limited
checking semantics and visualization semantics for Lf . space, we can only hint at an excerpt of related work here.
Regarding the topic of syntax, Heidenreich et al. [16]
C. Pragmatics Challenges present a generic approach for the composition of models that
1) Data and Control Flow between Model and Code: In is based on invasive software composition and the Reuseware
MoCos, models and code coexist and realize the functionality Composition Framework. Krahn et al. [17] use an extended
of the component together. It is important to be able to grammar format that supports language inheritance and em-
invoke models from code and vice versa (C8). The MoCo bedding for the modular development of textual domain-
specific languages. Bae et al. [18] propose to modularize a [3] M. Derakhshanmanesh, M. Amoui, G. O’Grady, J. Ebert, and L. Tahvil-
large metamodel into a set of small metamodels and present dari, “GRAF: Graph-based Runtime Adaptation Framework,” in Pro-
ceeding of the 6th international symposium on Software engineering for
their idea of model slicing along the UML. In contrast to adaptive and self-managing systems - SEAMS ’11. New York, NY,
modularization approaches, Atkinson et al. propose a Single- USA: ACM Press, May 2011, pp. 128–137.
Underlying-Model (SUM) [19] that serves all users. [4] G. Blair, N. Bencomo, and R. B. France, “Models@run.time,” Computer,
vol. 42, no. 10, pp. 22–27, 2009.
Regarding the topic of semantics, Plotkin [12] proposes a [5] I. Kurtev, J. Bézivin, and M. Aksit, “Technological Spaces: An Initial
structural approach to operational semantics. Engels et al. [13] Appraisal,” in International Symposium on Distributed Objects and
describe dynamic metamodeling as a graph-based approach to Applications, DOA 2002, 2002.
[6] I. Crnkovic, S. Sentilles, A. Vulgarakis, and M. R. V. Chaudron,
the specification of semantics for (behavioral) modeling lan- “A Classification Framework for Software Component Models,” IEEE
guages. The Object Management Group (OMG) [20] provides Transactions on Software Engineering, vol. 37, no. 5, pp. 593–615, 2011.
a specification of the semantics of a foundational subset for [7] “Eclipse Modeling Framework Hompage,” https://eclipse.org/modeling/
emf/ (accessed July 16th, 2015).
executable UML models (fUML) using activity diagrams and a [8] “JGraLab Hompage,” http://jgralab.uni-koblenz.de (accessed July 15th,
dedicated action language. Mayerhofer [14] comprehensively 2015).
describes the state of the art in model execution. [9] S. Götz, N. Bencomo, and R. France, “Devising the Future of the
Models@Run.Time Workshop,” SIGSOFT Softw. Eng. Notes, vol. 40,
Regarding the topic of pragmatics, Balz et al. [21] discuss no. 1, pp. 26–29, Feb. 2015.
the embedding of behavioral models (state machines) into [10] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
object-oriented source code. Ecore Facade [22] is a textual Elements of Reusable Object-Oriented Software. Boston, MA, USA:
Addison-Wesley Longman Publishing Co., Inc., 1995.
domain-specific language for annotating existing Ecore meta- [11] The OSGi Alliance, “OSGi Core Release 5,” The OSGi Alliance, Tech.
models. This mechanism can be used to define multiple views Rep. March, 2012, http://www.osgi.org/Download/File?url=/download/
for a single metamodel via Ecore facade models. The survey r5/osgi.core-5.0.0.pdf (accessed July 15th, 2015).
[12] G. D. Plotkin, “A Structural Approach to Operational Semantics,” 1981.
by Szvetit and Zdun [23] covers existing research on models [Online]. Available: http://homepages.inf.ed.ac.uk/gdp/publications/
at runtime and software architecture in detail. [13] G. Engels, J. H. Hausmann, R. Heckel, and S. Sauer, “Dynamic Meta-
Modeling: A Graphical Approach to the Operational Semantics of
Behavioral Diagrams in UML,” in Proceedings of the 3rd international
V. C ONCLUDING R EMARKS conference on the Unified Modeling Language (UML 2000), York (UK),
ser. LNCS, B. S. A. Evans, S. Kent, Ed., vol. 1939. Berlin/Heidelberg:
In this paper, we introduced comprehensive language mod- Springer, 2000, pp. 323–337, third International Conference.
els as a way to specify modeling languages in the context of [14] T. Mayerhofer, “Defining Executable Modeling Languages with fUML,”
model-integrating software components. Moreover, we gave Ph.D. dissertation, Institute of Software Technology and Interactive
Systems, 2014.
concrete examples along the insurance sales app study and [15] J. Sztipanovits and G. Karsai, “Model-Integrated Computing,” Com-
elaborated on a first set of challenges. puter, vol. 30, no. 4, pp. 110–111, Apr. 1997.
We conclude that an infrastructure is needed that provides [16] F. Heidenreich, J. Henriksson, J. Johannes, and S. Zschaler, “On
Language-Independent Model Modularisation,” in Transactions on
all model-specific services in a light-weight, homogeneous, Aspect-Oriented Software Development VI, ser. Lecture Notes in Com-
formally founded, easily understandable, and efficient manner puter Science, S. Katz, H. Ossher, R. France, and J.-M. Jézéquel, Eds.
using a comprehensive technological modeling space supply- Springer Berlin Heidelberg, 2009, vol. 5560, pp. 39–82.
[17] H. Krahn, B. Rumpe, and S. Völkel, “MontiCore: Modular Development
ing full modeling and metamodeling support, and coherent of Textual Domain Specific Languages,” in Objects, Components, Mod-
interoperable services based on a powerful data structure. els and Patterns, ser. Lecture Notes in Business Information Processing,
Regarding future work, we plan to carry out additional case R. Paige and B. Meyer, Eds. Springer Berlin Heidelberg, 2008, vol. 11,
pp. 297–315.
studies to identify further challenges for the infrastructure [18] J. H. Bae, K. Lee, and H. S. Chae, “Modularization of the UML
needed to support model-integrating software components. In Metamodel Using Model Slicing,” in Information Technology: New
the long run, we aim to manifest our lessons learned in a Generations, 2008. ITNG 2008. Fifth International Conference on, April
2008, pp. 1253–1254.
systematically derived engineering method [24]. [19] C. Atkinson, R. Gerbig, and C. Tunjic, “A Multi-level Modeling
Environment for SUM-based Software Engineering,” in Proceedings of
ACKNOWLEDGMENT the 1st Workshop on View-Based, Aspect-Oriented and Orthographic
Software Modelling, ser. VAO ’13. New York, NY, USA: ACM, 2013,
This work is supported by the Deutsche Forschungsgemein- pp. 2:1—-2:9.
schaft (DFG) under grants EB 119/11-1 and EN 184/6-1. The [20] The Object Management Group, “Semantics of a Foundational Subset
for Executable UML Models (fUML),” p. 441, 2012. [Online].
authors would like to thank Gregor Engels for his valuable Available: http://www.omg.org/spec/FUML/
feedback and Thomas Iguchi for his implementation support. [21] M. Balz, M. Striewe, and M. Goedicke, “Embedding Behavioral Models
into Object-Oriented Source Code,” Proceedings of ”Software Engineer-
R EFERENCES ing 2009”, 2009.
[22] “Ecore Facade,” 2015. [Online]. Available: http://www.emftext.org/
[1] M. Derakhshanmanesh, J. Ebert, T. Iguchi, and G. Engels, “Model- index.php/EMFText Concrete Syntax Zoo Ecore Facade
Integrating Software Components,” in Model-Driven Engineering Lan- [23] M. Szvetits and U. Zdun, “Systematic literature review of the objectives,
guages and Systems - 17th International Conference, MODELS 2014, techniques, kinds, and architectures of models at runtime,” Software &
Valencia, Spain, September 28 - October 3, 2014. Proceedings, ser. Systems Modeling, pp. 1–39, 2013.
Lecture Notes in Computer Science, J. Dingel, W. Schulte, I. Ramos, [24] G. Engels and S. Sauer, “A Meta-Method for Defining Software
S. Abrahão, and E. Insfrán, Eds., vol. 8767. Springer, 2014, pp. 386– Engineering Methods,” in Graph Transformations and Model-Driven
402. Engineering, ser. Lecture Notes in Computer Science, G. Engels,
[2] M. Derakhshanmanesh, Model-Integrating Software Components - En- C. Lewerentz, W. Schäfer, A. Schürr, and B. Westfechtel, Eds. Springer
gineering Flexible Software Systems. Springer, 2015. Berlin Heidelberg, 2010, vol. 5765, pp. 411–440.