porting the approach presented in this thesis. Following the idea of the FraSCAti imple- mentation [140] of the SCA standard, this reference architecture is itself developed as a component-based application. It thus makes it possible to finely configure (and even to dynamically reconfigure, as discussed in Section 9.2) the adaptation loop according to the need.
6.2.1 The Case of Small Adaptive Systems
In the case of small adaptive systems, where the total number of configurations remains manageable by hand, it is possible to generate and validate all the possible configurations at design-time and define the adaptation logic using simple ECA rules. At runtime, the adaptation loop is thus configured as illustrated in Figure 6.4. In particular the Weaver component simply chooses already woven configuration from a cache and does not per- form weaving at runtime.
ECA
Reasoner
Weaver
variability reasoning variabilityConfig.
Cache
architecture context architectureFigure 6.4: Runtime Architecture for Small Adaptive Systems
This particular configuration of the adaptation loop is rather efficient, since most of the tasks (weaving, validation) are performed at design-time. This is rather similar to what
Bencomo et al. [15, 12, 13, 14, 17] or Zhang et al. [165] propose. However, this kind of con- figuration of the adaptation loop is not adapted to complex adaptive systems that cannot be fully validated at design-time due to the explosion of the number of configurations.
6.2.2 ECA, Goals and Online generation/validation of Configurations to Tame
Complex Adaptive Systems
In the case of complex adaptive systems, such as the ones addressed in the DiVA project, it is not possible to enumerate and validate all the possible configurations of a DAS at design-time. At runtime, the adaptation loop is thus configured as illustrated in Fig- ure 6.5. This loop use an ECA-like reasoner and a goal optimizer in combination. Since all the reasoner components consume and produce variability model, it is possible to chain several reasoners in order to derive the variability model in several steps. Depending on the context, the two reasoners compute a derived variability model that is transformed into an architectural model by the weaver. If a corresponding configuration already ex- ists in cache, then it is directly reused. Otherwise, all the aspect models corresponding to the derived variability model are actually woven. Since all the configurations cannot be validated at design-time, all the woven configuration are checked at runtime. In a configuration is valid, it is submitted to the causal link component, to drive the dynamic reconfiguration. Otherwise, the weaver informs the reasoner that this particular config- uration is invalid, which updates the constraints of the variability model in order not to derive this configuration anymore.
ECA
Reasoner Weaver Checker
variability context reasoning variability architecture architecture Config. Cache architecture Goal Reasoner variability context reasoning
Figure 6.5: Runtime Architecture for Complex Adaptive Systems
This configuration of the adaptation loop combines several reasoning paradigms and is able to weave and validate configurations at runtime. This configuration is thus well- adapted to complex adaptive systems that cannot be designed in extension and that can-
not be fully validated at design-time.
6.3
Discussion
This reference architecture supports the different contributions presented in the previous chapters of this part. It can be used at design-time (for simulation purpose) or at runtime to support the dynamic adaptation process. Indeed, it mainly manipulates design models, even at runtime. This architecture is very modular and it can be configured into different ways depending on the complexity of the DAS it has to manage. This architecture has been employed by different users to realize various case studies, as described in the next chapter.
Chapter 7
Validation: Application to 2 Case
Studies
Contents
7.1 Objectives . . . 119 7.2 Validation on a Crisis Management System . . . 120 7.2.1 Design of the Crisis Management System . . . 120 7.2.2 Some Aspect Models of the Crisis Management System . . . 122 7.2.3 Comparative Study of SmartAdapters V1 and V2 . . . 123 7.3 Validation on EnTiMid . . . 128 7.3.1 Scenario . . . 128 7.3.2 Results . . . 128 7.3.3 Discussion . . . 129
7.1
Objectives
In this Chapter, we apply our approach to two different case studies (in addition to the running example (D-CRM) that was presented in the previous chapter). The first case study is conducted by an industrial partner of the DiVA European project. The second one is currently incubated in the academic world and may be industrialized in a near future. It is important to note that these 2 case studies (+ the D-CRM presented along the previous chapters) are not conducted by people involved in the development of the tools supporting the work described in this thesis. This is an important remark: this means that the tools developed in the context of this thesis (and more largely, the tools developed within the DiVA project) are actually usable by industrial and academic people with no insight of these tools.
We illustrate the design and aspect weaving steps on the first case study, since we only have access to the design artifacts of this case study i.e., we cannot run the system ourself to perform experiments. The model-driven dynamic reconfiguration will thus be validated on the second case study developed within the INRIA Triskell Team.
The objectives of this validation are to evaluate:
• The modeling step (variability, context, reasoning). In particular, we will evaluate if this modeling step is able to tame the explosion of the number of artifacts a designer has to specify to describe and engineer a DAS.
• The weaving of aspect models. In particular, we will evaluate the expressiveness of SmartAdapters (is it able to automatically produce woven models that make sense for a designer), its performances and its scalability (is it able to weave a sequence of aspects in a reasonable time).
• The model-driven dynamic adaptation process. In particular, we will evaluate its performances.