The document discusses incrementality in model checking for self-adaptive systems. It proposes an approach called parametric model checking which treats changing parts of a system as unknown parameters. At design time, model checking is done parametrically to produce verification results dependent on parameter values. At run time, monitoring provides actual parameter values, allowing efficient re-evaluation of verification results. This approach aims to make model checking more incremental by localizing the impact of changes. The document also discusses other techniques for achieving incrementality, such as assume-guarantee reasoning and handling alternative refinements.

1. Development of dynamically evolving and
self-adaptive software
4. Incrementality
LASER 2013
Isola d’Elba, September 2013
Carlo Ghezzi
Politecnico di Milano
Deep-SE Group @ DEIB
1
Tuesday, September 10, 13

2. Lifecycle of self-adaptive systems
Reqs
0
Specification
Implementation
Development time
Run time
1
E
Reasoning
Self-adaptation
Monitoring
Specification
Execution
Env
2
Tuesday, September 10, 13

3. The problem
• 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
3
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!
4
Tuesday, September 10, 13

5. The quest for incrementality
Incremental verification
Given 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
5
Tuesday, September 10, 13

6. 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
6
Tuesday, September 10, 13

7. Incrementality by parameterization
m
g
i
d
a
r
a
p
m st r
o ir
m k f ate
g o
l
in Co up
k
r
o
m
W
r
a
W
• 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
Tuesday, September 10, 13

8. Run-Time
(online)
Design-Time
(offline)
Working mom paradigm
Partial
evaluation
0
1
E
Parameter
values
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"
8
Tuesday, September 10, 13

9. An example
r = Pr(◊ s = 5) > r
0.85 − 0.85⋅ x + 0.15⋅ z − 0.15⋅ x ⋅ z − y ⋅ x
r=
0.85 + 0.15⋅ z
9
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 runtime verification
- symbolic matrix multiplications, but very sparse
and normally only few variables
10
Tuesday, September 10, 13

11. An example
(s3, s4) (s5, s6) model the cache hit probability,
a dynamic content has the current distribution of user requests
a static content been requested that requires ad-hoc processing
which depends probability of an HTTP self-redirect
on has been requested
Application
Server
Data Cache
Server
Database
Server
Web Server
Http Proxy
Server
0
0.7
2
0.20
0.12/0
(1-y)*0.3
0/0
0.1/0
6
0.15/
0.07
0.3
z
0.25
(1-y)*0.7
y
(1-z)
0.1/0
0.55
1
5
(1-k)
k
x
7
1
0.05/0
Http 503 Server
Unavailable
4
3
Cache
Server
(1-x)
(1-w)
0.12/
0.04
File Server
8
9
1
w
Http
Response
Error: too many
connections
Rewards: AverageCost/AverageLatency
11
Tuesday, September 10, 13
1

12. Matrix representation
0 0
B 0
B 0
B 0
Q=B 0
B
B 0
@
0
0
Transient-to-transient
(1
y)0.3
0.2
0
0
0
0
0
0
0
0.55
0
0
0
0
0
0
0
B
B
B
R=B
B
@
Transient-to-absorbing
y
0
0
0
0
0
0
(1
y)0.7
0
0
0
0
0
0
0
0
0.25
0.3
x
1 w
z
1 k
0
0
0
0
w
0
k
0
0
0
1
x
0
0
0
0
1
C
C
C
C
C
A
0
0
0.7
0
0
0
0
0
1
0
0
0
0
0
0
1
z
0
C
C
C
C
C
C
A
(1)
(2)
12
Tuesday, September 10, 13

13. ID
R1
R2
R3
R4
R5
R6
Table 1: Requirements R1-R6.
Informal Definition
PCTL
(Reliability): “The probabil- P 0.999 (⌃ s = s8 )
ity of successfully handling a
request must be greater than
0.999”
(Cache hit probability): “At P 0.8 (¬(s = s4 )^
least 80% of the requests ¬(s = s6 ) U s =
are correctly handled with- s8 )
out accessing the database or
the file server”
(Complexity bound ): “70% P 0.7 (⌃5 s =
of the requests must be suc- s8 )
cessfully processed within 5
operations”
(Early risk fingering): “No P0.1 (⌃ P 0.95 ( ⌃s =
more than 10% of the runs s7 _ s = s9 ))
can reach a state from which
the risk of eventually raising
an exception is greater than
0.95”
(Cost): “The average cost R0.03 (⌃ s = s7 _
for handling a request must s = s8 _ s = s9 )
be less .03 · 10 2 dollars”
(Response time): “The av- R0.022 (⌃ s =
erage response time must be s7 _ s = s8 _ s =
s9 )
less than 0.022 seconds”
13
Tuesday, September 10, 13
Application
Server
Data Cache
Server
Database
Server
Web Server
Http Proxy
Server
0
0.7
2
0.20
0.12/0
(1-y)*0.3
0/0
0.1/0
y
6
0.15/
0.07
0.3
z
0.25
(1-y)*0.7
(1-z)
0.1/0
0.55
1
5
(1-k)
k
x
7
1
0.05/0
Http 503 Server
Unavailable
4
3
Cache
Server
(1-x)
(1-w)
0.12/
0.04
File Server
8
1
9
1
w
Http
Response
Error: too many
connections

14. An example
• Consider a flat reachability formula; e.g. R1
• The result produced by WM is
f (k, w, x, y, z) =
.7w
+ .7yw
y
.144375k + 1
.7yxw + .144375zk
+ .144375yk + .7xw
.144375yzk
14
Tuesday, September 10, 13

15. Partial evaluation of a flat reachability formula
back to theory
Let T be a set of target absorbing states
We need to evaluate
Pr(true U {sj 2 T }) =
X
sj 2T
b0j
where B = N x R; N is the inverse of I - Q, P =
✓
Q
0
Matrix R is available, we need to compute N
In our context, N must be evaluated partially, i.e., by a
mix of numeric and symbolic processing
15
Tuesday, September 10, 13
R
I
◆

16. 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!)
16
Tuesday, September 10, 13

17. Parametric vs conventional model
checking
17
Tuesday, September 10, 13

18. Conclusions
• 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
18
Tuesday, September 10, 13

19. Incrementality by composition:
assume-guarantee
• 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
Text
guarantees P1 and P2 unconditionally
<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
C. Jones, 1983, TOSEM
19
Tuesday, September 10, 13

20. Benefits from modularity and
encapsulation
• 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
20
Tuesday, September 10, 13

21. 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
C. Ghezzi, C. Menghi, A. M. Sharifloo, P, Spoletini, On requirements verification for model refinements, RE 2013
21
Tuesday, September 10, 13

22. 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
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
22

23. 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
ac
a
a b
Tuesday, September 10, 13
c
b
a b
b

24. Path-qCTL
• qCTL = qualitative CTL
• Path-qCTL = qCTL + operator on a finite path
• Its syntax is defined as
φ→ φ∧φ|¬φ|EφUφ|EGφ|p|EpGφ
|EpGφ
- EpGφ = “There exists a path that reaches the final state for
which φ always holds”
• Examples
- φ1 = AF(crossing)
- φ2 = ¬E(¬permit U crossing)
Tuesday, September 10, 13

25. 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

26. an assume-guarantee method [?], that need the designer
to add assumption to its system. Both the approach are
inconvenient: the first can be extremely expensive in terms
of time and the second can be unfeasible in this context
since the different components are not know at each level
of refinement.
To cope with these limitations, we propose XXX, a
methodology for supporting the design phase of complex
systems, by providing an analysis method that can be applied
Original property P model is built.
incrementally while the
EG('1 ) '2 )
Outline
• Incremental modeling consists in specifying systems
refining them with subsequent steps of refinement (at
each step the introduced components are unknown and
not detailed)
• Our proposal is an approach to incremental modeling
and verifying systems. The approach consists on modelC1
C2
ing a level of abstraction identifying those components
that need to be further specified (transparent states).
Then the model is checked with a modified model
First Modelalgorithm (LOVER) that check the model
checking
against a property, generating the properties that the
transparent states must satisfied for the original property to be true in the model. This process is repeated
on the model of the transparent states (once they
are specified) Derived the properties generated in the
against properties
previous step. If the model contains Developer state,
transparent
Developer
new constraints, that will be checked on the model,
Cspecified.
once it is 11
• advantages from the modeling point of view (different
levels of abstraction help to focus to the big picture but
also to the details) and from the verification point of
view (more efficient, no need to re-run the verification
on the flat model at each refinement)
……..
• formalisms used: statechart and CTL (explain why
statechart is suitable for incremental verification)
• generalization: analogously to what happen for incremental modeling, when an adaptive systems is specified
some components are unknown and are known only at
runtime
• further generalization: verification of statechart (hierarTuesday, September 10, 13
Overview
granularity by redefining states through a (sub)statechart or
the composition of (sub)statecharts. Concurrency describes
the possible parallel behaviors of two or more statecharts
running in parallel at the same time; such behaviors are
synchronized through communication.
In this paper, we consider the original definition of Statecharts which includes its most popular features, ignoring
some elements, such as time actions, history, special events
(e.g., events generated when a state is entered or exited) and
special actions (e.g., start action, history clear, deep clear)1 .
Level%1%
Figure 1.
Statechart example
B. Syntax
Given a set of atomic propositions AP , the two subsets
Derived properties
E and I partition it. They represent the environmental and
internal propositions, respectively. Intuitively, If a system is
defined over AP , E are YES
propositions of which the truth value
cannot be controlled, while E are controlled. A condition c
over I is defined as c ! i | ¬c | c ^ c, while an
action a has the form aNO i = 0 | i = 1 | neg(i),
!
where i 2 I and neg is an operator that negate the truth
value of i. C and A are a fine set of conditions and of
actions over I, respectively. Formally, a statechart is a tuple
S = hQ, Q0 , St, ⇢, E , C , A, ⌧ i, where
• Q is a finite set of states that can be themselves
Statecharts, often call chart-states [9];
2
• ⇢ is the hierarchical relation, used to decompose states
into sub-states;
26
Level%2%
1 [Paola:
because . . .]

27. The Verification Algorithm
CHECK(M, φ)
open,
traveling
e4[c4]|a4
e4[c4]|a4
e3[c3]|a3
e1[c1]|a1
e3[c3]|a3
e2[c2]|a2
e1[c1]|a1
e2[c2]|a2
open,
traveling
open,
traveling
¬open,
approaching
¬open,
open,
traveling
open,
¬open,
¬open,
approaching open, approaching
approaching
approaching
S2
S2
S2
approaching
S2
¬open,
¬open,
crossing
crossing
¬open,
¬open,
traveling
Result
Result'
traveling
¬open,
¬open,
approaching
approaching
Translate)Statecharts)in)ILTS)
Translate)Statecharts)in)ILTS)
Model&Check+ILTS+
Derived'
Proper+es'
CHECK(M’,φ’)
Developer
e4[c4]|a4
e3[c3]|a3
e1[c1]|a1
e2[c2]|a2
Update'Results'
Tuesday, September 10, 13
φ’'φ'’'
…’'