by Carlos Parra, Clément Quinton and Laurence Duchien
The design of a mobile application is a tedious task owing to its intrinsic variability. Software designers must take into account in their development process the versatility of available platforms (eg Android, iPhone, tablets). The variety of existing devices and their divergences (eg frontal camera, GPS) introduce a further layer of complexity to the development process. In addition, at runtime, many potential situations have to be considered (eg limited connectivity, hardware heterogeneity, changes of user preference, etc.). Such software systems are seen increasingly as evolutive systems.
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. Software adaptations open the door for new categories of systems that use all the information available both at design time, to postpone and minimize the impact of developer decisions, and at runtime, to take advantage of the information available in the application environment. 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. Typically, this kind of information is designated as context information. Hence, a context-aware system is aware of changes in the context and is able to adapt to offer better user experiences. A well-known example of such behaviour is when a system changes its behaviour depending on the location. This is especially true in mobile computing.
Figure 1: CAPucine software Product Line process
In this project, we explore the applicability of the Software Product Line (SPL) paradigm to the development of adaptable systems for mobile applications. SPLs aim at managing and building multiple software products from a set of previously developed and tested assets. An asset is understood as any software artifact that can be employed in the development of an application. In SPL engineering, commonalities and variabilities across a set of applications (ie product family) are identified, so that assets can be developed, and used to create different products.
The product derivation defines how assets are selected according to a given feature configuration, and specifies how those assets are composed in order to build the desired product. While the product derivation is commonly perceived as only belonging to the development process of products, this is not always the case and it can be extended to cover the adaptation of an existing product at runtime. In fact, the idea of using SPLs to derive dynamic products has recently started to gain interest from the academic community (see for example, the work of Hallsteinsen et al.). A Dynamic SPL (DSPL) is capable of producing systems that can be adapted at runtime in order to dynamically fit new requirements or resource changes.
Our DSPL, named CAPucine for Context-Aware Service-Oriented Product Line, proposes a unified approach that supports the complete software life cycle: from feature selection and initial product derivation, to runtime adaptation in response to changes of the execution environment. It is a complete approach for designing and implementing DSPL (see Figure). We concretize the notion of asset with a definition of aspect models to leverage the variability across a family of products. Derivation of products is divided into two adaptation processes: design time adaptation and runtime adaptation. The former is in charge of creating the initial product. The latter modifies the product once it has been created and deployed depending on the execution context. Finally our approach unifies design and runtime adaptations by representing both categories of adaptation as aspect models and brings benefits in terms of modularization, platform independence, reusability, and fast development.
As the first contribution, we introduce both: a simple - yet complete - variability model, and an aspect model that realizes variability. With the variability model we aim to define a family of products and identify commonalities and variabilities among them using variants. Additionally, the variability model allows the definition of constraints between those variants. The aspect model, on the other side, is used to construct platform independent representations of variability. Each aspect is self-contained in the sense that it has the three pieces of information required for it to be integrated into any product. It defines the model that represents the subsystem to be added, advice with a set of changes to the core application, and finally, pointcuts that identify the places where the aspect performs the modifications.
As a second contribution, we propose two independent processes for product derivation. Variability and aspect modelling define a complete development process that unifies the expression and manipulation of domain independent concerns at both design time and runtime. Aspect models are used in two different processes called design weaving and runtime weaving respectively. Design weaving aims at building a single product. Runtime weaving aims at adapting a product being executed. Developers can then reuse the same artifacts used for building a software product to adapt it dynamically among various configurations.
For the design weaving, the CAPucine approach is based on a model driven process where transformations and code generation are employed to obtain source code from a set of models. For the runtime weaving, we use FraSCAti, a service-oriented and component-based SCA platform with dynamic reconfiguration properties. A context manager to process events coming from the environment is associated for making decisions about the adaptation.
Link:
ADAM team: http://adam.lille.inria.fr
Please contact:
Laurence Duchien
Inria, LIFL, Université Lille1, France
Adam project-team
Tel: +33 3 59 57 78 65
E-mail:
