Next we present and discuss the outputs of each step of ModelVars2SPL.

Features Traceability

The table below presents the modules of BS obtained in the Feature Traceability. The module d0(+Base.{0}) represents the mandatory feature Base and it is the feature with the highest number of elements. The modules d1(−Converter.{0}, +Consortium.{0}) OR d1(+Base.{0}, −WithdrawLimit.{0}) represent those elements that are present when the feature Converter is not present and feature Consortium is present, or when the Base is present but WithdrawLimit is not present.

The relationships between modules are represented in a dependency graph, which is illustrated as follows. We can observe that all modules have relationships with the module d0(+Base.{0}), which has the mandatory feature Base. The number of dependencies in the graph is shown by the edge labels. This dependency graph provides information regarding the composition of the variants. For example, if we want to add the feature WithdrawLimit in a variant that has only feature Base, then we need to put seven model elements of d0(+WithdrawLimit.{0}) together d0(+Base.{0}) and remove two elements of the moduled d1(+Base.{0}, −WithdrawLimit.{0}).

Reverse Engineering of Feature Models

An example of FM obtained with our approach is illustrated below. This FM is the optimal solution found by NSGA-II for the BS case study. Considering the eight variants of BS, the FM denotes the exact combination of features desired and does not break any dependency of the dependency graph. The tree of the FM is illustrated at the top of the figure, which has one mandatory feature Base, and three optional features Converter, Consortium, and WithdrawLimit. The eight possible combinations of features (i.e., configurations) are presented at the bottom of the figure.

Model Merging

To illustrate the output of the Model Merging step, the figure below presents the merged model for the BS case study. This model is a complete class diagram with all the existing elements among the variants. Compared to BS8, which is the variant with all features, this model has represented the absence of features related with the variants without the feature WithdrawLimit. This means that this model provides a better overview of all variants, considering both presence and absence of model elements.

Variability Grafting

An example of PLA (i.e., an annotated class diagram) for the BS case study is illustrated in the following. The model is the same of previous step, except from the annotations regarding the variabilities and features. For a sack of illustration, we present annotation of classes, attributes, and operations. The classes Bank, Consortium, and Converter, have their annotations depicted at the bottom of the figure. The annotated attributes accounts, converter, and cons, of the class Bank are illustrated at the top of the figure. The comment annotations for the operations deposit(), withdrawLimit(), and withdrawWithoutLimit() are presented on the right.

Download Case Studies of Scenario 1 - In this scenario the case studies are composed of variants which implement all possible configurations (i.e., combinations of features). For instance, there are variants which implement few features and a variant which implements the maximum possible number of features.