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, Conﬁguration Management.

Abstract:

Software Product Line Engineering promises a signiﬁcant 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 ﬁltered editing framework that has

been extended by multi-user support. Using ﬁltered 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). Speciﬁc products are then derived in a prefer-

ably automated way based on feature conﬁgurations

that resolve variability. This requires to connect im-

plementation artifacts to speciﬁc 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

deﬁned to which speciﬁc 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 ﬁrst-class

artifacts from which application code is generated.

MDSE involves well-deﬁned languages such as the

Uniﬁed 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 ﬁltered editing model that

fully automates variability management using the re-

vision control metaphors check-out and commit. In

order to select a speciﬁc 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

check-out

modify

commit

Local Repository

Revision

Feature

Configuration

Choice

Feature

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 deﬁned 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 deﬁnition of the operations pull and push in

the context of ﬁltered 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 ﬁltered 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 ﬁltered product

line engineering, combining version control concepts

workspace, repository, revision graph with the SPLE

concepts feature model and (partial) feature conﬁg-

uration. Moreover, the version control operations

check-out and commit are extended by the speciﬁca-

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 conﬁguration has to

be speciﬁed. The selected revision of the feature

model and the selected version (revision and fea-

ture conﬁguration) of the product are ﬁltered 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 conﬁguration speciﬁed as ambition.

The contents of the local repository have been for-

mally deﬁned based on notions introduced by the Uni-

form Version Model (UVM) (Westfechtel et al., 2001).

Moreover, the internal data structure has been de-

ﬁned 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 deﬁn-

ing which elements of the version space are included

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

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 ﬁles 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 deﬁne the set

of versions V intensionally.

O = {o

,... ,o

} (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

∧ ... ∧ b

, b

∈ {o

,¬o

} (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 conﬁguration.

An ambition is an option binding that allows for

unbound options and thus denotes a subset of the ver-

sion space V .

a = b

∧ ... ∧ b

, b

∈ {o

,¬o

,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 ρ

all of which have to be satisﬁed by an

option binding in order to be consistent:

R = ρ

∧ ... ∧ ρ

(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

⇒ r

i−1

is in-

troduced; the mapping between the revision graph and

rule base constraints is redeﬁned 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

deﬁned 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 ﬁlter 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 speciﬁed ambi-

tion a, and deleted elements remain invisible there.

Accordingly, the updated visibility v

(e) is deﬁned:

(e) =











v(e) if e remains unmodiﬁed.

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 deﬁni-

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 justiﬁed 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

Remote and Local Transactions. Different copies

of the repository are synchronized not after each

commit, but only at user-deﬁned synchronization

points. For this purpose, the extended frame-

work distinguishes between remote transactions,

which are started with a pull and ﬁnished 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 ﬁgure and the table redeﬁne 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 deﬁnes an attribute for the revision number

– private revisions are externally displayed using the

nesting public revision as qualiﬁer – and additional

commit details (date, message, user). Secondly, a

generic predecessors/successors relationship is de-

ﬁned. 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 deﬁnes refer-

ences to low-level rule base elements (see Section 2),

which are transparently derived using the transforma-

tion patterns deﬁned 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 ﬁnishing (3) the trans-

action. Pattern (4) ensures that the initial revision is

selected. In general, predecessor/successor relation-

ships between two revisions r

i−1

and r

are mapped

to version rules of the form r

⇒ r

i−1

, i.e., when a

revision is selected, all predecessors are enforced to

be selected, too. There are ﬁve cases in which such

relationships are created: (5) After ﬁnishing 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 ﬁnishing a remote transaction. Pat-

tern (9) enforces a linear version history by automati-

cally merging with remotely ﬁnished transactions.

3.3 Example

To illustrate the dynamic behavior of a collabora-

tive revision graph, Figure 2 shows a sample version

history involving two ﬁctional developers, Alice and

Bob. Alice creates the repository, which transparently

introduces a revision option r

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

(6). By ﬁnishing 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) and r

⇒ r

0.∞

(5).

Concurrently, Bob clones the repository, which also

starts a write transaction (option r

, rule r

⇒ r

0.∞

Both developers commit private revisions to their lo-

cal repositories and then ﬁnish their current remote

transaction. Bob is the ﬁrst to push, r

is closed,

and r

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

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

and r

⇒ r

1.∞

. Al-

ice ﬁnishes the transaction in a straightforward way.

After that, Bob starts his work forgetting to pull r

Thus, he receives an out of date error when trying to

push r

3.∞

. The incoming r

4.∞

is automatically merged

before ﬁnishing r

. Please note: Despite the underly-

ing mechanisms deﬁned in Section 3.2 and illustrated

in this example being intrinsically complex, the ﬁc-

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 identiﬁers to each element. Using di-

rected deltas (Tichy, 1985), change sequences re-

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

Table 1: Detailed mapping between collaborative revision graphs and low-level version rules.

Nr. Pattern Transformation Metamodel Ref.

1 public revision r

option r

revisionOption

2 private revision r

i. j

nested in public revision r

option r

i. j

revisionOption

3 ﬁnished public revision r

option r

i.∞

ﬁnishedOption

4 initial public revision r

rule r

initPublicRule

5 public revision r

as successor of ﬁnished public revision r

i−1

rule r

⇒ r

i−1.∞

predecessorRules

6 initial private revision r

i.0

nested in public revision r

rule r

i.0

⇒ r

initPrivateRule

7 private revision r

i. j

as successor of private revision r

i. j−1

rule r

i. j

⇒ r

i. j−1

predecessorRules

8 ﬁnished public revision r

with private head r

i.h

rule r

i.∞

⇒ r

i.h

predecessorRules

9 public revision r

with incoming r

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

0..1initPublicRule

revisionNumber : int

date : Date

message : String

user : String

Revision

publicInit

publicHead

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.0

r0.∞

Push

r1.0 r1.7...

Commit

r2.0

r2.4...

Commit

Push

Outofdate

Pullr2

Pushagain

Push

r4.0 r4.5...

Commit

Clone

Push

...

Commit

Push

Outofdate

Pullr4

Pushagain

r3.∞

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

and ending at r

denote an instantiation of a predecessor rule r

⇒ r

Collaborative and Distributed Management of Versioned Model-driven Software Product Lines

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 ﬁltered editing and negative variability.

Cross-references. The conceptual framework ab-

stracts from speciﬁc 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 deﬁned 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 modiﬁca-

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 conﬂicts. Due

to space restrictions, this paper does not deal with

product conﬂict resolution in the workspace.

4.2 Low-Level Transaction Layer

In order to keep track of the elements modiﬁed 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

modiﬁcation (i.e., insertion, deletion, or modiﬁ-

cation of a child element). The visibility update

function (cf. Equation 10 in Section 2) is mod-

iﬁed 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

ﬁnishing 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

the speciﬁed transaction number (∆

), elements refer-

enced by elements in ∆

or by their visibilities (∆

and the transitive closure (

) over the containers (∆

)

of elements in ∆

or ∆

Algorithm 1: Symmetric Delta Projection.

procedure PROJECTDELTA(P, tNr)

∆

← elements of P carrying tNr

∆

for e

∈ ∆

for e

∈ elements cross-referenced by e

if e

/∈ ∆

then

∆

← ∆

∪ {e

}

for o

∈ options referred to in v(e

) do

← high-level concept of o

if ve

/∈ (∆

∪ ∆

) then

∆

← ∆

∪ {ve

}

∆

for e

∈ (∆

∪ ∆

) do

for e

∈ container

) do

if e

/∈ (∆

∪ ∆

) then

∆

← ∆

∪ {e

}

return ∆

∪ ∆

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 deﬁnition of the product space P, a merged

product space P

including an incoming delta ∆ can

be easily calculated as

= P ∪ ∆ (11)

However, element merging imposes several new chal-

lenges such as the identiﬁcation of “equal” elements,

which are rather speciﬁc to the implementation and

therefore discussed in Section 5.3.

Moreover, conﬂicts 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 conﬂict with an incoming delta, i.e.,

the local repository is out of date).

Raw Visibility Merging. In case no outgoing

changes exist to redeﬁne the visibility of an element

e ∈ P, it is assumed that the “more recent” visibility

is transferred from the delta to the local version.

(e) =



∆

(e) if e ∈ ∆ and v

∆

(e) is deﬁned.

(e) otherwise.

(12)

Three-Way Visibility Merging. If the local reposi-

tory is out of date, the visibilities of its elements in P

may conﬂict with the visibilities deﬁned in ∆. In this

case, the common base version b must be considered:

(e) =







(e) if e /∈ ∆ or v

∆

(e) is undeﬁned.

∆

(e) if e /∈ P or v

(e) is undeﬁned.

µ(v

(e),v

∆

(e)) otherwise.

(13)

Here, v

(e) is the visibility of e in the common base

version of the considered revisions in the revision

graph. Along with this, µ(v

) is the three-way

visibility merge function (Westfechtel, 2014):

µ(v

) = (v

∧ v

) ∨ (v

∧ ¬v

) ∨ (v

∧ ¬v

)

(14)

In case there is no difference between v

and v

, this

function evaluates to v

(conversely for swapping v

and v

). Otherwise, insertions and deletions made ef-

fective by the visibility update function (Equation 10)

are combined.

4.5 Deﬁnition of Pull and Push

Based upon the deﬁnitions from the preceding sub-

sections, we now formally deﬁne 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 ﬁnd

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

v w

0.0

)(

0.2

0.10.0

frr





)(

0.30.0 B

frr 

fr 

0.1

)(

))(

)((

0.4

0.2

0.10.0

frr







fr 

0.2

)(

0.3

0.2





fr 

0.4

)(

0.3

0.4





)(

0.3

0.4





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 unﬁnished 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 ﬁnishes 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 ﬁnished, 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 simpliﬁcations: (1) One change is

performed per commit. (2) For each remote transac-

tion, only the ﬁrst commit is shown. (3) The feature

model consists of two optional features f

and f

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 ﬁnal 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 speciﬁc feature,

resulting in ambition true. The transferred delta

contains { f

, f

,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

. The delta is { f

,q, x,s, z}.

Revision 1. Alice concurrently removes arc q and

bubble x, and adds arc p, under ambition f

. The

delta is { f

,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 ﬁrst to ﬁn-

ish, so Alice receives an out of date error when

trying to push. When pulling to r

, the incoming

delta is merged. The visibility of arc q and bubble

x has been concurrently modiﬁed, such that v

0.0

∧¬(r

1.0

∧ f

) and v

∆

= r

0.0

∧¬(r

2.0

∧ f

). Us-

ing the base visibility v

= r

0.0

, the three-way vis-

ibility merge function (Equation 14) evaluates to

(q) = v

(x) = r

0.0

∧ ¬(r

1.0

∧ f

) ∧ ¬(r

2.0

∧ f

Revision 4. Alice re-inserts bubble x and adds bubble

y, arcs t and u under ambition f

. The delta is

{ f

,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

. The transferred delta is

calculated as { f

,w,s, u,y, z}.

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

Merging Revisions 1 and 2. Bob receives an out of

date error when trying to push. As a consequence,

the incoming delta of r

is merged. This time,

the visibilities of arc u and bubble y are merged:

µ(true,r

4.0

∧ f

3.0

∧ f

) = (r

4.0

∧ f

) ∨ (r

3.0

∧

). 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 speciﬁed 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 trafﬁc 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 ﬁle

system. Additionally, the transaction log (see Sec-

tion 4.2) is stored within a simple text ﬁle.

Read and write transactions are protected by a

server-side lock ﬁle, 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>

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

ﬁnishing a write transaction successfully, all modiﬁed

EMF resources are saved at a time; otherwise, in case

the transaction has been canceled, all modiﬁcations

are rolled back.

5.2 Mapping VCS to REST Operations

The architectural style REST is based on the Hyper

Text Transfer Protocol (HTTP). Modiﬁable and non-

modiﬁable data is qualiﬁed 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 modiﬁcation.

Below, the mapping of the distributed VCS op-

erations create

, 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 .

Push. Transferring client-side changes to the remote

repository is realized as a PUT method on

Conceptually trivial, therefore omitted in Section 4.

Y = −1 requests the entire repository (clone).

Collaborative and Distributed Management of Versioned Model-driven Software Product Lines

.../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 ﬁrst.

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 speciﬁc representation of the

product and version space.

Being based on EMF, SuperMod specializes the

set-theoretic deﬁnition 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 ﬁles 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, speciﬁc match-

ing strategies are applied. For complex elements such

as EMF classes or features of the feature model, we

rely on unique object identiﬁers. Atomic values such

as EMF attribute values or lines in plain text ﬁles

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 ﬁxed at check-out time.

As another difference, in EPOS, transactions may be

nested in a tree; user modiﬁcations 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 ﬁl-

tered editing (check-out/commit) from synchroniza-

tion (pull/push) and transfers symmetric deltas only

on demand, leading to a less disruptive workﬂow.

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 speciﬁed at commit

time. Conversely, EPOS does not explicitly address

three-way merging, such that “the last update wins”.

UVM’s 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

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 conﬁguration 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 conﬁguration

level. In particular, the approach facilitates unﬁltered

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-speciﬁc 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 ﬁltered 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, ﬁltered 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 speciﬁc 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 ﬁl-

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 ﬁl-

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 deﬁned 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 beneﬁt

is demonstrated by screencasts (see below).

As soon as tool users apply concurrent modiﬁca-

tions to the same versioned artifact, conﬂicts 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:

. 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:

. A screencast illustrating the contri-

butions of this paper is available here:

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

http://btn1x4.inf.uni-bayreuth.de/supermod/update

http://btn1x4.inf.uni-bayreuth.de/supermod/

webapp/supermod-server.war

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

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 conﬁgura-

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

Management, volume 2 of Trends in Software, pages

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

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.

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 Speciﬁcation,

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 conﬁguration management. In Ham-

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

tors, Proceedings of the 3rd International Conference

on Model-Driven Engineering and Software Develop-

ment (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 conﬁguration 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.

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