software engineering for self-adaptive systems baldoino fonseca
TRANSCRIPT
Self-Adaptation
• The complexity of current software-based systems has led the software engineering community to look for inspiration in diverse related fields (e.g., robotics, artificial intelligence) as well as other areas (e.g., biology) to find new ways of designing and managing systems and services.
• Self-adaptation
– Has become one of the most promising directions.
– The capability of the system to adjust its behaviour in response to its perception of the environment.
19/04/23 2Carlos J. P. Lucena © LES/PUC-Rio
The Development of Self-adaptive Systems
• The development of self-adaptive systems can be viewed from two perspectives:
• top-down when considering an individual system
– assess their own behaviour and change it when the assessment indicates a need to adapt due to evolving functional or non-functional requirements
• bottom-up when considering cooperative systems
– The global behaviour of the system emerges from these local interactions.
19/04/23 3Carlos J. P. Lucena © LES/PUC-Rio
19/04/23 4Carlos J. P. Lucena © LES/PUC-Rio
The Study of Self-Adaptive Systems
• The topic of self-adaptive systems has been studied within the diferent research areas of software engineering, including, requirements engineering, software architectures, middleware, component-based development, and programming languages (most of these initiatives have been isolated).
• Other research communities that have also investigated this topic from their own perspective are even more diverse: fault-tolerant computing, biologically inspired computing, multi-agent systems, (distributed artificial intelligence) and robotics, among others.
19/04/23 5Carlos J. P. Lucena © LES/PUC-Rio
Roadmap
• Requirements
- state of the art
- research challenges
• Engineering- state of the art
- research challenges
19/04/23 6Carlos J. P. Lucena © LES/PUC-Rio
Requirements – State of the Art 1
• Requirements engineering is concerned with what a system ought to do and within which constraints it must do it.
• Requirements engineering for self-adaptive systems, therefore, must address what adaptations are possible and what constrains how those adaptations are carried out.
19/04/23 7Carlos J. P. Lucena © LES/PUC-Rio
Requirements – State of the Art 2
• In particular, questions to be addressed include:
• what aspects of the environment are relevant for adaptation?
• Which requirements are allowed to vary or evolve at runtime and which must always be maintained?
• In short, requirements engineering for self-adaptive systems must deal with uncertainty because the expectations on the environment frequently vary over time.
19/04/23 8Carlos J. P. Lucena © LES/PUC-Rio
Requirements – State of the Art 3
• One of the main challenges that self-adaptation poses is that when designing a self-adaptive system, we cannot assume that all adaptations are known in advance
• That is, we cannot anticipate requirements for the entire set of possible environmental conditions and their respective adaptation specifications.
• For example, if a system is to respond to cyber-attacks, one cannot possibly know all attacks in advance since malicious actors develop new attack types all the time.
19/04/23 9Carlos J. P. Lucena © LES/PUC-Rio
Requirements – State of the Art 4
• As a result, requirements for self-adaptive systems may involve degrees of uncertainty or may necessarily be specified as “incomplete".
• The requirements specification therefore should cope with:
- the incomplete information about the environment and the resulting incomplete information about the respective behaviour that the system should expose
- the evolution of the requirements at runtime
19/04/23 10Carlos J. P. Lucena © LES/PUC-Rio
Requirements – Challenges 1
A New Requirements Language
• Traditionally, requirements documents make statements such as “the system shall do this".
• 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.
19/04/23 11Carlos J. P. Lucena © LES/PUC-Rio
Requirements – Challenges 2
• For example:
– Traditional RE:
• “the system shall do this ... ."
– Adaptive RE:
• “the system might do this ... ."
• “But it may do this..." ... “as long as it does this ... ."
• “the system ought to do this... ." but “if it cannot, it
• shall eventually do this ...“
19/04/23 12Carlos J. P. Lucena © LES/PUC-Rio
Requirements – Challenges 3
Mapping to Architecture
• Given a new requirements language that explicitly handles uncertainty, it will be necessary to provide systematic methods for refining models in this language down to specific architectures that support runtime adaptation.
• One can imagine, therefore, a semi-automated process for mapping to architecture where heuristics and/or patterns are used to suggest architectural units corresponding to certain vocabulary terms in the requirements.
19/04/23 13Carlos J. P. Lucena © LES/PUC-Rio
Requirements – Challenges 4
Managing Uncertainty
• In general, once we start introducing uncertainty into our software engineering processes, we must have a way of managing this uncertainty and the inevitable complexity associated with handling so many unknowns.
• Certain requirements will not change (i.e., invariants), whereas others will permit a degree of flexibility.– For example, a system cannot start out as a transport robot and self-
adapt into a robot chef!
• Allowing uncertainty levels when developing self-adaptive systems requires a trade of between flexibility and assurance such that the critical high-level goals of the application are always met.
19/04/23 14Carlos J. P. Lucena © LES/PUC-Rio
Requirements – Challenges 6
Online Goal Refinement
• As in the case of design decisions that are eventually realized at runtime, new and more flexible requirement specifications would imply that the system should perform the RE processes at runtime, e.g. goal-refinement
Traceability from Requirements to Implementation
• New operators of a new RE specification language should be easily traceable down to architecture, design, and beyond. Furthermore, if the RE process is performed at runtime we need to assure that the final implementation or behaviour of the system matches the requirements.
19/04/23 15Carlos J. P. Lucena © LES/PUC-Rio
Roadmap
• Requirements
- state of the art
- research challenges
• Engineering- state of the art
- research challenges
19/04/23 16Carlos J. P. Lucena © LES/PUC-Rio
Engineering: State of the Art & Feedback Loops
Preliminary consideration
• Any attempt to automate self-adaptive systems necessarily has to consider feed-back loops. We focus on the feed-back loop - a concept that is elevated to a first-class entity in control engineering - when engineering self-adaptive software systems.
Commonalities of self-adaptive systems
• What self-adaptive systems have in common is that design decisions are moved towards runtime and that the system reasons about its state and environment. The reasoning typically involves feedback processes with four key activities: collect, analyze, decide, and act
19/04/23 18Carlos J. P. Lucena © LES/PUC-Rio
Example
• For example, keeping web services up and running for a long time requires:
– collecting of information that reflects the current state of the system,
– analysis 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.
19/04/23 19Carlos J. P. Lucena © LES/PUC-Rio
Engineering: Generic Control Loop 1
• When engineering a self-adaptive system, questions about these properties become important.
• The feedback cycle starts with the collection of relevant data from environmental sensors and other sources that reflect the current state of the system.
• Some of the engineering questions that need be answered are: How reliable is the sensor data?
19/04/23 20Carlos J. P. Lucena © LES/PUC-Rio
Engineering: Generic Control Loop 2
• Next, the system analyzes the collected data.
• There are many approaches to structuring and reasoning about the raw data (e.g., using applicable models, theories, and rules).
• Some of the applicable questions here are: How is the current state of the system inferred? How much past state may be needed in the future? What data need to be archived for validation and verification?
19/04/23 21Carlos J. P. Lucena © LES/PUC-Rio
Engineering: Generic Control Loop 3
• Next, a decision must be made about how to adapt the system in order to reach a desirable state.
• Approaches such as risk analysis can help to make a decision among various alternatives.
• Here, the important questions are: How is the future state of the system inferred? How is a decision reached (e.g., with off-line simulation or utility/goal functions)?
19/04/23 22Carlos J. P. Lucena © LES/PUC-Rio
Engineering: Generic Control Loop 4
• Finally, to implement the decision, the system must act via available actuators and effectors.
• Important questions here are: When should and can the adaptation be safely performed? How do adjustments of different feedback loops interfere with each other? Do centralized or decentralized control help achieve the global goal?
• 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.
19/04/23 23Carlos J. P. Lucena © LES/PUC-Rio
Autonomic Computing
• Autonomic computing seeks to improve computing systems with a similar aim of decreasing human involvement.
• The term “autonomic” comes from biology.
– In the human body, the autonomic nervous system takes care of unconscious reflexes, that is, bodily functions that do not require our attention
• The term autonomic computing was first used by IBM in 2001 to describe computing systems that are said to be self-managing.
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Autonomic Computing
• Autonomic computing aims at providing systems with self-management capabilities
– self-configuration (automatic configuration according to a specified policy)
– self-optimization (continuous performance monitoring)
– self-healing (detecting defects and failures, and taking corrective actions)
– self-protection (taking preventive measures and defending against malicious attacks)
Challenges on Support Self-Adaptation
• Tight-coupling between application code and adaptation logic
• Significant development effort to explicitly model the numerous potential states and paths from one state to a new state.
• Trace the self-adaptive requirements to implementation elements
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Approach Overview
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
IDW NN PI
Interpolation
SplineVegetation Slope Rain
Factors
GeoRisc
1New Requirement or
Context Change
2Analyze and System
Reconfiguration
Feature Model Reconfiguration
IDW NN PI
Interpolation
SplineVegetation Slope Rain
Factors
GeoRisc
3Runtime Constraint
Validation
4Adaptation selection
5Structure Constraint
Validation
6Derivation
7System
Reconfiguration
Interpolation Agent
Interpolation Agent
Runtime system
Architectural Models
GeoRisc
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Vegetation
Slope Rain
Factors
IDW NN PI
Interpolation
Spline
Preserved Forest
Degraded Forest
Plantation
Vegetation
Floodplain(...)
scale Scale Scale Scale
SM Generation Process
Variabilidades
Feature Model
• The running system is viewed as a valid configuration of the feature model.
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
• Feature model helps to avoid wrong feature model configuration.
IDW NN PI
Interpolation
SplineVegetation Slope Rain
Factors
GeoRisc
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Domain-specific Architecture Models
Classes, Aspectos ...
JADE Model
Files
Feature Model
Automatic Reasoning on Feature Model
• Based on Constraint Programming - Constraint Satisfaction Problem (CSP)
– Set of variables
– Set of constraints over those variables
• CSP for Feature Model
– Set of variables F representing the features in the feature model
– Each configuration is a set of values for these variables
• fi = 1 (Selected) or fi = 0 (Deselected)
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Automatic Reasoning on Feature Model
• Configuration rules
– Set of constraints C associated with each variable f• Mandatory Relation
– f1 = f
• Optional Relation
– f1 f
• Or-relation
– f f1 v f2 v … fn
• Alternative Relation
– f fi | i [1..n] (f1 (¬f2^…^¬fn^f)^(f2 (¬f1^…
^¬fn^f)^…^(fn (¬f1^…^¬fn-1^f)
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Automatic Reasoning on Feature Model
• The CSP is able to answer the following questions
– Number of Products
– Filter
– Products
– Variant
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Feature Model Reconfiguration
• Feature Model Reconfiguration
– A A’ select and deselect a set of features
• Staged Feature Reconfiguration
– A A’1 A’2 ... A’ n = A’
• Diagnose:
– Staged Reconfiguration Errors
– Conflicts
– Software Evolution
Automatic Repair of Feature Model Configuration
• Find a valid configuration from a given flawed configuration.
– Results in set of feature selection changes to which fix the invalid configuration.
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Slope
Factors
File DataBase
Rain
File DataBase
Vegetation
File DataBase xSlope
Factors
File DataBase
Rain
File DataBase
Vegetation
File DataBase
Automatic Reasoning on Architecture Models
• Based on Constraint Programming
• CSP for Domain-specific Architecture Models
– Set of variables A representing the element in the architecture model
– Set of variables D representing the element in the domain-specific
architecture model
– Each configuration is a set of values for these variables
• di = 1 (Selected) or di = 0 (Deselected)
• ai = 1 (Selected) or ai = 0 (Deselected)
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Automatic Reasoning on Architecture Models
• Configuration Rules
– Set of constraints Cf for each variable d which have a feature
expression associated
• Boolean Feature expression di
– Set of constraints Ca for each variable d which have
architecture element associated
• di ai
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Dynamic Binding Approach
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Runtime Environment
OSGi
JADE
JVM
Management Server
GenArch
FeatureModel
Multi-levelModels
KnowledgeKnowledge
References
• Software Engineering for Self-Adaptive Systems: A Research Road Map
– Betty H.C. Cheng, et. al.
• A survey of Autonomic Computing—Degrees, Models, and Applications
– MARKUS C. HUEBSCHER and JULIE A. McCANN
19/04/23 40Carlos J. P. Lucena © LES/PUC-Rio