Interface contracts are sets of constraints specifying valid exchanges of messages between two or more peers. A contract violation occurs when one of the peers fails to fulfil one of these constraints and emits a message that is not a valid continuation of a message "trace". In some cases, the message that directly exposes the violation turns out to be the last of a succession of forced moves, while the "root cause" of the violation resides earlier in the trace and may emanate from a different peer. We formally define the notion of causality for interface contracts expressed in a first-order extension of Linear Temporal Logic. In particular, we show how the detection of root causes reduces to satisfiability solving of a precise set of formulæ. An experimental setup shows how causality can be analyzed automatically on a pre-recorded message trace.
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’s
Sylvain Hallé 2
14. A lighthearted introduction
<Move>
Message <Player>X</Player>
<Row>1</Row>
<Col>A</Col>
</Move>
‘‘O’’ web service
‘‘X’’ web service
Sylvain 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 service
Sylvain 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
Game
Sylvain 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
Transaction
Sylvain Hallé 3
18. A more serious example
Shop service
Each has its own requirements on the
course of a transaction Customer
service
Sylvain 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 requirements
Sylvain 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
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=y
Sylvain 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 j
Sylvain 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 / j
Sylvain Hallé 13
41. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
Sylvain Hallé 13
42. Direct violation
A message m is a direct violation for a trace m if:
.
· m j and
· m .m / j
X
Sylvain 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
O
Sylvain 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 X
Sylvain 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 X
Sylvain 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 X
Sylvain 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 X
Sylvain 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 X
Sylvain 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 O
Sylvain 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 O
Sylvain 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 O
Sylvain 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 O
Sylvain 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 O
Sylvain 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’ / j
Sylvain 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 violation
Sylvain 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 O
Sylvain 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 O
Sylvain 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 O
Sylvain Hallé 16
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 O
Sylvain 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 violation
Sylvain 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 taken
Sylvain Hallé 17
63. How to find root violations?
Solution #1
Bauer et al. (RV 2007): anticipatory semantics for LTL
Sylvain 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
a
Sylvain 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
a
Sylvain 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
a
Sylvain 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
b
Sylvain 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
b
Sylvain 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
b
Sylvain 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
b
Sylvain 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
b
Sylvain Hallé 18
72. How to find root violations?
Problem:
· Designed for LTL
a b
a b
b
a
Sylvain Hallé 19
73. How to find root violations?
Problem:
· Designed for LTL
.
· With LTL-FO+, M is infinite
a b
a b
b
a
Sylvain 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 on
Sylvain 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 checker
Sylvain 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 violation
Sylvain Hallé 20
80. How to find root violations?
Problem:
· Requires bounded data domains
· Exponential blow-up of formula
· Non-incremental process
Sylvain 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
s
Sylvain 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
s
Sylvain 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 continue
Sylvain Hallé 24
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), Øa
Sylvain Hallé 25
91. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
Sylvain Hallé 25
92. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25
93. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25
94. Runtime monitoring
Example: G (a ® X Øa)
a ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25
95. Runtime monitoring
Example: G (a ® X Øa)
’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25
96. Runtime monitoring
Example: G (a ® X Øa)
G (a ® X Øa), Øa ’
’ G (a ® X Øa), Øa
s=a
Sylvain 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=a
Sylvain Hallé 25
98. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a, Øa ’ G (a ® X Øa), Øa
s=a
Sylvain 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=a
Sylvain Hallé 25
100. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
a, Øa ’ G (a ® X Øa), Øa
s=a
Sylvain Hallé 25
101. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
s=a
Sylvain Hallé 25
102. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
s = aa
Sylvain Hallé 25
103. Runtime monitoring
Example: G (a ® X Øa)
Øa ’ G (a ® X Øa)
s = aa
Sylvain 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 = aa
Sylvain 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 nodes
Sylvain 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 nodes
Sylvain 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 formulas
Sylvain 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 quantifiers
Sylvain Hallé 29
111. A workflow for root violation detection
Sylvain Hallé 30
112. A workflow for root violation detection
1 1
... n n
}
Leaf nodes from current
monitor state
Sylvain Hallé 30
113. A workflow for root violation detection
1 1
... n n
}
m
Incoming
message
Sylvain Hallé 30
114. A workflow for root violation detection
1 1
... n n
}
m UPDATE
Monitor
update function
Sylvain Hallé 30
115. A workflow for root violation detection
1 1
... n n
} } 1
' '
1
...
m UPDATE
' '
k k
New leaf nodes
Sylvain 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 k
Sylvain 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 k
Sylvain 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 k
Sylvain 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 node
Sylvain 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
nodes
Sylvain 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 pruning
Sylvain 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 contract
Sylvain 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
Overhead
Sylvain 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 difference
Sylvain 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
overhead
Sylvain Hallé 35