+ All Categories
Home > Documents > Interface Automata

Interface Automata

Date post: 24-Feb-2016
Category:
Upload: holleb
View: 58 times
Download: 3 times
Share this document with a friend
Description:
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 - PowerPoint PPT Presentation
18
Interface Automata 29-September-2011
Transcript
Page 1: Interface Automata

Interface Automata

29-September-2011

Page 2: Interface Automata

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

Page 3: Interface Automata

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

Page 4: Interface Automata

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

Page 5: Interface Automata

Sample Interface Automata

• User– Designed to be used only with message-transmission

services that cannot fail

Page 6: Interface Automata

Comp User

• Compose Comp with User– msg? and msg! collapsed to msg;– Error state 6 upon second failed nack?

• Composition– Note how a “new” automata

is created from thecomposition with its own In/Out actions

• Handling errors– Why does 6 have no exiting

arrows?– Declared “Illegal” state(s)

Page 7: Interface Automata

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

Page 8: Interface Automata

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

Page 9: Interface Automata

Example

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

Page 10: Interface Automata

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 cannot

be composed in thisrestrictive way

Page 11: Interface Automata

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?

Page 12: Interface Automata

QuickComp

• Comp QuickComp means QC refines C

Page 13: Interface Automata

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

Page 14: Interface Automata

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

Page 15: Interface Automata

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

Page 16: Interface Automata

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

Page 17: Interface Automata

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

Page 18: Interface Automata

Single-Threaded vs. Multi-Threaded


Recommended