Development of dynamically evolving and self-adaptive software. 4. Incrementality

Transcription

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 DEIB 1

2 Lifecycle of self-adaptive systems Reqs 0 Specification 1 E Reasoning Implementation Development time Self-adaptation Specification Monitoring Run time Execution Env 2

3 The problem Verification needs to work at run-time to support selfadaptive reactions It may be subject to strict response time requirements to support timely reactions Current mainstream approaches do not fit this requirement 3

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

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

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

7 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 Working mom paradigm Cook first Warm-up later symbolic parameters and is very efficient 7

8 Working mom paradigm Design-Time (offline) 1 0 E Partial evaluation Run-Time (online) 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

9 An example r = Pr( s = 5) > r r = x z 0.15 x z y x z 9

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

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

12 Matrix representation Q = 0 0 (1 y)0.3 0 (1 y) x z R = Transient-to-absorbing Transient-to-transient 0 y x w w 0 z k k 1 C A 1 C A (1) (2) 12

13 Table 1: Requirements R1-R6. ID Informal Definition PCTL R1 R2 (Reliability): The probability of successfully handling a request must be greater than (Cache hit probability): At least 80% of the requests are correctly handled without accessing the database or the file server R3 (Complexity bound): 70% of the requests must be successfully processed within 5 operations 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 R5 (Cost): The average cost for handling a request must be less dollars R6 (Response time): The average response time must be less than seconds P ( s = s 8 ) P 0.8 ( (s = s 4 )^ (s = s 6 ) U s = s 8 ) P 0.7 ( apple5 s = s 8 ) P apple0.1 ( P 0.95 ( s = s 7 _ s = s 9 )) R apple0.03 ( s = s 7 _ s = s 8 _ s = s 9 ) R apple0.022 ( s = s 7 _ s = s 8 _ s = s 9 ) 13 Http Proxy Server 0 0/0 y 7 Http 503 Server Unavailable (1-y)*0.3 1 (1-y)*0.7 Web Server / /0 Cache Server x 0.55 (1-x) Application Server / / 0.04 File Server (1-w) w Data Cache Server 5 0.1/0 z 8 1 Http Response (1-z) (1-k) Database Server / 0.07 k 9 1 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 y k yw.7yxw zk yk +.7xw yzk 14

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 {s j 2 T }) = X s j 2T b 0j where B = N x R; N is the inverse of I - Q, P = Q R 0 I 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

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

17 Parametric vs conventional model checking 17

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

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

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

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

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

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 a c a c a b 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φ E p G - E p Gφ = There exists a path that reaches the final state for which φ always holds Examples - φ 1 = AF(crossing) - φ 2 = E( permit U crossing)

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

26 Overview Original property P crementally whi EG(' 1 ) ' 2 ) Outline Level%1% C 1 C 2 First Model Developer C 11 Derived properties Developer Derived properties YES Level%2% NO.. 26

27 The Verification Algorithm CHECK(M, φ) e 4 [c 4 ] a 4 e 4 [c 4 ] a 4 open, traveling open, traveling open, traveling open, traveling open, approaching open, approaching e 3 [c 3 ] a 3 e 1 [c 1 ] a 1 e e 2 [c 1 [c 2 ] a 1 ] a 2 1 e 2 [c 2 ] a 2 e 3 [c 3 ] a 3 open, open, open, open, approaching open, approaching approaching S2 open, approaching S2 crossing crossing open, open, S2 S2 approaching approaching open, traveling open, traveling Result Result' Translate)Statecharts)in)ILTS) Translate)Statecharts)in)ILTS) Model&Check+ILTS+ Derived' Proper+es' Developer e 4 [c 4 ] a 4 CHECK(M,φ ) φ 'φ' ' ' e 1 [c 1 ] a 1 e 2 [c 2 ] a 2 e 3 [c 3 ] a 3 Update'Results'