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. Today’s 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. That’s 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 φI on the inputs (input assumption) ∙ A postcondition φO on the outputs (output guarantee) • Remember that the environments is providing the free inputs. So, the predicate φI constraints the environment to provide variables satisfying it. • 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. • The interface tells the environment what it will return with φO. • 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 that’s what we want from the environnement, this is the input assumption. 6

8. Base and symbols A/G Interface Interface automata Discussion • Let’s 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 doesn’t 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 symbolsA/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 symbolsA/G Interface Interface automata Discussion • 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. 10

12. Base and symbolsA/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 can’t do it!). • An automata than has absolutely no interaction with its environnement is called closed. We have AI = AO = Ø. 11

13. Base and symbolsA/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 don’t 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 symbolsA/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∩ Aoutput,F) U (Aoutput,F∩ Ainput,G) 13

15. Base and symbolsA/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 symbolsA/G Interface Interface automata Discussion Remember the component that will try twice to send a message. ok; Now, let’s think of a component that calls it… send; 6 …and let’s take the product. We identify the shared parts. They become hidden. 15

17. Base and symbolsA/G Interface Interface automata Discussion • 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. 16

18. Base and symbolsA/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 symbolsA/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 symbolsA/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 symbolsA/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 symbolsA/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)