Software Engineering for Self-Adaptive
Systems
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
2
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 nonfunctional requirements
• bottom-up when considering cooperative systems
– The global behaviour of the system emerges from these local
interactions.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
3
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
4
Roadmap
• Requirements
– state of the art
– research challenges
• Engineering
– state of the art
– research challenges
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
5
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
6
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?
• 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
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
7
Requirements – State of the Art 3
• Requirements engineering for self-adaptive systems
must deal with uncertainty because the expectations
on the environment frequently vary over time.
• For example, if a system is to respond to cyberattacks, one cannot possibly know all attacks in
advance since malicious actors develop new attack
types all the time.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
8
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
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
9
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 selfadaptive systems that gives stakeholders the flexibility to
account for uncertainty in their requirements documents.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
10
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
11
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 selfadapt 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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
12
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
13
Roadmap
• Requirements
– state of the art
– research challenges
• Engineering
– state of the art
– research challenges
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
14
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
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
15
Figure 1: Activities of the control loop.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
16
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
17
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?
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
18
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?
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
19
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)?
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
20
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
21
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.
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
22
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)
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
JAAF-*
Baldoíno Fonseca Neta
05/11/2015
24
@LES/P
JAAF
• JAAF-S é um framework que basea-se na experiência
adquirida durante o desenvolvimento do seu antecessor
(JAAF 1.0) a fim de fornecer suporte ao desenvolvimento de
agentes auto-adaptativos orientados a serviços.
• A principal diferença entre o JAAF-S e o JAAF 1.0 esta na
adição de um conjunto de mecanismos para:
– Monitoramento;
– Descoberta;
– Seleção;
– Disponibilização de serviços em tempo de execução.
05/11/2015
25
@LES/P
JAAF 1.0
• Fornece mecanismos reutilizáveis para o desenvolvimento
de agentes auto-adaptativos como uma extensão do JADE;
• Arquitetura baseada em Control-loop
– Collect
– Analyze
– Decision
– Effector
05/11/2015
26
@LES/P
JAAF 1.0: Hot-spots e Frozen-spots
• Agente (classe AdaptationAgent)
• Planos de Auto-Adaptação (classe AdaptationControlLoop)
• Atividades (classe Behaviour)
• Mecanismos de Raciocínio (interface IReasoningStrategy)
05/11/2015
27
@LES/P
JAAF 1.0: Diagrama de Classes
05/11/2015
28
@LES/P
JAAF-S
•
É uma evolução do framework JAAF 1.0;
•
Fornece mecanismos para o desenvolvimento de
agentes capazes de realizar as seguintes tarefas
relacionadas a Web Service (WS):
–
Monitoramento;
–
Detecção de falhas provenientes da sua execução;
–
Descoberta de novos serviços WS capazes de solucionar
tais falhas;
–
Seleção do melhor dentre os vários descobertos;
–
Notificações e configurações necessárias para
disponibilização do WS selecionado.
05/11/2015
29
@LES/P
JAAF-S: Control-loop
•
Collect
–
•
Analyze
–
•
Collect e utiliza um conjunto de mecanismos de raciocínio para
detecção de problemas e descoberta de novos WS.
Decision
–
•
Utiliza tecnologias para monitoramento de eventos e WS.
Estrutura tais informações de forma que elas possam ser
entendidas pelas atividades seguintes;
Seleciona serviço que melhor solucione os problemas que
levaram à necessidade da auto-adaptação;
Effector
–
05/11/2015
Realiza as notificações e configurações necessárias para
disponibilização do serviço selecionado pela atividade
Decision.
30
@LES/P
JAAF-S: Diagrama de Classes
05/11/2015
31
@LES/P
JAAF-S: Diagrama de Classes
05/11/2015
32
@LES/P
JAAF-S: Analyze
05/11/2015
33
@LES/P
JAAF-S: Analyze
• Raciocínio Baseado em Regras (RBR)
– Considere que a atividade Collect esteja monitorando um
determinado serviço e as seguintes informações são
coletadas:
• (i) Número de falhas ocorridas durante a sua execução
(representada pela variável serviceFailure);
• (ii) tempo de resposta (representada pela variável responseTime);
• (iii) autenticações realizadas com sucesso (representada pela
variável authenticationErro).
05/11/2015
34
@LES/P
JAAF-S: Analyze
• Raciocínio Baseado em Regras (RBR)
R1: If serviceFailure > 0 Then Problem = “serviceFailure”
R2: If Problem!=“serviceFailure” AND responseTime > 10
Then Problem = “highResponseTime”
R3: If Problem!=“serviceFailure” AND authenticationErro == true
Then Problem = “highResponseTime”
05/11/2015
35
@LES/P
JAAF-S: Analyze
• Raciocínio Baseado em Casos (RBC)
– Similaridade entre Objetos
• O objetivo deste mecanismo é encontrar as experiências passadas
mais similares com o problema atual. Para tanto, ele estende a API
jColibri2, a fim de fazer uso dos algoritmo de similaridade local e
global.
• Tais algoritmos são aplicados entre os dados coletados na atividade
Collect, juntamente, com os problemas detectados a partir da
aplicação do RBR, e o conjunto de casos (ou experiências
passadas) recuperados a partir do banco de dados.
– Similaridade entre OWL-S
• O objetivo do mecanismos em questão é verificar o nível de
similaridade entre as soluções enviadas pelo mecanismo
anteriormente descrito e um conjunto de Profiles descrevendo
serviços atualmente on-line.
05/11/2015
36
@LES/P
JAAF-S: Analyze
• Similaridade entre Objetos
05/11/2015
37
@LES/P
JAAF-S: Analyze
• Similaridade entre Profiles
05/11/2015
38
@LES/P
JAAF-S: Decision
05/11/2015
39
@LES/P
JAAF-S: Decision
• Função de Utilidade
– Avalia e seleciona cada serviço levando em consideração
diferentes dimensões de qualidade como tempo de resposta,
custo, performance, segurança, escalabilidade, etc.
– Exemplo:
• Serviço Pacote Viagem Nordeste Paraíso
– Possui tempo de resposta (t) médio, segurança (s) excelente e
escalabilidade (e) médio, com utilidade ut(médio) = 0.5,
us(excelente) = 1 e ue(médio) = 0.5, respectivamente.
– Considerando que o tempo de resposta tem peso wt =0.2,
segurança ws = 0.4 e escalabilidade we = 0.4 a importância do
serviço é calculada da seguinte forma:
– 0.2*0.5 + 0.4*1 + 0.4*0.5 = 0.7;
• Reputação
– Basea-se na reputação dos serviços para realizar a seleção.
05/11/2015
40
@LES/P
JAAF-S: Effector
05/11/2015
41
@LES/P
JAAF-S: Frozen-spots
• Um control-loop de auto-adaptação representado pela classe
ControlLoop.
• Quatro atividades: Collect, Analyze, Decision e Effector.
• Um mecanismo para monitoramento de WS e outro para
interceptação de eventos.
• Dois mecanismos de similaridade:
– (i) Verifica similaridade entre objetos
– (ii) Verifica similaridade entre ontologias OWL-S.
• Dois mecanismos de seleção :
– (i) Função de Utilidade
– (ii) Reputação;
• Três mecanismos relacionados a atividade Effector:
– (i) realiza notificação de mudanças;
– (ii) realiza as configurações necessárias para disponibilização de novos serviços
– (iii) toma as ações necessárias para execução do serviço.
05/11/2015
42
@LES/P
JAAF-S: Hot-spots
• Planos de auto-adaptação (classe abstrata AdaptationConrolLoop)
• Atividades (classe abstrata Behaviour)
• Monitoramento (classe abstrata Monitor)
• Raciocínios (interface IReasoningStrategy)
• Técnicas para seleção de serviços (classe abstrata
SelectionStrategy)
• Mecanismos para efetivação da solução (interface Iactuator)
05/11/2015
43
@LES/P
Automated Support for Self-Adaptation in
Multi-Agent Systems
Challenges on Support Self-Adaptation
• Adaptation policies prescribe a set of rules that guide the
behavior of system components
Policy P1 {
Condition {
! Component.isLoadHigh()
} Decision {
Component.helloWorld()
}
Policy P2 {
Condition {
Component.isLoadHigh()
} Decision {
Component.sendEmail("[email protected]",
“Problem !!", "...")
}
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Challenges on Support Self-Adaptation
• Tight-coupling between application code and adaptation
logic
Policy P2 {
Condition {
Component.isLoadHigh()
} Decision {
Component.sendEmail("[email protected]",”Problem !!", "...")
}
1. Extensive effort to develop the adaptation action
1. Require significant development effort to explicitly
model the numerous potential error states and recovery
paths from an error state to a correct state
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Our Approach
• Feature model is the knowledge base that serves all steps
of the control loop, instead of fixed adaptation polices
• Feature model defines all possible configurations of the
underline system.
CC = {f} | f ∈ FM ∧ f = 1 ∧ CC ⊆ FM
GeoRisc
Interpolation
Factors
Vegetation
Slope
Rain
IDW
NN
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
PI
Spline
Approach Overview
• When a reconfiguration need emerge, we consider it as an
e over a feature f ∈ FM, in a certain set of conditions
C , the multi-agent system derive an adaptation action α.
event
e(f) ∧ C ⇒ α | α ∈ {αh,αo,αc,αp }
α({Cps},{Cpd})
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Approach Overview
Runtime system
Interpolation Agent
Adaptation
Polices
Interpolation Agent
Event
System
Reconfiguration
Feature Model
Reconfiguration
Derive a
Adaptation Action
GeoRisc
Interpolation
Factors
Vegetation
Slope
Rain
Feature Model
Adaptation
Inference
IDW
NN
Spline
GeoRisc
Interpolation
Factors
Vegetation
PI
Slope
Rain
IDW
NN
Adaptation
selection
PI
Spline
Architectural
Models
Structural Constraint
Validation
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Feature Model Operations
• RC takes an inconsistent feature model configuration
ψi
and returns a set of valid feature model configuration
ψv.
RC(ψi)={ψv}
• FL takes a feature model configuration ψ and a set of
characteristic C as input and returns a set of valid
feature model configuration
ψv
that satisfies at the
same time all feature model constraints and the set of
characteristics.
FL(ψ,C) = {ψv}
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Feature Model Reconfiguration
• OT takes a set of objective functions O and a set of valid
feature model configuration ψc as input and returns a valid
feature model configurations ψo that better satisfies all
object functions.
OT({ψc},O) = ψo
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Deriving Adaptation Action
• The problem to find an adaptation action that reaches the
requested adaptation is equivalent to find a valid
reconfiguration of the feature model and compare it with the
current configuration.
• Let DR denote a derivation operation
DR(ψv,Ma,Mo,Mc,CK) = {Cp} | Cp ⊆ Mo
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Deriving Adaptation Action
Healing
αh(DR(RC(CC),Ma,Mo,Mc) – DR(CC,Ma,Mo,Mc),
DR(CC,Ma,Mo,Mc) – DR(RC(CC),Ma,Mo,Mc))
Optimization
αo(DR(OT({ψc},O),Ma,Mo,Mc) – DR(CC,Ma,Mo,Mc),
DR(CC,Ma,Mo,Mc) – DR(OT({ψc},O),Ma,Mo,Mc))
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Mapping Feature Model to CSP
• 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
Mapping Feature Model to CSP
• Configuration rules
– Set of constraints C associated with each variable 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
Mapping Models to CSP
• 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
Mapping Architectural Models to CSP
• 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
Working Example - GeoRisc
SM Generation Process
Input
• Factors to be
analyzed
Step 1
• Data
Interpolation
Step 2
• Landslide risk
prediction
Output
Factors
• Landslide risk
Vegeta
tion
Slope
Rain
Interpolation
IDW
NN
PI
Spline
Vegetati
on
Preserved
Forest
scale
Degraded
Forest
(...) Plantation
Scale
Scale
Variabilidades
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Floodplain
Scale
Configuration Knowledge
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Working Example I - Self-healing
• Georisc Input  Factors to be analyzed
– Different data sources
• File
• Data Base
Factors
Vegetation
Slope
Rain
File
DataBase
File
DataBase
...
...
...
...
c:\\GeoRisco\\dados\\rain.shp
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
File
DataBase
jdbc:mysql://localhost/olis
Working Example I- Self-healing
@MBehaviour(ID="Rain",agentName="GeoRiscAgent")
public class Rain extends CyclicBehaviour {
private GeoRiscAgent geoRiscAgent;
@MResource
private String dataSource = “db://jdbc:mysql://localhost/olis“;
“file://c:\\GeoRisco\\dados\\rain.shp“;
...
}
Failure(Rain)
Monitor
Factors
Analyzer
Data Source
Failure
x
Feature Model
Reconfiguration
Rain
File
Derive adaptation
actions
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Factors
DataBase
Rain
File
DataBase
Dynamic Binding Approach
Runtime Environment
Feature
Model
Multi-level
Models
Configuration
Model
Plan
JADE
Management Server
Analyse
Knowledge
OSGi
JVM
Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio
Monitor
Execute
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
05/11/2015
Carlos J. P. Lucena © LES/PUC-Rio
63
Software Engineering for Self-Adaptive
Systems