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
A Speci(ication-‐oriented Perspective
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
A Speci(ication-‐oriented Perspective
Environment
Requirements EnvironmentAssumptions
Speci5ication
Requirements EnvironmentAssumptions
NEW Speci5ication
13
A Speci(ication-‐oriented Perspective
Environment
Requirements EnvironmentAssumptions
Speci5ication
Requirements EnvironmentAssumptions
NEW Speci5ication
14
A Speci(ication-‐oriented Perspective
Environment
Requirements EnvironmentAssumptions
Speci5ication
Requirements EnvironmentAssumptions
NEW Speci5ication
Challenges:1) In which state a running system can be safely updated to satisfy the new speci5ication?
15
A Speci(ication-‐oriented Perspective
Environment
Requirements EnvironmentAssumptions
Speci5ication
Requirements EnvironmentAssumptions
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