Software Product Lines

This page presents the activities of the ADAM Project-team in the domain of Software Product Lines (SPLs).

One of the concerns of the ADAM team is to build modular software systems that can be easily adapted at design and runtime. From this modularity the team also searches to promote the reuse of different parts of system in order to build new ones. Regarding this concern, the team has worked in two main contributions:

1. CAPucine: Unifying Design and Runtime Adaptations
2. AppliDE: Modeling and Generation of Applications for Smartphones

Introduction: Software Product Lines

Forty years after the first conference on Software Engineering [1] and almost twenty years after the IEEE Computer Society has standardized this discipline, Software Engineering is still struggling to produce large software systems [2, 3]. This is related to the fact that requirements keep on changing even after software has been built and deployed. To tackle such a challenge, a cornerstone element that is intrinsic to any modern software is the notion of adaptation. If a system is designed and implemented to be adapted, then it is more likely that it can better support changes in its requirements, architecture, and even implementation. However, adaptations are difficult to define since they may take place at early stages of the development process, but also at runtime where there are many situations that have to be considered (e.g., limited connectivity, hardware heterogeneity, changes of user preferences, etc.). Thus, two issues remain open: (1) the production of software systems in a cost-efficient way, and (2) the adaptation of such systems to changing requirements.

In order to deal with the first issue, the SPL paradigm proposes the management and build of multiple software products from a set of previously developed and tested assets. In SPL engineering, commonalities and variabilities across a set of applications (i.e., product family) are identified, so that assets can be developed, and used to create new different products. However, traditional SPLs do not consider the adaption of derived products along their entire life cycle.

To face the second issue, in recent years the academic community has extended the SPLs paradigm to enable the derivation of dynamic products. In [4] authors introduce SPLs for derivation of software that needs to be adapted at runtime; they refer to this kind of SPLs as dynamic. A Dynamic SPL (DSPL) is capable of producing systems that can be adapted at runtime in order to dynamically fit new requirements or resources changes.

References

[1] NATO software engineering conference, 1968.

[2] Frederick P. Brooks Jr. The mythical man-month: After 20 years. IEEE Software, 12(5):57–60, 1995.

[3] Steven Fraser, Frederick P. Brooks Jr., Martin Fowler, Ricardo Lopez, Aki Namioka, Linda M. Northrop, David Lorge Parnas, and Dave A. Thomas. "no silver bullet" reloaded: retrospective on "essence and accidents of software engineering". In ACM SIGPLAN OOPSLA’07 Companion, pages 1026–1030, 2007.

[4] Svein Hallsteinsen, Mike Hinchey, Sooyong Park, and Klaus Schmid. Dynamic Software Product Lines. Computer, 41(4):93–95, 2008.

CAPucine: Unifying Design and Runtime Adaptations

CAPucine defines a framework for DSPLs that enables adaptations at design and runtime based on MDE [1] and AOM [2, 3]. Figure 1 presents a global view of CAPucine. It is divided in two parts. In the top of the figure the elements for the domain engineering process are depicted. The assets are models and metamodels related to three different domains:

• Variability for feature modeling: CAPucine introduces a feature metamodel that defines the main concepts for features and relationships in order to express the variabilities and commonalities of a product family.

• Application for core and aspect modeling: An application is modeled as a combination of a core and a set of aspects. The core is modeled using a metamodel that includes the essential elements of a component and service based application. The aspects are intended to enrich or modify the elements of the core by adding or deleting news elements at specific points in the core structure. The core as well as the aspects use an architecture based on a components that offer services and require references.

• Platform for SCA and Java modeling: CAPucine uses Service-Component Architecture (SCA) [4] as a target platform. SCA proposes a reconciliation between the Service Oriented Architecture (SOA) and CBSE, by defining a framework for describing the composition and the implementation of services using software components. In order to generate the code for the SCA runtime platform, two metamodels are used: one for SCA and one for Java. The architecture of the product is defined using an SCA model, which references implementations for every component described. Such implementations are written in Java.

Figure 1. A global view of CAPucine

The bottom of Figure 1 depicts the application engineering process. Here two types of product derivation are defined: one for adaptations at design time, and one for adaptations at runtime. The former one is in charge of building a product, whereas the latter one is intended to modify an existing running product.

In the design phase a product is built from a manual Product Configuration. First, a constraint Analysis step is performed, which verifies constraints at the level of features and the assets that realize them. Out of this analysis, an order of composition is obtained. Next, the composition, called design weaving, puts together the common elements of all products with the features selected for the particular product being built. Once the whole composed model reflecting the choice is built, the generation takes place. At the end of the design, the code for the product is generated.

On the other hand, the runtime phase aims at modifying an application at execution. One advantage of using SPLs is that assets used for both phases are the same. Hence, by starting from the same set of models created and used in the design phase, the runtime phase generates the adequate software artifacts that change the product dynamically in a process called Runtime Weaving. To achieve this, in this phase the adaptation cycle includes a process of decision making, an executing platform for performing dynamic modifications, and the use of context information to trigger the process of adaptation.

Publications

1. Using Constraint-based Optimization and Variability to Support Continuous Self-Adaptation. C. Parra, D. Romero, S. Mosser, R. Rouvoy, L. Duchien and L. Seinturier. In 27th Symposium On Applied Computing (SAC 2012). Riva del Garda, Italy, March 2012.
2. Unifying Design and Runtime Software Adaptation Using Aspect Models. C. Parra, X. Blanc, A. Cleve, and L. Duchien. In Science of Computer Programming(SCP). Special edition on software evolution. 2011.
3. Feature-based Composition of Software Architectures. C. Parra, A. Cleve, X. Blanc, and L. Duchien. In 4th European Conference on Software Architecture (ECSA 2010). Copenhagen, Denmark, August 2010.
4. Context Awareness for Dynamic Service- Oriented Product Lines. C. Parra, X. Blanc and L. Duchien. In 13th International Software Product Line Conference (SPLC’09). San Francisco, USA, August 2009.
5. Dynamic Software Product Lines for Context-Aware Web Services. C. Parra, R. Leaño, X. Blanc, L. Duchien, N. Pessemier, C. Taconet and Z. Kazi-Aoul. In Enabling Context-Aware Web Services: Methods, Architectures, and Technologies. Chapman and Hall/CRC, 2010.

PhD Theses

1. Towards Dynamic Software Product Lines: Unifying Design and Runtime Adaptations. Carlos Parra. University Lille 1. March 2011.
2. Context as a Resource: A Service-Oriented Approach for Context-Awareness. Daniel Romero. PhD Thesis. University Lille 1. July 2011.

References

[1] Douglas C. Schmidt. Model-driven engineering. IEEE Computer, 39(2), February 2006.

[2] Aspect-oriented modelling wokshops series. http://www.aspect-modeling.org/.

[3] Robert France and Jean-Marc Jézéquel. Editorial for the special issue on aspects and model-driven engineering. Transactions on Aspect-Oriented Software Development, 2009.

[4] Open SOA. Service component architecture specifications, November 2007. http://www.oasis-opencsa.org/.

AppliDE: Modeling and Generation of Applications for Smartphones

AppliDE proposes a Model Driven SPL (MD-SPL) for the derivation of mobile applications for different platforms from a same application model. In order to enable the generation to different target platforms, AppliDE defines a platform independent metamodel as well as customized code generators for each platform. The metamodel includes concepts to define (1) the functionalities offered by the application (e.g., mail and SMS sending, and GPS activation), (2) the required data sources (e.g., files, Web Services or databases) and (3) the graphical elements (e.g. view, buttons, labels and text fields). Then, the code source of the target platform is obtained by executing the code generators from AppliDE. In this way, developers can model mobile applications independently of the target platform.

For the time being, AppliDE supports Android and iOS as target platforms. However, thanks to the usage of MDE principles, the MD-SPL of AppliDE can be easily extended to include additional code generators for others platforms.

Publications

1. Using Multiple Feature Models to Design Applications for Mobile Phones. C. Quinton, S. Mosser, C. Parra and L. Duchien. In Joint workshop of the 3rd International Workshop on Model-driven Approaches in Software Product Line Engineering and 3rd Workshop on Scalable Modeling Technique (MAPLE/SCALE'11) colocated with SPLC'11. Munich, Germany, August 2011.

Presentations

1. Presentation of the MAPLE/SCALE'11 workshop

Tool Demonstration

The following video shows the usage of a tool provided by CAPucine, which illustrates the main concepts of the framework related to the design and runtime adaptations. The demonstration uses MobiHome, an application enabling the control of home appliances such as heating, drapes and lights. The CAPucine tool also integrates AppliDE, in order to enable the generation and adaptation not only of SCA applications but also of mobile applications.

CAPucine Demo