Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

- Chasing Bugs with the BeepBeep Even... by Sylvain Hallé 193 views
- Decentralized Enforcement of Artifa... by Sylvain Hallé 333 views
- Solving Equations on Words with Mor... by Sylvain Hallé 156 views
- A Runtime Monitoring Framework for ... by Sylvain Hallé 1004 views
- A formalization of complex event st... by Sylvain Hallé 741 views
- Portable runtime verification with ... by Sylvain Hallé 515 views

850 views

Published on

No Downloads

Total views

850

On SlideShare

0

From Embeds

0

Number of Embeds

20

Shares

0

Downloads

8

Comments

0

Likes

1

No embeds

No notes for slide

- 1. Sylvain Hallé
- 2. A lighthearted introductionSylvain Hallé 2
- 3. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’Sylvain Hallé 2
- 4. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ MovesSylvain Hallé 2
- 5. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
- 6. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ and O mu st alternate Moves 1. X symbols n’t put two . 2. Ca in sa me square must be ually, there . 3. Event Rules a line of three O’sSylvain Hallé 2
- 7. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
- 8. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
- 9. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
- 10. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves RulesSylvain Hallé 2
- 11. A lighthearted introduction Player ‘‘O’’ Player ‘‘X’’ Moves Rules GameSylvain Hallé 2
- 12. A lighthearted introduction ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
- 13. A lighthearted introduction Move ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
- 14. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
- 15. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> Interface contract ‘‘O’’ web service ‘‘X’’ web serviceSylvain Hallé 3
- 16. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> Interface contract ‘‘O’’ web service ‘‘X’’ web service GameSylvain Hallé 3
- 17. A lighthearted introduction <Move> Message <Player>X</Player> <Row>1</Row> <Col>A</Col> </Move> Interface contract ‘‘O’’ web service ‘‘X’’ web service TransactionSylvain Hallé 3
- 18. A more serious example Shop service Each has its own requirements on the course of a transaction Customer serviceSylvain Hallé 4
- 19. A more serious example S1. All carts with more than three items are labelled ‘‘large’’ and must be paid by credit . S2. Every cart created must be cbecked out . S3. Payment mode must be only one of ‘‘Credit’’ or ‘‘PayPal’’ C1. A cart created with a mode of payment must be checked out with the same mode of payment Interface contract = ‘‘sum’’ (i.e. logical conjunction) of individual requirementsSylvain Hallé 5
- 20. Formalizing interface contracts The service’s behaviour follows constraints on... 1. Sequences of operations only 2. Parameter values only 3. Both at the same time LTL-FO+: extension of LTL with quantifiers on message parameters (Hallé & Villemaire, EDOC 2008)Sylvain Hallé 6
- 21. Formalizing interface contracts LTL formula = assertion on a trace (of messages) Ga "always a" Xa "the next message is a" Fa "eventually a" aWb "a until b abacdcbaqqtam... G (a ® X b) FALSE Ø (q Ú t) W c TRUE But what about data contents?Sylvain Hallé 7
- 22. Formalizing interface contracts What if symbols are XML documents? LTL-FO+ = LTL + first-order quantification on elements Let... p = argument of a function f... filters acceptable values for x... according to the current message s0 s |= $p x : j(x) Û $k : s |= j(k) AND k Îf(s0,p)Sylvain Hallé 8
- 23. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/bSylvain Hallé 9
- 24. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 XPath expression p = a/bSylvain Hallé 9
- 25. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s0,p) =Sylvain Hallé 9
- 26. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s0,p) = {1,2}Sylvain Hallé 9
- 27. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s1,p) =Sylvain Hallé 9
- 28. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 p = a/b f(s1,p) = {}Sylvain Hallé 9
- 29. LTL-FO+ Example: <d> <a> <e>1</e> <b>1</b> <e>2</e> s= <b>2</b> </a> </d> <c>5</c> <c>5</c> <c>6</c> s0 s1 TRUE "a/b x : x=1 Ú x=2 TRUE "c x : x=5 FALSE G "c x : x=5 TRUE "c x : F $ c y : x=ySylvain Hallé 9
- 30. LTL-FO+ ‘‘X and O must alternate’’Sylvain Hallé 10
- 31. LTL-FO+ ‘‘X and O must alternate’’ G( )Sylvain Hallé 10
- 32. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X (" p’ : p=p’))Sylvain Hallé 10
- 33. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X (" p’ : p=p’))Sylvain Hallé 10
- 34. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X ("Move/Player p’ : p=p’))Sylvain Hallé 10
- 35. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X ("Move/Player p’ : p=p’)) /Sylvain Hallé 10
- 36. LTL-FO+ ‘‘X and O must alternate’’ G ("Move/Player p : X ("Move/Player p’ : p=p’)) / A trace of messages m that satisfies an interface contract j is noted m jSylvain Hallé 10
- 37. Contract compliance If m / j , whose fault is it? who·dun·it A whodunit (for "Who[s] done it?") is a complex, plot-driven variety of the detective story in which the puzzle is the main feature of interest. The reader is provided with clues from which the identity of the perpetrator of the crime may be deduced before the solution is revealed in the final pages of the book. (Wikipedia)Sylvain Hallé 11
- 38. Contract compliance If m / j , whose fault is it? who·dun·it A whodunit (for "Who[s] done it?") is a complex, plot-driven variety of the detective story in which the puzzle is the main feature of interest. The reader is provided with clues from which the identity of the perpetrator of the crime may be deduced before the solution is revealed in the final pages of the book. (Wikipedia)Sylvain Hallé 11
- 39. Contract compliance Applications: Which component does not implement the standard correctly? Which component should compensate the others for the violation? At runtime: which component should take a different action to avoid a violation?Sylvain Hallé 12
- 40. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / jSylvain Hallé 13
- 41. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / jSylvain Hallé 13
- 42. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j XSylvain Hallé 13
- 43. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j X X OSylvain Hallé 13
- 44. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j X X X O O XSylvain Hallé 13
- 45. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j X X X O O XSylvain Hallé 13
- 46. Direct violation A message m is a direct violation for a trace m if: . · m j and · . X and/ O mu st alternate 1 m .m j symbols n’t put two . 2. Ca in sa me square must be ually, there . 3. Event a line of three O’s X X X O O XSylvain Hallé 13
- 47. Direct violation A message m is a direct violation for a trace m if: . · m j and · m .m / j Hypothesis #1 The sender of m is responsible for the contract violation X X X O O XSylvain Hallé 13
- 48. Direct violation A message m is a direct violation for a trace m if: . · m j and WAN TED · m .m / j Hypothesis #1 The sender of m is responsible for the contract violation r ‘‘O’’ Playe g the for violatin ntract int erface co X X X O O XSylvain Hallé 13
- 49. Direct violation Another example: X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 14
- 50. Direct violation Another example: X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 14
- 51. Direct violation Another example: and O mu st alternate 1. X ls X o symbo n’t put tw . X X 2. Ca O O X in sa me square must be ually, there . 3. EveX tO n a li reeOO’s ne of th X O X X O X X O O X X O X O X O X O X X O X O OX X OSylvain Hallé 14
- 52. Direct violation Another example: X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 14
- 53. Direct violation Another example: WANTED X X X O O X X O X O X O X O X O X O X O X O X X X O X O Player ‘‘ X’’ for violating the interface contrac X O X t O OX X OSylvain Hallé 14
- 54. Root violation A message m is a root violation for a trace m if: . · m j and · for any (infinite) suffix m’, we have m.m.m’ / jSylvain Hallé 15
- 55. Root violation A message m is a root violation for a trace m if: . · m j and · for any (infinite) suffix m’, we have m.m.m’ / j Hypothesis #2: The sender of m is responsible for the contract violationSylvain Hallé 15
- 56. Root violation X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 16
- 57. Root violation X X X O O X X O X O X O X O X O X O X O X O X X X O X O X O X O OX X OSylvain Hallé 16
- 58. Root violation WANTED X X X O O X X O X O X O X O X O X O X O X O X X X O X O Player ‘‘O’’ for violating the interface contrac X O X t O OX X OSylvain Hallé 16
- 59. ObservationsSylvain Hallé 17
- 60. Observations 1. Root violations capture the fact that direct violations are sometimes the result of a sequence of ‘‘forced moves’’ X O X O X O X O X X O X O X O X O X O X O OX X X O X O X OSylvain Hallé 17
- 61. Observations 1. Root violations capture the fact that direct violations are sometimes the result of a sequence of ‘‘forced moves’’ X O X O X O X O X X O X O X O X O X O X O OX X X O X O X O . WANTED WANTED 2. The faulty peer may not be the same vs. as in an ensuing direct violationSylvain Hallé 17
- 62. Observations 1. Root violations capture the fact that direct violations are sometimes the result of a sequence of ‘‘forced moves’’ X O X O X O X O X X O X O X O X O X O X O OX X X O X O X O . WANTED WANTED 2. The faulty peer may not be the same vs. as in an ensuing direct violation . 3. The interface contract is not contradictory in itself: a root violation depends on the actual course of actions takenSylvain Hallé 17
- 63. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTLSylvain Hallé 18
- 64. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j a b a b b aSylvain Hallé 18
- 65. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) a b a b b aSylvain Hallé 18
- 66. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M . a b a b b aSylvain Hallé 18
- 67. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M . a b a b m=a a bSylvain Hallé 18
- 68. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M . a b a b m=ab a bSylvain Hallé 18
- 69. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M: discard any pointer to . a b a b m=ab a bSylvain Hallé 18
- 70. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M: discard any pointer to . a b a b m=aba a bSylvain Hallé 18
- 71. How to find root violations? Solution #1 Bauer et al. (RV 2007): anticipatory semantics for LTL 1. Create the Büchi automaton M equivalent to j . 2. Label each state based on language emptiness ( ) or not ( ) . 3. Read m by keeping pointers to states of M: discard any pointer to . a b 4. A message is a root violation if a no pointer is left b m=aba a bSylvain Hallé 18
- 72. How to find root violations? Problem: · Designed for LTL a b a b b aSylvain Hallé 19
- 73. How to find root violations? Problem: · Designed for LTL . · With LTL-FO+, M is infinite a b a b b aSylvain Hallé 19
- 74. How to find root violations? Solution #2 Conversion to LTL 1. Bound the domains for each path expression . 2. Convert quantifiers into equivalent expressions If f(_, a/b) Í {1,2} , then "a/b x : F $ a/b y : x=y becomes ( F $ a/b y : 1=y ) Ù ( F $ a/b y : 2=y ) ...and so onSylvain Hallé 20
- 75. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checkerSylvain Hallé 20
- 76. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ?Sylvain Hallé 20
- 77. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ? m1 m2 j ?Sylvain Hallé 20
- 78. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ? m1 m2 j ? m1 m2 m3 j ?Sylvain Hallé 20
- 79. How to find root violations? Solution #2 Conversion to LTL 3. The formula is now pure LTL; use solution #1 OR 4. Send messages one by one to an LTL model checker m1 j ? m1 m2 j ? m1 m2 m3 j ? The first message that causes the validation to fail is a root violationSylvain Hallé 20
- 80. How to find root violations? Problem: · Requires bounded data domains · Exponential blow-up of formula · Non-incremental processSylvain Hallé 21
- 81. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic .Sylvain Hallé 22
- 82. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas sSylvain Hallé 22
- 83. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules sSylvain Hallé 22
- 84. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules s s’Sylvain Hallé 22
- 85. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules 3. Compute an outcome function on resulting state to decide if contract is violated s s’Sylvain Hallé 22
- 86. Proposed solution Exploit an on-the-fly runtime monitoring algorithm for linear temporal logic . 1. Monitor state = set of LTL-FO+ formulas 2. Upon each new message: update state according to transformation rules 3. Compute an outcome function on resulting state to decide if contract is violated s’Sylvain Hallé 22
- 87. Runtime monitoring Algorithm overview: 1. An LTL formula is decomposed into nodes of the form sub-formulas that sub-formulas that must must be true now be true in the next state Example:Sylvain Hallé 23
- 88. Runtime monitoring 2. Negations pushed inside (classical identities + dual of U = V) 3. At the leaves, G contains atoms + negations of atoms: we evaluate them Verdict: ! All leaves contain FALSE: formula is false ! A leaf is empty: formula is true ! Otherwise: 4. Next event: D copied into G and we continueSylvain Hallé 24
- 89. Runtime monitoring Example: G (a ® X Øa)Sylvain Hallé 25
- 90. Runtime monitoring Example: G (a ® X Øa) G (a ® X Øa) ’ a ® X Øa ’ G (a ® X Øa) Øa ’ G (a ® X Øa) a, X Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), ØaSylvain Hallé 25
- 91. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), ØaSylvain Hallé 25
- 92. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 93. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 94. Runtime monitoring Example: G (a ® X Øa) a ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 95. Runtime monitoring Example: G (a ® X Øa) ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 96. Runtime monitoring Example: G (a ® X Øa) G (a ® X Øa), Øa ’ ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 97. Runtime monitoring Example: G (a ® X Øa) G (a ® X Øa), Øa ’ a ® X b, b ’ G (a ® X Øa) Øa ’ G (a ® X Øa) a, X Øa, Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 98. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 99. Runtime monitoring Example: G (a ® X Øa) A variable and its negation can never be true at the same time Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 100. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) a, Øa ’ G (a ® X Øa), Øa s=aSylvain Hallé 25
- 101. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) s=aSylvain Hallé 25
- 102. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) s = aaSylvain Hallé 25
- 103. Runtime monitoring Example: G (a ® X Øa) Øa ’ G (a ® X Øa) s = aaSylvain Hallé 25
- 104. Runtime monitoring Example: G (a ® X Øa) No way to extend the trace: formula is false, i.e. message c is a direct violation of the formula s = aaSylvain Hallé 25
- 105. Detecting direct violations By construction (Gerth et al., PSTV 1995): Let N = be a monitor node resulting from the processing of a message m. The message is a direct violation of the conditions in N if and only if it contains p Ù Øp for some proposition p.Sylvain Hallé 26
- 106. Detecting direct violations By construction (Gerth et al., PSTV 1995): Let N = be a monitor node resulting from the processing of a message m. The message is a direct violation of the conditions in N if and only if it contains p Ù Øp for some proposition p. Consequence m is a direct violation if this happens for all leaf nodesSylvain Hallé 26
- 107. Detecting root violations Theorem Let N = be a monitor node resulting from the processing of a message m. The message is a root violation of the conditions in N if and only if the formula ( Ù G ) Ù X( Ù D ) is unsatisfiable. (See paper for the proof!)Sylvain Hallé 27
- 108. Detecting root violations Theorem Let N = be a monitor node resulting from the processing of a message m. The message is a root violation of the conditions in N if and only if the formula ( Ù G ) Ù X( Ù D ) is unsatisfiable. (See paper for the proof!) Consequence m is a root violation if this happens for all leaf nodesSylvain Hallé 27
- 109. Intuition 1. In the algorithm, each leaf node represents a possible set of conditions for a valid extension of the current trace sub-formulas that sub-formulas that must must be true now be true in the next state 2. If the conditions are contradictory, no trace extension can ever satisfy them . Ù 3. The formula p Ù Øp is a special case of ( G ) Ù X( Ù D), where the contradiction occurs in the current message . 4. Detection of root violations reduces to satisfiability solving of some set of LTL formulasSylvain Hallé 28
- 110. Adding first-order quantifiers Decomposition rules can be added to deal with LTL-FO+; the definition of root violation does not change 1. Atoms become equality tests (and vice versa) 2. Decomposition rules for quantifiersSylvain Hallé 29
- 111. A workflow for root violation detectionSylvain Hallé 30
- 112. A workflow for root violation detection 1 1 ... n n } Leaf nodes from current monitor stateSylvain Hallé 30
- 113. A workflow for root violation detection 1 1 ... n n } m Incoming messageSylvain Hallé 30
- 114. A workflow for root violation detection 1 1 ... n n } m UPDATE Monitor update functionSylvain Hallé 30
- 115. A workflow for root violation detection 1 1 ... n n } } 1 1 ... m UPDATE k k New leaf nodesSylvain Hallé 30
- 116. A workflow for root violation detection Node sent to LTL-FO+ 1 1 ... n n satisfiability solver } } 1 1 S ... m UPDATE k kSylvain Hallé 30
- 117. A workflow for root violation detection ... Kept if 1 1 n n satisfiable } } 1 1 S SAT 1 1 ... m UPDATE k kSylvain Hallé 30
- 118. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X Deleted if not k kSylvain Hallé 30
- 119. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X UNSAT k k S SAT k k Repeat for every nodeSylvain Hallé 30
- 120. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X UNSAT k k S SAT k k New monitor nodesSylvain Hallé 30
- 121. A workflow for root violation detection 1 1 ... n n } } 1 1 S UNSAT SAT 1 1 ... m UPDATE X UNSAT k k S SAT k k Declare root violation if no node remains after pruningSylvain Hallé 30
- 122. Experimental setup BeepBeep (Hallé & Villemaire, 2011) used as the LTL-FO+ runtime monitor TSPASS (Ludwig & Hustadt, 2010) used as the S temporal satisfiability solver 100 randomly-generated traces of shopping cart transactions Validation of the shopping cart contractSylvain Hallé 31
- 123. Experimental results Experiment 1: overhead incurred by use of a solver Solver time: 40 13 ms / message Number of traces 30 20 10 0 <1 1-2 2-3 3-4 >4 OverheadSylvain Hallé 32
- 124. Experimental results Experiment 2: difference (in messages) between root and direct violation 80 Number of traces 60 Violation detected ‘‘in advance’’: 18% 40 less messages consumed 20 0 0 1-5 6-10 11-15 16-20 Length differenceSylvain Hallé 33
- 125. Future work The concept of violation is a parameterized one: s s’Sylvain Hallé 34
- 126. Future work The concept of violation is a parameterized one: Call an error when the current trace cannot be extended by at least n suffixes with at least k messages s s’Sylvain Hallé 34
- 127. Future work The concept of violation is a parameterized one: k = ‘‘lookahead’’ n = ‘‘degree of freedom’’ Call an error when the current trace cannot be extended by at least n suffixes with at least k messages s s’Sylvain Hallé 34
- 128. Future work The concept of violation is a parameterized one: k = ‘‘lookahead’’ n = ‘‘degree of freedom’’ Call an error when · Direct violation the current trace cannot be extended by at least n=1, k=1 n suffixes with at least k messages s s’Sylvain Hallé 34
- 129. Future work The concept of violation is a parameterized one: k = ‘‘lookahead’’ n = ‘‘degree of freedom’’ Call an error when · Direct violation the current trace cannot be extended by at least n=1, k=1 n suffixes with at least k messages · Root cause s n=1, k=¥ s’Sylvain Hallé 34
- 130. Take-home points 1. The peer responsible for an interface contract violation may not cause it directly . 2. A root violation occurs when no infinite extension of the current transaction can ever fulfill an interface contract . 3. Using LTL-FO+ as the specification language, reduction to the propositional case results in an infinite search problem . 4. Leveraging on a runtime monitoring algorithm, root cause detection reduces to satisfiability solving . 5. An experimental setup can detect direct violations ahead of time with reasonable overheadSylvain Hallé 35

No public clipboards found for this slide

Be the first to comment