interface-based design philippe giabbanelli cmpt 894 – spring 2008

Interface-based designPhilippe Giabbanelli

CMPT 894 – Spring 2008

Brief review of concepts and symbols

Assume/guarantee interface

We have seen a number of ways to model interfaces for components.

Today’s approach is from a more theoretical point of view, providing a solid background.

Discussion

Interface automata

1

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.

2

• 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.

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.That’s an incremental design: we can add a specification.

• 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.


3

• 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.


4

• An A/G interface has:

∙ A set XI of input variables

∙ A precondition φI on the inputs (input assumption)

• Remember that the environments is providing the free inputs. So, the predicate φI constraints the environment to provide variables satisfying it.

∙ A set XO of output variables

∙ A postcondition φO on the outputs (output guarantee)

• The interface tells the environment what it will return with φO.

• As φI 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.

• In a division component with x and y, we might require y ≠ 0 as an input assumption, and a trivial TREE as output guarantee.


5

• 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.


6

It asks the environment to satisfy the formula so that the composition

works.

As that’s what we want from the environnement, this is the input

assumption.


7

• Let’s go for a simple example from the paper.

No input. Output x, with guarantee TRUE.F

GInputs x and y, with assumption x = 0 → y = 0. No output.

• The formula for compatibility becomes:For all x, TRUE → (x = 0 → y = 0)

Which simplifies to y = 0, that an environnement can provide. As F doesn’t put any restriction on x, it might provide x = 0 or not.

F G

• We can do the composition F || G. It has:

∙ input variable y (weakest condition provided by the context)

∙ input assumption y = 0

∙ output variable x

∙ output guarantee TRUE


8

• 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.

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.

This short explanation on A/G interfaces is mainly a summary of:


9

• 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).


10

• Let’s 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.


11

• 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.

aq

• 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).

AI(q) for ‘?’AO(q) for ‘!’AH(q) for ‘;’

• We assume than when we are in state q then the environnement will not provide an input action that is not enabled (otherwise we can’t do it!).

• An automata than has absolutely no interaction with its environnement is called closed. We have AI = AO = Ø.


12

• An execution is an alternating sequence of states and actions q0, a0…

• A state q’ is reachable from q if there is an execution q, …, q’.

• If all actions in an execution are output or hidden (i.e. we don’t need any input), then the execution is autonomous.

• If all actions are hidden then the execution is invisible.

(it can be autonomously reachable or invisibly reachable)

• A state q’ is reachable in an automaton F if it is reachable from q0.

…


13

• 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 ∩ Aoutput,F) U (Aoutput,F ∩ Ainput,G)


14

• 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.

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).

If an action is not synchronized, then it

is the business of only one of the automaton.

Otherwise, they can both move.


15

Remember the component that will try twice to send a message.

Now, let’s think of a component that calls it…

…and let’s take the product.

We identify the shared parts.

send;

ok;

They become hidden.

6


16

• Let’s 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.


17

Thus, incompatible compositions are not only when there is a reachable error state but when there is no good context against it.

• 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).


18

• To go from the product F x G to the composition F || G, we remove all transitions leading to incompatible states.

The ‘caller’ component does not tolerate any error, thus it is not

compatible with fail.

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 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.


19

• 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)


20

• 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.


21

• An environment is found as a winning strategy in a two-player game.

• 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!).

(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.

Article used for this presentation

Interface-based Design (Luca de Alfaro, Thomas A. Henzinger, Engineering Theories of Software-intensive Systems, Springer 2005)

interface-based design philippe giabbanelli cmpt 894 – spring 2008

Documents

f input

discussion interface

inputs of g

ag interfaces

outputs of f

compatible components

output guarantee of

free inputs