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 specific infrastructure. As a first 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 efficient implementation for a nice and easy-to-
understand specification” (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 predefined 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;
V
¨
olter and Groher, 2007a; Kulkarni and Reddy, 2008;
J
¨
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
Copyright
c
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;
V
¨
olter and Groher, 2007b), transformation-based ap-
proaches (Smaragdakis and Batory, 2000), and do-
main specific 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-specific
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-
fined by the input model, e.g. by defining 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 redefine 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 specific 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 configure 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
FD
constraint
mandatory
feature
optional
feature
alternative
features
or
features
Qualified
Associations
Unidirectional Bidirectional
or
features
Associations
Type
Factory Interface
Figure 1: A a feature model of a simplified 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 define a fixed
frame with a number of extension points and highly
flexible 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 Configuration of Features. A selec-
tion and configuration mechanism has to be easy
to understand, has to detect invalid selections and
configurations, and has to directly influence 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 first 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 configuring the
product line components, customizations are added
to define 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 specification. 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 fits 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
configuration options to configure 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 configura-
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 configuration 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
configuration options for local variability, it may also
contain variation points, which are define 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 define 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 file 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 efficient 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;
J
¨
orges, 2013).
As a code generator component may contain
transformations, a code generator component may de-
fine different behaviors for different configurations.
For instance, before generating code some transfor-
mations have to be applied. Such behavior may also
be configured 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 defined 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 definition 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 defines 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 defi-
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 definition of the code generator
component interfaces. This forms a specification 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 fi-
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-
fined methods to call functionality. This approach
suffers from implicit knowledge about the generated
artifacts. It is only beneficial 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 sufficient
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,
specification 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).
J
¨
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.
K
¨
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 Specific Languages, Glob-
alDSL ’13. ACM.
Singhal, V. P. (1996). A Programming Language for Writing
Domain-Specific 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.
V
¨
olter, M. and Groher, I. (2007a). Handling Variability in
Model Transformations and Generators. In Proceed-
ings of the 7th Workshop on Domain-Specific Model-
ing (DSM) at OOPSLA.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
544
V
¨
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