Interface-based design

1
Interface-based design
Philippe Giabbanelli CMPT 894 Spring 2008
2
We have seen a number of ways to model interfaces
for components.
Todays approach is from a more theoretical point
of view, providing a solid background.
Brief review of concepts and symbols
Assume/guarantee interface
Interface automata
Discussion
1
3
Base and symbols A/G Interface
Interface automata Discussion
Without much surprises, we are still
interesting in the same thing
To see if two components are compatible (i.e.
work well together), we use interfaces having
protocol information.
A component is often an open system it has
some free inputs that will be given by other
components throughout the interactions.
We want to be able to specify the compatibility
of components with their free inputs.
?
?
We say that two open components are compatible
if there exists an environment providing all free
inputs so that they are compatible.
In other words, interfaces are well-formed if
there is a (friendly) environment in which they
are compatible.
Those components have free inputs.
We want to be able to say if they are compatible.
We do not want to specify the interfaces to close
the systems.
Thats an incremental design we can add a
specification.
2
4
Base and symbols A/G Interface
Interface automata Discussion
If have a compatibility , then we can define a
composition .
Let F and G be interfaces. If F G then F G
is well defined.
Compatible components can be put together in
any order.
Let F, G, H, I be interfaces.
If F G, H I and F G H I then F H, G
I, F H G I.
We have the refinement . As usual, if F
F and F is compatible with G, then F is
compatible with G.
The interfaces defined in the paper are called
Assume/Guarantee (A/G).
The language for interfaces is interface
automata.
3
5
Base and symbols A/G Interface
Interface automata Discussion
An A/G interface has
A set XI of input variables
A set XO of output variables
A precondition fI on the inputs (input
assumption)
A postcondition fO on the outputs (output
guarantee)
Remember that the environments is providing the
free inputs. So, the predicate fI constraints the
environment to provide variables satisfying it.
As fI is a constraint on the environnement, it
might not be satisfied by all environnements. In
other words, there are contexts to use an A/G.
The interface tells the environment what it
will return with fO.
In a division component with x and y, we might
require y ? 0 as an input assumption, and a
trivial TREE as output guarantee.
4
6
Base and symbols A/G Interface
Interface automata Discussion
To compose two A/G interfaces
Their output variables have to be disjoint.
If an interface provides F input to G, then the
output guarantee of F implies the input
assumption or G (or the other way around).
In the case where all inputs of G are outputs
of F, or vise versa, they are compatible if the
following formula ? is true
If some inputs are free, ? has free input
variables. So, the interfaces are compatible if
there is a good context, i.e. if ? is satisfiable.
5
7
Base and symbols A/G Interface
Interface automata Discussion
It asks the environment to satisfy the formula so
that the composition works.
As thats what we want from the environnement,
this is the input assumption.
6
8
Base and symbols A/G Interface
Interface automata Discussion
Lets go for a simple example from the paper.
F
F
G
Output x, with guarantee TRUE.
No input.
We can do the composition F G. It has
G
Inputs x and y, with assumption x 0 ? y 0.
No output.
input variable y (weakest condition provided
by the context)
input assumption y 0
output variable x
The formula for compatibility becomes
output guarantee TRUE
For all x, TRUE ? (x 0 ? y 0)
Which simplifies to y 0, that an environnement
can provide. As F doesnt put any restriction on
x, it might provide x 0 or not.
7
9
Base and symbols A/G Interface
Interface automata Discussion
As usual we are interested in composition and
refinements!
We have an A/G interface F. To refine it, an
A/G interface F must
Accept all the inputs of F.
Produce only outputs of F.
This short explanation on A/G interfaces is
mainly a summary of
L. de Alfaro and T.A. Henzinger, Interface
theories for component-based design, Proc.
Embedded Software, Lecture Notes in Computer
Science 2211, pages 148 165. Springer-Verlag,
2001.
8
10
Base and symbols A/G Interface
Interface automata Discussion
As classical automaton, an interface automata
can be seen as a directed graph with labels on
the edges.
Vertices are states
Labels are the names of actions
Edges are transitions (on actions)
Actions are partitionned in three sets (think
of visibly context-free)
input
output
internal (cannot be seen by the environnement)
On a given state with an input, it can go to only
one state (deterministic).
9
11
Base and symbols A/G Interface
Interface automata Discussion
Lets illustrate those automata with an example
from the paper.
A component offers a service  send  to send
messages.
the components returns either  ok  or  fail 
The components relies on trnsmt to send the
message.
trnsmit can succeed (ack) or fail (nack). We
try it twice.
Input.
Output.
10
12
Base and symbols A/G Interface
Interface automata Discussion
Before going any further, we need to establish
the usual definitions.
If there is an action a at a state q, we say
that a is enabled at q.
a
AI(q) for ?
q
AO(q) for !
AH(q) for
The set of input actions available (i.e.
enabled) at q is AI(q).
Respectively, output actions are AO(q) and hidden
are AH(q).
We assume than when we are in state q then the
environnement will not provide an input action
that is not enabled (otherwise we cant do it!).
An automata than has absolutely no interaction
with its environnement is called closed. We have
AI AO Ø.
11
13
Base and symbols A/G Interface
Interface automata Discussion
An execution is an alternating sequence of
states and actions q0, a0

If all actions in an execution are output or
hidden (i.e. we dont need any input), then the
execution is autonomous.
If all actions are hidden then the execution is
invisible.
A state q is reachable from q if there is an
execution q, , q.
(it can be autonomously reachable or invisibly
reachable)
A state q is reachable in an automaton F if it
is reachable from q0.
12
14
Base and symbols A/G Interface
Interface automata Discussion
Prior to define the composition, we need to
define the usual restrictions.
A (very!) simplified way to think of
compositions is with two situations
F
G
G
F
So, the inputs of G might have been sent by
outputs of F, or vice-versa.
shared(F, G) (Ainput,G n Aoutput,F) U
(Aoutput,F n Ainput,G)
13
15
Base and symbols A/G Interface
Interface automata Discussion
First, we define the product automaton F x G.
Basically, it is the union of F and G,
synchronizing on actions in shared(F, G) and
allowed to do their own things asynchronously in
between.
If an action is not synchronized, then it is the
business of only one of the automaton.
We hide shared actions in the product.
i.e. everything that is shared is taken out of AI
and AO and goes into AH (hidden).
Otherwise, they can both move.
14
16
Base and symbols A/G Interface
Interface automata Discussion
Remember the component that will try twice to
send a message.
ok
Now, lets think of a component that calls it
send
6
and lets take the product.
We identify the shared parts.
They become hidden.
15
17
Base and symbols A/G Interface
Interface automata Discussion
Lets consider a state (q, r) where q comes
from an automaton F and r from the other G.
If there is a shared action that it is an
output of q but not an input of r (or
vice-versa), we call it an error state.
If there is no reachable error state (think of
the liveness assumption in the previous
presentation), we can do the composition F G.
If there is a reachable error state but F x G
is not closed (i.e. there are some free inputs),
it is a bit more tricky
By providing  good inputs , the environment of
F x G might ensure that no error state will ever
be encountered.
Thus, incompatible compositions are not only when
there is a reachable error state but when there
is no good context against it.
16
18
Base and symbols A/G Interface
Interface automata Discussion
More formally, if F and G are composable, then
we have an environment E such that
E is composable with F x G
(F x G) x E is closed (i.e. the environment
provides all free inputs if any)
E prevents error states of F x G from being
entered (i.e. by providing good inputs it
avoids reachable errors)
E accepts all outputs of F x G
Such environment E is called a legal
environment. There is always a legal environment
for an F and G (hint trivial empty closure).
Thus, incompatible compositions are not only when
there is a reachable error state but when there
is no good context against it.
17
19
Base and symbols A/G Interface
Interface automata Discussion
To go from the product F x G to the composition
F G, we remove all transitions leading to
incompatible states.
Fail can only happen if the context gives us nack.
Thus, we can compose under a good context giving
ack.
The composition removes only transitions, but as
a result some states might become unreachable and
they can be removed as well.
The caller component does not tolerate any
error, thus it is not compatible with fail.
The states left over after the deletion process
are the relevant ones. They can be found in
linear time thus we can check and do the
composition in linear time.
18
20
Base and symbols A/G Interface
Interface automata Discussion
As usual, after the composition comes the
refinement.
This component can try to send a message twice
(when receiving send) or once (when receiving
once). Thus, it clearly refines the component
that just receives send and tries twice. However,
once is only an input for this component!
F refines F if all input transitions of F can be
simulated by F, and each output transition of F
can be simulated by F (more input, less outputs).
(more details in Alternating refinement relations
by Alur, Henzinger, Kupferman and Vardi, Proc.
Concurrency Theory 1998)
19
21
Base and symbols A/G Interface
Interface automata Discussion
There are some limitations on environments the
assumption of an automaton says which inputs may
occur but not which ones must occur.
The better context to show compatibility is the
one that provides no input. It cannot reach any
error
If we want to specify inputs that must occur,
there is a number of ways.
(see Synchronous and bidirectional component
interfaces, from Chakrabarti, De Alfaro,
Henzinger and Mang, 2002)
An environment is found as a winning strategy
in a two-player game.
F and G are compatible if the environment has a
strategy to avoid errors.
The 1st player is the environment, providing
inputs to F x G.
The 2nd player is the team F x G of interfaces,
choosing internal transitions and outputs.
20
22
Base and symbols A/G Interface
Interface automata Discussion
If we have hidden transitions, then the state
of an interface cannot be known completely by the
environment. In other words, it has only partial
information.
Winning strategies in games with partial
information is in general exponential (constructs
all possibles subsets of states) thus inpractical
for synchronous interfaces (remember that here we
chose asynchronous!).
An environment is found as a winning strategy
in a two-player game.
(see The complexity of two-player games of
incomplete information by J. Reif, Journal of
Computer and System Sciences 1984)
The idea of game is flexible enough. Different
goals/meanings can be created by modifying the
objective function of the game.
21
23
Article used for this presentation
Interface-based Design (Luca de Alfaro, Thomas A.
Henzinger, Engineering Theories of
Software-intensive Systems, Springer 2005)