Your SlideShare is downloading.
×

×
Saving this for later?
Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.

Text the download link to your phone

Standard text messaging rates apply

Like this presentation? Why not share!

- Laser 0-prologue by Carlo Ghezzi 122 views
- PowerPoint Presentation - Iterative... by Softwarecentral 1705 views
- Scrum an iterative and incremental... by Ashish Agrawal 147 views
- Unique features of windows 8 by FITC 619 views
- Agile Project Management by Samuel90 628 views
- Software Development – Traditional ... by Faiza Yousuf 3780 views
- ICSE 2009 keynote by Carlo Ghezzi 321 views
- Introduction to Agile Project Manag... by Samuel90 3933 views
- Software Requirements for Safety-re... by Vittorio Giovara 3308 views
- Iterative Incremental development by Oliver Schreck 2083 views
- Agile Project Management for IT Pro... by rachna_nainani 4748 views
- Laser 2-change by Carlo Ghezzi 91 views

Like this? Share it with your network
Share

131

Published on

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

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

Published in:
Technology

No Downloads

Total Views

131

On Slideshare

0

From Embeds

0

Number of Embeds

0

Shares

0

Downloads

8

Comments

0

Likes

1

No embeds

No notes for slide

- 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 Speciﬁcation Implementation Development time Run time 1 E Reasoning Self-adaptation Monitoring Speciﬁcation Execution Env 2 Tuesday, September 10, 13
- 3. 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 Tuesday, September 10, 13
- 4. The problem • Veriﬁcation needs to work at run-time to support self-adaptive reactions • Veriﬁcation 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 speciﬁcation • 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 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 Tuesday, September 10, 13
- 6. 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 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 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 Tuesday, September 10, 13
- 8. Run-Time (online) Design-Time (ofﬂine) 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 efﬁcient probabilistic model checking” [FormSERA 2012] A. Filieri, C. Ghezzi, "Further steps towards efﬁcient runtime veriﬁcation: 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 veriﬁcation - 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 Deﬁnition 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 ﬁle server” (Complexity bound ): “70% P 0.7 (⌃5 s = of the requests must be suc- s8 ) cessfully processed within 5 operations” (Early risk ﬁngering): “No P0.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 R0.03 (⌃ s = s7 _ for handling a request must s = s8 _ s = s9 ) be less .03 · 10 2 dollars” (Response time): “The av- R0.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 ﬂ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 Tuesday, September 10, 13
- 15. 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 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 efﬁcient: polynomial formula for reachability, minor additional complications for full R-PCTL coverage (but still very efﬁcient!) 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 conﬁned to only model parameters As expected, beneﬁts 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 satisﬁes P (P true for all behaviors of the composite) then the system also satisﬁes Q C. Jones, 1983, TOSEM 19 Tuesday, September 10, 13
- 20. 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 Tuesday, September 10, 13
- 21. Incrementality by alternative reﬁnements • • • • • This is a particular case of incrementality-by-composition, where the focus is on supporting alternative reﬁnement A reﬁnement point is a part of the system that is subject to alternative designs through possibly different reﬁnements 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 reﬁnement point, so that any reﬁnement that satisﬁes PL makes the system satisfy PG When alternative reﬁnements are evaluated, it is only necessary to prove that they satisfy the local property (i.e., the proof only applies to the reﬁnement, not to the whole system) The approach ﬁts an iterative, agile development C. Ghezzi, C. Menghi, A. M. Shariﬂoo, P, Spoletini, On requirements veriﬁcation for model reﬁnements, RE 2013 21 Tuesday, September 10, 13
- 22. Context 1: LTSs and CTL • • • LTSs are extended to accommodate unspeciﬁed states, which are reﬁned by an LTS with one initial and one ﬁnal state The proof of property P for such LTS can yield true, false, or a proof obligation for the reﬁnement If the obligation is fulﬁlled by the reﬁnement, P holds for the whole LTS Shariﬂoo, A.M., Spoletini, P.: Lover: Light-weight formal veriﬁcation 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 reﬁned into an ILTS with one initial and one ﬁnal 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 ﬁnite path • Its syntax is deﬁned as φ→ φ∧φ|¬φ|EφUφ|EGφ|p|EpGφ |EpGφ - EpGφ = “There exists a path that reaches the ﬁnal state for which φ always holds” • Examples - φ1 = AF(crossing) - φ2 = ¬E(¬permit U crossing) Tuesday, September 10, 13
- 25. Context 2: StateCharts AGaVE: AGile Veriﬁcation Environment Veriﬁcation technique - to check whether a speciﬁcation satisﬁes a given property - to (automatically) generate sub-properties that the missing components have to respect - implemented for StateCharts C. Ghezzi, C. Menghi, A. M. Shariﬂoo, P, Spoletini, On requirements veriﬁcation for model reﬁnements, 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 ﬁrst 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 reﬁnement. 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 reﬁning them with subsequent steps of reﬁnement (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 speciﬁed (transparent states). Then the model is checked with a modiﬁed model First Modelalgorithm (LOVER) that check the model checking against a property, generating the properties that the transparent states must satisﬁed for the original property to be true in the model. This process is repeated on the model of the transparent states (once they are speciﬁed) 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, Cspeciﬁed. 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 veriﬁcation point of view (more efﬁcient, no need to re-run the veriﬁcation on the ﬂat model at each reﬁnement) …….. • formalisms used: statechart and CTL (explain why statechart is suitable for incremental veriﬁcation) • generalization: analogously to what happen for incremental modeling, when an adaptive systems is speciﬁed some components are unknown and are known only at runtime • further generalization: veriﬁcation of statechart (hierarTuesday, September 10, 13 Overview granularity by redeﬁning 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 deﬁnition 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 deﬁned over AP , E are YES propositions of which the truth value cannot be controlled, while E are controlled. A condition c over I is deﬁned 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 ﬁne 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 ﬁnite 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 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' Tuesday, September 10, 13 φ’'φ'’' …’'

Be the first to comment