Interface Theories in Practice Luca de Alfaro UC Santa Cruz GDV 2006.
Transcript of Interface Theories in Practice Luca de Alfaro UC Santa Cruz GDV 2006.
Interface Theories in Practice
Luca de AlfaroUC Santa Cruz
GDV 2006
Theory
(In theory, many things work...)
Collaborators: Tom HenzingerMarielle Stoelinga
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
• Transition systems: 1 decision
• Closed systems: 1 actor – Output: hat outputs can be generated?
• Games: 2 decisions
• Open Systems: 2 actors:
– Input: what inputs to give next?
– Output: what outputs to generate next?
• Model open systems as games, rather than transition systems.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
• Transition systems: 1 decision
• Closed systems: 1 actor – Output: hat outputs can be generated?
• Games: 2 decisions
• Open Systems: 2 actors:
– Input: what inputs to give next?
– Output: what outputs to generate next?
• Model open systems as games, rather than transition systems.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
• Transition systems: 1 decision
• Closed systems: 1 actor – Output: hat outputs can be generated?
• Games: 2 decisions
• Open Systems: 2 actors:
– Input: what inputs to give next?
– Output: what outputs to generate next?
• Model open systems as games, rather than transition systems.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send!
msg?
msg? send!
ack?
nack?fail!
ok!
ack? nack?
ok! fail!
A Game Model
Input moves: the inputs that are allowed.
Output moves: the outputs that can be generated.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send!
msg?
msg? send!
ack?
nack?fail!
ok!ack?nack?
msg?
*?
*?
*?
ack? nack?
ok! fail!
send!
msg?
msg? send!
ack?
nack?fail!
ok!
ack? nack?
ok! fail!
A Game Model
Input moves: the inputs that are allowed.
Output moves: the outputs that can be generated.
A Transition-System Model
Output moves: the outputs that can be generated.
Input moves: always accepted (input enabled).
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send!
msg?
msg? send!
ack?
nack?fail!
ok!ack?nack?
msg?
*?
*?
*?
ack? nack?
ok! fail!
send!
msg?
msg? send!
ack?
nack?fail!
ok!
ack? nack?
ok! fail!
A Game Model A Transition-System Model
What is the difference??
• Refinement
• Composition
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Simulation as Open System Refinement?
Q¹
Pµµ
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Simulation as Open System Refinement?
Often, it is defined as transition system refinement. However:
• If P accepts fewer inputs, it is usable in fewer ways.
• Indeed, we cannot plug P for Q in a design.
Q¹
Pµµ?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Simulation as Open System Refinement?
Often, it is defined as transition system refinement. However:
• If P accepts fewer inputs, it is usable in fewer ways.
• Indeed, we cannot plug P for Q in a design.
Q¹
Pµµ?
Simulation is not the proper notion of refinement for open systems!
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
To define open-system refinement, let’s look at type theory
Dom()
Dom()
Im()
Im()
¹ µ
µ
Subtyping is Domain/Image contravariant
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Open System Refinement
¹ µ
µ
This is alternating simulation, the notion of refinement for games![Alur,K,Henzinger,V CONCUR98]
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
TS: Simulation
Spec
Impl
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
TS: Simulation
Spec
Impl
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
TS: Simulation
Spec
Impl
All behaviors of the implementation are allowed by the specification
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Games: Alternating Simulation
Spec
Impl
Inputs Outputs
The implementation accepts all the specification inputs,
and produces a subset of the outputs.
The implementation can be substituted for the specification.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Alternating Simulation Example
send!
msg?
msg? send!
ack?
nack?fail!
ok!
ack? nack?
ok! fail!
send!
msg?
msg? send!
ack?
nack?fail!
ok!
ack? nack?
ok! fail!done!once?
once?send!
ack? done!
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Types: Composition
Dom() Im()
Condition:
Dom() Im()
Im() µ Dom()
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Types: Composition
Dom() Im()
What if
Dom() Im()
Im() µ Dom() ?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Types: Composition
Dom() Im()
What if
Dom() Im()
Im() µ Dom() ?
Can we restrict Dom() to Dom’(),
to ensure Im’() µ Dom() ?
YES ) Compatible, type derivationNO ) Incompatible
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
int x intx=0 ! y=0 int
x
yz
Types: Composition
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
int
Compatible?
Types: Composition
int x intx=0 ! y=0 int
x
yz
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
intx 0 int
x
Compatible? Yes! Outcome:
Compatible: Are there inputs for which it works?New type: most general restrictions under which it works.
Types: Composition
int
int x intx=0 ! y=0 int
x
yz
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Behaviors: Composition
a?
b?
c?a!
b!µ
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Behaviors: Composition
a?
b?
c?a!
b!
a!
b!
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Behaviors: Composition
b?
c?a!
b!µ
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Behaviors: Composition
b?
c?a!
b!
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Process Algebra
b?
c?a!
b!
b!Not for us!
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send! nack?
msg? ok! fail!
ack?
msg? send! send!ack?
ack?
nack?
nack?fail!
ok!
Example: Interface Automata Composition
msg!
ok?
msg! fail?ok?
Local incompatibility:Here, fail? cannot be accepted
fail! generated
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send! nack?
msg! ok! fail!
ack?
msg! send! send!ack?
ack?
nack?
nack?
ok!
Example: Interface Automata Composition
Local incompatibility
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send! nack?
msg! ok! fail!
ack?
msg! send! send!ack?
ack?
nack?
nack?
ok!
Example: Interface Automata Composition
Can we restrict the inputs to avoid the local incompatibility?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send! nack?
msg! ok! fail!
ack?
msg! send! send!ack?
ack?
nack?
nack?
ok!
Example: Interface Automata Composition
Can we restrict the inputs to avoid the local incompatibility?
YES.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send! nack?
msg! ok! fail!
ack?
msg! send! send!ack?
ack?
nack?
ok!
Example: Interface Automata Composition
The resulting interface automaton.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Practice:
The Ticc Tool
GPL licencehttp://dvlab.cse.ucsc.edu/Ticc
Collaborators:
Marco FaellaVishwanath RamanPritam RoyAxel LegayBo AdlerLeandro Dias Da Silva
Intended Application:
?
Intended Application:
Compatibility checking.
Modeling - Desiderata
• Synchronization (actions)• one-to-one, one-to-many, many-to-many
• Shared state (local + global variables)
• Communication (actions can update variables)
• one-to-one, one-to-many, many-to-many
) Sociable Interfaces [FROCOS 2005] Implemented in Ticc.
Many-to-One Synchronization does not work in Interface Automata
a? a! a!
Many-to-One Synchronization does not work in Interface Automata
a!a!
Incompatible: neither can accept a!.
Ticc usesSociable Interfaces
For a in the language:
a?
a!
a is not generated as output, buta can be accepted as input.
a can be generated as output,but it cannot be accepted as input.
a can neither be generated as output,nor accepted as input.
[dA, Faella, et al.FROCOS 05]
Ticc usesSociable Interfaces
For a in the language:
a?
a!
a?
a!
a can be generated as output, and a can be accepted as input.
a is not generated as output, buta can be accepted as input.
a can be generated as output,but it cannot be accepted as input.
a can neither be generated as output,nor accepted as input.
[dA, Faella, et al.FROCOS 05]
new in sociable interfaces
Product of sociable interfaces
1
3
a?
A
B
a?
1A
3B
a?
1
2
a!
A
B
a?
1A
2B
a!
Product of sociable interfaces
1
3
a?
2
a!
A
B
a?
1A
3B
a?
2B
a!
Product of sociable interfaces
1
3
a?
2
a!
A
C
a!
1A
3C
a!
a! from 1 has no corresponding a? from A
locally incompatible
state
Product of sociable interfaces
1
3
a?
2
a!
A
B
a?
C
a!
1A
3B
a?
3C
a!
2B
a!
Product of sociable interfaces
X Incompatible
fire?
fd!
smoke1?
fire!
Controlunit
Detector 1
smoke2?
fire!
Detector 2
X Incompatible
fire?
fd!
smoke1?
fire!
Controlunit
Detector 1
smoke2?
fire!
Detector 2
Not accepted
by all other components
X Compatible
fire?
fd!
smoke1?
fire!
Controlunit
Detector 1
smoke1?fire?
smoke1?fire?
fire?
smoke2?
fire!
Detector 2
smoke2?fire?
smoke2?fire?
fire?
fire?
fire?
Ticc Model
t=0
t=1
t=2
smoke2?
fire!
Detector 2
smoke2?fire?
smoke2?fire?
fire?module FireDetector2: var t: [0..2] initial: t=0
input smoke2: { local: t=0 ==> t':=1 else true ==> // do nothing }
output fire: { t=1 ==> t'=2 }
input fire: { } // disregard
endmodule
What feedback should Ticc give?
Naive belief:
“Ticc will tell us when components are incompatible”.
Reality:
Most components are compatible: in an environment that does nothing, often nothing (bad) happens.
) We need more diagnostic information...
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Example: A detector that can be disabled
s=0
s=1
s=2
fire?
fd!
t=0
t=1
t=2
smoke1?
fire!
Detectors=3
disable?
Control Unit
disable?
disable?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
What happens if we forget the disable?
s=0
s=1
s=2
fire?
fd!
t=0
t=1
t=2
smoke1?
fire!
Detectors=3
disable?
Control Unit
disable?
disable?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
s=0
s=1
s=2
fire?
fd!
t=0
t=1
t=2
smoke1?
fire!
Detector
s=3
disable?
Control Unit
s=0, t=0
s=0, t=1
s=1, t=2
smoke1?
fire!
fd!
s=3, t=0
s=3, t=1
smoke1?
disable?
disable?
fire!
The controlunit cannot accept fire!
once disabled
(s=3)
What happens if we forget the disable?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
s=0, t=0
s=0, t=1
s=1, t=2
smoke1?
fire!
fd!
s=3, t=0
s=3, t=1
smoke1?
disable?
disable?
fire!
Is there an environmentwhere the components work together?
) does Input have astrategy s.t., whateverOutput does, the incompatibility does notoccur?
What happens if we forget the disable?
Locallyincompatible
state
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
s=0, t=0
s=0, t=1
s=1, t=2
smoke1?
fire!
fd!
s=3, t=0
s=3, t=1
smoke1?
disable?
disable?
Is there an environmentwhere the components work together?
) does Input have astrategy s.t., whateverOutput does, the incompatibility does notoccur?
YES.
(Compatibility does notgive us information here)
What happens if we forget the disable?
Locallyincompatible
state
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
s=0, t=0
s=0, t=1
s=1, t=2
smoke1?
fire!
fd!
s=3, t=0
s=3, t=1
smoke1?
disable?
disable?
The interesting question is:
What has becomeimpossible?
(What environment inputsare no longer enabled?)
What question should we ask?
Locallyincompatible
state
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
s=0, t=0
s=0, t=1
s=1, t=2
smoke1?
fire!
fd!
s=3, t=0
s=3, t=1
smoke1?
disable?
disable?
Given an action, e.g., smoke?, Ticc gives a path such that:
Ticc Feedback
1. Starts from an initial state
2. Goes to the action taking only “good” steps.
3. Takes an instance of the action that has become prohibited.
4. Continues, taking only output steps, until an incompatibility is reached.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Ticc Feedback
Restriction of action a:
a?
Input and output actions,in the “good” states.
Output actions only,in the pruned states.
Locallyincompatible
state
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
send!msg!
ok!
ack?
nack?
Ticc Feedback
s=0 s=1 s=2 s=3 s=4
s=6
s=5
send!
ack?
nack?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Games and Global Variables are a difficult mix
• a! may want to update a global variable x.
The module emitting a! can communicate a value to other modules by writing into x.
• a? may want to update a local variable y.
The module receiving a? may want to update its internal state as a consequence.
• But, when a! and a? synchronize, only one of Input/Output should be able to take decisions (otherwise, not a game).
) Updates by input actions are deterministic.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Output Actions: Global + Local Update
local global
local global
Current state
Next state
a!
updates updates
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Input Actions: Global Assumptions
Current state local global
Next state local global
Assumption on how action a!, emitted from another module, can update the global variables.
assumption
a?
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Current state local global
Next state local global
The module receiving a? can look at the current state, and at the new values of the global variables, to update its local variables (communication). The update must be deterministic.
a?
Input Actions: Local Update
update(det)
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
I/O Synchronization and Communication
local of P global
local of P global
local of Q
local of Q
Check that gupd implies gasm
(the output update satisfies the input assumption)
P || Q
a!
gupd gasm
a?
lupd
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
I/O Synchronization and Communication
local of P global
local of P global
local of Q
local of Q
P || Q
a!
gupd gasm
a?
lupd update (det)
All new values are determined by the emitter of a!(the result is an Output move).
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
A House Repair Example
• Many things can break, repair-people are called to fix them.
• Repair people want to work alone in a room: before starting, they check that the room is not busy, and assume others do the same.
• Except, a rude electrician does not care if anyone is already working on the kitchen.
Kitchen
LivingRmBathRm
BedRmElectricalFloorsWallsDirt
Plumbing
bre
aks
fixes
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Ticc: Features and Capabilities
• Additional features: CTL model-checking, (soon ATL), simulation, ...
• The tool is written in Ocaml, it relies on the MDD package cudd/glu [Somenzi et al.]
• Efficient: uses saturation techniques for symbolic exploration [Ciardo, Yu CHARME 2005]
• GPL licence, lots (we hope) of documentation.
http://dvlab.cse.ucsc.edu/Ticc
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Does it work in practice?• Certainly better than not having input assumptions.
– One can use *: { } as the everything-goes assumption.– Gives guidance, very little to lose.
• Efficient– Many problems reduce to reachability, saturation works
great.
• Sometimes weak guidance– When Ticc complains, there is a good reason. – But at times, it does not catch problems until several
components are composed.
• Uses its own input language.– The language is flexible for composition, but poor (right
now) for datatype support (boolean and integer range).– Will anyone code in it? If the ideas are useful, others will
implement them in industrial tools.
Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)
Future work• Better guidance• Local checks
– Check compatibility pairwise, or in small groups of components.
• Real-time implementation– It’s in the works...
• Sat-based algorithms – They would be a good fit!
Come and use the tool, hack its code, modify it, etc etc! It’s fun!
http://dvlab.cse.ucsc.edu/Ticc