-Model-Integrating Software Components (MoCos) use models at runtime as first class entities within components to build flexible and adaptive software systems. Building such systems requires to design and implement the required domainspecific modeling languages. Insufficient design and realization of modeling languages raises the risk that they may not be optimized for their later use. Although various works on the use of models at runtime exist, they do not address the engineering of modeling languages to be used in software components at runtime. In this paper, we introduce the idea of Comprehensive Language Models (CLMs) which explicitly considers modeling language engineering as a part of the development of component based software systems. This is achieved by extending the modeling 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 on Android based on which we derive a set of key challenges for the community.
Models are no longer just used to design software but can
become an integrated part of it, i.e., (executable) models and
code coexist at runtime with equal rights. In previous works
[
The MoCo-approach combines models described using arbitrary Domain-Specific Modeling Languages (DSMLs) and embeds them within software components following a tailorable component design pattern that guides software engineers: the MoCo Template. It is depicted in Figure 1 and briefly introduced, next.
Each MoCo can have ports (PFunction, PManage) that are wired to the internal implementation, which is either encoded by a programming language (MoCoCode) or by a modeling language (MoCoModel). Conceptually, there may be sets of languages used on either side. In practice, a base technology such as the Java Virtual Machine (JVM) and its byte code format acts as a unifier. Programming languages «module» MoCoCode «module»
MoCoModel «component»
MoCo IModelState
IModelState ICodeState IInterpret IAction «l»euodm itraeodM ICIInotdeerpSrteatte
IAction «delegate» «delegate» are used on the code side, e.g., Java, and different – potentially integrated – DSMLs are used on the model side. Both constituents of a MoCo are encapsulated using interfaces. Optionally, a smart Mediator can manage any redirection from and to the MoCo’s ports as well as communication between the model and code parts.
The expected advantages of the MoCo approach are: (i)
enhanced flexibility because the system and its individual
components can be observed using model queries, can be modified by
adapting models using an editor or model transformations and
can be executed using model interpreters [
An essential difference between component-based and
model-integrating software is the use of various models at
runtime (not just reflective models@run.time [
There are examples for such technological spaces like the
Eclipse Modeling Framework (EMF) [
While different approaches and solutions for modeling and 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 integrated part of a software system. Moreover, the challenges associated with designing DSMLs that support the symbiosis of models at runtime and code within software components have to be inspected.
This paper tackles the following research problems and their associated challenges: (Q1) How to specify modeling languages comprehensively for generating adequate runtime support for them? (Q2) What are challenges for modeling languages in the context of MoCos?
In answering Q1, we propose that the introduction of a new
i.e., a specification of a modeling language to such an extent
that all required activities on models are supported. We claim
that each CLM should at least specify the following parts of
DSML: (i) syntax (metamodel and constraints), (ii) semantics
(dynamic state, constraints, state transitions) and (iii)
pragmatics (at least facades [
In answering Q2, we provide a description of selected
challenges related to the seamless integration of models and
code in software components, based on the Insurance Sales
App (ISA) case study [
The Insurance Sales App (ISA) is a prototypical application
for Google’s Android mobile operating system. It has been
developed to evaluate the feasibility of MoCos [
integrate use «moco» IsaCarProduct1 «moco»
IsaConfig use
use Model-Integrating «moco»
Component IsaCarProduct1
integrate Modeling Language
LComputation use is dynamically extensible at the component level and single components’ internals can be also monitored and modified at runtime. For example, insurance fee formulas are adapted, based on the current physical location of a customer. A screenshot of ISA is shown in Figure 2 (left), illustrating one of the views of the Graphical User Interface (GUI) specific to the car insurance product.
ISA’s architecture consists of a mix of pure Java libraries and MoCos, i.e., a certain part of the running software is encoded in models that are used at runtime, e.g., by querying and transforming them. An excerpt is depicted in Figure 2 (right). The specific modeling languages used represent (i) feature trees (Lf ) for architectural reconfiguration, (ii) computation (Lc) for insurance fee formulas and (iii) graphical user interfaces (Lg) for data presentation and user input capturing.
Regarding implementation, all MoCos conform to the
structure proposed by the MoCo Template. For components, we
used OSGi’s [
As a clarification for what exactly a Comprehensive Language Model (CLM) is, we give an example in the context of the ISA case study. More concretely, we describe the CLM for Lc in the following and sketch how it relates to Lg. This background knowledge is required to understand some of the challenges described later in this paper.
CLMc, i.e., the CLM that fully specifies the modeling language Lc, is depicted in Figure 3. It consists of three major parts: syntax, semantics and pragmatics.
UML-style metamodel and mostly represents the static structure. The language represents programs (Prog) consisting of statements (Stmt). There are special statements such as conditional (If), an assignment (Ass) and further specific then else statements for loading (Load) and saving (Store) variables (Var). Variables and constants (Const) are expressions (Expr). Expressions have a value (val) as well as a left and right side of a specified binary operator (Bin).
(i) by extending the metamodel with information about the
dynamic state and (ii) by adding a description of state
transitions by following Plotkin’s Structured Operational Semantics
(SOS) approach [
Like in Dynamic Metamodeling [
In terms of encoding the allowed state transitions in the dynamic state, we chose Plotkin’s approach as a technologyindependent precise and comprehensible formalism. For example, as shown in Figure 3, the semantics of a Stmt in Lc is that a given variable’s value is replaced with another (potentially the same) value.
3) Pragmatics Specification: Lc’s pragmatics is specified using a facade, e.g., using a notation similar to Java classes as illustrated in Figure 3. This approach facilitates the use of models similar to code objects. Moreover, the specification of available services on models of a given language, here Lc, supports communication between modeling language designers, 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 models. These services are realized as facades.
For example, the ComputationModel facade allows to load a model from a file, to get and set a value for a variable and, importantly, to evaluate a model (e.g., representing an insurance fee formula in ISA) by starting model execution at a certain Prog element.
Besides the use of single modeling languages, it is particularly interesting when multiple languages are used together.1 In the context of ISA, each insurance product MoCo carries the insurance fee formula (an instance of Lc) and its corresponding representation of the graphical user interface (an instance of Lg). The two modeling languages had to be integrated. For this purpose, additional associations (loadValFrom and storeValIn roles) were introduceAd Nanodte tohne Ssepmecainfitcicasti,oVnersion 0.1 of state transitions in CLMc was extended to encode the semantics of loading values from the GUI (Load) Jau¨rngedn Esbtoerrting values from a formula in the GUI’s TextView (Load). In [Stmt] : (Var !Double) ! (Var ! Double) Figure 4, the corresponding i n8tae:gArsastio[na](vs)i=a sadda.iletfitv7!e ae.rxigthet.nvasl}ion of two CLMs is given. 8 i : If [i](s) = if isT{rue(i.cond.val) then [i.then](s) else [i.els CLMGUI
Syntax
loadValFrom
Textview value : String storeValIn
Load Store [Expr] : Expr ! Double 8 c : Const [c] = c.val 8 v : Var [v] = v.val CLMComputati8obn: Bin [b] = cas’+e’b:.bop.leoftf.val + b.right.val;
Syntax Sem’’-*’’:a:bnb..tlleiecfftts..vvaall ⇤ bb..rriigghhtt..vvaall;; ’/’: b.left.val/b.right.val; end 8 l : Load [l](sc,sg) : (sc {l.var !l.loadValFrom.value}, sg) 8 st : Store [st](sc,sg) : (sc, sg {st.storeValIn !st.var.val})
CLMs support the specification and design of modeling languages to be used within model-integrating software components as described. However, there are still many open challenges that need to be tackled.
1The GEMOC initiative (http://gemoc.org/) provides related work on the coordinated use of heterogeneous modeling languages.
Building on the use of CLMs, we elaborate on an initial list of challenges for modeling languages in the context of MoCos using the ISA running example. For readability, we formulate each challenge as a question and cluster them according to (i) syntax, (ii) semantics and (iii) pragmatics as summarized in Table I. A detailed description follows subsequently.
low a divide-and-conquer approach and split larger systems in smaller pieces, e.g., into software components and connectors. A standardized approach for the modularization of modeling languages is missing, though. A main part of any DSML’s definition is the specification of its syntax with a metamodel. While package-structures and import mechanisms are available, depending on the concrete modeling technology, the modeling language designer cannot orchestrate modeling languages and their metamodels in a black-box fashion (C1). In ISA for example, feature models (Lf ) are managed and used by a MoCo called IsaConfig and insurance fees models (Lc) as well as GUI models (Lg) are managed and used by insurance products like the IsaCarProduct1 MoCo.
2) Integration of Metamodels: Integration means that at least two existing modeling languages shall be merged. In contrast to distributed, potentially not connected models conforming to different metamodels, this approach conveniently enables full access, e.g., via model queries, to the conforming models of this integrated modeling language (C2). In ISA for example, insurance fee models and GUI models are used tightly together within the IsaCarProduct1 MoCo, e.g., values from computed fees are directly associated with elements of the user interface.
3) Links between Different Models: In a MoCo-based software system, the architectural decomposition based on functionality dictates a clean separation of concerns between the various MoCos. As in any other component-based software systems, MoCos are connected with each other via provided and required interfaces. While separation of concerns has many well-known advantages, it has one major disadvantage in the context of MoCos: the flexibility that comes with the ability to query and transform a single (possibly large) interconnected model can no longer be leveraged if single models are distributed and encapsulated across individual MoCos (C3). There are no associations between them on the model-level. The ability to establish links and to access these distributed models is especially helpful to debug MoCos and their interdependencies. In ISA for example, it is interesting to know the available insurance fee formulas (contained in IsaCarProduct1) for a specific feature configuration (contained in IsaConfig).
4) Context-Dependent Views on Models: Modeling languages and their metamodels are only partly used, i.e., the available expressiveness is not required and a restricted metamodel will be sufficient. Moreover, only some data may be relevant for a certain use case and MoCo. The ability to define an adequate and context-specific view on sets of models (C4) helps to reduce complexity and supports ease of use of DSMLs. In fact, a view can be seen as a specification for the model parts that can be used by another MoCo. In ISA for example, an adaptation manager MoCo may need to control certain location-dependent variables of the insurance fees and their associated GUI elements. These parts could be encoded by a special adaptation view.
B. Semantics Challenges
are not only used as pure data (similar to databases) but
some are also executed. Therefore, the semantics of modeling
languages needs to be precisely specified (C5). There is a
multitude of options available and one can choose between a
spectrum of rather informal and very formal approaches [
2) Realization of Model Execution: Given a specification of semantics for a modeling language, this specification needs to be implemented (C6) and related decisions need to be taken carefully. In general, there has been no commonly accepted proposal for the realization of model semantics/model interpreters, yet. Besides the development of stand-alone interpreters and model interpreters embedded into the metamodel, code generation is another option. Each approach has its advantages and disadvantages, e.g., with regards to performance, complexity and reusability. In ISA for example, there is at least one model interpreter for each modeling language.
One sub-challenge that is critical in the case of interpretation is the way to deal with the parts of a model that may change during interpretation (C6.1). We refer to them as the model’s dynamic state, in contrast to the rest of the model, the static structure. While these parts can be regarded as the execution context of a stand-alone model interpreter, it can be also seen as a part of the actual model. In ISA for example, models of the kind of Lf , i.e., feature configurations, are used for runtime reconfiguration. This implies that the state of a feature (selected or not selected) varies. This information can be stored separately by the model interpreter (e.g., technically as a hashmap) or it can be a Boolean attribute in the Lf metamodel.
A second sub-challenge is related to the reuse of model interpreters (C6.2). In this specific case, one needs to distinguish between (i) reuse of model interpreter implementations and (ii) their instances at runtime. Depending on the chosen type of implementation, the reuse potential varies. In ISA for example, the same feature model can be interpreted by different model interpreters concurrently if the dynamic state, i.e., the feature selection flag, is stored by the model interpreters themselves. On the contrary, if the dynamic state is part of each model but needs to be different per semantics, then the model needs to be duplicated or an embedded model interpreter needs to instantiate the dynamic state multiple times.
A third sub-challenge is related to the interdependencies of semantics and, hence, the interplay of model interpreters (C6.3). Ideally, each modeling language comes with its own set of model interpreters. In case that two modeling languages need to be used together, it is required that not only their metamodels are integrated (see C2) but it is also necessary that their semantics fit. In the simplest form, one model interpreter invokes another model interpreter, which asks for a more sophisticated management of dependencies – especially if these shall be dynamic. In ISA for example, each insurance product MoCo encapsulates an insurance fee formula model and a GUI model. Given that their metamodels were previously integrated, the model interpreter of Lc (i) may access metaclasses of Lg and operate on them (e.g., store a computed insurance fee in a text field), or (ii) may invoke the model interpreter of Lg to perform the task.
3) Variants of Semantics: We experienced that while for some modeling language (especially general-purpose modeling languages) a single semantics specification is sufficient, in the case of DSMLs, multiple semantics for the same modeling language need to be supported (C7). Therefore, in this context, a modeling language becomes a software product line. Reuse is critical to deal with complexity and to avoid redundancy and duplication. In ISA for example, there may be behavioral semantics (dynamic reconfiguration), constraint checking semantics and visualization semantics for Lf .
MoCos, models and code coexist and realize the functionality
of the component together. It is important to be able to
invoke models from code and vice versa (C8). The MoCo
Template already defines a pattern with its Mediator and
sketched interfaces. We deem it important to further
standardize these interfaces and to provide realization guidelines,
e.g., in the scope of our reference implementation (MoCo
API) [
2) Services on Models: When talking about services on models, two categories need to be distinguished: (i) foreseen services that are provided by the modeling language designer and (ii) unforeseen services that are specific to a certain user of a modeling language (e.g., a system or a component). Moreover, modeling languages – especially DSMLs as primarily used in MoCos – need to be compact and adequately expressive. A strategy and a set of mechanisms is required to specify context-specific services, realize them and to manage the resulting variability (C9). In ISA for example, different insurance products, i.e., different MoCos, require similar special services, like email reporting. This particular service was not initially foreseen when developing Lc and Lg. Therefore, it was first developed as a part of the respective MoCoCode module, resulting in clones across the different insurance product MoCos. To solve such issues, often required and DSML-specific services need to be offered by a facade as a part of the CLM.
in the MoCo concept, any kind of analysis or manipulation needs to be controlled (C10). Models need to be accessible only in predefined authorized, i.e., safe and secure, ways. It needs to be decided whether models can be accessed using the MoCos’ interfaces only or if there is a more powerful role that can inspect everything, i.e., all models within all MoCos across the system architecture. Indeed, there is a tradeoff between flexibility and encapsulation. In ISA for example, obviously insurance fee formulas should not be editable by anyone, even though this is technically possible at any time using model transformations. An adaptation manager MoCo that adjusts the fee formulas according to the geolocation of the sales person and potential customer requires exactly this ability, though.
While there are works that deal with individual challenges
described in this paper, we observe that a comprehensive
solution approach is missing. The work on Model-Integrated
Computing, initiated by Sztipanovits and Karsai [
Regarding the topic of syntax, Heidenreich et al. [
Regarding the topic of semantics, Plotkin [
Regarding the topic of pragmatics, Balz et al. [
els as a way to specify modeling languages in the context of model-integrating software components. Moreover, we gave concrete examples along the insurance sales app study and elaborated on a first set of challenges.
We conclude that an infrastructure is needed that provides all model-specific services in a light-weight, homogeneous, formally founded, easily understandable, and efficient manner using a comprehensive technological modeling space supplying full modeling and metamodeling support, and coherent interoperable services based on a powerful data structure.
Regarding future work, we plan to carry out additional case
studies to identify further challenges for the infrastructure
needed to support model-integrating software components. In
the long run, we aim to manifest our lessons learned in a
systematically derived engineering method [
This work is supported by the Deutsche Forschungsgemeinschaft (DFG) under grants EB 119/11-1 and EN 184/6-1. The authors would like to thank Gregor Engels for his valuable feedback and Thomas Iguchi for his implementation support.