Interface-based design Philippe 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.

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 4 An A/G interface has: ∙ A set X I 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 X O 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.

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 7 Let’s go for a simple example from the paper. No input. Output x, with guarantee TRUE. F G Inputs 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

Base and symbols A/G Interface Interface automata Discussion 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, This short explanation on A/G interfaces is mainly a summary of:

Base and symbols A/G Interface Interface automata Discussion 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).

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 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. a q The set of input actions available (i.e. enabled) at q is A I (q). Respectively, output actions are A O (q) and hidden are A H (q). A I (q) for ‘?’ A O (q) for ‘!’ A H (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 A I = A O = Ø.

Base and symbols A/G Interface Interface automata Discussion 12 An execution is an alternating sequence of states and actions q 0, a 0 … 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 q 0. …

Base and symbols A/G Interface Interface automata Discussion 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 GG F So, the inputs of G might have been sent by outputs of F, or vice-versa. shared(F, G) = (A input,G ∩ A output,F ) U (A output,F ∩ A input,G )

Base and symbols A/G Interface Interface automata Discussion 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 A I and A O and goes into A H (hidden). If an action is not synchronized, then it is the business of only one of the automaton. Otherwise, they can both move.

Base and symbols A/G Interface Interface automata Discussion 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

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 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).

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 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)

Base and symbols A/G Interface Interface automata Discussion 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.

Base and symbols A/G Interface Interface automata Discussion 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)