A Bottom-Up Approach for Reconstructing Software Architecture Product Lines

Contents

- Abstract

- Implementation: Case of OSGi Component/Service Model

1. Eclipse BUT4Reuse adapter overview

2. Multi-views SAPL construction for Eclipse Software Architecture Variants

3. Graphical visualization of the Recovered SAPL

4. Reverse Engineering of the Eclipse Variants

5. Architecture and Product Derivation

Abstract :

« A large component and service-based software system exists in different forms, as different variants targeting different business needs and users. This kind of systems is provided as a set of "independent" products and not as a "single whole". The presence of a single model describing the architecture of the whole system may be of great interest for developers of future variants. Indeed, this enables them to see the invariant part of the whole, on top of which new functionality can be built, in addition to the different options they can use.

We investigate in this work the use of software product line reverse engineering approaches, and in particular the framework named But4Reuse, for reconstructing an architecture model of a Software Architecture Product Line (SAPL), from a set of variants. We propose a generic process for reconstructing an architecture model of such a product line. We have instantiated this process for the OSGi Java framework and experimented it for building the architecture model of Eclipse IDE SPL. The results of this experimentation showed that this process can effectively reconstruct such an architecture model »

- Implementation: Case of OSGi Component/Service Model

Eclipse-based applications run on top of Equinox which is the reference implementation of the OSGi specification. It is a collection of similar software products that share a set of software assets. It offers a set of "releases" where each one is a large-sized Java application composed of hundreds to thousands of components, registering and consuming hundreds of services. This complex structure requires a considerable effort to understand all dependencies when building a new product. The default Eclipse releases are predefined for targeting specific developer needs.

Currently, if a developer wants to create a customized release, she/he has to select one of the default releases, newt, she/he manually installs new software that meets her/his requirements.

We have implemented an adapter for Eclipse variants. We consider the Eclipse releases as product variants. We aim to reconstruct the SAPL architecture in order to be able to develop efficiently a personalized Eclipse variant.

1. Eclipse BUT4Reuse adapter overview

But4Reuse relies on adapters to support different artifact types. We present here our adapter for Eclipse-SA. First, our adapter uses implicitly another tool for recovering the software architecture of each Eclipse variants. The adapter use the recovered software architectures as input SA variants. The adapter performs mainly the following activities :

- decomposes the variants,

- identify the elements,

- apply a similarity strategy between elements

- identify structural dependencies

- identify blocks and name features

The following Figure shows the results of the adaptation for a set Eclipse variants. The selected variants are the 12 Eclipse IDE Kepler SR2 releases which are downloaded from: https://bit.ly/2uylkT8.

2. Multi-views SAPL construction for Eclipse Software Architecture Variants

In order to construct the OSGi SAPL, the developer can use our tool, which is implemented as separate plug-in (named "org.but4reuse.archmodel.synthesis"). This plug-in provides an extension-point for other developers to contribute by developing extensions for generating for other kinds of component-based software product lines, such as applications built with Java 9+ module system. These developers need only to declare the extension and to implement a predefined interface (named "ISoftwareArchitectureProductLineSynthesis") provided by our plug-in.

The following figure shows how to perform the action of creating SAPL

Several techniques have been proposed in the literature which aim to synthesize the feature model. We have reused the techniques that are integrated in the But4Reuse. In the first technique, we the SAPL has a flat organization (all the features have the same level). The second technique is "the alternative before hierarchy model". It is based on calculating first the alternative constructions from the identified mutual exclusion constraints between features, and then create a hierarchy using the requires constraints (in the previous figure the two SAPL are created). The developer can select one or several techniques from preference page.

3. Graphical visualization of the Recovered SAPL

Our plug-in provides an editor that allows to visualize graphically the SAPL. First, the SAPL can be visualized as a compact representation of all the assets of the SAPL in terms of "features". The following figure depicts the reconstructed SAPL using the alternative before hierarchy technique.

Second, we enable the developer to click twice on a given feature in order to visualize its architecture, which can be opened in another editor. In this way, instead of visualizing the whole SAPL in one screen, we assist the developer to understand features progressively.

The following figure shows an excerpt of the architecture of the feature "eclipse birt". As we can see, the component "BIRT Emitter Conf. Plug-in" provides an extension-point which is extended by several plugins.

4. Reverse Engineering of the Eclipse Variants

In our approach, we assume that the Software Architecture of the product variants can already exist and considered as inputs for our SAPL-RE process. Hence, our plug-in can perform the software architecture recovering for each Eclipse variant as standalone function (not during the adaptation). We can see this in the following figure.

In the current implementation, the software architecture of each Eclipse variant is recovered using a algorithm where the output architecture is presented as a flat organization. Our plug-in provides an extension-point for other developers to contribute by developing extensions for recovering the software architecture variants using personalized algorithm such as FCA, WCA, etc. These developers need only to declare the extension and to implement a predefined interface (named "ISoftwareArchitectureVariantRecovery") provided by our plug-in. The following figure shows the preference page for selecting the SAR algorithm.

5. Architecture and Product Derivation

In order to derive a new Eclipse variant using our approach, the developer can use first the FeatureIDE tool for configuring manually the SAPL and select a set of desired features among the identified list. Before deriving the variant, we offer to the developer a way for mapping this configuration into an architecture model for this variant. This architecture model represents the structure of selected features and their relationships without variability information, which is useful for the understanding purpose. At the end, the new variant can be derived by collecting the extracted software assets which correspond to the selected features. We suggest to the developer to follow this steps:

· Generate the feature model using the existing function in But4Reuse.

· Create a new FeatureIDE project and copy the generated feature model in this project.

· Configure a new variant in which we select the desired features.

· Use our tool to derive new software architecture that corresponding to the configured variant. As we can see in the following figure, we show how to perform this action.