laser 3-incremental

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


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


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!


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


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


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"


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


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


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


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


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


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)


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)


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!)


Parametric vs conventional model checking


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


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


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


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


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


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


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φ


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


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%


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)


laser 3-incremental

Technology

s change

proof of s

requests s

b b b r

system model s

c c c c c c a1212

c c c c c a0

s6 u s