Software Engineering for Self-Adaptive Systems Self-Adaptation

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. 18/03/2018 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. 18/03/2018 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. 18/03/2018 Carlos J. P. Lucena © LES/PUC-Rio 4

Roadmap • Requirements – state of the art – research challenges • Engineering – state of the art – research challenges 18/03/2018 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. 18/03/2018 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 18/03/2018 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. 18/03/2018 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 18/03/2018 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. 18/03/2018 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. 18/03/2018 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. 18/03/2018 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. 18/03/2018 Carlos J. P. Lucena © LES/PUC-Rio 13

Roadmap • Requirements – state of the art – research challenges • Engineering – state of the art – research challenges 18/03/2018 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 18/03/2018 Carlos J. P. Lucena © LES/PUC-Rio 15

Figure 1: Activities of the control loop. 18/03/2018 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. 18/03/2018 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? 18/03/2018 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? 18/03/2018 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)? 18/03/2018 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. 18/03/2018 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. 18/03/2018 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 18/03/2018 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. 18/03/2018 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 18/03/2018 26 @LES/P

JAAF 1. 0: Hot-spots e Frozen-spots • Agente (classe Adaptation. Agent) • Planos de Auto-Adaptação (classe Adaptation. Control. Loop) • Atividades (classe Behaviour) • Mecanismos de Raciocínio (interface IReasoning. Strategy) 18/03/2018 27 @LES/P

JAAF 1. 0: Diagrama de Classes 18/03/2018 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. 18/03/2018 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 – 18/03/2018 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 18/03/2018 31 @LES/P

JAAF-S: Diagrama de Classes 18/03/2018 32 @LES/P

JAAF-S: Analyze 18/03/2018 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 service. Failure); • (ii) tempo de resposta (representada pela variável response. Time); • (iii) autenticações realizadas com sucesso (representada pela variável authentication. Erro). 18/03/2018 34 @LES/P

JAAF-S: Analyze • Raciocínio Baseado em Regras (RBR) R 1: If service. Failure > 0 Then Problem = “service. Failure” R 2: If Problem!=“service. Failure” AND response. Time > 10 Then Problem = “high. Response. Time” R 3: If Problem!=“service. Failure” AND authentication. Erro == true Then Problem = “high. Response. Time” 18/03/2018 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 j. Colibri 2, 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. 18/03/2018 36 @LES/P

JAAF-S: Analyze • Similaridade entre Objetos 18/03/2018 37 @LES/P

JAAF-S: Analyze • Similaridade entre Profiles 18/03/2018 38 @LES/P

JAAF-S: Decision 18/03/2018 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. 18/03/2018 40 @LES/P

JAAF-S: Effector 18/03/2018 41 @LES/P

JAAF-S: Frozen-spots • Um control-loop de auto-adaptação representado pela classe Control. Loop. • 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. 18/03/2018 42 @LES/P

JAAF-S: Hot-spots • Planos de auto-adaptação (classe abstrata Adaptation. Conrol. Loop) • Atividades (classe abstrata Behaviour) • Monitoramento (classe abstrata Monitor) • Raciocínios (interface IReasoning. Strategy) • Técnicas para seleção de serviços (classe abstrata Selection. Strategy) • Mecanismos para efetivação da solução (interface Iactuator) 18/03/2018 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 P 1 { Condition { ! Component. is. Load. High() } Decision { Component. hello. World() } Policy P 2 { Condition { Component. is. Load. High() } Decision { Component. send. Email("admin@website. com", “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 P 2 { Condition { Component. is. Load. High() } Decision { Component. send. Email("admin@website. com", ”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 Geo. Risc 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 event e over a feature f ∈ FM, in a certain set of conditions C , the multi-agent system derive an adaptation action α. 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 Event Interpolation Agent System Reconfiguration Feature Model Reconfiguration Derive a Adaptation Action Geo. Risc Interpolation Factors Vegetation Slope Rain Feature Model Adaptation Inference IDW NN Spline Geo. Risc 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 – f 1 f • Or-relation – f f 1 v f 2 v … fn • Alternative Relation – f fi | i [1. . n] (f 1 (¬f 2^…^¬fn^f))^(f 2 (¬f 1^…^¬fn^f))^…^(fn (¬f 1^…^¬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 - Geo. Risc SM Generation Process Input Factors • Factors to be analyzed Step 1 • Data Interpolation Step 2 Vegeta tion Output Rain Interpolation • Landslide risk prediction • Landslide risk Slope IDW NN PI Spline Vegetati on Preserved Forest scale Degraded Forest (. . . ) Plantation 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 Data. Base . . . c: \Geo. Risco\dados\rain. shp Camila Nunes, Elder Cirilo e Ingrid Nunes © LES/PUC-Rio File Data. Base jdbc: mysql: //localhost/olis

Working Example I- Self-healing @MBehaviour(ID="Rain", agent. Name="Geo. Risc. Agent") public class Rain extends Cyclic. Behaviour { private Geo. Risc. Agent geo. Risc. Agent; @MResource private String data. Source = “db: //jdbc: mysql: //localhost/olis“; “file: //c: \Geo. Risco\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 Data. Base Rain File Data. Base

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. Mc. CANN 18/03/2018 Carlos J. P. Lucena © LES/PUC-Rio 63

Software Engineering for Self-Adaptive Systems