INES – National Institute of Science and Technology for Software Engineering

INES at SBSI’2012

The paper “A Traceability Tool for Mapping Features and Core Assets in Software Product Lines ” – in portuguese,   Uma ferramenta para rastreabilidade de core assets em linha de produtos de software, was accepted for publication at SBSI – Brazilian Symposium on Information Systems.

This activity is part of the MSc work presented by Anderson Fonseca e Silva, mentored by Vinicius Cardoso Garcia at CESAR.EDU and is part of the project “S.Ma.R.T – Social Machines Research Team”

More details about the publication: SILVA, A. F. ; Garcia, Vinicius Cardoso . Uma ferramenta para rastreabilidade de core assets em linha de produtos de software. In: Simpósio Brasileiro de Sistemas de Informação, 2012, São Paulo. Trilha Especial – Aplicativos de SI – Ferramentas (Special Track – Applications of IS – Tools) – Full papers, 2012.

Dependable Evolution of Software Product Lines

An important competitive differential for software factories is the ability to launch similar products customized to the clients, in a fast and cost-reduced way, without compromising quality. This has been possible through software product line engineering. A software product line (PL) is a set of related software products that are generated from reusable assets. Products are related in the sense that they share common functionality. Assets correspond to components, classes, property files, and other artifacts that we compose or instantiate in different ways to specify or build the different products. This kind of reuse targeted at a specific set of products can bring significant productivity and time to market improvements.

To obtain the benefits associated to the PL approach with reduced upfront investment, we can minimize the initial PL analysis and development process by bootstrapping existing related products into a PL. Through an extraction process, we separate variations from common parts and then discard duplicated common parts. A similar process applies to PL evolution, when, for instance, adding a new product requires extracting variations from parts previously shared by a number of products.

Although useful to reduce initial investments and risks, this extraction and evolution process can be costly and tiresome. Manually extracting and modifying different code fragments, besides other kinds of assets, requires substantial effort, especially for checking necessary conditions to ensure that the evolution can be performed in a safe way. Nonetheless, it can also introduce defects, compromising the PL benefits in other cost and risk dimensions.

We believe that the PL extraction and evolution process can benefit from semi-automatic refactorings, with formal basis, to ensure correctness and avoid running tests after the refactoring. Applying semi-automatic refactorings, guided by the developer, has the advantage of guaranteeing refactoring by construction. However, it imposes restrictions over the involved assets, such as the use of reflection, and demands from the developer the knowledge of the available transformations and the ability to identify which ones are better suited for a given situation. When the developer does not have such knowledge and ability, it is important to count with an alternative: verifying, ‘a posteriori’, that modifications to a PL really consist of a refactoring can be automatically performed in various situations, and approximated in the remaining ones.

However, existing refactoring notions focus on justifying the transformation of a single program into another, they do not consider transforming a PL into another, or a set of a programs into a PL. In fact, a PL can have conflicting artifacts, such as two classes with the main method, or two versions of the same configuration file, which makes the assets from a PL an invalid program. This prevents such assets set to benefit from existing refactoring notions. Beyond such program refactoring limitations – without mentioning requirements, tests and design models – in a PL, we tipically need extra elements to automatically generate products: Feature Models (FMs) and Configuration Knowledge (CK).

For these reasons, this project intends to propose, formalize, implement, and evaluate refactorings and refactoring checkers for PLs. In particular, we will define and implement refactoring catalogues, based on a behavior-preserving refinement notion. We will have catalogues that modify the PL as a whole, as well as individually modifying FMs and CK. Separate modifications to FM and CK are important to support compositional PL evolution. Besides that, we will reuse existing program and model refactoring catalogues for different languages. Similarly, we will have checkers for specific situations, such as when we modify only a single PL element (FM, CK, or assets), and checkers for changes that affect the PL as a whole.