Towards the Integration of Model-Driven Engineering, Software Product

Line Engineering, and Software Conﬁguration Management

Felix Schw

agerl, Thomas Buchmann, Sabrina Uhrig and Bernhard Westfechtel

Applied Computer Science I, University of Bayreuth, Universit

atsstr. 30, 95440 Bayreuth, Germany

Keywords:

Model-Driven Software Engineering, Software Product Lines, Software Conﬁguration Management.

Abstract:

Model-Driven Software Engineering (MDSE), Software Product Line Engineering (SPLE) and Software Con-

ﬁguration Management (SCM) have been established as independent disciplines to ease different aspects of

software development. The usage of models as high-level abstractions promises to increase productivity, while

software product lines manage variability within a family of similar software products; software conﬁguration

management systems manage evolution and support collaborative development. In this paper, we explore the

state of the art regarding the pairwise combinations MDSE/SPLE, SPLE/SCM, and MDSE/SCM and show

that an integrated solution combining all three disciplines is missing. We present a conceptual framework

to integrate MDSE, SPLE and SCM uniformly based on a ﬁltered editing model. The framework implies a

number of advantages, namely unconstrained variability, a reduction of cognitive complexity, improved con-

sistency, tool independence, and a higher level of automation. Our formalism is based on a uniform versioning

model for temporal, cooperative, and logical versioning of models. By an example, we show the feasibility of

our approach.

1 INTRODUCTION

The discipline Model-Driven Software Engineering

(MDSE) (V

olter et al., 2006) is focused on the de-

velopment of models as ﬁrst-class artifacts in or-

der to describe software systems at a higher level

of abstraction and to automatically derive platform-

speciﬁc source code. In this way, MDSE promises to

increase the productivity of software engineers, who

may focus on creative and intellectually challenging

modeling tasks rather than on repeated activities at

source-code level. Models are typically expressed in

well-deﬁned languages such as the Uniﬁed Modeling

Language (UML), which deﬁne the structure as well

as the behavior of model elements. The Eclipse Mod-

eling Framework (EMF) (Steinberg et al., 2009) pro-

vides the technological foundation for many model-

driven applications.

Software Product Line Engineering (SPLE) (Pohl

et al., 2005) enforces an organized reuse of software

artifacts in order to allow for the systematic devel-

opment of a set of similar software products. Com-

monalities and differences among different members

of the product line are typically captured in variability

models, e.g., feature models (Kang et al., 1990). Dif-

ferent methods exist to connect the variability model

to a platform, which provides a (non-functional) im-

plementation of the product domain. The concept of

negative variability considers the platform as a multi-

variant product which forms the superimposition of

all product variants. In order to automatically derive

a single-variant product, the variability within the fea-

ture model needs to be resolved by specifying a fea-

ture conﬁguration.

Software Conﬁguration Management (SCM) is a

well-established discipline to manage the evolution of

software artifacts

. A sequence of product revisions

is shared among a repository. Besides storage, tradi-

tional SCM systems (Chacon, 2009; Collins-Sussman

et al., 2004; Vesperman, 2006) assist in the aspects

of collaboration and variability to a limited extent,

by providing operations like diff, branch and merge.

Internally, the components of a versioned software

artifact – most frequently, the lines of a text ﬁle –

are represented as deltas. The most commonly used

delta storage type are directed deltas, which consist

of the differences between consecutive revisions in

terms of change sequences, whereas symmetric deltas

(Rochkind, 1975) constitute a superimposition of all

revisions, annotated with revision visibilities.

Throughout this paper, we use the terms software con-

ﬁguration management and version control as synonyms.

Schwägerl F., Buchmann T., Uhrig S. and Westfechtel B..

Towards the Integration of Model-Driven Engineering, Software Product Line Engineering, and Software Conﬁguration Management.

DOI: 10.5220/0005195000050018

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

ISBN: 978-989-758-083-3

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

A combination of three mutually independent, tra-

ditional tools, one for each discipline, seems satisfac-

tory at ﬁrst glance. An arbitrary MDSE tool might

be used for the creation of a software model (e.g., a

set of UML class diagrams), a preprocessor language

for managing the variability of the software model (or

the source code generated from it), and a line-oriented

version control system to manage the evolution of the

software model (or the source code).

In this paper, we present a conceptual framework

which realizes an integrated combination of the three

disciplines. It assumes an editing model similar to

version control systems, where the developer may use

his/her preferred tool to perform changes to versioned

software artifacts within a single-version workspace.

The workspace is synchronized with a repository that

persists all existing product versions. In addition to

revision graphs, the high-level variability mechanism

of feature models is provided to deﬁne logical prod-

uct variants. Version selection is performed in both

the revision graph and the feature model. In the lat-

ter case, a feature conﬁguration is selected, which al-

lows for the combination of various logical proper-

ties in a consistent product variant. The adoption of a

version control oriented editing model to SPL devel-

opment brings the advantage of unconstrained vari-

ability: Single-version constraints do not affect the

multi-version product in the repository. By provid-

ing an integrated mechanism, the distinction between

variability in time and variability in space is blurred.

Our conceptual framework will allow to postpone the

decision, whether a change to a product constitutes a

temporal evolution step or a new product variant, until

the commit.

In the subsequent section, we outline the state

of the art with respect to the pair-wise combina-

tions MDSE/SPLE, MDSE/SCM and SPLE/SCM.

Section 3 clariﬁes the contribution of our paper, be-

fore we describe a conceptual framework (Section 4)

that allows for a combination of MDSE, SPLE and

SCM in an integrated way, by providing a uniform

versioning concept and a multi-version product model

for the repository. In Section 5, an example is con-

ducted. Section 6 includes a critical discussion, be-

fore the paper is concluded.

2 STATE OF THE ART

2.1 MDPLE/MDSE Integration

Model-Driven Product Line Engineering (MDPLE) is

motivated by a common goal of MDSE and SPLE —

increased productivity. Lifting up variability manage-

ment to the abstraction layer of modeling seems ad-

equate: Both disciplines consider models as primary

artifacts. Feature models (Kang et al., 1990) have a

well-deﬁned syntax and semantics. The platform of

the product line is provided as a domain model with a

ﬁxed or variable meta-model.

There exist a number of approaches to MDPLE

based on positive variability. They require spe-

ciﬁc tools in order to compose variable realization

fragments with the common core, typically using

model transformations (Jayaraman et al., 2007; Ziadi

and J

equel, 2007) or aspect-oriented programming

techniques (V

olter and Groher, 2007). This way, the

core model is kept small and concise, but conﬂicts

arise as soon as transformations or aspects are com-

bined to realize several features.

Approaches based on negative variability assume

a multi-variant domain model that realizes all features

of the product domain in a place. It must be syn-

tactically well-formed, but need not be semantically

meaningful (i.e., neither executable nor translatable

into a target language). Existing approaches differ in

the way how features are mapped to realization ar-

tifacts. On the one hand, mapping information may

be stored within the domain model, e.g., using an-

notations (Gomaa, 2004; Buchmann and Westfechtel,

2012), which correspond to preprocessor directives at

source code level (K

astner et al., 2009). On the other

hand, mapping information can be made explicit by

using a distinct mapping model (Heidenreich et al.,

2008; Buchmann and Schw

agerl, 2012).

A common assumption of the mentioned ap-

proaches based on negative variability is that the user

operates in a multi-variant view. When modifying

the superimposition, all variants are visible at a time,

and mapping information is added manually. The ap-

proach described in (Westfechtel and Conradi, 2009)

deviates from this editing model. Like in version con-

trol systems, the user operates in a single-version view

(ﬁltered editing, see (Sarnak et al., 1988)) and need

not map model elements to revision visibilities man-

ually. The framework presented in this paper ties on

this approach, providing higher-level abstractions for

the feature model and the domain model.

2.2 MDPLE/SCM Integration

Model Version Control subsumes the combination

of MDSE and version control (Altmanninger et al.,

2009), with the goal of lifting existing version con-

trol metaphors (commit, update, etc.) up to the ab-

straction level of models. Rather than calculating

deltas on the low-level physical representation (e.g.,

lines of text within the XMI serialization), existing

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

approaches to model versioning (Koegel et al., 2010;

Taentzer et al., 2014; Westfechtel, 2014) deﬁne op-

erations such as object insertion or attribute change.

This improves both accuracy and consistency to a sig-

niﬁcant extent. Special emphasis is put on three-way

merging, which is necessary to reconcile concurrent

modiﬁcations to versioned artifacts. Model-speciﬁc

kinds of merge conﬂicts can occur, which must be re-

solved in order to produce a consistent result. For

typical conﬂict types, the reader is referred to (Alt-

manninger et al., 2010; Koshima and Englebert, 2014;

Westfechtel, 2014). The three-way merge tool BT-

Merge (Schw

agerl et al., 2013) guarantees a consis-

tent merge result, given valid EMF model versions as

inputs.

For storing and merging model versions, change

logs are may be used to describe the performed mod-

iﬁcations. Approaches such as (Koegel et al., 2010;

Schneider et al., 2004) record the user’s changes, but

lack generality because they require a custom editor

or at least extensions to existing editors. In case no

change log is available, it needs to be reconstructed

by matching and differencing, as realized in (Oliveira

et al., 2005; Brun and Pierantonio, 2008; Taentzer

et al., 2014). The quality of the matching can be sig-

niﬁcantly improved by the use of universally unique

identiﬁers (UUIDs) that remain stable within subse-

quent revisions of model elements.

2.3 SPLE/SCM Integration

Software Product Line Evolution deals with common

problems that occur during the management of the

life-cycle of software product lines, for instance prop-

agating changes from the variability model to the plat-

form. A survey can be found in (Laguna and Crespo,

2013). In contrast to approaches discussed in this pa-

per, platform and variability model are represented as

artifacts on the same conceptual level, i.e., there is no

“versioning” relationship as in software conﬁguration

management. When lifting product line evolution up

to the modeling level, model transformations or de-

composition techniques (Heider et al., 2012) play an

important role.

As mentioned above, both SPLE and SCM man-

age variability within software artifacts. While SCM

is focused on variability in time, i.e., evolution, SPLE

provides mechanisms for variability in space, i.e., the

co-existence of similar products in terms of logical

variants. All approaches mentioned below study vari-

ability in space at a level that does not meet the re-

quirements of software product lines, which are de-

veloped in a systematic way. Furthermore, their pri-

marily targeted product space is text ﬁles.

With branches, traditional version control systems

(Chacon, 2009; Collins-Sussman et al., 2004) offer

logical variants to a limited extent. It is only possible

to restore variants that have been committed earlier

(extensional versioning, see (Conradi and Westfech-

tel, 1998)), but not to create new variants based on

a predicate on variant options, i.e., feature conﬁgura-

tions (intensional versioning).

The commercial SCM system Adele (Estublier

and Casallas, 1994) has logical variants built into

its object-oriented data model as symmetric deltas,

which are exposed to the user. Temporal variability is

realized by a versioning layer on top which relies on

directed deltas. Thus, logical and temporal versioning

are not integrated at the same conceptual level.

In (Reichenberger, 1995), an approach for or-

thogonal version management is proposed. A ver-

sion cube is formed by product, revision, and variant

space. Albeit, this approach does not consider that the

variant space may be subject to temporal evolution.

In (Zeller and Snelting, 1997), an approach to uni-

ﬁed versioning based on feature logic is presented.

Versions of artifacts (i.e., text ﬁles) are stored with

selective deltas; visibilities are controlled by feature-

logical expressions. Constraints on feature combina-

tions are expressed by version rules.

The uniform version model (UVM) presented in

(Westfechtel et al., 2001) deﬁnes a number of ba-

sic concepts (options, visibilities, constraints) for ver-

sion control, which have been initially introduced in

the context of change-oriented versioning (Munch,

1993). UVM is designed to support both intensional

and extensional versioning and does not assume a

concrete product model, i.e., it is applicable to the

MDSE context. It will provide the theoretical foun-

dation for the framework presented in this paper.

3 CONTRIBUTIONS

Despite the increased variability gained with it, in-

tensional versioning has never become popular for

industrial applications. In our opinion, this is due

to the high cognitive overhead resulting from both

the low-level representation of both the version space

(boolean variables and predicates) and the the product

space (sequences of text lines).

Our conceptual framework provides an integrated

solution to MDSE, SPLE and SCM, which addresses

several drawbacks such as the constrained variability

which is common to the MDPLE approaches, the lack

of logical versioning concepts in model version con-

trol, and inadequacies concerning the low-level repre-

sentation of both the variant space and product space

TowardstheIntegrationofModel-DrivenEngineering,SoftwareProductLineEngineering,andSoftwareConfiguration

Management

feature space

revision space

product space

option space

mapped

versioned

versioned by

Figure 1: The roles of the revision, the feature and the prod-

uct space within the repository. Abstractions represented by

dashed lines are invisible to the user.

in integrated SPLE/SCM solutions. Our framework

uses the UVM described in the previous section as its

theoretical foundation and provides higher-level ab-

stractions for it. A prototype called SuperMod (Su-

perimposition of Models) is currently under develop-

ment, which will use EMF both for its own implemen-

tation and as the primarily targeted product space.

3.1 The Conceptual Framework

As depicted in Figure 1, our conceptual framework

consists of elements which are deﬁned by set theory

and distributed over three spaces: A revision space,

which controls the temporal evolution of both the

product space and the feature space. Elements of the

product space are also versioned with respect to the

feature space in order to achieve logical variability.

Both the revision space and the feature space abstract

from a low-level option space.

The product space is represented as a superimpo-

sition of product versions. In SPLE, this corresponds

to negative variability, and in SCM to symmetric

deltas, respectively. The superimposition allows for

extrinsic variability (Westfechtel and Conradi, 2009);

single-version restrictions do not apply for the multi-

version representation. The connection between the

product space and the version space is established

by visibilities (also known as presence conditions in

SPLE, see (Czarnecki and Kim, 2005)), boolean ex-

pressions on the options of the version space, which

are assigned to elements of the product space and

the feature space. The decision which elements are

variable, i.e., to which elements visibilities may be

assigned, depends on the speciﬁc product space im-

plementation. This allows for an adjustable level of

granularity with respect to versioned elements. The

prototype SuperMod will support heterogeneous ﬁle

systems as product spaces, consisting of EMF models

and further contents such as plain text or XML ﬁles.

The revision space is inherited from revision con-

trol systems and utilizes a directed acyclic revision

graph. Logical variability is managed by a feature

model, which provides a high-level representation of

logical properties of a system. Internally, elements

of both the revision and the feature space are mapped

onto options which are managed by the option space

that realizes UVM as described in (Westfechtel et al.,

2001). This mapping happens behind the scene, while

only the higher-level abstractions of revision graph

and feature model/conﬁguration are presented to the

user for version selection and version space editing.

The feature model plays a dual role: For the revi-

sion space, it is versioned the same way as the product

space; for the product space, it incorporates an addi-

tional variability model.

3.2 An Integrated Editing Model

As illustrated in Figure 2, our conceptual framework

deﬁnes an editing model oriented towards version

control metaphors. The basic assumption is that the

user edits a single version selected by a choice (the

read ﬁlter), but the changes affect multiple versions

which are deﬁned by a so called ambition (the write

ﬁlter). Editing a product version consists of three –

partly automated – steps:

checkout

revision space

multi-version product space

ambition choice

...

defines

commit

modifies

visibilities

multi-version

feature space

option space

single-version

feature space

single-version

product space

...

repository workspaceuser

Figure 2: The integrated editing model underlying our conceptual framework.

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

1. Checkout: The user performs a version selection

(a choice) in the repository. In the revision graph,

the selection comprises a single revision. In the

feature space, a feature conﬁguation has to be

speciﬁed. A single-version copy of the repository,

ﬁltered by the selected version, is loaded into the

workspace.

2. Modify: The user applies a set of changes to the

single-version product and/or to the feature model

in the workspace.

3. Commit: The changes are written back to the

repository. For this purpose, the user is prompted

for an additional selection of a partial feature

conﬁguration (an ambition) to delineate the log-

ical scope of the performed changes. Visibilities

of versioned elements are updated automatically,

and a newly created revision is submitted to the

repository.

3.3 Beneﬁts of an Integrated Approach

Taking into account the remarks given in the previ-

ous and current section, our conceptual framework

advances the state of the art by the following aspects:

Unconstrained Variability. Typically, SPLE tools

based on negative variability require that the

multi-variant domain model is valid with respect

to its meta-model. This may impede variability to

a certain extent. E.g., in an intrinsic multi-variant

UML model, it is not allowed that a class has dif-

ferent names in different versions. By means of an

extrinsic product space model, we allow models

to vary arbitrarily within the multi-version repos-

itory; single-version workspace models are still

constrained by their respective meta-models.

Non-Destructive Updates. Combined SPLE/SCM

solutions that assume orthogonality between the

revision and the variant space, e.g., (Reichen-

berger, 1995), are faced with destructive updates:

A change to the logical visibility of an element

is not limited to the current revision, but global,

which may lead to an inconsistent reproduction

of old revisions. Our conceptual framework

guarantees the immutability of revisions.

Reduction of Cognitive Complexity. By the adop-

tion of typical version control metaphors (e.g., up-

date or commit), our approach reduces the cogni-

tive complexity for the development of a model-

driven software product line. The user applies

his/her local changes in a single-version view, and

visibilities are updated automatically. The user is

neither faced with difﬁcult architectural decisions

with respect to a multi-variant domain model (a

common problem with negative variability), nor

with the necessity to describe feature realizations

by means of model transformations (as in SPLE

approaches based on positive variability).

Uniform Versioning. Our conceptual framework

provides a uniform versioning concept for logical

and temporal changes. Not until writing back a

change to the repository, the user has to decide

if it incorporates a new revision of an existing

variant or a new variant that co-exists in parallel.

Multi-Resource EMF Models. Many MDPLE

tools, e.g. (Heidenreich et al., 2008; Buchmann

and Schw

agerl, 2012), as well as model version-

ing tools such as (Schw

agerl et al., 2013), assume

that a model is a self-contained single-resource

entity. Our conceptual framework preserves

the integrity of cross-resource links in case

multiple EMF resources are submitted to version

control. This applies even for references to the

meta-model, which may vary, too. Furthermore,

non-model (plain text or XML) ﬁles may be

versioned.

Tool Independence. Our conceptual framework as-

sumes a purely state-based environment; it does

not require change logs which would in turn need

an integration of custom recording mechanisms

into the tools which are used to modify elements

of the workspace. Changes are reconstructed by

differencing, using UUIDs if available.

4 FORMALIZED APPROACH

In this section, we detail our contributed conceptual

framework. The versioning mechanism and the edit-

ing model described in the previous subsection are

formalized based on the notions introduced by the

uniform version model (Westfechtel et al., 2001). An

extrinsic meta-model for the product space is formal-

ized by means of several Ecore models.

4.1 The Option Space

The option space – which is mapped by both the revi-

sion space and the feature space – is deﬁned by a set

of concepts described in (Westfechtel et al., 2001) us-

ing set theory and propositional logic. In Sections 4.2

and 4.3, we will show how the mapping between fea-

ture/revision space and option space is realized, be-

fore an integration is described in Section 4.4.

Options. An option represents a (logical or tempo-

ral) property of a software product which is either

TowardstheIntegrationofModel-DrivenEngineering,SoftwareProductLineEngineering,andSoftwareConfiguration

Management

present or absent. The option space deﬁnes a global

option set:

O = {o

, . . . , o

} (1)

Choices and Ambitions. A choice is a conjunction

over all options, each of which occurs in either posi-

tive or negated form:

c = b

∧ . . . ∧ b

, b

∈ {o

, ¬o

} (i ∈ {1, . . . , n}) (2)

An ambition is an option binding which allows for

unbound options (b

= true, such that this component

can be eliminated from the conjunction):

a = b

∧ . . . ∧ b

, b

∈ {o

, ¬o

, true} (i ∈ {1, . . . , n})

(3)

Options occurring positively or negatively in the

conjunction are bound. Thus, a choice is a complete

binding and designates a speciﬁc version, whereas an

ambition may have unbound options (partial binding)

in order to describe a set of versions. The version

speciﬁed by the choice is used for editing, whereas the

change affects all versions speciﬁed by the ambition.

The ambition must include the choice; otherwise, the

change would be performed on a version located out-

side the scope of the change. Formally, this means

that the choice must imply the ambition:

c ⇒ a (4)

Version Rules. The option space deﬁnes a set of

version rules — boolean expressions over a subset of

deﬁned options. The rule base R is composed of a

set of rules ρ

, . . . , ρ

all of which have to be satisﬁed

by an option binding in order to be consistent. Thus,

we may view the rule base as a conjunction:

R = ρ

∧ . . . ∧ ρ

(5)

A choice c is strongly consistent if it implies the rule

base R :

c ⇒ R (6)

In the case of ambitions, only the existence of a

consistent version is required. An ambition is weakly

consistent if it overlaps with the constrained option

space:

R ∧a 6= f alse (7)

Visibilities. Each element e of the versioned prod-

uct space may deﬁne a visibility v(e) — a boolean ex-

pression over a subset of deﬁned options. An element

e is visible under a choice c iff its visibility is implied

by the choice, i.e., it evaluates to true given the option

bindings of the choice:

c ⇒ v(e) (8)

Filtering. The operation of ﬁltering a product space

by a choice c can be realized as a conditional copy,

where elements e that do not satisfy the choice (c 6⇒

v(e)) are omitted.

In case an element e does not deﬁne a visibility,

we implicitly assume v(e) = true (global visibility).

The visibility f alse, in turn, would correspond to a

deletion from the repository.

4.2 The Feature Space

The option space introduced in Section 4.1 is appli-

cable to intensional versioning. However, concepts

such as options, constraints and choices should not be

exposed to the user directly because they are repre-

sented at a too low conceptual level. Feature models

(Kang et al., 1990) meet the requirements of SPLE

in a satisfactory way. We show how feature modeling

concepts can be mapped to the low-level option space.

In Section 4.7, we will revisit the feature space in its

role of an additional product space.

Feature Options. A feature is a discriminating log-

ical property of a software product. It is adequate to

map each feature to a feature option f ∈ O

, where

⊆ O.

Feature Dependencies and Constraints. Feature

models offer several high-level abstractions: First of

all, features are organized in a tree, which makes them

existentially depend on each other. Non-leaf features

are either AND- or OR-features. If an AND-feature

is selected, its mandatory child features have to be se-

lected as well. In the case of an OR-feature, exactly

one child has to be selected (exclusive disjunction).

Table 1: Mapping feature models to option space constraints.

Pattern Transformation

root feature f

child feature f

of parent feature f f

⇒ f

AND feature f and mandatory child f

f ⇒ f

OR feature f and child features f

, . . . f

f ⇒ ( f

⊗ . . . ⊗ f

)

excludes f

¬( f

∧ f

)

requires f

⇒ f

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

Table 2: Mapping revision graphs to option space constraints.

Pattern Transformation

initial revision r

new revision r

after revision r

i−1

⇒ r

i−1

mutually exclusive branches with origins r

and r

¬(r

∧ r

)

Additionally, cross-tree relationships may be deﬁned:

requires and excludes constraints.

It is straightforward to map feature models to

propositional logic (see Table 1).

Version Selection. Feature conﬁguations describe

the characteristics of a single product of the product

line and thus may be considered as a version selection

within the feature space. A feature conﬁguration is

derived from a feature model by assigning a selection

state to each feature. A feature conﬁguration can be

mapped to a choice or ambition by setting the binding

for a feature option f

∈ O

as follows:







if feature f

is selected.

¬ f

if feature f

is deselected.

true if no selection is provided for f

(9)

Please note that only partial feature conﬁgurations

allow for unbound options (b

= true). These may

only be speciﬁed for ambitions, not for choices.

4.3 The Revision Space

In SCM, the evolution of a software product is ad-

dressed. The history of a repository is typically rep-

resented by a revision graph. Revision control de-

viates from variability management in two aspects.

First, revisions are organized extensionally, i.e., only

revisions that have been committed earlier may be

checked out. Second, revisions are immutable: Once

committed, they are expected to be permanently avail-

able, and should not be affected by destructive up-

dates (see Section 3.3).

Revision Options. Temporal versioning can be re-

alized by revision options (called transactions options

in (Westfechtel et al., 2001)) r ∈ O

, where O

⊆ O.

For each commit, a new revision option is introduced

automatically. In order to achieve immutability, nei-

ther a revision option itself nor a visibility referring to

it may ever be deleted.

Revision Constraints. Automatically derived revi-

sion constraints may reduce the size of the revision

space considerably. As summarized in Table 2, impli-

cations are introduced for consecutive revisions trans-

parently. Furthermore, exclusion constraints are in-

troduced for branches intended to co-exist in parallel.

Choice Selection. A version in the revision space is

selected as a single revision r

by the user. Since each

revision option requires the corresponding options of

its predecessor revision (r

⇒ r

i−1

), a choice in the re-

vision space is created by conjunction of the selected

revision with all of its predecessors. All other revi-

sions appear in a negative binding. For each revision

option r

∈ O

within a revision choice c

, the option

binding b

is determined as:







if r

is the selected revision r

or a predecessor of it.

¬r

else.

(10)

Choices referring to the revision space are neces-

sarily complete since the binding true may never ap-

pear. The number of selectable versions equals the

number of available revision options (extensional ver-

sioning).

Ambition Selection. In contrast to choices, ambi-

tions in the revision space only consist of one bound

option, namely a newly introduced revision option

which is a successor of the previously selected revi-

sion choice. As a consequence, within a revision am-

bition a

, exactly one revision r

occurs in a positive

state. Bindings for other revision options are implic-

itly set to true.

= r

, r

is a successor of r

. (11)

Rather than including all predecessors of the se-

lected revision, in an ambition, only the new revi-

sion itself occurs. This results in much shorter vis-

ibilities when taking into account the editing model

shown in Section 4.8. Ambitions of this form are

weakly consistent since constraints ρ

of the form

⇒ r

i−1

(see Table 2) will be evaluated as follows:

∧ (r

⇒ r

) = r

∧ r

6= f alse.

4.4 Hybrid Versioning

The combination of the revision and the feature space

causes interactions between elements of the revision

TowardstheIntegrationofModel-DrivenEngineering,SoftwareProductLineEngineering,andSoftwareConfiguration

Management

space and the and variant space. Thus, we provide the

following extensions to our framework.

Hybrid Option Space. In hybrid versioning, the

option set is decomposed into two disjoint subsets,

feature options and revision options:

O = O

∪O

(12)

An analogous decomposition is applied to the rule

base.

R = R

∪R

(13)

Hybrid Choice Selection. A version selection has

to be performed in both the revision and the feature

space. Correspondingly, a hybrid choice is a complete

option binding on O

∪O

. It must be ensured that

each selected feature option is visible under the subset

of the choice that refers to the revision space.

c = c

∧ c

(14)

Hybrid Ambition Speciﬁcation. From the user’s

perspective, the speciﬁcation of a hybrid ambition

does not differ from a speciﬁcation in the feature

space. A conjunction of the selected feature conﬁgu-

ration a

and a revision option r

, which is introduced

transparently as a successor of the revision r

selected

for the choice, is formed automatically.

a = r

∧ a

(15)

Since a revision ambition is always weakly con-

sistent (see above), an ambition in the hybrid version

space only needs to be weakly consistent with respect

to the feature part of the rule base:

∧ a

6= f alse (16)

Similarly, it is sufﬁcient to require that the feature

part of the choice and the ambition imply each other:

⇒ a

(17)

4.5 Versioned File Systems

The product space of our conceptual framework is

formalized by means of several Ecore class diagrams.

In order to provide support for multi-resource mod-

els (see Section 3.3), complete sub-trees of ﬁle sys-

tems (e.g., an Eclipse project) will be submitted to

version control. As shown in the class diagram in

Figure 3, ﬁles and folders are organized hierarchi-

cally using the composite design pattern. The ab-

stract class VersionedElement provides versioned

elements with an optional visibility.

VersionedElement Visibility

VersionedResource

VersionedFile

+ contentType : String

+ name : String

VersionedFolder

contents

0..1

Figure 3: Ecore class diagram for the meta-model of ver-

sioned ﬁle systems in our conceptual framework.

Our conceptual framework supports different ﬁle

content types. For each content type, a speciﬁc

pair of import/export model transformations needs

to be deﬁned in order to convert the intrinsic multi-

version representation into a single-version ﬁle in the

workspace, which may be modiﬁed by the user with

his/her favorite editor (in order to ensure tool inde-

pendence, see Section 3.3). As one representative for

ﬁle content types, EMF is discussed in the next sub-

section. Similarily, plain text ﬁles and XML ﬁles will

be supported in the prototype SuperMod.

4.6 Multi-vrsion EMF Models

The meta-model shown in Figure 4 incorporates the

following design decisions with respect to multi-

variant EMF models: (a) unconstrained variability

(see Section 3.3), (b) versioned meta-data, (c) vari-

able object classes, and (d) variable object containers.

Considering the EMF product space meta-model,

all elements of the EMF ﬁle content type are variable

(a). Due to (d), an object must be able to have dif-

ferent containers in different versions. Thus, the con-

tainment hierarchy of objects inside a resource is ﬂat-

tened. We assume a unique identiﬁer (uuid) assigned

to each object. Objects may vary in their class (c) and

in the values for their structural features (attributes

and references). Attribute values are represented by

string literals; reference values may be internal, by

deﬁning a link to an existing object, or external, by

specifying a workspace-global object URI.

In order to meet design decision (b), classes and

structural features are divided into the categories in-

ternal and external, too. Internal classes/features de-

ﬁne a reference to a co-versioned meta-object, while

external classes/features are identiﬁed by their pack-

age URI and class name, or their feature name, re-

spectively. This way, the conformance relationship

between objects and their corresponding classes is

variable (c). Technically, a multi-version EMF model

represents two modeling layers (model and meta-

model) at the same intrinsic modeling level, which

enables co-versioning of models, meta-models, and

conformance relationships between those.

The import/export transformation pair for the

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

VersionedElement

VersionedModel

Object

ClassRef

FeatureRef Value

InternalFeatureRef

ExternalClassRef

+ uuid : String

+ uri : String

+ name : String

InternalClassRef

ExternalFeatureRef

+ pkUri : String

+ name : String

AttributeValue

+ literal : String

ExternalRefVal

+ uri : String

InternalRefVal

VersionedFile

linkTarget

featureObj

classObj

Figure 4: Simpliﬁed Ecore class diagram for the meta-model of the multi-version EMF product space.

EMF ﬁle content type maps each multi-version ob-

ject of the repository to a corresponding EObject in

the workspace, setting attribute and reference values

accordingly. The ﬂattened containment links are con-

verted back into a hierarchical object tree.

4.7 Multi-version Feature Models

Our conceptual framework controls the evolution of

an additional product space, the feature model which

describes the feature space introduced in Section 4.2

at a higher level of abstraction. The meta-model

shown in Figure 5 assumes that the following modiﬁ-

cations are supported: (a) insertion of a new (manda-

tory or optional, AND or OR) feature below a ﬁxed

parent feature, (b) deletion of an existing feature, and

relationship. Within the visibilities of elements of

the feature models, only revision options are allowed.

Additionally to their higher-level abstractions, low-

level options and constraints are versioned within the

feature space. This is not shown in the ﬁgure, but im-

plied in the example in Section 5.

4.8 The Formalized Editing Model

Below, we ﬁnalize our editing model sketched in Sec-

tion 3.2. In contrast to (Westfechtel et al., 2001),

the ambition is speciﬁed at commit-time; the decision

whether a change corresponds to the realization of an

existing or a new feature, or to a new revision of the

checked-out product conﬁguration, can be postponed.

Versioned

Element

Feature

Relationship

+ name : String

+ mandatory : Boolean

AndFeature

Feature

Model

0..1

parent

children

source

target

OrFeature

Requires Excludes

root

Figure 5: Ecore class diagram for the meta-model of multi-

version feature models.

1. The user selects a revision r

from the revision

graph. The derived choice is c

= r

∧ ··· ∧ r

2. The feature model is ﬁltered by selecting elements

which satisfy the revision choice (c

⇒ v(e

))

and are exported into the workspace.

3. The user performs a choice c

on the ﬁltered fea-

ture model by specifying a completely bound fea-

ture conﬁguration. Options for invisible features

are automatically negatively bound: b

= ¬ f

4. The effective choice c is calculated as the conjunc-

tion c = c

∧ c

. It must be strongly consistent ac-

cording to the rule base: c ⇒ R .

5. The product space is ﬁltered by selecting elements

which satisfy the choice (c ⇒ v(e

)) and then

are exported into the workspace.

6. Within the workspace, the user applies modiﬁca-

tions to the ﬁltered product space and/or to the ﬁl-

tered feature model. Updates are broken down to

insertions and deletions of element versions. Both

spaces are imported back into their multi-version

representation and merged into the repository.

7. A new revision option r

is added to O

. The con-

straint r

⇒ r

is added to R

8. Next, the user speciﬁes an (incomplete) feature

conﬁguration a

that delineates the scope of the

change. The ambition must be weakly consistent

according to the rule base: R

∧ a

6= f alse. Fur-

thermore, the ambition must be implied by the

choice: c

⇒ a

9. The applied modiﬁcations are written back under

the effective ambition a. For changes to the feature

model, a = r

; for changes to the product space,

a = r

∧ a

. Each modiﬁed (inserted or deleted)

element e is processed as follows:

For these checks, the modiﬁed option set and rule base

and R

are taken into account. Furthermore, bindings

for inserted features are omitted from c

, and bindings for

deleted features from a

, respectively.

TowardstheIntegrationofModel-DrivenEngineering,SoftwareProductLineEngineering,andSoftwareConfiguration

Management

• Inserted elements e

ins

are appended to the prod-

uct space (or to the feature model). Their visi-

bility is set to the ambition: v(e

ins

) := a.

• For re-inserted elements e

reins

, which have not

been visible under c, the visibility is modiﬁed

as follows: v(e

reins

) := v

old

reins

) ∨ a.

• Deleted elements e

del

remain in the multi-

version product space (feature model). Their

visibility is set to v(e

del

) := v

old

del

) ∧ ¬a.

5 EXAMPLE

We illustrate our approach by means of an example

which refers to an evolving product line of ﬂow dia-

grams. Flow diagrams are connected graphs with a

single start node (no incoming, one outgoing control

ﬂow, cardinality 0/1), multiple activity nodes (1/1),

binary decision nodes (1/2), join nodes (+/1), and end

nodes (1/0). Start and end nodes are represented by

rounded rectangles, decision nodes by diamonds, and

join nodes by circles, respectively. We have chosen

this meta-model as it signiﬁcantly limits variability

(e.g., multiple successors for an activity) within the

workspace. Within the repository, the unconstrained

multi-version representation (see Section 4.6) is used.

We will develop a product line of ﬂow diagrams

in subsequent steps: In revision 1, the product space

is initialized by performing a global change that only

affects the revision space. Next, two independent

changes are applied that correspond to two mutually

exclusive features. In the last revision, a change is re-

assigned to a new feature, mapping a temporal change

to a logical feature retrospectively.

Initializing the Repository. In the beginning, the

version space consists of a revision graph that

only contains the initial revision r

and a feature

model with a mandatory root feature R. The prod-

uct space consists of an empty ﬂow diagram.

Step 1. In order to populate our empty product space,

we need to specify a choice. At the moment, there

is only one possibility allowed by the rule base:

c = r

∧ f

. Figure 6, step 1, shows the modiﬁca-

tions applied: the insertion of a start node, the ac-

tivity node v and an end node. The change is com-

mitted as a new revision r

, resulting in the ambi-

tion a = r

∧ f

. A constraint r

⇒ r

is added to

transparently

Step 2. As there is no variability deﬁned in the fea-

ture model yet (the selection of f

is mandatory),

it sufﬁces to select a revision. A selection of re-

vision 1 results in the choice c = r

∧ r

∧ f

. Af-

ter checkout, v is locally deleted and a sequence

of activity nodes consisting of w and x is inserted

(cf. Figure 6, step 2). Furthermore, an optional

feature A is introduced, which automatically adds

the constraint f

⇒ f

to R

. For the commit, we

specify a feature conﬁguration with A selected, re-

sulting in a = r

∧ f

. Please note that the per-

formed change is not visible for products which

do not include A.

Step 3. Once again, the latest revision is chosen. In

the feature space, A is deselected, which generates

c = r

∧ r

∧ f

∧ ¬ f

. Thus, the checked-

out product version is not affected by the deletion

of v performed in revision 2. As shown in Fig-

ure 6, step 3, an additional feature B is introduced,

which excludes A due to an OR relationship. This

results in an addition of the constraints f

⇒ f

Analogous constraints are inserted for subsequent revi-

sions.

workspace before workspace after

feature model product feature model

product

choice

revision feature conf.

ambition

revision

feature conf.

R: selected

A: deselected

R: selected

A: deselected

B: selected

step

R: selected

A: selected

R: selected

A: deselected

B: selected

R: selected

A: deselected

B: selected

C: deselected

Figure 6: Speciﬁed choices and ambitions as well as local modiﬁcations performed during subsequent update/commit cycles.

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

Table 3: Visibilities of the superimposed feature model and product space after revision 4 (hidden from the user). For the

reasons of clarity and comprehensibility, visibilities of ﬂow edges have been omitted.

Element Visibility Expression

Feature Root feature R, option f

and constraint f

Model Feature A, option f

and constraint f

⇒ f

Feature B, option f

; constraints f

⇒ f

and f

⊗ f

Feature C, option f

and constraint f

⇒ f

Product Start and end node r

∧ f

Space Activity node v r

∧ f

∧ ¬(r

∧ f

) ∧ ¬(r

∧ f

)

Activity nodes w and x r

∧ f

Guard y and join node r

∧ f

∧ ¬ f

∧ f

∧ ¬(r

∧ ¬ f

)

Activity node z r

∧ f

∧ ¬ f

∧ f

and f

⊗ f

. Within the workspace, we perform

a corresponding realization: the replacement of v

by a new activity node z guarded by a conditional

node y. Finally, we commit the change under a

feature conﬁguration in which A is deselected but

B is selected: a = r

∧ f

∧ ¬ f

∧ f

Step 4. After revision 3 has been committed, we

come to the conclusion that the guard y should not

realize feature B, but an optional child feature C.

This retrospective feature assignment can be per-

formed by checking out the latest revision with

feature B included: c = r

∧ · · · ∧ r

∧ f

∧ ¬ f

∧

. Then, a feature C is introduced and the guard

as well as the join node are deleted (cf. Figure 6,

step 4). The change is associated with a negation

of C’s feature option: a = r

∧ f

∧¬ f

∧ f

∧¬ f

As a consequence, in revision 4, the guard y is

only visible for products which include C. In case

revision 3 is restored, y’s visibility still only de-

pends on B (immutability).

Results. All modiﬁcations have been applied in a

single-version view based on the ﬁltered editing

model deﬁned in Section 4.8. Figure 7 shows the

superimposition of the product space after revi-

sion 4. Table 3 shows visibilities of elements of

both the feature model and the product space. Vis-

ibility changes, which affect elements such as v or

y, are characterized by multiple revision options

inside an expression.

Figure 7: The superimposed product space in its extrinsic

representation (hidden from the user).

Beneﬁts Revisited. To conclude this example, we

revisit the beneﬁts claimed in Section 3.3.

The extrinsically represented model shown in Fig-

ure 7 could not have been created using a single-

version editor because it violates the constraints im-

posed by the ﬂow diagram meta-model (see above).

Our approach, in contrast, allows for unconstrained

variability. The management of visibilities was fully

automated; we have focused on local modiﬁcations

and the deﬁnition of the editing scope).

In an unﬁltered editing model, the superimposi-

tion as well as the option expressions would have been

necessarily speciﬁed manually by the user. In our ex-

ample, all versioning information is created automat-

ically based on the user-speciﬁed partial feature con-

ﬁgurations for the ambitions (three in total). Thus, the

ﬁltered editing model brings a signiﬁcant advantage

in terms of reduced cognitive complexity. Within the

workspace, a hypothetical editor for single-version

ﬂow diagrams is employed, which exempliﬁes the ad-

vantage of tool independence.

Within the last two steps, the uniform representa-

tion of revisions and features has been utilized to map

an initially temporal change to a new feature. Fur-

thermore, we have shown that the update performed

in step 4 is non-destructive.

6 DISCUSSION

A thorough evaluation of our approach will be feasi-

ble as soon as a stable implementation of SuperMod

is available. In advance, we discuss some potential

(conceptual and/or technical) problems, for each of

which we sketch possible solutions.

Limited Awareness of other Versions. An ad-

vantage adopted from UVM is that the user

may operate in a single-version view. On the

downside, ﬁltered editing also reduces awareness

of other versions that are invisible in the local

workspace. The information which variants a

modiﬁed element belongs to, i.e., its visibility,

TowardstheIntegrationofModel-DrivenEngineering,SoftwareProductLineEngineering,andSoftwareConfiguration

Management

is hidden from the user. This is in contrast to

MDPLE approaches based on negative variability,

where the whole superimposition is visible (and

editable), including mapping information (i.e.,

visibilities). Thus, the advantage of reduced

complexity is instantaneously linked to the

disadvantage of limited awareness.

Mitigating the restriction of a complete choice

might increase the editable subset of the super-

imposition, but then product consistency control

becomes more important (see below). Further-

more, this does not yet solve the problem of hid-

den visibilities. As a solution, we might provide a

specialized editor to support visibility-aware, par-

tially ﬁltered multi-version editing. Rather than

actually ﬁltering invisible elements, they could be

shaded in gray, as realized in the tool MODPL

(Buchmann and Westfechtel, 2012), and protected

against local modiﬁcations. However, this would

remove the beneﬁt of tool independence.

Product Consistency Control. Currently, our con-

ceptual framework does not ensure the consis-

tency of extrinsically represented products. Con-

sidering multi-variant EMF models, consistency

violations might concern referential integrity, the

containment hierarchy, type correctness, or the

cardinality of structural features. Additionally,

each meta-model may deﬁne its own context-

sensitive consistency constraints using the Object

Constraint Language (OCL).

In Section 4.1, we have introduced version rules.

Although they ensure that no inconsistent ver-

sions are speciﬁed (e.g., mutually exclusive fea-

tures), they cannot make any assertions to an ex-

trinsically represented product version, or a set

thereof. For this purpose, additional product rules

should be enforced before products are converted

into their single-version representation using the

export transformation. In (Westfechtel, 2014),

generic EMF product rules have been investigated

in the context of three-way merging. The tool

FAMILE (Buchmann and Schw

agerl, 2012) pro-

vides an OCL extension to check and repair the

consistency of derived products.

Scalability. The representation of the product space

(including visibilities) as a superimposition will

result in a growing memory consumption. Due

to the immutability of revisions, product space

elements will never be effectively deleted from

the repository. Furthermore, the evaluation of the

constantly growing visibilities will be noticeable

in terms of higher commit and update runtimes.

We propose three optimizations.

• Hierarchical Propagation of Visibilities: Prod-

uct space elements are organized hierarchi-

cally. Due to existential dependency, the effec-

tive visibility of an element might be deﬁned by

conjunction with its parent visibility. When a

tree of elements is modiﬁed, only its root ele-

ment’s visibility needs to be updated.

• Substitution of Ambition Expressions: The

mechanism of writing back changes using an

ambition results in corresponding option ex-

pressions appearing in the visibility of all af-

fected elements. If these expressions become

too long, they might be substituted by an arti-

ﬁcial option ∆

. The constraint ∆

⇒ a is then

added to the rule base once, and the change is

run under ∆

, with the same effect.

• Global Storage for Visibilities: Visibilities are

directly contained in product space elements,

which will result in duplicates. Storing iden-

tical visibilities within a global data structure,

and caching evaluation results for a given op-

tion binding, might reduce memory consump-

tion and runtime. A technically sound solution

is described in (Munch, 1993, Section 6.6).

Collaborative Editing. One of the greatest advan-

tages of SCM systems is the support for collab-

orative development performed by multiple de-

velopers. In its current state, our editing model

does not explicitly support collaboration. Concur-

rent changes are committed as multiple succes-

sors of a base revision. In order to achieve op-

timistic versioning, it should be permitted to cre-

ate a new revision with several predecessors. This

may be achieved by generalizing step 1 of the edit-

ing model presented in Section 4.8 inasmuch as

a non-empty set of mutually unrelated revisions

may be selected. As soon as mutually unrelated

branches are merged, the corresponding exclusion

constraint (see Table 2) needs to be removed.

In addition to adaptations to the version space

and the editing model, collaborative editing will

require support for three-way merging in the

workspace. Tools and approaches for the detec-

tion and resolution of merge conﬂicts have been

discussed in Section 2.2.

Added Value for the End User. We have described

the integrated editing model in a very abstract

way, and the pragmatic question arises, how end

users, being SPL developers and SCM users,

might gain advantage of our approach.

For SPL developers, the main advantage is the

mentioned reduction of cognitive complexity,

which may be achieved by (1) the fact that modi-

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

ﬁcations are performed to ﬁltered versions of the

product line rather than to a multi-variant do-

main model, (2) the concepts of choices and ambi-

tions being expressed in a user-oriented way, mak-

ing manual feature annotations obsolete, and (3)

improved consistency support gained by version

rules, which may avoid product line inconsisten-

cies in advance. The development of an intuitive

user interface will be necessary, especially in or-

der to facilitate the speciﬁcation of feature con-

ﬁgurations, which is a frequent task in the ﬁltered

editing model.

For SCM users, the added value is the possibility

of introducing logical options, i.e., features, in ad-

dition to temporal options (revisions). When com-

pared to the widespread concept of branches, fea-

tures allow for an exponential number of product

versions: n branches represent n variants, while

n features allow for up to 2

variants (this number

may be signiﬁcantly constrained by the rule base).

7 CONCLUSION

We have explored the conceptual groundwork for

an integrated solution to MDSE, SPLE and SCM.

Our presented approach is purely state-based, has an

extrinsic product space model allowing for uncon-

strained variability, and supports intensional and ex-

tensional versioning uniformly. By providing higher-

level abstractions, version selection is eased signiﬁ-

cantly. In an example, we have shown that this uni-

form handling enables a high level of automation and

a reduction of cognitive complexity.

Although it will be far from trivial to meet the spe-

ciﬁc requirements of the three disciplines by a sin-

gle tool, we are convinced that the disciplines can

proﬁt from each other with respect to the way how

tools are used. For instance, the ﬁltered editing model

borrowed from SCM can increase comprehensibility

in MDPLE, while feature models provide a powerful

logical extension to temporal versioning.

In addition to the technical realization of our ap-

proach, we think that in future, the deﬁnition of a de-

velopment process would be advantageous in order to

combine the ﬁltered editing model with MDPLE. For

evaluation purposes, we are looking for a case study

of industrial scale, which would allow for a quantita-

tive evaluation against approaches which rely on an

unﬁltered editing model.

REFERENCES

Altmanninger, K., Schwinger, W., and Kotsis, G. (2010).

Semantics for accurate conﬂict detection in SMoVer:

Speciﬁcation, detection and presentation by example.

International Journal of Enterprise Information Sys-

tems, 6(1):68–84.

Altmanninger, K., Seidl, M., and Wimmer, M. (2009). A

survey on model versioning approaches. Interna-

tional Journal of Web Information Systems (IJWIS),

5(3):271–304.

Brun, C. and Pierantonio, A. (2008). Model differences

in the Eclipse Modelling Framework. UPGRADE,

IX(2):29–34.

Buchmann, T. and Schw

agerl, F. (2012). Ensuring well-

formedness of conﬁgured domain models in model-

driven product lines based on negative variability.

In Proceedings of the 4th International Workshop

on Feature-Oriented Software Development, FOSD

2012, pages 37–44, New York, NY, USA. ACM.

Buchmann, T. and Schw

agerl, F. (2012). FAMILE: tool

support for evolving model-driven product lines. In

orrle, H., Botterweck, G., Bourdells, M., Kolovos,

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

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

at the 8th European Conference on Modelling Foun-

dations and Applications, CEUR WS, pages 59–62,

Building 321, DK-2800 Kongens Lyngby. Technical

University of Denmark (DTU).

Buchmann, T. and Westfechtel, B. (2012). Mapping fea-

ture models onto domain models: ensuring consis-

tency of conﬁgured domain models. Software and Sys-

tems Modeling.

Chacon, S. (2009). Pro Git. Apress, Berkely, CA, USA, 1st

edition.

Collins-Sussman, B., Fitzpatrick, B. W., and Pilato, C. M.

(2004). Version Control with Subversion. O’Reilly,

Sebastopol, CA.

Conradi, R. and Westfechtel, B. (1998). Version models for

software conﬁguration management. ACM Computing

Surveys, 30(2):232–282.

Czarnecki, K. and Kim, C. H. P. (2005). Cardinality-based

feature modeling and constraints: a progress report.

In International Workshop on Software Factories at

OOPSLA’05, San Diego, California, USA. ACM.

Estublier, J. and Casallas, R. (1994). The Adele conﬁgura-

tion manager. In Tichy, W. F., editor, Conﬁguration

Management, volume 2 of Trends in Software, pages

99–134. John Wiley & Sons, Chichester, UK.

Gomaa, H. (2004). Designing Software Product Lines with

UML: From Use Cases to Pattern-Based Software Ar-

chitectures. Addison-Wesley, Boston, MA.

Heidenreich, F., Kopcsek, J., and Wende, C. (2008). Fea-

tureMapper: Mapping features to models. In Compan-

ion Proceedings of the 30th International Conference

on Software Engineering (ICSE’08), pages 943–944,

Leipzig, Germany.

TowardstheIntegrationofModel-DrivenEngineering,SoftwareProductLineEngineering,andSoftwareConfiguration

Management

Heider, W., Rabiser, R., and Gr

unbacher, P. (2012). Facil-

itating the evolution of products in product line engi-

neering by capturing and replaying conﬁguration de-

cisions. International Journal on Software Tools for

Technology Transfer, 14(5):613–630.

Jayaraman, P. K., Whittle, J., Elkhodary, A. M., and Gomaa,

H. (2007). Model composition in product lines and

feature interaction detection using critical pair anal-

ysis. In Proceedings of the 10th International Con-

ference on Model Driven Engineering Languages and

Systems (MoDELS), pages 151–165, Nashville, USA.

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

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

main analysis (FODA) feasibility study. Technical Re-

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

sity, Software Engineering Institute.

astner, C., Apel, S., Trujillo, S., Kuhlemann, M., and Ba-

tory, D. S. (2009). Guaranteeing syntactic correctness

for all product line variants: A language-independent

approach. In TOOLS (47), pages 175–194.

Koegel, M., Hermannsdoerfer, M., von Wesendonk, O., and

Helming, J. (2010). Operation-based conﬂict detec-

tion. In Di Ruscio, D. and Kolovos, D. S., editors, Pro-

ceedings of the 1st International Workshop on Model

Comparison in Practice (IWMCP 2010), pages 21–30,

Malaga, Spain.

Koshima, A. and Englebert, V. (2014). Collaborative edit-

ing of EMF / Ecore meta-models and models: Conﬂict

detection, reconciliation, and merging in DiCoMEF.

In Pires, L. F., Hammoudi, S., Filipe, J., and das

Neves, R. C., editors, Proceedings of the 2nd Interna-

tional Conference on Model-Driven Engineering and

Software Development (MODELSWARD 2014), pages

55–66, Lisbon, Portugal. SCITEPRESS Science and

Technology Publications, Portugal.

Laguna, M. A. and Crespo, Y. (2013). A systematic map-

ping study on software product line evolution: From

legacy system reengineering to product line refactor-

ing. Sci. Comput. Program., 78(8):1010–1034.

Munch, B. P. (1993). Versioning in a Software Engineering

Database — The Change Oriented Way. PhD thesis,

Tekniske Høgskole Trondheim Norges.

Oliveira, H. L. R., Murta, L. G. P., and Werner, C. (2005).

Odyssey-VCS: a ﬂexible version control system for

UML model elements. In SCM, pages 1–16. ACM.

Pohl, K., B

ockle, G., and van der Linden, F. (2005). Soft-

ware Product Line Engineering: Foundations, Princi-

ples and Techniques. Berlin, Germany.

Reichenberger, C. (1995). VOODOO - a tool for orthogonal

version management. In Estublier, J., editor, SCM,

volume 1005 of Lecture Notes in Computer Science,

pages 61–79. Springer.

Rochkind, M. J. (1975). The source code control sys-

tem. IEEE Transactions on Software Engineering,

1(4):364–370.

Sarnak, N., Bernstein, R. L., and Kruskal, V. (1988). Cre-

ation and maintenance of multiple versions. In Win-

kler, J. F. H., editor, SCM, volume 30 of Berichte des

German Chapter of the ACM, pages 264–275. Teub-

ner.

Schneider, C., Z

undorf, A., and Niere, J. (2004). CoObRA

- a small step for development tools to collaborative

environments. In Workshop on Directions in Soft-

ware Engineering Environments in 26th international

conference on software engineering, Edinburgh, Scot-

land, UK.

Schw

agerl, F., Uhrig, S., and Westfechtel, B. (2013).

Model-based tool support for consistent three-way

merging of EMF models. In Proceedings of the work-

shop on ACadeMics Tooling with Eclipse, ACME ’13,

pages 2:1–2:10, New York, NY, USA. ACM.

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

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

Eclipse Series. Addison-Wesley, Upper Saddle River,

NJ, 2nd edition edition.

Taentzer, G., Ermel, C., Langer, P., and Wimmer, M.

(2014). A fundamental approach to model versioning

based on graph modiﬁcations: From theory to imple-

mentation. Software & Systems Modeling, 13(1):239–

272.

Vesperman, J. (2006). Essential CVS. O’Reilly, Sebastopol,

CA.

olter, M. and Groher, I. (2007). Product line implementa-

tion using aspect-oriented and model-driven software

development. In Proceedings of the 11th International

Software Product Line Conference, SPLC ’07, pages

233–242, Washington, DC, USA. IEEE Computer So-

ciety.

olter, M., Stahl, T., Bettin, J., Haase, A., and Helsen, S.

(2006). Model-Driven Software Development: Tech-

nology, Engineering, Management. John Wiley &

Sons.

Westfechtel, B. (2014). Merging of EMF models - for-

mal foundations. Software & Systems Modeling,

13(2):757–788.

Westfechtel, B. and Conradi, R. (2009). Multi-variant mod-

eling - concepts, issues and challenges. In Mezini,

M., Beuche, D., and Moreira, A., editors, Proceedings

1st International Workshop on Model-Driven Product

Line Engineering (MDPLE 2009), pages 57–67. CTIT

Proceedings.

Westfechtel, B., Munch, B. P., and Conradi, R. (2001).

A layered architecture for uniform version manage-

ment. IEEE Transactions on Software Engineering,

27(12):1111–1133.

Zeller, A. and Snelting, G. (1997). Uniﬁed version-

ing through feature logic. ACM Trans. Softw. Eng.

Methodol., 6(4):398–441.

Ziadi, T. and J

equel, J.-M. (2007). PLiBS: an Eclipse-

based tool for software product line behavior engi-

neering. In Proc. of 3rd Workshop on Managing Vari-

ability for Software Product Lines, SPLC 2007, Ky-

oto, Japan.

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