Paderborn

1

Challenges of self-adaptive softwarethe fading boundary between

development time and run time

9th International Heinz Nixdorf Symposium

Carlo Ghezzi Politecnico di Milano

Deep-SE Group @ DEI-PoliMI

The vision

• World fully populated by computationally rich devices offering services (disappearing computer) – appliances, sensors/actuators, ... “things”

• Cyber-physical systems• Mobility• Situation-aware computing

– new “services” built dynamically in a situation-dependent manner

• Continuously running systems– need to evolve while they offer service

2

The challenge

• Change and flexibility adversary of dependability

• Can they be reconciled through sound design methods?

3

The machine and the world

4

GoalsRequirements

Domainproperties(assumptions)

Specification

P. Zave and M. Jackson. Four dark corners of requirements engineering. ACM Trans. Softw. Eng. Methodol., 6(1):1–30, 1997.

Dependability arguments

Assume that a rigorous (formal) representation is given for– R = requirements– S = specification– D = domain assumptions

if S and D are all satisfied and consistent, it is necessary to prove

– S, D |= R

5

Change comes into play

• Changes in goals/requirements• Changes in domain assumptions

– Usage context• request profiles

– Physical context• space, time, …

– Computational context• external components/services (multiple ownership) ‣ systems increasingly built out of parts that are developed, maintained,

and even operated by independent parties‣ no single stakeholder oversees all parts, which may change

independently‣ yet by assembling the whole one commits to achieving certain goals

6

Changes may affect dependability

• Changes may concern• R • D

• We can decompose D into Df and Dc

– Df is the fixed/stable part

– Dc is the changeable part

We need to detect changes to Dc

and make changes to S to keep satisfying R

7

(self-)adaptation (vs. evolution)

Change revisited

• Change recognized as a crucial problem since the 1970’s (see work by M. Lehman)

• Traditionally managed off-line: software maintenance• What is new here

– the unprecedented degree of change– the request that software responds to changes while

the system is running (continuously running systems), possibly in a self-managed manner

8

A paradigm change• Conventional separation between development time

and run time is blurring• Models + requirements need to be kept + updated at

run time (systems need to be reflective)• Continuous verification must be performed to detect

the need for adaptation

9

Env

F(S=OK)

R. Calinescu, C. Ghezzi, M. Kwiatkokwska, R. Mirandola, “Self-adaptive software needs quantitative verification at runtime”, Comm. ACM, Sept. 2012

Zoom-in A framework for (self) adaptation

10

• [ICSE 2009] I. Epifani, C. Ghezzi, R. Mirandola, G. Tamburrelli, "Model Evolution by Run-Time Parameter Adaptation”

• [RE 2009] C. Ghezzi, G. Tamburrelli, "Reasoning on Non Functional Requirements for Integrated Services”

• [FSE 2010] I. Epifani, C. Ghezzi, G. Tamburrelli, "Change-Point Detection for Black-Box Services”

Specific focus• Non-functional requirements

– reliability, performance, energy consumption, cost, …

• Quantitatively stated in probabilistic terms• Dc decomposed into Du , Ds

– Du = usage profile

– Ds = S1 ∧ .... ∧ Sn Si assumption on i-th service

11

?System under development

???

?

???Hard to estimate at design time + very likely to change at run time

Our approach in a nutshell

12

E1

0Reqs + Initial

Assumptions

Formalization

Implementation

Execution

Monitoring

Learning & update

Models

• Different models provide different viewpoints from which a system can be analyzed

• Focus on non-functional properties and quantitative ways to deal with uncertainty

• Use of Markov models– DTMCs for reliability– CTMCs for performance– Reward DTMCs for energy/cost

13

Quantitative modelling

• Operational model: state machine with probabilities on transitions (DTMC)

• Success/failure states as final• Requirements expressed as properties in PCTL (probabilistic

extension of CTL) • typically: reachability properties

• P>0.8 [◊(system state = success)]

• Excellent tools exist to perform verification via model checking– PRISM (Kwiatkowska et al.)

• http://www.prismmodelchecher.org/

– MRMC (Katoen at al.) • http://www.mrmc-tool.org/trac/

14

The approach in in action: e-commerce service composition

15

3 probabilistic requirements:R1: “Probability of success is > 0.8”R2: “Probability of a ExpShipping failure for a user recognized as BigSpender < 0.035”R3: “Probability of an authentication failure is less then < 0.06”

Users classified as BigSpender

or SmallSpender based on their usage profile.

Assumptions

16

User profile domain knowledge

External service assumptions (reliability)

DTMC model

17

Property check via model checkingR1: “Probability of success is > 0.8”R2: “Probability of a ExpShipping failure for a user recognized as BigSpender < 0.035”R3: “Probability of an authentication failure is less then < 0.06”

0.84

0.0560.031

What happens at run time?

• We monitor the actual behavior• A statistical (Bayesian) approach estimates the updated DTMC

matrix (posterior) given run time traces and prior transitions• Boils down to the following updating rule

18

A-priori Knowledge A-posteriori Knowledge

Model @ run time• A detected violation of a requirements does not mean that the

violation actually occurred in reality (i.e., experienced by user)• Model analysis has a predictive nature

19

0.067

Probability of a ExpShipping failure for a user recognized a BigSpender < 0.035

Predictedfailure!

Reflective run time environments

• Traditionally software engineering has been mostly concerned with development time

• The result is code that simply needs to be run

(Self-)adaptive software requires much more- must be able to reason at run time about itself and

the environment✓models✓ goals and requirements✓ strategies

must be available at runtime20

Run-time agility, incrementality• Agility taken to extremes

- time boundaries shrink ✓ constrained by real-time requirements

• Verification approaches must be re-visited- they must be incremental

Given S system (model), P property to verify for S Change = new pair S’, P’Incremental verification reuses part of the proof of S against P to verify S’ against P’

21

Incrementality by parameterization

• Requires anticipation of changing parameters• The model is partly numeric and partly symbolic• Evaluation of the verification condition requires

partial evaluation (mixed numerical/symbolic processing)

• Result is a formula (polynomial for reachability on DTMCs)

• Evaluation at run time substitutes actual values to symbolic parameters

22

[ICSE 2011] A. Filieri, C. Ghezzi, G. Tamburrelli, “Run-Time Efficient Probabilistic Model Checking”[FAC 2012] A Filieri, C. Ghezzi, G. Tamburrelli,, “A formal approach to adaptive software: continuous assurance of non-functional requirements”, Formal Aspects of Computing, vol. 4, n. 2, 2012

Working mom paradigm

Cook first

Warm-up la

ter

Working mom paradigm

23

Des

ign-

Tim

e(o

fflin

e)R

un-T

ime

(onl

ine)

Partial evaluation

Parametervalues

E1

0

Analyzable properties: reliability, costs (e.g., energy consumption)

Back to example

24

12

Profiler

9

Buy

6

Search

1

Returning

3

NewCustomer

7

Buy

4

Search

11

10

ExpShipping

12

14

Logout

16

Success

5 1

FailedLg

8

FailedChk

15 1

FailedNrmSh

13 1

FailedExpSh

1

0

Login

0.97

0.030.65

0.35

1

1

0.20.5 0.05

0.6

NrmShipping

0.030.95

0.1 0.97

0.95

0.9

1

0.15

1

0.3

0.05

CheckOut

0.25

x

1-x

Design time evaluation has very high complexityRun time evaluation is extremely efficient

Zoom-in Control-theory based self adaptation

25

[ASE 2011] A. Filieri, C. Ghezzi, A. Leva, M. Maggio, “Self-Adaptive Software Meets Control Theory: A Preliminary Approach Supporting Reliability Requirements”[SEAMS 2012] A. Filieri, C. Ghezzi, A. Leva, M. Maggio, "Reliability-driven dynamic binding via feedback control"

First approach• Tune software through its model via feedback control loop• Formally prove controller’s capabilities (error reduction,

convergence, ...)

26

Parametric behavioral

model

Dynamiccontrollable

model

Control the model, control the software

Dynamiccontrollable

model

Controller

Reliability-driven Dynamic-binding

27

[SEAMS2012]

Abstract interface

Concreteimplementations

T�

T�

T�

T�p 1-p

p 1-p p 1-p

C0

C1 C2

PI Controllers

Zoom-in Dynamic software update

28

[ESEC/FSE 2011] X, Ma, L, Baresi, C, Ghezzi, V. Panzica La Manna, and J. Lu, “Version-consistent Dynamic Reconfiguration of Component-based Distributed Systems”[SEAMS 2012] C. Ghezzi, J. Greenyer, V. Panzica La Manna, "Synthesizing Dynamically Updating Controllers from Changes in Scenario-based Specifications"

29

Goal• Support run-time changes to the structure and

behavior of a running software

Low$Disruption$ Timeliness$ Safety$

• Two approaches:• Module level• Model level

10

A Speci(ication-‐oriented Perspective

Environment

11


Environment

Requirements EnvironmentAssumptions

Speci5ication Requirements: The set of runs (events sequences) allowed in the system.

“Something that the system must (not) do”

Assumptions: The set of runs we assume can happen in the system.

“Something that the environment will (not)

12


Environment


Speci5ication


NEW Speci5ication

13


Environment


Speci5ication


NEW Speci5ication

14


Environment


Speci5ication


NEW Speci5ication

Challenges:1) In which state a running system can be safely updated to satisfy the new speci5ication?

15


Environment


Speci5ication


NEW Speci5ication

Challenges:1) In which state a running system can be safely updated to satisfy the new speci5ication?2) How the dynamically updating system can be automatically derived?

17

Contribution

1.General formal de5inition of correct dynamic updates from changes in the speci5ication.

2.Approach for automatically synthesizing a dynamically updating controller from changes in scenario-‐based speci5ications.

Challenges:1) In which state a running system can be safely updated to satisfy the new speci5ication?2) How the dynamically updating system can be automatically derived?

37

Conclusions and future work

• (Self-)adaptation is needed• It requires a paradigm shift• Run-time environments must become semantically

rich• Run-time reasoning must be supported, not just

execution• Continuous change and the quest for incrementality• Opportunities for interdisciplinary

research• Challenges from real scenarios

Thanks to the group

38

Acknowledgements

This work is supported by and Advanced Grant of the European Research CouncilProgramme IDEAS-ERC, Project 227977---SMScom

39

Paderborn

Documents

requirements s

run time systems

development time

dependability changes

design time

goalsrequirements changes

play changes

specification d