Maintaining Workspace Consistency in Filtered Editing

of Dynamically Evolving Model-driven Software Product Lines

Felix Schw

agerl and Bernhard Westfechtel

Applied Computer Science I, University of Bayreuth, Universit

atsstr. 30, 95440 Bayreuth, Germany

Keywords:

Model-driven Software Engineering, Software Product Line Engineering, Version Control, Filtered Editing.

Abstract:

Model-driven software product line engineering is complicated: In addition to deﬁning a variability model,

developers must deal with a multi-variant domain model. To reduce complexity, ﬁltered editing, inspired by

version control, was recently transferred to software product line engineering. On check-out, a single-variant

model is derived based on a conﬁguration of its features. On commit, the representatively applied change is

scoped with the features to which it is relevant. The here considered dynamic editing model involves different

kinds of evolution: The variability model and the domain model are edited concurrently. Features, which de-

ﬁne the workspace contents or the scope of the change, may be introduced or deleted. Furthermore, the scope

of a change may be revised until commit. The dynamism of this ﬁltered editing model raises consistency prob-

lems concerning the evolving relationships between the variability model, the speciﬁed conﬁguration, and the

scope of the change. This paper formalizes these constraints and presents consistency-preserving algorithms

for the workspace operations check-out, commit, as well as a new operation, migrate. This way, the evolution

of model-driven software product lines is managed automatically, non-disruptively, and consistently.

1 INTRODUCTION

In model-driven software engineering (MDSE), soft-

ware systems are developed from high level mod-

els, which are eventually transformed into executable

code (V

olter et al., 2006). Models are abstractions of

systems; they may be located at different levels of de-

tail, e.g., requirements, architecture, and design. A

model is an instance of a metamodel, which deﬁnes

the abstract syntax of the used modeling language.

Software conﬁguration management is concerned

with the evolution of software systems; version con-

trol lies at its heart (Conradi and Westfechtel, 1998).

A version denotes a state of an evolving artifact. Evo-

lution may occur along several dimensions, giving

rise to historical, logical, and cooperative versioning

(Estublier and Casallas, 1995). Versions with respect

to the historical and the logical dimension are called

revisions and variants, respectively. Cooperative ver-

sioning orchestrates the work of different software

developers. Historical versioning is frequently sup-

ported by revision graphs, which allow for branches

that support logical versioning to a limited extent.

Finally, software product line engineering (SPLE)

is a paradigm to develop software applications based

on the principle of variability (Pohl et al., 2005). A

platform is a set of artifacts that form a common

structure from which a set of derivative products can

be efﬁciently developed and produced. A variabil-

ity model, e.g., a feature model (Kang et al., 1990),

describes common and discriminating features of the

variants of a product line. The combination of MD-

PLE and SPLE, model-driven product line engineer-

ing (MDPLE) is a promising research ﬁeld, since

it may increase productivity in two ways (Gomaa,

2004). Yet, it requires to edit multi-variant models,

which tends to be cognitively complex.

To this end, several approaches to partially ﬁltered

software product line engineering recently emerged

astner et al., 2008; Walkingshaw and Ostermann,

2014), where variants not important for a change are

hidden. In this paper, we assume fully ﬁltered edit-

ing, where the multi-variant domain model is entirely

transparent to the developer. Instead, he/she modiﬁes

a single-variant model in several edit sessions; in each

session, the speciﬁc variant to be edited is described

using a choice, i.e., a read ﬁlter. The modiﬁcations

are transferred back to the platform using an ambi-

tion, a write ﬁlter that deﬁnes the variants for which

the changes apply.

The contributions presented here are based on a

conceptual framework (Schw

agerl et al., 2015a) that

SchwÃd’gerl F. and Westfechtel B.

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines.

DOI: 10.5220/0006071800150028

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 15-28

ISBN: 978-989-758-210-3

1. check-out

2. modify

3. commit

Repository

Multi

-Version

Domain Model

Feature Model

Revision

Graph

Revision

Feature

Configuration

Feature

Ambition

Workspace

Domain Model

Feature Model

Figure 1: An architectural and functional sketch of the considered conceptual framework.

transfers the check-out/modify/commit workﬂow from

version control to ﬁltered MDPLE. As shown in Fig-

ure 1, in addition to a revision graph, which controls

the historical evolution of the product line, a feature

model is used for logical versioning. Selecting a ver-

sion during check-out involves the selection of a re-

vision as well as the deﬁnition of a feature conﬁgu-

ration, which serves as read ﬁlter. A corresponding

product version is transferred from the repository to

a workspace. The write ﬁlter is provided as a feature

ambition, a partial selection in the feature model.

Without loss of generality, the editing model is as-

sumed to be dynamic in the sense that it supports co-

evolution of feature and domain model and permits

updates to the scope of a change during the edit ses-

sion. Dynamic ﬁltered editing was characterized ear-

lier (Schw

agerl et al., 2016b); however, formal deﬁ-

nitions of the operations part of the editing model are

missing, and consistency has been neglected.

In this paper, we show that dynamic ﬁltered edit-

ing requires well-deﬁned workspace operations com-

plying to a set of consistency constraints. As main

contributions, we formally deﬁne these constraints

and present algorithms which preserve them. For ex-

ample, the consistency-preserving commit operation

ensures that there are no contradictions between the

feature conﬁguration, the feature ambition, and the

feature model, which is subject to evolution. Further-

more, an extra operation is provided to migrate the old

feature conﬁguration such that it is consistent with a

new feature model and obviates repeated check-outs.

Section 2 gives a brief overview on (dynamic) ﬁl-

tered MDPLE, introducing a running example. Sec-

tion 3 sketches the addressed evolution scenario.

Next, formal foundations are explained. Sections 5

and 6 present workspace consistency constraints and

algorithms for consistency-preserving workspace op-

erations, respectively. Section 7 describes the imple-

mentation. Section 8 evaluates and critically reﬂects

our contribution. Section 9 presents related work.

2 FILTERED MDPLE

In the considered conceptual framework, all kinds of

versioning, i.e., the revision graph as well as the fea-

ture model, are mapped internally to a common uni-

form version model (Westfechtel et al., 2001), which

is not exposed to the end user. Behind the curtains, the

framework relies on negative variability. The plat-

form, which corresponds to the repository in SCM

terms, contains a superimposition of all revisions and

variants; the connection to the version model(s) is re-

alized by visibilities (dashed boxes in Figure 1).

The repository relies on a three-layered architec-

ture: A revision graph controls the evolution of both

the feature model and the main artifact, the domain

model. The feature model, whose role is dual, serves

as an additional variability model. This way, the do-

main model is versioned by both the revision graph

and the feature model, which is also reﬂected in the

visibilities of the respective layers. All repository

contents are transparent to the end users.

The workspace, in which the product line engi-

neer evolves the product line, contains a selected revi-

sion of the feature model and a single-version domain

model; the term “version” denotes a speciﬁc variant

in the revision selected for the feature model.

On check-out, the workspace is populated through

a staged selection process. In the ﬁrst stage, a re-

vision of the product line is selected; this selection

uniquely determines a revision of the feature model.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

a) c)

Legend

mandatory feature

optional feature

unbound features

selected features

deselected feature

inserted elements

deleted elements

Figure 2: Example iteration of ﬁltered editing: Attribute weight is introduced under ambition weighted.

In the second stage, a variant of the domain model is

determined by conﬁguring the feature model. In the

resulting feature conﬁguration, each feature is bound

either to true (selected) or to false (deselected).

On commit, the repository contents are updated

such that the changes performed in the workspace be-

come persistent. However, the scope of the changes

is rarely conﬁned to the single variant in which they

are performed. Therefore, the product line engineer is

requested to specify a feature ambition when commit-

ting his or her changes. A feature ambition constitutes

a partial feature conﬁguration in the sense that some

features are bound to either true or false, while the

other features remain unbound. For the users, this is

decisive, since they must identify those features the

performed change is associated with. When taking

into consideration the deﬁnition of feature as “incre-

ment of program functionality” (Batory, 2005), the

number of features bound should be typically small.

We illustrate the conceptual framework using

the well-known graph product line example (Lopez-

Herrejon and Batory, 2001). The product line consists

of a structural model, represented as a UML class dia-

gram, where vertices and edges are realized. Further-

more, variable properties such as labels, weights, and

directed vs. undirected edges, are deﬁned.

Assuming that several iterations of the ﬁltered

editing model have been performed, Figure 2 illus-

trates one iteration where the feature weighted is both

deﬁned and realized, from the end user’s perspective:

First, the user selects a unique revision within the re-

vision graph (not shown). Next, in the chosen revi-

sion of the feature model (a), the user selects a feature

conﬁguration where all available features, including

the mandatory features Graph, Vertices, and Edges,

and the optional feature labeled are selected (b). This

results in a version of the domain model that is unique

with respect to both the revision graph and the feature

model; this version populates the workspace (c). Fur-

thermore, the selected revision of the feature model

is made available. In the edit session, the user intro-

duces an optional feature for weighted edges (d). The

feature is implemented in the same editing cycle by

attaching the attribute weight to class Edge (c). Upon

commit, the user deﬁnes the ambition of the change

by selecting exclusively the feature weighted from the

feature model (e). All other features remain unbound

as the performed change is immaterial to them. As

a consequence, weight becomes visible in future vari-

ants that include weighted.

3 EVOLUTION SCENARIO

As hinted in the preceding example, this paper as-

sumes a dynamic ﬁltered editing model where both the

feature model and the domain model are available in

the workspace for editing (e.g., the feature weighted

has been both deﬁned and realized at a time). Fur-

thermore, the feature ambition may be speciﬁed and

updated between check-out and commit.

When compared to static ﬁltered editing (cf. re-

lated work), where the feature model may not evolve

and the scope of a change must be deﬁned at check-

out (Westfechtel et al., 2001), the ﬂexibility added

by dynamic ﬁltered editing implies new consistency

problems. For example, for the sample iteration

sketched in Figure 2, the feature weighted against

which the change is committed was not present at

check-out time. To this end, we develop a variety of

constraints, redeﬁne check-out and commit, and in-

troduce an operation migrate, taking these constraints

into account by enforcing them.

The generalized evolution scenario, forming the

problem statement of this paper, is illustrated in Fig-

ure 3. The vertical dashed lines divide the ﬁgure into

four parts, dedicated to check-out, modify, commit,

and migrate, respectively. Blue arrows indicate evolu-

tion. Grey arrows represent consistency relationships

and are labeled with the numbers of constraints in-

troduced in Section 5. Unlike in Figure 1, the do-

main model is not shown, and versioning of the fea-

ture model is not illustrated explicitly.

Check-out. The editing cycle starts with an initial

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines

Choice

Version Space

complete (1)

& strongly

consistent (2)

with

evolves

Version Space

Choice

Ambition

complete (6) & strongly

consistent (7) with

co-evolves

weakly consistent with (5)

weakly

consistent

with (4)

CHECK-OUT

COMMIT MIGRATE

included in (8)

MODIFY

satisfiable (3)

Figure 3: Evolution scenario summarizing the problem statement and contributions of this paper.

revision graph, from which a speciﬁc revision is

selected. In the resulting revision of the feature

model, all features need to be either selected or

deselected. The unique version deﬁned by the re-

vision and feature conﬁguration is referred to as

the choice. The provided check-out operation has

to ensure that the choice is complete (in particu-

lar, no features from the feature model may re-

main unbound) and strongly consistent (all ver-

sion rules deﬁned in the feature model must hold).

Modify. In the workspace, the feature model may be

edited as required, provided that it remains satis-

ﬁable, i.e., non self-contradictory.

Commit. The commit operation will eventually re-

sult in a revised version space, where the revi-

sion graph is extended with a new revision for the

performed change; the feature model may have

evolved, as well. For commit, the user needs to

deﬁne a feature ambition; the combination of fea-

ture ambition and the new revision is called am-

bition. This ambition must be checked for weak

consistency with the new revision of the feature

model, which means that there must be no con-

tradiction to the version rules implied by the fea-

ture model (such that there exists at least one valid

version within the set of versions described by the

ambition). Furthermore, the ambition at commit

time must be weakly consistent with the choice at

check-out time, which means that there must be

no contradiction between the old choice and the

ambition (e.g., the ambition must not select a fea-

ture which was deselected in the old choice).

Migrate. Finally, the choice must co-evolve with the

change: A new choice has to be established which

satisﬁes the same constraints as the old choice,

since the end of the previous cycle coincides with

the start of the next cycle. To this end, we intro-

duce an operation choice migration, which is per-

formed immediately after commit. It essentially

extends the old choice with the ambition, ensures

completeness of the migrated choice and strong

consistency with respect to the new feature model,

as well as inclusion of the migrated choice in the

ambition. Consequently, executing a new check-

out under the migrated choice would result in a

copy of the workspace at commit time.

Figure 4 summarizes the editing cycle as state di-

agram. Initially, the workspace is Pending, i.e., not

populated yet. On check-out, a speciﬁc version is

selected from the repository. After modifying the

workspace and committing, the user may either con-

tinue with the subsequent iteration, requiring to mi-

grate the choice, or migration is canceled, triggering

a transition back into state Pending. To re-populate

the workspace, a new choice must be speciﬁed then.

The ﬁgure suggests two important properties of the

editing model: (1) Except for the initial version, and

as long as choice migration is never aborted, check-

out is an optional operation. (2) Choice migration is a

shortcut assuming that the user wants to perform the

subsequent iteration using the current workspace as

starting point, as usual in version control.

Let us resume the example from Figure 2 keep-

ing the informally deﬁned consistency constraints in

mind. At check-out, it is ensured that the conﬁgura-

tion of the selected feature model revision is complete

and strongly consistent. In the edit session, the fea-

ture model is extended with a feature weighted, which

Pending Unmodified

Modified

Committed

check‐out

modify

commit

migrate

cancel

modify

discon‐

nect

Figure 4: Workspace operations as state transitions.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

serves as ambition for the commit. The ambition con-

tradicts with neither the new feature model nor the old

choice. Migration extends the old choice with the new

feature. During choice migration, the choice is ex-

tended by a positive selection of weighted, such that it

becomes complete, strongly consistent, and included

in the ambition.

4 FORMAL FOUNDATIONS

Following (Westfechtel et al., 2001; Schw

agerl et al.,

2015a), we provide a formalization of the underly-

ing conceptual framework. Internally, versioning con-

cepts exposed at the user interface – revision graphs

and feature models – are mapped to a generic base

layer, the formal foundation of which is propositional

logic. Workspace consistency constraints (Section 5)

and consistency-preserving algorithms (Section 6) are

formalized upon the base layer.

An option represents a (logical or historical) prop-

erty of a software product that is either present or ab-

sent. The option set is deﬁned globally:

O “ to

, . . . , o

u (1)

Internally, the conceptual framework maps revisions

and features to options transparently.

A choice is a conjunction over all options, each of

which occurs in either positive or negated form:

c “ b

^ . . . ^ b

, b

P to

, o

u (2)

It can also be represented as a binding map, i.e., a

set of binding tuples po

, s

q, where s

P ttrue, f alseu

denotes the boolean selection state of an option o

Choices are derived from a user-based selection of

a revision and a feature conﬁguration.

An ambition is an option binding that allows for

unbound options:

a “ b

^ . . . ^ b

, b

P to

, o

, trueu (3)

When represented as a binding map, tuples for un-

bound options are omitted.

Ambitions are derived from a selection in the fea-

ture model, which may leave a number of features un-

bound in order to describe a set of variants to which a

change is applied. In the revision graph, the manage-

ment of ambitions is automated (see Section 6).

A version rule is a boolean expression over a sub-

set of options. The rule base R is a conjunction of

rules ρ

, . . . , ρ

all of which have to be satisﬁed by a

choice in order to be consistent:

R “ ρ

^ . . . ^ ρ

, ρ

is an expression over O (4)

Version rules are derived automatically from revision

graph and feature model (Schw

agerl et al., 2015a).

Preferences and defaults have been introduced to

ease version selection. A preference is a tuple of the

form p

“ po

, π

q, where π

is an initialization expres-

sion for option o

. Defaults d

“ po

, s

q deﬁne a fall-

back selection state s

P ttrue, f alseu. For each op-

tion, at most one preference and at most one default

is allowed; preferences have a higher priority.

P “ tpo

, π

q, . . . po

, π

qu,

is an expression over O

(5)

D “ tpo

, s

q, . . . po

, s

qu, s

P ttrue, f alseu (6)

The conceptual framework infers preferences and de-

faults transparently in order to assist the user in selec-

tions in the version space. In particular, they automate

the management of the revision graph.

Each element e of the product space (i.e., the

union of feature and domain model) carries a visibil-

ity v

, a boolean expression over the variables of O.

Visibilities in the feature model are composed only of

revision options; visibilities in the domain model are

composed of both revision and feature options. An el-

ement e is visible under a given choice c iff applying

c to its visibility v

evaluates to true:

pcq “ true (7)

The operation ﬁlter is applied during check-out.

From a base element set E, those elements e that do

not satisfy the choice are omitted.

f ilterpE, cq “ E z te P E |v

pcq “ f alseu (8)

On commit, visibilities must be updated such that

inserted (deleted) elements become (in)visible in all

choices included in the ambition a. Accordingly, the

updated visibility v

peq is deﬁned:

peq “

vpeq if e is unmodiﬁed.

a if e has been inserted.

vpeq ^ a if e has been deleted.

(9)

For updates to the domain model, the full ambition

a is used; for updates to the feature model, bind-

ings of feature options are omitted from the ambition,

since the feature model evolves merely in the revision

space.

5 WORKSPACE CONSISTENCY

CONSTRAINTS

In this section, the consistency constraints mentioned

in Section 3, Figure 3, are elaborated on the basis of

the formal foundations from Section 4. To cope with

evolution, we use superscripts (

= check-out,

modify,

= commit,

= migrate).

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines

5.1 Check-out

In ﬁltered editing, a choice designates a unique ver-

sion used for check-out. Therefore, unbound options

must not occur. Moreover, the choice must comply

with the rules derived by, e.g., feature dependencies.

Constraint 1. The binding map c

speciﬁed as

choice during check-out must be complete with re-

spect to the global option set O

at check-out time.

@o P O

: pDpo, sq P c

: s P ttrue, f alseuq (10)

Constraint 2. The choice c

at check-out time (sat-

isfying Constraint 1) must be strongly consistent with

the rule base R

at check-out time.

q “ true (11)

Here, R

q denotes the evaluation of the rules

contained in R

under the choice c

5.2 Modify

By editing the feature model, the user modiﬁes parts

of the option set and the rule base. It must be avoided

that the user introduces rules disallowing consistent

version selection in future check-outs.

Constraint 3. After each modiﬁcation to the version

space, the rule base

must be satisﬁable:

Dc : pR

pcq “ trueq (12)

5.3 Commit

At commit time, the conjunction of the ambition and

the rule base must be satisﬁable (weak consistency):

At least one choice c must exist which agrees with a

in all common option bindings (c ñ a

) such that all

rules hold under c.

Constraint 4. An ambition a

speciﬁed during com-

mit must be weakly consistent with the rule base R

at commit time.

Dc : pc ñ a

q ^ pR

pcq “ trueq (13)

In the version determined by the choice, a change

is applied representatively for the ambition. Thus,

there must not be any contradiction between option

bindings of the check-out time choice and the commit

time ambition inferred from feature selections:

Constraint 5. The ambition a

must be weakly con-

sistent with the check-out choice c

@po, sq P a

: po, sq R c

, s P ttrue, f alseu (14)

To support co-evolution (cf. Section 3), Con-

straint 5 allows to commit against a newly introduced

feature which was not bound in c

5.4 Migrate

Due to modiﬁcations of the rule base, the choice c

speciﬁed at check-out time may become incomplete

with respect to the option set O

, and/or inconsistent

with the rule base R

at commit time. These tem-

porary inconsistencies are explicitly allowed in order

to support feature model evolution. However, before

starting the subsequent iteration, it is required that

the version being modiﬁed in the subsequent iteration

must be uniquely and consistently identiﬁed by c

Constraint 6. The binding map c

describing the

choice after migration must be complete with respect

to the commit time option set O

@o P O

: pDpo, sq P c

: s P ttrue, f alseuq (15)

Constraint 7. The migrated choice c

(satisfying

Constraint 6) must remain strongly consistent with the

rule base R

at commit time.

q “ true (16)

Apart from this, it is required that the migrated

choice c

must still comply with ambition a

, which

represents changes applied to the current workspace.

Since all newly introduced options are mandatory to

be selected or deselected for the choice at migration

time, total inclusion (realized by propositional logical

implication in the opposite direction) is required.

Constraint 8. An ambition a

must include the mi-

grated choice c

describing the workspace contents

for the subsequent iteration.

ñ a

(17)

6 CONSISTENCY-PRESERVING

ALGORITHMS

In this section, we contribute detailed algorithms for

operations check-out, modify, commit, and migrate

mentioned in Figure 3. In addition, their properties

are discussed and runtime considerations are made.

For illustration, we refer back to the example from

Figure 2 where adequate. The algorithms contain in-

teractive steps, which have been underlined in the de-

scriptions below. Subscripts (

) refer to disjoint

subsets of revision graph or feature model.

6.1 Check-Out

According to Section 3, the purpose of check-out is to

populate an empty workspace with a consistent prod-

uct version uniquely deﬁned by the user.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

Algorithm 1: Check-Out.

Ð option in O

belonging to a selected revision

Apply revision preferences P

and revision defaults D

to c

:“ o

Filter the feature model by c

and export it into the workspace Ź Equation 8.

Ð select feature conﬁguration in the ﬁltered feature model

Ð c

^ c

Apply preferences P

and defaults D

to c

if not p@o P O

: pDpo, sq P c

: s P ttrue, f alseuqq then Ź Ensure Constraint 1.

return error “Choice is not complete.”

if not pR

q “ trueq then Ź Ensure Constraint 2.

return error “Choice is not strongly consistent.”

Filter the domain model by c

and export it into the workspace Ź Equation 8.

Memorize c

for the subsequent commit

Algorithm 1 ﬁrst asks the user for a revision selec-

tion. Using preferences and defaults introduced dur-

ing commit (cf. Section 6.3), it is ensured that options

of the selected revision as well as all predecessors are

bound to true, whereas remaining options are bound

to f alse, making the revision choice complete. Next,

the feature model, whose elements’ visibilities only

refer to revision options, is ﬁltered by the revision

choice. In the ﬁltered feature model, the user speciﬁes

a conﬁguration; invisible options for deleted features

(cf. Section 6.2) are bound to f alse by correspond-

ing defaults. The effective choice c

is calculated by

conjunction of revision and feature choice, before be-

ing checked for completeness and strong consistency.

Finally, the workspace is populated with ﬁltered ver-

sions of both the feature and the domain model.

Properties. If successful, Algorithm 1 transitions

the workspace into state Unmodiﬁed and produces a

choice both complete and strongly consistent with re-

spect to the check-out time rule base, such that Con-

straints 1 and 2 are ensured. In case the user speci-

ﬁes an incomplete or inconsistent choice, the action

is canceled and the workspace remains Pending.

Complexity. Applying preferences and defaults re-

quires to iterate over the preference set P and the de-

fault set D, the size of both is bounded by |O|. En-

suring Constraints 1 and 2 requires iterations over O

and R , respectively; the size of the latter is pro-

portional to |O|. While ﬁltering, each element of

E is considered. The total complexity is therefore

Op|O| ` |E|q.

Example. Figure 2b depicts a valid feature choice.

It would have been disallowed to leave any option un-

bound or to assign a negative selection state to one

of the mandatory features Graph, Vertices, or Edges.

Yet, the equivalent change could have been applied in

a version where labeled was deselected.

6.2 Modify

The consistency of the domain model is supposed to

be ensured by the respective single-version editing

tools used for modiﬁcation. For the feature model,

Constraint 3 is actively ensured after each modi-

ﬁcation. Furthermore, deletion of features in the

workspace version of the feature model is redeﬁned:

Rather than persistently deleting a feature, it is

merely hidden from the user interface and thus not

available in future revisions of the feature model.

Nevertheless, its feature option o

, which still may

occur in visibilities of domain model elements, re-

mains in O

. Deletion is only applicable to features

bound to f alse in the current choice c

. Otherwise,

choice migration (see Section 6.4) would transfer the

positive selection state to the choice for the next it-

eration, where o

and corresponding realization arti-

facts are hidden. To maintain completeness of future

choices, a default po

, f alseq is introduced to D

transparently. This default also affects version rules

referencing the feature; their evaluation is automated.

Properties. Constraint 3 is actively enforced. The

workspace enters (or remains in) state Modiﬁed.

Complexity. The satisﬁability check described by

Constraint 3 performed after each save is NP-comp-

lete. The runtime of feature deletion can be neglected.

Example. Since all features are bound positively,

feature deletion cannot be applied here. If labeled

had been bound to f alse in c

and then been deleted,

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines

Algorithm 2: Commit.

Ð choice memorized during preceding check-out or migration

Ð option of most recently committed revision

r`1

Ð new revision option with user-speciﬁed details (commit message, etc.)

Ð O

Y o

r`1

Ź New revision option.

Ð P

Y po

, o

r`1

q Ź Ensures that predecessor revisions are selected.

Ð D

Y po

r`1

, f alseq Ź Non-predecessor revisions must be deselected.

Ð ﬁlter feature/domain model by c

Ź Reproduce checked-out workspace.

Ð current workspace version of feature and domain model

Ð select feature ambition in the current workspace version of the feature model

Ð a

^ o

r`1

if not pDc : pc ñ a

q ^ pR

pcq “ trueq then

return error “Ambition is not weakly consistent.” Ź Ensure Constraint 4.

if not p@po, sq P a

: po, sq R c

q then

return error “Ambition is inconsistent with choice.” Ź Ensure Constraint 5.

Differentiate ws

with ws

to ﬁnd modiﬁed (inserted or deleted) elements

Update the visibilities of modiﬁed feature model elements using a

:“ o

r`1

Ź Equation 9.

Update the visibilities of modiﬁed domain model elements using a

Ź Equation 9.

a default po

labeled

, f alseq would have been transpar-

ently introduced, which automatically deselects the

invisible feature in future check-outs.

6.3 Commit

A consistency-preserving commit operation is formal-

ized in Algorithm 2. The revision graph is handled au-

tomatically, introducing a new revision option along

with a preference and default ensuring that selecting

a single revision will lead to complete and consistent

revision choices in future. Through repeated applica-

tion of preferences of the form po

, o

r`1

q, the selec-

tion is propagated back until the initial revision. De-

faults, having a lower priority, are applied to unbound

revision options thereafter. Next, the check-out ver-

sion of the workspace is reconstructed and differenti-

ated with its commit time version.

Besides, the user speciﬁes a feature ambition. It

is ensured by corresponding checks that feature am-

bitions must be weakly consistent with the rule base

(Constraint 4) and the previous choice (Constraint 5).

Visibilities of affected elements are updated as de-

ﬁned by Equation 9. For updates applied to the feature

model, the new revision option serves as ambition.

For the domain model, a conjunction of the new re-

vision option and the chosen feature ambition is used.

Properties. If successful, Algorithm 2 transitions

the workspace into the state Committed, while ensur-

ing Constraints 4 and 5 for the speciﬁed ambition.

Otherwise, the workspace remains in state Modiﬁed;

in this case, the user may retry the commit.

Complexity. Reproducing the checked-out work-

space and updating the visibilities both imply a run-

time proportional to |E|. Constraint 5 checks a max-

imum of |O| options. Runtime is dominated by the

NP-complete satisﬁability check in Constraint 4.

Example. The speciﬁed ambition (Figure 2e) is

weakly consistent with both the rule base – a valid

representative would be c

Ytpo

weighted

, truequ – and

the check-out time choice (which did not include a

binding for the newly introduced feature). In the am-

bition, it would be disallowed to assign selection state

f alse to feature labeled being positively bound in c

6.4 Migrate

Migration prepares the workspace choice for the sub-

sequent iteration. In contrast to check-out and com-

mit, this operation is not triggered explicitly by the

user, but invoked transparently after commit. Con-

versely, it makes the subsequent check-out optional,

enabling a non-disruptive revision control workﬂow.

Algorithm 3 iterates over options unbound in the

choice, assuming that the user stays in the current

view. If a corresponding option has been bound in

the ambition, the binding is transferred to the choice.

Otherwise, preferences and defaults are triggered as

far as applicable, with the aim to complete c

trans-

parently. As a “last resort”, a binding state is obtained

non-deterministically. Since the new option has been

ignored in the ambition, there cannot exist any refer-

ence to it in updated visibilities; therefore, it is im-

material for the subsequent choice whether the op-

tion is selected. At this point, it is not known how

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

Algorithm 3: Migrate.

Ð c

for o P O

if ppo, trueq R c

q ^ ppo, f alseq R c

q then Ź Never override existing bindings.

Ð unde f ined

if Dpo, sq P a

: s P ttrue, f alseu then s

Ð s

else if a preference p P P

is applicable to o then

Ð apply p to o

else if a default d P D

is applicable to o then

Ð apply d to o

else s

Ð user selection for o

Ð c

Y po, s

if not R

q “ true then Ź Ensure Constraint 7.

return error “Cannot migrate to a consistent choice.”

else Memorize c

for the subsequent commit Ź Obviate check-out.

new (and therefore unbound) features will be incor-

porated in the next iteration. Therefore, the user may

choose among the set of choices describing the cur-

rent workspace equivalently.

Properties. Completeness (Constraint 6) is fulﬁlled

by iterating over all options in O

and assigning true

or f alse to missing bindings. A strongly consistent

choice (Constraint 7) is enforced.

Being its descendant, c

includes c

. Moreover,

is weakly consistent with c

(cf. Constraint 5).

Thus, no contradictions exist between c

and a

Bindings for missing options are transferred from the

ambition, inferred from preferences or defaults, or if

not applicable, requested from the user. Altogether,

the migrated choice c

is included in the ambition

(as required by Constraint 8).

If migration succeeds, the workspace directly en-

ters state Unmodiﬁed. Otherwise or if the user can-

cels the operation, entering state Pending immediately

triggers an exceptional check-out, forcing the user

into specifying a new choice.

Complexity. Assuming that the binding maps un-

derlying choices and ambitions have been imple-

mented as an associative data structure, iterating over

all options requires a maximum runtime proportional

to |O|. Preferences and defaults, whose number

is bounded to |O|, are taken into account at most

two times per newly introduced option o

new

P O

new

Therefore, when neglecting user interaction, total

complexity is Op|O| ¨ |O

new

|q.

Example. Bindings for the new revision as well as

for the new feature weighted are inferred automati-

cally from the ambition. If an additional feature had

been introduced but neither been bound in the ambi-

tion nor considered by a feature model rule, a selec-

tion would have been requested interactively.

7 IMPLEMENTATION

The consistency-preserving algorithms shown in Sec-

tion 6 have been implemented as an extension to Su-

perMod (Schw

agerl et al., 2015b), a prototype for

ﬁltered MDPLE. The tool has been handcrafted in a

model-driven way using the Eclipse Modeling Frame-

work (EMF) (Steinberg et al., 2009). The artifacts to

be versioned, representing the “domain model”, are

EMF models, which may be instances of arbitrary

metamodels, e.g., of the EMF-based metamodel for

UML2 (OMG, 2011b). Being suitable for heteroge-

neous projects, the system may also manage text ﬁles,

which are interpreted internally in the repository as

EMF model instances.

Constraint validation has been implemented in a

user-friendly and non-disruptive way providing spe-

ciﬁc dialogs (cf. cut-outs in Figure 2) for choice and

ambition selection as well as choice migration. For

modiﬁcation of the feature model, the tool provides a

dedicated editor that enforces satisﬁability each time

the modiﬁed feature model is saved. Constraint vio-

lations are reported using the EMF Validation Frame-

work (Steinberg et al., 2009).

Internally, choices and ambitions are represented

as binding maps (cf. Section 4), such that they can

efﬁciently be passed to boolean expressions. For sat-

isﬁability checks, e.g., Constraints 3 and 4, the solver

Sat4j (Berre and Parrain, 2010) is utilized. Moreover,

optimized data structures ensure scalability; for in-

stance, equivalent visibilities are re-used rather than

being cloned (Schw

agerl et al., 2016a).

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines

Local

Repository

Workspace

check-out

commit

User A

Local

Repository

Workspace

check-out

commit

User Z

Remote

Repository

pull

push

Figure 5: SuperMod’s distributed architecture.

Cooperative versioning is supported through the

distributed architecture displayed in Figure 5. Each

user owns a local repository; check-out and com-

mit operations are used to populate the workspace

and to persist changes locally. Local repositories are

synchronized through a remote repository by oper-

ations pull and push (Chacon, 2009). Technically,

the synchronizing operations have been realized as

REST-based (Fielding, 2000) web services. Symmet-

ric deltas are transferred in XMI (OMG, 2011a) for-

mat; see (Schw

agerl and Westfechtel, 2016).

8 EVALUATION

In order to evaluate the editing model in connec-

tion with the presented constraints and consistency-

preserving algorithms, we report on two data sets ex-

tracted from case studies that refer to standard exam-

ples from SPL literature. The ﬁrst example is the

product line for graphs (cf. Sections 2 and 3); its

adaptation to ﬁltered product line editing has been

shown in (Schw

agerl et al., 2015b). The second case

study refers to a product line for Home Automation

Systems (HAS) originally introduced in (Pohl et al.,

2005) and adapted in (Schw

agerl et al., 2016b).

All results were obtained by analyzing recorded

version histories. While the Graph product line was

realized by the authors themselves, the HAS study was

conducted by a master student with MDPLE back-

ground. In order to foster an incremental style of de-

velopment, requirements were communicated to the

modeler(s) in multiple interview sessions. Particu-

larly in the HAS case study, hypothetical customer

feedback was given, such that it became necessary to

both revise the realization of existing features and to

deﬁne and realize new features.

Table 1 summarizes key ﬁgures of both case stud-

ies. The bottom half demands for further explanation:

1. Average ambition complexity: The complexity of

an ambition is deﬁned as the number of features

it binds. Negatively bound features are treated as

two bindings (as feature expressions derived from

them contain an additional syntax tree element for

the negation). Note that an ambition can also have

complexity 0 in case no feature is bound for a uni-

versal change (true).

2. Migration interactions: The ratio of editing model

iterations in which at least one user interaction is

required during migration.

3. Explicit check-outs: The ratio of iterations where

the optional check-out operation is necessary

since the previously applied migration does not

produce the desired choice for the next iteration.

4. Commits canceled: The ratio of commit opera-

tions canceled due to violations of a consistency

constraint, such that further domain or feature

model editing was required.

In sum, the results show that (1) the complex-

ity of ambitions is in average close to 1, support-

ing the proposition that ambitions frequently consist

of only a single feature binding; (2) migration hap-

pens transparently for the larger part of iterations

and signiﬁcantly accelerates the development; (3) the

check-out operation, which has been made optional

by the dynamic editing model, is necessary only in

a small number of iterations; (4) only in one of al-

together 47 iterations was it necessary to cancel the

commit (in this case, the feature the user intended

to realize was accidentally missing in the feature

model). In contrast, the larger part of iterations did

neither require a check-out nor user interaction during

migrate, underlining that the dynamic ﬁltered editing

model is non-disruptive while workspace consistency

is maintained smoothly in the background.

Threats to Validity. The signiﬁcance of the results

derived from Table 1 is potentially limited by two

factors. First, it was clearly communicated to the

evaluators that the scope of the changes applied in

one iteration should be equal, leading to compara-

bly short-running iterations. However, in real-world

scenarios, inexperienced users may accidentally re-

alize several different features in one iteration, mak-

ing it impossible to specify a valid global ambition.

Second, cooperative versioning was faded out in both

case studies as multi-user operation had not been im-

plemented yet. We expect the number canceled com-

mits to slightly increase with multi-user support due

to problems such as doubly introduced features.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

Table 1: Aggregate results quantifying the user complexity of the dynamic ﬁltered editing model.

Graph HAS

number of iterations 9 38

feature model size 8 17

domain model size 26 106

average ambition complexity 8{9 “ 0.89 41{38 “ 1.08

% migration interactions 1{9 “ 0.11 5{38 “ 0.13

% explicit check-outs 3{9 “ 0.33 6{38 “ 0.16

% commits cancelled 0{9 “ 0 1{38 “ 0.026

9 RELATED WORK

This paper continues a series of previous work on Su-

perMod and its theoretical foundations published by

the authors; see references section. Here, we refer to

approaches that explicitly deal with workspace con-

sistency problems appearing with ﬁltered editing or

related forms thereof. Furthermore, we supply refer-

ences to related papers published in the meantime.

Version Control Systems. With branches, almost

all contemporary revision control systems, including

Subversion (Collins-Sussman et al., 2004) and Git

(Chacon, 2009), offer co-existing product variants.

Yet, existing approaches only allow to restore variants

committed earlier (extensional), but not to re-combine

new variants in a way as ﬁne-grained as provided by

feature models (intensional versioning). In addition,

the state of the art lacks a version control system that

(1) operates at a level of abstraction higher than text

ﬁles (e.g., EMF models), and (2) supports intensional

versioning. It is for these reasons why SuperMod has

been handcrafted rather than relying on existing sys-

tems as low-level layer.

Model-Driven Product Line Engineering. As

mentioned in the introduction, MDPLE (Gomaa,

2004) is motivated by a common goal of its sub-

disciplines, increased productivity. A speciﬁc prod-

uct variant may be conﬁgured from a set of selected

features in two ways. Approaches based on positive

variability, e.g., (Zschaler et al., 2010), require spe-

ciﬁc tools, e.g., model transformations, to compose

variable realization fragments. Negative variability,

e.g., (Heidenreich et al., 2008) means that the prod-

uct variant is constructed by ﬁltering all elements not

required for this variant from a superimposition. The

approach at hand internally uses negative variability.

Integrated Historical and Logical Versioning.

The integration of revision and variant control was

targeted earlier. Approaches to orthogonal version

management (Reichenberger, 1995) did not consider

the variability model to be subject to historical evo-

lution. In (Zeller and Snelting, 1997), an approach

based on feature logic was presented; externally, vari-

ant annotations are mapped to low-level C preproces-

sor directives.

The Uniform Version Model (UVM) (Westfech-

tel et al., 2001) deﬁnes version control foundations

parts of which had been introduced in the context of

change-oriented versioning (Munch, 1993). Albeit,

the low-level variability model is not provided as an

explicit artifact in the workspace. The here consid-

ered framework represents both the product and the

version space as high-level models. In (Westfech-

tel et al., 2001) an explicit check-out is necessary in

advance to each iteration, since an operation corre-

sponding to choice migration is missing. This results

in a more disruptive and less automated workﬂow.

In (Seidl et al., 2014), a solution to integrated his-

torical and logical versioning based on positive vari-

ability is presented. The approach relies on explicit

historical versioning of the variability model. Hy-

per feature models record different versions of fea-

tures and allow for version-aware constraints such

as version range restrictions. Versioning is based

upon a delta language for EMF models, such that

for each increment added to the product line, a for-

ward delta must be speciﬁed manually. To derive a

speciﬁc version of the product, a revision must be

selected for each active feature consistently. In con-

trast, the here considered conceptual framework man-

ages deltas transparently, removing the necessity of

speciﬁc editing tools; in SuperMod, familiar single-

version EMF model editing tools may be used.

Filtered Editing. Negative variability assumes a

multi-variant domain model realizing all features of

the product domain. Approaches can be further dis-

tinguished by the degree of multi-version complexity

passed on to the user.

In unﬁltered approaches, mapping information,

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines

regardless of whether stored within the domain

model (Gomaa, 2004) or in a distinct mapping

model (Heidenreich et al., 2008), must be maintained.

In fully ﬁltered multi-variant editing tools (Sar-

nak et al., 1988; Westfechtel et al., 2001), a choice

uniquely denotes a representative of the ambition. By

presenting only a single-version view, cognitive com-

plexity is reduced while familiar editing tools may

be reused for multi-version editing. The approach at

hand represents fully ﬁltered editing.

Approaches to partially ﬁltered editing (Walk-

ingshaw and Ostermann, 2014; Zeller and Snelting,

1997) aim at hiding variants to which the current

change is immaterial, without requiring the choice

to be complete. However, there is only a single ﬁl-

ter serving as choice and ambition simultaneously.

Speciﬁc tools or preprocessor languages are still re-

quired, and the ﬁltered multi-variant product is still

constrained with single version rules.

A source-code centric approach to temporarily ﬁl-

tered editing is described in (K

astner et al., 2008).

Here, a partial feature conﬁguration is speciﬁed as

write ﬁlter. Code fragments immaterial for the change

are hidden. As approximation for a read ﬁlter, a

context is derived an extended view on the write ﬁl-

ter. The change recording mechanism provided in the

MDPLE approach contributed by (Heidenreich et al.,

2008) works in a similar way.

In the presented dynamic ﬁltered editing model,

the variability model may evolve during an iteration

embraced by update and commit. This is in con-

trast to representatives of static ﬁltered editing, e.g.,

UVM (Westfechtel et al., 2001) and EPOS (Munch,

1993), where the ambition is speciﬁed at check-out

time; since the rule base does not evolve, constraints

dealing with its evolution are unnecessary. Similarly,

in (Walkingshaw and Ostermann, 2014), having a sin-

gle ﬁlter requires that the scope of a change must

be known beforehand, inhibiting the concurrent intro-

duction of a feature and its realization (cf. example in

Figure 2). To our knowledge, the ﬂexibility implied

by the dynamic ﬁltered editing model, introduced in

(Schw

agerl et al., 2015a) and fully speciﬁed in this

paper, is unique in literature.

Product Line Development Processes. The de-

velopment process implied by the dynamic ﬁltered

editing approach signiﬁcantly differs from phase-

structured SPL processes such as (Pohl et al., 2005).

First, it intentionally blurs domain engineering, i.e.,

the creation of the platform, and application engi-

neering, i.e., the adaptation of derived products. Sec-

ond, complex design decisions, such as deﬁning vari-

ation points and variants in the product, are auto-

mated. Feature ambitions, where an arbitrary subset

of features can be selected in order to deﬁne the scope

of a change in the ﬁltered editing model, are related

staged feature conﬁgurations (Czarnecki et al., 2004),

which are used for stepwise reﬁnement during appli-

cation engineering and require additional consistency

properties such as parent-child co-selection.

Variation Control Systems. As variation control

systems, we refer to tools that generalize the concept

of version control systems by adding support for in-

tensional variant management. SuperMod also falls

into this category.

In (Mitschke and Eichberg, 2008), a logical ver-

sioning layer transparently mapping feature models,

domain models, and traceability links to Subversion,

is described. New variants are created locally by

merging branches containing variability at the gran-

ularity of source ﬁles. Yet, it remains unclear how

product speciﬁc changes may be written back to mul-

tiple variants; the concept ambition is missing.

In (Montalvillo and D

ıaz, 2015), an extension en-

abling SPLE management is presented. It allows to

propagate product speciﬁc changes, performed in a

merged branch, back to the trunk, such that domain

and application engineering are blurred in a similar

way as in the here considered framework. Rather than

being integrated into the underlying version control

system Git, the extension is built upon the hosting

platform GitHub, resulting in a comparably loosely-

coupled SPLE tool integration.

The conﬁguration management platform pre-

sented in (Linsbauer et al., 2016) supports both vari-

ability and revision management. To this end, vari-

ability information is automatically extracted from

different variants created by copying and adapting

(clone-and-own approach). Once migrated to the

platform, generalized check-out and commit opera-

tions, which are scoped by conﬁgurations, can be

used. Rather than actually applying intensional ver-

sioning, the approach relies on reference variants,

which constitutes the variant that “best matches” the

selected conﬁguration. This drastically reduces preci-

sion when compared to truly intensional approaches.

In (St

anciulescu et al., 2016), a prototypical varia-

tion control system relying on the editing model of

(Walkingshaw and Ostermann, 2014) is presented.

Like in our framework, the concept of ambition is

used to scope changes during commit (here: put). In

contrast, check-out (here: get) also allows for partial

conﬁgurations. Unresolved variability remains visi-

ble to the user in the workspace, e.g., in the form of

preprocessor directives.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

Related Consistency Questions. While this paper

is focused on workspace consistency, the orthogo-

nal problem of product consistency must be distin-

guished. Since the multi-variant model managed in

the repository is unconstrained with respect to its vari-

ability, product derivation may deliver conﬂicting re-

sults. For instance, a UML class may obtain two can-

didate names when two features that deﬁne candidates

for the name are selected. Such problems occur much

more often in multi-user development. Depending

on the concrete representation used for the product

space, specialized solutions exist; see (Th

um et al.,

2014) for a survey.

10 CONCLUSION

We have presented an approach to maintaining

workspace consistency in dynamic ﬁltered editing of

evolving model-driven software product lines. To this

end, we have deﬁned a set of workspace consistency

constraints and have redeﬁned workspace operations

such that these constraints are preserved. On check-

out, the choice describing the version populating the

workspace is checked for completeness and strong

consistency with the feature model. Within an edit

session, modiﬁcations to the feature model are per-

mitted only if they preserve its satisﬁability. On com-

mit, the ambition delineating the scope of the change

is checked for weak consistency with both the choice

speciﬁed at check-out time and the evolved feature

model. Finally, the choice used for the subsequent it-

eration is migrated such that it is complete, strongly

consistent with the commit-time feature model, and

included in the ambition.

The approach at hand uses a conceptual frame-

work whose application is in no way restricted

to model-driven software product line engineering.

While the majority of constraints and algorithms pre-

sented here are obsolete when following a static,

waterfall-like development process, they become rel-

evant whenever dynamic, i.e., iterative and incremen-

tal editing of (potentially) variational software arti-

facts is required, e.g., in agile software development.

Furthermore, when conﬁned to the logical dimension,

our constraints and algorithms may support two-layer

ﬁltered SPLE architectures, which do not include a re-

vision graph. Only slight adaptations are necessary in

case a different variability model (as opposed to fea-

ture models) or product space representation (as op-

posed to EMF models) is to be supported.

The material presented in this paper has been im-

plemented completely as extension to the Eclipse-

based tool SuperMod. The user interacts with a lo-

cal repository; multiple copies of local repositories

are synchronized with a master repository by pull and

push. The tool has been applied successfully to two

standard case studies: the well-known graph example

and a Home Automation product line. In this paper,

we have deduced from the aggregated data sets that

the dynamic ﬁltered editing model keeps user com-

plexity small and exposes a high degree of automa-

tion; user interaction is only necessary in a small num-

ber of development iterations, where ambiguities oc-

cur or when migration produces a non-intuitive result.

Future work will address the consistency of de-

rived product variants in the workspace, where con-

ﬂicts can arise due to concurrent modiﬁcations.

REFERENCES

Batory, D. (2005). Feature models, grammars, and propo-

sitional formulas. In Proceedings of the 9th In-

ternational Conference on Software Product Lines,

SPLC’05, pages 7–20, Berlin, Heidelberg. Springer.

Berre, D. L. and Parrain, A. (2010). The Sat4j library, re-

lease 2.2. JSAT, 7(2-3):59–6.

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., Helsen, S., and Eisenecker, U. (2004).

Staged conﬁguration using feature models. In Nord,

R., editor, Software Product Lines, volume 3154 of

Lecture Notes in Computer Science, pages 266–283.

Springer Berlin Heidelberg.

Estublier, J. and Casallas, R. (1995). Three dimensional ver-

sioning. In Estublier, J., editor, Software Conﬁgura-

tion Management: Selected Papers SCM-4 and SCM-

5, volume 1005 of Lecture Notes in Computer Science,

pages 118–135, Seattle, WA. Springer-Verlag.

Fielding, R. T. (2000). REST: Architectural Styles and

the Design of Network-based Software Architectures.

Doctoral dissertation, University of California, Irvine.

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 Com-

panion Proceedings of the 30th International Confer-

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

944, New York, NY, USA. ACM.

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.

Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines

astner, C., Trujillo, S., and Apel, S. (2008). Visualizing

software product line variabilities in source code. In

Proceedings of the 2

International SPLC Workshop

on Visualisation in Software Product Line Engineer-

ing (ViSPLE), pages 303–313.

Linsbauer, L., Egyed, A., and Lopez-Herrejon, R. E. (2016).

A variability aware conﬁguration management and re-

vision control platform. In Proceedings of the 38th

International Conference on Software Engineering

Companion, ICSE ’16, pages 803–806, New York,

NY, USA. ACM.

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

dard problem for evaluating product-line methodolo-

gies. In Proceedings of the Third International Con-

ference on Generative and Component-Based Soft-

ware Engineering, GCSE ’01, pages 10–24, London,

UK. Springer.

Mitschke, R. and Eichberg, M. (2008). Supporting the evo-

lution of software product lines. In Oldevik, J., Olsen,

G. K., Neple, T., and Paige, R., editors, ECMDA

Traceability Workshop Proceedings 2008, pages 87–

96, Berlin, Germany.

Montalvillo, L. and D

ıaz, O. (2015). Tuning GitHub for

SPL development: branching models & repository op-

erations for product engineers. In Proceedings of the

19th International Conference on Software Product

Line, SPLC 2015, Nashville, TN, USA, July 20-24,

2015, pages 111–120.

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

Database — The Change Oriented Way. PhD thesis,

Tekniske Høgskole Trondheim Norges.

OMG (2011a). OMG MOF 2 XMI Mapping Speciﬁcation,

Version 2.4.1. Object Management Group.

OMG (2011b). OMG Uniﬁed Modeling Language (OMG

UML), Superstructure, Version 2.4.1.

Pohl, K., B

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

ware Product Line Engineering: Foundations, Princi-

ples and Techniques. Springer, 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.

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.

Schw

agerl, F., Buchmann, T., Uhrig, S., and Westfech-

tel, B. (2015a). Towards the integration of model-

driven engineering, software product line engineer-

ing, and software conﬁguration management. In Ham-

moudi, S., Pires, L. F., Desfray, P., and Filipe, J., edi-

tors, Proceedings of the 3rd International Conference

on Model-Driven Engineering and Software Develop-

ment, pages 5–18, Angers, France. SCITEPRESS.

Schw

agerl, F., Buchmann, T., Uhrig, S., and Westfech-

tel, B. (2016a). Realizing a conceptual framework to

integrate model-driven engineering, software product

line engineering, and software conﬁguration manage-

ment. In Desfray, P., Filipe, J., Hammoudi, S., and

Ferreira Pires, L., editors, Model-Driven Engineering

and Software Development, volume 580 of Communi-

cations in Computer and Information Science (CCIS),

chapter 2, pages 21–44. Springer.

Schw

agerl, F., Buchmann, T., and Westfechtel, B. (2015b).

SuperMod - A model-driven tool that combines ver-

sion control and software product line engineering. In

Proceedings of the 10th International Conference on

Software Paradigm Trends, pages 5–18, Colmar, Al-

sace, France. SCITEPRESS.

Schw

agerl, F., Buchmann, T., and Westfechtel, B. (2016b).

Filtered model-driven product line engineering with

SuperMod: The home automation case. In Lorenz,

P., Cardoso, J., Maciaszek, L. A., and van Sinderen,

M., editors, Software Technologies, volume 586 of

Communications in Computer and Information Sci-

ence (CCIS), chapter 2, pages 19 – 41. Springer.

Schw

agerl, F. and Westfechtel, B. (2016). Collaborative and

distributed management of versioned software prod-

uct lines. In Proceedings of the 11th International

Conference on Software Paradigm Trends, pages 83–

94, Lisbon, Portugal. SCITEPRESS.

Seidl, C., Schaefer, I., and Aßmann, U. (2014). Integrated

management of variability in space and time in soft-

ware families. In Proceedings of the 18th Interna-

tional Software Product Line Conference - Volume 1,

SPLC ’14, pages 22–31, 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.

anciulescu, S¸., Berger, T., Walkingshaw, E., and

Wa¸sowski, A. (2016). Concepts, operations and feasi-

bility of a projection-based variation control systems.

In Proceedings of the 32nd International Conference

on Software Maintenance and Evolution, ICSME’16.

um, T., Apel, S., K

astner, C., Schaefer, I., and Saake, G.

(2014). A classiﬁcation and survey of analysis strate-

gies for software product lines. ACM Computing Sur-

veys, 47(1):6:1–6:45.

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

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

nology, Engineering, Management. John Wiley &

Sons.

Walkingshaw, E. and Ostermann, K. (2014). Projectional

editing of variational software. In Generative Pro-

gramming: Concepts and Experiences, GPCE’14,

Vasteras, Sweden, September 15-16, 2014, pages 29–

38.

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 versioning

through feature logic. ACM Transactions on Software

Engineering and Methodology, 6(4):398–441.

Zschaler, S., S

anchez, P., Santos, J., Alf

erez, M., Rashid,

A., Fuentes, L., Moreira, A., Ara

ujo, J., and Kulesza,

U. (2010). VML* — a family of languages for vari-

ability management in software product lines. In

van den Brand, M., Ga

sevic, D., and Gray, J., edi-

tors, Software Language Engineering, volume 5969

of Lecture Notes in Computer Science, pages 82–102.

Springer Berlin / Heidelberg, Denver, CO, USA.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development