Dynamically Adaptive Systems monitor changes in their operating environment, and re-configure to better suit prevailing conditions. We have previously [1] likened this to the balancing of conflicting softgoals as the environment dictates changes in what constitutes an acceptable balance between them. DASs commonly utilise some form adaptive middleware (for example [2]), which separates the concerns of environmental monitoring, adaptation planning and effecting component substitution from the DAS' business logic. Adaptive middleware codifies system configurations (as combinations of components) and the conditions under which they are adopted in adaptation policies. These can be thought of as re-statements of decisions made after analysis of the environment, and of the available system components during the Requirements Engineering process.
Our existing LoREM process [3] offers an i*-based modelling approach for DASs operating in environments that can be partitioned into distinct domains. An individual steady-state system, termed a target system is derived for each domain, as conceptualised in [4]. From a modelling perspective, each target system is as complex as a traditional, non-adaptive system developed for the domain, with the key artefact to emerge from the modelling process being a selection of components to be adopted in each domain. This paper explores a method by which these selections of components, (modelled in i* SR diagrams) combined with i* models of environmental partitions can be used to derive the policies used by the system's adaptive middleware to control the DAS' adaptive behaviour.
Given our belief that adaptation policies re-state the results of component selection decisions taken during the RE process, and that those decisions are recorded in i* models in LoREM, the research has three aims: 1.To establish a link between the i* based environmental modelling carried out as part of the LoREM process and DAS adaptation policies. 2. To develop an approach by which the adaptation policies can be derived from the i* models and 3. To automate the process.
Understanding the link between the LoREM i* models and a DAS' final adaptation policies is important in pinpointing modelling deficiencies and performing maintenance on the DAS. Given the complex nature of the environments for which a DAS will typically prove most useful, understanding may be incomplete or inaccurate. Being able to trace a sub-optimal or failing target system back to the environmental analysis is crucial to a time and cost efficient evolution process.
The ability to derive adaptation policies directly from LoREM models could reduce the time and effort spent in their development. DASs are hugely complex systems, and any support mitigating some of this complexity is beneficial.
Automating the derivation process not only saves time and helps to reduce the possibility of errors being made during policy derivation, but opens up an interesting possibility: the DAS may be able to perform the derivation itself. A combination of this ability, requirements monitoring and models@runtime [5] could allow a DAS to perform some limited self-maintenance, in the form of correcting modelling deficiencies in response to monitored data, and re-creating its adaptation policies based on the updated model. This possibility is discussed further in section 5.
The LoREM process involves creating i* SR models of each target system, illustrating the degree to which it satisfices the DAS' softgoals in each domain. These models are known as level 1 models. Level 2 models, show how the DAS' adaptive infrastructure monitors the environment, plans and effects adaptation for each valid transition between target systems. Level 3 models aid in the selection of the adaptive infrastructure, but are beyond the scope of this paper.
In [6] we augmented the level 1 i* models with NFR framework [7] claims, which are used to record assumptions about the domain, or the behaviour of the DAS itself. Claims are attached to contribution links, either making or breaking the attached link. A made contribution link (of any i* type) is lent special credence in the decisionmaking process, whereas a broken link's contribution is disregarded. This differs from the use of fine-grained contribution links in that a claim speaks to the importance of a contribution, whereas fine-grained contribution links speak to its magnitude. Claims differ to i* beliefs too, in that a belief is held by an actor to be true, with no presumption of truth by the analyst. Claims allow us to strike different softgoal balances for different target systems, even if softgoal contributions are unchanged.
To allow us to demonstrate our policy derivation method, we present a conceptually simple DAS first presented in [8]. The adaptive image viewer was Deriving Adaptive Behaviour from i* models designed as a pedagogical example, and its sole adaptive capability is to introduce a caching component as the latency encountered in loading files increases beyond a set threshold. The system's operating environment can be easily divided into 2 domains: low (D 1 ) and high (D 2 ) latency. For each domain, a target system is modelled: S 1 and S 2 respectively. Figure 1 shows the level 1 i* models for each target system.
As Fig. 1 shows, the only difference between the two target systems is the means by which the "Load Data" goal is satisfied. With two conflicting softgoals: "Maximise Speed" and "Minimise Memory Usage", the system opts not to waste memory using a cache in the low latency domain, but tries to prioritise speed in the high latency domain. The claims on the models explain the rationale behind the selection decision, despite the contributions of the "[Don't] Use Cache" tasks remaining constant.
By comparing the two level one models in Fig. 1, it is possible to infer the component substitutions involved in transitioning from S 1 to S 2 and vice-versa. The precise component (or class) names associated with each selectable task can be placed in a lookup table when generating policies. Noting which component substitutions are necessary to transition between target systems is the first step in deriving the policies.
Figure 2 shows the level 2 i* model for the S 1 -S 2 transition. A similar model is produced for each valid transition, showing the three roles of a DAS' adaptation infrastructure. The monitoring mechanism observes the environment, providing data to the decision-making mechanism, which identifies when the environment switches from one domain to another and triggers adaptation. The Adaptation mechanism performs the component substitutions needed to adopt the appropriate target system.
To derive adaptation policies, the two key elements of the level 2 model are the transition being triggered, and the trigger itself. The transition is represented by the "Adapt from S 1 to S 2 " task on Fig. 2, and the trigger by the "Fire HIGH_LATENCY event" task. As with the level 1 models, a lookup table can be used to associate a specific class with the "Fire HIGH_LATENCY event" task. Identifying these two elements is the second step in deriving adaptation policies. From Fig. 2, we can see that the S 1 -S 2 transition is triggered by the HIGH_LATENCY event, and by comparing the two level 1 models in Fig. 1, we can see that the only reconfiguration necessary is to swap the "Don't Use Cache" image loader with the "Use Cache" one. Hence, Fig. 3 shows the relevant portion of an adaptation policy compatible with the GridKit adaptive middleware [2].
The rule shown in Fig. 3 is a snippet taken from a full adaptation policy generated by the tool created to automate the process. The tool operates on LoREM level 1 and 2 models created using the Organisation Modelling Environment (OME) i* modelling tool . The tool can be adjusted to produce policies for other adaptive infrastructures, and operates on the OME tool's saved models.
DASs are a notable class of system, representing a first step on the road to fully autonomous systems. The complexity of DASs, and the environments for which they are conceived presents a problem of scale to the software engineering process. The i* based LoREM process offers a way to model and specify DASs where the <ReconfigurationRule> <FrameWork>Cache</FrameWork> <Events><Event><Type>HIGH_LATENCY</Type><Value/></Event></Events> <Reconfiguration> <FileType>Java</FileType><Name>Reconfigurations.Cache</Name> </Reconfiguration> </ReconfigurationRule> environment can be partitioned. This work builds upon LoREM, speeding the development of adaptation policies, aiding DAS implementation and maintenance.
We have demonstrated a link between a DAS' level 1 and 2 i* models and the system's adaptation polices. It is possible to derive the policies automatically, directly from models created with the OME i* modelling tool. Confirming this link not only improves support for policy creation, but allows sub-optimal adaptive behaviour to be traced back to the environmental understanding that led to its specification.
The LoREM process is applicable only to DASs in partitionable environments, which is not always the case. We are considering ways in which other environments may be better supported by similar processes. Within the LoREM process, we are examining ways in which i* models can be used to validate developed DAS behaviour.
Perhaps the most important possibility opened up by this work is (as mentioned in section 2) is that of a DAS deriving its own adaptation policies from models at runtime. For this to be useful, the models would also need to be modifiable. By monitoring system performance and the environment it may be possible to identify modelling deficiencies automatically. In response, the models could be modified by the DAS, which would then re-derive its adaptation policies, thus adjusting its behaviour to fit the new models. Systems performing this kind of adaptation could be described as self-maintaining or self-tuning, and are the subject of ongoing work.