Domain-Specific Composition of Model Deltas.

Full text

Page 1

Domain-Speci?c Composition of Model Deltas
Maider Azanza1, Don Batory2, Oscar Díaz1, and Salvador Trujillo3
1University of the Basque Country, San Sebastián, Spain
{maider.azanza, oscar.diaz}@ehu.es
2University of Texas at Austin, Austin, Texas, USA
batory@cs.utexas.edu
3IKERLAN Research Centre, Mondragon, Spain
strujillo@ikerlan.es
Abstract. We present a general approach to the incremental develop-
ment of model-based applications using endogenous transformations, i.e.
transformations whose input and output models conform to the same
metamodel. Our work describes these transformations as model deltas
that, when composed, deliver a complete model. We establish a relation-
ship between a metamodel and its corresponding delta metamodel, show
how model deltas can be de?ned as model changes (additions), explain
how deltas can be composed using domain-speci?c composition algo-
rithms, and propose metamodel annotations to specify these algorithms.
We present di?erent case studies as proofs of concept.
1Introduction
Model Driven Engineering (MDE) conceives software development as transfor-
mation chains where models are the artifacts to be transformed. Transformations
which map abstract models to executables have received the most attention [30].
An initialModel of an application is conceived and then is mapped, level by
level, until a platform-speci?c model is reached. The main challenges are map-
ping between levels, where each level has its own distinct metamodel, and bal-
ancing trade-o?s between alternative transformation strategies, e.g. addressing
non-functional requirements. These transformations, that have di?erent input
and output metamodels, are exogenous.
The creation of initialModels has itself been the subject of research. View-
points have been used to address distinct perspectives of a target system [20].
In UML, class diagrams, state machine diagrams and activity diagrams capture
di?erent perspectives of the same application. Each viewpoint has its own dis-
tinct metamodel. But even viewpoints can be too coarse-grained to be units of
development. Object-oriented (OO) programming faces similar problems when
modularity is arranged by classes, rather than by concerns. Individual concerns
crosscut distinct classes, complicating both development and maintenance [14].
Likewise, an initialModel integrates many distinct concerns of an applica-
tion. Ease of maintenance encourages concerns to be both explicit and speci?ed
separately as model transformations, so that the initialModel itself is the re-
sult of a chain of endogenous transformations, i.e. transformations whose input

Page 2

and output models conform to the same metamodel. A consequence is that
an initialModel is constructed incrementally by composing di?erent endoge-
nous transformations ci, one per concern, starting from a base: initialModel =
c3(c2(c1(baseModel))). This is the essense of incremental development [35].
Incremental development is not new. Collaborations have been proposed to
support role-based designs in the incremental development of OO programs
where each role contributes attributes and operations to achieve the role's pur-
pose [31]. Classes are then ?incrementally? extended by the roles they endorse.
Incremental development is also at the heart of feature-oriented programming [5].
Here, the notion of feature displaces that of role as the design driving force. Prod-
ucts are then incrementally constructed by composing the features the product
will exhibit. This paper inherits from these approaches. The primary di?erence
stems from the artifacts being incrementally de?ned (i.e. initialModels), and the
mechanism realizing the increments (i.e. endogenous transformations).
Current model transformation languages (e.g. ATL [15], ETL [19], RubyTL
[11]) can specify any transformation. They were designed to handle arbitrarily
complex mappings between di?erent metamodels. Our experience and that of
many others suggests that typical endogenous transformations are much simpler
[3,23,24,32].
In this paper, we explore endogenous transformations characterized by:
? Model Deltas. Transformations are expressed as changes (additions) to mod-
els that when composed with a base model, deliver a complete model.
? Domain-speci?city. Domain-speci?c composition algorithms are essential
[3,24,28,36]. To this end, we annotate the domain metamodel to specify com-
position algorithms. We show that this light-weight approach o?ers a prac-
tical and powerful way to integrate domain-speci?c composition algorithms
seamlessly into a development environment.
We implement our ideas using the Epsilon Merging Language (EML) [18] and
present di?erent case studies as proofs of concept4.
2 Big Picture
Incremental development is widely known to handle design complexity and im-
prove design understandability [35]. Although any artifact can be developed in-
crementally, the greatest bene?ts are observed when families of related artifacts
are developed. This occurs in Software Product Lines (SPL) [10].
In an SPL, features can be seen as endogenous transformations [5]. A feature
is an increment in program functionality that customers use to distinguish one
program from another. SPL programs are constructed from a pre-planned set of
features, which map (Java) programs to (Java) programs. A particular program
in an SPL is produced by applying features to an initial program.
4Our composition engine and examples used in this paper are available for download
at http://www.onekin.org/andromeda.

Page 3

A product line in an MDE setting is a set of models. The baseModel cor-
responds to the above mentioned initial program and expresses the greatest
common denominator of all SPL members. In many product lines, baseModel is
simply the empty model ∅ [6].
Figure 1a shows a meta-
model MM and its cone of
instances (i.e. the set of all
models that conform to MM).
A subset of the cone is a set
of models that belongs to a
product line PL (e.g. m2...m4
belong to PL, m1 is not a
member, and all m1...m4con-
form to MM). Note that the
empty model ∅ and model mA
are outside the cone of MM,
meaning that ∅ and mA do
not conform to MM.
Figure 1b shows feature
realizations (i.e. endogenous transformations) as arrows5that map one model
to another. An important property about arrows is that a composition of two
or more arrows is yet another arrow [6]. Further, observe that a composition of
arrows may produce an intermediate model (mA) that does not conform to MM.
Only the members of PL (m2, m3 and m4) are required to conform to MM,
regardless of the steps needed to obtain them. The members of PL are produced
by composing arrows starting from ∅ and this collection of arrows de?nes the
features of PL.
A speci?cation of all legal compositions of features in a product line is a
feature model [16]. Every model in PL's product line has a derivation (i.e., com-
position of arrows starting from ∅) that is expressed by the PL's feature model.
Figure 1c illustrates the SPL perspective: a collection of arrows (features) plus
a feature model (that constrains how these arrows can be composed) yields the
set of models of a product line.
The relationships among arrows described above are very general; they hold
for all implementations. The key questions in mapping arrows to an implemen-
tation are: (i) how is an arrow speci?ed?, (ii) if arrows are themselves models
then, what is an arrow metamodel? (iii) how are arrows composed? and (iv) how
can domain-speci?c arrow composition algorithms be de?ned? The next sections
address these issues.
Fig.1. Models, Endogenous Transformations and
Product Lines
5The term comes from Category Theory. Arrows are maps between objects. In an
MDE setting arrows can be implemented using endogenous or exogenous transfor-
mations depending on their function. In this work we are interested in arrows that
build SPLs (i.e. endogenous transformations) that implement deltas. See [6] for a
description of the links between MDE, SPLE and Category Theory.

Page 4

3A Questionnaire SPL and its Arrows
Fig.2. Feature Model for
the CSSPL
Questionnaires are a common research instrument in
Social Sciences as a means to gather information. A
set of questions is presented to respondents and a re-
search hypothesis is validated against their answers.
Although the Web is an invaluable resource for con-
ducting surveys, social scientists generally lack the
technical knowledge to make their questionnaires ac-
cessible online. To overcome this, abstractions are de-
?ned to liberate domain experts from the technicali-
ties of Web surveys and are transformed into actual
Web implementations6.
Similar questionnaires that are targeted to di?er-
ent population pro?les are needed on a regular basis.
A one-size-?ts-all questionnaire is inappropriate. Our
example focusses on Crime and Safety Surveys that
assess citizens' feelings on the safety of their enviroment. Figure 2 shows the
feature model for the Crime and Safety Survey Questionnaire SPL (CSSPL)7.
Its features de?ne how questionnaires vary in this domain. Speci?cally, (i) if the
respondent is a female, she is given a Sexual Victimization Block apart from
the Base Questionnaire, (ii) if he or she belongs to a minority, a Hate Crime
Block is added and (iii) regarding age, adults are given the Consumer Fraud
Block while minors receive the School Violence Block. Now questionnaire cre-
ation is not just a ?single shot?. Rather, a questionnaire is characterized in terms
of features that customizes it for a target audience.
Fig.3. Feature Implementation Options
6Examples
(http://www.esurveyspro.com) and Lime Service (http://www.limeservice.org).
7This Questionnaire family is inspired in the European Crime and Safety Survey
(http://www.europeansafetyobservatory.eu/euics_fiq.htm).
ofapplicationsthatcatertothisneedareESurveyPro

Page 5

There are two basic ways to implement a feature (i.e. an arrow that in-
crements a model with certain functionality). One is to use a general-purpose
transformation language. Figure 3a shows how the Minor feature is expressed
in RubyTL. That is, how the Department of Youth should be added to the
acknowledgments of the Base Questionnaire, how the estimated completion
time is increased in 10 minutes, and the School Violence Block that should
be included when the questionnaire is directed to minors. Another way is simply
to create a model delta that de?nes the additions the Minor feature makes to a
model (see Figure 3b). The latter brings the following advantages: (i) permits
the checking of questionnaire constraints (e.g. option codes have to follow a
certain format), (ii) makes features easier to understand and analyze [36] and
(iii) separates what the feature adds from how it is added, thus making the how
reusable for all questionnaire arrows. This advantages are revised in Section 7.
Note that this de?nition of endogenous transformations is monotonic, features
are not allowed to delete previously existing model elements.
4Arrow Metamodels
Let M and MM be a model and its metamodel, respectively. Further, let AM
and AMM stand for an arrow model and its arrow metamodel, respectively. This
section presents a de?nition of AMM and its relationship with MM.
Figure 4 is a simpli?ed Ques-
tionnaire Metamodel MM. Ar-
rows (which to us represent frag-
ments/additions to MM models)
do not satisfy all constraints of
MM. In the Question metaclass,
for example, each question must
have at least two options. An ar-
row can contribute just one or no
option at all. This is the case for
the Minor feature (see Figure 5),
where question atq2 has but one
option. Once this feature is com-
posed with the base, the result
has four options, which is con-
formant with the questionnaire
metamodel. Hence, an AMM can
be created by eliminating con-
straints from MM.
However, not every constraint
in the metamodel should be removed. Consider the Question metaclass which
requires every question to have at most seven options. If any arrow adds more
than seven options, every questionnaire created using that arrow will not conform
Fig.4. Questionnaire Metamodel

Page 6

Fig.5. Constraint Violation by the Minor Feature
to the metamodel. Thus, this upper-bound constraint should be ful?lled by every
arrow8.
Two types of constraints are encountered when creating
arrow metamodels:
Fig.6. AMM Cone
? Arrow Constraints: Constraints that can be validated
for every arrow (e.g. upper-bounds, option codes
have to follow a certain format, etc.). These constraints
are kept in the AMM.
? Deferred Constraints: Constraints that can only be
evaluated after all arrows are composed, i.e. when the
entire product model has been assembled (e.g. lower-
bounds)9. The AMM is obtained by removing these
contraints from the metamodel.
Domain engineers should decide to which group each con-
straint belongs. An AMM can also be automatically generated from the product
metamodel simply by removing all the metamodel's constraints except upper-
bounds. However, the ?rst option is preferrable as it detects more inconsistencies
earlier in the process (i.e. at arrow creation time). We derived the AMM for the
Questionnaire MM by removing eight lower-bound constraints.
Figure 6 shows the relationship between the cones of MM and AMM. Each
model miin MM is equivalent to an arrow ∅ → miin AMM. This means that
the cone of AMM not only includes every model in the cone of MM, but other
models and arrows as well (e.g., models ∅ and mA, and arrow mA→ m4and
composite arrow ∅ → mA). The close relationship between AMM and MM means
that arrows are de?ned using the same concepts as models and, as they belong
to an SPL, they are designed with composition in mind, the topic of the next
section.
8This holds for composed arrows as well. If a composed arrow adds more than seven
options, its use will also not conform to the the Question metaclass.
9This has a database counterpart. The database administrator de?nes a database
schema with constraints. Additionally, the administrator can declare a constraint
to be validated as soon as a database update happens (immediate mode) or wait
till the end of the transaction, once all updates were conducted (deferred mode).
The deferred mode allows for some constraints to be violated during a transaction
execution, as long as the constraints hold at the end of the transaction.

Page 7

5Arrow Composition
Model composition has been de?ned as the operation MAB = Compose (MA,
MB, CAB) that takes two models MA, MB and a correspondence model CAB
between them as input, and combines their elements into a new output model
MAB[7]. Arrow composition is a special case, where both MAand MBconform
to the same metamodel. Further, the correspondence model CABis implicit as
objects with the same name (or rather, identi?er) in models MAand MB are,
in fact, the same object. Arrow composition is performed by pairing objects of
di?erent fragments with the same name (identi?er) and composing them.
Fig.7. Composition of Minor and Base Features
There are two distinct cases in object composition:
? Generic: This is the default, metamodel independent, composition [2,5]. The
composition of a pair of objects equals the composition of their correspond-
ing attribute pairs. The composition of a pair of scalar-valued attributes is
this: if both have di?erent non-null values, composition fails and an error
is raised. Otherwise, the non-null value is the result. In the case of set-
valued attributes (including references), their union is the result. Figure 7
presents di?erent examples of this composition: title, introduction, logo
and appreciation_text attributes.
? Domain-Speci?c: In a majority of cases, generic composition is su?cient.
The remaining cases require a domain-speci?c composition method. Consider
the acknowledgments and time attributes in the Questionnaire metaclass.
An organization can fund all the study or only part of it. Figure 7 shows
how the base study is funded by Organization A and the part regarding
minors is funded by the Department of Youth. If objects were composed
generically, an error would be raised as both objects have a di?erent value in
the acknowledgments attribute. However, the convention for questionnaires
is to concatenate both acknowledgments as the result.
The time attribute is another example. It indicates the estimated time
needed to complete the questionnaire. The base feature takes 20 minutes
and the minor feature needs 10 more. The expected behavior would add
both values to the result, not to raise an error.
A practical tool should allow domain engineers to annotate any class or attribute
to indicate that a customized composition algorithm, rather than the default

Page 8

algorithm, is to be used. Additionally, since some algorithms are likely to be used
in di?erent domains (e.g. string concatenation), a set of keywords are provided
to denote those recurrent algorithms as annotations on the metamodel, hereafter
referred to as built-in algorithms. These annotations include: @concat (i.e. given
two values V1 and V2, the composition delivers V1V2), @slash_concat (i.e. the
composition delivers V1/V2), @sum (i.e. the composition delivers the addition of
V1 and V2), @min (minimum value), and @max (maximum). Engineers can turn a
domain-speci?c composition algorithm into a built-in algorithm by naming and
including it in a composition-algorithm library.
Fig.8. Annotated Questionnaire Metamodel
Figure 8 depicts the
annotated Questionnaire
metamodel. Note that
the acknowledgments at-
tribute in Questionnaire
and the introduction
attribute in Block are
annotated with @concat.
This indicates that their
values are to be com-
posed by concatenation.
Moreover, the time at-
tribute in Questionnaire
is annotated with @sum,
meaning that composed
contents should be added.
When no built-in al-
gorithm is su?cient, en-
gineers must resort to
describing domain-speci?c composition algorithms procedurally (hereafter called
ad-hoc algorithms). This is the only case that requires knowledge of a transforma-
tion language, which in our case is EML. In the Questionnaire domain, blocks
can be de?ned using a scale. When composing blocks with di?erent scales, Ques-
tionnaire semantics dictate not to merge blocks but to keep them as separate
sub-blocks10. We specify ad-hoc algorithms as a piece of EML code, and is an
annotation that is attached to the block class11(see Figure 8).
10Note that this domain speci?c composition is not limited to individual attributes as
in the above examples; it applies to complete Block objects.
11This option is debatable. Another possibility is to embed the ad-hoc algorithm di-
rectly into the generated code using a ?protected region?, i.e. a piece of code that is
not overridden when the code is newly generated. We prefer to have all composition
algorithms speci?ed in a single place: the metamodel. In our opinion, this facilitates
understandability and maintainability.

Page 9

5.1Implementation
Given an annotated metamodel MM, our prototype automatically generates Ep-
silon Merging Language (EML) rules for composing arrows. EML is a rule-based
language for merging models of diverse metamodels and technologies [18].
The Object metaclass de?nes the core metamodel of our implementaion of
ANDROMEDA (ANnotation-DRiven Oid-based coMposEr for moDel Arrows)
(see Figure 9). Object instances are singled out by an explicit identi?er that is
used for object matching. Object holds the generic methods for match, merge,
and copy methods. Match compares pairs objects and decides if they match.
Merge merges two objects that match and copy copies objects for which no
match has been found to the result.
This generic behavior can
bespecialized tocater for
the composition peculiarities
of the domain at hand. To
this end, Object specializa-
tions are created for each do-
mainmetaclass (seeFigure
9). Note how Questionnaire
and Block override the generic
merge method to address their
own speci?c composition se-
mantics.
Generic behavior. This be-
havior is provided by AN-
DROMEDA. The match method
is realized through an Epsilon
Comparison Language (ECL)
rule (see Figure 10a) [17]. This rule indicates that two Objects match if they
are instances of the same class and have the same identi?er. The merge method
is supported through an EML rule (see Figure 10b). The rules applies to all
Object instances. We also provide methods that de?ne default merge behavior
for attributes and references.
Domain-speci?c behavior. Domain-speci?c EML rules that extend the generic
EML rules (rule extension is the counterpart of method inheritance) are gener-
ated. Metamodel annotations indicate that generic merging needs to be substi-
tuted by domain-speci?c merging. Three situations arise:
Fig.9. Extended Questionnaire Metamodel
? Generic Algorithm (e.g. Question metaclass). See Figure 10c for an example.
This rule extends the generic rule MergeObject for the Question metaclass
by just reusing the default methods.
? Built-in Algorithm (e.g. Questionnaire metaclass). The annotations in the
metaclass the metamodel (see Figure 8), the acknowledgments attribute is
annotated with @concat and the time attribute is annotated with @sum.
These annotations lead to the merge rule in Figure 10d where the generic

Page 10

Fig.10. Implementing composition through EML and ECL rules.
merge of acknowledgments and time attributes is overridden by string con-
catenation and integer addition respectively.
? Ad-hoc Algorithm (e.g. Block class). The approach is similar to the built-in
algorithm, but now the code embedded in the annotation is directly copied
into the EML rule (see Figure 10e).
6 Case Studies
Among the motivations for connecting arrows and product lines in Section 2 is
to underscore the generality of their relationships. We believe our CSS Ques-
tionnaire SPL (CSSPL) is typical of a basic MDE product line, and we have
explained how our tools handle it. But there are examples from other technical
spaces [8] for which these same relationships can be demonstrated to hold.
The largest examples of feature-based compositions come from Feature Ori-
ented Programming (FOP), i.e. from the EBNF technical space [8]. SPLs in FOP
are families of Java-based programs. AHEAD Tool Suite (ATS) is a set of tools
to support FOP [5]. ATS was refactored into the ATS Product Line (APL), i.e.,
ATS bootstraps itself by composing features of APL. Over time, ATS has grown
to 24 di?erent tools comprising over 200K LOC Java. In our case study, we focus
only on model representations of the code that corresponds to features12.
12Along with APL, we also created models for the Graph Product-Line (GPL), a
family of classical graph applications [21]. The results of GPL are not much di?erent

Page 11

Features in APL are written in Jak, a superset of Java that supports features
and metaprogramming [5]. We de?ned a bridge that translates an APL feature
written in Jak into a model fragment that conforms to the Jak Arrow Metamodel
and the other way around. By composing model fragments, we can produce a
model of the ATS product line.
Interestingly, no constraint had to be removed from the Jak metamodel to
produce its arrow metamodel: all constraints de?ned in the Jak metamodel where
applicable to arrow models. Next, a composition algorithm was chosen for each
element in the Jak metamodel.
Table 1 lists statistics about the Jak Metamodel,
with statistics from the Questionnaire metamodel
(Qst) for comparison purposes. The number of classes,
attributes and references of each metamodel and the
distribution of their composition types are listed. Note
that Jak uses a large number of domain-speci?c com-
position algorithms. While this is not unexpected,
what is interesting is that several of these algorithms
worked on objects and not attributes.
Table 2 compares the average size of CSSPL and
APL features with their size in objects (a.k.a Objs)
and references (a.k.a Refs). It also presents the aver-
age size for particular products we composed. Note that APL model arrows are
on average four times larger than the arrows of CSSPL, and APL products are
over ?fty times larger than CSSPL products.
Again, one of the advantages of the Jak case stud-
ies was to demonstrate our composition principles
hold across di?erent technical spaces. Another advan-
tage was that we could verify the correctness of our
compositions. Model arrows were composed to yield a
certain product and then transformed into code. The
same product was obtained by directly composing its
code features and both results were compared using
source equivalence to test for equality13.
MM DATA
Classes
Attributes
References
Removed Constraints
Generic Comp.
D.S. Comp.
Jak Qst
12
18
25
0
37
18
5
15
7
8
23
4
Table 1. Jak and Ques-
tionnaire Metamodels
Objs Refs
22
109
63
3035 9394
CSSPL Features
APL Features
CSSPL Products
APL Products
21
332
62
Table
APL Statistics
2.
CSSPLand
7Perspective and Related Work
7.1 Perspective
We conceive model construction as a gradual composition of model arrows. Each
arrow realizes an increment in application functionality (i.e. a feature), and the
than what we report for APL and CSSPL. The GPL case study is available at
http://www.onekin.org/andromeda.
13Source equivalence is syntactic equivalence with two relaxations: it allows permuta-
tions of members when member ordering is not signi?cant and it allows white space
to di?er when white space is unimportant.

Page 12

functionality of the ?nal application is the added functionality of each of its
arrows. Therefore, the characterization of our work is twofold. First, increments
in functionality are embodied as deltas that are expressed in the same language
as the ?nal model. The bene?ts include:
? Certain domain constraints can be checked at arrow building time, allowing
earlier error detection. It paves the way to safe composition, the assurance
that all products of the SPL conform to the domain metamodel.
? It separates what a feature adds from how it is added, thus making the
composition algorithms reusable for all features that conform to the same
metamodel.
? Declarativeness. Model arrows are easier to read and write than their trans-
formation counterpart. Figure 3a shows the same Minor feature but now re-
alized using a general-purpose transformation language, RubyTL [11]. Even
to someone accustomed to reading transformation rules, it takes some time
to grasp information that the transformation adds to the base model. When
handling SPLs with hundreds of features, scalability is a main issue and
declarativeness a major enabler.
? The Arrow Metamodel can be derived from the domain metamodel (e.g.
Questionnaire) by removing constraints.
Second, our work also uses model superimposition as the default approach to
model composition. Additionally, domain-speci?c composition semantics are cap-
tured through annotations in the domain metamodel. This improves the declar-
activeness of how the composition algorithms are captured. The bene?ts include:
? Automatization. The composition algorithm can be automatically generated.
As a proof of concept, we showed the implementation that generates EML
rules.
? Understandability: Anchoring composition annotations on the metamodel,
permits designers to focus on the what rather than on how the composition
is achieved.
? Maintenance: Additional composition algorithms can be added or removed
with minimal e?ort. This could be of interest in the context of metamodel
evolution where new metaclasses/attributes can be added that require cus-
tomized composition algorithms [33].
Our work also raises research questions that are subject of future work. General-
izing our arrow de?nition to allow deletions is a case in point. We want to study
in which cases is that deletion necessary and what its drawbacks are. Moreover,
in an MDE setting endogenous transformations de?ne only half of the picture.
We are interested in transformations that map an arrow that is an instance of
an arrow metamodel to an arrow that is an instance of another [6]. Another
topic deals with safe composition: once all arrows are composed, the resulting
model should ful?ll all the constraints of the metamodel. We want to guarantee
that all legal feature compositions yield models that satisfy all constraints of
the metamodel, but without enumeration. Existing work suggests a direction in
which to proceed [12,22,29].

Page 13

7.2 Related Work
Implementation Approaches. Two main trends in implementing endogenous trans-
formations can be identi?ed: transformation languages vs. model deltas. Exam-
ples of the former include C-SAW [4], MATA [34] and VML* [36]. A transfor-
mation language is more versatile and it performs analyses that are presently
outside our work. For example, MATA comes with support to automatically de-
tect interactions between arrows. Since arrows in MATA are graph rules, the
technique of critical pair analysis can be used to detect dependencies and con-
?icts between rules14. This versatility, however, comes at a cost: (i) it requires
developers to be familiar with a graph transformation language and (ii) being
de?ned in a di?erent language, it reduces checking with respect to the domain
metamodel that can be performed on the transformations. To ease the developers
burden, MATA de?nes transformations between UML and the underlying graph
rules. Nevertheless, these transformations must be de?ned for every metamodel
at hand.
Traditionally SPL arrows are de?ned as model deltas ? a set of additions
? that are superimposed on existing models. Recently, several researchers have
followed this trend, particularly using aspects to implement them [3,23,24,32].
To the best of our knowledge, none of these approaches de?nes a mechanism to
check the conformance of arrows to their arrow metamodels. Interestingly, Smar-
tAdapters [24] de?nes pointcuts as model snippets that conform to a metamodel
that is obtained by eliminating all constraints from the domain metamodel, in a
similar fashion to the way we de?ne arrow metamodels [26]. However, no mention
is made about an advice metamodel.
Along with aspects, collaborations are another candidate paradigm for realiz-
ing model deltas. Collaborations are monotonic extensions of models that encode
role-based designs and are composed by superimposition [31]; collaborations are
a centerpiece in recent programming languages (e.g. Scala [25]) and prior work
on feature-based program development [5]. In contrast, aspects may o?er a more
general approach to express model deltas, where pointcuts identify one or more
targets for rewriting (a.k.a. advising). However, the generality of aspects is by no
means free: it comes at a cost of increased complexity in specifying, maintaining,
and understanding concerns [1].
Domain-Speci?city. There are a number of model delta composition tools,
some using Aspect Oriented Modeling (AOM), that are now available. XWeave
[32] and Kompose [13] support only generic composition, although the latter has
some limited support for domain speci?cities in the form of pre-merge and post-
merge directives. Other approaches, e.g. SmartAdapters [24], VML* [36] and
FeatureHouse [3], provide support for domain-speci?c composition. The ?rst
two require engineers to explicitly indicate how arrows are to be composed,
while we strive to promote reuse by automatically generating as much as pos-
sible from the metamodel by leveraging metamodel annotations. FeatureHouse
also accounts for domain speci?cities. However, it is restricted to tree composi-
tion, and domain-speci?c composition is limited to tree leaves. In contrast, our
14It may be possible to de?ne a corresponding analysis on model fragments.

Page 14

approach considers graphs rather than trees and composition can be simultane-
ously speci?ed at di?erent points within models.
Model Di?erences. Model arrows are closely related to the idea of model
model di?erences [9,27]. The main distinction stems from their purpose, the
former implement a feature in an SPL and are normally built separately while
the latter are calculated as the di?erence between two models that conform to
the same metamodel.
8 Conclusions
MDE conceives software development as transformation chains where models are
the artifacts to be transformed. We presented an approach to the incremental
development of initialModels in an SPL setting. Models are created incremen-
tally by progressively applying endogenous transformations that add increments
in functionality. We depicted these transformations as arrows and implemented
them as model deltas. We explained how arrows realize features in SPLs, how
arrows conform to arrow metamodels, and how arrow metamodels are derivable
from domain metamodels. The focus of our work stressed the need for domain-
speci?c composition algorithms, and how they could be added to metamodels in
a practical way. Further, our case studies illustrated the technical-space indepen-
dence of our approach. We believe our light-weight approach o?ers a practical
and powerful way to integrate domain-speci?c composition algorithms seamlessly
into an MDE development environment.
Acknowledgments. We gratefully thank L. Vozmediano for her help with the
questionnaires domain and J. De Sosa, M. Kuhlemann, R. Lopez-Herrejon, G.
Puente and J. Saraiva for fruitful discussions during the preparation of this
draft. This work was co-supported by the Spanish Ministry of Education, and
the European Social Fund under contract MODELINE, TIN2008-06507-C02-01
and TIN2008-06507-C02-02. Batory's work was supported by NSF's Science of
Design Project CCF-0724979.
References
1. S. Apel et al. Aspectual Feature Modules. IEEE TSE, 34(2), 2008.
2. S. Apel et al. FeatureHouse: Language-Independent, Automated Software Compo-
sition. In ICSE, 2009.
3. S. Apel et al. Model Superimposition in Software Product Lines. In ICMT, 2009.
4. K. Balasubramanian et al. Weaving Deployment Aspects into Domain-Speci?c
Models. IJSEKE, 16(3), 2006.
5. D. Batory et al. Scaling Step-Wise Re?nement. IEEE TSE, 30(6), 2004.
6. D. Batory et al. The Objects and Arrows of Computational Design. In MoDELS,
2008.
7. J. Bézivin et al. A Canonical Scheme for Model Composition. In ECMDA-FA,
2006.
8. J. Bézivin and I. Kurtev. Model-based Technology Integration with the Technical
Space Concept. In MIS, 2005.

Page 15

9. A. Cicchetti et al. A Metamodel Independent Approach to Di?erence Representa-
tion. JOT, 2007.
10. P. Clements and L. M. Northrop. Software Product Lines - Practices and Patterns.
Addison-Wesley, 2001.
11. J. S. Cuadrado et al. RubyTL: A Practical, Extensible Transformation Language.
In ECMDA-FA, 2006.
12. K. Czarnecki and K. Pietroszek. Verifying feature-based model templates against
well-formedness OCL constraints. In GPCE, 2006.
13. F. Fleurey et al. A generic approach for automatic model composition. In MoDELS
Workshops, 2007.
14. G. Gottlob et al. Extending Object-Oriented Systems with Roles. ACM TOIS,
14(3), 1996.
15. F. Jouault and I. Kurtev. Transforming Models with ATL. In MoDELS Satellite
Events, 2005.
16. K. Kang et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study.
Technical report, CMU/SEI-90-TR-21, Software Engineering Institute, 1990.
17. D. Kolovos. Establishing Correspondences between Models with the Epsilon Com-
parison Language. In ECMDA-FA, 2009.
18. D. Kolovos et al. Merging Models with the Epsilon Merging Language (EML). In
MoDELS, 2006.
19. D. Kolovos et al. The Epsilon Transformation Language. In ICMT, 2008.
20. V. Kulkarni and S. Reddy. Separation of Concerns in Model-Driven Development.
IEEE Software, 20(5), 2003.
21. R. Lopez-Herrejon and D. Batory. A Standard Problem for Evaluating Product-
Line Methodologies. In GCSE, 2001.
22. R. Lopez-Herrejon et al. Using incremental consistency management for confor-
mance checking in feature-oriented model-driven engineering. In VAMOS, 2010.
23. B. Morin et al. A Generic Weaver for Supporting Product Lines. In EA, 2008.
24. B. Morin et al. Weaving Aspect Con?gurations for Managing System Variability.
In VAMOS, 2008.
25. M. Odersky et al. An Overview of the Scala Programming Language. Technical
report, EPFL, 2004.
26. R. Ramos et al. Matching Model-Snippets. In MODELS, 2007.
27. J. E. Rivera and A. Vallecillo. Representing and Operating with Model Di?erences.
In TOOLS, 2008.
28. Ina Schaefer. Variability modelling for model-driven development of software prod-
uct lines. In VAMOS, 2010.
29. S. Thaker et al. Safe Composition of Product Lines. In GPCE, 2007.
30. A. Vallecillo, J. Gray, and A. Pierantonio, editors. ICMT, 2008.
31. M. VanHilst and D. Notkin. Using Role Components to Implement Collaboration-
Based Designs. In OOPSLA, 1996.
32. M. Völter and I. Groher. Product Line Implementation using Aspect-Oriented and
Model-Driven Software Development. In SPLC, 2007.
33. Guido Wachsmuth. Metamodel adaptation and model co-adaptation. In ECOOP,
2007.
34. J. Whittle and P. Jayaraman. MATA: A Tool for Aspect-Oriented Modeling Based
on Graph Transformation. In MODELS Workshops, 2007.
35. N. Wirth. Program Development by Stepwise Re?nement. Commununications of
the ACM, 14(4), 1971.
36. S. Zschaler et al. VML* - A Family of Languages for Variability Management in
Software Product Lines. In SLE, 2009.