=Paper=
{{Paper
|id=Vol-2060/mekes4
|storemode=property
|title=Shepherding Model Evolution in Model-Driven Development
|pdfUrl=https://ceur-ws.org/Vol-2060/mekes4.pdf
|volume=Vol-2060
|authors=Arvid Butting,Steffen Hillemacher,Bernhard Rumpe,David Schmalzing,Andreas Wortmann
|dblpUrl=https://dblp.org/rec/conf/modellierung/ButtingHRSW18
}}
==Shepherding Model Evolution in Model-Driven Development==
https://ceur-ws.org/Vol-2060/mekes4.pdf
Ina Schaefer,Ina
Loek Cleophas,
Schaefer, LoekMichael Felderer
Cleophas, (Eds.):
Michael Workshops
Felderer at Modellierung
(Hrsg.): Modellierung 2018,
2018,
ModellierungLecture
in der Entwicklung von kollaborativen
Notes in Informatics eingebetteten
(LNI), Gesellschaft Systemen (MEKES)
für Informatik, Bonn 2018 67
1
Shepherding Model Evolution in Model-Driven Development
Arvid Butting,1 Steffen Hillemacher,1 Bernhard Rumpe,1
David Schmalzing,1 Andreas Wortmann1
Abstract: Model-driven development (MDD) for cyber-physical systems leverages sophisticated tool
chains to translate models into programming language artifacts. As minuscule model changes can
entail severe changes to generated artifacts and their integration with handcrafted artifacts, evolving
models can produce unforeseen challenges. Reporting outdated handcrafted artifacts, generated arti-
facts with missing handcrafted artifacts, and modified artifacts, supports developers in comprehending
the effect of model changes and can guide evolving related programming language artifacts. Current
work on artifact modeling in MDD processes supports modeling of relations between artifacts only,
which prevents expressing that artifacts are generated from model parts contained by artifacts. We
present an artifact model that supports this granularity. Based on such an artifact model and artifact
data extractors we present a method to determine the impact of model evolution on generated and
handcrafted code. This method is realized with the MontiCore language workbench and enables
developers to identify the effect of model changes. Ultimately, it facilitates model evolution in MDD
for cyber-physical systems.
Keywords: Model-Driven Development; Impact Analysis; Artifact Model
1 Introduction
Applying model-driven development during the development of heterogeneous cyber-
physical systems (CPS), e. g. as part of collaborative systems, is one possibility to control
and manage the complexity of such systems. Model-driven development (MDD) [Völ+13]
lifts models to primary development artifacts. These models can be more abstract, better
comprehensible, and better suitable to automated processing than general-purpose program-
ming language (GPL) artifacts. To create software from models, these usually are translated
using model-to-model or model-to-text transformations. In both cases, MDD tool chains
can translate one model to an arbitrary number of artifacts of different kinds (e. g. GPL
artifacts, documentation, configurations).
Where the intended system interacts with GPL software, such as drivers for sensors or actu-
ators of cyber-physical systems, the abstraction of models usually requires bridging the gap
between system specification and system implementation [FR07] manually by integrating
1 Software Engineering, RWTH Aachen University, Aachen, Germany. @se-rwth.de
This research has partly received funding from the German Federal Ministry for Education and Research under
grant no. 01IS16043P. The responsibility for the content of this publication is with the authors.
cba
68 Arvid Butting, Steffen Hillemacher, Bernhard Rumpe, David Schmalzing, Andreas
Wortmann
handcrafted GPL artifacts with GPL artifacts generated from the models [Gre+15]. Evolv-
ing models can invalidate the relations between handcrafted and generated artifacts, e. g.
handcrafted artifacts may reference missing formerly generated artifacts derived from model
parts that have been removed during evolution or vice verse. Consequently, model evolution
can produce comprehensive target system evolution efforts and gaining an overview of its
effects can be complicated.
We propose to support developers in model evolution by automatically providing reports of
artifacts relevant to evolution with respect to the specific MDD tool chain. To this end, we
propose a method that shepherds model evolution through reporting impacted generated
and handcrafted artifacts to the developer, hence reducing the effort of comprehending
the evolution effects. To achieve this, we (1) explicate the relations between various kinds
of artifacts of an MDD tool chain through an artifact model; (2) derive instances of this
model from the file system automatically; and (3) compare these for code generated from
models before and after evolution to derive impacted artifacts. This paper consequently
contributes a method to prepare MDD tool chains and derive sets of affected artifacts
based on which the developers can comprehend required changes to the generated system
more efficiently. This method is realized with the MontiCore language workbench and
illustrated through evolution of a MontiArc software architecture model. To this end, Sec. 2
describes preliminaries, before Sec. 3 exemplifies the benefits of the presented method.
Sec. 4 introduces the method and illustrates its application. Sec. 5 discusses it and debates
related work. Sec. 6 concludes.
2 Preliminaries
Our method to explicate artifact relations in MDD processes relies on the artifact
model [But+17] and is realized with the MontiCore language workbench [Hab+15; KRV10].
Throughout the paper we use models of the MontiArc [HRR12; Rin+15] to illustrates its
application. This section introduces all three.
2.1 The Artifact Model
Our method to explicate artifact relations in MDD processes relies on the artifact
model [But+17] and is realized with the MontiCore language workbench [Hab+15; KRV10].
Throughout the paper we use models of MontiArc [HRR12; Rin+15] to illustrates its appli-
cation. This section introduces all three.
Typical MDD projects require a multitude of different artifacts that address the different
domains’ concerns and conform to different languages. Managing the complexity of these
projects requires understanding the relations between artifacts, which entails understanding
the relations between their languages as well as between the tools producing and processing
Shepherding Model Evolution in Model-Driven Development 69
specific artifact kinds AM instances of the artifact ArD
with their relations kinds in the file system
*
Artifact * a:ArcModelFile
refersTo
refersTo refersTo
ArcModelFile JavaSourceFile c:ArcModelFile j:JavaSourceFile
Fig. 1: Exemplary artifact model (left) with corresponding artifact data (right).
such artifacts. To this end, reifying this information as a first-level modeling concern in
form of an explicit artifact model (AM) [But+17] helps to cope with its complexity. Such
an AM precisely specifies the kinds of artifacts, tools, languages, and relations involved in
an MDD project and thus represents the project in a structured and machine processable
way. An AM describes all different situations in terms of present artifacts and relations
that could arise during their lifetime. The current situation of the project can be inspected
by automatically extracting artifact data (ArD) from the project conforming to the artifact
models’ entities and relations. This is displayed in Fig. 1 by example. The left side displays
an excerpt of an AM realized as a class diagram. In the example AM an artifact can be a
model file or a Java source file. Moreover, the association models that artifacts can refer
to each other. The object diagram on the right side depicts the data corresponding to the
artifact model ontologically, i. e. it represents an instance of the AM at a specific point in
time. In this case, the model file a refers to another model file c as well as the Java source
file j.
2.2 The MontiCore Language Workbench
MontiCore [Hab+15; KRV10] is a language workbench for the development of external,
textual domain-specific languages (DSLs). A MontiCore grammar, which is a context-free
grammar in an extended EBNF shape, describes the syntax of a DSL. From this, MontiCore
generates language-processing infrastructure such as an abstract syntax data structure and a
parser. For the definition of restrictions not expressible with context-free grammars, e. g.
uniqueness of names, MontiCore supports to restrict the syntax of a language by adding
well-formedness rules in form of Java context condition classes. Parsed models can be
translated into target language artifacts by an employed template-based code generation
engine based on FreeMarker2. The workflow of processing a model can be configured using
Groovy scripts. Typically, the workflow starts with parsing the model to obtain an instance
of the abstract syntax data structure, the abstract syntax tree (AST). Afterwards, the abstract
syntax can be minimized to include only the language’s essential structure. Further, context
2 The FreeMarker Website: https://freemarker.apache.org/
70 Arvid Butting, Steffen Hillemacher, Bernhard Rumpe, David Schmalzing, Andreas
Wortmann
composed atomic component typed, unidirectional
component with automaton connector
BumperBot MA
BumperControl MotorCmd Motor
controller left
left cmd
Idle Drive
TouchSensor Motor
Contact Turn Back MotorCmd
ts c c right
right cmd
component outgoing incoming component
type name port c port cmd instance name
Fig. 2: Exemplary MontiArc software architecture of a CPS BumperBot.
condition are checked by a generated visitor infrastructure for the AST. The last step is to
translate the parsed model into target language artifacts.
2.3 The MontiArc Architecture Description Language
MontiArc [HRR12; Rin+15] is a component & connector architecture description language
(C&C ADL) realized with MontiCore. MontiArc enables describing component models
with typed, directed communication interfaces (ports) and connectors connecting pairs of
components via their ports. The data types sent and received via ports are defined in a
class diagram model. The communication between components is realized as message ex-
change following semantics based of the FOCUS formalism [BS01]. MontiArc components
may be hierarchically structured via introducing interconnected component instances as
subcomponents. Components without subcomponents (atomic components) specify their
behavior with embedded behavior models, such as automata. To this effect, MontiArc has
an extension mechanism to include new behavior languages. MontiArc includes a code
generator to translate the models into executable source code that can be deployed, e. g. to
cyber-physical systems.
An exemplary MontiArc component model is depicted in Fig. 2. It models a robot that
drives forward until it touches a wall, then drives backwards for a short period of time,
turns around and proceeds to drive forward. The component BumperBot includes four
subcomponent instances - each one of the types TouchSensor and BumperControl
and two of type Motor. The component of type TouchSensor, e. g. contains a single
outgoing port c of type Contact. The component behavior of the controller is defined
by an embedded automaton. This automaton contains four states and four transitions. The
Shepherding Model Evolution in Model-Driven Development 71
subcomponent of improved component type
BumperBot MA
UltraSonic BumperControl MotorCmd Motor
us d controller left
left cmd
Idle Drive
Distance
Distance Ad- Motor
Contact MotorCmd
d Adapter c c just right
da right cmd
new adapter between us.d and controller.c
Fig. 3: Updated version of the BumperBot depicted in Fig. 2.
transition conditions are formulated against valuations of incoming ports and transition
actions trigger messages on outgoing ports. From each component, the MontiArc Java code
generator produces a Java class implementing the interface of the component (its name and
ports), another Java class for the behavior (e. g. defined by an automaton model), a class
capturing the input port valuations of a component and a class capturing the output port
valuations. These classes interact with a run-time environment that realizes the message
passing semantics and with classes generated from type definition class diagrams. The
behavior of atomic components that do not contain a behavior model can be specified
via handcrafted implementations. To this effect, MontiArc leverages the generation gap
pattern [Gre+15] to integrate such handcrafted artifacts with generated code.
3 Example
Models and handcrafted artifacts of MDD projects evolve over time, which may be due to
changing requirements, ongoing refinement, or refactoring. These artifacts are related to
each other in different ways: for instance, artifacts can reference other artifacts (e. g. im-
porting), artifacts can be created from other artifacts (e. g. code generation), or handcrafted
artifacts impose requirements on other artifacts (e. g. tests for generated artifacts). All of
these may change during model evolution.
Consider the evolution of the BumperBot architecture model depicted in Fig. 3, which
has been changed as follows: (1) Due to a change in requirements, the system shall no
longer recognize walls by contact, but instead detect walls via an ultrasonic sensor. To
meet this new requirement, the subcomponent TouchSensor is exchanged with a new
component UltraSonic. As the ultrasonic sensor outputs an Integer distance value
and the BumperControl component expects a Boolean value indicating a contact, an
additional component DistanceAdapter translates low distance values into a “contact”.
72 Arvid Butting, Steffen Hillemacher, Bernhard Rumpe, David Schmalzing, Andreas
Wortmann
(2) The behavior automaton of the component BumperControl is modified by merging
the states Back and Turn into the state Adjust. How these changes impact the effort
of adjusting the handcrafted artifacts after evolution cannot be estimated with little effort
as both model changes affect the generated artifacts, and hence, also to handcrafted code
that interacts with the modified generated artifacts. For instance, artifacts generated from
TouchSensor are not part of the project anymore, and therefore related tests are obsolete;
the new components may not be tested at all and require additional efforts investigation; and
the behavior automaton has changed, which might impact other artifacts as well. Making
the artifact relations of a MDD tool chain explicit can support developers in understanding
which artifacts are (potentially) affected by the model evolution and hence shepherd the
evolution efforts.
4 Estimating Model Evolution Impact
This section presents our method to identify artifacts potentially affected by modifications
of model artifacts and the preparation of an MDD tool chain for the collection of artifact
data.
4.1 Reifying the Model-Driven Tool Chain
To apply our method in a concrete project, some preparing activities are necessary. These
activities are depicted in Fig. 4 by an activity diagram. First, the artifact types and possible
relations have to be identified. Artifact types can be distinguished based on file types, but fur-
ther distinction based on project related purposes, e. g. separation into test and functionality
implementation artifacts, is also conceivable. Relations can be different kinds of depen-
dencies between generated or handcrafted source code artifacts, relations between model
elements, or mappings between model elements and generated artifacts they contribute to.
Sophisticated project knowledge helps to identify a project’s relevant artifact types and
relations. Once these are identified, the artifact model can be created. Afterwards, the arti-
fact data extractors need to be developed. Extractors investigate the current state of project
artifacts and create instances of artifact model types to produce artifact data conforming to
the artifact model. They can be realized as data loggers capturing dynamic relations during
the generation process, e. g. relations between model elements and generated artifacts they
contribute to, or analyze the file system to gather static dependencies between artifacts. A
part of the artifact model used in our running example is depicted in Fig. 5. Each MontiArc
model is stored in its own artifact called ArcModelFile and consists of a number of
MontiArc model elements. A MontiArc model element is described through its own artifact
ArcElement and can be, among others, a component or automaton, which are represented
in the artifact model by the artifacts Component and FSMachine, respectively. Java
source files that are generated from the MontiArc tool chain can be represented in the
artifact model by artifacts of type JavaSourceFile. A model element can contribute
Shepherding Model Evolution in Model-Driven Development 73
act Preparation AD
Identify Create Implement
artifact artifact ArD
relations model extractors
Fig. 4: Preparing activities to utilize an artifact model for impact analysis.
AM
ArcModelFile
contains
*
* /contributesTo * *
ArcElement JavaSourceFile
1
/behavior /tests
contains *
Component FSMachine Test
0..1 1
Fig. 5: Part of the artifact model used in our example.
to a number of Java source files and multiple model elements can contribute to the same
Java source file. Java source files that test other Java source files are represented in the
artifact model by the artifact Test. A test can test other Java source files while a Java
source file can be tested by multiple test artifacts, which is indicated by the relation tests.
In order to precisely define the derived associations contributesTo, behavior and
test, we use the OCL/P [Rum11]. Based on the desired level of detail, the artifact type
JavaSourceFile can be further divided into component, component input, component
result, and component implementation artifacts. The first three are generated for each
component, the latter has to be handcrafted if an atomic component does not contain an
automaton.
4.2 Guiding Model Evolution
Once an artifact model and the required extractors have been created for an MDD project,
they can be utilized to estimate the impact of changes in the project. The process we propose
to identify differences between two versions of an MDD project is depicted in Fig. 6 by two
activity diagrams, artifact differencing and model differencing. The result of the activities
depicted in both diagrams are lists of artifacts that have to be considered by a developer
when evolving the MDD project to its new version. These lists include generated artifacts
that may exhibit new behavior, handcrafted artifacts that reference outdated generated
artifacts, and new generated artifacts for which tests, documentation, or other handcrafted
artifacts need to be developed.
The starting point of artifact differencing is some version t of the MDD project to be
further developed, including all generated and handcrafted artifacts. Utilizing the previously
74 Arvid Butting, Steffen Hillemacher, Bernhard Rumpe, David Schmalzing, Andreas
Wortmann
act Artifacts Differencing AD
Develop Develop Compare Produce
Extract Extract
MDD Project MDD Project ArD lists of
ArD of t ArD of t’
Version t Version t’ of t and t’ differences
act Model Differencing AD
Compare Identify Identify Produce
AS of t and changed AS related list modified
t’ models elements artifacts aritfacts
Fig. 6: Activities involved in investigating the impact of changes.
implemented extractors, the current state of the artifacts under investigation has to be
captured, in form of artifact data conforming to the used artifact model. This activity is
usually automated. Once the artifact data has been extracted, the evolution to the next
version t’ can be initialized by adapting models, e. g. to new requirements and speci-
fications, and by re-executing the generator for the modified models. The result of this
step is an artifact landscape, again including models and generated artifacts according
to the new version of the project, and (potentially outdated) handcrafted code artifacts.
Utilizing the implemented extractors the artifact data of t’ is extracted. The artifact data
of the two versions can then be compared to identify differences between the two artifact
landscapes. From this comparison we can identify (1) new artifacts for which handcrafted
artifacts, such as functionality implementation code, tests, or documentation, do not yet
exist, (2) handcrafted artifacts that reference generated artifacts no longer available, and
(3) handcrafted code that interacts with generated code that differs in both versions. For
model differencing we compare the abstract syntax (AS) of the models of the two project
versions to identify model elements that have been modified, added, or deleted. Using the
extracted artifact data we can identify related generated artifacts those model elements con-
tribute to. As a result we obtain a list of generated artifacts that may have changed through
modifications in the respective model. Handcrafted artifacts that reference these generated
artifacts need to be reviewed by a developer and may need to be adapted to changes in the
generated artifacts. Applying the presented processes to our example we can identify those
artifacts that need be considered when evolving the BumperBot to its new version. By
comparing the artifact data of the two versions, we can identify that the generated Java
classes for the TouchSensor are missing in the new version and that an handcrafted
artifact TouchSensorImpl previously referenced one of these artifacts. Further, we can
identify that tests and documentation artifacts refer to this implementation artifact. We
can therefore conclude that these artifacts are outdated and need to be modified or deleted.
Comparing the artifact data of the two versions, we can also identify that new component
artifacts for UltraSonic and DistanceAdapter were added to the project. Based
on our project knowledge and the artifact model we can identify those artifacts, besides
test and documentation, that should possibly be developed for these components, such as
Shepherding Model Evolution in Model-Driven Development 75
component implementation artifacts. Through the activities of model differencing, we can
identify that the automaton of the component BumperControl has been modified. Since
this model element contributes to the BumperControlImpl artifact, we can conclude
that the behavior of this artifact may have changed and therefore artifacts with relations to
the BumperControlImpl need to be reviewed and possibly modified.
5 Discussion and Related Work
In MDD projects, proper model management is crucial when working with large collec-
tions of models – even more, if impact analysis is performed on these. To improve the
model management, [BJV04] introduces the notion of megamodels. Megamodels are still
subject to ongoing research [Sal+16; Sim+15]. Under the assumption that everything is
a model [Béz05], the notion of artifact models as proposed in this work is a megamodel,
too. However, there is a difference between megamodels and the proposed artifact model,
or artifact models in general, from our viewpoint. Most importantly, we require formal
encoding of models and their relations. Moreover, the elements of megamodels represent
models and the links represent relationships between models [Sal+16]. Using an AM, the
focus is on the model-driven build process including a white-box view of the MDD tools,
such as a code generator. As a consequence, using an AM allows for a detailed modeling of
the insides of an artifact and its relationships based in these. In general, the quality of the
proposed approach relies on the level of detail of the artifact model. The finer-grained the
change can be analyzed, the more precise is the measurement of its impact. For example,
if the artifact model of a MontiArc tool chain does not distinguish between generated
classes that contain the input, the output, the behavior, or the structure of a component, the
estimated effect of a change in a component model may not distinguish between those as
well. Our approach considers syntactic changes in models only. Currently, syntactic changes
that do not modify the behavior, e. g. through refactoring, are not distinguished between
modifications that affect the behavior. Semantic differencing can be used to investigate this
further.
6 Conclusion
We presented a method to facilitate shepherding model evolution for sophisticated MDD
tool chains, such as in the development of CPS. This method relies on making the artifact
kinds and their relations of a given MDD tool chain explicit as its artifact model. Based on
this, the state of artifacts can be extracted from the file system and is accessible for analyses,
such as identifying changed artifacts, missing handcrafted artifacts for generated artifacts,
and vice verse. Automating this identification of artifacts potentially relevant to evolution
supports developers in estimating the impact of evolution and guides their adjusting efforts,
which ultimately facilities model evolution.
76 Arvid Butting, Steffen Hillemacher, Bernhard Rumpe, David Schmalzing, Andreas
Wortmann
References
[Béz05] Jean Bézivin. “On the Unification Power of Models”. In: Software and Systems
Modeling 4.2 (2005), pp. 171–188.
[BJV04] Jean Bézivin, Frédéric Jouault, and Patrick Valduriez. “On the Need for Meg-
amodels”. In: Proceedings of the OOPSLA/GPCE: Best Practices for Model-
Driven Software Development workshop, 19th Annual ACM Conference on
Object-Oriented Programming, Systems, Languages, and Applications. 2004.
[BS01] Manfred Broy and Ketil Stølen. Specification and Development of Interac-
tive Systems. Focus on Streams, Interfaces and Refinement. Springer Verlag
Heidelberg, 2001.
[But+17] Arvid Butting et al. “Taming the Complexity of Model-Driven Systems En-
gineering Projects”. In: Grand Challenges in Modeling 2017 (GRAND’17).
2017.
[FR07] Robert France and Bernhard Rumpe. “Model-Driven Development of Complex
Software: A Research Roadmap”. In: Future of Software Engineering 2007 at
ICSE. 2007.
[Gre+15] Timo Greifenberg et al. “Integration of Handwritten and Generated Object-
Oriented Code”. In: Model-Driven Engineering and Software Development
Conference (MODELSWARD’15). Vol. 580. CCIS. Springer, 2015, pp. 112–
132.
[Hab+15] Arne Haber et al. “Composition of Heterogeneous Modeling Languages”. In:
Model-Driven Engineering and Software Development Conference (MODEL-
SWARD’15). Vol. 580. CCIS. Springer, 2015, pp. 45–66.
[HRR12] Arne Haber, Jan Oliver Ringert, and Bernard Rumpe. MontiArc - Architectural
Modeling of Interactive Distributed and Cyber-Physical Systems. Tech. rep.
RWTH Aachen, 2012.
[KRV10] Holger Krahn, Bernhard Rumpe, and Steven Völkel. “MontiCore: a Framework
for Compositional Development of Domain Specific Languages”. In: Inter-
national Journal on Software Tools for Technology Transfer (STTT). Vol. 12.
2010, pp. 353–372.
[Rin+15] Jan Oliver Ringert et al. “Language and Code Generator Composition for
Model-Driven Engineering of Robotics Component & Connector Systems”. In:
Journal of Software Engineering for Robotics (JOSER) 6.1 (2015), pp. 33–57.
[Rum11] Bernhard Rumpe. Modellierung mit UML. 2nd. Xpert.press. Springer Berlin,
Sept. 2011.
[Sal+16] Rick Salay et al. “Heterogeneous Megamodel Slicing for Model Evolution”.
In: ME@ MODELS. 2016, pp. 50–59.
Shepherding Model Evolution in Model-Driven Development 77
[Sim+15] Jocelyn Simmonds et al. “A megamodel for Software Process Line model-
ing and evolution”. In: Model Driven Engineering Languages and Systems
(MODELS), 2015 ACM/IEEE 18th International Conference on. IEEE. 2015,
pp. 406–415.
[Völ+13] Markus Völter et al. Model-Driven Software Development: Technology, En-
gineering, Management. Wiley Software Patterns Series. Wiley, 2013. isbn:
9781118725764.