Laser 3-incremental


Published on

Third lecture at the LASER Summer School, Elba Island, Sept. 2013

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Laser 3-incremental

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. Parametric vs conventional model checking 17 Tuesday, September 10, 13
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 φ’'φ'’' …’'