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
Model-driven Software Engineering, Software Product Line Engineering, Version Control, Filtered Editing.
Model-driven software product line engineering is complicated: In addition to defining a variability model,
developers must deal with a multi-variant domain model. To reduce complexity, filtered 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 configuration 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-
fine 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 filtered editing model raises consistency prob-
lems concerning the evolving relationships between the variability model, the specified configuration, 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.
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 defines
the abstract syntax of the used modeling language.
Software configuration 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 efficiently 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 field, 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 filtered
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 filtered edit-
ing, where the multi-variant domain model is entirely
transparent to the developer. Instead, he/she modifies
a single-variant model in several edit sessions; in each
session, the specific variant to be edited is described
using a choice, i.e., a read filter. The modifications
are transferred back to the platform using an ambi-
tion, a write filter that defines 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
2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
1. check-out
2. modify
3. commit
Domain Model
Feature Model
Domain Model
Feature Model
Figure 1: An architectural and functional sketch of the considered conceptual framework.
transfers the check-out/modify/commit workflow from
version control to filtered 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 definition of a feature configu-
ration, which serves as read filter. A corresponding
product version is transferred from the repository to
a workspace. The write filter 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 filtered editing was characterized ear-
lier (Schw
agerl et al., 2016b); however, formal defi-
nitions of the operations part of the editing model are
missing, and consistency has been neglected.
In this paper, we show that dynamic filtered edit-
ing requires well-defined workspace operations com-
plying to a set of consistency constraints. As main
contributions, we formally define 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 configuration, the feature ambition, and the
feature model, which is subject to evolution. Further-
more, an extra operation is provided to migrate the old
feature configuration such that it is consistent with a
new feature model and obviates repeated check-outs.
Section 2 gives a brief overview on (dynamic) fil-
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 reflects
our contribution. Section 9 presents related work.
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 reflected 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 specific variant
in the revision selected for the feature model.
On check-out, the workspace is populated through
a staged selection process. In the first 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)
mandatory feature
optional feature
unbound features
selected features
deselected feature
inserted elements
deleted elements
Figure 2: Example iteration of filtered editing: Attribute weight is introduced under ambition weighted.
In the second stage, a variant of the domain model is
determined by configuring the feature model. In the
resulting feature configuration, 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 confined 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 configuration 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 definition 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 defined.
Assuming that several iterations of the filtered
editing model have been performed, Figure 2 illus-
trates one iteration where the feature weighted is both
defined 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
configuration 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 defines 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.
As hinted in the preceding example, this paper as-
sumes a dynamic filtered 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 defined and realized at a time). Fur-
thermore, the feature ambition may be specified and
updated between check-out and commit.
When compared to static filtered editing (cf. re-
lated work), where the feature model may not evolve
and the scope of a change must be defined at check-
out (Westfechtel et al., 2001), the flexibility added
by dynamic filtered 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, redefine 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 figure 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
Version Space
complete (1)
& strongly
consistent (2)
Version Space
complete (6) & strongly
consistent (7) with
weakly consistent with (5)
with (4)
included in (8)
satisfiable (3)
Figure 3: Evolution scenario summarizing the problem statement and contributions of this paper.
revision graph, from which a specific revision is
selected. In the resulting revision of the feature
model, all features need to be either selected or
deselected. The unique version defined by the re-
vision and feature configuration 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 defined in the feature model must hold).
Modify. In the workspace, the feature model may be
edited as required, provided that it remains satis-
fiable, 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
define 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
satisfies 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 specific 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 specified then.
The figure 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 defined consistency constraints in
mind. At check-out, it is ensured that the configura-
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
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.
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 defined 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 configuration.
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 satisfied 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
, π
q, where π
is an initialization expres-
sion for option o
. Defaults d
, s
q define 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
, π
is an expression over O
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 filter 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 defined:
vpeq if e is unmodified.
a if e has been inserted.
vpeq ^ a if e has been deleted.
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
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,
= commit,
= migrate).
Maintaining Workspace Consistency in Filtered Editing of Dynamically Evolving Model-driven Software Product Lines
5.1 Check-out
In filtered 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
specified 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 modifies 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 modification to the version
space, the rule base
must be satisfiable:
Dc : pR
pcq trueq (12)
5.3 Commit
At commit time, the conjunction of the ambition and
the rule base must be satisfiable (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
specified 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 modifications of the rule base, the choice c
specified 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 modified in the subsequent iteration
must be uniquely and consistently identified 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
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
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 defined 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 configuration in the filtered 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 first 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 filtered by the revision
choice. In the filtered feature model, the user specifies
a configuration; 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 filtered ver-
sions of both the feature and the domain model.
Properties. If successful, Algorithm 1 transitions
the workspace into state Unmodified 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-
fies 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 filtering, 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 modification. For the feature model,
Constraint 3 is actively ensured after each modi-
fication. Furthermore, deletion of features in the
workspace version of the feature model is redefined:
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 Modified.
Complexity. The satisfiability 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
Ð new revision option with user-specified details (commit message, etc.)
Y o
Ź New revision option.
Y po
, o
q Ź Ensures that predecessor revisions are selected.
Y po
, f alseq Ź Non-predecessor revisions must be deselected.
Ð filter 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
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 find modified (inserted or deleted) elements
Update the visibilities of modified feature model elements using a
: o
Ź Equation 9.
Update the visibilities of modified domain model elements using a
Ź Equation 9.
a default po
, 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
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 specifies 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-
fined 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 specified ambition.
Otherwise, the workspace remains in state Modified;
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 satisfiability check in Constraint 4.
Example. The specified ambition (Figure 2e) is
weakly consistent with both the rule base a valid
representative would be c
, 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 workflow.
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
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 fulfilled
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 Unmodified. 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
Therefore, when neglecting user interaction, total
complexity is Op|O| ¨ |O
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.
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
filtered 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 files,
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-
cific dialogs (cf. cut-outs in Figure 2) for choice and
ambition selection as well as choice migration. For
modification of the feature model, the tool provides a
dedicated editor that enforces satisfiability each time
the modified 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
efficiently be passed to boolean expressions. For sat-
isfiability 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
User A
User Z
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).
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 first example is the
product line for graphs (cf. Sections 2 and 3); its
adaptation to filtered 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
define and realize new features.
Table 1 summarizes key figures of both case stud-
ies. The bottom half demands for further explanation:
1. Average ambition complexity: The complexity of
an ambition is defined 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 significantly 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 filtered editing
model is non-disruptive while workspace consistency
is maintained smoothly in the background.
Threats to Validity. The significance 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 filtered 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
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 filtered 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 fine-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
files (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 specific prod-
uct variant may be configured from a set of selected
features in two ways. Approaches based on positive
variability, e.g., (Zschaler et al., 2010), require spe-
cific 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 filtering 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) defines 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 workflow.
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 specified manually. To derive a
specific 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
specific 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 unfiltered 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 filtered 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 filtered editing.
Approaches to partially filtered 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 fil-
ter serving as choice and ambition simultaneously.
Specific tools or preprocessor languages are still re-
quired, and the filtered multi-variant product is still
constrained with single version rules.
A source-code centric approach to temporarily fil-
tered editing is described in (K
astner et al., 2008).
Here, a partial feature configuration is specified as
write filter. Code fragments immaterial for the change
are hidden. As approximation for a read filter, a
context is derived an extended view on the write fil-
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 filtered editing model,
the variability model may evolve during an iteration
embraced by update and commit. This is in con-
trast to representatives of static filtered editing, e.g.,
UVM (Westfechtel et al., 2001) and EPOS (Munch,
1993), where the ambition is specified 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 filter 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 flexibility implied
by the dynamic filtered editing model, introduced in
agerl et al., 2015a) and fully specified in this
paper, is unique in literature.
Product Line Development Processes. The de-
velopment process implied by the dynamic filtered
editing approach significantly 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 defining 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 define the scope
of a change in the filtered editing model, are related
staged feature configurations (Czarnecki et al., 2004),
which are used for stepwise refinement 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 files. Yet, it remains unclear how
product specific 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 specific 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 configuration 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 configurations, 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 configuration. 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
configurations. 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 conflicting re-
sults. For instance, a UML class may obtain two can-
didate names when two features that define 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.
We have presented an approach to maintaining
workspace consistency in dynamic filtered editing of
evolving model-driven software product lines. To this
end, we have defined a set of workspace consistency
constraints and have redefined 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, modifications to the feature model are per-
mitted only if they preserve its satisfiability. On com-
mit, the ambition delineating the scope of the change
is checked for weak consistency with both the choice
specified 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 confined to the logical dimension,
our constraints and algorithms may support two-layer
filtered 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 filtered 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-
flicts can arise due to concurrent modifications.
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
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 configuration management. ACM Computing
Surveys, 30(2):232–282.
Czarnecki, K., Helsen, S., and Eisenecker, U. (2004).
Staged configuration 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 Configura-
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 configuration management and re-
vision control platform. In Proceedings of the 38th
International Conference on Software Engineering
Companion, ICSE ’16, pages 803–806, New York,
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 Specification,
Version 2.4.1. Object Management Group.
OMG (2011b). OMG Unified 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.
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 configuration 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.
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 configuration 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.
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.
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.
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 classification 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 &
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–
Westfechtel, B., Munch, B. P., and Conradi, R. (2001).
A layered architecture for uniform version manage-
ment. IEEE Transactions on Software Engineering,
Zeller, A. and Snelting, G. (1997). Unified 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