1 / 18

Interface Automata

Interface Automata. 29-September-2011. Modeling Temporal Behavior of Component. Component behaves with Environment Traditional (pessimistic) approach Environment is free to behave as it wants to Two components are compatible if no environment leads them into an error state

holleb
Download Presentation

Interface Automata

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interface Automata 29-September-2011

  2. Modeling Temporal Behavior of Component • Component behaves with Environment • Traditional (pessimistic) approach • Environment is free to behave as it wants to • Two components are compatible if no environment leads them into an error state • Optimistic approach of Interface Automata • Components designed with assumptions about environment • Two components are compatible if some environment can make both of them work together • In context of this course • Write code ONCE and know that it works

  3. Interface Automata • Interaction specified by synchronizing input and output actions • Internal actions of concurrent automata are interleaved asynchronously • Input actions • Model methods that can be called • Receiving ends of communication channels • Output actions • Model method calls • Messages being transmitted • Exceptions • Component designed under environmental assumptions • i.e., an object works if methods called in specific order

  4. Sample Automata • Internal state machineexternally invisible • Labels • msg? means message received • send! means action sent out • Dot/arrow on interface species in- or out-connection • Internal transitions are arrows between states based upon interface interactions • Let’s discuss possible valid/invalid interactions

  5. Sample Interface Automata • User • Designed to be used only with message-transmission services that cannot fail

  6. Comp  User • Compose Comp with User • msg? and msg! collapsed to msg; • Error state 6 upon second failed nack? • Composition • Note how a “new” automatais created from thecomposition with its own In/Out actions • Handling errors • Why does 6 have no exitingarrows? • Declared “Illegal” state(s)

  7. Interface Automata • Definition in paper • Review page 113 • Compatibility and Composition • All independent actions are asynchronous • All shared actions force automata to synchronize state transitions • Two automata P and Q are composable if • They don’t share states • There is no duplication of Input or Output actions • That is, “shared” means pairing Input with Output

  8. Component Product • Review Definition (p114) • Legal environments • Steers away from Illegal states • How to specify? Use an Interface Automata! • Environment Automata E • E is composable with R and non-empty • Input of E is the output of R • Illegal(R, E) = 

  9. Example • Channel wraps error-prone send (ack/nack) with an error-free get_token / put_token to ensure delivery • Parse this from the graphics

  10. Final Notation • Automata Product Composition: Comp  User • Restricted Composition:Comp || User • Nice features of composition • Associative (P || Q) ||R == P || (R || Q) if either is defined • Some automata cannotbe composed in thisrestrictive way

  11. Refinement • Consider relation between abstract and concrete version of a component • QuickComp (next slide) • Provides try-twice msg service • Provides try-once once service • Shouldn’t QuickComp be considered a refinement of Comp?

  12. QuickComp • Comp QuickComp means QC refines C

  13. Contravariance • Refined automata must allow for (possibly) more legal inputs and (possibly) fewer outputs • Weaken the pre-condition • Strengthen the post-condition • Notion of alternating simulation • Q refines P if • all input steps of P can be simulated by Q • all output steps of Q can be simulated by P • works because internal state transitions are invisible to external viewers • Captures a simple kind of subclassing • If Q refines P then implementation Q is able to provide more services than specification P • Q must be consistent with P on shared services

  14. More definitions • Transitive: Q refines P and R refines Q • If P Q and Q R then P R • Reflexive: P refines P • P P • Refinement and compatibility are related • Replace P with Q if (a) P and Q are connected to the environment by same input/output; and (b) P Q

  15. Refinement is Compositional • Is P||R S||T? • One need only check two smaller cases • Is P S? • Is R T? • Compositional reasoning is the key to dealing with large scale systems

  16. Refinement and Composition • Given interface automata P, Q, and R where • Q and R are composable • InputQ OutputR InputP OutputR • If P and R are compatible and P Q • Q and R are compatible • P||R Q||R

  17. Single-Threaded Interface Automata • Many compositions can be restricted to single-threaded • Client makes request (and then blocks); during this time client cannot alter state • Server receives request and once it has responded, it becomes quiescent and won’t alter state • See Figure 7

  18. Single-Threaded vs. Multi-Threaded

More Related