Laser 3-incremental

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

Lifecycle of self-adaptive systems
Reqs

0

Speciﬁcation

Implementation
Development time
Run time

1

E

Reasoning

Self-adaptation

Monitoring

Speciﬁcation
Execution
Env
2


The problem
• Veriﬁcation 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 ﬁt this
requirement

3

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

The quest for incrementality
Incremental veriﬁcation
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 efﬁcient to perform

5

An approach

• Incrementality by parameterization
-

We treat what can change as an unknown parameter
Veriﬁcation 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

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 veriﬁcation 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 efﬁcient

7

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

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

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 veriﬁcation
- symbolic matrix multiplications, but very sparse
and normally only few variables

10

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

1

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

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


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

An example
• Consider a ﬂat 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

Partial evaluation of a ﬂat 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

R
I

◆

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 efﬁcient: polynomial
formula for reachability, minor additional
complications for full R-PCTL coverage (but still
very efﬁcient!)
16


Parametric vs conventional model
checking

17

Conclusions
• Parametric model checking is a way to achieve
•
•

incrementality
Works when changes can be conﬁned to only
model parameters
As expected, beneﬁts increase as the delta is
smaller

18

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 satisﬁes P (P true
for all behaviors of the composite) then the system also satisﬁes Q
C. Jones, 1983, TOSEM
19

Beneﬁts 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

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


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

22

Incomplete LTS (ILTS)
• Set of states partitioned into regular and transparent
states
- Transparent states represent components
- Transparent states can be reﬁned into an ILTS with one initial
and one ﬁnal state
ac

a

a b


c

b

a b

b

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)


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

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

The Veriﬁcation 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'


φ’'φ'’'
…’'

Laser 3-incremental

More Related Content

Similar to Laser 3-incremental (20)

Recently uploaded (20)

Laser 3-incremental