Towards Product Lining Model-driven Development Code Generators

Alexander Roth and Bernhard Rumpe

Software Engineering, RWTH Aachen University, Aachen, Germany

Keywords:

Model-driven Development, Code Generator Product Line, Component-based Software Engineering.

Abstract:

A code generator systematically transforms compact models to detailed code. Today, code generation is

regarded as an integral part of model-driven development (MDD). Despite its relevance, the development

of code generators is an inherently complex task and common methodologies and architectures are lacking.

Additionally, reuse and extension of existing code generators only exist on individual parts. A systematic

development and reuse based on a code generator product line is still in its infancy. Thus, the aim of this paper

is to identify the mechanism necessary for a code generator product line by (a) analyzing the common product

line development approach and (b) mapping those to a code generator speciﬁc infrastructure. As a ﬁrst step

towards realizing a code generator product line infrastructure, we present a component-based implementation

approach based on ideas of variability-aware module systems and point out further research challenges.

1 INTRODUCTION

An integral part of model-driven development (MDD)

are generators, which successively, systematically,

and automatically transform abstract models to con-

crete code. Today’s code generators help to “compute

an efﬁcient implementation for a nice and easy-to-

understand speciﬁcation” (Czarnecki and Eisenecker,

2000). Disparate domains have adopted code gener-

ators including cyber-physical systems (Haber et al.,

2012) and cloud-based systems (Navarro P

erez and

Rumpe, 2013).

Even though code generators are used in multiple

domains, they are tailored to one domain, serve a pur-

pose, and are mostly not designed for reuse. Product

line engineering focuses on identifying commonali-

ties and variability (the ability to change or customize

a system in a predeﬁned way (Pohl et al., 2005)) to

create components that are used to develop software

products for an area of application (Clements and

Northrop, 2012). Applying ideas of product line en-

gineering to code generators helps to design reusable

code generator components in order to develop gen-

erator product lines and support reuse.

Multiple authors have discussed implementation

mechanisms for code generator product lines (Ba-

tory et al., 1994; ?; Smaragdakis and Batory, 2000;

olter and Groher, 2007a; Kulkarni and Reddy, 2008;

orges, 2013). However, the approaches either re-

quire the developer to know the code generator’s in-

ternals (Apel et al., 2013); result in hardly maintain-

able code generators; are lacking essential concepts

to prevent dublicate components with minor adapta-

tions; or are based on textual composition of gener-

ated artifacts. These short comings in code generator

product line development result in hardly maintain-

able and understandable code generators and hamper

code generator reuse.

Consequently, the aim of this paper is to apply

current ideas of product line engineering to MDD

code generators in order to identify research oppor-

tunities. By analyzing common approaches to imple-

ment product lines a mapping to a code generator in-

frastructure is presented. This infrastructure is based

on code generator components with a separation of

global and local variability (K

astner et al., 2012). We

argue that a clear understanding and a language in-

dependent implementation concept of a code genera-

tor component’s interface is crucial for code generator

product lines and present possible extensions.

Hence, an overview of current literature (Sec-

tion 2) shows the state of the art and points out

short comings in this research area. Next, our un-

derstanding of a code generator is presented in Sec-

tion 3 to discuss upcoming challenges in developing

code generator product lines. By applying variability-

aware module systems to code generators further

challenges including code generator component inter-

faces are presented in Section 4. Finally, code genera-

tor component composition with respect to the differ-

539

Roth A. and Rumpe B..

Towards Product Lining Model-driven Development Code Generators.

DOI: 10.5220/0005242605390545

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

ISBN: 978-989-758-083-3

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

ent forms of composition is introduced in Section 5

and the paper is concluded in Section 6.

2 RELATED WORK

Preprocessor and conditional approaches are the most

popular approaches to implement variability (Czar-

necki and Eisenecker, 2000; V

olter and Groher,

2007a). To avoid hardly maintainable code be-

cause of too many conditions (Spencer and Col-

lyer, 1992), multiple approaches have been pro-

posed including an approach based on Aspect-

Oriented Programming (V

olter and Groher, 2007a;

olter and Groher, 2007b), transformation-based ap-

proaches (Smaragdakis and Batory, 2000), and do-

main speciﬁc language-based approaches (Singhal,

1996; Czarnecki et al., 2000). A major drawback of

these approaches is that in depth knowledge of the

generator’s internals is required (Apel et al., 2013).

Moreover, the language based approaches require ei-

ther a powerful transformation or domain-speciﬁc

language. Rather than proposing a language to imple-

ment variability, this paper focuses on identifying re-

search directions in developing code generator prod-

uct lines and proposes explicit interfaces to support

information hiding.

Besides the above variability implementation

mechanisms that have been used to implement code

generators, a component-based (Kulkarni and Reddy,

2008), a layered (Batory and O’Malley, 1992), and

a service-oriented approach (J

orges, 2013) have been

proposed to implement code generator product lines.

These approaches are based on textual composition

of artifacts. Additionally, in the latter approach a

variant is a full copy of an existing code generator

with additional extensions and adaptations. Thereby,

the commonalities of all variants are not managed on

their. Moreover, none of the approaches addresses in-

put language variability, which is the variability de-

ﬁned by the input model, e.g. by deﬁning a keyword

to change the generated code. In this paper, we build

on top of these ideas but consider input language vari-

ability as well as variability within components.

3 GENERATORS AND PRODUCT

LINES

A generator can be seen as a software system that pro-

duces an implementation from a higher-level descrip-

tion of a part of a software (Czarnecki and Eisenecker,

2000). A code generator is a special type of a gener-

ator that creates an implementation in a programming

language from a set of input artifacts, which are typ-

ically models. We also assume that a code genera-

tor always terminates, is deterministic, is not an inter-

active system, and generates at least one output arti-

fact from one input artifact. Such code generators are

built on top of existing compilers for programming

languages (Brambilla et al., 2012).

Basically, a code generator consists of a front-end

(language processing) and a back-end (code genera-

tion). Language processing is concerned with parsing

the models, checking language constraints and cre-

ating an internal representation (abstract syntax tree

and symboltable). Code generation transforms the in-

ternal representation to concrete code stored in output

artifacts.

In most cases, a code generator has one particular

purpose and is not designed in an extensible way for

being reused it in different application areas. An ap-

proach to exploit code generator reuse, i.e., allowing

customizations and adaptations to the code generator

to redeﬁne the purpose or the area of application, is to

create a code generator product line. In the remainder

of this section, we introduce code generator product

lines and identify research opportunities.

3.1 Code Generator Product Lines

A code generator product line is a set of components

used to create a concrete code generator product that

describes a software product line for a speciﬁc area

of application. A code generator variant, which rep-

resents a concrete code generator, is modeled by se-

lecting a set of components and adding customiza-

tions and adaptations. A code generator product line

strongly differs from general product line develop-

ment as understood in (Clements and Northrop, 2012;

Bosch, 2000; Pohl et al., 2005), because (a) code gen-

erators are techniques to manage end-product lines

and (b) a code generator is often at least partially itself

generated. Based on these primary differences code

generator product lines can be seen as either a tooling

to conﬁgure software product lines or as a product line

on its own. In the remainder of this paper, we use the

latter understanding.

Each code generator product line component is ei-

ther a front-end or a back-end component. Front-end

components are concerned with extending the lan-

guage processing, e.g. additional constraints to re-

strict the set of input models. A back-end component

adds functionality to the code generation process.

In the following, we shortly describe the two pro-

cesses in which a product line is developed and point

out open research questions.

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

540

Data Explorer

Core Generator

Class

Default

Constructor

Enum Interface

Object

Instantiation

Builder

Factory

Unidirectional Bidirectional

Associations → Interface

constraint

mandatory

feature

optional

feature

alternative

features

Qualified

Associations

Unidirectional Bidirectional

features

Associations

Type

Factory → Interface

Figure 1: A a feature model of a simpliﬁed class diagram-to-Java code generator.

3.1.1 Domain Engineering

Domain engineering focuses on collecting, organiz-

ing, and storing past experience in developing sys-

tems in a domain in the form of reusable assets and

additionally providing means of reusing these as-

sets (Czarnecki and Eisenecker, 2000). All relevant

information is integrated in a coherent domain model.

An example of the commonalities and variability of

a code generator product line for a class diagram-to-

Java generator is shown in the feature model (Kang

et al., 1990) in Figure 1.

A research question is if domain engineering for

code generator product lines differs from domain en-

gineering proposed for software product lines. For

instance, since each code generator maps concepts of

the input language to concepts of the target language

features of the input language and features of the out-

put language are part of the code generator feature

model. In Figure 1 input language concepts (Class,

Enum, and Interface features) as well as output lan-

guage concepts (Builder and Factory) are part of

the code generator product line.

In the domain engineering the architecture of the

product line is designed as well. To our knowledge

GenVoca (Batory et al., 1994), a component-based

approach (Kulkarni and Reddy, 2008), and a Service-

Oriented architecture (J

orges, 2013) are currently the

only architecture proposed for generators. Possible

candidates for other code generator product line ar-

chitectures are generic architectures that deﬁne a ﬁxed

frame with a number of extension points and highly

ﬂexible architectures that support structural variation,

i.e., even the skeleton may vary.

By analyzing existing approaches to implement

software product line architectures, we have extracted

a set of requirements that should be considered when

developing a code generator product line:

1. Traceability of Features. Throughout the life-

cycle of the product line a mapping between a fea-

ture and its implementing source code elements

should be kept to ensure maintainability (Apel

et al., 2013).

2. Selection and Conﬁguration of Features. A selec-

tion and conﬁguration mechanism has to be easy

to understand, has to detect invalid selections and

conﬁgurations, and has to directly inﬂuence the

resulting product, i.e., every selected feature must

be included in the product.

3. Separation of Concerns. The implementation of

a product line should be separated into differ-

ent components to support component reusabil-

ity (Clements and Northrop, 2012).

4. Separation of Variability. Separating variability

by allowing each component to be a product line

on its own helps reducing complexity (K

astner

et al., 2012). In generator product lines variabil-

ity at generator level and variability at generated

artifact level have to be regarded as well.

5. Enable Reuse. Product line development aims at

designing components that can be reused in other

product lines (Pohl et al., 2005; Clements and

Northrop, 2012).

6. Component Composition. A product line im-

plementation regards component composition by

making it “as easy as merging code” (K

astner

et al., 2012). From set of components a variant is

composed by ﬁrst validating constraints and sec-

ond sticking the components together.

Subsequently, we analyze the process of how to form

a code generator variant and point out research oppor-

tunities.

3.1.2 Application Engineering

In the application engineering process a variant is de-

rived using the product line architecture and the set

of components. After selecting and conﬁguring the

product line components, customizations are added

to deﬁne a concrete product variant. In code generator

product lines customizing components means to adapt

the components’ behavior by including handwritten

extensions or writing glue code. An infrastructure for

TowardsProductLiningModel-drivenDevelopmentCodeGenerators

541

code generator product lines has to support such kind

of extensions.

The derivation process of a variant can either be

performed manually, automated (assembly of compo-

nents is supported by tools and generators), or auto-

matically (ordering and assembly of the variant is sup-

ported by tools and generators (Czarnecki and Eise-

necker, 2000)). Here, the automatical approach ex-

tends the automated approach by deriving a variant

from a speciﬁcation. In all of these approaches, a

general challenge is to ensure the syntax, type, and

behavioral correctness.

In the remainder, we implement a code generator

product line to identify further research challenges.

4 IMPLEMENTING CODE

GENERATORS PRODUCT

LINES

Using the variability-aware module system ap-

proach (K

astner et al., 2012), we implement a code

generator product line. We are aware of other ap-

proaches to implement code generator product lines.

This approach has been chosen because it ﬁts the

idea of reusable components with separated variabil-

ity concerns as described in Section 3.1.1.

A variability-aware module system eliminates

predominant variability, i.e., the need to represent

variability using components, in component-based

approaches by separating variability into global and

local variability concerns. Global variability is con-

cerned with representing variability by components,

whereas local variability is concerned with the vari-

ability inside a component. Each component provides

conﬁguration options to conﬁgure local variability.

Since components contain local variability, they form

product lines on their own. Composing components

becomes composition of entire product lines.

To give an example of a code generator prod-

uct line, we assume the feature model in Figure 1

shows our code generator product line. It produced

Java code from class diagram models. Rather than

using a feature-to-component mapping, we map the

feature Types to one component with a conﬁgura-

tion option for the Default Constructor. The

component’s interface contains variability concerns

(generate classes, interfaces, enumerations, or default

constructors) and variability constraints (classes are

mandatory). Here, global variability is modeled by

the Types component and local variability is modeled

by the conﬁguration options. A research question is if

there are guidelines on how to map features to com-

ponents with local variability.

Crucial to component-based approaches are inter-

faces. In the following, we introduce code generator

component interfaces.

4.1 Code Generator Component

Interface

A code generator component interface is the interface

provided by each code generator component. Besides

conﬁguration options for local variability, it may also

contain variation points, which are deﬁne by devel-

opers and assigned during application engineering to

specify individual adaptations. These variation points

can be used in the application engineering process to

customize a component.

For code generator components, it is not practical

to deﬁne each generated method because (a) they are

possibly generated during run-time and, thus, do not

exist a priori and (b) rather than method declarations

parts of generated code are exchanged to parameter-

ize a code generator component at generation-time.

Without explicitly method or code declarations other

ways have to be found to prevent generation of syn-

tactically incorrect code. A research direction based

on generating code into containers and checking its

syntax before writing to a ﬁle has been proposed

in (Zschaler and Rashid, 2011). Still it is unknown

what methods are generated before generation-time.

During code generation components exchange in-

formation to adapt the generation process. For in-

stance, information about generated artifacts are ex-

changed to prevent overwriting. Typically, such in-

formation is implicit and only known to the genera-

tor developer. This hampers efﬁcient code generator

reuse. To improve reusability such implicit knowl-

edge should be made explicit in code generator com-

ponent interfaces. However, such an approach re-

quires an ontology for the exchanged information and

an infrastructure to support information exchange,

e.g. shared-memory (Batory and O’Malley, 1992;

orges, 2013).

As a code generator component may contain

transformations, a code generator component may de-

ﬁne different behaviors for different conﬁgurations.

For instance, before generating code some transfor-

mations have to be applied. Such behavior may also

be conﬁgured during application engineering to, e.g.

leaf out some transformations. Thus, an infrastructure

demands for explicit representation of component’s

behavior and support for customizing such behavior.

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

542

5 CODE GENERATOR

COMPONENT COMPOSITION

Deriving a concrete product from a set of components

means to compose components and add customiza-

tions. In compliance to (Rumpe, 2013), we under-

stand code generator component composition as the

derivation of a code generator component C = A ⊗ B

from two code generator components A and B using a

composition operator ⊗. This composition demands

for two code generator components A and B with pre-

cisely deﬁned interfaces and encapsulated internals.

The composition C = A ⊗ B binds both code gener-

ator components together with respect to their com-

mon interface. The the resulting composition has a

combined meaning. A deﬁnition of the composition

operator for the variability-aware module system that

also regards global and local variability has been pro-

posed in (K

astner et al., 2012).

Composition is separated into different

forms (Rumpe, 2013). In the following, we an-

alyze these forms and give implications for a code

generator product line infrastructure.

5.1 Forms of Composition

Syntactic composition deals with how the component

composition looks like. When composing code gen-

erator components, the composition of two code gen-

erator components may generate one or multiple ar-

tifact(s) that either contain code that is produced by

multiple code generator components or code that is

generated by only one code generator component. In

both cases the generated code needs to be checked for

syntactic errors.

Assuming that semantics is understood as

in (Harel and Rumpe, 2004), then semantic compo-

sition is concerned with the meaning of the code gen-

erator component composition. Each code generator

component deﬁnes the mapping of the input language

concepts to concepts in the output language. The

meaning of a code generator composition is the com-

posed meaning of all involved code generator com-

ponents. The semantics are derived from the compo-

sition operator and the semantics of each composed

code generator component. An infrastructure for code

generator product lines has to support individual deﬁ-

nitions of the composition operator, since the seman-

tics may vary for different code generator variants.

A major challenge in code generator product line

development is to decompose the overall code gen-

erator into small components. In consequence, that

the code generator component interfaces have to be

designed for composition. This form of composition

- called methodical composition - points out that a

method for mapping feature models to code genera-

tor components is currently lacking.

When the overall code generator product line is

decomposed in code generator components the devel-

opment task is to be organized. Organizational com-

position is concerned with organizing the collabora-

tive and independent development of code generator

components. A prerequisite for an independent de-

velopment is a clear deﬁnition of the code generator

component interfaces. This forms a speciﬁcation that

has to be followed by each development team of a

code generator component. An initial approach has

been proposed in (Kulkarni and Reddy, 2008).

Finally, technical composition regards the de-

mands for the infrastructure to enable code genera-

tor component composition. A major challenge is in-

cremental code generation, i.e., small changes to the

input do not require a complete regeneration but only

the relevant parts are regenerated. Technical composi-

tion also regards binding times of the code generator

components. Conceptually, the components need to

be composed as soon as possible in the development

such that developers have an understanding of the ﬁ-

nal product. Technically the composition should be

handled as late as possible to support partial regener-

ation and increase speed of code generation.

In the following, we present different ways to

compose code generator components.

5.2 Binding Times

Composing code generator components at generation

time requires an infrastructure that allows compo-

nents to exchange information about the generated ar-

tifacts or the component’s internals, e.g. names of

generated methods or pieces of target code. Then,

the generated artifacts are created collaboratively. De-

spite early error detection in the generation process, a

common understanding and a standardization of the

information exchanged is crucial. Only then, collab-

oration between code generator components can take

place. Moreover, in such an approach information ex-

change may also require knowledge about the context

of the exchanged information.

Another approach to compose code generator

components is to create artifacts that can be composed

at run-time. The generated artifacts are a priori de-

signed to provide target language constructs that are

used in other artifacts. For instance, provide prede-

ﬁned methods to call functionality. This approach

suffers from implicit knowledge about the generated

artifacts. It is only beneﬁcial for more than one devel-

oper, if the implicit knowledge is available for every

TowardsProductLiningModel-drivenDevelopmentCodeGenerators

543

developer at anytime.

Finally, a hybrid approach that uses composition

at generation- and run-time may provide a sufﬁcient

solution to handle composition. However, it is cur-

rently not common in practice.

6 CONCLUSION

Despite the relevance of MDD code generators, there

are no common development methodologies and ap-

proaches for developing code generators product

lines. We have analyzed the common processes of

product line engineering to identify research chal-

lenges for code generator product lines. It shows that

research is needed in analyzing, designing architec-

tures, and implementing code generator product lines.

As a primary step towards an infrastructure for

code generator product lines, we have applied ideas of

variability-aware module systems to identify research

challenges. Crucial to a code generator product line

are interfaces, which contain variability, generation

information, extensions to the generated artifacts, and

different behavior of the code generator components.

This is unique to code generator product lines com-

pared to general software product lines.

We have pointed out the different forms of code

generator composition to derive requirements for a

code generator product line infrastructure. The main

requirements for a code generator product line infras-

tructure are support for incremental code generation,

speciﬁcation of code generator component interfaces,

support for validation of generated code, and support

for individual semantics of a composition operator.

REFERENCES

Apel, S., Batory, D., K

astner, C., , and Saake., G. (2013).

Feature-Oriented Software Product Lines: Concepts

and Implementation. Springer-Verlag.

Batory, D. and O’Malley, S. (1992). The Design and Im-

plementation of Hierarchical Software Systems with

Reusable Components. ACM Transactions on Soft-

ware Engineering and Methodology, 1(4).

Batory, D., Singhal, V., Thomas, J., Dasari, S., Geraci,

B., and Sirkin, M. (1994). The GenVoca Model of

Software-System Generators. IEEE Software, 11(5).

Bosch, J. (2000). Design and Use of Software Archi-

tectures: Adopting and Evolving a Product-line Ap-

proach. ACM Press/Addison-Wesley Publishing Co.

Brambilla, M., Cabot, J., and Wimmer, M. (2012). Model-

Driven Software Engineering in Practice. Morgan &

Claypool.

Clements, P. and Northrop, L. (2012). Software Product

Lines: Practices and Patterns. Addison-Wesley Long-

man Publishing Co., Inc.

Czarnecki, K. and Eisenecker, U. W. (2000). Genera-

tive programming: methods, tools, and applications.

ACM Press/Addison-Wesley Publishing Co.

Czarnecki, K., Eisenecker, U. W., Gl

uck, R., Vandevoorde,

D., and Veldhuizen, T. L. (2000). Generative Pro-

gramming and Active Libraries. In Selected Papers

from the International Seminar on Generic Program-

ming. Springer-Verlag.

Haber, A., Ringert, J. O., and Rumpe, B. (2012). MontiArc

- Architectural Modeling of Interactive Distributed

and Cyber-Physical Systems. Technical Report AIB-

2012-03, RWTH Aachen University.

Harel, D. and Rumpe, B. (2004). Meaningful Modeling:

What’s the Semantics of ”Semantics”? Computer,

37(10).

orges, S. (2013). Construction and Evolution of Code Gen-

erators - A Model-Driven and Service-Oriented Ap-

proach, volume 7747 of Lecture Notes in Computer

Science. Springer.

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

and Peterson, A. S. (1990). Feature-Oriented Domain

Analysis (FODA) Feasibility Study. Technical report.

astner, C., Ostermann, K., and Erdweg, S. (2012). A

variability-aware module system. In OOPSLA.

Kulkarni, V. and Reddy, S. (2008). An Abstraction for

Reusable MDD Components: Model-based Genera-

tion of Model-based Code Generators. In Proceedings

of the 7th International Conference on Generative

Programming and Component Engineering, GPCE

’08. ACM.

Navarro P

erez, A. and Rumpe, B. (2013). Modeling Cloud

Architectures as Interactive Systems. In Proceedings

of the 2nd International Workshop on Model-Driven

Engineering for High Performance and Cloud com-

puting, volume 1118. CEUR Workshop Proceedings.

Pohl, K., B

ockle, G., and Linden, F. J. v. d. (2005). Soft-

ware Product Line Engineering: Foundations, Princi-

ples and Techniques. Springer-Verlag New York, Inc.

Rumpe, B. (2013). Towards Model and Language Compo-

sition. In Proceedings of the First Workshop on the

Globalization of Domain Speciﬁc Languages, Glob-

alDSL ’13. ACM.

Singhal, V. P. (1996). A Programming Language for Writing

Domain-Speciﬁc Software System Generators. PhD

thesis, Faculty of the Graduate School of the Univer-

sity of Texas at Austin.

Smaragdakis, Y. and Batory, D. (2000). Application Gen-

erators. In in Software Engineering volume of the En-

cyclopedia of Electrical and Electronics Engineering.

John Wiley and Sons.

Spencer, H. and Collyer, G. (1992). #ifdef considered harm-

ful, or portability experience with C News. In USENIX

Summer Technical Conference.

olter, M. and Groher, I. (2007a). Handling Variability in

Model Transformations and Generators. In Proceed-

ings of the 7th Workshop on Domain-Speciﬁc Model-

ing (DSM) at OOPSLA.

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

544

olter, M. and Groher, I. (2007b). Product Line Imple-

mentation Using Aspect-Oriented and Model-Driven

Software Development. In Proceedings of the 11th In-

ternational Software Product Line Conference, SPLC

’07. IEEE Computer Society.

Zschaler, S. and Rashid, A. (2011). Towards Modular

Code Generators Using Symmetric Language-aware

Aspects. In Proceedings of the 1st International Work-

shop on Free Composition, FREECO ’11. ACM.

TowardsProductLiningModel-drivenDevelopmentCodeGenerators

545