Section: New Results
Software composition
Participants : Nicolas Anquetil, Hugo Arboleda, Rémi Douence, Fabricio Fernandes, Jean-Claude Royer.
Our results on software composition have focused on four main activities: management of multiple representation for programs, fine-grained configuration and traceability for software product lines, and providing support for extraction of components from legacy code. Some of these results strongly link ASCOLA's work on CBSE with that on AOP by expressing aspectual representations and aspectual MDE transformations. One of the main domain of investigations was software product line engineering where we have shown the benefits of component and aspect abstractions, in particular, to enable a precise management of the flow of information to properly reuse artifacts.
Compositional transformation of data structure representations
Achieving separation of concerns has been a core objective of software engineering for decades. In general, software can be decomposed properly only according to a single concern, other concerns crosscut the prevailing one. This problem is well known as the tyranny of the dominant decomposition. Similarly, at the programming level, the choice of a representation for a data structure frequently drives the implementation of algorithms. We have explored an alternative that forgoes the need for a dominant representation [22] . Instead, each algorithm is developed in its “natural” representation and a representation is converted into another one only if necessary. To support this approach, we designed a framework for Java, that performs partial conversions and dynamic optimizations using lazy evaluation, and that preserves soundness of executions. Through performance evaluations over graph theoretic examples we have demonstrated that this approach provides a practicable but more efficient alternative to naive, manual representation modifications.
Fine-grained Configurations for Software Product Lines
As part of his PhD thesis [11] , Hugo Arboleda has presented an approach based on Model-Driven Development to create Software Product Lines (SPLs). In Model-Driven SPL approaches, the derivation of a product starts from a domain application model. This model is transformed through several stages reusing model transformation rules until a product is obtained. Transformations rules are selected according to variants included in configurations created by product designers. Configurations include variants from variation points, which are relevant characteristics representing the variability of a product line. As we have shown, there are at least two drawbacks in many of these approaches [20] . First, the selection of variants affects the whole domain application model, impeding fine-grained configurations, i.e. configurations at the level of individual elements in the model. Second, model transformations are coupled with variants which make their maintenance and adaptation difficult. Like in the Triskell team, our aim is to conciliate both flexibility and automation for product derivation. We define an approach that uses metamodeling and feature modeling. Our approach (1) provides mechanisms to improve the expression of variability of Model-Driven SPLs by allowing designers to create fine-grained configurations of products, and (2) integrates a product derivation process which uses decision models and Aspect-Oriented Programming facilitating the reuse, adaptation and composition of model transformation rules. We have defined a decision model as a set of aspects [21] . An aspect maintains information of what and when transformations rules that generate commonalities of products must be intercepted (joinpoints) and what transformation rules (advices) that generate variable structures must be executed instead. Our strategy maintains uncoupled variants from model transformation rules. This solves problems related to modularization, coupling, flexibility and maintainability of transformations rules because they are completely separated from variants; thus, they can evolve independently.
Traceability for Software Product Lines
Another problem in SPL engineering that we have addressed is the management of traceability. As part of the European AMPLE project we have created a common traceability framework across the various activities of the SPL development. We have identified four orthogonal traceability dimensions in SPL development, one of which is an extension of what is often considered as “traceability of variability” [16] . Furthermore, we have specified a metamodel for a repository of traceability links in the context of SPLs and the implementation of a corresponding traceability framework. This framework permits to perform fundamental traceability management operations, such as trace import and export, modification, query and visualization.
Extracting Components from Java Source Code
Architectural erosion is the process by which a system's architecture gradually degrades as maintainers make changes to the system that violates the original architectural intents. To address this problem, new languages and development methods are currently under investigation that make explicit some architectural decisions in the source code (for the benefit of the programmers) and allow automatic verification and enforcement of these decisions, either at compile or execution time. We have explored the possibilities of automatic reverse-engineering of such legacy applications in order to define a more formal model by extracting the component types they contain and to make explicit the communication channels between them [19] . This work provides an overview of the main rules and the associated tool support we have developed. Furthermore, we have defined several heuristics for the corresponding reverse-engineering task which are mainly based on communication integrity properties. If a type of interest is passed as parameter of a method or returned by a method it is classified as a data type, otherwise as a component type. The data type classification is then propagated through subtyping and also by composition. This tool is intended to help its user compare (and map) a concrete implementation with an abstract model.
