=Paper=
{{Paper
|id=None
|storemode=property
|title=Separating Local and Global Aspects of Runtime Model Reconfiguration
|pdfUrl=https://ceur-ws.org/Vol-641/paper_05.pdf
|volume=Vol-641
|dblpUrl=https://dblp.org/rec/conf/models/TrollmannLA10
}}
==Separating Local and Global Aspects of Runtime Model Reconfiguration==
<pdf width="1500px">https://ceur-ws.org/Vol-641/paper_05.pdf</pdf>
<pre>
Separating Local and Global Aspects of Runtime
            Model Reconguration
             Frank Trollmann, Grzegorz Lehmann, Sahin Albayrak


                            DAI-Labor, TU Berlin
                       Faculty of Electrical Engineering
                            and Computer Science
       Frank.Trollmann@dai-labor.de, Grzegorz.Lehmann@dai-labor.de,
                       Sahin.Albayrak@dai-labor.de


      Abstract.    There is a growing need for applications that are able to
      adapt themselves to the context of use. One promising approach for the
      adaptation of an application during its execution is the use of models at
      runtime. In this approach models of the application and its context of
      use are kept alive during the execution. The application can be adapted
      by reconguring the structure of these models.
      Model Reconguration has local aspects as it handles the structure of a
      model and has to deal with its specic properties. It also possesses global
      aspects, as the joint reconguration of several models is required due to
      consistency considerations. This paper aims at solving possible conicts
      between the global and the local aspects of Model Reconguration by
      introducing a distinction between two Levels of abstraction that enables
      the designer to separate and interrelate global and local aspects of Model
      Reconguration.


1 Introduction
There is a growing need for applications that are able to adapt themselves to the
current context of use. Especially in dynamic and personalized areas like smart
homes such adaptive applications are important as they can adjust to the user's
specic needs as well as her environment. Adaptations trigger changes in the
applications user interface or behavior. In [1] the need for adaptations as well as
special challenges in this eld of research is stressed.
   Adaptability results in a growing complexity of software applications and
their development. According to [2], one promising approach for dealing with
this complexity is the models at runtime approach (also called models@run.time
approach). This approach is similar to Model Driven Engineering (MDE) [3],
where the development of a software application is accompanied by the creation
and transformation of a set of models. The dierence between these approaches
is in their goal. MDE aims to generate the nal application code from the in-
termediate models. The goal of the models@run.time approach is to keep the
models alive at runtime. In this approach the running application results from
an interpretation of these models.
   In the models@run.time approach a running application consists of a set
of models. These models represent dierent aspects of the application and its
context of use. The applications user interface and behavior result from the
interpretation of these models within a certain framework. The advantages of this
approach for adaptations are twofold. First, the current state of the application
and its context of use can easily be retrieved by querying the representing models.
This is essential because the application is supposed to react to these states by
adapting itself. Second, a change in the structure of one or more of these models
automatically aects the execution of the application. Thus, the adaptation of
an application can be achieved by changing the structure of its models. We call
such a structural change a Model Reconguration.
   Some adaptations of an application require the joint reconguration of several
models. This can be necessary if an intended adaptation is within the scope of
several models at once. Another reason for a joint reconguration of models is
to maintain the consistency in models that partially overlap in the aspects they
represent. According to this, Model Reconguration needs to have global aspects
that enable the designer to express joint recongurations of several models.
   A models@run.time framework may contain dierent models expressed in dif-
ferent modeling languages. Reconguration techniques are often specic to one
modeling language. This allows them to optimally deal with the specic struc-
tural and behavioral properties of this modeling language. This means Model
Reconguration also needs to have certain local aspects.
   When implementing a framework for Model Reconguration, there can be
a conict of interest between these local and global aspects. In this publication
we propose a distinction between a Recongurable Model and a Reconguration
Model. This distinction serves to establish a separation of concern between the
local and global aspects of Model Reconguration, which allows the designer to
model and interrelate both.
   The paper is structured as follows. First, in Section 2 the problems arising
from the global and local aspects of Model Reconguration are subsumed. Re-
congurable Models are then discussed in Section 3. Afterwards, our description
of the Reconguration Model is given in Section 4. In Section 5 existing ap-
proaches to Model Reconguration are introduced and related to the concepts
introduced in this paper. Section 6 gives a conclusion and hints to future work.


2 Problem Statement
While authors are clear about the overall goals of Model Driven Engineering,
the actual set of models required to build an application is far from xed. One
possible set of models is described in the CAMELEON Reference Framework
[4]. Current approaches dier in the set of used models, as well as the modeling
languages these models are described in.
   The same goes for models@run.time approaches. Several possible runtime en-
sembles of models do exist and several modeling languages are used for describing
these models. Techniques for Model Reconguration are often local to a certain
modeling language. This determines the local aspects of Model Reconguration.
   These local aspects are important because Model Reconguration is tightly
interwoven with the structure that is recongured. The advantage of a recon-
guration technique, specically tailored to a modeling language, is that it can
handle or preserve certain properties, specic to this modeling language. One
example for such a specic approach is the Graph Transformation technique,
analyzed in [5]. This technique can only be applied to P/T nets. Due to this
exclusiveness it is able to preserve the ring behavior of these net.
   It is also important to change the structure of several models at the same
time. This enables the designer to treat the set of runtime models as a consistent
whole. For example, the CAMELEON Reference Framework contains three dif-
ferent models for user interfaces: the Abstract, Concrete and Final User Interface
Model. When these models are used at runtime they have to be kept consistent
with each other. This can be best done by reconguring them jointly and thus
ensuring consistency after each reconguration.
   The set of runtime models within an application is not restricted to a xed set
of models. In addition, the models, used within one runtime ensemble are likely to
be modeled in dierent modeling languages. This constitutes a potential conict
between global and local aspects of Model Reconguration. According to the
local aspects it is possible that the designer chooses a dierent reconguration
technique for each model in the runtime ensemble. These techniques are local
to their modeling language and cannot be applied the other models. This is a
problem for the global aspects of Model Reconguration which require a joint
reconguration of the set of runtime models.
   Our approach towards these potential problems is to separate the local and
global aspects within two dierent components. The idea is to unite each model
and its local reconguration as a so-called Recongurable Model. A component,
called a Reconguration Model, steers the global recongurations. This model
uses the Recongurable Models in order to accomplish this goal.
   For this separation to work, the Reconguration Model should be able to
abstract from the following properties of the Recongurable Models:

  Model Kinds: The Reconguration Model should be independent of the kinds
    of used models as well as their purpose in order to not restrict the designer
    to a xed set of models.
  Modeling Language: The Reconguration Model should not be limited in the
    set of modeling languages it is able to recongure. This way the designer is
    free in her choice of modeling languages.
  Reconguration Technique: The Reconguration Model should be able to
    abstract from the used reconguration technique. This way the designer is
    free in her choice of reconguration technique.

   In Sections 3 and 4 the concepts of Recongurable Model and Reconguration
Model are introduced and discussed in detail.
   Figure 1 shows an example for excerpts of a Task and User Interface model
which are part of a runtime ensemble. The Task Model represents the applica-
tions structure of task and subtasks. The User Interface Model represents its
user interface. These two models represent the user interface of a login window
and its part of the task tree. The user is able to input username and password
in parallel and then nish the task Login by clicking on the login button.


             Fig. 1. Running Example: Two Models of a Login Mask


   One possible adaptation of the user interface is to show the input of user-
name and password in consecutive windows. A reason for this adaptation is the
availability of dierent authentication protocols. In this case it is not certain
that the user needs a password to log into the system. For example, he could
also be identied by the MAC Address of his devices. In this case the input of
a password becomes obsolete. Such an adaptation requires changes in the User
Interface Model and the Task Model. The user interface has to be adapted to
showing two windows. One to input the username and one to input the pass-
word. In addition the task model has to reect the fact that Input Username
and Input Password are now executed consecutive.
   This example is oversimplied as the reconguration is really more com-
plex than indicated here. The changes in the models are more complex due to
the requirement to reect more than one authentication method. In addition,
other models have to be recongured to connect the new user interface and its
execution logic. Nevertheless, this toy example already requires the joint recon-
guration of two models and will serve as a running example throughout the
rest of the paper.


3 Recongurable Model
The notion of a Recongurable Model is introduced in order to encapsulate
the local aspects of Model Reconguration. In each Recongurable Model the
designer is able to concentrate on the structural changes of one model. In this
scope she is able to choose a reconguration technique that suits her preferences.
In this Section the notion of a Recongurable Model is dened and discussed.
   A Recongurable Model is a model that can be recongured. In addition to
the models structure it contains means for changing this structure. A scheme for a
                      Fig. 2. Scheme of a Recongurable Model


Recongurable Model can be seen in Figure 2. A Recongurable Model consists
of a Structure and a set of Reconguration Operations. The Reconguration
Operations can be executed, resulting in a change of the structure. A more
formal denition of a Recongurable Model can be seen in Denition 1.

Denition 1 (Recongurable Model). A Recongurable Model r=(S,OPs)
consists of a model S, determining the Structure of the Recongurable Model,
and a set of Reconguration Operations OPs, that can be applied to change this
Structure.
   The Structure    S of a Recongurable Model is not restricted. An arbitrary
model conforming to an arbitrary meta model may constitute this structure.
Reconguration Operations      OPs represent ways to change S in a way that it
still conforms to its meta model. A more formal denition of a Reconguration
Operation is given in Denition 2.

Denition 2 (Reconguration Operation). A Reconguration Operation
for a meta model MM is a function OP : M → M mapping one model, that
conforms to MM to another one. M is the set of all models that conform to MM.
   A Reconguration Operation is a function that can be applied to the current
Structure   S to generate a new Structure. This operation strictly acts within the
set of models conforming to the meta model  MM of S. Thus, the Reconguration
Operations cannot violate the conformity to the meta model. A Reconguration
Operation can be executed from outside of the Recongurable Model without
any knowledge of   S. For each Reconguration Operation OP, a Reconguration
Endpoint    OP' is available which automatically applies OP to S.
   While modeling a Recongurable Model the designer has to provide the cur-
rent Structure   S as well as the set of Reconguration Operations OPs. In prin-
cipal, any model can be used for dening    S, regardless of its modeling language.
Based on this model and its modeling language, the designer then chooses the
most suitable reconguration techniques to model     OPs.
   This process represents the standard case of producing a Recongurable
Model. Other variations are also imaginable. For example the Reconguration
Operations could be generated automatically from another description of vari-
ability, like an enumeration of all possible structures.
   At runtime,   S is used as the initial structure of the Recongurable Model. The
Reconguration Operations can be executed in order to change this structure.
These operations and their Reconguration Endpoints enable external models,
like the Reconguration Model, to trigger changes in S.


       Fig. 3. Running Example: Recongurable User Interface and Task Model


   In our Running example there are two models that need to be made recon-
gurable. These are the Task and User Interface Model, introduced in Figure 1.
In Figure 3 their recongurable versions are depicted. In both cases the struc-
ture   S consists of the models introduced in Figure 1. Each model contains one
Reconguration Operation. In the Recongurable Task Model the two parallel
tasks Input Username and Input Password can be made consecutive. The
Reconguration Operation of the Recongurable User Interface Model splits the
login window and distributes the input elements for username and password.
   In the Figure it is not mentioned how these Recongurations are imple-
mented. The techniques, used in both models are independent from each other
and can be chosen by the designer. Due to the graphical representation of a
user interface she might decide to use a form of Graph Transformation in the
Recongurable User Interface Model. For changing one temporal operator in the
Recongurable Task Model she might choose an action as provided by the Ker-
Meta environment. These two Reconguration Operations describe the changes,
required for our Running Example. However, on the level of Recongurable Mod-
els it is not possible to interrelate these two model changes. This is the purpose
of the Reconguration Model, introduced in the next Section.


4 Reconguration Model

In the previous section Recongurable Models as an encapsulation of the local
aspects of Model Reconguration, are described. This section introduces the
notion of a Reconguration Model. This model builds upon the denition of
Recongurable Models and reects the global aspects of Model Reconguration.


                    Fig. 4. Scheme of a Reconguration Model


   A scheme for a Reconguration Model can be seen in Figure 4. A Recong-
uration Model contains High Level Reconguration Operations. Each of them
is connected to a trigger, which is responsible for determining when to execute
this Operation. The Reconguration Model can adapt a set of Recongurable
Models. This is done by executing the Reconguration Endpoints of their Re-
conguration Operations.
   The triggers serve as Guards for executing the High Level Reconguration
Operations. Whenever a trigger res the High Level Reconguration Operation
is executed and calls the Reconguration Operations it requires.
   The designer models the High Level Reconguration Operations to describe
complex joint recongurations of several models. The structural changes in each
model are accomplished by calling the Reconguration Operations, provided by
their Recongurable Model. This represents the global aspects of Model Recon-
guration. Inside this global description of reconguration logics she is able to
abstract from the properties mentioned in Section 2:
  Model Kinds: The Reconguration Model can work with any Recongurable
   Model regardless of its inner implementation or purpose. Therefore, it is
   independent of the actual set of models used at runtime.
  Modeling Language: The structure that is recongured is hidden within the
   Structure S of a Recongurable Model. The Reconguration Model only
   triggers the Reconguration Operations for changing this structure and does
   not touch the structure directly. Thus, the Reconguration Model can work
   independent of the Modeling Language.
  Reconguration Technique: The Reconguration Model only needs a refer-
   ence to the Reconguration Operations in order to execute them. It does
   not have to know how they are implemented. Thus, it can work indepen-
   dent of the reconguration technique used to describe the Reconguration
   Operations.


              Fig. 5. Running Example: The Reconguration Model


   A Reconguration Model for our running example is depicted in Figure 5.
This Reconguration Model uses the Recongurable Task Model and Recon-
gurable User Interface Model depicted in Figure 3. It contains one High Level
Reconguration Operation, which consists of two steps. In the rst step the Task
Model is recongured, using Reconguration Operation A. In the second step
Reconguration Operation B of the Recongurable User Interface Model is trig-
gered. This High Level Reconguration Operation executes all changes discussed
in our running example.
   The purpose of this publication is to propose the dierentiation between local
and global aspects of Model Reconguration and their separate handling by in-
troducing two levels of abstraction. The complete denition of both components
is still work in progress. Although a High Level Reconguration Operation is de-
picted as a series of consecutive steps in the running example, we do not believe
this to be the nal or best solution. Some hints on possible implementations are
given in the remainder of this section.
   There are several possible ways to implement a High Level Recongura-
tion Operation. For example, a visual language could be used for describing the
workow of application of the Reconguration Operations. Languages like UML
- Statecharts, Flowcharts or Petri Nets could be utilized for this task. Several
lessons can also be learned from the eld of Graph Transformation, where several
means for high level transformation logic are proposed. Imperative programming
languages, like Java or C++, could also be utilized.
   Before deciding on one of these alternatives a detailed analysis of the prop-
erties and control structures, required for a comfortable modeling of high level
recongurations has to be carried out. In the next section, related work in the
eld of Model Reconguration is discussed. This work is then related to the local
and global aspects of model reconguration and the concepts introduced in this
paper.


5 Related Work
Several approaches towards Model Reconguration have been implemented. This
section serves to introduce some of these approaches and interrelate them to the
local and global aspects identied in this paper and our notion of Recongurable
Model and Reconguration Model.
   One of the most recognized techniques for reconguring models is Graph
Transformation. A Graph Transformation rule searches and substitutes one oc-
currence of a pattern within a graph with another one. The concrete syntax of
several modeling languages can be described as a graph. For this reason a vari-
ation of a Graph Transformation technique is an obvious choice for structural
adaptations in these languages. A variety of applications for Graph Transfor-
mations to dynamic systems can be found in [6]. Although neither of these ap-
plications is specially applied to the reconguration of models at runtime, they
all contain an initial structure that is recongured using graph transformation
rules. This is very similar to our notion of a Recongurable Model.
   Several specic Graph Transformation languages do exist. These languages
are dedicated to a certain modeling language and can only be applied to models
within this language. For example, in [5] a Graph Transformation approach for
rewriting P/T nets is introduced. This technique preserves the ring behavior of
P/T nets. This shows the capability of specic Graph Transformation languages
to preserve properties of the transformed models and their structure. A spe-
cic Graph Transformation Language can be a good choice of a reconguration
technique to describe Reconguration Operations.
   In [7] this specic Graph Transformation language for P/T nets is applied to
model a exible emergency scenario. In this publication, the initial scenario is
modeled using a P/T net and the possible changes to this scenario are modeled
as a set of Graph Transformation rules, specic for P/T nets. This setup is very
similar to our notion of a Recongurable Model. The P/T net can serve as the
current Structure   S and the set of Graph Transformation rules are similar to
our Reconguration Operations    OPs.
   In [8], Schürr studies approaches towards building programmed graph re-
placement systems from Graph Transformation rules. He also proposes his own
approach towards unifying these approaches. The purpose of programmed graph
replacement systems is to provide means for dening complex schemes of recon-
guration out of Graph Transformation rules and thus enable the designer to
take a global view on Graph Transformation. However, an abstraction from the
concrete reconguration technique or modeling language was out of scope for
Schürr. For this reason programmed graph replacement systems do not make
these abstractions. Nevertheless, we consider this publication to be a valuable
source of inspiration for the design and implementation of High Level Recong-
uration Operations.

   USIXML [9] uses Graph Transformation techniques in a more general scope.
In this framework all models are described in XML. This format is used as the
basis for Graph Transformation. This enables a transformation between dier-
ent models, used for backward and forward engineering. The approach towards
Graph Transformation taken in USIXML is also an interesting one for Model
Reconguration as it enables the designer to describe several models as one
joint XML le and then recongure them jointly. This approach captures cer-
tain global aspects. However, it can only be applied to models that are described
within an XML structure. Thus, it is not general enough to satisfy our require-
ments from Section 2.

   Graph Transformation is not the only concept that has been tested within
the scope of Model Reconguration. In [10] Morin et Al. describe their approach
towards modeling adaptive systems using models and aspects. The system is
specied as a set of aspect models. They are weaved into one runtime model,
which represents the whole running application. The system is adapted by recon-
guring the aspect models and weaving a new runtime model. This newly woven
runtime model is then compared to the old one and a script for transforming
the old into the new one is generated. In this publication model reconguration
also clearly has local and global aspects. Recongurations are specied for each
aspect model but are then woven into one runtime model. Global consistency
can be checked by specifying a set of consistency constraints. However, this can
only serve to check consistency after the reconguration. In our opinion a way
for specifying how two aspects are recongured jointly in order to preserve their
consistency is still required.

   The meta modeling language KerMeta [11] can also proof as a useful tool for
Model Reconguration. The purpose of this language is to provide a language
that is able to model the structure and behavior of a modeling language. The
behavior is modeled by an action language. This way the designer of a modeling
language can model the structure and behavior of this language jointly. This ap-
proach can also proof interesting for model reconguration as structural changes
of such models can also be described by this action language. The KerMeta
action language can be used as a technique for implementing Reconguration
Operations.
   In this section we introduced a selection of approaches towards runtime re-
conguration of models. None of these approaches were explicitly able to model
all local and global aspects of Model Reconguration. However, several similar-
ities between these approaches and the components and separation introduced
in this paper have been found. This leads us to expect that the separation and
components we introduced, even given their current level of abstraction, capture
many of the aspects, also addressed by these publications and are a good starting
point for further research towards a universal Reconguration Model.


6 Conclusion and Future Work
This paper proposes a separation between a Recongurable Model, which is a
model that oers certain Reconguration Operations that can be executed at
runtime, and a Reconguration Model, which is responsible for triggering and
steering the recongurations in all models used at runtime. The aim of this sep-
aration is to provide an approach to Model Reconguration that captures local
and global aspects. Local aspects are strongly interwoven with the used mod-
els and modeling languages. Global aspects concern the interrelation of several
models and their joint recongurations.
   The Recongurable Model reects local aspects of Model Recongurations
and enables the designer to model Reconguration Operations that are close
to the used modeling languages. In the Reconguration Model the designer can
take a global view on Model Reconguration and interrelate the recongurations
of dierent models.
   Several existing approaches have been analyzed regarding their capability to
capture the global and local aspects of Modeling Reconguration. Although none
of the analyzed approaches had the exibility to deal with all our requirements,
they had several similarities to our approach.
   In the near future the notions of Recongurable Model and Reconguration
Model have to be further detailed. For example, the current denition provides no
means for expressing additional application conditions for Reconguration Op-
erations. For this step several sources of inspiration have been identied within
the related work.
   In Future Work we also plan to dene a specic language for describing Re-
conguration Models. In Section 4 some ideas on how the components within
this Reconguration Model can be implemented are given. These sources of in-
spiration have to be analyzed for their actual usability before a decision towards
the nal implementation can be made. In addition to a language for express-
ing such high level reconguration operations, a set of control structures, like
conditional or repeated application of rules has to be dened and formalized.
   Additionally, we plan on dening and executing a case study with the dened
reconguration language as a proof of concept.
References
 1. Coutaz, J.: User interface plasticity: Model driven engineering to the limit! In:
    ACM, Engineering Interactive Computing Systems (EICS 2010) International Con-
    ference. Keynote paper., ACM publ. (2010) 18 Keynote paper.
 2. Blair, G., Bencomo, N., France, R.B.: Models@ run.time. Computer 42(10) (2009)
    2227
 3. Schmidt, D.C.: Model-driven engineering. IEEE Computer 39(2) (2006)
 4. Calvary, G., Coutaz, J., Thevenin, D.: A unifying reference framework for the
    development of plastic user interfaces, Springer-Verlag (2001) 173192
 5. Ehrig, H., Habel, A., Kreowski, H.J., Parisi-Presicce, F.: Parallelism and concur-
    rency in high-level replacement systems. Math. Struct. in Comp. Science 1 (1991)
    361404
 6. Blostein, D., Schürr, A.: Computing with graphs and graph rewriting. Technical
    report, FACHGRUPPE INFORMATIK, RWTH (1997)
 7. Homann, K., Ehrig, H., Padberg, J.: Flexible modeling of emergency scenarios
    using recongurable systems. In: Proc. of the 10th World Conference on Integrated
    Design & Process Technology. (2007) 15 CDROM.
 8. lim: Programmed graph replacement systems. In: In Rozenberg, G. (Ed.), Hand-
    book on Graph Grammars: Foundations, World Scientic (1997) 479546
 9. Limbourg, Q.: Multi-Path Development of User Interfaces. PhD thesis, Université
    Catholique de Louvain, Institut d'Administration et de Gestion (IAG), Louvain-
    la-Neuve, Belgium (2004)
10. Morin, B., Barais, O., Nain, G., Jezequel, J.M.: Taming dynamically adaptive sys-
    tems using models and aspects. In: ICSE '09: Proceedings of the 31st International
    Conference on Software Engineering, Washington, DC, USA, IEEE Computer So-
    ciety (2009) 122132
11. alain Muller, P., Fleurey, F., marc Jézéquel, J.: Weaving executability into object-
    oriented meta-languages. In: in: International Conference on Model Driven En-
    gineering Languages and Systems (MoDELS), LNCS 3713 (2005, Springer (2005)
    264278

</pre>