Self adaptive software systems

Back Matter Pages About these proceedings Introduction Self-adaptive software evaluates its own behavior and changes its behavior when the evaluation indicates that the software does not accomplish what it is intended to do or when better functionality or better performance is possible. The self-adaptive approach in software engineering builds on well-known features like the use of errors and the handling of exceptions in languages like Lisp or Java and aims at improving the robustness of software systems by gradually adding new features of self-adaption and autonomity.

The revised full papers presented in the volume together with an introductory survey by the volume editors assess the state of the art in this emerging new field and set the scene for future research and development work. Java Lisp Self-adaptive software adaptable software architecture adaptive software adaptive systems distributed systems embedded systems multi-agent systems proving reconfigurable systems self-adaptive control systems software adaption software engineering structured analysis.

Editors and affiliations. Dynamic Object Language Labs. Andover USA 2. Buy options. In order to approach the problem of lacking specification approaches for self-adaptive system, we are currently working on a holistic modeling and analysis approach for adaptive systems.

Our approach, called Adapt Cases, is based on the UML and uses model-checking techniques to assure high quality of created software models. We developed a wide range of prototypical Tools to evaluate our approaches. Please get in contact with us if you are interested in any of the tools. The following tools are available:.

Gregor Engels. Tools We developed a wide range of prototypical Tools to evaluate our approaches. An instance of this case would occur if a new SLA is agreed requiring a maximum of only one second per request, for the four hours before the conference opening.

In either case, the system purpose and corresponding properties are managed explicitly as the control objectives for the adaptive system. Thus, ideally both, the system adaptation reference control input and the reference context input should be automatically derived from these control objectives and fed into the corresponding feedback loops cf.

This automatic derivation ensures the consistency and synchronization between these two sets of reference inputs. In our example, when the time changes from am to am, the control objectives monitor is notified of this event. Then, the control objectives analyzer determines that the control objectives must change according to the agreed SLAs and the control objectives controller plan, and execute the replacement of the in force SLA of 6 seconds per request by the SLA of 3 seconds per request.

This change defines the quality attribute or new control objective e. The new SLA also determines the relevant context information that must be monitored from the environment e. Thus, from this new SLA, the control objectives manager derives the reference control inputs quality attribute: request processing performance; set point: 6; units: seconds and the corresponding reference context inputs sensor infrastructure type: logical; sensor type: time; precision: tenths of second; minimum resolution: one tenth of second; monitoring sampling rate: every 30 seconds.

Finally, the dynamic adaptation of control reference inputs is addressed by closing the control objectives manager as another feedback loop, in which the monitor receives symptoms from the context analyzer control error ; the analyzer, planner and executor conform the control objectives manager; and the target system is represented by the triple: context manager, adaptation mechanism, and core controlled system.

Adaptation Control Feedback Loop The adaptation control feedback loop mission is to serve as a guarantor for the continued fulfillment of the target system purposes and corresponding properties preservation. We refer to purpose and properties as system variables to be controlled. To accomplish this mission, the adaptation control feedback loop follows the separation of concerns criteria described in previous sections.

In turn, these criteria conform to the general principle of control theory, which relies on quantitative expressions to measure the error in the controlled system variables, and a reference control input for each of these variables. The adaptation control feedback loop continually gathers these measurements from the target system through its adaptation monitor.

This monitor notifies control symptoms for adaptation to the adaptation analyzer, which determines the necessity of performing a system adaptation. The simplest case for this occurs when the measured variables under control, compared to their corresponding reference control inputs, indicate that some control objective is not being fulfilled.

Whenever it is relevant, the adaptation analyzer notifies this fact with its corresponding information to the system adaptation controller. With this information, the planner element selects a strategy to adapt the system with the goal of reestablishing the fulfillment of the violated control objective. The result of this strategy is sent as an ordered list of system architecture reconfiguration actions, which are performed in the target system by the executor, thus closing the control loop.

Context Manager Feedback Loop The feedback loop depicted in the bottom part of Figure 5 represents the context manager as part of the monitoring mechanism in our reference model. The reference context input corresponds to the reference context management objectives derived from the system control objectives. These reference inputs form the basis for the generation of context models that represent environmental information useful for supporting the adaptation process.

In our application example, context models represent context information types as well as different levels of granularity, constraints, and relations among context entities, and spatial and scope information that must be managed for guaranteeing the objectives of the ubiquitous conference system e.

This information is preprocessed by the context transducer to generate numeric values from physical and logical sensors, and determine comparable measures by performing basic transformations. Furthermore, the context analyzer performs the context handling process required for the context adaptation controller to decide about adapting the context manager, and for the control objectives manager to decide about changing the system objectives, as demanded by the adaptive system and its environment.

Changes in control objectives can be performed fully or semi-automatically, depending on whether or not it is necessary to re-negotiate and, consequently, for the user to intervene cf. Section 4. The context adaptation controller is in charge of defining and executing the adaptation plan for the context manager, according to its adaptation strategy.

Finally, the measured control output and the adaptive system internal context are used to achieve the context manager goal: to support the system adaptation process and the management of the system control objectives.

Feedback Loop Interactions The decoupling proposed by our model not only supports the separation of the corresponding feedback control loops, but also the separation of the elements within each feedback loop. Even though control loops are designed independently of each other, they must operate together to achieve the overall system objectives.

As depicted in Figure 5, in order to ensure the achievement of the control objectives, our reference model specifies four interactions among its feedback loops, labeled A , B , C and D.

We classify interactions A and B as indirect interactions because they are realized through the control objectives manager, and interactions C and D as direct interactions due to their direct connections between the context manager loop and the adaptation loop. Interaction A provides the reference context input i. Interaction B enables the control objectives manager to decide about changes in the control objectives, whenever the context manager detects that given the current context, the current set of control objectives should be dynamically adjusted or re- negotiated.

Interaction C is realized through context symptoms that are identified and sent from the context monitor to the adaptation analyzer. These context symptoms can 42 www. The communication mechanism and the information associated with these symptoms depend on the supported adaptation type i. Interaction D represents the internal context sensed by the context manager from the adaptive system. Monitoring internal context information is necessary to assess the consistency of the system after an adaptation.

By analyzing internal context information that characterizes the current state of system properties, the context manager must be able to infer symptoms about the achievement of system goals. Applying the Reference Model According to Bass, Clements and Kazman , the process of designing a concrete software architecture for a system should start either from a reference model or from an architectural style, or from both. In either case, the process continues with successive refinement steps, where each step augments the previous with additional information from further analysis of requirements in the problem domain as well as design decisions.

To obtain a concrete self-adaptive software architecture for the conference system of our hypothetical example, we follow this step-wise refinement process, starting from our reference model. An intermediate refinement step is obtained by mapping and incorporating the reference model elements into the conference system components.

Figure 6 illustrates this refinement step by using contracts as system control objectives, and SLAs as reference control inputs. We also assume that in this case the context manager is not required to be self-adaptive. Through further refinement, we obtain a concrete software architecture for our conference management system, the UML deployment diagram depicted in Figure 7.

To illustrate the system behaviour, assume that the system has been configured to accept registration requests just for two days before the conference start day.

Thus, for this conference, the mission of ControlObjectivesManager is to preserve four performance SLAs: i, ii three seconds per request from am to pm and iii, iv six seconds from pm to am on Sep.

ControlObjectivesManager, once notified through its contextSymptoms port of the am beginning-of-conference-registration time-event on Sep. However, both components monitor the target system at different rates.

Figure 6. The reference model elements mapped into the conference management system components. Note that the context manager is not self-adaptive. AdaptMonitor signals corrective adaptation symptoms to the AdaptAnalyzer based on comparisons between the system measurements and reference control inputs, either in a stabilized and normal system state, or immediately after a system adaptation, during the stabilization phase. ContextMonitor provides the AdaptAnalyzer with i predictive adaptation symptoms, based on the recognition of behavioural adaptation; or with ii preventive adaptation symptoms, based on context events gathered by the ContextGathering components.

Whenever AdaptAnalyzer determines that a system adaptation is required, it provides the corresponding context information to the AdaptController component. With this information, AdaptController requests a system architecture reconfiguration plan from the ArchReconfRuleSystem, and then sends the reconfiguration actions to ReflectionInfrastructure for execution.

To achieve better SLA performance over time, one plausible architecture 44 www. Figure 7. Simplified software architecture for the conference management system derived from our reference model. Finally, the ConferenceRegistration component receives registration requests from WebBrowser clients.

The ConferenceRegistration component redirects them to the different ConferenceRegistProcessor components for processing. Related Work This section presents evidence of the application of feedback loops to concrete implementations of adaptive software systems.

However, as concrete implementations, they are not necessarily examples of reference models. On the contrary, these cases evidence the necessity of providing reference models with explicit application guidelines, such as the one we illustrate in this paper. A first example of concrete implementations is the self-healing system developed by Garlan, Cheng and Schmerl Similarly, the separation of concerns and the management of common control objectives are not considered.

A second interesting instance is the context-aware dynamic software product line proposed by Parra, Blanc and Duchien They proposed the introduction of context-aware assets that are dynamically incorporated into the product line, depending on context changes.

Although their architecture alludes to the existence of feedback loop elements i. From the community of autonomic computing we consider the real-time adaptive control approach for autonomic computing environments proposed by Solomon, Ionescu, Litoiu and Mihaescu Their system aims to control the computing infrastructure through a mathematical model of the variation of the number of users per unit time.

Based on this function, the system modifies the control structure of the autonomic computing infrastructure by replacing its controller with one that matches the model of users variation in time. Furthermore, their adaptive control is based on a multi-layer architecture similar to ACRA, where the two upper layers correspond to the autonomic system adaptation and the autonomic system layers respectively, and the lowest layer corresponds to the managed infrastructure. The autonomic system adaptation layer adapts the autonomic system layer whenever the management 46 www.

Even though their approach separates the adaptation and the autonomic management mechanisms into different layers, the concerns are not separated within every layer. For the implementation of self-organizing systems, Caprarescu and Petcu proposed a decentralized autonomic manager composed of many independent lightweight feedback loops implemented as agents, where each agent is an implementation of a MAPE-K loop.

Control objectives in this approach are specified as policies. Moreover, each feedback loop agent uses just one policy that is shared among all the agents organized in the same group. At the architectural level, this approach is based on the three layers proposed by Kramer and Magee The system performs its adaptation based on a process of three phases.

The first one separates agents into groups, by policy i. Feedback loops adapt the system by modifying their parameters, adding new components or reconnecting components. However, although their approach makes the separation of multiple feedback loops explicit, the elements of each loop are highly coupled. Finally, it is worth noting that none of the analyzed approaches address the preservation of context relevance.

In our approach, this critical aspect is achieved by a dynamic self-adaptive infrastructure of monitoring that is explicitly maintained by the context adaptation controller feedback loop. Conclusions and Future Work Control theory, as a discipline matured over the past century, has condensed in its feedback loop reference model and corresponding variations the accumulated knowledge and experience of control engineers designing and building automated controllers for physical systems. The main goal we address in this paper is to illustrate the application of a feedback loop-based reference model to the engineering of self-adaptive software systems.

For this, we used a reference model we previously proposed for designing self-adaptive software systems where feedback loops are explicit components of the software architecture. We illustrated how to apply this reference model to obtain the architecture of an conference management system with ubiquitous characteristics.

Our reference model and its application process require of course additional work to be widely usable. Some of the aspects that, in our opinion, are worth of future work are: i the definition of a domain specific language DSL to enforce the visibility of feedback loops, their elements and properties; ii the derivation of domain-specific reference architectures for self-adaptation that enable software engineers to design domain specific concrete architectures.

These architectures must address different issues such as controlling several control objectives and ways of organizing multiple groups of feedback loops; iii the implementation of a self-adaptive context management infrastructure or the improvement of an existing one to support the dynamic nature of context information, as well as its uncertainty and unsteadiness; iv the operational definition of control objectives as contracts, to support the synchronized cooperation between context management systems and self-adaptation mechanisms; and v the development of a governance infrastructure to manage the feedback loop interactions.

References Abid, Z.