A Comparison of Mechanisms for Integrating Handwritten and

Generated Code for Object-Oriented Programming Languages

Timo Greifenberg

, Katrin Hölldobler

1∗

, Carsten Kolassa

, Markus Look

Pedram Mir Seyed Nazari

, Klaus Müller

, Antonio Navarro Perez

, Dimitri Plotnikov

, Dirk Reiss

Alexander Roth

, Bernhard Rumpe

, Martin Schindler

and Andreas Wortmann

Software Engineering, RWTH Aachen University, Aachen, Germany

Institute for Building Services and Energy Design, TU Braunschweig, Braunschweig, Germany

Keywords:

Code Generation, Handwritten Code Integration, Model-driven Development.

Abstract:

Code generation from models is a core activity in model-driven development (MDD). For complex systems

it is usually impossible to generate the entire software system from models alone. Thus, MDD requires

mechanisms for integrating generated and handwritten code. Applying such mechanisms without considering

their effects can cause issues in projects with many model and code artifacts, where a sound integration for

generated and handwritten code is necessary.

We provide an overview of mechanisms for integrating generated and handwritten code for object-oriented

languages. In addition to that, we deﬁne and apply criteria to compare these mechanisms. The results are

intended to help MDD tool developers in choosing an appropriate integration mechanism.

1 INTRODUCTION

Model-driven development (MDD) (Kleppe et al.,

2003) pursues the vision to create complex software

systems from abstract models by transforming these

into concrete implementations (France and Rumpe,

2007). However, the prevailing conjecture is that de-

riving a non-trivial, complete implementation from

models alone is not feasible (Wile, 2003). Current

MDD techniques thus require tool developers to in-

tegrate generated and handwritten code. To per-

form this code integration, various mechanisms can

be used. However, there is no best integration mech-

anism which should always be used. Instead, it de-

pends on the context in which this code integration

has to be carried out and on the concrete requirements

which integration mechanisms are best suited to be

applied.

To support MDD tool developers in selecting in-

tegration mechanisms, we examined existing mech-

anisms to integrate generated and handwritten code

for object-oriented programming (OOP) languages.

Additionally, we created a set of criteria focusing

∗

K. Hölldobler is supported by the DFG GK/1298 Algo-

Syn.

on different properties of code integration mech-

anisms to assess and compare these mechanisms.

The presented criteria are based on a decade of

experiences in object-oriented software engineering

and MDD research (Rumpe, 2011; Rumpe, 2012),

code generator development and code integration re-

search (Rumpe et al., 2010; Schindler, 2012), and

experiences with MDD processes within various do-

mains including automotive (Grönniger et al., 2008),

cloud computing (Navarro Pérez and Rumpe, 2013),

robotics (Ringert et al., 2013), and smart build-

ings (Kurpick et al., 2012).

We introduce eight handwritten code integration

mechanisms and evaluate each with respect to our cri-

teria. Moreover, we show strengths and weaknesses

of each integration mechanism in the evaluation re-

sults. By means of this, we seek to increase the

comparability between the integration mechanisms.

In particular, this overview is intended to be used

by MDD tool developers to ﬁnd a proper integration

mechanism on a case-by-case basis.

Please note, that the list of integration mechanisms

and evaluation criteria presented in this paper does not

claim to be complete. However, if further integration

mechanisms need to be compared or the mechanisms

Greifenberg T., Hölldobler K., Kolassa C., Look M., Mir Seyed Nazari P., Müller K., Navarro Perez A., Plotnikov D., Reiss D., Roth A., Rumpe B., Schindler

M. and Wortmann A..

A Comparison of Mechanisms for Integrating Handwritten and Generated Code for Object-Oriented Programming Languages.

DOI: 10.5220/0005239700740085

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 74-85

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

need to be evaluated with respect to additional evalu-

ation criteria, this paper can be used as a basis easily.

In summary, the contributions of this paper are:

• A list of evaluation criteria for code integration

mechanisms.

• A collection of mechanisms to integrate generated

and handwritten code.

• An evaluation of the integration mechanisms

based on the list of evaluation criteria.

In the remainder, we introduce criteria to assess

the different integration approaches (Section 2). The

code integration approaches are separated into mecha-

nisms based on speciﬁc concepts in programming lan-

guages (Section 3) and mechanisms free of such re-

quirements (Section 4). Subsequently, we summarize

and discuss the evaluation results (Section 5). After

that we elaborate on related work (Section 6) before

we conclude this contribution (Section 7).

2 EVALUATION CRITERIA

The following criteria concern different properties of

integration mechanisms and aim at helping develop-

ers in selecting a suitable mechanism. These crite-

ria are based on existing literature (Stahl and Völter,

2006; Pietrek et al., 2007), best practices in software

development (Parnas, 1972; Gamma et al., 1995), and

our experience (Rumpe, 2011; Grönniger et al., 2008;

Rumpe et al., 2010; Kurpick et al., 2012; Rumpe,

2012; Schindler, 2012; Navarro Pérez and Rumpe,

2013; Ringert et al., 2013). This list does not claim

to cover all aspects of handwritten code integration.

Nonetheless, it can be used as an initial list of crite-

ria which can be adapted to ﬁt personal needs. The

presented criteria are not weighted on purpose since a

weighting is highly subjective and also tailored to an

application scenario, which is not intended.

C1: Separation of Generated and Handwritten

Code. - Can generated and handwritten code be sep-

arated into different ﬁles?

Separation of concerns is an essential design prac-

tice in software development (Parnas, 1972) and has

been proposed as a criterion to evaluate integration

mechanisms for handwritten code by (Stahl and Völ-

ter, 2006; Pietrek et al., 2007). One crucial beneﬁt of

separating generated and handwritten code into dif-

ferent ﬁles is that it can be ensured that the generator

does not overwrite handwritten code. In case of mix-

ing generated and handwritten code in one ﬁle, the

handwritten code might not always be preserved.

C2: Support for Overriding Generated Parts. -

Can developers add handwritten parts that are used

instead of particular generated parts?

Depending on the developer’s requirements it can be

necessary to adapt particular parts of the generated

functionality. This can be done by integrating hand-

written code that reﬁnes these parts. A beneﬁt of such

handwritten code reﬁnements is that the code gener-

ator does not have to be changed to ﬁt different re-

quirements.

C3: Extendability of the Generated Interfaces.

- Can the generated interfaces be extended with hand-

written methods?

Hiding implementation details is accepted as com-

mon practice in software development (Parnas, 1972;

Gamma et al., 1995). Accordingly, we assume that

functionality of the generated system is provided to

developers through dedicated generated interfaces

and that the system’s functionality is only accessed

by using these. Obviously, these generated interfaces

are oblivious to handwritten code. Consequently, the

generated interfaces need to be extended to allow

access to handwritten functionality.

C4: Independence of Handwritten Code at

Generation-time. - Is the generator independent of

the existence of handwritten code at generation-time?

In some handwritten code integration mechanisms the

generated code needs to be adapted if handwritten

code is present. In this case the handwritten code

is processed by the generator and the generated code

is adapted accordingly. For instance, the handwritten

code is merged into the generated code and one arti-

fact is produced. If this functionality is not provided

by the generator framework, a generator developer

has to extend the generator with such functionality.

This additional effort might not be desired and can be

avoided by choosing a generator framework with sup-

port for handling handwritten code. However, then

the choice of an integration mechanism inﬂuences the

choice of the generator framework. This is not always

feasible.

C5: Independence of Additional OOP Language

Constructs. - Can the integration mechanism be re-

alized using only default OOP language constructs?

Some of the existing handwritten code integration

mechanisms are tailored to a particular type of OOP

language that provides speciﬁc language constructs.

Consequently, such integration mechanisms are re-

stricted to generators that generate code in one of

these languages. The beneﬁt of handwritten integra-

tion mechanisms using default OOP language con-

structs is that no additional tooling is required and the

AComparisonofMechanismsforIntegratingHandwrittenandGeneratedCodeforObject-OrientedProgramming

Languages

generator is not tailored to a speciﬁc type of language.

The following language constructs are regarded as the

default OOP language constructs in this work: (ab-

stract) classes, inheritance, interfaces, object creation

facility and message-passing capability. Except for

interfaces this understanding complies with (Eliens,

1994). We are aware that not all OOP languages pro-

vide the concept of interfaces but interfaces can be

realized using classes with empty method bodies and

inheritance.

3 INTEGRATION MECHANISMS

BASED ON LANGUAGE

CONCEPTS

In this section, we present a catalog of integration

mechanisms that presuppose certain concepts in the

target language, for instance, inheritance known from

object-oriented programming. Each presented mech-

anism is described and evaluated with the following

scenario:

Assume the input model for the code generator

is an UML class diagram (CD) containing the class

NotePad. As CDs do not model class behavior, im-

plementations of NotePad methods can be developed

manually and the resulting handwritten code needs to

be integrated with the code generated for NotePad.

The same problems arise whenever modeling lan-

guages do not support modeling of all aspects of a

system and these parts have to be developed manu-

ally. The mechanisms presented in the remainder of

this publication are not limited to CDs and a particu-

lar type of code generation. We only use CDs to give

an illustrative example.

3.1 Generation Gap

The generation gap mechanism (Vlissides, 1998;

Stahl and Völter, 2006; Fowler, 2010) assumes that

an interface and a default implementation are gener-

ated for each class in the input model. For instance,

the interface NotePad and the default implementa-

tion NotePadBaseImpl are generated for the class

NotePad. Manual extensions of speciﬁc methods or

behavior different from the default implementation

are deﬁned in the handwritten class NotePadImpl.

Figure 1 depicts this pattern for the class NotePad.

Please note, that here and in the following «gc» de-

notes generated code and «hc» denotes handwritten

code.

In this case, NotePadImpl is the implementa-

tion that will be used by both the generated code as

«interface»

NotePad

NotePadBaseImpl

«gc»

NotePadImpl

«hc»

Figure 1: Generation gap pattern for the NotePad Example.

well as manually written code that uses the interface

NotePad.

Please note, that the generation gap mechanism re-

quires developers to create the handwritten class, no

matter whether handwritten code is inserted into that

class or not. In projects in which handwritten exten-

sions are rarely needed, this leads to bloated projects

with an unnecessary high number of artifacts.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. This criterion holds by deﬁnition of

the pattern, as the handwritten code has to be stored

in separate classes.

C2: Support for Overriding Generated Parts. Ful-

ﬁlled. The possibility to override generated methods

is a crucial feature of the pattern.

C3: Extendability of the Generated Interfaces.

Unfulﬁlled. This approach does not provide means to

reﬂect added methods in the generated interface. The

extended generation gap mechanism (see Section 3.2)

addresses this issue.

C4: Independence of Handwritten Code at

Generation-time.

Fulﬁlled. Whether or what handwritten code exists

does not inﬂuence the code generation in any way.

C5: Independence of Additional OOP Language

Constructs. Fulﬁlled. This mechanism does not re-

quire additional OOP language constructs.

3.2 Extended Generation Gap

A mechanism that addresses two disadvantages of the

basic generation gap mechanism (see Section 3.1) -

the inability to extend the generated interface and the

necessity to create an implementation class - is the ex-

tended generation gap mechanism. Since this mecha-

nism has been developed for our particular needs, its

name is not a well-known term in MDD.

The ﬁrst disadvantage is addressed by allowing to

add a handwritten interface on top of the generated

interface, as shown in Figure 2. As the generated

interface NotePad extends the handwritten interface

NotePadBase, all methods added to NotePadBase

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

«interface»

NotePad

NotePadBaseImpl

«gc»

«interface»

NotePadBase

«hc»

NotePadImpl

«hc»

Figure 2: Extended generation gap pattern with an addi-

tional handwritten Interface.

are also available when accessing NotePad. However,

developers do not have to add this handwritten inter-

face. Instead, the generator checks at generation-time

whether it exists. If it does exist, the generated in-

terface will extend the handwritten interface. Conse-

quently, the generator needs to be executed again after

adding a handwritten interface to reﬂect this change in

the generated code.

When a developer adds a handwritten interface,

the handwritten implementation class (NotePadImpl

in Figure 2) has to be provided as well. If no hand-

written interface is present, the generator generates a

concrete class NotePadBaseImpl by default and an

additional implementation class does not have to be

added by developers. In this way, developers are not

forced to integrate their own implementation class.

However, if a developer adds the handwritten class

NotePadImpl, which has to extend the generated base

class NotePadBaseImpl, this class is used in the gen-

erated code and NotePadBaseImpl becomes abstract.

This integration of handwritten code requires the gen-

erator to be executed again, as it checks at generation-

time whether developers added their own implemen-

tation classes.

Other variations of the generation gap mechanism

are possible. For instance, assuming that a handwrit-

ten interface always exists. A detailed discussion is

neglected because the variations are very similar and,

as shown in the example, differ in technical details.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. See Section 3.1.

C2: Support for Overriding Generated Parts. Ful-

ﬁlled. See Section 3.1.

C3: Extendability of the Generated Interfaces.

Fulﬁlled. The API of the generated class can be

extended easily by adding the handwritten interface

NotePadBase which is extended by the generated in-

terface NotePad. Thus, method signatures which are

added to the handwritten interface are also available

in the generated one. The actual implementations of

these methods have to be added to the handwritten

implementation class NotePadImpl.

C4: Independence of Handwritten Code at

Generation-time. Unfulﬁlled. The generator has

to check whether a handwritten interface or a hand-

written implementation class was introduced, as this

inﬂuences the structure of the generated code.

C5: Independence of Additional OOP Language

Constructs. Fulﬁlled. See Section 3.1.

3.3 Delegation

Delegation is a pattern of object composition in

object-oriented programming. In essence, the pattern

consists of two objects taking the roles of one delega-

tor and one delegate, respectively. The delegator del-

egates parts of its functionality to the delegate by in-

voking methods of the delegate. To this end, the dele-

gate provides an interface declaring the method signa-

tures that can be invoked. Figure 3 gives an overview

of the objects and relationships involved. Here,

NotePad is the delegator and NotePadDelegateImpl

is the delegate implementing the methods deﬁned in

the NotePadDelegate interface.

«interface»

NotePadDelegate

NotePad

«gc»

NotePad-

DelegateImpl

«hc»

«creates»

acts as delegator

Figure 3: Delegation pattern requires a delegator for regard-

ing handwritten implementations.

The delegator is responsible for instantiating the

delegate. In this case, NotePadDelegateImpl is the

implementation that will be used by both the gener-

ated code as well as manually written code that uses

the interface NotePadDelegate.

The relationship between the delegator and its del-

egate can be unidirectional or bidirectional. In the for-

mer case, the delegate has no knowledge of its delega-

tor. All interaction takes place via its method param-

eters and return values. In the latter case, the delegate

has a reference to its delegator and may respond to

delegated tasks by invoking methods on its delegator.

In any case the delegator is in control and initiates

all interactions. The delegator can choose to keep the

same delegate instance for subsequent delegations or

to use a new instance for every single delegation.

In essence, the purpose of delegation is to out-

source functionality to a distinct object with an ex-

plicit interface speciﬁc to this functionality. This pur-

AComparisonofMechanismsforIntegratingHandwrittenandGeneratedCodeforObject-OrientedProgramming

Languages

pose makes delegation naturally applicable to the in-

tegration of handwritten and generated code. The

roles of the delegators are taken by generated classes

while the roles of the delegates are taken by handwrit-

ten classes. All functionality that cannot be generated

is delegated to the handwritten delegates. The dele-

gate interfaces, thus, are well-deﬁned and distinct in-

terfaces between generated and handwritten code. It

can be generic and handwritten or speciﬁc and gen-

erated. The choice depends on whether the delegated

functionality depends on the model or not. For in-

stance, to delegate the implementation of method sig-

natures in class diagrams to a delegate, it is appro-

priate to generate the delegate interface based on the

method signatures deﬁned by the CD.

In general, delegation provides a higher degree of

encapsulation and cohesion compared to alternative

patterns. Moreover, it avoids inheritance in handwrit-

ten classes since delegates only have to implement an

interface. In programming languages without support

for multiple inheritance delegation allows developers

to use inheritance with handwritten classes.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. The pattern separates generated

and handwritten code by putting them into different

classes and interfaces.

C2: Support for Overriding Generated Parts. Un-

fulﬁlled. In this mechanism, only designated delega-

tors can be implemented to provide handwritten code.

It is not possible to override other generated parts.

C3: Extendability of the Generated Interfaces.

Unfulﬁlled. The generated interface can be extended

by subinterfaces and concrete delegators according

for the extended subinterface. However, the generated

delegator is not aware of these extensions.

C4: Independence of Handwritten Code at

Generation-time. Fulﬁlled. The existence of hand-

written delegate classes does not inﬂuence the code

generation.

C5: Independence of Additional OOP Language

Constructs. Fulﬁlled. The default OOP language

constructs sufﬁce to implement this mechanism.

Alternatives. The cardinalities of the delegation re-

lationship are not necessarily restricted. Thus, an im-

plementation of the pattern may associate one delega-

tor with exactly one delegate, or one delegator with

many delegates, or many delegators with one del-

egate. The choice between these variants depends

heavily on whether the delegate is stateful or state-

less. Stateless delegates can generally be shared by

many delegators and do not need to be instantiated re-

peatedly. Moreover, combinations of delegators and

delegates can be made with different combinations of

classes for both roles. For instance, a general purpose

delegate may be appropriate for different classes of

delegators.

3.4 Include Mechanism

Include mechanisms are based on dedicated language

constructs which allow to deﬁne that a certain ﬁle

should be included into another ﬁle at a speciﬁc point.

This idea can be easily used to integrate generated and

handwritten ﬁles as either a generated ﬁle includes

handwritten ﬁles (see Figure 4) at designated places

or vice versa. In general, the effect of using an in-

clude statement is equivalent to injecting the content

of the included ﬁle to the corresponding location in

the including ﬁle. Speciﬁc languages may offer in-

clude mechanisms with different meanings, but this

will not be discussed in the following as the focus is

on the general idea of include mechanisms.

NotePad

include

part

«gc»

«hc»

Figure 4: The include mechanism adds include statements

to the generated ﬁle to consider handwritten artifacts.

By including handwritten ﬁles in generated ﬁles,

the generator can deﬁne the required structure of the

ﬁles and developers merely need to introduce selected

handwritten ﬁles, which are included properly with-

out the developer having to worry about it. This is ad-

vantageous if developers should not be able to deviate

from this generated structure, as they can only pro-

vide the handwritten ﬁles which are included. Thus,

developers are guided in which ﬁles to provide. On

the other hand, if developers need more ﬂexibility and

should be able to deviate from such a generated struc-

ture, including generated ﬁles in handwritten ﬁles is

more appropriate. This variant is, of course, accom-

panied by the risk that developers forget to include the

proper generated ﬁles at the proper places.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. No matter whether generated ﬁles

include handwritten ﬁles or vice versa, generated and

handwritten parts are separated into different ﬁles.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

C2: Support for Overriding Generated Parts. Un-

fulﬁlled. It is not possible to integrate handwrit-

ten code which is used instead of generated code as

handwritten code can only be included and, therefore,

added.

C3: Extendability of the Generated Interfaces.

Conditionally fulﬁlled. To fulﬁll this criterion, a pro-

gramming language has to allow include statements

inside of interfaces to extend the signature. Even

though we are not aware of a language that supports

this, the concept itself does not forbid it. Therefore

this criterion might be fulﬁlled, depending on the spe-

ciﬁc target language.

C4: Independence of Handwritten Code at

Generation-time. Fulﬁlled. The generation of

the include functionality does not depend on the

existence of handwritten code.

C5: Independence of Additional OOP Language

Constructs. Unfulﬁlled. The mechanism requires in-

clude constructs which do not belong to the default

OOP language constructs.

3.5 Partial Classes

Partial classes facilitate splitting class implementa-

tions into several source code ﬁles. These parts

are merged in a pre-compilation phase. The result

contains the union of all methods, ﬁelds and super

types of all its partial deﬁnitions. In contrast to

aspect-oriented programming (see Section 3.6), par-

tial classes are concerned with only one class rather

than multiple.

The partial classes mechanism suits well for inte-

grating handwritten and generated code. Each gener-

ated partial class can be extended by adding handwrit-

ten code in its own partial class in a separate source

ﬁle. The resulting generated and handwritten code

is integrated automatically by merging them. This

merging can either be done by applying naming con-

ventions, i.e., partial classes with the same name are

merged, or by explicit notations. How and which par-

tial classes are merged is deﬁned by the used lan-

guage.

The CD in Figure 5 illustrates the partial class

mechanism. In this case, the generated code is

stored in the partial class NotePadBaseImpl and the

handwritten code is stored in a separate partial class

NotePadBaseImpl.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. The handwritten and generated par-

«partial»

NotePadBaseImpl

«gc»

«partial»

NotePadBaseImpl

«hc»

«interface»

NotePad

«gc»

Pre-compiler

NotePadBaseImpl.java

Figure 5: Partial classes mechanism merges the handwritten

and the generated implementation to one single artifact.

tial classes can be located in different source code

ﬁles.

C2: Support for Overriding Generated Parts.

Conditionally fulﬁlled. In general, the partial classes

mechanism does not forbid to override methods’ im-

plementations. However, depending on the used pro-

gramming language that supports partial classes, this

criterion may not be fulﬁlled.

C3: Extendability of the Generated Interfaces.

Conditionally fulﬁlled. The concept of the partial

classes mechanism can be applied to interfaces, too.

Thus, the additional method signatures can be added

to the handwritten partial interface which is merged

with the generated partial interface. However, if a re-

alization of the partial class mechanism supports par-

tial classes but not partial interfaces, this criterion is

not fulﬁlled.

C4: Independence of Handwritten Code at

Generation-time. Fulﬁlled. Handwritten code does

not have to exist at generation-time, because its

existence does not inﬂuence the code generation

process. Handwritten code only has to be available

when the pre-compiler merges the generated and

handwritten code.

C5: Independence of Additional OOP Language

Constructs. Unfulﬁlled. This mechanism requires

support for partial classes which is not regarded as a

default OOP language construct in this work.

3.6 Aspect-Oriented Programming

Aspect-oriented programming (AOP) (Kiczales et al.,

1997) addresses crosscutting concerns - functionality

or features scattered across several classes causing du-

plication - by encapsulating duplicated code in one

place. Although integrating handwritten code with

generated code does not necessarily deal with cross-

cutting concerns, AOP can be used for this integra-

AComparisonofMechanismsforIntegratingHandwrittenandGeneratedCodeforObject-OrientedProgramming

Languages

tion (Schindler, 2012). One advantage in this con-

text is that the generated code does not need to offer a

speciﬁc architecture to be extendable by handwritten

code. Instead, the handwritten code is added by so

called aspects.

An aspect reacts to a predeﬁned event (pointcut)

during the program execution. Such a predeﬁned

event can be, for instance, a method call of a speciﬁc

method in a speciﬁc class. The action that is executed

when a pointcut is reached is implemented in an ad-

vice. Such an advice can be executed before, after or

instead of the according event.

The integration of handwritten code can, thus, be

performed by implementing an advice that is executed

instead of a speciﬁc generated method. Accordingly,

handwritten code could be executed before or after

executing particular generated code, by using a be-

fore or after advice. All these cases, of course, require

the generator to create at least a dummy implementa-

tion of the corresponding method so that the hand-

written advice can be executed instead of that gener-

ated method.

NotePadBaseImpl

«gc»

«aspect»

NotePad

«hc»

Aspect Weaver

NotePadBaseImpl

«gc+hc»

Figure 6: Overview of an aspect-oriented integration mech-

anism for a part of a generated software system.

Figure 6 illustrates the idea underlying the inte-

gration of handwritten code using AOP. In this case,

handwritten code is added to an advice in an aspect.

An aspect weaver then takes the instructions given

in the aspect and produces a combined artifact (e.g.

a source code ﬁle) in which the advice implementa-

tion is woven into the code of the generated classes.

This means that the advice instructions are introduced

into the proper locations in the generated classes. In

the example given in Figure 6, the implementation of

a generated method in NotePadBaseImpl would be

replaced by the advice implementation, if the aspect

contains one advice for one method.

Besides the additional overhead of weaving the as-

pects into the source code, a major drawback of AOP

is that it is more difﬁcult to understand the program

ﬂow as it is inﬂuenced by aspects. Moreover, refac-

torings in the source code may lead to invalid aspects,

known as the fragile pointcut problem (Kellens et al.,

2006).

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. AOP offers a clear separation of

the handwritten and the generated code. The gener-

ated code is not aware of the aspects, which contain

the handwritten code and which are stored in separate

ﬁles.

C2: Support for Overriding Generated Parts. Ful-

ﬁlled. As described above, an advice can be imple-

mented such that it is called instead of a particular

event in the generated class. By means of this, the ex-

ecution of a generated method can be prevented and

instead the handwritten implementation is executed.

C3: Extendability of the Generated Interfaces.

Fulﬁlled. Concepts in aspect-oriented programming

allow to extend interfaces and classes. Consequently,

the API can be extended.

C4: Independence of Handwritten Code at

Generation-time. Fulﬁlled. The generator and the

generated code is not aware of handwritten code at

all.

C5: Independence of Additional OOP Language

Constructs. Unfulﬁlled. In order to be able to use

this mechanism, the generated code needs to con-

form to a programming language that supports aspect-

oriented programming or contains aspect-oriented ex-

tensions. This is not provided by OOP languages by

default.

Alternatives. If the target language does not sup-

port aspect-orientation, hook points can be created in

the generated code. Every hook point is called at the

beginning and end of a method execution. By using

inheritance, these hook points can be used to add be-

havior before or after the actual method execution.

The behavior can be changed completely by over-

riding the method representing the hook point (see

generation gap in Section 3.1). To some extent, this

mechanism simulates aspects in AOP but it is not able

to extend the API.

4 GENERAL INTEGRATION

MECHANISMS

Besides integration mechanisms that rely on language

concepts, integration approaches free of this restric-

tion are presented in this section. In compliance with

Section 3, these approaches are evaluated with respect

to the criteria described in Section 2.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

4.1 PartMerger Mechanism

A PartMerger is a component that is capable of merg-

ing multiple ﬁles of a speciﬁc type, e.g., Java ﬁles,

into one ﬁle. Obviously, this idea ﬁts well to integrate

handwritten and generated parts, as these parts can be

separated into different ﬁles and later be merged by

the PartMerger as shown in Figure 7.

The PartMerger mechanism is a generalization of

the partial classes mechanism (see Section 3.5). In

contrast to partial classes, the PartMerger can also

deal with non-source code artifacts. For instance, the

DSL tool bench MontiCore (Grönniger et al., 2008;

Krahn et al., 2010) uses this mechanism to merge gen-

erated and handwritten Eclipse plugin.xml ﬁles and

Eclipse manifest ﬁles.

Java PartMerger

NotePad.java

«gc»

NotePad.java

«hc»

NotePad.java

Figure 7: The PartMerger mechanism merges source code

artifacts (e.g. Java source code) to one artifact.

Without any restriction on how to merge differ-

ent ﬁles, the PartMerger mechanism is very ﬂexi-

ble. To consider handwritten code, a PartMerger can

give higher priorities to handwritten extensions when

merging two ﬁles. Furthermore, there are different

strategies for invoking the PartMerger and for deﬁn-

ing the ﬁles to be merged. A simple strategy is to in-

voke the PartMerger automatically for ﬁles conform-

ing to a speciﬁc naming convention on the artifact

level, e.g., ﬁles with the same ﬁle name in speciﬁc

folders or ﬁles with a common pre- or postﬁx. An-

other strategy is to let the developers conﬁgure which

ﬁles should be merged.

A drawback of the PartMerger mechanism is the

lack of tool support when integrating handwritten

code. The reason for this is that common function-

alities such as code completion are not directly avail-

able to access parts of the generated code due to the

strict separation of the generated and the handwritten

source code ﬁles. Developers need to implement such

tooling on their own, if they want to take advantage

of such tooling. This is an advantage of applying par-

tial classes (see Section 3.5). The according tooling

for this does not have to be implemented by the de-

veloper but it is already provided.

The PartMerger mechanism is very similar to the

partial classes mechanism. The main difference is

rooted in the language support for partial classes. In

other words, a language that supports partial classes

provides concepts to deﬁne what language parts are

merged. The compiler takes care of the merging. In

contrast, the PartMerger approach is based on a dedi-

cated conﬁgurable tool that merges different artifacts,

e.g. Java source code artifacts. Consequently, the

PartMerger mechanism is not tailored to a particular

language. However, the realization of the PartMerger

might be tailored to particular languages.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Fulﬁlled. The separation of artifacts is a pre-

condition for this approach.

C2: Support for Overriding Generated Parts. Ful-

ﬁlled. A PartMerger component can be implemented

in such a way that it assigns a higher priority to hand-

written parts so that certain generated parts are sub-

stituted by handwritten parts in the merged artifact.

In this way, the handwritten code will be executed in-

stead of the generated code.

C3: Extendability of the Generated Interfaces.

Fulﬁlled. Extending the API of a generated compo-

nent is easily possible. To accomplish this, a hand-

written interface provided by developers needs to be

merged with the generated interface.

C4: Independence of Handwritten Code at

Generation-time. Fulﬁlled. Handwritten artifacts

do not have to exist at generation-time, because they

do not inﬂuence the generation-process. Instead,

handwritten artifacts only have to be available when

the PartMerger merges the generated and handwritten

artifacts. This takes place after the code generator

has ﬁnished.

C5: Independence of Additional OOP Language

Constructs. Fulﬁlled. This mechanism does not re-

quire any kind of OOP language construct at all.

4.2 Protected Regions

Protected regions are designated regions located in

generated code that allow to add handwritten code

(see Figure 8). A common use case for applying pro-

tected regions is to generate method signatures from

input models and to insert protected regions into the

corresponding method bodies.

Each protected region is typically surrounded by

comments comprising a unique identiﬁcation string.

In this way, it can be differentiated between differ-

ent protected regions. Before (re)generating code, the

generator identiﬁes protected regions in the generated

AComparisonofMechanismsforIntegratingHandwrittenandGeneratedCodeforObject-OrientedProgramming

Languages

NotePad

protected region

part

«hc»

«gc»

Figure 8: The protected regions mechanism requires prede-

ﬁned regions that contain handwritten code.

code and manages the code contained in these regions

based on the identiﬁcation strings. While generating

code, it reinserts the code previously contained in a

particular protected region. As a consequence, the

identiﬁcation string associated with a protected region

is crucial to be able to preserve the handwritten code

in subsequent generator executions.

Different model-to-text transformation languages

provide built-in support for declaring protected re-

gions, including XPand (XPand website, 2014), Ac-

celeo (Acceleo website, 2014), Epsilon Generation

Language (Rose et al., 2008), JET (JET website,

2014) and MOFScript (Oldevik et al., 2005). Some

of these languages have different names for the pro-

tected region mechanism, e.g., protected area (Stahl

and Völter, 2006), user code block in Acceleo, user

region in JET, and unprotected block in MOFScript.

A major drawback of protected regions is that

it cannot be guaranteed that the generator preserves

handwritten implementations. The reason for this is

that handwritten code is mixed with generated code.

In addition, to support this mechanism, a guarantee

has to be given that the identiﬁcation string is unique

and stable. Otherwise, handwritten code may get lost

in some situations.

Evaluation Criteria

C1: Separation of Generated and Handwritten

Code. Unfulﬁlled. The handwritten and generated

parts are mixed within the same ﬁles, therefore there

is no separation according to our criterion.

C2: Support for Overriding Generated Parts. Un-

fulﬁlled. It is not possible to override generated code.

Only explicitly designated parts can be extended.

C3: Extendability of the Generated Interfaces.

Fulﬁlled. An extension of the API can be achieved

by generating in such a way that protected regions are

introduced into the generated interfaces. Then, meth-

ods can be added to that protected region.

C4: Independence of Handwritten Code at

Generation-time. Unfulﬁlled. The generator has

to analyze the previously generated code to extract

handwritten code from protected regions. Otherwise

the generator would not be able to inject that code

from the protected regions back into the generated

code.

C5: Independence of Additional OOP Language

Constructs. Fulﬁlled. This mechanism does not re-

quire any kind of OOP language construct at all.

Alternatives. The Eclipse Modeling Framework

(EMF) (Budinsky et al., 2008) applies a mechanism

to integrate handwritten code which is different to

protected regions described so far, but conceptually

comparable. In EMF, every class, method etc. that

is generated, includes a Javadoc comment that con-

tains a generated tag (Gronback, 2009). By removing

the generated tag the generated implementation can

be changed. Hence, removing the generated tag cor-

responds to introducing a protected region.

5 DISCUSSION

In this section, we summarize and discuss the evalu-

ation results shown in Table 1. A plus sign in a table

cell indicates that the approach fulﬁlls the correspond-

ing criterion, whereas a minus sign expresses that the

criterion was not satisﬁed. Parentheses denote that the

criterion is fulﬁlled under certain conditions.

All approaches, except for protected regions, sep-

arate generated and handwritten code on the basis of

ﬁles. Thus, it is ensured that the handwritten code

is not overwritten because only the generated ﬁles are

overwritten. However, the protected regions approach

combines generated and handwritten code. Conse-

quently, without external mechanisms this approach

does not protect handwritten code from being over-

written.

Table 1 also shows that the extended generation

gap approach, the aspect-oriented programming ap-

proach and the PartMerger approach provide the most

ﬂexibility when overriding generated parts and ex-

tending the generated interfaces. For partial classes,

it depends on the actual programming language being

used whether it is possible to override generated parts

or not. Moreover, it also depends on the program-

ming language, if besides partial classes also partial

interfaces are supported. The situation is different for

include mechanisms. Here, we are not aware of any

language allowing for includes in interfaces to extend

the generated interfaces. However, the concept itself

does not forbid such behavior. Therefore, its applica-

bility also depends on the used language.

A topic that should be discussed when allowing

to add handwritten code is the support for restrict-

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

Table 1: Overview of Integration Mechanisms and Results of Analysis with respect to the Criteria.

Generation

Gap

Extended

Gen. Gap

Delegation

Include

Mecha-

nism

Partial

Classes

AOP

PartMerger

Protected

Regions

C1: Separation of generated

+ + + + + + + -

and handwritten code

C2: Support for overriding

+ + - - (+) + + -

generated parts

C3: Extendability of the

- + - (+) (+) + + +

generated interfaces

C4: Independence of hand-

+ - + + + + + -written code at

generation-time

C5: Independence of addi-

+ + + - - - + +tional OOP language

constructs

ing what parts of the generated code can be over-

riden. For all approaches that are based on default

OOP language concepts restrictions can either be de-

ﬁned by using the private or ﬁnal modiﬁer in the gen-

erated code (generation gap and extended generation

gap) or by deﬁning a delegation interface that is to be

implemented (delegation). Other approaches only al-

low for adding handwritten code at predeﬁned points

in the generated code (include mechanism and pro-

tected regions). For all other approaches it depends

on the compiler/framework used (partial classes and

AOP) or the implementation of the part merging (Part-

Merger) what kinds of restrictions can be deﬁned.

All approaches but the extended generation gap

mechanism and protected regions do not need to

check for the existence of handwritten code at

generation-time. The extended generation gap ap-

proach demands the generator to check for the exis-

tence of the handwritten interface, as the generated

interface must extend this handwritten interface if it

exists. Moreover, it checks for the existence of the

handwritten implementation class, as this class is used

in the generated code if it exists. In case of protected

regions, the generator has to extract the handwritten

code from the generated code before (re)generating

to be able to reinsert it into the generated code.

Moreover, Table 1 illustrates that only the fol-

lowing approaches can be used without requiring

other language constructs than the default OOP lan-

guage constructs: generation gap, extended gener-

ation gap, delegation, PartMerger and protected re-

gions. All other mechanisms depend on additional

language constructs which are not provided by default

by OOP languages, e.g., include functionality or par-

tial classes.

6 RELATED WORK

To the best of our knowledge, no other publication

exists which gives a comparable overview and evalu-

ation of different integration mechanisms. However,

as most of the presented mechanisms have been de-

scribed by other authors, we give an overview of ex-

isting work in this section.

Pietrek et. al. (Pietrek et al., 2007) provide a ba-

sic introduction to MDE and list guidelines on how to

integrate generated and handwritten artifacts includ-

ing generation gap, protected regions, as well as in-

clude mechanisms. These mechanisms are also cov-

ered in (Petrasch and Meimberg, 2006).

Similarly, Stahl et. al. (Stahl and Völter, 2006)

propose and describe the adaptation of different de-

sign patterns - in particular delegation - to integrate

handwritten and generated code. These mechanisms

are also discussed in (Völter, 2003; Völter and Bet-

tin, 2004). The latter covers aspect-oriented methods

as well. This concept is also employed in (Groher

and Voelter, 2009; Völter and Groher, 2007; Kang

et al., 2009). Additionally, a brief overview of inte-

gration mechanisms is given in (Fowler, 2010). It in-

cludes different variations of the generation gap, par-

tial classes and protected regions mechanisms.

Approaches that speciﬁcally target .NET as the

target platform and thus allow special language fea-

tures including partial classes are covered in (Dollard,

2004; Greenﬁeld et al., 2004). Both also cover pro-

tected regions, as well as generation gap and delega-

tion.

The mechanisms supported in MetaEdit+ (Tolva-

nen and Kelly, 2009) are protected regions, function-

ality externalized in separate ﬁles (similar to the in-

AComparisonofMechanismsforIntegratingHandwrittenandGeneratedCodeforObject-OrientedProgramming

Languages

clude approach in our paper) as well as the direct in-

clusion of handwritten code in model ﬁles and are de-

scribed in (Kelly and Tolvanen, 2008). Direct inclu-

sion of handwritten code in model ﬁles has been left

out, because we put the focus on integrating handwrit-

ten code in generated code.

The different approaches that affect the imple-

mentation of model-driven architecture are presented

in (Frankel, 2003). They range from the unidirec-

tional code inclusion to complete round-trip engi-

neering, where code portions of handwritten code are

traced and reﬂected back into the model.

The code generator LLBLGen Pro (LLBLGen Pro

website, 2014) supports different target infrastruc-

tures and allows the integration of handwritten code

through protected regions, user-speciﬁc templates that

are included during the generation process, as well as

language-speciﬁc features such as partial classes.

The approach described in (Warmer and Kleppe,

2006) supports the concept of partial classes for gen-

erated object-oriented code and protected regions for

code that does not support this mechanism. Addition-

ally, Brückmann et al. (Brückmann and Gruhn, 2010)

advocate patterns such as delegation to incorporate

manually written code in generated parts.

7 CONCLUSION

In this paper, we presented eight mechanisms to in-

tegrate generated and handwritten code for OOP lan-

guages: generation gap, extended generation gap, del-

egation, include mechanisms, partial classes, AOP,

PartMerger and protected regions. To increase com-

parability between different integration mechanisms,

we proposed ﬁve evaluation criteria which address

different properties of integration mechanisms, for in-

stance, whether generated and handwritten code is

separated or whether it is possible to override gen-

erated parts. Table 1 on page 10 summarizes the re-

sults of the evaluation of the presented integration ap-

proaches with respect to this set of evaluation criteria.

Essentially, choosing a suitable mechanism for

integrating handwritten and generated code depends

on the concrete use case and the associated require-

ments. The catalog of integration mechanisms and

evaluation criteria presented in this paper provides an

overview for model-driven development tool develop-

ers that can be used to ﬁnd an appropriate integra-

tion approach on a case-by-case basis. Additionally,

we discussed related issues including restricting parts

that can be overriden to point out concerns that have

to be regarded.

We are aware of the fact that the evaluation criteria

proposed in this paper might not always be sufﬁcient

to decide which integration mechanism to use. In

addition, the list of presented integration approaches

does not claim to be complete. However, the ap-

proaches and criteria shown in this paper can be used

as a foundation that can be adapted and extended to

ﬁt speciﬁc requirements.

REFERENCES

Acceleo website (2014). http://www.eclipse.org/acceleo/.

Last visited on 22/09/2014.

Brückmann, T. and Gruhn, V. (2010). An Architectural

Blueprint for Model Driven Development and Mainte-

nance of Business Logic for Information Systems. In

Proceedings of the 4th European conference on Soft-

ware architecture, ECSA ’10, pages 53–69. Springer-

Verlag.

Budinsky, F., Steinberg, D., Merks, E., Ellersick, R., and

Grose, T. J. (2008). Eclipse Modeling Framework.

Addison-Wesley, 2nd edition.

Dollard, K. (2004). Code Generation in Microsoft .NET.

Apress.

Eliens, A. (1994). Principles of Object-Oriented Software

Development. Addison-Wesley Longman Publishing

Co., Inc.

Fowler, M. (2010). Domain Speciﬁc Languages. Addison-

Wesley.

France, R. and Rumpe, B. (2007). Model-Driven Devel-

opment of Complex Software: A Research Roadmap.

In Future of Software Engineering, ICSE ’07, pages

37–54. IEEE Computer Society.

Frankel, D. S. (2003). Model Driven Architecture: Applying

MDA to Enterprise Computing. Wiley.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley Profes-

sional.

Greenﬁeld, J., Short, K., Cook, S., and Kent, S. (2004).

Software Factories: Assembling Applications with

Patterns, Models, Frameworks, and Tools. Wiley.

Groher, I. and Voelter, M. (2009). Aspect-Oriented Model-

Driven Software Product Line Engineering. In Trans-

actions on Aspect-Oriented Software Development VI,

pages 111–152. Springer-Verlag.

Gronback, R. C. (2009). Eclipse Modeling Project: A

Domain-Speciﬁc Language (DSL) Toolkit. Addison-

Wesley.

Grönniger, H., Hartmann, J., Krahn, H., Kriebel, S., Roth-

hardt, L., and Rumpe, B. (2008). Modelling Automo-

tive Function Nets with Views for Features, Variants,

and Modes. In Proceedings of Embedded Real Time

Software and Systems, ERTS ’08.

Grönniger, H., Krahn, H., Rumpe, B., Schindler, M., and

Völkel, S. (2008). MontiCore: a Framework for the

Development of Textual Domain Speciﬁc Languages.

In 30th International Conference on Software Engi-

neering, ICSE ’08, pages 925–926. ACM.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

JET website (2014). http://www.eclipse.org/modeling/m2t/

?project=jet#jet. Last visited on 22/09/2014.

Kang, K. C., Sugumaran, V., and Park, S. (2009). Applied

Software Product Line Engineering. Auerbach Publi-

cations.

Kellens, A., Mens, K., Brichau, J., and Gybels, K. (2006).

Managing the Evolution of Aspect-oriented Software

with Model-Based Pointcuts. In Proceedings of the

20th European Conference on Object-Oriented Pro-

gramming, ECOOP ’06, pages 501–525. Springer-

Verlag.

Kelly, S. and Tolvanen, J.-P. (2008). Domain-Speciﬁc Mod-

eling: Enabling Full Code Generation. Wiley.

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

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

Aspect-Oriented Programming. In European Confer-

ence on Object-Oriented Programming, ECOOP ’97,

pages 220–242. Springer Verlag.

Kleppe, A. G., Warmer, J., and Bast, W. (2003). MDA

Explained: The Model Driven Architecture: Practice

and Promise. Addison-Wesley Longman Publishing

Co., Inc.

Krahn, H., Rumpe, B., and Völkel, S. (2010). MontiCore:

a Framework for Compositional Development of Do-

main Speciﬁc Languages. International Journal on

Software Tools for Technology Transfer, pages 353–

372.

Kurpick, T., Pinkernell, C., Look, M., and Rumpe, B.

(2012). Modeling Cyber-Physical Systems: Model-

Driven Speciﬁcation of Energy Efﬁcient Buildings. In

Proceedings of the Modelling of the Physical World

Workshop, MOTPW ’12, pages 2:1–2:6. ACM.

LLBLGen Pro website (2014). http://www.llblgen.com/.

Last visited on 22/09/2014.

Navarro Pérez, A. and Rumpe, B. (2013). Modeling Cloud

Architectures as Interactive Systems. In 2nd Inter-

national Workshop on Model-Driven Engineering for

High Performance and CLoud computing, MDHPCL

’13, pages 15–24, Miami, Florida. CEUR Workshop

Proceedings.

Oldevik, J., Neple, T., Grønmo, R., Aagedal, J., and Berre,

A.-J. (2005). Toward Standardised Model to Text

Transformations. In Proceedings of the First Euro-

pean conference on Model Driven Architecture: foun-

dations and Applications, ECMDA-FA ’05, pages

239–253. Springer-Verlag.

Parnas, D. L. (1972). On the Criteria to be Used in Decom-

posing Systems into Modules. Communications of the

ACM, 15(12):1053–1058.

Petrasch, R. and Meimberg, O. (2006). Model-Driven Ar-

chitecture: Eine praxisorientierte Einführung in die

MDA. Dpunkt Verlag.

Pietrek, G., Trompeter, J., Niehues, B., Kamann, T., Holzer,

B., Kloss, M., Thoms, K., Beltran, J. C. F., and Mork,

S. (2007). Modellgetriebene Softwareentwicklung.

MDA und MDSD in der Praxis. Entwickler.Press.

Ringert, J. O., Rumpe, B., and Wortmann, A. (2013). From

Software Architecture Structure and Behavior Mod-

eling to Implementations of Cyber-Physical Systems.

In Software Engineering 2013 Workshopband, pages

155–170. GI, Köllen Druck+Verlag GmbH, Bonn.

Rose, L. M., Paige, R. F., Kolovos, D. S., and Polack, F. A.

(2008). The Epsilon Generation Language. In Pro-

ceedings of the 4th European conference on Model

Driven Architecture: Foundations and Applications,

ECMDA-FA ’08, pages 1–16. Springer-Verlag.

Rumpe, B. (2011). Modellierung mit UML, volume 2nd

Edition. Springer.

Rumpe, B. (2012). Agile Modellierung mit UML : Code-

generierung, Testfälle, Refactoring. Springer.

Rumpe, B., Schindler, M., Völkel, S., and Weisemöller,

I. (2010). Generative Software Development. In

Proceedings of the 32nd International Conference

on Software Engineering, ICSE ’10, pages 473–474.

ACM.

Schindler, M. (2012). Eine Werkzeuginfrastruktur zur ag-

ilen Entwicklung mit der UML/P. PhD thesis, RWTH

Aachen University.

Stahl, T. and Völter, M. (2006). Model-Driven Software De-

velopment: Technology, Engineering, Management.

Wiley.

Tolvanen, J.-P. and Kelly, S. (2009). MetaEdit+: Deﬁn-

ing and Using Integrated Domain-Speciﬁc Modeling

Languages. In Proceeding of the 24th ACM SIGPLAN

conference companion on Object oriented program-

ming systems languages and applications, OOPSLA

’09, pages 819–820. ACM.

Vlissides, J. (1998). Pattern Hatching: Design Patterns Ap-

plied. Addison-Wesley.

Völter, M. (2003). A Catalog of Patterns for Program Gen-

eration, Version 1.6. http://www.voelter.de/data/pub/

ProgramGeneration.pdf. Last visited on 22/09/2014.

Völter, M. and Bettin, J. (2004). Patterns for Model-

Driven Software-Development, Version 1.4. http://

www.voelter.de/data/pub/MDDPatterns.pdf. Last vis-

ited on 22/09/2014.

Völter, M. and Groher, I. (2007). Handling Variability

in Model Transformations and Generators. In Pro-

ceedings of the 7th OOPSLA Workshop on Domain-

Speciﬁc Modeling, DSM ’07. ACM.

Warmer, J. and Kleppe, A. (2006). Building a Flexible

Software Factory Using Partial Domain Speciﬁc Mod-

els. In Proceedings of the 6th OOPSLA Workshop on

Domain-Speciﬁc Modeling, DSM ’06, pages 15–22.

ACM.

Wile, D. S. (2003). Lessons Learned from Real DSL Ex-

periments. In Proceedings of the 36th Annual Hawaii

International Conference on System Sciences, HICSS

’03, pages 265–290. IEEE Computer Society.

XPand website (2014). http://www.eclipse.org/modeling/

m2t/?project=xpand#xpand Last visited on

22/09/2014.

AComparisonofMechanismsforIntegratingHandwrittenandGeneratedCodeforObject-OrientedProgramming

Languages