At the code level, Aspect-Oriented Programming (AOP) [84, 83, 7], and related program- ming paradigms such as Feature-Oriented Programming (FOP) [127] or Mixins [142], pro- vide flexible ways to implement Software Product Lines [80, 5, 6, 48, 97]. The idea is to encapsulate each feature into a well-defined composition unit [151] (aspect, feature, mixin layer) that can easily extend an existing program. All these paradigms proposes different but complementary composition mechanisms in order to extend/refine Object-Oriented
programs.
Recently, Aspect-Oriented Modeling (AOM) has been applied in the context of Model- Driven Software Product Lines [88, 77, 64, 102, 100, 120]. In the context of the DiVA project, we pioneered the use of AOM in order to manage the dynamic variability of complex adaptive systems [105, 106, 104], or Dynamic Software Product Lines. AOM approaches tend to unify the composition concepts of AOP, FOP, Mixins, etc of the programming level in order to propose advanced composition mechanisms at design-time, based on model composition and model transformation. We can distinguish two main types of AOM approaches:
• Merge-based approaches, such as Kompose [49, 55, 56] or the Composition Direc- tives [130], which propose systematic ways to merge models. Elements with the name signature, previously defined by the designer (in the case a default name matching is not sufficient), are merged into a single one, while elements that do not match are introduced into the resulting model. In the case where the two in- put models are not aligned, it is possible to apply directives (mainly renaming) to modify some elements and force the match. The superimposition operator used by Cetina et al. [30, 31, 32] can be seen as a simple merge operator. While the merge- based approaches are well adapted to weave non cross-cutting features, it seems very difficult (even impossible) to weave cross-cutting features that impact several places.
• Pointcut-based approaches, such as MATA [160, 77], SmartAdapters [88, 101] or GeKo [102], which allow to weave the same aspect in several places (join points) of the same base model. The aspect is totally defined according to the pointcut. At weaving time, a first pass will determine all the join points. Next, the aspect is con- textualized for all the identified join points, and actually woven into the base model. Pointcut-based approaches are supposed to fill the lack of quantification of merge- based approach, so that they can weave cross-cutting aspects. However, it appears that these approaches do not offer the right mechanisms to properly weave aspects, as we further discuss in Chapter 4.
2.5
Conclusion
Figure 2.4 illustrates a map of the approaches we have presented in this state-of-the-art. These approaches are positioned according to their abilities with respect to validation and variability management. One of the ultimate goals of the development of adaptive system would be to achieve a degree of validation close to the extensive model-based approaches, with variability management capabilities close to the DSPL approaches and aspect-oriented approaches.
Validation Variability Management Extensive Model- Based approaches Adaptive Execution Platforms Models@runtime approaches DSPL approach Separation of Concerns and Aspect-Oriented Approaches Multi-staged approaches
Figure 2.4: A Map of the presented approaches
In this thesis, we combine Model-Driven Engineering and Aspect-Oriented Modeling techniques to go one step further towards this goal.
Approach Variability Management Validation Trigger SAFRAN, Rainbow, MADAM & MUSIC Dynamic variability clearly encapsulated into adaptation rules. No need to explicitly specify all the possible config- urations. The template architecture in MADAM/- MUSIC rather restrict the possibility of adaptation.
No mechanisms to manage possible in- teractions between adaptation rules. Either ECA or goals (utility functions). Georgantas et al. Distributed reasoning on the set of available ser- vices.
Recovery mecha- nism if the reconfig- uration encouters a problem. apparition- /disappearing of services in the environment. AspectJ-like aspects for CBSE
Aspects clearly encapsu- late (cross-cutting) vari- ability units.
FAC and AOpen- COM are direclty based on Fractal and
OpenCOM, with no explicit model allowing validation before adaptation. Possible to use an existing rea- soning paradigm to trigger aspect weaving/un- weaving. Aspect of As- sembly Reconfiguration clearly encapsulated into aspects of assembly. Limited ex- pressivity of the pointcut and advice languages.
An explicit architec- tural model is built before the actual adaptation, making it possible to detect and resolve errors.
ECA
Part II
Chapter 3
Models Manipulated and Exchanged
Contents
3.1 Introduction . . . . 65 3.2 Overview . . . . 66 3.3 Variability Metamodel . . . . 67 3.4 Environment and Context Metamodel . . . . 69 3.5 Reasoning Metamodel . . . . 71 3.5.1 ECA-like rules . . . 71 3.5.2 Goals . . . 72 3.6 Architecture Metamodel . . . . 74
3.1
Introduction
This part details the contributions of this thesis, briefly introduced in the Introduction chapter. The key objective of the approach is to reduce the number of artifacts a designer has to specify to describe and execute an adaptive system, and to raise the level of abstrac- tion of these artifacts. It is important to note that this thesis is not about self-adaptation mechanisms themselves. Instead, we propose to rely on the well established component composition as the underlying technique for dynamic adaptation.
We use a dynamic customer relationship management system (D-CRM) as a running example in this part. This system is inspired by one of the case studies of the DiVA Euro- pean project, provided by CAS AG. The objective of the D-CRM is to provided accurate client-related information depending on the context. For example, when the user is work- ing in his office, he can be notified by e-mail, via a rich web-based client. He can also access critical resources since he is connected to a trusted network. When he is driving his car to visit a client, he should be notified by a mobile or smart phone, and only with
information which is either critical or related to the client. If he is using a mobile phone, he can be notified via SMS or audio/voice, and phone calls are forwarded from his office. If he is using a smart-phone, he can additionally use a light-weight web client.