Generating Multi-Variant Java Source Code Using Generic Aspects

Sandra Greiner and Bernhard Westfechtel

Chair of Applied Computer Science I, University of Bayreuth, Universitätsstrasse 30, 95440 Bayreuth, Germany

Keywords:

Model-Driven Software Engineering, Model-to-Text, Model Transformations, Software Product Line Engi-

neering, Feature Annotations, Negative Variability, Feature Propagation.

Abstract:

Model-driven product line engineering (MDPLE) aims at increasing productivity when realizing a family

of related products. Relying on model-driven software engineering (MDSE) seeks to support this effect by

using models raising the level of abstraction. In MDSE model transformations are successfully applied to

transform in between different (model) representations. During MDPLE models based on negative variability

are augmented with variability information, we refer to as annotations. To derive products, source code is

generated in model-to-text (M2T) transformations. However, applying single-variant model transformations

(SVMT) to annotated models, typically loses the information in the output as SVMTs are not capable to process

annotations. This work contributes a solution which reuses existing SVMTs without changing them and which

transfers annotations to the output orthogonally to the reused transformation. In particular, we contribute

generic aspects, supporting any kind of input metamodel, to augment the outcome of (M2T) SVMTs with

annotations. Producing multi-variant source code (MVSC) is advantageous because all variants are reﬂected

in the output. Thus, changes made inside the MVSC can be integrated easily in all concerned products upon

their derivation. Otherwise, this needs to be done manually in a cumbersome process contradicting the purpose

of MDPLE, to raise productivity.

1 INTRODUCTION

Model-driven software engineering (MDSE) is a dis-

cipline aiming to increase productivity by generating

source code from models residing on a higher le-

vel of abstraction than the pure text (Völter et al.,

2006). Different kinds of models with well-deﬁned

syntax and semantics come into play during the pro-

cess of establishing a software system. A metamo-

del deﬁnes the abstract syntax to which a model con-

forms. The Eclipse Modeling Framework (EMF)

(Steinberg et al., 2009) is the de facto standard to re-

alize domain speciﬁc metamodels based on the Ecore

(meta-metamodel).

Furthermore, a whole set of similar software sy-

stems can be summarized in a software product line

(SPL). Based on the principles of organized reuse and

variability, the discipline of SPL engineering (SPLE),

too, seeks to increase productivity when realizing a

family of related products. A well-known process

in SPLE (Pohl et al., 2005) is divided into two pha-

ses: domain engineering, where common parts of the

software are deﬁned in a platform, and application

engineering, where products are (automatically) de-

rived from the platform. A platform holding all va-

riants is said to rely on negative variability whereas

with positive variability a base version for all pro-

ducts is extended with different fragments realizing

the speciﬁcs of single features. Combining both dis-

ciplines, MDSE and SPL (model-driven product line

engineering (MDPLE)) is meant to further raise the

level of abstraction and productivity. In MDPLE ty-

pically products are derived from models, which are

used to design the platform during domain engineer-

ing. These domain models usually capture all variants

without explicitly being aware of the variability. An

MDPLE tool based on negative variability is FAMILE

(Buchmann and Schwägerl, 2012). It uses feature mo-

dels (Kang et al., 1990) to deﬁne the variability where

a feature conﬁguration selecting the features needed

in one variant allows to derive customized products

from the domain models. A mapping, denoted as an-

notation in the sequel, can be associated with each

model element to declare to which feature(s) the ele-

ment belongs and is necessary for automatically deri-

ving products.

On the other hand, model transformations play a

key role to automate the creation or evolution of mo-

dels from models residing on different levels of ab-

Greiner, S. and Westfechtel, B.

Generating Multi-Variant Java Source Code Using Generic Aspects.

DOI: 10.5220/0006536700360047

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 36-47

ISBN: 978-989-758-283-7

stractions. While model-to-model (M2M) transforma-

tions allow to transform in between two (or more)

models, model-to-text (M2T) transformations gene-

rate plain text (output) from a given model (input).

M2T transformations are often used to automatically

generate source code for a given model. A transfor-

mation considering only one direction is called uni-

directional whereas languages which not only spe-

cify the forward direction but also treat the backward

transformation are called bidirectional. While in in-

place transformations the input model serves as out-

put model as well, a separate output is created (ba-

tch) or modiﬁed (incremental) in out-place transfor-

mations. Incremental transformations usually rely on

keeping track of the link between in- and output ele-

ment in traces.

A frequently used M2M language is the At-

las Transformation Language (ATL) (Jouault et al.,

2008). Acceleo

, is a M2T language implementing

the Mof2Text standard proposed by the Object Mana-

gement Group (OMG) (Object Management Group,

2008). Likewise, Xpand (Efftinge et al., 2004) is anot-

her M2T language originating from the open Archi-

tecture Ware (oAW) project with the special feature to

support aspect-oriented programming (Kiczales et al.,

1997) which allows to extend already existing trans-

formations without modifying the original one.

By now, model transformations in various forms

are mature and frequently applied in MDSE. In MD-

PLE, however, multi-variant models are associated

with annotations which are not covered by aforemen-

tioned single-variant model transformation (SVMT).

Having a multi-variant input insofar as all variants are

visible in the model, the outcome also includes all va-

riants but the annotations are lost. If the multi-variant

output should be annotated as well, usually the anno-

tations have to be manually transferred in a laborious

and error-prone process.

Recently, the problem of this kind of multi-variant

model transformations (MVMT) was addressed in re-

search: In (Salay et al., 2014) the authors change

the execution semantics of single-variant graph-based

M2M transformations to conform to annotated multi-

variant input and produce annotated multi-variant

output. Contrastingly, an a posteriori approach to

automatically apply annotations after executing the

SVMT is proposed in (Greiner et al., 2017). Still, this

work only supports the reuse of speciﬁc ATL trans-

formations. Other research rather regards variability

in the rules (Strüber and Schulz, 2016) sometimes re-

sulting in the need to learn new language constructs

(Sijtema, 2010).

The enumerated proposals, however, only cover

http://www.eclipse.org/acceleo

M2M transformations: source code is usually only

derived for single products by providing a set of fe-

atures. If manual changes, e.g., implementing a met-

hod body, are performed in the product, these modi-

ﬁcations need to be applied to every single product

separately. This in turn is laborious and might lead

to diverging or erroneous realizations of the same fe-

ature.

Therefore, the present work contributes a solution

which successfully (1) reuses SVMTs and augments

the outcome (2) orthogonally to the existing transfor-

mation with annotations. Technically, the language

Xpand

is chosen since it leaves existing SVMTs un-

touched and allows to alter them with aspects. In

contrast to aspect-oriented approaches, e.g., written

in Xpand (Voelter and Groher, 2007), we do not im-

plement one aspect for each feature which are ad-

ded on demand to the ﬁnal product (positive variabi-

lity). Rather annotations are propagated to the source

code, reﬂecting all variants, by using one single ge-

neric Xpand aspect. The annotations are integrated in

form of preprocessor comments resulting in annota-

ted multi-variant source code (MVSC). Consequently,

manual changes can be added to the MVSC and are

included in the concerned products when being deri-

ved by providing a set of features to the preprocessor.

The remainder is structured in the following way:

At ﬁrst, we motivate the need for MVSC based on a

concrete example. Then, the paper provides an over-

view on the contribution and, next, a description of the

technical realization. Finally, it shows example trans-

formations. In the end, related work is discussed and

a conclusion is drawn including an outlook on future

work.

2 MOTIVATION

This section stresses the importance of MVMT, in ge-

neral, and of annotations inside source code, in par-

ticular. By looking at a simpliﬁed form of the well-

known SPL for Graph libraries as example from lite-

rature (Lopez-Herrejon and Batory, 2001), we deduce

some properties and requirements an (M2T) MVMT

should fulﬁll.

We used the Xpand2 implementation which we refer to

as Xpand in the sequel.

Generating Multi-Variant Java Source Code Using Generic Aspects

Figure 1: Graph domain model annotated with features from the feature model seen in the upper left corner.

2.1 Necessity for Annotated

Multi-Variant Source Code

The example is based on an annotated Ecore model

for the Graph SPL. As depicted in Figure 1, the Graph

consists of Egdes and Nodes which are mandatory

features of the feature model placed in the upper left

corner of the ﬁgure. Edges might be Directed and/or

Weighted. Moreover, nodes might be Colored.

With state-of-the art MDPLE tools based on ne-

gative variability, so far, products are derived by

providing a feature conﬁguration, ﬁrst, and by ﬁlte-

ring the annotated multi-variant domain model after-

wards. Based on the ﬁltered model, (Java) source

code is generated resulting in single-variant source

code (SVSC). Having, for instance, only the featu-

res Edges and Nodes selected results in three classes.

The class Node contains a ﬁeld edges and a corre-

sponding ﬁeld nodes is included in the class Edge.

For both ﬁelds respective accessor methods are ge-

nerated. Since for the omnipresent Graph class only

the method stubs for the operations getNode() and

getEdge() are created, the engineer implements their

method bodies manually in the ﬁnal product. The

whole code, however, is completely unaware of fea-

tures and the manual modiﬁcations are unique to this

single product.

In the meantime, more products are derived, all

missing the two method bodies implemented in the

ﬁrst derived product. As the manual implementation

should be present in all products, the developer copy-

and-pastes the manual modiﬁcations to all other de-

rived products. Despite the increased effort – con-

tradicting the promise of increased productivity when

using MDPLE –, a high risk to forget one product or

to slightly modify the implementations inadvertently

remains.

This problem could be solved by generating the

MVSC ﬁrst and adding manual implementations

there. Although it is possible to generate the source

code including all variants from elements present in

the domain model, the default Ecore code generation

is not able to integrate annotations in the generated

text. A link to the feature(s) a single source code frag-

ment is realizing is missing. As a consequence, it is

not possible to derive products from this code base au-

tomatically. To do so, it would be necessary to have

the annotation belonging to a source code fragment

associated with the corresponding fragment. Please

note: This kind of problem can hardly be solved by

designing more detailed domain or feature models.

Even if behavior was modeled and source code for

method bodies was automatically derived, still typi-

cally manual extensions are required. If such exten-

sion was associated with a feature, it would be best

having it in all corresponding products automatically

upon derivation.

As deducted from this scenario, having annotated

MVSC, hence, provides the following beneﬁts:

• Products can be derived automatically from the

MVSC without generating a single-variant model

ﬁrst.

• Derived products may include manually added

source code fragments concerning them, increa-

sing the degree of automation and productivity.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

2.2 Consequences

In order to be beneﬁcial, we postulate some require-

ments on (text producing) MVMTs:

Reuse. Existing SVMT should not be meaningless

but integrated and ideally be reused as they are. This

is achieved by propagating annotations separately and

automatically. This approach offers the following ad-

vantages: First, the programmer does not have to le-

arn any new language construct. Second, the cog-

nitive level of the transformation does not increase.

Third, already achieved realizations are not meaning-

less but are integrated seamlessly.

Tracelink. The kind of annotations realized in the

input must be translated into a form understood by

the output which should happen orthogonally to the

reused SVMT. Having the links transferred in an ort-

hogonal step, strictly separates the concerns of trans-

forming the model and propagating the annotations.

Commutativity. The source code generated for a

model which was derived from a multi-variant dom-

ain model by specifying a feature conﬁguration

should be the same as the source code which results

from preprocessing the annotated MVSC by the same

conﬁguration. Deriving the source code from the

MVSC achieves the same goal but based on a higher

degree of automation (see Section 2.1).

Transformation Engine. Furthermore, an MVMT

engine is needed that fulﬁlls the following criteria:

• Generic: support any kind of variability represen-

tation as input and produce generic output based

on the reused transformation

• Reuse of: already present SVMTs.

On the whole, we postulate MVMTs which are

automatically executed based on the reuse of unchan-

ged SVMTs. Supporting commutativity is achieved

by propagating tracelinks orthogonally to the reused

SVMTs.

3 OVERVIEW

This section provides an overview on our solution to-

wards generating MVSC: SVMTs should be executed

as they are and augmented with annotations orthogo-

nally to the SVMT. In this work the source code pro-

duced by an M2T transformation should be annotated

Figure 2: Realization approach to an orthogonal variability

integration.

without changing the SVMT allowing to derive pro-

ducts from the multi-variant code base.

Figure 2 depicts our approach schematically: An

SVMT should be reused (step 1) and annotations

should be translated separately (step 2) into prepro-

cessor directives. Since the SVMT should not have to

be altered, the approach demands for an M2T trans-

formation language that generates artifacts or provi-

des mechanisms to work with orthogonally to the exe-

cuted base transformation. We have picked the M2T

language Xpand to serve this purpose because it al-

lows to adapt the behavior of existing model trans-

formations with an aspect-oriented approach. More

details on the language are given in the remainder of

this section.

As shown in the aforementioned ﬁgure, the an-

notation transfer relies on a generic implementa-

tion supporting arbitrary model transformations writ-

ten in Xpand: F2DMM annotations (explained in

Section 3.3) are transferred to the resulting source

code in form of preprocessor directives. As Java does

not support a preprocessor, the directives are transla-

ted into JavaDoc comments and will be processed by a

separate Eclipse plugin, which is roughly explained in

Section 3.2. Thus, source code fragments belonging

to a speciﬁc feature are embraced with comments in

the multi-variant Java source code resulting from the

SVMT.

Please note: The reused SVMT is single-variant

as it does not cover any variability information at all,

being unaware of the variability. Nevertheless, the in-

put domain model is multi-variant as it may reﬂect the

complete platform including all variants, based on the

principle of negative variability. However, the dom-

ain model elements are likewise unaware of the vari-

ants they correspond with. This information is cap-

tured orthogonally to the domain model in a sepa-

rate model, e.g., in form of F2DMM annotations (see

Section 3.3). Nevertheless, generating source code

from the multi-variant domain model in the SVMT re-

sults in MVSC including all modeled variants of the

input. The MVSC is unaware of the corresponding

Generating Multi-Variant Java Source Code Using Generic Aspects

features, too.

Altogether, with the provided solution it is possi-

ble to support the automatic MVSC generation for a

single-variant Xpand code generation written for an

Ecore-compliant metamodel. With the present solu-

tion the input models must store the annotations in

the F2DMM. However, for a different annotation re-

presentation a new advice could be written to support

other SPL tools.

3.1 Xpand

Xpand stems from the openArchitectureWare (oAW)

project where it serves as template-based M2T trans-

formation language. Extensive documentation can be

found in (Efftinge et al., 2004).

Xpand projects typically consist of templates, ex-

tensions and an MWE(2) workﬂow. In the templates

a DEFINE block speciﬁes how a metamodel element

is converted into text. In these blocks plain text can

be intermingled with other Xpand directives, e.g., the

FILE or EXPAND directives, where the ﬁrst one crea-

tes a ﬁle with the given path and the latter one calls

another DEFINE block. Moreover, complex instructi-

ons can be written in extensions which provide a sub-

set of the Xtend language. Additionally, extensions

may call Java methods that could be used for any in-

struction which is not (or only restrictively) expressi-

ble with Xtend.

A basic example of a text producing template is

shown in Listing 3.1: For all eClassiﬁers (l. 2) contai-

ned in an EPackage (l. 1) a ﬁle is created with the path

name returned from an extension call (l. 5). The text

in line 6 is written verbatim to the output except for

the extension call inside the French quotation marks.

The call returns a String containing the fully qualiﬁed

name of the respective package.

1 «DEFINE main FOR ecore :: EP a c k a g e »

2 «EXPAND cl FOREACH e C l a s sif i e r s »

3 «ENDDEFINE»

4 «DEFINE cl FOR e c ore :: E C l assi f i e r »

5 «FILE p a c k ageP a t h () + "/ " + n a me +

". java "»

6 package « pack a g e N ame ()»;

7 «ENDFILE»

8 «ENDDEFINE»

Listing 1: Example transformation generating ﬁles for

eClassiﬁers.

Most importantly for the present work, the lan-

guage allows to extend or rewrite template deﬁniti-

ons with an aspect-oriented component: advice tem-

plates deﬁne AROUND blocks specifying a genera-

ted element that they might (almost) arbitrarily al-

ter. Quite like a DEFINE statement, they ﬁrst state

a fully qualiﬁed element that should be modiﬁed and

second the type of this element. Wildcards (*) inside

the fully qualiﬁed name allow to scan different direc-

tories and/or to match arbitrary element types of DE-

FINE blocks.

Finally, MWE(2) workﬂows

are used to execute

the transformation. Workﬂows are given a name and

consist of different components. They are interpre-

ted as normal Java classes. When executing model

transformations, a workﬂow usually speciﬁes a rea-

der component which receives the path to the input

model/s and its/their metamodel/s and an Xpand ge-

nerator component. The latter expects the entry point

at the transformation (corresponding with the root ele-

ment of the input) and a path to which the output is

written. The generator component may receive advi-

ces which can be realized for templates and extensi-

ons alike.

In addition, Xpand allows to realize incremental

behavior with protected blocks in the templates and

by specifying the respective ﬁles in the workﬂow. Ho-

wever, this functionality was not examined in our pre-

sent contribution.

3.2 Java Preprocessor

In order to properly handle source code annotated

with preprocessor directives, some facility supporting

this task is needed. In the past, some approaches

have been proposed but they are mostly not compa-

tible with current Eclipse projects, e.g., Prebop

, or

require a manual adaptation of the build process, e.g.,

when using the Java Comment Preprocessor

. Thus,

we introduce a different preprocessor, which we de-

veloped in a model-driven way, realized as Eclipse

plugin. As Java does not support preprocessor directi-

ves, they are included in a non-invasive way into the

source code in the form of comments. The preproces-

sor is conﬁgurable with respect to

• the ﬁles that should be preprocessed by their ﬁle-

ending,

• the kind of comment signs that open and close the

directives inside these ﬁles,

• the names/signs for the opening, closing and pos-

sible branching directives.

Furthermore, the preprocessor expects a set of ﬂags

with boolean values which resemble a feature conﬁ-

guration. All source code fragments surrounded with

http://www.eclipse.org/Xtext/documentation/

306_mwe2.html

http://prebop.sourceforge.net/

https://github.com/raydac/java-comment-preprocessor

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

directives evaluating to false are turned into com-

ments by the preprocessor.

3.3 Feature to Domain Mapping Model

Last but not least, a representation for the variability

of models is needed. We choose the form provided by

the tool FAMILE (Buchmann and Schwägerl, 2012),

which is based on negative variability and relies on

the Eclipse Modeling Framework (EMF) (Steinberg

et al., 2009). While feature models capture the va-

riability, a single product is associated with one fea-

ture conﬁguration which sets the features to true or

false. Moreover, annotations are boolean expressions

over the features, called feature expressions(FE), and

can be assigned to arbitrary domain model elements.

They are stored in a separate model, the feature to

domain mapping model (F2DMM) which resembles

the structure of the domain model it belongs to and,

thus, stores an object mapping (OM) for all EObjects

contained in the domain-model. For example, every

instance of an EClass or an EOperation, etc., is refe-

renced by an OM and may be visible just for speciﬁc

features. Based on feature conﬁgurations, ﬁnal pro-

ducts are derived by ﬁltering all objects the FEs of

which evaluate to false.

4 REALIZING THE

MULTI-VARIANT SOURCE

CODE GENERATION

As mentioned before, this work aims at providing a

mechanism to augment the result of a single-variant

M2T transformation – in the present approach written

in Xpand – with annotations. Particularly, we pro-

pagate FEs stored in the separate mapping model of

the tool FAMILE (F2DMM) resulting in annotated

MVSC. We assume the Xpand SVMTs already exist.

They should be reused without any modiﬁcations.

For the solution two components are decisive: A

template containing the advice to modify the existing

SVMT and a second MWE(2) workﬂow executing the

workﬂow of the SVMT augmented with the provided

advice. Now details on both are illuminated.

4.1 Advice Template

First of all, the automatic transfer of annotations re-

quires a generic instruction to annotate source code

fragments related with an annotated model element.

The generated text should be surrounded with a com-

ment opening the IF preprocessor directive stating the

respective annotation and a second comment closing

the preprocessor directive after the generated text is

written to the output.

First, in order to regard any model element text

is generated for, the provided AROUND statement ex-

pects an arbitrary Object. Next, it searches the re-

spective object mapping in the F2DMM referencing

the domain model in which the given EObject is con-

tained. If the OM stores an FE, an opening and a

closing comment need to encompass the actual text

production of the SVMT.

Listing 4.1 depicts a simpliﬁcation of the re-

spective advice: By using wildcards in the AROUND

statement (l. 1), the following procedure is executed

for any Object text is generated for inside a ﬁle lo-

cated in a templates

folder. As FAMILE only sup-

ports Ecore-compliant domain models, EObjects are

the only elements, text is generated for. Thus, ﬁrstly,

the algorithm searches the corresponding OM (l. 2)

with the help of an extension call. The respective

function getOM examines the F2DMM, which is lo-

aded in the background upon the ﬁrst call of getOM.

It, then, returns the matching mapping. If the OM

contains an FE (l. 3), the actual text production is sur-

rounded by comments containing the FE (l. 4 - 7).

The comment is constructed in another function pro-

vided in the extensions (l. 4 and 7) and depends on the

fact whether the container of the object also owns an

FE. The instruction targetDef.proceed() (l. 6 and 10)

executes the original text production of the SVMT.

1 «AROUND t e m p l ates : : * : : * FOR Object»

2 «LET getOM (( E O b j ect ) this ) AS om»

3 «IF om . i s Se t F ea t u reE x p rS t r ()»

4 « g etO p e nin g C om m e n t ()»

5 // @ID : « getID ()»

6 « t a r g etDef . proceed ()»

7 « g etC l o sin g C om m e n t ()»

8 «ELSE»

9 // @ID : « getID ()»

10 « t a r g etDef . proceed ()»

11 «ENDIF»

12 «ENDLET»

13 «ENDAROUND»

Listing 2: Simpliﬁcation of the advice encompassing an ac-

tual text genreation.

By adding the comments, it is possible to relate

the text surrounded with comments to a speciﬁc fea-

ture and, hence, to inject the variability information

in the pure text. Note, that each element receives only

the FE it is associated with in the F2DMM. As there

Per convention, Xpand projects store all the text gene-

rating templates in a folder templates and extensions in a

folder extensions.

Generating Multi-Variant Java Source Code Using Generic Aspects

are no nested preprocessor directives by construction,

transitive dependencies are not reﬂected in the created

comment style. Up to now, we assume a valid feature

model and, moreover, prefer to put only the concrete

FE. In that way, the information remains which con-

crete feature a single element realizes.

Furthermore, in any case a unique ID is generated

for the EObject (l. 5 and 9) and put before the gene-

rated text. This way we keep a unique trace informa-

tion, which might be used to support later evolution

processes.

Listing 4.1 illustrates the comment style, for in-

stance for the ﬁeld weight of the class Edge from the

example shown in Section 2. First, the container ex-

pression (Edges) is closed (l. 1) and the actual expres-

sion Weighted is opened (l. 2) in the opening com-

ment. In the closing comment the actual preprocessor

directive is closed (l. 6) and the one of the container

is opened again (l. 7).

Closing and opening container expressions is ne-

cessary as nested directives are not supported with

the present approach: One closing JavaDoc comment

always closes all comments that were opened be-

fore. Hence, closing the comment originally associa-

ted with the EObject would also close the one of any

container, if it was still open. Therefore, if the con-

tainer owns an FE, its statement must be opened after

closing the one associated with the EObject. Addi-

tionally, it must be closed before opening the actual

comment because the preprocessor does not support

nested comments.

1 /

#ENDIF Edges

2 /

#IFDEF Weighted #

3 // @ID: _TACGEFc3Eeetfr4BhVYAxQ

4 p r otecte d int weight ;

6 /

#ENDIF Weighted

7 /

#IFDEF Edges #

Listing 3: Example of a ﬁeld annotated with JavaDoc com-

ments generated by our advice.

4.2 Workﬂow

The second necessary part to realize the annotations

is the workﬂows. As depicted in Figure 2, the Xpand

project providing the advice template calls the reused

SVMT. Thereby it adds the generic advice template

to the Xpand generator executed in the single-variant

workﬂow. Accordingly, the advice project provides a

workﬂow that executes the SVMT and adds the pre-

viously presented advice. Without the loss of gener-

ality

, technically, we assume that the single-variant

code generation is initiated by an MWE2 workﬂow

providing a slot to add an advice template. This slot

is ﬁlled with the generic Xpand advice project which,

ﬁnally, executes the single-variant workﬂow augmen-

ted with advices.

Summing it up, in order to execute the MVSC ge-

nerations, the source domain model must be provided

as input to the reused MWE2 workﬂow which is exe-

cuting the single-variant code generation. Alongside

for any EObject, text is generated for, the advice is

being called surrounding the text with the correspon-

ding comment.

5 EXAMPLES

To demonstrate the feasibility of the contributed ad-

vice, we present two independent transformations re-

spectively. The ﬁrst one produces Java source code

for annotated Ecore models, the second one produces

Java source code for annotated instances of the Java

MoDisco metamodel. MoDisco (Bruneliere et al.,

2010) is an extensible model-driven framework sup-

porting different use cases of software modernization.

It provides an Ecore-compliant metamodel that re-

sembles the Java AST and offers discoverers that, e.g.,

translate Java source code into valid instances of this

metamodel. The framework also includes an M2T en-

gine that converts such models back into Java source

code.

The transformations were partially reimplemen-

ted in Xpand for the purpose of this evaluation be-

cause the EMF and MoDisco code generators are im-

plemented in different template languages (JET and

Acceleo, respectively, both do not natively support

aspect-orientation). In addition, since we do not exa-

mine the incremental behavior of Xpand yet, the M2T

templates focus on the structural parts of the metamo-

dels and neglect, e.g., method bodies.

Below, we present how the outcome of the afo-

rementioned transformations is enriched with annota-

tions by our provided generic aspect. We pick one

Ecore class as example and illustrate the transforma-

tion process: Remember the class Edge, depicted in

Figure 3 on the left hand side which is visible when

the feature Edges is selected and which may have an

attribute weight (Weighted) and a source and target

node when feature Directed is selected or exactly two

nodes if it is not. We only show the generated inter-

face for space and simplicity reasons.

The procedure is quite similar for a simple MWE work-

ﬂow.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

Figure 3: Generated interface when applying the Xpand transformation without (1) and with (2) advices on the Edge class.

Ecore to Java Source Code. The ﬁrst transforma-

tion receives as input an annotated Ecore model of

the Graph SPL (Lopez-Herrejon and Batory, 2001).

The plain Xpand transformation creates source code

which partially resembles the default Ecore code ge-

neration: For instance, for every EClass an interface

and a class are created. Additionally, for the structural

features ﬁelds are included in the containing classes

and set- and get-method stubs in both, the interfaces

and classes.

Figure 3 shows the different outcome when ap-

plying the Xpand transformation without (1) and with

(2) advices. Applying the SVMT (1) on the multi-

variant edge class results in a class and an interface

where all modeled elements – independent of the as-

sociated features – are visible. The connection to the

features is lost.

Executing the same transformation with advices

(2), i.e., our provided second workﬂow, generates the

same source code but adds the annotations in form

of preprocessor directives. For instance, the methods

setWeight and getWeight are embraced with the "# IF-

DEF Weighted #" comment and the closing "# ENDIF"

comment.

In general, each element created in a DEFINE

block receives the ID corresponding with the EObject

it was created from. Moreover, if its associated OM

contains an FE, it is embraced with a preprocessor di-

rective mentioning the FE. Accordingly, while the at-

tribute name inside the edge class only receives its

corresponding ID, the other methods are additionally

embraced by preprocessor directives. Consequently,

the resulting source code is aware of all possible va-

riants and allows to associate manual modiﬁcations

with a feature.

Finally, products can be derived from the MVSC.

Figure 4 depicts the edge interface after the preproces-

sor was run on a conﬁguration that consists of nodes

with weighted edges: All code with deselected featu-

res is moved into JavaDoc comments, hence, making

it invisible in the resulting product

MoDisco to Java Source Code. In order to illus-

trate the same advice is able to annotate source code

generated for instances of different metamodels, we

additionally investigated an annotated Java MoDisco

model of the Graph SPL. The model discovered from

the source code resulting from the default Ecore code

generation serves as input to the second scenario. It

Still, the complete MVSC is part of a product to al-

low working in continuing steps with different conﬁgurati-

ons and possible modiﬁcations. To export only the visible

source code into a new project as standalone product would

not cause a problem.

Generating Multi-Variant Java Source Code Using Generic Aspects

Figure 4: The Edge interface after running the preprocessor

on the feature conﬁguration.

was annotated with an F2DMM containing similar

presence conditions as could be inferred from the an-

notated Ecore elements. A snippet of the annotated

Edge interface in the F2DMM tree perspective is dis-

played in Figure 5 respectively for the other elements.

Annotations associated with one element are written

verbatim behind the respective element in grey color.

In contrast to the Ecore model, in the Java model re-

sulting from discovering the source code, for exam-

ple, the accessor methods created for a ﬁeld are sepa-

rate model elements. Accordingly, they are associated

with distinct OMs, that, however, carry the same FEs

in the F2DMM.

On the left of Figure 6, the annotated source code

resulting from executing the SVMT with our provi-

Figure 5: Annotated MoDisco Edge interface.

Figure 6: The annotated Edge interface after the MVMT

(left) and after running the preprocessor (right).

ded Xpand advice is placed. The source code almost

equals the one generated with the Xpand Ecore code

generation (bottom of Figure 3). However, the Xpand

implementation generating Java from Ecore in the

ﬁrst scenario does not include all details of the Ecore

standard code generation. Rather it uses the standard

Java libraries (e.g., using an ArrayList instead of the

EList). As a consequence, the discovered model re-

sulting from the default Ecore code generation (which

is input to this scenario) includes EMF-speciﬁc types

which are, thus, included in the text produced with the

MoDisco to Java Xpand transformation.

Comparing the Outcome. As the examples above

demonstrate, one and the same advice presented in

Section 4 is sufﬁcient to correctly translate FEs into

preprocessor directives and to place them around the

corresponding generated text. Thus, the methods cre-

ated for the ﬁeld weight in the interface Edge are gi-

ven the corresponding comment. Similarly, the met-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

hods for source and target are only present in Directed

graphs. Some small differences are visible. For in-

stance, with the MoDisco model as input, each acces-

sor method receives a separate comment instead of

commenting them pairwise. In addition, their para-

meters are given own comments. This is due to the

fact, that the MoDisco model contains a MethodDe-

claration for each operation and handles the parame-

ters as unique EObjects. As they are all considered as

EObjects, the F2DMM foresees a mapping for each

of these elements and, accordingly, they may contain

separate FEs that are added with the contributed ad-

vice. In contrast, in Ecore the corresponding mapped

object is a structural feature (one EObject) for which

two methods with a ﬁxed style are created in one DE-

FINE block.

Finally, we like to stress that applying the same

feature conﬁguration results in (almost) the same pro-

duct. Some differences remain, like having an EList

instead of an ArrayList as container for multi-valued

structural features. Nonetheless, the same functiona-

lity is achieved.

Conclusion. The examples showed that it is possi-

ble to automatically annotate source code with our

multi-variant M2T Xpand transformation by reusing

SVMTs. Our contribution aims at providing a gene-

ric mechanism to propagate annotations into source

code, which was demonstrated for two transformati-

ons based on considerably different metamodels. The

success of transferring the annotations, however, de-

pends on whether the text for some EObject is cre-

ated in a separate DEFINE statement. If this is the

case, we can deduce that all metamodels annotated

with FEs could be supported. Accordingly, the reused

SVMT must adhere to some (standard) Xpand coding

conventions. On the whole, our contributed generic

advice allows to generate multi-variant source code

from which different products can be derived.

6 RELATED WORK

The present work realizes an M2T MVMT automati-

cally propagating annotations from models based on

negative variability to source code. Regarding such

transformations, the ﬁeld of comparable work is po-

pulated rather sparsely.

In (Greiner et al., 2017) the authors reuse exis-

ting single-variant M2M transformations and transfer

annotations automatically, based on evaluating a per-

sisted trace and the execution model, in a second step

orthogonally to the reused model transformation. We

take up the idea of reusing existing model transfor-

mations but add annotations with the help of aspects.

Thus, we do not have to evaluate the transformation

artifacts a posteriori and do not rely on a persisted

trace. Rather we integrate annotations based on the

capabilities of the transformation language and pro-

vide a generic implementation that, however, also al-

lows to reuse existing transformations without modi-

fying them.

Another approach to realize MVMTs lifts the

transformation (Salay et al., 2014). This work pro-

poses an algorithm for graph-based transformations

which generates an MVMT where the single-variant

rules, e.g., their application conditions, are interpre-

ted with variability semantics. The approach was not

only successfully applied to in-place graph transfor-

mations but also to out-place M2M transformations

with a graph-oriented DSL that had to be slightly mo-

diﬁed for this purpose (Famelis et al., 2015). Instead

of changing the execution semantics of the SVMT,

our approach executes the single-variant transforma-

tion without adaptations. We rather exploit the exis-

ting capabilities of the engine without changing the

SVMT to propagate annotations seamlessly. Further-

more, we produce source code instead of models as

it increases the degree of automation to deliver a ﬁnal

product. Manual modiﬁcations required in the anno-

tated MVSC may be automatically integrated in all

products in that way.

In contrast, in (Strüber and Schulz, 2016) the

transformation rules themselves are variability-aware.

Although the proposed tool allows ﬁltered editing on

the rules which reduces the cognitive complexity, it is

necessary to consider variability in the transformation

rules themselves. Moreover, the tool solves different

problems, e.g., allowing to transform in between plat-

form independent and platform speciﬁc models in the

context of Model-Driven Architecture (MDA) (Mellor

et al., 2004).

In (Sijtema, 2010) the authors are, likewise, chan-

ging the transformation rules by introducing new syn-

tax to ATL transformations. The new language con-

structs are maintained in higher-order transformati-

ons. Again, this approach addresses variability in

transformations rather than in models.

Technically, Xpand has already been used to en-

rich existing transformations with source code frag-

ments belonging to different features (Voelter and

Groher, 2007). In contrast to our contribution, a diffe-

rent approach is applied. As with aspect-oriented ap-

proaches, each feature that could be added to a com-

mon code base is realized in a separate aspect and pro-

vided in a second workﬂow. We, instead, provide only

one single aspect that annotates source code contai-

Generating Multi-Variant Java Source Code Using Generic Aspects

ning realizations for all features. Thus, our approach

is tailored for negative rather than for positive varia-

bility.

On the whole, our approach is unique with re-

spect to the following aspects: First, it addresses

M2T transformations rather than M2M transformati-

ons. Second, unlike in (Strüber and Schulz, 2016; Si-

jtema, 2010) the approach deals with multi-variant in-

put rather than with multi-variant transformation spe-

ciﬁcations. Finally, unlike in (Salay et al., 2014; Grei-

ner et al., 2017), the already existing functionality of

the transformation engine is exploited, relying on as-

pects which extend reused transformation deﬁnitions

in a modular way.

7 CONCLUSION AND FUTURE

WORK

Summing it up, the presented approach provides an

automated propagation of variability annotations by

reusing SVMTs. In particular, we transfer FEs to

the MVSC generated from Xpand templates. To the

best of our knowledge, it is the ﬁrst approach suppor-

ting the automated creation of annotated multi-variant

source code by reusing (existing) single-variant M2T

transformations. Thus, with the present work ﬁnal

products can be derived from multi-variant source

code instead of from single-variant models. This, in

turn, lays the foundation to automatically integrate

manual modiﬁcations to the source code in all deri-

ved products. Previously, this had to be accomplis-

hed with laborious handwork on every single product

which leads to errors and an increased effort that con-

tradicts the paradigm of MDPLE of increased pro-

ductivity.

Future work investigates the incremental behavior

of Xpand transformations when altering it with ad-

vices and considers to propagate manual changes in

a backward transformation to the corresponding mo-

del elements. Moreover, the combination of FEs, es-

pecially when considering backward transformations,

should be examined.

REFERENCES

Bruneliere, H., Cabot, J., Jouault, F., and Madiot, F. (2010).

MoDisco: a generic and extensible framework for mo-

del driven reverse engineering. In Proceedings of

the IEEE/ACM International Conference on Automa-

ted software engineering (ASE 2010), pages 173–174,

Antwerp, Belgium.

Buchmann, T. and Schwägerl, F. (2012). FAMILE: tool

support for evolving model-driven product lines. In

Störrle, H., Botterweck, G., Bourdellès, M., Kolovos,

D., Paige, R., Roubtsova, E., Rubin, J., and Tolvanen,

J.-P., editors, Joint Proceedings of co-located Events

at the 8th ECMFA, CEUR WS, pages 59–62, Building

321, DK-2800 Kongens Lyngby. Technical University

of Denmark (DTU).

Efftinge, S., Friese, P., Hase, A., Hübner, D., Kadura, C.,

Kolb, B., Köhnlein, J., Moroff, D., Thoms, K., Völter,

M., et al. (2004). Xpand documentation. Technical re-

port, Technical report, 2004-2010.(cited on page 64).

Famelis, M., Lúcio, L., Selim, G., Di Sandro, A., Salay, R.,

Chechik, M., Cordy, J. R., Dingel, J., Vangheluwe, H.,

and Ramesh, S. (2015). Migrating automotive product

lines: a case study. In International Conference on

Theory and Practice of Model Transformations, pages

82–97. Springer.

Greiner, S., Schwägerl, F., and Westfechtel, B. (2017). Re-

alizing multi-variant model transformations on top of

reused ATL speciﬁcations. In Pires, L. F., Ham-

moudi, S., and Selic, B., editors, Proceedings of the

5th International Conference on Model-Driven Engi-

neering and Software Development (MODELSWARD

2017), pages 362–373, Porto, Portugal. SCITEPRESS

Science and Technology Publications, Portugal.

Jouault, F., Allilaire, F., Bézivin, J., and Kurtev, I. (2008).

ATL: A model transformation tool. Science of Com-

puter Programming, 72:31–39. Special Issue on Ex-

perimental Software and Toolkits (EST).

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E.,

and Peterson, A. S. (1990). Feature-oriented dom-

ain analysis (FODA) feasibility study. Technical Re-

port CMU/SEI-90-TR-21, Carnegie-Mellon Univer-

sity, Software Engineering Institute.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lo-

pes, C., Loingtier, J.-M., and Irwin, J. (1997). Aspect-

oriented programming. ECOOP’97–Object-oriented

programming, pages 220–242.

Lopez-Herrejon, R. E. and Batory, D. S. (2001). A stan-

dard problem for evaluating product-line methodolo-

gies. In Proceedings of the Third International Confe-

rence on Generative and Component-Based Software

Engineering, GCSE ’01, pages 10–24, London, UK.

Springer.

Mellor, S. J., Kendall, S., Uhl, A., and Weise, D. (2004).

MDA Distilled. Addison Wesley Longman Publishing

Co., Inc., Redwood City, CA, USA.

Object Management Group (2008). MOF Model to Text

Transformation Language, Version 1.0. Object Mana-

gement Group, Needham, MA, formal/2008-01 edi-

tion.

Pohl, K., Böckle, G., and van der Linden, F. (2005). Soft-

ware Product Line Engineering: Foundations, Princi-

ples and Techniques. Springer, Berlin, Germany.

Salay, R., Famelis, M., Rubin, J., Sandro, A. D., and Che-

chik, M. (2014). Lifting model transformations to pro-

duct lines. In 36th International Conference on Soft-

ware Engineering, ICSE ’14, Hyderabad, India - May

31 - June 07, 2014, pages 117–128.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

Sijtema, M. (2010). Introducing variability rules in atl

for managing variability in mde-based product lines.

Proc. of MtATL, 10:39–49.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,

E. (2009). EMF Eclipse Modeling Framework. The

Eclipse Series. Addison-Wesley, Boston, MA, 2nd

edition.

Strüber, D. and Schulz, S. (2016). A Tool Environment

for Managing Families of Model Transformation Ru-

les, pages 89–101. Springer International Publishing,

Cham.

Voelter, M. and Groher, I. (2007). Handling variability in

model transformations and generators. In 7th OOP-

SLA Workshop on Domain-Speciﬁc Modeling.

Völter, M., Stahl, T., Bettin, J., Haase, A., and Hel-

sen, S. (2006). Model-Driven Software Development:

Technology, Engineering, Management. John Wiley

& Sons.

Generating Multi-Variant Java Source Code Using Generic Aspects