Software Engineering for Self-Adaptive Systems: A Research Roadmap
Summary (6 min read)
1. INTRODUCTION
- The simultaneous explosion of information, the integration of technology, and the continuous evolution from softwareintensive systems to ultra-large-scale (ULS) systems requires new and innovative approaches for building, running and managing software systems [18] .
- A consequence of this continuous evolution is that software systems must become more versatile, flexible, resilient, dependable, robust, energy-efficient, recoverable, customizable, configurable, or self-optimizing by adapting to changing operational contexts and environments.
- The proper realization of the self-adaptation functionality still remains a significant intellectual challenge, and only recently have the first attempts in building self-adaptive systems emerged within specific application domains.
- The global behaviour of the system emerges from these local interactions.
- Each of these views are roughly presented in terms of the state of the art and the challenges ahead.
2. REQUIREMENTS
- As such, a selfadaptive system must continuously monitor changes in its context and react accordingly.
- But noncritical goals could well be relaxed, thus allowing the system a degree of flexibility during or after adaptation.
- Requirements engineering for self-adaptive systems, therefore, must address what adaptations are possible and what constrains how those adaptations are carried out.
2.1 State of the Art
- Requirements engineering for self-adaptive systems appears to be a wide open research area with only a limited number of approaches yet considered.
- The authors therefore propose that richer requirements languages are needed.
- For self-adaptive systems, the prescriptive notion of "shall" needs to be relaxed and could, for example, be replaced with "the system may do this or it may do that" or "if the system cannot do this, then it should eventually do that.".
- This idea leads to a new requirements vocabulary for self-adaptive systems that gives stakeholders the flexibility to account for uncertainty in their requirements documents.
Traceability from requirements to implementation.
- A constant challenge in all the topics shown above is "dynamic" traceability.
- New operators of a new RE specification language should be easily traceable down to architecture, design, and beyond.
- Doing so is different from the traditional requirements traceability.
2.3 Final Remarks
- The authors have presented several important research challenges that the requirements engineering community will face as the demand for self-adaptive systems continues to grow.
- These challenges span RE activities during the development phases and runtime.
- In order to gain assurance about adaptive behaviour, it is important to monitor adherence and traceability to the requirements during runtime.
- Given the increasing complexity of applications requiring runtime adaptation, the software artifacts with which the developers manipulate and analyze must be more abstract than source code.
3. MODELLING
- Endowing a system with a self-adaptive property can take many different shapes.
- Understanding the problem and selecting a suitable solution requires precise models for representing important aspects of the self-adaptive system, its users, and its environment.
- For the identification of the system modelling dimensions, two perspectives were considered: the abstraction levels associated with the system, and the activities associated with the adaptation.
- The first perspective refers to the requirements (e.g., goals), the design (e.g., architecture), and the code of the software system, and the second refers to the key activities of the feedback control loop, i.e., collect, analyse, decide, and act.
- The other two groups are related to non-functional properties, i.e., timing and dependability, that are particularly relevant to some classes of self-adaptive systems.
3.1 Illustrative Case
- A concrete application could be the DARPA Grand Challenge contest [44] .
- The ACS takes into account the regular traffic environment, including the traffic infrastructure and other vehicles.
- The scenario the authors envision is the one in which there is a UV driving on the road through a region where people and animals can cross the road unexpectedly.
- To anticipate possible collisions, the ACS is extended with a self-adaptable control system (SCS).
- In case an obstacle is detected, the SCS manoeuvres the UV around the obstacle negotiating other obstacles and vehicles.
3.2 Overview of Modelling Dimensions
- The authors give overview of the important modelling dimensions per group.
- Each dimension is illustrated with an example from the illustrative case.
Adaptation
- The first group describes the modelling dimensions related to adaptation.
- The domain of type of adaptability ranges from parametric to compositional.
- It is imperative for the software engineering community to develop better models that incorporate the AI techniques in solving the practical problems of automatic adaptive systems.
- Thereby, if applied to a large-scale software system, almost all current techniques suffer from scalability problems.
- Principled approaches for efficient gathering of information at run-time are needed.
Degree of automation. The automation dimension refers
- To the degree of human intervention required for self-adaptation.
- In a process-oriented approach, the system is characterised as sensed, by providing the means for producing or generating objects having the desired characteristics.
- In the illustrative case, self-adaptation is realized by the SCS that is part of the application logic.
- This modelling dimension refers to the impact that adaptation might have upon the system.
- In the illustrative example, the SCS monitors the environment and decides at run-time when it has to take control over the ACS to avoid collisions.
Timing
- The second group describes modelling dimensions related to timing issues.
- In the illustrative example, the SCS must guarantee that the UV reacts effectively to avoid collisions with possibly a human being.
- The domain ranges from predictable to degradable.
- In time-critical cases, the self-adaptable system often needs to act in a highly predictable manner.
- Monitoring a system, especially when there are several different QoS properties of interest, has an overhead.
Dependability
- The third and final group the authors consider describes modelling dimensions related to dependability, that is, the ability of a system to deliver a service that can justifiably be trusted [1] .
- The domain of each of these properties ranges from high to low.
- The domain of maintainability ranges from autonomous to humanbased.
- Since the illustrative example is related to an embedded real-time system, the data integrity will be short-term.
3.3 Challenges Ahead
- In spite of the many years of software engineering research, construction of self-adaptive software systems has remained a very challenging task.
- The discussion is structured in line with the three presented groups of modelling dimensions.
4. ENGINEERING
- Building self-adaptive software systems cost-effectively and in a predictable manner is a major engineering challenge even though adaptive systems have a long history with huge successes in many different branches of engineering [49, 16] .
- Mining the rich experiences in these fields, borrowing theories from control engineering, and then applying the findings to software-intensive adaptive systems is a most worthwhile and promising avenue of research.
- Lehman's work on software evolution [30] has shown that "[t]he software process constitutes a multilevel, multiloop feedback system and must be treated as such if major progress in its planning, control, and improvement is to be achieved.".
- Therefore, any attempt to automate parts of these processes such as self-adaptive systems necessarily also has to consider feedback loops.
- Therefore, the authors advocate to focus on the feedback loop-a concept that is elevated to a first-class entity in control engineering-when engineering self-adaptive software systems.
4.1 State of the Art & Feedback Loops
- Self-adaptation in software-intensive systems comes in many different guises.
- The reasoning typically involves feedback processes with four key activities: collect, analyze, decide, and act as depicted in Figure 1 [14] .
- Keeping web services up and running for a long time requires collecting of information that reflects the current state of the system, analyzing of that information to diagnose performance problems or to detect failures, deciding how to resolve the problem (e.g., via dynamic load-balancing or healing), and acting to effect the made decision.
- The authors have observed that feedback loops are often hidden, abstracted, or internalized when presenting the architecture of self-adaptive systems [36] .
- Therefore, besides making the control loops explicit, the control loops' properties have to be made explicit as well.
Generic Control Loop Model
- The generic model of a control loop presented in Figure 1 provides a good overview of the main activities around the feedback loop, but ignores many properties of the control and data flow around the loop.
- Next, the system analyzes the collected data.
- Some of the applicable questions here are:.
- The above questions -and many others -regarding the control loop should be explicitly identified, recorded, and resolved during the development of the self-adaptive system.
Control Theory
- The control loop is a central element of control theory, which provides well-established mathematical models, tools, and techniques to analyze system performance, stability, sensitivity, or correctness [6, 15] .
- Researchers have applied results of control theory and engineering when building selfadaptive systems.
- Good engineering practice calls for reducing multiple control loops to a single one, or making control loops independent of each other [37] .
- If this is not possible, the design must make the interactions of control loops explicit and expose how these interactions are handled.
- Mining the experiences in these fields and applying them to software-intensive adaptive systems is a most worthwhile next step.
Specific Control Loop Models
- Another key observation that the authors made is that different application areas introduce different nomenclature and architectural diagrams for their realization of the generic feedback loop depicted in Figure 1 .
- Control engineering leverages the Model Reference Adaptive Control (MRAC) solution to describe many kinds of feedback-based systems (e.g., flight control) [16] .
- Further, the systems are often decentralized in such a way that the agents do not have a sense of the global goal but rather it is the interaction of their local behavior that yields the global goal as an emergent property.
- An example of a self-organizing biologically inspired software system is a distributed computational system built using the tile architectural style from [3] .
- In an attempt to unify the self-adaptive (top-down) and self-organising (bottom-up) views, [12] propose a software architecture based on the use of metadata and policies where adaptation properties and feedback loop reasoning are considered explicitly both at design-time and run-time.
4.2 Challenges Ahead
- The authors have argued that the control loop should be a firstclass entity when thinking about the engineering of selfadaptive systems.
- The authors believe that understanding and reasoning about the control loop is key for advancing the construction of self-adaptive systems from an ad-hoc, trial-anderror endeavor towards a more disciplined approach.
- For such systems the control loop seems implicitly present.
- Examples of such properties are system state that is used to reason about the system's behavior, and policies and business goals that govern and constrain how the system will and can adapt.
- Furthermore, users might want feedback from the system about the information collected by sensors and how this information is used to adapt the system.
5. ASSURANCES
- Developers need to provide evidence that the set of stated functional and nonfunctional properties are satisfied during system's operation.
- Tra-ditional verification and validation methods, static or dynamic, rely of stable descriptions of software models and properties.
- Current verification and validation methods do not align well with changing goals and requirements as well as variable software functionality.
- Novel verification and validation (V&V) methods are required to provide assurance in self-adaptive systems.
- Thereafter, the authors present a set of research challenges for V&V methods implied by the presented framework.
5.1 Framework
- Over a period of operation, the system operates through a series of operational modes.
- Sequences of behavioral adjustments in the known modes are known.
- Goals and requirements of a self-adaptive system may also change during run-time.
- Properties can also be related to each other.
5.2 Challenges
- Self-adapting systems have to contend with dynamic changes in modes and contexts as well as the dynamic changes in user requirements.
- When formal property proofs do not seem feasible, run-time assurance techniques may rely on demonstrable properties of adaptation, like convergence and stability.
- Software vendors may have a difficult time to argue that they applied the expected care when developing a critical application if the software is self-adaptive.
- Software may enter unforeseeable states that have never been tested or reasoned about.
6. LESSONS AND CHALLENGES
- The authors present the overall conclusions of the road map paper in the context of lessons learned and what were the major challenges identified.
- First and foremost, this exercise had no intention of being exhaustive.
- In the following, for each of the four views, the authors presented some of the identified challenges.
- The major challenge here is the definition of a new requirements language that would be able to capture uncertainty at a more abstract level.
- Considering requirements might vary at run-time, systems should be made aware of their own requirements, hence the need of "requirements reflection" and online goal refinement.
Modelling.
- The more precise the models are, the more effective they should be in supporting run-time analysis and decision process.
- At the same time models should be sufficiently simple, otherwise synthesis might become unfeasible.
- The definition of utility functions for supporting decision making is a challenging task, and practical techniques are needed to specify and generate these utility functions.
- Once loops become more explicit, it becomes much easier to reify properties, so they can be queried and modified at run-time.
- For facilitating the reasoning between system properties and its control loops, reference architectures should be defined that highlight key aspects of these loops, such as, number, structural arrangements, interactions and stability conditions.
Assurances.
- The major challenge here is to supplement traditional methods applied at requirements and design stages of development with run time assurances.
- There are uncertainties associated with this process, hence probabilistic approaches is a promising research direction.
- This might be achieved with adaptation-specific model driven environments.
- The authors can conclude that all four theses refer to new challenges the software engineering of self-adaptive systems has to face which result from the dynamics of adaptation.
- This dynamics requires that well proven principles and techniques valid for standard software engineering have to be questioned and new solutions have to be considered.
Did you find this useful? Give us your feedback
Citations
783 citations
[...]
616 citations
600 citations
Cites background from "Software Engineering for Self-Adapt..."
...Some of the ideas developed in this paper have initially been presented elsewhere [26,36,56]....
[...]
333 citations
323 citations
References
3,363 citations
"Software Engineering for Self-Adapt..." refers background in this paper
...The control loop is a central element of control theory, which provides wellestablished mathematical models, tools, and techniques to analyze system performance, stability, sensitivity, or correctness [30, 31]....
[...]
2,092 citations
Additional excerpts
...In goal-modelling notations such as KAOS [14] and i [15], there is no explicit support for uncertainty or adaptivity....
[...]
1,743 citations
"Software Engineering for Self-Adapt..." refers background in this paper
...In goal-modelling notations such as KAOS [14] and i! [15], there is no explicit support for uncertainty or adaptivity....
[...]
Related Papers (5)
Frequently Asked Questions (10)
Q2. What other fields might be used to help in the development of self-adaptive systems?
Some of the fields have been mentioned in this paper, like, control theory, but other fields from which software engineering might get some inspiration for the development of self-adaptive systems are, decision theory, non-classic computation, and computer networks.
Q3. What technologies might be used to help self-adaptive systems?
Technologies like, model driven development, aspect-oriented programming, and software product lines might offer new opportunities in the development of self-adaptive systems, and change the processes by which these systems are developed.
Q4. What is the common scheme from control engineering?
Another typical scheme from control engineering is organizing multiple control loops in the form of a hierarchy where, due to the employed different time periods, unexpected interference between the levels can be excluded.
Q5. Why is the MRAC solution a solid starting point for the design of self-adaptive?
Because of the separation of concerns (i.e., model reference, adaptive algorithm, controller and process), this solution is a solid starting point for the design of self-adaptive software-intensive systems.
Q6. What are the technical options for implementing reconfigurability at the architecture level?
There are a variety of technical options forimplementing reconfigurability at the architecture level, including component-based, aspect-oriented and product-line based approaches, as well as combinations of these.
Q7. What are the main arguments for making self-adaptation external?
Garlan and Schmerl also advocate to make self-adaptation external, as opposed to be internal or hard-wired, to separate the concerns of system functionality from the concerns of self-adaptation [8].
Q8. Why do the V&V methods need to be supplemented with run-time assurance techniques?
Due to this high dynamism, V&V methods traditionally applied at requirements and design stages of development must be supplemented with run-time assurance techniques.
Q9. What other research communities have also investigated this topic from their own perspective?
Other research communities that have also investigated this topic from their own perspective are even more diverse: fault-tolerant computing, distributed systems, biologically inspired computing, distributed artificial intelligence, integrated management, robotics, knowledge-based systems, machine learning, control theory, etc.
Q10. What is the argument that current state-of-the-art engineering practices are not sufficiently mature?
It can be also argued that current state-of-the-art engineering practices are not sufficiently mature to warrant self-adaptive functionality.