Integrated revision and variation control for evolving model-driven software product lines

Abstract

Software engineering projects are faced with abstraction, which is achieved by software models, historical evolution, which is addressed by revision control, and variability, which is managed with the help of software product line engineering. Addressing these phenomena by separate tools ignores obvious overlaps and therefore fails at exploiting synergies between revision and variation control for models. In this article, we present a conceptual framework for integrated revision and variation control of model-driven software projects. The framework reuses the abstractions of revision graphs and feature models and follows an iterative, revision-control-like approach to software product line engineering called product-based product line development. A single version (i.e., a variant of a selected revision) is made available in a workspace, where the user may apply arbitrary modifications. Based on a user-provided specification of the affected variants, the changes are automatically written back to a transparent repository that relies on an internal multi-version storage. The uniform handling of revisions and variants of models is achieved by transparently mapping version concepts to a semantic base layer, which is defined upon propositional logic. At the heart of the conceptual framework is a dynamic filtered editing model, which allows that the versioned artifacts and the feature model co-evolve. We contribute algorithms for checkout and commit, which satisfy a set of consistency constraints referring to variant specifications in an evolving feature model. This article furthermore addresses the orchestration of collaborative development by distributed replication and the well formedness of text and model artifacts to be checked out into the workspace. The Eclipse-based tool SuperMod demonstrates the feasibility of the conceptual framework. It allows the user to reuse arbitrary editing tools for text-based programming and/or Ecore-based modeling languages. An evaluation based on three case studies investigates the properties of SuperMod with a specific focus on filtered editing. The evaluation demonstrates that the dynamic filtered editing model reduces the cognitive complexity and the amount of user interaction necessary for variation control when compared to unfiltered model-driven approaches to software product line engineering.

Case studies

In this appendix, which is an excerpt of [48, Sect. 15.3], the case studies conducted with regard to the evaluation summarized in Sect. 8 are presented. The evaluation subjects developed the multi-version artifacts from scratch based on a list of requirements provided beforehand. We here present the revision histories, logs of command histories including all relevant version management actions (checkout, commit, amend, etc.), and relevant extracts of the product resources available in their local workspace.

1.1 Extended Graph library

This case study, excerpts of which serve as running example in this article, was initially described as an evaluation case in [36] and adapted for the demonstration of many SPL approaches in literature. Below, we present a complete version of the product line that has been developed by the authors from scratch. Figure 22 summarizes the SuperMod commands invoked during the experimentation.

Fig. 22

History of interactive commands for the Graph case study

Requirements To make the experimentation of this synthetic case study as realistic as possible, the requirements for the product line were assigned to different product line increments realized by Alice and Bob alternatingly. Furthermore, intentional obstacles were created, such that synchronization conflicts and product well-formedness violations came into play. The list of task descriptions is reproduced here:

Table 12 Version history underlying the Graph Library case study

• 1. Alice: Initialize the repository. Add basic support for graphs that contain a node set and an edge set. Assume graphs are undirected, but do not define a feature for this.

• 2. Bob: Clone Alice’s repository. Introduce a mutually exclusive distinction between directed and undirected graphs. Ensure that Alice’s realization of edges is valid for undirected graphs only, and commit a new realization for directed graphs.

• 3. Alice: Concurrently to Bob’s change above, add support for labeled and weighted graphs as two optional, independent features. Reconcile your changes with Bob’s.

• 4. Bob: Wait until Alice pushes revision 3. Add support for colored graphs.

• 5. Alice: Add constructors to the classes for vertices and edges. Their parameters should match the available properties for colored/labeled/weighted/directed graphs.

• 6. Bob: Concurrently, define new features for the graph algorithms transpose (requires a directed graph) and shortest path (requires a directed and weighted graph). Reconcile your changes with Alice’s.

Preliminaries The case study was conducted with SuperMod in combination with the UML modeling tool Valkyrie [9].

The technical preparations were made in Alice’s modeling environment. After having initialized the Valkyrie project using the provided project wizard, the domain model created is represented as two models, an abstract syntax model (an instance of the Eclipse UML 2.0 metamodel), and a GMF notation model that defines concrete graphical class diagram syntax for abstract model elements.

To this Eclipse project, SuperMod support was added by the Share command. After selecting the hybrid collaborative repository architecture in a first step, the connection to the central remote repository was established.

Overall version history Before we present the key user actions performed in the subsequent remote transactions, we summarize the complete version history of the case study in Table 12.

Fig. 23

Alice’s workspace contents after public revision 1

The majority of private revisions was processed in “the straightforward way”: introduce a new feature, add corresponding realization artifacts to the domain model, and commit, using an ambition where the newly introduced feature is positively bound and no further bindings are set.

Public revision 1 In revision 1.1, Alice commits the initial workspace contents using an empty ambition (as no features are defined yet). Revision 1.2 exclusively refers to the feature model—the result of the corresponding modifications is shown in Fig. 23a. In revisions 1.3 until 1.5, the features Graph, Vertices, and Edges are realized straightforwardly (cf. Table 12). Revision 1.6 is an evolutionary change and therefore addresses the same set of variants (derived feature ambition $\{(O_{Edges}, true )\}$). The resulting view on the domain model—which equals here the multi-variant domain model as all features are mandatory so far—is depicted in Fig. 23b. Alice concludes the remote transaction by a Push.

Public revision 2 Bob joins the fictional project based on a Clone of revision 1 pushed by Alice. The remote transaction running in his workspace gets the public revision number 2 assigned.

After defining the mutually exclusive features Directed and Undirected, Bob is faced with the problem that the realization of the second feature is already present in the workspace. The corresponding elements therefore need to be constrained to Undirected variants. Bob achieves this by removing the elements in question from his workspace and by committing this deletion using an ambition where Undirected is negatively selected; see Fig. 24a. Through this “double negation”, the visibilities of deleted elements will be automatically conjuncted with the feature option belonging to Undirected. (The same principle is applied in revisions 35 until 37 of the Home Automation Example.)

Fig. 24

Variant definitions provided by Bob in revision 2

Subsequently, Bob is prompted for the definition for an option binding for Directed in an interactive migration. Selecting $true$, this produces the correct choice for the change realized in revision 2.2, namely the definition of two associations for directed edges. An explicit checkout is not required either. Figure 25 depicts Bob’s repository contents at push time. Public transaction 4 is started in his workspace.

Fig. 25

Bob’s repository contents at the end of revision 2

Public revision 3 Alice starts her work on the subsequent public transaction in advance to Bob’s push; therefore, the version history is temporarily branched. In revision 3.1, she introduces the features Weighted and Labeled. Furthermore, she realizes the former feature in the domain model.

Fig. 26

Version space and workspace presented to Alice in revision 3

After committing, Alice is prompted for an interactive choice migration since the binding for feature Labeled is missing. She specifies a positive selection (cf. Fig. 26a) because this matches her intention for the subsequent private revision 3.2, where she realizes this feature straightforwardly. The final workspace contents are depicted in Fig. 26b.

As prescribed by the experimentation requirements, as soon as Alice attempts to push, a synchronization obstacle occurs as Alice’s version history must be reconciled with Bob’s public revision 2 finished in the meantime. Following SuperMod’s collaborative workflow, an out of date situation is signaled to Alice, who is forced to pull and to update her workspace to the latest revision. As her current workspace choice does not provide bindings for the remotely defined features Directed and Undirected, Alice is forced to complete her workspace choice interactively—see Fig. 27.

Fig. 27

Interactive choice migration after Alice’s pull during public revision 3

Alice’s and Bob’s concurrent modifications are, however, not conflicting at product level, such that no well-formedness violations occur in Alice’s workspace after pull and update. She may therefore resume her push without any further restrictions.

Public revision 4 Bob waits for Alice to push, preventing synchronization problems beforehand. Then, he checks out a weighted, directed, unlabeled variant. The realization of the feature Colored defined by the requirements list happens in a straightforward way—see Table 12. Figure 28 depicts Bob’s workspace contents as he pushes.

Fig. 28

Bob’s workspace contents after public revision 4

Public revision 5 Alice, too, avoids synchronization problems by awaiting Bob’s push. For defining the constructor of class Vertex, she checks out a colored, labeled, weighted, undirected variant. The realization is split into two distinct commits (with different ambitions): In revision 5.1, a constructor without parameters is introduced for the feature Vertices. The parameter color is added conditionally for Colored variants in revision 5.2.

Still in the same workspace view, Alice defines the constructor for Edge in revision 5.3, as well as the parameter for undirected edges (adjacents of type Vertex with multiplicity 2) in revision 5.4. The intermediate workspace contents are depicted in Fig. 29.

Fig. 29

Alice’s workspace after private revision 5.4

Fig. 30

Alice’s workspace after private revision 5.6

Thereafter, the constructor parameters for directed graphs are addressed. To this end, Alice must checkout based on a different choice, selecting feature Directed as well as all other non-conflicting optional features. In revision 5.5, the parameters source and target are added conditionally for Directed graphs. In the same view, the parameter weight is added for Weighted graphs in revision 5.6; see Fig. 30.

In this way, the mutual order of the constructor parameters belonging to Directed and Weighted is fixed; however, no mutual order for adjacents and weight has been defined, although the features are allowed to be combined. In order to avoid well-formedness violations in future products, Alice uses revision 5.7 to make the order explicit. Switching back to her first choice (checking-out an undirected, colored, weighted, labeled graph), an order conflict is reported to Alice as expected. This is default-resolved by placing adjacents before weight, which matches Alice’s preference. For the subsequent commit, she must specify an ambition that is specific enough for the performed change—she positively selects the features Undirected and Weighted, which are realized by the affected parameters.

Last, Alice straightforwardly adds a last constructor parameter for Labeled graphs. After this, a total order (except for the parameters belonging to the mutually exclusive features Directed and Undirected) is defined in the transparent multi-version collection that organizes the constructor parameters of Edge. The workspace domain model present in Alice’s workspace as she pushes is shown in Fig. 31.

Public revision 6 Without awaiting Alice’s push, Bob contributes the final public revision in the straightforward way. The first revision 6.1 is used to introduce features and constraints for the algorithms Transpose and ShortestPath; see Fig. 32a. These are positively selected in the subsequent interactive migration and then realized as operations using the corresponding features as ambitions in revisions 6.2 and 6.3. Then, Bob attempts to push, being forced to pull Alice’s changes connected to public revision 5 first.

Fig. 31

Alice’s workspace after private revision 5.8

Fig. 32

Bob’s final workspace contents at public revision 6

Since both Alice and Bob add elements to the operations list of class Vertex, another order conflict is raised here. This time, the default resolution strategy suggests an order that is not in line with the usual convention that constructors are placed before regular operations: [shortestPath, Vertex]. Therefore, Bob manually revises the repair action and switches the order. The resulting workspace contents depicted in Fig. 32b are committed under $\{(o_{ShortestPath}, true )\}$. Bob pushes the final state of the Graph case study.

1.2 Home automation system

In a second evaluation case,¹ we apply SuperMod to the standard example of a product line for Home Automation Systems (HAS) from [44]. A HAS consists of several technical components communicating with each other; since most components are optional and interchangeable, this case study is frequently used for product lines. We here abstract from the communication layer and consider a requirements-centric view of the system. Moreover, we conduct the study in single-user mode.

The larger part of the case study is organized in a plan-driven way. Consecutively, the activities analysis, design, and implementation (based on generated source code) are executed. For analysis and design, we rely on UML use case, activity, package, and class diagrams using Valkyrie [9] (see above) and its Java code generator. At the end, fictional customer feedback that required to revisit design decisions is given. Figure 33 depicts the underlying command history.

Table 13 Version history of the use case diagram. Based on [52, Table 1]

Requirements analysis Requirements analysis is split into two phases. To begin with, residents’ interactions with the HAS are documented in a use case diagram. Subsequently, one use case is representatively refined by means of an activity diagram.

After having initialized a Valkyrie project and having connected it to SuperMod version control, the first phase is initiated based on an empty use case diagram. In consecutive iterations, we introduce actors, components, use cases, and relationships as summarized in Table 13. The table also shows that the feature model is developed simultaneously, introducing new features on demand in order to delineate the scope of the respective changes. Figure 34 depicts a variant of the final use case diagram.

Fig. 33

Command History of the HAS case study

During the second analysis phase, the feature IdentificationMechanism is further refined by adding three concrete mechanisms, namely Keypad, MagneticCard, and FingerprintScanner. Features representing these mechanisms are organized in an OR-group, meaning that at least one mechanism must be chosen in a valid configuration. In case several mechanisms are available, one of them must be chosen during identification at runtime (see below). The available selection should be restricted by the active features; this is realized in revisions 10 until 12 shown in Table 14. The resulting activity diagram is depicted in Fig. 35; Figure 36 presents the feature model in its state at the end of the analysis phase.

Design The static structure of the HAS product line is also developed in two phases. After modeling an initial package diagram, specific packages are refined by class diagrams.

Fig. 34

The use case diagram of the HAS study after revision 7, shown in a variant that includes all mandatory and optional features available. From [52, Fig. 7]

Table 14 Version history of the activity diagram for Identify. Based on [52, Table 2]

Table 15 indicates that the package diagram (see Fig. 37) is developed in an iterative and incremental way by realizing one feature after another. Variation points are anticipated by static modeling of appropriate design patterns, namely Strategy and Command [21], which are thereafter refined by class diagrams. Here, we refrain from introducing new features during the design phase.

As shown in Table 16, the package identification is refined by a class diagram, exemplifying the realization of transparent variation points during design. In revision 29, general details are added to the class IdentificationMechanism as well as to the interface IMechanism that realizes the Command pattern. Its specific realizations are added subsequently and scoped with the respective feature. In this case, the only necessary changes are to make the respective command classes realize IMechanism (see Fig. 38). Similar refinements might have been applied to the packages doorLock, alarm, and heating.

Fig. 35

The activity diagram of the use case Identify after revision 12, shown in a variant that includes all sub-features of IdentificationMechanism. From [52, Fig. 8]

Fig. 36

The final HAS feature model after revision 12. From [52, Fig. 9]

Implementation In the here considered model-driven product line, the structural part of the source code can be derived from the artifacts developed in the design phase using Valkyrie’s Java source code generator. The main class HomeAutomationSystem shall contain the main executable as command line application. Below, we confine the presentation to the implementation of the method identify() of class IdentificationMechanism, which implements the activity diagram shown in Fig. 35 above.

Variability is achieved by making the declarations and usages of specific mechanism classes dependent on their respective features. As indicated in Table 17, after the initial code generation run in revision 33, a variant that includes all identification mechanisms is made available in the workspace. In revision 34, a multi-variant implementation is provided by manual source code extensions (see Listing 1). We then connect the variable constructor calls and the concrete implementation classes to their respective features by applying the negative implementation, i.e., by removing the corresponding source code file and the statement containing the constructor call, and by committing against the negation of the respective feature. In advance to performing these deletions, it is necessary to checkout explicitly a suitable choice where the respective features are deselected.

Table 15 Version history of the package diagram. Additional horizontal lines indicate that an explicit checkout was necessary between the affected revisions. Based on [52, Table 3]

Responding to customer feedback So far, the SPL has been developed in a phase-structured and proactive way, following the classical development activities analysis, design, and implementation. We now investigate to which extent SuperMod and the underlying approach allow to react to a new customer request that crosscuts all three development activities. The fictional customer feedback consists in a feature request to extend the list of identification mechanisms available by a biometric mechanism.

In response to this feedback, we checkout the latest revision of the HAS, choosing the customer’s product variant (which includes all sub-features of IdentificationMechanism). Then, we realize the increment in one single iteration under the same feature ambition.

• Analysis. A new feature Biometric is introduced to the OR-group below IdentificationMechanism (cf. Fig. 36). The request does not affect the use cases themselves, but the activity diagram that details the use case Identify (cf. Fig. 35): We add a new activity BiometricIdentification and connect it to the decision/merge node in analogy to the existing identification actions.

• Design. We define a new class Biometric as well as an outgoing realization relationship to the interface IMechanism in the class diagram shown in Fig. 38. This transparently extends the package diagram’s view (cf. Fig. 37).

• Implementation. The (incremental) code generation is re-invoked, creating a new source file Biometric.java. To the implementation of method IdentificationMechanism.identify() (cf. Listing 1), we add after line 99:

  

• Deployment. The current iteration is finalized by committing all pending changes to the repository under revision 38. In the feature ambition, exclusively the new feature Biometric is selected positively. Last, the same product variant as present in the developer’s workspace is deployed to the customer using the Export command.

Fig. 37

The package diagram after revision 28. The product variant shown does not include features Active and Automatic, thus not classes doorLock::ActiveLock and heating::Automatic, either. From [52, Fig. 10]

Table 16 Revision history of the class diagram refining package identification. Based on [52, Table 4]

1.3 Bootstrapping SuperMod

In a third case study, SuperMod is applied to an instance of a custom metamodel, which in turn is based on Ecore. The considered modeling language reflects an extended subset of the conceptual framework’s core metamodel introduced in Sect. 3.2; it is capable of describing the architecture provided by as well as the operations offered by a concrete SuperMod repository. The architecture in turn comprises a specific combination of pre-defined dimensions, which can be version-related (e.g., the revision graph), product-related (e.g., the versioned file system), hybrid (e.g., the feature model), or transparent (e.g., the change space optimization presented in [50]). Overall, the product line shall be capable of reproducing at least seven conceivable repository architectures (the details of which are out of scope of this article; see [48, Sect. 14.3]).

Fig. 38

The class diagram that refines package identification (revision 32), with Keypad, MagneticCard, and FingerprintScanner selected. From [52, Fig. 11]

Table 17 Overall commit history of the implementation phase. Based on [52, Table 5]

The SuperStrap (for SuperMod bootstrap) metamodel is depicted as an Ecore class diagram in Fig. 39. A repository consists of an ordered set of dimensions. These are connected by a cross-reference controlledDimensions, which indicates a versioning relationship. A set of operations represents the commands available to the user.

For editing the singleton instance of the SuperStrap metamodel versioned by SuperMod, a customized generated EMF tree editor is used in this experiment. For better precision, the generated source code has been extended such that the editor relies on UUIDs.

The focus of this experiment lies on the suitability of the approach for fine-grained and alternative variability. To this end, we add an intentional obstacle, which is reflected by the attribute architectureCode. Its value must be unique for every allowed repository architecture mapped by corresponding feature configurations. Conversely, the metamodel defines this attribute as single-valued, such that alternative values cannot be expressed in a single-version model instance (constrained variability).

The overall command history summarizing the actions underlying this case study is depicted in Fig. 40.

Requirements Feature model and domain model shall be edited concurrently based on a list of domain model artifacts to be considered in consecutive blocks of iterations:

• 1. The specific dimensions and their relationships.

• 2. Pieces of optimization controlled by individual features: visibility forest and change space (see [50] for interest; not in scope of this article).

• 3. Operations to be offered by concrete variants of the repository. We here confine the list to CheckOut, Commit, Pull, Push, and Amend (see [55] for interest; not in scope of this article).

• 4. Finally, the distinct values of the attribute architectureCode.

Table 18 Revision history of the first phase of the bootstrapping case. Additional horizontal lines indicate that an explicit checkout was necessary

Fig. 39

The SuperStrap metamodel underlying the third evaluation case

Fig. 40

Command History of the SuperStrap case study

Preliminaries In an empty Eclipse project, a new model conforming to the SuperStrap metamodel is created, instantiating a new Repository as root object. Then, SuperMod version control support is added based on the hybrid (non-collaborative) repository architecture. The initial contents are committed as revision 1.

Dimensions and relationships In the first phase of the case study, we introduce features for the human-visible dimensions (file hierarchy, low-level logical dimension, feature model, revision graph, and collaborative revision graph). As evident from the revision history shown in Table 18, there is a one-to-one correspondence between features and instances of Dimension. Furthermore, the relationships between the dimensions—represented as instances of controlledDimension—depend on combinations of source and target feature.

Due to the mutual exclusions between features Logical and FeatureModel, as well as RevisionGraph and Collab, it is necessary to apply the changes in three different views, such that two explicit checkouts become necessary. In these situations, the operation Migrate is not applicable since the respective bindings added in the ambition are conflicting with the subsequently intended choice.

Single-version views on different revisions of the domain model, as well as the final revision of the feature model, are provided in Fig. 41.

Fig. 41

Workspace artifacts belonging to the first phase of the bootstrapping case

Table 19 Revision history for the second phase of the bootstrapping case

Optimization. The optimizing features suggested by the requirements list are reflected in the domain model in two different ways. First, the visibility forest is covered by an instance of a corresponding class attached to the repository (see revision 15 in Table 19); this modification involves a successful interactive migration step. Second, the change space is represented in the solution space as an additional, transparent dimension that controls all other version dimensions, except for the low-level logical dimension, to which an excludes relationship is defined in the feature model.

The corresponding controlledDimensions links are added under suitable ambitions; this requires to use two different choices in total, such that one additional checkout operation comes into play. We begin in a collaborative variant—this feature is still present in the workspace after revision 14—and switch to a single-user variant in advance to realizing revision 19. Fig. 42 presents relevant cutouts of the artifacts modified in the local workspace.

Operations When compared to the two previous phases, the changes connected to the operations offered by the repository are less invasive. Furthermore, the operations are not explicitly modeled as features.

Fig. 42

Workspace artifacts for the second phase of the bootstrapping case

Table 20 Revision history for phase three of the bootstrapping case

Fig. 43

Workspace domain model, revision 22, of the bootstrapping case

Table 21 Architecture codes specified during phase four of the bootstrapping case

As indicated by Table 20, CheckOut and Commit are offered by all repository architectures available, whereas Pull and Push require the existence of a collaborative dimension. Last, the operation Amend is exclusive for repository architectures that contain both a change space and a feature model as dimensions [50, 55].

In this specific version history, it is not necessary to explicitly checkout by a choice where ChangeSpace is active, since this feature has already been positively bound in the ambition of revision 22.

Figure 43 depicts a product variant with all operations enabled.

Architecture code In spite of its rather simple representation in the solution space—the value of a string-valued attribute—the architecture code appears to be the most complex detail for multi-variant realization. As listed in the requirements, the value of architectureCode is supposed to match the most adequate identifier of the seven conceivable SuperMod architectures. This provides an extreme case of alternative variability, which is managed in an unconstrained way by SuperMod’s intrinsic repository representation.

Since the different values of this attribute are mutually exclusive in the model instance presented in the workspace, seven different ambitions are necessary to match this requirement. Table 21 summarizes the revision history; six explicit checkouts are applied between the corresponding iterations, provided that we can stay in the view obtained after revision 22 before realizing and committing revision 23.

In the checkout performed in advance to the final revision 29, we are faced with a product conflict: the mutual order of the dimensions RevisionGraph and Logical has not been defined unambiguously during the first phase of the case study (cf. Table 18), as the orthogonal architecture does not assume any relationship between these dimensions. The default resolution strategy (which gives priority to the least recent value) resolves the order conflict by placing the logical dimension before the revision graph. Albeit, version selection is performed in the historical dimension first, thus we correct this order in the course of manual reconciliation. Figure 44 shows both the revised workspace contents and the ambition used for the final commit.

Fig. 44

Workspace contents and feature ambition for revision 29