Collaborative and Distributed Management of Versioned 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, Configuration Management.
Abstract:
Software Product Line Engineering promises a significant gain in productivity, yet with the addition of new
challenges one of which is the increased complexity of collaborative development. This paper presents an ap-
proach to distributed and collaborative product line engineering based on a filtered editing framework that has
been extended by multi-user support. Using filtered editing, the product line is developed in a single-version
view in a local workspace and transparently organized in a local repository. The contributed conceptual ex-
tension orchestrates the evolution and synchronization of different copies of the repository. This way, local
transactions realized by check-out and commit are complemented by remote transactions using the operations
pull and push. The proposed approach has been implemented as an extension to the model-driven tool Super-
Mod backed by a REST-based web service, evolving the toolset to a distributed product line version control
system. We discuss relevant design decisions and illustrate our contributions by several examples.
1 INTRODUCTION
Software Product Line Engineering (SPLE) empha-
sizes the methodical development of families of sim-
ilar software products based on organized reuse and
mass customization (Pohl et al., 2005). To man-
age variability, commonalities and differences among
products are captured in feature models (Kang et al.,
1990). Specific products are then derived in a prefer-
ably automated way based on feature configurations
that resolve variability. This requires to connect im-
plementation artifacts to specific features or com-
binations thereof, as realized by presence condi-
tions (Czarnecki and Kim, 2005). Literature distin-
guishes positive variability, where a minimal core is
defined to which specific features are added (Apel
and K
¨
astner, 2009), from negative variability, where
product variants are derived by removing unnecessary
artifacts from a superimposition, as realized, e.g., by
preprocessor languages (K
¨
astner et al., 2008).
Over the last decade, the importance of Model-
Driven Software Engineering (MDSE) (V
¨
olter et al.,
2006) has grown. Models are considered as first-class
artifacts from which application code is generated.
MDSE involves well-defined languages such as the
Unified Modeling Language (UML) (OMG, 2011b).
The combination of SPLE and MDSE yields the in-
tegrating discipline Model-Driven Product Line En-
gineering (MDPLE) (Gomaa, 2004), which promises
increased productivity by offering high-level abstrac-
tions to describe both variability and products.
Revision control deals with the problems of evo-
lution and collaboration in software development.
Distributed version control systems as Git (Chacon,
2009) remove the bottleneck of a centralized server
having to orchestrate changes immediately, and add
off-line support. In Git, the commands check-out and
commit are used to synchronize the workspace with
a locally persisted repository; the operations pull and
push synchronize different copies of a repository.
In (Schw
¨
agerl et al., 2015a), a conceptual frame-
work for the integration of revision control, SPLE,
and MDSE has been developed. Its model-driven
implementation has been presented in (Schw
¨
agerl
et al., 2016; Schw
¨
agerl et al., 2015b). The tool
SuperMod supports the incremental development of
a model-driven software product line in a single-
version workspace using a filtered editing model that
fully automates variability management using the re-
vision control metaphors check-out and commit. In
order to select a specific version and to delineate the
scope of a change to be committed, the user makes
selections in a feature model in addition to the revi-
sion graph. To date, both the conceptual framework
and SuperMod suffered from being applicable only in
a single-user environment.
Schwägerl, F. and Westfechtel, B.
Collaborative and Distributed Management of Versioned Model-driven Software Product Lines.
DOI: 10.5220/0005971300830094
In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 2: ICSOFT-PT, pages 83-94
ISBN: 978-989-758-194-6
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
83
check-out
modify
commit
Local Repository
Revision
Feature
Configuration
Choice
Feature
Ambition
Ambition
Workspace
Chosen Product
Version
Chosen Feature
Model Revision
Revision
Graph
Multi
-Revision
Feature Model
Multi
-Version
Product
Figure 1: Filtered single-user MDPLE as originally defined by the conceptual framework and supported by SuperMod.
The contributions presented in the paper at hand
remove this single-user restriction. Multiple copies
of the product line are orchestrated by a server-side
repository. Differences between multiple repositories
are transferred using the operations pull and push.
The theoretical contribution of this paper is an ex-
tension of the conceptual framework by transaction
support, a distinction between remote (pull/push) and
local transactions (check-out/commit), as well as a
formal definition of the operations pull and push in
the context of filtered MDPLE. The contributions
have been implemented as a REST-based web service
(Fielding, 2000), which reads and produces symmet-
ric deltas (Rochkind, 1975). Being based on a model
representation, the structure and calculation of deltas
is considerably more complicated when compared to
text-oriented version control systems like Git.
Section 2 revisits relevant parts of the conceptual
framework. In Section 3, theoretical extensions based
on collaborative revision graphs are presented, before
client-server synchronization comes into focus (Sec-
tion 4). Client-side implementation is discussed sub-
sequently. Section 6 outlines related approaches fo-
cusing on filtered editing and collaborative SPLE.
2 FOUNDATIONS
The theoretical contributions of this paper are built
upon a conceptual framework for the integration of
historical and logical versioning, i.e., version con-
trol and SPLE. The original framework (Schw
¨
agerl
et al., 2015a) supports single-user filtered product
line engineering, combining version control concepts
workspace, repository, revision graph with the SPLE
concepts feature model and (partial) feature config-
uration. Moreover, the version control operations
check-out and commit are extended by the specifica-
tion of choices and ambitions (see Figure 1). More
than ordinary version control systems, the underlying
editing model encourages iterative software develop-
ment. Each iteration consists of three steps:
Check-out. The user performs a version selection (a
choice) in the local repository. In the revision
graph, the choice comprises a single revision. In
the feature model, a feature configuration has to
be specified. The selected revision of the feature
model and the selected version (revision and fea-
ture configuration) of the product are filtered and
loaded into the workspace.
Modify. The user applies changes to the single-
version product and/or to the feature model.
Commit. The changes are written back to the local
repository. The user is prompted for a feature am-
bition, a partial selection in the feature model de-
scribing the set of variants to which the change
applies. Visibilities of versioned elements are
updated automatically, such that changes to the
product become visible only for the current revi-
sion, and only for variants included in the partial
feature configuration specified as ambition.
The contents of the local repository have been for-
mally defined based on notions introduced by the Uni-
form Version Model (UVM) (Westfechtel et al., 2001).
Moreover, the internal data structure has been de-
fined by a set of metamodels (Schw
¨
agerl et al., 2016)
serving for the model-driven realization of SuperMod
(Schw
¨
agerl et al., 2015b). Following remarks recapit-
ulate the theoretical foundations of the framework.
A repository R is a triple consisting of a product
space P, a version space V , and a mapping map defin-
ing which elements of the version space are included
ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends
84
in which version.
R = (P,V, map) (1)
Elements of V are externally shown as higher-level
abstractions such as revisions or features and inter-
nally mapped to low-level elements (options and ver-
sion rules, see below). P contains elements of both
the feature model and the domain model (which theo-
retically may be anything representable by set theory,
e.g., text files or EMF models).
An option represents a (logical or temporal) prop-
erty of a software product that can be either present or
absent. The global option set is used to define the set
of versions V intensionally.
O = {o
1
,... ,o
n
} (2)
Each revision and each feature is mapped to one op-
tion transparently.
A choice is a conjunction over all options, each of
which occurs in either positive or negated form:
c = b
1
... b
n
, b
i
{o
i
,¬o
i
} (i {1,. .. ,n}) (3)
Choices uniquely identify elements of the version
space V . In SuperMod, they are inferred automati-
cally from a user-based selection of a revision and a
completely bound feature configuration.
An ambition is an option binding that allows for
unbound options and thus denotes a subset of the ver-
sion space V .
a = b
1
... b
n
, b
i
{o
i
,¬o
i
,true} (4)
Ambitions are inferred from a partial user-based se-
lection in the feature model. Thus, an ambition may
leave options unbound in order to describe a set of
versions to which a change is applied.
Version rules are boolean expressions over a sub-
set of options. The rule base R is a conjunction of
version rules ρ
i
all of which have to be satisfied by an
option binding in order to be consistent:
R = ρ
1
... ρ
m
(5)
In SuperMod, version rules are managed transpar-
ently and kept invisible to the user. E.g., for a se-
quence of revisions, a rule of the form r
i
r
i1
is in-
troduced; the mapping between the revision graph and
rule base constraints is redefined in Section 3. The se-
mantics of feature models is mapped to propositional
logical constraints (Schw
¨
agerl et al., 2015a).
A choice c is strongly consistent if it implies the
rule base R :
c R (6)
In the case of ambitions, only the existence of a
consistent version is required. An ambition is weakly
consistent if it overlaps with the rule base:
R a 6= f alse (7)
Each element e of the product space carries a vis-
ibility v(e), a boolean expression over the variables
defined in the option set. This way, visibilities imple-
ment the function map declared in (1). An element e
is visible under a choice c V if its visibility is im-
plied by the choice, i.e., it evaluates to true given the
option bindings of the choice:
c v(e) (8)
The filter operation is applied during check-out.
Filtering a product space P by a choice c can be real-
ized as a conditional copy, where elements e that do
not satisfy the choice are omitted.
f ilter(P,c) = P \ {e P| c 6⇒ v(e)} (9)
During commit, the visibility of product space ele-
ments is updated such that inserted elements become
visible in all choices implied by the specified ambi-
tion a, and deleted elements remain invisible there.
Accordingly, the updated visibility v
0
(e) is defined:
v
0
(e) =
v(e) if e remains unmodified.
a if e was newly inserted.
v(e) a if e was re-inserted.
v(e) ¬a if e was deleted.
(10)
For changes to the actual product, the ambition a re-
ferred to above binds both revision and feature op-
tions. However, for changes to the feature model, all
feature options are stripped from a, since the feature
model is merely versioned by the revision graph.
3 COLLABORATIVE SPLE
In this section, we explain extensions to the con-
ceptual framework providing the basis for the defini-
tion of the synchronization mechanisms in Section 4,
which enable collaborative MDPLE in the end.
3.1 Design Decisions
The metamodel and mapping explained subsequently
are justified by the following design decisions.
Optimistic Synchronization. The conceptual
framework does not require locks to coordinate
collaborative versioning. Rather, developers
may concurrently modify their copies of the
repository.
Enforcement of a Linear Version History. Each
revision committed to the repository is a suc-
cessor of the latest revision available, the head.
By intention, the conceptual framework does not
support branches; as a replacement, variable parts
of the product should be modeled using features.
Collaborative and Distributed Management of Versioned Model-driven Software Product Lines
85
Remote and Local Transactions. Different copies
of the repository are synchronized not after each
commit, but only at user-defined synchronization
points. For this purpose, the extended frame-
work distinguishes between remote transactions,
which are started with a pull and finished with a
push operation, from local transactions, which re-
alize an update-modify-commit iteration. This re-
duces synchronization overhead and enables off-
line product line development. Moreover, it is
not necessary to start a remote transaction explic-
itly; rather, all necessary bookkeeping steps are
enforced after each pull transparently.
3.2 Metamodel and Rule Base Mapping
Figure 2 and Table 1 illustrate an Ecore meta-
model for revision graphs as well as a mapping to
low-level rule base elements for instances thereof.
Both the figure and the table redefine the mapping
from (Schw
¨
agerl et al., 2016, Table 2 and Figure 7).
A revision graph is a container for public revi-
sions, which represent remote transactions and in turn
contain private revisions, which express local transac-
tions. Both inherit from an abstract base class Revi-
sion that defines an attribute for the revision number
private revisions are externally displayed using the
nesting public revision as qualifier and additional
commit details (date, message, user). Secondly, a
generic predecessors/successors relationship is de-
fined. Last, references {private|public}{Init|Head}
memorize corresponding revisions.
In addition to the structure of the revision graph,
the metamodel shown in Figure 2 also defines refer-
ences to low-level rule base elements (see Section 2),
which are transparently derived using the transforma-
tion patterns defined in Table 1. Private revisions are
mapped to a revision option in a straightforward way
(pattern 2), whereas public revisions are mapped to
two options, starting (1) and finishing (3) the trans-
action. Pattern (4) ensures that the initial revision is
selected. In general, predecessor/successor relation-
ships between two revisions r
i1
and r
i
are mapped
to version rules of the form r
i
r
i1
, i.e., when a
revision is selected, all predecessors are enforced to
be selected, too. There are five cases in which such
relationships are created: (5) After finishing a remote
transaction, a succeeding remote transaction is started
immediately. (6) All private revisions follow the start
option of the parent public revision. Pattern (7) en-
sures successorship of private revisions, and (8) is in-
stantiated before finishing a remote transaction. Pat-
tern (9) enforces a linear version history by automati-
cally merging with remotely finished transactions.
3.3 Example
To illustrate the dynamic behavior of a collabora-
tive revision graph, Figure 2 shows a sample version
history involving two fictional developers, Alice and
Bob. Alice creates the repository, which transparently
introduces a revision option r
0
and a corresponding
initial public revision rule (patterns 1 and 4 in Ta-
ble 1). Next, she performs an initial commit, which
introduces a nested private revision r
0.0
as successor
of r
0
(6). By finishing the transaction through the
push operation, r
0.
(3) and rule r
0.
r
0.0
(8) are in-
troduced transparently. The next transaction is started
automatically, introducing r
1
(1) and r
1
r
0.
(5).
Concurrently, Bob clones the repository, which also
starts a write transaction (option r
2
, rule r
2
r
0.
).
Both developers commit private revisions to their lo-
cal repositories and then finish their current remote
transaction. Bob is the first to push, r
2
is closed,
and r
3
is started immediately. Thereafter, Alice tries
to push and receives an out of date error, enforcing
a pull until the current head, such that the incoming
r
2.
is merged with r
1.
. When pushing again, pat-
tern (9) is instantiated, adding r
1.
r
2.
to the rule
base transparently. Moreover, a new remote transac-
tion is begun by introducing r
4
and r
4
r
1.
. Al-
ice finishes the transaction in a straightforward way.
After that, Bob starts his work forgetting to pull r
4
.
Thus, he receives an out of date error when trying to
push r
3.
. The incoming r
4.
is automatically merged
before finishing r
3
. Please note: Despite the underly-
ing mechanisms defined in Section 3.2 and illustrated
in this example being intrinsically complex, the fic-
tional users are only exposed to familiar revision con-
trol metaphors (commit, push, pull, out of date).
4 DISTRIBUTED SPLE
So far, we have completely ignored the feature model
and the product, both being versioned by the collab-
orative revision graph. Likewise, the evolution of the
version graph itself must be orchestrated. Figure 4
complements Figure 1 by the architecture of the syn-
chronization component, which is detailed below.
4.1 Design Decisions
The list of design decisions is extended by items re-
ferring to the synchronizing operations pull and push:
Symmetric deltas (Rochkind, 1975) correspond to a
superimposition of all existing revisions, assign-
ing version identifiers to each element. Using di-
rected deltas (Tichy, 1985), change sequences re-
ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends
86
Table 1: Detailed mapping between collaborative revision graphs and low-level version rules.
Nr. Pattern Transformation Metamodel Ref.
1 public revision r
i
option r
i
revisionOption
2 private revision r
i. j
nested in public revision r
i
option r
i. j
revisionOption
3 finished public revision r
i
option r
i.
finishedOption
4 initial public revision r
0
rule r
0
initPublicRule
5 public revision r
i
as successor of finished public revision r
i1
rule r
i
r
i1.
predecessorRules
6 initial private revision r
i.0
nested in public revision r
i
rule r
i.0
r
i
initPrivateRule
7 private revision r
i. j
as successor of private revision r
i. j1
rule r
i. j
r
i. j1
predecessorRules
8 finished public revision r
i
with private head r
i.h
rule r
i.
r
i.h
predecessorRules
9 public revision r
i
with incoming r
c
causing out of date rule r
i.
r
c.
predecessorRules
finished : Boolean
PublicRevision
RevisionGraph
public
Revisions
*
predecessors
successors
*
*
(from core)
Option
(from core)
Rule
revisionOption
predecessor
Rules
1
*
0..1initPublicRule
revisionNumber : int
date : Date
message : String
user : String
Revision
publicInit
publicHead
0..1
0..1
/ displayName : String
PrivateRevision
0..1initPrivateRule
privateRevisions
*
0..1
privateInit
privateHead 0..1
0..1
finishedOption
Figure 2: Metamodel for collaborative revision graphs. Classes core::Option and core::Rule refer to options and version rules,
respectively, as introduced in Section 2.
r3.0
r3.8
Alice
Bob
Create
Commit
r0
r0.0
r0.∞
Push
r1
r2
r1.0 r1.7...
Commit
Commit
r2.0
r2.4...
Commit
Commit
Push
Outofdate
Pullr2
Pushagain
r3
Push
r4
r4.0 r4.5...
Commit
Commit
Clone
Push
...
Commit
Commit
Push
Outofdate
Pullr4
Pushagain
r5
r3.∞
r6
r4.∞
r1.∞r2.∞
Figure 3: Example revision graph illustrating the interplay between public and private revisions. Boxes denote revisions with
corresponding options. Black arrows starting at r
x
and ending at r
y
denote an instantiation of a predecessor rule r
y
r
x
.
Collaborative and Distributed Management of Versioned Model-driven Software Product Lines
87
check-out
modify
commit
Local Repository
Remote Repository
Multi
-Version
Product
Multi
-Revision
Feature Model
Revision
Graph
pull
push
Symmetric
Deltas
Local
Repository
...
Transaction Layer
Figure 4: Synchronization of multiple local copies of the repository using a server-side repository and symmetric deltas.
construct product revisions on demand, ensuing
from a fully persisted baseline revision. Although
directed deltas consume less space, we decided
for symmetric deltas, since they harmonize better
with filtered editing and negative variability.
Cross-references. The conceptual framework ab-
stracts from specific product space types; how-
ever, it is assumed that cross-references be-
tween elements of the product space need to be
managed. Besides, references between higher-
level version models and low-level rule base el-
ements exist (e.g., references to core::Option and
core::Rule in Figure 2). Last, through visibilities,
product space elements refer to options defined in
the version space. It is therefore important to cor-
rectly handle references from elements which are
part of the delta to elements not included there.
Three-way Merging. According to our chosen opti-
mistic versioning strategy, concurrent modifica-
tions may occur. Our solution relies on an auto-
mated three-way merging procedure that involves
the user as late as possible, i.e., when trying to
check-out a product that contains conflicts. Due
to space restrictions, this paper does not deal with
product conflict resolution in the workspace.
4.2 Low-Level Transaction Layer
In order to keep track of the elements modified by the
current write transaction, a simple transaction layer
has been added to the conceptual framework. It is
realized by the following extensions:
Each local repository carries a read transaction
number, which indicates the revision number of
the most recently pulled public revision, and a
write transaction number, which equals the revi-
sion number of the public revision organizing the
current remote transaction.
Each element (i.e., product space element or ver-
sion space element such as revision) carries a
transaction number that indicates its most recent
modification (i.e., insertion, deletion, or modifi-
cation of a child element). The visibility update
function (cf. Equation 10 in Section 2) is mod-
ified such that it assigns the current write trans-
action number to (re-)inserted and deleted ele-
ments. Furthermore, transaction numbers are up-
dated during the creation of public and private re-
visions accordingly.
The server-side repository manages a global
transaction log to which transaction starting and
finishing events are appended. Also from this log,
new public revision numbers are generated. The
transaction log for the example from Figure 3 is
o0 c0 o1 o2 c2 o3 c1 o4 c4 o5 c3 o6,
where o denote opened, c closed transactions.
Transactions are opened, but not necessarily
closed, in numerical order.
4.3 Symmetric Delta Calculation
The increments transferred along with push and pull
operations are symmetric deltas; they are here con-
sidered as subsets of the product space, consisting
of the feature model and the primary product. As
pointed out in Section 4.1, special emphasis is put on
the consistency of cross-references between different
types of elements. Algorithm 1 describes a generic
procedure for calculating symmetric deltas as a pro-
jection of the product space based on a given trans-
action number. The delta is returned as the sub-set
of the product space that contains elements carrying
ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends
88
the specified transaction number (
0
), elements refer-
enced by elements in
0
or by their visibilities (
1
),
and the transitive closure (
+
) over the containers (
2
)
of elements in
0
or
1
.
Algorithm 1: Symmetric Delta Projection.
procedure PROJECTDELTA(P, tNr)
0
elements of P carrying tNr
1
=
/
0
for e
0
0
do
for e
1
elements cross-referenced by e
0
do
if e
1
/
0
then
1
1
{e
i
}
for o
1
options referred to in v(e
0
) do
ve
1
high-level concept of o
1
if ve
1
/ (
0
1
) then
1
1
{ve
1
}
2
=
/
0
for e
01
(
0
1
) do
for e
2
container
+
(e
01
) do
if e
2
/ (
0
1
2
) then
2
2
{e
2
}
return
0
1
2
4.4 Raw vs. Three-Way Merging
The counterpart to delta calculation is merging. This
operation appends an incoming delta to a product
space P, which is an “add-only” structure; no element
is ever permanently removed.
Element Merging. When assuming a purely set-
theoretic definition of the product space P, a merged
product space P
0
including an incoming delta can
be easily calculated as
P
0
= P (11)
However, element merging imposes several new chal-
lenges such as the identification of “equal” elements,
which are rather specific to the implementation and
therefore discussed in Section 5.3.
Moreover, conflicts arise when two “equal” ele-
ments e carry different visibilities in P and . Spe-
cial attention is paid here, since visibilities encode in-
sertions and deletions of elements. We have to dis-
tinguish between raw merging (an incoming delta is
to be integrated into the local repository) and three-
way merging (the local repository contains outgoing
changes which conflict with an incoming delta, i.e.,
the local repository is out of date).
Raw Visibility Merging. In case no outgoing
changes exist to redefine the visibility of an element
e P, it is assumed that the “more recent” visibility
is transferred from the delta to the local version.
v
0
(e) =
v
(e) if e and v
(e) is defined.
v
P
(e) otherwise.
(12)
Three-Way Visibility Merging. If the local reposi-
tory is out of date, the visibilities of its elements in P
may conflict with the visibilities defined in . In this
case, the common base version b must be considered:
v
0
(e) =
v
P
(e) if e / or v
(e) is undefined.
v
(e) if e / P or v
P
(e) is undefined.
µ(v
b
(e),v
P
(e),v
(e)) otherwise.
(13)
Here, v
b
(e) is the visibility of e in the common base
version of the considered revisions in the revision
graph. Along with this, µ(v
b
,v
1
,v
2
) is the three-way
visibility merge function (Westfechtel, 2014):
µ(v
b
,v
1
,v
2
) = (v
1
v
2
) (v
1
¬v
b
) (v
2
¬v
b
)
(14)
In case there is no difference between v
b
and v
1
, this
function evaluates to v
2
(conversely for swapping v
1
and v
2
). Otherwise, insertions and deletions made ef-
fective by the visibility update function (Equation 10)
are combined.
4.5 Definition of Pull and Push
Based upon the definitions from the preceding sub-
sections, we now formally define the operations pull
and push referred to in Figure 4.
Pull. This operation fetches incoming changes from
the remote and appends them to the local repository.
1. The current read transaction number is sent to the
server as part of a pull request.
2. The server analyzes the transaction log to find
all write transactions closed since the transmitted
read transaction number.
3. If there are no newly closed transactions, cancel.
4. For each of the new transactions, a symmetric
delta is calculated using Algorithm 1.
5. The deltas are combined and sent to the client.
6. The client merges the incoming delta with the lo-
cal repository as shown in Section 4.4.
(a) In case there are no outgoing changes, raw
merging is applied. Then, a check-out is en-
forced in order to transfer incoming changes to
the workspace.
Collaborative and Distributed Management of Versioned Model-driven Software Product Lines
89
v w
x
y
z
p
q
u
s
t
0
4
1
4
3
4
3
3
3
2
0.0
r
)(
)(
0.2
0.10.0
B
A
fr
frr
)(
0.30.0 B
frr
)(
))(
)((
0.4
0.2
0.10.0
A
B
A
fr
fr
frr
B
fr
0.2
)(
0.3
0.2
B
B
fr
fr
A
fr
0.4
)(
)(
0.3
0.4
B
A
fr
fr
)(
)(
0.3
0.4
B
A
fr
fr
Figure 5: Product space of the running example, including visibilities (grey boxes), and transaction numbers (black boxes).
(b) In case there are outgoing changes (i.e., pend-
ing commits in an unfinished public revision),
three-way merging is applied, and the local
workspace is checked-out anew.
7. The client’s read transaction number is updated
to the server’s latest read transaction number.
Push. This operation finishes a remote transaction
and transfers all committed changes to the server.
1. A pull is enforced. For incoming changes, corre-
sponding public revisions are memorized.
2. The current remote transaction is finished, instan-
tiating patterns 3 and 8 from Table 1. Revision
details (user, date, commit message) are applied.
3. A symmetric delta is calculated using Algorithm 1
and the current write transaction number.
4. The delta is sent to the server as part of a push
request.
5. The server raw-merges the incoming delta with
the remote repository as shown in Section 4.4.
6. The transaction log is updated by closing the
client’s write transaction and opening a new write
transaction immediately.
7. The new write transaction number is transferred
to the client.
8. In the client revision graph, a new public revision
is introduced, instantiating patterns 1 and 5 from
Table 1. In addition, for each incoming revision
memorized in step 1, pattern 9 is enforced.
4.6 Example
We refer back to the example introduced in Sec-
tion 3.3 with a focus on delta calculation and three-
way merging. To facilitate understanding the exam-
ple, we make some simplifications: (1) One change is
performed per commit. (2) For each remote transac-
tion, only the first commit is shown. (3) The feature
model consists of two optional features f
A
and f
B
,
not imposing any further constraints. (4) The prod-
uct space is represented as a simple bubbles and arcs
model. Both bubbles and arcs carry a label, which
also serves as equality criterion.
The final state of the remote repository’s product
space, including visibilities, is depicted in Figure 5.
Below, the performed changes (each followed by push
and commit) are ordered by push date.
Revision 0. Alice initializes the repository, creating
the entire feature model and an initial product
consisting of bubbles v, w, x and arc q. She does
not associate her change with a specific feature,
resulting in ambition true. The transferred delta
contains { f
A
, f
B
,v,w,x,q}.
Revision 2. Ensuing from revision 0, Bob removes q
and x, and inserts arc s and bubble z, all under
ambition f
B
. The delta is { f
B
,q, x,s, z}.
Revision 1. Alice concurrently removes arc q and
bubble x, and adds arc p, under ambition f
A
. The
delta is { f
A
,q, x, p,w}. w is included as an ele-
ment cross-referenced by the inserted arc p.
Merging Revisions 3 and 4. Bob was the first to fin-
ish, so Alice receives an out of date error when
trying to push. When pulling to r
2
, the incoming
delta is merged. The visibility of arc q and bubble
x has been concurrently modified, such that v
R
=
r
0.0
¬(r
1.0
f
A
) and v
= r
0.0
¬(r
2.0
f
B
). Us-
ing the base visibility v
b
= r
0.0
, the three-way vis-
ibility merge function (Equation 14) evaluates to
v
0
(q) = v
0
(x) = r
0.0
¬(r
1.0
f
A
) ¬(r
2.0
f
B
).
Revision 4. Alice re-inserts bubble x and adds bubble
y, arcs t and u under ambition f
A
. The delta is
{ f
A
,y,t, u,w,x}
Revision 3. Ensuing from revision 1, Bob concur-
rently deletes bubble w and arc s, and inserts u
and y, under ambition f
B
. The transferred delta is
calculated as { f
B
,w,s, u,y, z}.
ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends
90
Merging Revisions 1 and 2. Bob receives an out of
date error when trying to push. As a consequence,
the incoming delta of r
4
is merged. This time,
the visibilities of arc u and bubble y are merged:
µ(true,r
4.0
f
A
,r
3.0
f
B
) = (r
4.0
f
A
) (r
3.0
f
B
). Moreover, the visibility of q is raw-merged.
In this example, we have focused on the internals
of low-level transaction management, delta calcula-
tion, visibility update, and visibility merging. It is
important to notice that the end users Alice and Bob
never get bothered with these details, since they oper-
ate in their local workspaces using the VCS abstrac-
tions commit, push, and pull, which hide complexity
from them. The example also shows that visibility
merging produces the intuitive result; the concurrent
deletions of q and t as well as the concurrent inser-
tions of u and y have been combined, while the log-
ical scopes the ambitions specified by the users
have been maintained. During delta calculation, the
smallest subset necessary to describe the changes in a
self-contained way is yielded, reducing synchroniza-
tion traffic to a minimum.
5 IMPLEMENTATION
The extensions to the conceptual framework pre-
sented in Sections 3 and 4 have been implemented
as plug-ins for the research prototype SuperMod
(Schw
¨
agerl et al., 2015b), removing its single-user re-
striction. SuperMod has been developed in a model-
driven way using the Eclipse Modeling Framework
(EMF) (Steinberg et al., 2009). The tool is publicly
available for evaluation purposes; installation instruc-
tions and an accompanying screencast video are ref-
erenced at the end of this paper. Figure 6 shows
that SuperMod’s client has been realized as a team
provider plug-in for the Eclipse IDE. This section out-
lines the most important implementation details that
enable collaborative MDPLE.
5.1 Server Architecture
The server component of SuperMod has been realized
as a REST-based (Representational State Transfer)
(Fielding, 2000) web-service hosted on an Apache
Tomcat 7 servlet container. The remote repository is
an instance of the SuperMod metamodel (Schw
¨
agerl
et al., 2016) and persisted in the XMI (XML Metadata
Interchange) (OMG, 2011a) format in the server’s file
system. Additionally, the transaction log (see Sec-
tion 4.2) is stored within a simple text file.
Read and write transactions are protected by a
server-side lock file, ensuring that push and pull op-
Tomcat7
SuperModServer
WebApplication
EclipseIDE
SuperMod
Client
Repo
EclipseTeam
Provider
Create
Pull
Push
HTTP/REST
Create
Pull
Push
Repo
<xmi>
<xmi>
<xmi>
Figure 6: Coarse architecture of communication between
client (left) and server (right).
erations never coincide. Atomicity of push and pull is
ensured using EMF’s resource framework. Only after
finishing a write transaction successfully, all modified
EMF resources are saved at a time; otherwise, in case
the transaction has been canceled, all modifications
are rolled back.
5.2 Mapping VCS to REST Operations
The architectural style REST is based on the Hyper
Text Transfer Protocol (HTTP). Modifiable and non-
modifiable data is qualified by means of resources en-
coded in hierarchical URLs. The content transferred
with and obtained by a HTTP request (i.e., the entity)
may have binary or text format. Moreover, different
methods are distinguished: GET serves for reading,
POST for creation, and PUT for modification.
Below, the mapping of the distributed VCS op-
erations create
1
, pull, and push, to HTTP methods
is explained, assuming that the servlet is running at
http://root.url/supermod/. These methods are
invoked by the SuperMod client transparently when
the user demands the corresponding operation.
Create. The initialization of a new remote repository
is available as a POST method on
.../supermod/repo/path/create?user=X,
where the entity contains the XMI serialization
of the entire initial repository. Variable repo/path
distinguishes several independent repositories.
The initial write transaction number 1 is returned.
Pull. Server-side changes are requested using GET
...supermod/repo/path/pull?user=X&read
TransactionNr=Y, where the query entity is kept
empty. An XMI-serialized delta is returned that
includes changes referring to transactions closed
after Y .
2
Push. Transferring client-side changes to the remote
repository is realized as a PUT method on
1
Conceptually trivial, therefore omitted in Section 4.
2
Y = 1 requests the entire repository (clone).
Collaborative and Distributed Management of Versioned Model-driven Software Product Lines
91
.../supermod/repo/path/push?user=X&read
TransactionNr=Y&writeTransactionNr=Z. In
case Y does not equal the most recently closed
transaction number, the repository is out of date,
returning an response code that signalizes to
the client that a pull must be performed first.
Otherwise, the local repository is merged with
the delta XMI-serialized in the entity; a new write
transaction is started, whose number is returned.
5.3 Product Space Merging
As aforementioned, merging the client or remote
repository with incoming changes consists of visi-
bility merging, which has been implemented as ex-
plained in Section 4.4, and element merging, details
of which depend on the specific representation of the
product and version space.
Being based on EMF, SuperMod specializes the
set-theoretic definition of the repository (see Equa-
tion 1) by representing both version and product space
as a containment tree of elements. Likewise, non-
hierarchical cross-references are allowed between el-
ements. Sequences, which occur, e.g., as text files or
as values of ordered structural features in EMF mod-
els, are represented as a directed graph.
Product space merging has been implemented as a
recursive procedure beginning at the model roots. To
decide on equality of tree elements, specific match-
ing strategies are applied. For complex elements such
as EMF classes or features of the feature model, we
rely on unique object identifiers. Atomic values such
as EMF attribute values or lines in plain text files
are matched by string equality. In case two elements
of the repository and delta version are considered as
equal, they are merged, and so are their children recur-
sively. During sequence merging, transitive relation-
ships between vertices, encoded in paths, are main-
tained (Schw
¨
agerl et al., 2015c).
6 RELATED WORK
The original contribution of the current paper is the
addition of multi-user support to both a conceptual
framework for the integration of MDSE, SPLE, and
version control (Schw
¨
agerl et al., 2015a) and its im-
plementation SuperMod (Schw
¨
agerl et al., 2015b).
Reconciliation of revision control and variabil-
ity management has originated in the Uniform Ver-
sion Model (UVM) (Westfechtel et al., 2001), a con-
ceptual predecessor of our framework. UVM itself
is derived from change-oriented versioning (Munch,
1993) (CoV), which was implemented in the rela-
tional data base version control system EPOS. The de-
sign of a collaborative component for EPOS was pre-
sented in (Conradi and Malm, 1991). EPOS and Su-
perMod have in common a low-level transaction layer
assigning transaction numbers to versioned elements.
Furthermore, the notions of choices, ambitions, and
visibilities are shared, but CoV (and UVM) require
that the ambition must be fixed at check-out time.
As another difference, in EPOS, transactions may be
nested in a tree; user modifications are allowed only
in leaf transactions. There is technically no difference
between commit and push. Synchronization is orches-
trated by a propagation mechanism between differ-
ent workspaces. In contrast, SuperMod separates fil-
tered editing (check-out/commit) from synchroniza-
tion (pull/push) and transfers symmetric deltas only
on demand, leading to a less disruptive workflow.
EPOS offers (but is not restricted to) pessimistic syn-
chronization by inhibiting multiple transactions hav-
ing overlapping ambitions. This cannot be applied in
SuperMod, where the ambition is specified at commit
time. Conversely, EPOS does not explicitly address
three-way merging, such that “the last update wins”.
UVMs layered architecture (Westfechtel et al.,
2001) extends the low-level transaction layer of
EPOS. Transactions are manifested in visibilities by
means of transaction options, which coarsely corre-
spond to public revision options but are never shown
to the user in the form of a revision graph as realized
in SuperMod. Similarly, the variant management pro-
vided by UVM is more complex than in SuperMod,
since the user is exposed to variant options directly.
The distinction between local and remote trans-
actions used in this paper was borrowed from dis-
tributed revision control systems such as Git (Cha-
con, 2009), which extend centralized revision con-
trol systems such as Subversion (Collins-Sussman
et al., 2004), where, speaking in Git metaphors, each
commit enforces a pull. SuperMod and the under-
lying framework advance the state of the art in dis-
tributed revision control in two ways. On the one
hand, support for logical variants has been added by
integrating SPLE metaphors; by providing the possi-
bility of re-combining different features (i.e., inten-
sional versioning), our approach goes considerably
beyond branches and forks offered by Git. On the
other hand, models are versioned as structured arti-
facts rather than taking their text-based serialization
as a basis for line-oriented version control.
Few SCM systems have been extended with par-
tial support for SPLE, or vice versa. Adele (Estublier
and Casallas, 1994) has logical variants built into
its object-oriented data model as symmetric deltas,
ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends
92
which are exposed to the user. Temporal variabil-
ity is realized by a versioning layer on top, enabling
collaborative development. Conversely, in (Krueger,
2002), an extension to the SPLE toolchain BigLever
is presented that deals with controlling the variability
of different diverging products. In both approaches,
logical and cooperative versioning are not integrated
at the same conceptual level.
Software Product Line Evolution deals with com-
mon problems occurring during the management of
the life-cycle of software product lines, for instance
propagating changes from the variability model to the
platform (Laguna and Crespo, 2013). Product and
variability model are typically represented as artifacts
on the same conceptual level, i.e., there is no “version-
ing” relationship as in software configuration man-
agement. In addition, there exists no approach or tool
offering the full range of capabilities of state-of-the-
art version control systems. The approach by (Thao,
2012) relies on change propagation at configuration
level. In particular, the approach facilitates unfiltered
collaborative SPLE. Though, change propagation, as
opposed to state-based versioning, requires deep in-
tegration into the toolchain. The authors also present
a solution for semi-automatic backward propagation
of product-specific changes to the product line. How-
ever, instead of connecting visibilities of updated ele-
ments to an ambition as provided by SuperMod, man-
ual visibility updates are required.
Approaches to filtered editing can be found in ear-
lier literature (Sarnak et al., 1988) or in more recent
related work (Walkingshaw and Ostermann, 2014). In
the context of SPLE, filtered editing has only been
employed partially in related work. For instance, the
source-code centric tool CIDE (K
¨
astner et al., 2008)
offers the possibility to temporarily restrict a varia-
tional project to a view on a specific variant. Simi-
larly, the MDPLE tool Feature Mapper (Heidenreich
et al., 2008) includes a change recording mode. Al-
beit, these approaches are only designed for local fil-
tered editing rather than for collaborative MDPLE.
7 CONCLUSION
We have presented a novel approach facilitating col-
laborative SPLE, and in particular Model-Driven
Product Line Engineering. The key contribution is
the extension of a conceptual framework that had so
far enabled single-user MDPLE on the basis of a fil-
tered editing model. To this end, the existing reper-
toire of operations check-out and commit has been
extended by pull and push, which synchronize dif-
ferent copies of the product line repository. The op-
erations are defined based upon a collaborative revi-
sion graph, which organizes remote and local trans-
actions, as well as symmetric deltas. The conceptual
contributions have been implemented as plug-ins for
the Eclipse-based tool SuperMod, which has been ad-
vanced to a distributed version control system. The
server component has been realized as a REST-based
web service. The distributed VCS operations pull and
push have been mapped to the HTTP methods GET
and PUT; symmetric deltas are transferred in XMI
format. A low-level transaction layer ensures that
transactions are coordinated consistently. A compar-
ison with related work reveals that the extensions to
the framework and SuperMod advance the state of the
art in both version control and SPLE. Through a sim-
ple example, the added value of the theoretical contri-
butions has been demonstrated; the practical benefit
is demonstrated by screencasts (see below).
As soon as tool users apply concurrent modifica-
tions to the same versioned artifact, conflicts at prod-
uct space level may arise. This type of consistency
control is orthogonal to the problem of collaborative
editing. It has therefore been neglected in this paper
an will be addressed by future research.
Tool and Screencasts. The tool SuperMod is avail-
able as several Eclipse plug-ins from the following
update site:
3
. We recommend Eclipse Mars, Mod-
eling edition. The server component requires a Tom-
cat 7 servlet container. It is available as a web appli-
cation archive:
4
. A screencast illustrating the contri-
butions of this paper is available here:
5
. Adobe Flash
plug-in is required.
REFERENCES
Apel, S. and K
¨
astner, C. (2009). An overview of feature-
oriented software development. Journal of Object
Technology, 8(5):49–84.
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 Malm, C. C. (1991). Cooperating trans-
actions and workspaces in EPOS: Design and prelim-
inary implementation. In Proceedings of the 3rd In-
3
http://btn1x4.inf.uni-bayreuth.de/supermod/update
4
http://btn1x4.inf.uni-bayreuth.de/supermod/
webapp/supermod-server.war
5
http://btn1x4.inf.uni-bayreuth.de/supermod/screencast
(item Collaborative MDPLE based on the Graph exam-
ple)
Collaborative and Distributed Management of Versioned Model-driven Software Product Lines
93
ternational Conference on Advanced Information Sys-
tems Engineering (CAiSE’91), pages 375–392.
Czarnecki, K. and Kim, C. H. P. (2005). Cardinality-based
feature modeling and constraints: a progress report.
In International Workshop on Software Factories at
OOPSLA’05, San Diego, California, USA. ACM.
Estublier, J. and Casallas, R. (1994). The Adele configura-
tion manager. In Tichy, W. F., editor, Configuration
Management, volume 2 of Trends in Software, pages
99–134. John Wiley & Sons, Chichester, UK.
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.
K
¨
astner, C., Trujillo, S., and Apel, S. (2008). Visualizing
software product line variabilities in source code. In
Proceedings of the 2nd International SPLC Workshop
on Visualisation in Software Product Line Engineer-
ing (ViSPLE), pages 303–313.
Krueger, C. W. (2002). Variation management for soft-
ware production lines. In Proceedings of the Second
International Conference on Software Product Lines,
SPLC 2, pages 37–48, London, UK, UK. Springer-
Verlag.
Laguna, M. A. and Crespo, Y. (2013). A systematic map-
ping study on software product line evolution: From
legacy system reengineering to product line refactor-
ing. Sci. Comput. Program., 78(8):1010–1034.
Munch, B. P. (1993). Versioning in a Software Engineering
Database The Change Oriented Way. PhD thesis,
Tekniske Høgskole Trondheim Norges.
OMG (2011a). OMG MOF 2 XMI Mapping Specification,
Version 2.4.1. Object Management Group.
OMG (2011b). UML Infrastructure. Object Management
Group, Needham, MA, formal/2011-08-05 edition.
Pohl, K., B
¨
ockle, G., and van der Linden, F. (2005). Soft-
ware Product Line Engineering: Foundations, Princi-
ples and Techniques. Springer, Berlin, Germany.
Rochkind, M. J. (1975). The source code control sys-
tem. IEEE Transactions on Software Engineering,
1(4):364–370.
Sarnak, N., Bernstein, R. L., and Kruskal, V. (1988). Cre-
ation and maintenance of multiple versions. In Win-
kler, J. F. H., editor, SCM, volume 30 of Berichte des
German Chapter of the ACM, pages 264–275. Teub-
ner.
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 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 (MODELSWARD 2015), pages 5–18, Angers,
France. SCITEPRESS.
Schw
¨
agerl, F., Buchmann, T., Uhrig, S., and Westfech-
tel, B. (2016). Realizing a conceptual framework
to integrate model-driven engineering, software prod-
uct line engineering, and software configuration man-
agement. In Desfray, P., Filipe, J., Hammoudi, S.,
and Ferreira Pires, L., editors, Model-Driven Engi-
neering and Software Development, volume 580 of
Communications in Computer and Information Sci-
ence (CCIS), chapter 2, pages 21–44. Springer Inter-
national Publishing. Revised Selected Papers from
MODELSWARD 2015.
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 ICSOFT-PT 2015 - Proceedings of the 10th In-
ternational Conference on Software Paradigm Trends,
pages 5–18, Colmar, Alsace, France. SCITEPRESS.
Schw
¨
agerl, F., Uhrig, S., and Westfechtel, B. (2015c). A
graph-based algorithm for three-way merging of or-
dered collections in EMF models. Science of Com-
puter Programming, 113, Part 1:51 – 81. Selected and
Revised Papers from MODELSWARD 2014.
Steinberg, D., Budinsky, F., Paternostro, M., and Merks,
E. (2009). EMF Eclipse Modeling Framework. The
Eclipse Series. Addison-Wesley, Upper Saddle River,
NJ, 2nd edition edition.
Thao, C. (2012). Managing evolution of software product
line. In Glinz, M., Murphy, G. C., and Pezz
`
e, M., edi-
tors, 34th International Conference on Software Engi-
neering, ICSE 2012, June 2-9, 2012, Zurich, Switzer-
land, pages 1619–1621. IEEE.
Tichy, W. F. (1985). RCS a system for version con-
trol. Journal of Software: Practice and Experience,
15(7):637–654.
V
¨
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. (2014). Merging of EMF models - for-
mal foundations. Software & Systems Modeling,
13(2):757–788.
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.
ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends
94