Extraction and Evolution of Architectural Variability Models in Plugin-based Systems

The following web page provides material, details and results of the experiments we conduct in reverse engineering architectural feature models from different versions of the  FraSCAti project.


Case Study and Motivation

FraSCAti Architecture

Started three years ago, the development of the FraSCAti platform begun with a framework, first validated by a basic implementation of the standard, and then incrementally enhanced. After four major releases, it now supports several SCA specifications (Assembly Model, Transaction Policy, Java Common Annotations and APIs, Java Component Implementation, Spring Component Implementation, BPEL Client and Implementation, Web Services Binding, JMS Binding), and provides a set of extensions to the standard, including binding implementation types (HTTP, Java RMI, JMS, JSON-RPC, REST, SOAP, JNA, UPnP), component implementation types (composite, Java, BPEL, Fractal, OSGi, Scala, Java supported scripting languages like BeanShell, Groovy, JavaScript, Jython, JRuby), interface description types (Java, WSDL, UPnP, C headers), property description types (Java et XSD), runtime API for assembly and component introspection/reconfiguration (see paper at  SCC'09).

As its capabilities grew, FraSCAti has also been refactored and completely architected itself with SCA components. With all these capabilities, the platform has become highly (re-)configurable in many parts of its own architecture. It notably exposes a larger number of extensions that can be activated throughout the platform, creating numerous variants of a FraSCAti deployment. For example, some variations consist in one or more specific components bound to many other mandatory or optional parts of the platform architecture. It then became obvious to FraSCAti technical leads that the variability (i.e., "the ability of a software system or artefact to be efficiently extended, changed, customized or configured for use in a particular context.") of the platform should be managed to pilot and control its evolution as a Software Product Line (SPL).

FraSCAti Artefacts

The entire set of .composite files and SCA diagrams form the "architectural model" of FraSCAti.

.composite_diagram and .png files have been automatically generated using Eclipse SCA Tools (plus a manual layout).

You can download the .composite and .composite_diagram files below. Note that the files are from the last version of the FraSCAti project.

main SCA composite of FraSCAti (other components are described below)

FraSCAti composite PNG

implementations, interfaces, bindings and properties

AssemblyFactory composite PNG

SCA composite of the FraSCAti parser


SCA composite of the FraSCAti composite parser


metamodels supported by the FraSCAti SCA parser



Component Factory

Java compilers and membrane generators


binding factory


services (empty composite at the moment)


Goal: Extraction and Evolution of FraSCAti Architectural Variability Model

In order to manage the FraSCAti platform as an SPL, we needed to capture its variability from the existing architecture. We chose to rely on a particular kind of variability model, Feature Models (FMs), based on their wide adoption, the existence of formal semantics, reasoning techniques and tool support. Several software artefacts (SCA composite files, Maven descriptors, unformal documents) describe FraSCAti architecture, but variability, though, is not explicitly represented. As the FraSCAti main software architect (SA) had an extensive expertise in the architecture and in its evolution, it was decided to make him model the architecture he has in mind with variation points (see left part of the figure). As a domain expert, he had the ability to elicitate the architectural variation points and explain rationale behind these decisions.

Motivating scenario

This task resulted in a manually created FM (see Figure, or download the FM (FeatureIDE or S2T2 format)) and it was clearly daunting, time-consuming and error-prone, requiring substantial effort from the SA.

fmSA (originally designed by Philippe Merle, software architect of FraSCAti) S2T2 screenshot

In this case as in all large scale architectures, it is very difficult to guarantee that the resulting FM ensures a safe composition of the architectural elements when some features are selected. Another approach thus relies on an automated extraction, so that an architectural FM that represents variability of the architecture is automatically extracted from the appropriate artefacts (see right part of the figure). This operation clearly saves time and reduces accidental complexity, but the accuracy of the results directly depends on the quality of the available documents and of the extraction procedure.

Extraction of Architectural Variability Model

Overview and illustration

We now describe how we realize the extraction procedure.

Extraction procedure

Let us a take a simple example, summarized by the following figure:

Projection example

where FMs are examplified versions of FMArch150, FMPlugin, FMArch.

The set of configurations is as follows:

Set of configurations of FMArch150 Set of configurations of FMFull Set of configurations of FMArch

Using the language FAMILIAR (the file projectionExample.fml is available for download), we can realize the scenario ...

FAMILIAR projection example (screenshot)

... and give information to the software architect (e.g., which configurations have been removed from the 150% architectural FM).

Projection example (FML sessin in Eclipse)

A similar FAMILIAR script has been used for computing the enforced architectural FM of FraSCAti (see below).


To produce the enforced architectural FM, we use the following FAMILIAR code:

extraction procedure (generated)

Visualisation of feature models

150% architectural feature model

The following figure is a visual representation of a so called "150% architectural FM" (you can also download the FM (FeatureIDE or S2T2 format)), using  S2T2.

fmArch150 150% architectural FM: S2T2 screenshot

plugins feature model

The following figure is a visual representation of a so called "plugins FM" (you can also download the FM (FeatureIDE or S2T2 format)), using  S2T2.

fmPlugin: S2T2 screenshot

FMFull, an aggregation of the two FMs with constraints

The following figure is a visual representation of a "FMFull" (you can also download the FM (FeatureIDE or S2T2 format)), using  S2T2.

fmFull: S2T2 screenshot

enforced architectural feature model

The following figure is a visual representation of the enforced architectural FM (you can also download the FM (FeatureIDE or S2T2 format)), using  S2T2.

fmArch enforced architectural FM, only require constraints (S2T2 screenshot)

Properties of the feature models

Impact of the extraction (benefits)


The case study FraSCAti is a typical example in which the problem of feature model evolution occurs and needs to be properly tackled. You can have a look at the presentation made at ECSA'11 conference or BENEVOL'11 workshop:

The challenge for a practitioner (e.g., software architect) is, for example, to understand and validate the evolutions between two versions of FraSCAti w.r.t. variability.

As a result, we used extensively the differencing techniques as well as the FAMILIAR language/environment to support those activities.

Feature Models

  • version 1.3: see above the links
  • version 1.4 (you can download the feature model in FML or FeatureIDE) or
  • version 1.5 (you can download the feature model in FML or FeatureIDE)