Post on 23-Jun-2015
description
1
Development of dynamically evolving and self-adaptive software
4. Incrementality
LASER 2013Isola d’Elba, September 2013
Carlo Ghezzi Politecnico di Milano
Deep-SE Group @ DEIB
Tuesday, September 10, 13
Lifecycle of self-adaptive systems
2
Reqs
E1
0
Implementation Monitoring
Execution
ReasoningSpecification
SpecificationDevelopment time
Run time
Env
Self-adaptation
Tuesday, September 10, 13
The problem
3
• Verification needs to work at run-time to support self-adaptive reactions• It may be subject to strict response time requirements
to support timely reactions• Current mainstream approaches do not fit this
requirement
Tuesday, September 10, 13
4
The problem• Verification needs to work at run-time to support
self-adaptive reactions • Verification subject to (application-dependent) hard
real-time requirements• Running conventional model checking tools after
any change impractical in most realistic cases• But changes are often local, they do not disrupt the
entire specification• Can they be handled in an incremental fashion?• This requires revisiting model checking algorithms!
Tuesday, September 10, 13
The quest for incrementality
5
Incremental verificationGiven a system (model) S, and a set of properties P met by S Change = new pair S’, P’ where S’= S + ∆S and P’= P + ∆P
Let ∏ be the proof of S against P
The proof ∏’ of P’ against S’ can be done by just performing a proof increment ∆∏ such that ∏’ = ∏ + ∆∏
Expectation: ∆∏ easy and efficient to perform
Tuesday, September 10, 13
An approach
• Incrementality by parameterization- We treat what can change as an unknown parameter- Verification result is parametric with respect to the
unknowns- At design time, we do analysis using the likely values we
can foresee
- At run time, we do analysis on the real values we gather via monitoring
6Tuesday, September 10, 13
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 and is very efficient
7
Working mom paradigm
Cook first
Warm-up la
ter
Tuesday, September 10, 13
Working mom paradigm
8
Run
-Tim
e(o
nlin
e)D
esig
n-T
ime
(offl
ine) Partial
evaluation
E1
0
Parametervalues
Analyzable properties: reliability, costs (e.g., energy consumption)
[ICSE 2011] A. Filieri, C. Ghezzi, G. Tamburrelli “ Run-time efficient probabilistic model checking”[FormSERA 2012] A. Filieri, C. Ghezzi, "Further steps towards efficient runtime verification: Handling probabilistic cost models"
Tuesday, September 10, 13
An example
9
r = 0.85− 0.85 ⋅ x + 0.15 ⋅ z− 0.15 ⋅ x ⋅ z− y ⋅ x0.85+ 0.15 ⋅ z
r = Pr(◊ s = 5)> r
Tuesday, September 10, 13
10
The WM approach
• Assumes that the Markov model is well formed • Works by symbolic/numeric matrix manipulation• All of (R) PCTL covered• Does partial evaluation (mixed computation, Ershov
1977)• Expensive design-time partial evaluation, fast run-
time verification- symbolic matrix multiplications, but very sparse
and normally only few variables
Tuesday, September 10, 13
11
30.05/0
Cache Server
Http Response
8 1
10.1/0
Web Server2
0.12/0
Application Server
60.15/0.07
Database Server
50.1/0
Data Cache Server
40.12/0.04
File ServerHttp 503 Server
Unavailable
7 1
00/0
Http Proxy Server
y
(1-y)*0.3
(1-y)*0.7
0.55
0.25
x
(1-x)(1-w)
z (1-k)
(1-z)0.7
0.3
0.20
Error: too many connections
9 1
k
w
An example
Rewards: AverageCost/AverageLatency
a dynamic content has been requested that requires ad-hoc processinga static content has been requestedprobability of an HTTP self-redirect(s3, s4) (s5, s6) model the cache hit probability,which depends on the current distribution of user requests
Tuesday, September 10, 13
12
Q =
0
BBBBBB@
0 (1� y)0.3 0 (1� y)0.7 0 0 00 0.2 0.55 0 0 0 00 0 0 0 0 0.7 00 0 0 0 1� x 0 00 0 0 0 0 0 00 0 0 0 0 0 00 0 0 0 0 0 1� z
0 0 0 0 0 0 0
1
CCCCCCA(1)
R =
0
BBBBB@
y 0 00 0.25 00 0.3 00 x 00 1� w w
0 z 00 1� k k
1
CCCCCA(2)
Matrix representationTransient-to-transient
Transient-to-absorbing
Tuesday, September 10, 13
13
Table 1: Requirements R1-R6.
ID Informal Definition PCTL
R1 (Reliability): “The probabil-
ity of successfully handling a
request must be greater than
0.999”
P�0.999(⌃ s = s8)
R2 (Cache hit probability): “At
least 80% of the requests
are correctly handled with-
out accessing the database or
the file server”
P�0.8(¬(s = s4)^¬(s = s6) U s =
s8)
R3 (Complexity bound): “70%
of the requests must be suc-
cessfully processed within 5
operations”
P�0.7(⌃5 s =
s8)
R4 (Early risk fingering): “No
more than 10% of the runs
can reach a state from which
the risk of eventually raising
an exception is greater than
0.95”
P0.1(⌃ P�0.95( ⌃s =s7 _ s = s9))
R5 (Cost): “The average cost
for handling a request must
be less .03 · 10�2dollars”
R0.03(⌃ s = s7_s = s8 _ s = s9)
R6 (Response time): “The av-
erage response time must be
less than 0.022 seconds”
R0.022(⌃ s =
s7 _ s = s8 _ s =
s9)
30.05/0
Cache Server
Http Response
8 1
10.1/0
Web Server2
0.12/0
Application Server
60.15/0.07
Database Server
50.1/0
Data Cache Server
40.12/0.04
File ServerHttp 503 Server
Unavailable
7 1
00/0
Http Proxy Server
y
(1-y)*0.3
(1-y)*0.7
0.55
0.25
x
(1-x)(1-w)
z (1-k)
(1-z)0.7
0.3
0.20
Error: too many connections
9 1
k
w
Tuesday, September 10, 13
An example
• Consider a flat reachability formula; e.g. R1• The result produced by WM is
14
f(k, w, x, y, z) = �.7w � y � .144375k + 1
+ .7yw � .7yxw + .144375zk
+ .144375yk + .7xw � .144375yzk
(1)
Tuesday, September 10, 13
Partial evaluation of a flat reachability formulaback to theory
Let T be a set of target absorbing statesWe need to evaluate
where B = N x R; N is the inverse of I - Q,
Matrix R is available, we need to compute NIn our context, N must be evaluated partially, i.e., by a
mix of numeric and symbolic processing
15
Pr(true U {sj 2 T}) =X
sj2T
b0j
P =
✓Q R0 I
◆(1)
Tuesday, September 10, 13
Design-time vs run-time costs
• Design-time computation expensive because of numeric/symbolic computations
• Complexity reduced by- sparsity- few symbolic transitions
- careful management of symbolic/numeric parts- parallel processing
• Run-time computation extremely efficient: polynomial formula for reachability, minor additional complications for full R-PCTL coverage (but still very efficient!)
16Tuesday, September 10, 13
Parametric vs conventional model checking
17Tuesday, September 10, 13
Conclusions
18
• Parametric model checking is a way to achieve incrementality
• Works when changes can be confined to only model parameters
• As expected, benefits increase as the delta is smaller
Tuesday, September 10, 13
Incrementality by composition: assume-guarantee
19
• We show that component M1 guarantees property P1 assuming that component M2 delivers property P2, and vice versa
• Then that the system composed of M1 || M2 guarantees P1 and P2 unconditionallyText
C. Jones, 1983, TOSEM
<P2> M1 <P1> <P1> M2 <P2>
<TRUE> M1 || M2 <P1&P2>
<P> M <Q> asserts that if M is part of a system that satisfies P (P true for all behaviors of the composite) then the system also satisfies Q
Tuesday, September 10, 13
Benefits from modularity and encapsulation
20
• Grounded on seminal work of D. Parnas (1972)- Design for change ‣ changes must be anticipated and encapsulated
within modules- Contracts (B. Meyer 1992)‣ interface vs implementation
Tuesday, September 10, 13
Incrementality by alternative refinements• This is a particular case of incrementality-by-composition,
where the focus is on supporting alternative refinement
• A refinement point is a part of the system that is subject to alternative designs through possibly different refinements
• Given a global property PG that should be assured by a system, the goal is to compute the local property PL that should be associated with a refinement point, so that any refinement that satisfies PL makes the system satisfy PG
• When alternative refinements are evaluated, it is only necessary to prove that they satisfy the local property (i.e., the proof only applies to the refinement, not to the whole system)
• The approach fits an iterative, agile development
21C. Ghezzi, C. Menghi, A. M. Sharifloo, P, Spoletini, On requirements verification for model refinements, RE 2013
Tuesday, September 10, 13
Context 1: LTSs and CTL
• LTSs are extended to accommodate unspecified states, which are refined by an LTS with one initial and one final state
• The proof of property P for such LTS can yield true, false, or a proof obligation for the refinement
• If the obligation is fulfilled by the refinement, P holds for the whole LTS
22
Sharifloo, A.M., Spoletini, P.: Lover: Light-weight formal verification of adaptive systems at run time. Symposium on Formal Aspects of Component Software, LNCS 2012
Tuesday, September 10, 13
Incomplete LTS (ILTS)
• Set of states partitioned into regular and transparent states
- Transparent states represent components- Transparent states can be refined into an ILTS with one initial
and one final state
a b
c
b
a
a
c
bb
a
Tuesday, September 10, 13
Path-qCTL
• qCTL = qualitative CTL• Path-qCTL = qCTL + operator on a finite path • Its syntax is defined as
φ→ φ∧φ|¬φ|EφUφ|EGφ|p|EpGφ
- EpGφ = “There exists a path that reaches the final state for which φ always holds”
• Examples- φ1 = AF(crossing)
- φ2 = ¬E(¬permit U crossing)
|EpGφ
Tuesday, September 10, 13
Context 2: StateCharts
AGaVE: AGile Verification Environment
Verification technique - to check whether a specification satisfies a given property- to (automatically) generate sub-properties that the missing
components have to respect- implemented for StateCharts
C. Ghezzi, C. Menghi, A. M. Sharifloo, P, Spoletini, On requirements verification for model refinements, RE 2013
Tuesday, September 10, 13
Overview
26
C11
DeveloperYES
NO
Developer
C2C1
II. AN OVERVIEW ON THE APPROACH
In general, the design phase consists in a series of subse-quent refinement steps, that allows the designer to model thesystem starting from an high level of abstraction, in which ageneral structure of the model is given, to the a level ofdetail, that describes the behavior of all the componentsof the system. If a verification technique is used duringthe design, this incremental approach requires to verify thesystem every time a new component is specified or to applyan assume-guarantee method [?], that need the designerto add assumption to its system. Both the approach areinconvenient: the first can be extremely expensive in termsof time and the second can be unfeasible in this contextsince the different components are not know at each levelof refinement.
To cope with these limitations, we propose XXX, amethodology for supporting the design phase of complexsystems, by providing an analysis method that can be appliedincrementally while the model is built.
EG('1 ) '2)Outline• Incremental modeling consists in specifying systems
refining them with subsequent steps of refinement (ateach step the introduced components are unknown andnot detailed)
• Our proposal is an approach to incremental modelingand verifying systems. The approach consists on model-ing a level of abstraction identifying those componentsthat need to be further specified (transparent states).Then the model is checked with a modified modelchecking algorithm (LOVER) that check the modelagainst a property, generating the properties that thetransparent states must satisfied for the original prop-erty to be true in the model. This process is repeatedon the model of the transparent states (once theyare specified) against the properties generated in theprevious step. If the model contains transparent state,new constraints, that will be checked on the model,once it is specified.
• advantages from the modeling point of view (differentlevels of abstraction help to focus to the big picture butalso to the details) and from the verification point ofview (more efficient, no need to re-run the verificationon the flat model at each refinement)
• formalisms used: statechart and CTL (explain whystatechart is suitable for incremental verification)
• generalization: analogously to what happen for incre-mental modeling, when an adaptive systems is specifiedsome components are unknown and are known only atruntime
• further generalization: verification of statechart (hierar-chical state are seen as transparent and the verificationbecomes more efficient).
III. MODELING FORMALISMS
A. Statecharts
Statechart is a structured graphical formalism used todescribe reactive systems, such as communication protocols,digital control unit and aboard software systems. Statechartsextend finite state machines considering hierarchy, concur-rency, and communication, that allow the designer to modelcomplex systems in a more compact way. In particular,hierarchy is used to model the system at different level ofgranularity by redefining states through a (sub)statechart orthe composition of (sub)statecharts. Concurrency describesthe possible parallel behaviors of two or more statechartsrunning in parallel at the same time; such behaviors aresynchronized through communication.
In this paper, we consider the original definition of Stat-echarts which includes its most popular features, ignoringsome elements, such as time actions, history, special events(e.g., events generated when a state is entered or exited) andspecial actions (e.g., start action, history clear, deep clear)1.
Figure 1. Statechart example
B. Syntax
Given a set of atomic propositions AP , the two subsetsE and I partition it. They represent the environmental andinternal propositions, respectively. Intuitively, If a system isdefined over AP , E are propositions of which the truth valuecannot be controlled, while E are controlled. A condition c
over I is defined as c ! i | ¬c | c ^ c, while anaction a has the form a ! i = 0 | i = 1 | neg(i),where i 2 I and neg is an operator that negate the truthvalue of i. C and A are a fine set of conditions and ofactions over I , respectively. Formally, a statechart is a tupleS = hQ,Q0, St, ⇢,E ,C ,A, ⌧i, where
• Q is a finite set of states that can be themselvesStatecharts, often call chart-states [9];
• ⇢
2 is the hierarchical relation, used to decompose statesinto sub-states;
1[Paola: because . . .]2[Paola: Ho do you define it? ✓ Q ⇥ }(S)? How the relation specify
the kind of hierarchy? Moreover the set of sub charts should be part of thetuple... am I wrong?]
Original property P
First Model
Derived propertiesDerived properties
……..
Level%1%
Level%2%
Tuesday, September 10, 13
The Verification Algorithm
Resulte1[c1]|a1 e2[c2]|a2
e3[c3]|a3
e4[c4]|a4
S2
S2¬open,
approaching
¬open,approaching
open,approaching
open,traveling
open,traveling ¬open,
approaching
¬open,crossing
¬open,traveling
Translate)Statecharts)in)ILTS)
CHECK(M, φ)
Model&Check+ILTS+
Result'
Derived'Proper+es'
Developere1[c1]|a1 e2[c2]|a2
e3[c3]|a3
e4[c4]|a4
CHECK(M’,φ’)
Update'Results'
φ’'φ'’'…’'
e1[c1]|a1 e2[c2]|a2e3[c3]|a3
e4[c4]|a4
S2
S2¬open,
approaching
¬open,approaching
open,approaching
open,traveling
open,traveling ¬open,
approaching
¬open,crossing
¬open,traveling
Translate)Statecharts)in)ILTS)
Tuesday, September 10, 13