=Paper=
{{Paper
|id=Vol-1463/paper3
|storemode=property
|title=Generating Domain-Specific Transformation Languages for Component & Connector Architecture Descriptions
|pdfUrl=https://ceur-ws.org/Vol-1463/paper3.pdf
|volume=Vol-1463
|dblpUrl=https://dblp.org/rec/conf/models/HermerschmidtHR15
}}
==Generating Domain-Specific Transformation Languages for Component & Connector Architecture Descriptions==
https://ceur-ws.org/Vol-1463/paper3.pdf
Generating Domain-Specific Transformation
Languages for Component & Connector
Architecture Descriptions
Lars Hermerschmidt, Katrin Hölldobler, Bernhard Rumpe, and Andreas Wortmann
Software Engineering, RWTH Aachen University, http://www.se-rwth.de/
Abstract—Component-based software engineering (CBSE) ii) refactoring: find architectural anti patterns and replace
decomposes complex systems into reusable components. these with established solutions. iii) refinement: replace
Model-driven engineering (MDE) aims to abstract from platform-independent with platform-specific components.
complexities by lifting abstract models to primary development
artifacts. Component and connector architecture description Describing transformations either requires handcrafting
languages (ADLs) combine CBSE and MDE to describe code to transform a model based on its representation,
software systems as hierarchies of component models. Using such as an abstract syntax tree (AST), in a general
models as development artifacts is accompanied with the purpose programming language or modeling with a generic
need to evolve, maintain and refactor those models, which
transformation language such as ATL [3]. The former is
can be achieved by model transformations. Domain-specific
transformation languages (DSTLs) are tailored to a specific tedious and error prone. The latter requires learning a new
modeling language as the modeling language’s concrete syntax is language, which might provide adequate transformation
used to describe transformations. To automate the development descriptions, but cannot rely on the original DSL’s notations.
of DSTLs for ADLs, we present a framework to systematically Domain-specific transformation languages (DSTLs) also
derive such languages from domain-specific C&C language
grammars. These DSTLs enable to describe such model called “transformations in concrete syntax” [4]–[7] reduce
transformations concisely in vocabulary of the underlying ADL. the effort of learning a transformation language as they
These domain-specific transformations are better comprehensible employ the familiar DSL’s syntax. In addition they allow
to ADL experts than generic transformations. a more concise definition of transformations as the AST
is not involved. Producing such DSTLs however requires
I. M OTIVATION AND P ROBLEM S TATEMENT the same effort as developing a DSL. To approach this,
Engineering non-trivial software systems demands we have developed a framework to generate DSTLs from
techniques to reduce development effort. Component-based DSLs while retaining their vocabulary. With this framework,
software engineering (CBSE) aims to reduce complexity developers can efficiently describe model transformations in
by composing systems from reusable components. Ideally, well-known form and the overhead of learning additional
these components can be developed independently by domain modeling elements is minimized.
experts and reused off-the-shelf - increasing component In the following, Sect. II presents the language workbench
maturity along the way. Components of CBSE usually MontiCore on which our framework, and the ADLs we
are source code artifacts, which gives rise to “accidental generate DSTLs for, build. Afterwards, Sect. III describes
complexities” [1] (dealing with programming instead of the framework before Sect. IV illustrates the resulting DSTLs
domain issues). Model-driven engineering (MDE) aims to and their application. Sect. V presents related work. Finally,
abstract from these by lifting abstract models to primary Sect. VI discusses the approach and Sect. VII concludes.
development artifacts. Such models are typically formulated
in terms of a domain-specific language (DSL) that reduces II. P RELIMINARIES
noise and trades expressiveness for comprehensibility. In
addition, such models can be better reusable, analyzable, The DSTL generation framework relies on the language
and automatically transformable into executable systems. development and integration mechanisms of the language
Component and connector (C&C) architecture description workbench MontiCore [8]. With this, it parses the
languages (ADLs) [2] combine CBSE and MDE to model grammars of MontiCore DSLs and generates domain-specific
systems as hierarchies of components. transformation languages. MontiCore provides a language to
Using ADLs in MDE gives rise to needs for multiple describe the integrated concrete and abstract syntax of DSLs
types of model transformations, such as: i) preprocessing: in terms of context-free grammars and means to generate
translate ADL keywords into equivalent component structures model processing infrastructure, such as tools to parse textual
or flatten the component hierarchy prior to code generation, models into an abstract syntax tree (AST), frameworks for
rearrange the subcomponent hierarchy for deployment. language integration and well-formedness checking [9], as
well as code generation [10]. Language integration enables
K. Hölldobler is supported by the DFG GK/1298 AlgoSyn. aggregation, inheritance, and embedding between DSLs. For
the latter, the host DSL provides extension points filled by «provided»
modeling elements of the embedded DSL. DSL parses DSTL-
creates
We apply our approach to MontiArc [11], a C&C «gen»
Grammar Gen
ADL build with MonitCore and its extension MontiSecArc. TM2J-Gen
Both describe logically distributed software architectures «gen» «provided»
creates
as hierarchies of connected components. Components are OD-Gen OD2J-Gen
black-boxes with interfaces of typed, directed ports. The «gen»
«provided»
behavior of atomic components is defined by source code DSTL
artifacts and the behavior of composed components emerges Grammar CF2J-Gen
from their subcomponents. MontiSecArc introduces the trust
level to distinguish components that might be influenced by Fig. 1. Overview of the generation of a DSTL including provided and
an adversary from those which are not that easy to reach. generated generators.
qAs modeling something unknown like an adversary is hard,
the trust level describes (physical) protection measures which A. From DSL to DSTL
hinder an adversary to compromise a component. The trust The automatic derivation of DSTL is solely based on
level abstracts from individual measures like locked doors, the grammar of the DSL. Thus, by taking the modeling
fences, and video surveillance to focus the model on IT language’s grammar as input the DSTL generator produces
security. A subcomponent’s trust level is denoted relative to the grammar for describing transformation rules following the
its containing component and the surrounding of a system is derivation rules described in [14] and a generator (OD-Gen,
assumed as insecure and hence has the trust level −1. Fig. 1) to translate those transformation rules to a LHS and
A classical measure to hinder adversaries to access a a RHS of a transformation in form of object diagrams (OD
resource is access control, such as role based access control, notation). Furthermore, the framework provides a generator to
or access control lists (ACLs) [12], which is noted by the translate this OD notation to Java (OD2J-Gen), a control flow
keyword access in MontiSecArc. Access is limited to certain language to control the application of transformation rules and
policies, such as roles or ACLs, for specific incoming ports or a generator (CF2J-Gen) to translate the control flow to Java.
complete components, where the later is equivalent to access As complex transformations usually are decomposed
control for all incoming ports of the component. Assigning to transformation rules combined by some kind of
users to roles or ACLs is left to run-time, such that new users’ application strategy ([15]), the control flow language uses the
access rights are defined by the access policy. transformation rule language via language embedding to allow
To avoid naming problems with policies when composing the description of complex transformations in form of so called
components, policies of different components are independent, transformation modules (Sect. III-B4). Finally, to ease the use
even if they have the same name. When interconnecting of the generators (OD-, CF2J-, and OD2J-Gen) the DSTL
components, e.g., client and server as depicted in Fig. 4, where generator creates glue code that combines those generators to a
one role has access to different components an identity link single generator (TM2J-Gen) able to translate transformation
connects these components. When interconnecting identities, modules to executable Java transformations.
the process of authentication, where a user from a proving
component claims to have a role at the verifying component, B. Generated DSTLs
ensures that only users, which possess this role are able to A DSTL created by the generator described above reuses the
claim it. In Fig. 4 Client’ is the proving component and concrete syntax of the DSL to describe patterns. In addition,
Server’ the verifying one. To specify proving and verifying the DSTL provides a replacement operator for modifications,
component, the identity link is directed from the former to allows to bind elements to variables, and to specify negative
the latter. elements and application constraints. With this, the DSTL is
able to describe endogenous in-place transformations [15],
III. DSTL G ENERATION F RAMEWORK [16]. In contrast to the typical transformation form consisting
The DSTL generation framework is able to create DSTLs of LHS and RHS, we use an integrated notation of LHS and
that, in conjunction with additional generated and provided RHS. Combining these in a single model avoids repeating
parts of the framework, realizes a graph transformation unchanged model parts on the RHS. The transformation
approach. In such approaches, complex transformations are operators, such as the replacement operator or negative
composed of small transformation rules where transformation elements, are provided for every model element defined by
rules usually are described by a left-hand side (LHS) - the a nonterminal such as components and ports. The following
model part before applying the rule - and a right-hand side explains those operators.
(RHS) - the same model part after being transformed [13]. 1) Pattern and Schema Variables: The DSTL uses concrete
The following sections explain the framework to automatically DSL syntax to describe patterns, thus, a pattern resembles the
derive DSTLs from the grammar of a modeling language model part it describes and omits parts that do not constrain
as well as the resulting DSTL and the application of the pattern. For example, the model in Lst. 1 could also serve
domain-specific transformations. as a pattern. However, every component that has the depicted
structure and arbitrary additional structures, such as additional well as any static Java method. Listing 2 shows a negative
ports or subcomponents, would be a suitable match for this element (l. 9) and a where-block (l. 11). An example of
pattern. There also is no need to start a pattern at the top-level an application constraint is shown in line 14 of Lst. 3. A
element of a model. Instead, all elements can be top-level transformation will only be applied if all positive elements
elements in a pattern. For instance, if a transformation is are found, no match for the negative elements is possible and
defined for a port and the containing component is irrelevant, the application constraint holds.
the pattern may only define the port and its modification. 4) Transformation Modules: To control and combine the
In many cases transformations need to be more general, transformation rules to transformation modules, the generated
thus, for abstraction purposes as well as binding model DSTL is combined with a generic control flow language via
elements to variables (for instance to move them), the language embedding.
generated DSTL provides a concept called schema variables. A transformation module, as shown in Lst. 2, consists of
Those variables consist of a type, i.e., the name of the instructions and transformation methods (introduced by the
nonterminal that defines the model element and a name keyword transformation) where the body of a transformation
starting with a $-sign. There are black box and a white box method is a transformation rule. The instruction methods
schema variables: Black box variables end with a semicolon define the application order of transformation methods.
(“ElementT ype SchemaV ar ;”), while white box variables The instruction method main() is the starting point of
allow to define the element’s structure within double square a transformation module. Within instructions, Java syntax
brackets (“ElementT ype SchemaV ar [[ Element ]]”). An extended by a special loop statement can be used to specify
example black box variable is depicted in line 6 of Lst. 3 for the control flow in an imperative manner. The loop statement
an access definition. Line 9-12 of Lst. 3 show a white box applies the following transformation rule until no further
variable for a component. match for the pattern can be found.
To ease the use of variables for names the type Name can
be omitted. A schema variable for a name is displayed in C. Translation and Application of a Transformation
Lst. 2 ($name in l. 7, $sp in l. 8). If a schema variable is A transformation module is defined using the control flow
used for a model element the corresponding element is bound language and its embedded transformation rule language (
to this variable during pattern matching. Thus, using the same Fig. 2), which have to be translated to Java code for execution.
variable twice refers to the same model element in both cases. This translation is performed by the composed and generated
However, for names we relaxed this such that two occurrences generator TM2J-Gen (Fig. 1 and Fig. 2). TM2J-Gen takes
of a schema variable for a name require equality instead of a transformation module as input and internally uses its
identity. When using variables for abstraction, without the need three subgenerators to translate it to an executable Java
for referencing them later, the anonymous $_ variable may be transformation. The latter reads a model and applies the
employed. It does not bind the model element and, hence, two transformation described by the transformation module.
occurrences neither require identity nor equality (Lst. 2, l. 9).
2) Modifications: The generated DSTL uses an integrated «provided» «gen»
notation of the LHS and RHS of a transformation rule. To Transformation conforms Control Flow embeds DSTL
achieve this the DSTL provides the replacement operator :- Module Language Grammar
that acts on element level (“[[ Element? :- Element? ]]”). parses
«gen»
The element left of :- is replaced by the one right of it. If the DSL
LHS is left blank an element is created and added. Leaving the Grammar TM2J-Gen
RHS blank deletes an element. A modification is illustrated in conforms creates
line 6 of Lst. 2.
3) Negative Elements, Application Constraints and parses Java creates Transformed
Model Transformation
Assignments: Negative application conditions [17] are Model
provided in form of negative elements with the following
Fig. 2. Overview of the translation and application of a transformation.
syntax: not [[ Element ]]. A negative element is an
element that must not occur in the model. Furthermore, IV. A PPLYING THE T RANSFORMATION L ANGUAGE
a where-block is provided that allows formulating With the DSTL derived from the DSL’s grammar, the
application constraints and assignments of schema description of model transformations is greatly facilitated as
variables. The where-block is structured as follows: the transformation developers are familiar with the DSLTs
where { Assignment∗ BooleanExpression? } vocabulary. The following sections illustrate application of
It starts with the assignment of schema variables that are model transformations to MontiArc and MontiSecArc with the
not assigned during pattern matching (i.e., parts of the RHS DSTLs generated for each.
of a transformation). Within the BooleanExpression the
elements of the transformation bound to schema variables can A. Preprocessing: Adding Structural C&C Elements
be used to formulate the constraint. Thereby, the signature A common challenge for the development of distributed
of the abstract syntax of the model elements can be used as systems is dealing with the unforeseeable run-time issues.
composed transformed new state
subcomponent MA 1 module AddMonitoring {
component component ports MTF
2 main ( ) { l o o p a d d P o r t s ( ) ;
RemoteNode RemoteNode‘ 3 l o o p addMonitor ( ) ;
int Actuator int Actuator‘ 4 loop connect ( ) ; }
left left 5
el effort el effort 6 t r a n s f o r m a t i o n addPorts ( ) {
Remote
Actuator Node 7 component $name {
State RemoteNode 8 p o r t [ [ : - out $sp s t a t e ] ] ;
State
Monitor 9 not [ [ out $_ s t a t e ] ]
Actuator monitor 10 }
State
11 where { $sp = $name . c o n c a t ( " S t a t e " ) ; }
int Actuator int Actuator‘ 12 }
right right 13
er effort er effort
14 t r a n s f o r m a t i o n addMonitor ( ) {
incoming port effort new sub- new 15 component $name {
of type int component connectors 16 [ [ : - component $ t y p e mo nitor ; ] ]
17 not [ [ component $_ mo nitor ; ] ]
18 [ [ : - c o n n e c t mo nitor . s t a t e - > s t a t e ; ] ] ;
Fig. 3. Applying the monitoring transformation to a composed component 19 component $_ {}
RemoteNode with a single subcomponent. 20 }
21 where { $ t y p e = $name . c o n c a t ( " Monitor " ) }
1 component RemoteNode { MA 22 }
2 port in int el , in int er ; 23
3 component A c t u a t o r l e f t , r i g h t ; 24 transformation connect ( ) {
4 connect e l - > l e f t . e f f o r t ; 25 component $_ {
5 connect er - > r i g h t . e f f o r t ; 26 component $ t y p e $name ;
6 } 27 [ [ : - c o n n e c t $name . s t a t e - > m onitor . $sp ; ] ] ;
28 not [ [ c o n n e c t $name . s t a t e - > mon itor . $_ ; ] ]
Listing 1. Textual syntax of composed component RemoteNode with 29 }
subcomponent Actuator. 30 where { $sp = $name . c o n c a t ( " S t a t e " ) ; }
31 }
To this effect, MontiArc introduces component monitoring. 32 }
Every component of the architecture is monitored by a specific Listing 2. The transformations required to add a monitor, related ports,
monitor per composed component. Instead of handcrafting and connectors to a software architecture.
the monitoring infrastructure for each component, it is transformation. The main block (ll. 2-4) invokes the three
conveniently integrated via model transformations. These transformations addPorts(), addMonitor(), and connect(),
transformations introduce new subcomponents, ports, and where addPorts() (ll. 6-12) adds state ports to all components
connectors, such that all composed components and their direct of the software architecture. To this effect, it iterates over
subcomponents are observed by a new subcomponent. That all components (denoted by concrete MontiArc syntax
subcomponent receives status messages from its neighboring component followed by a name $name) and adds a new
subcomponents, calculates an overall component status, outgoing port state to each of the component’s ports rule
and emits this via a new outgoing port. Applying this (l. 8), where no such port already exists (l. 9). The port’s
transformation to a composed component RemoteNode type is defined by $sp as calculated by the where-block
(Fig. 3) requires that (a) RemoteNode and all its (l. 11). The transformation addMonitor() (ll. 14-22) adds
subcomponents receive a new port to emit status messages, a new subcomponent monitor (l. 16) to each composed
(b) RemoteNode receives a new subcomponent of type component - enforced by requiring that the component
RemoteNodeMonitor that provides appropriate input ports contains a subcomponent (l. 19) - that does not already
for all new state ports and emits messages on the contain a monitor (l. 17). The type of monitor is calculated
overall state of RemoteNode, and (c) the state ports via $type (l. 21). Finally, the transformation connect()
of the subcomponents of RemoteNode are connected to (ll. 24-31) adds new connectors to each composed component
RemoteNodeMonitor, which itself is connected to the new to connect its subcomponents to its new monitor. This is
state port of RemoteNode. better comprehensible than a lengthy program exploiting
As the DSTL’s syntax is derived from the DSL, Lst. 1 the AST API and less susceptible to errors arising from
describes the textual syntax of the untransformed MontiArc accidental complexities of AST programming.
component RemoteNode for comprehension. The keyword
component (l. 1), followed by a name and curly brackets B. Refactoring: Resolving Anti-Patterns
declares a component definition (ll. 1-6). The components Architects need to consider security as one out of many
interface is defined by the keyword port and a list of directed, nonfunctional requirements. There are numerous commonly
typed ports (l. 2). Furthermore, a composed component known anti-patterns and design flaws [18]. We consider the
contains a set of subcomponents (l. 3), each starting with anti-pattern of client-side authentication [19, p. 687], which
the keyword component, followed by its type and name. is depicted in Fig. 4 using the MontiSecArc language. In this
The ports of subcomponents are connected via unidirectional case a client with low trust level enforces access control and
connectors (ll. 4-5). a server which has a higher trust level relies on that client.
Handcrafting these transformations in terms of AST Hence, an attacker able to impersonate the client can bypass
API calls requires considerable effort. Instead, the access control and compromise the server, as it relies on the
three transformation rules given in Lst. 2 describe this client.
MSA
these examples, developers have to use abstract syntax. Term
Client TL: -1 Server TL: +2 rewriting [4] works on concrete syntax as well by applying
access: user
trust
level rewriting rules to manipulate rather small connected model
limit access parts as compared to graph transformations. T-Core [30]
to policy user
Client‘ TL: -1 Server‘ TL: +2 and others [31] introduce transformation primitives which,
access: user access: user
identity
similar to term rewriting, do not automate the process of
link deriving an DSTL but are combined and configured to create
it. Thus, they do not propose a systematic and automated
Fig. 4. Applying the transformation to an insecure client server setup way of deriving a DSTL, but provide building blocks to
introduces access control to the server to make it secure.
create them. Our previous work on delta languages, which
describes small changes for models in concrete syntax of the
1 module C l i e n t A u t h { MTF modeling language, shares the underlying generative approach
2 main ( ) { l o o p a c c e s s P o r t ( ) ; }
3 of deriving those languages we use here and we first applied
4 transformation accessPort () { those deltas to architectural models [32].
5 SecArcComponent $C [ [ component $ c l i e n t {
6 A c c e s s $A ;
7 } ]] VI. D ISCUSSION
8 c o n n e c t $ c l i e n t . $_ - > $ s e r v e r . $someInPort ;
9 SecArcComponent $S [ [ component $ s e r v e r { A generated DSTL relies on the concrete syntax of its base
10 p o r t i n $someInPort ; DSL. However, for typing schema variables the nonterminal
11 [ [ : - a c c e s s $someInPort ( $ p o l i c y ) ] ] ;
12 } ]] names of the modeling language are used and, thus, this
13 where { $ p o l i c y = $A . g e t P o l i c y ( ) ; abstract syntax information become part of the concrete syntax
14 $C . g e t T r u s t l e v e l ( ) < $S . g e t T r u s t l e v e l ( ) }
15 } of the DSTL. This cannot be avoided completely as for the
16 } black box variant of schema variables the type cannot be
Listing 3. The transformation moves access control enforcement from inferred whenever there is an alternative of nonterminals in
client to server components. the base DSL. Furthermore, keywords such as not or where
We use the transformation depicted in Lst. 3 to identify and delimiters might conflict with the DSL’s concrete syntax.
client components which have this anti-pattern (ll. 5-7) and However, these problems can be solved by using MontiCore’s
add access control to the server (ll. 9-12). Client components language inheritance to redefine the concrete syntax of the
within this anti-pattern have one of the statement starting with DSTL. Allowing every model element of the base DSL as a
access, so we use a black box schema variable $A for the top level element in transformation rules leads to problems
common super type Access to match both (l. 6). Furthermore, if the model element does not have any mandatory concrete
there is a connection (l. 8) to a more trustworthy server syntax. Restructuring the DSL will solve this issue.
(l. 9-12). We use the white box variant of schema variables VII. S UMMARY
for the client ($C in l. 5) and the server ($S in l. 9). In
We presented a framework to generate DSTLs from the
the where-block we first retrieve the access policy from the
grammars of DSLs. The resulting DSTLs consist of declarative
client by utilizing the method getPolicy() from $A and assign
transformation rules that employ patterns based on the DSL’s
it to the $policy variable (l. 13). Finally, to ensure that the
concrete syntax to describe both what is to be replaced and
client has a lower trust level then the server, we use another
how it is to be replaced. These transformation rules are
method getTrustlevel() accessible via the variables $C and
embedded into a control flow language to describe complex,
$S (l. 14). Using a combination of keywords and abstract
imperative transformation modules. As such DSTLs reuse
syntax of MontiSecArc in the DSTL makes the patterns precise
the well-know vocabulary of the underlying DSL, modeling
and comprehensible to domain experts.
individual transformations require less effort from domain
V. R ELATED W ORK experts. The control flow language is very compact and
Similar to PROGRES [20], Fujaba [21], eMoflon [22], learning their combination is less complex than learning a
and Henshin [23], the transformations of our approach are general transformation language. The framework has been
endogenous, and in-place [16]. However, these approaches applied to the C&C ADLs MontiArc and its descendant
do not employ the concrete syntax of the underlying DSL. MontiSecArc. We currently examine the application of the
There are approaches for transforming software architectures DSTL generation framework to other ADLs in ongoing case
[24]–[26], however, they either introduce their own notation, studies.
operate on the abstract syntax or provides less functionality R EFERENCES
e.g. do not allows to remove elements [25]. Existing
[1] R. France and B. Rumpe, “Model-Driven Development
approaches to derive DSTLs from DSLs focus graphical
of Complex Software: A Research Roadmap,” in Future
languages [6], [27] and do not provide the concrete syntax of
of Software Engineering 2007 at ICSE., 2007.
the transformation language. Another approach to circumvent
generic transformation languages is to infer LHS and RHS of
model transformations from examples [28], [29]. To generalize
[2] N. Medvidovic and R. N. Taylor, “A Classification [18] IEEE Computer Society Center for Secure Design,
and Comparison Framework for Software Architecture “Avoiding the top 10 software security design flaws,”
Description Languages,” IEEE Trans. Software Eng., 2014.
2000. [19] M. Howard and D. E. Leblanc, Writing Secure Code,
[3] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev, “ATL: 2nd. Microsoft Press, 2002.
A model transformation tool,” Science of Computer [20] A. Schürr, Operationales Spezifizieren mit
Programming, 2008. Programmierten Graphersetzungssystemen:
[4] E. Visser, “Meta-programming with Concrete Object Formale Definitionen Anwendungsbeispiele and
Syntax,” in Generative Programming and Component Werkzeugunterstützung. Wiesbaden: Deutscher
Engineering, 2002. Universitäts-Verlag, 1991.
[5] T. Baar and J. Whittle, “On the Usage of Concrete [21] T. Fischer, J. Niere, L. Torunski, and A. Zündorf, “Story
Syntax in Model Transformation Rules,” in Diagrams: A New Graph Rewrite Language Based on
International Andrei Ershov memorial conference the Unified Modeling Language and Java,” in Theory
on Perspectives of systems informatics (PSI), 2007. and Application of Graph Transformations, 2000.
[6] R. Grønmo, “Using Concrete Syntax in Graph-based [22] E. Leblebici, A. Anjorin, and A. Schürr, “Developing
Model Transformations,” PhD thesis, University of eMoflon with eMoflon,” in Theory and Practice of
Oslo, 2009. Model Transformations, 2014.
[7] E. Syriani, H. Vangheluwe, R. Mannadiar, C. Hansen, [23] T. Arendt, E. Biermann, S. Jurack, C. Krause, and
S. V. Mierlo, and H. Ergin, “AToMPM: A Web-based G. Taentzer, “Henshin: Advanced Concepts and Tools
Modeling Environment,” in MODELS’13: Invited Talks, for In-Place EMF Model Transformations,” in Model
Demos, Posters, and ACM SRC., 2013. Driven Engineering Languages and Systems, 2010.
[8] H. Krahn, B. Rumpe, and S. Völkel, “MontiCore: a [24] J. M. Barnes, D. Garlan, and B. Schmerl, “Evolution
framework for compositional development of domain styles: foundations and models for software architecture
specific languages,” International Journal on Software evolution,” Software & Systems Modeling, 2014.
Tools for Technology Transfer (STTT), 2010. [25] O. Barais, A. F. Le Meur, L. Duchien, and J.
[9] A. Haber, M. Look, P. Mir Seyed Nazari, A. Navarro Lawall, “Software Architecture Evolution,” in Software
Perez, B. Rumpe, S. Voelkel, and A. Wortmann, Evolution, 2008.
“Integration of Heterogeneous Modeling Languages via [26] L. Grunske, “Formalizing Architectural Refactorings
Extensible and Composable Language Components,” as Graph Transformation Systems,” SNPD/SAWN ’05,
in Proceedings of the 3rd International Conference on 2005.
Model-Driven Engineering and Software Development, [27] T. Kühne, G. Mezei, E. Syriani, H. Vangheluwe, and
2015. M. Wimmer, “Explicit Transformation Modeling,” in
[10] M. Schindler, Eine Werkzeuginfrastruktur zur agilen Models in Software Engineering, 2010.
Entwicklung mit der UML/P. Shaker Verlag, 2012. [28] E. Kindler and R. Wagner, “Triple Graph Grammars:
[11] A. Haber, J. O. Ringert, and B. Rumpe, “MontiArc – Concepts, Extensions, Implementations, and
Architectural Modeling of Interactive Distributed and Application Scenarios,” Software Engineering Group,
Cyber-Physical Systems,” RWTH Aachen, Tech. Rep., Department of Computer Science, University of
2012. Paderborn, Tech. Rep., 2007.
[12] R. Sandhu and P. Samarati, “Access control: principle [29] P. Brosch, P. Langer, M. Seidl, K. Wieland, M. Wimmer,
and practice,” Communications Magazine, IEEE, 1994. G. Kappel, W. Retschitzegger, and W. Schwinger,
[13] M. Nagl, Graph-Grammatiken: Theorie, Anwendungen, “An Example Is Worth a Thousand Words: Composite
Implementierung. Vieweg, 1979. Operation Modeling By-Example,” in Model Driven
[14] K. Hölldobler, B. Rumpe, and I. Weisemöller, Engineering Languages and Systems, 2009.
“Systematically Deriving Domain-Specific [30] E. Syriani, H. Vangheluwe, and B. LaShomb, “T-Core:
Transformation Languages,” in International conference a framework for custom-built model transformation
on Model Driven Engineering Languages and Systems engines,” Software & Systems Modeling, 2013.
(MoDELS), 2015. [31] J. Sánchez Cuadrado, E. Guerra, and J. de Lara,
[15] T. Mens and P. V. Gorp, “A Taxonomy of Model “Towards the Systematic Construction of
Transformation,” Electronic Notes in Theoretical Domain-Specific Transformation Languages,” in
Computer Science, 2006. Modelling Foundations and Applications, 2014.
[16] K. Czarnecki and S. Helsen, “Feature-based Survey [32] A. Haber, K. Hölldobler, C. Kolassa, M. Look, K.
of Model Transformation Approaches,” IBM Systems Müller, B. Rumpe, and I. Schaefer, “Engineering
Journal, 2006. Delta Modeling Languages,” in Proceedings of the
[17] A. Habel, R. Heckel, and G. Taentzer, “Graph grammars 17th International Software Product Line Conference
with negative application conditions,” Fundamenta (SPLC’13), 2013.
Informaticae, 1996.