I/O & Interface Automata
description
Transcript of I/O & Interface Automata
![Page 1: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/1.jpg)
I/O & Interface Automata
By Josh Lessard, Josh Taylor, Real Xu
![Page 2: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/2.jpg)
Presenters’ Intro
![Page 3: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/3.jpg)
Presenters’ Problem
![Page 4: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/4.jpg)
Agenda
• Components & Automata
• Interface Automata
• Single-Threaded Interface Automata
• Conclusion
![Page 5: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/5.jpg)
Components & Automata
By Real Xu, [email protected]
User Interface Group, School of Computer Science, University of Waterloo
![Page 6: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/6.jpg)
Objective
• Understand Components & Framework
• Discover relationship between Component-Based Design and Embedded Systems
• Introduction to Component-Based Model of Computation
• Review evolvement
• Understand why we use automata
![Page 7: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/7.jpg)
Components & Framework
• What is component?• subroutines• processes/threads• distributed objects• review of lecture 1• any kind of building block
![Page 8: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/8.jpg)
![Page 9: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/9.jpg)
![Page 10: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/10.jpg)
Components & Framework
• What is framework?• Subroutines libraries? No structure• Operating systems? Yes, but weak• CORBA, DCOM? Yes, but confined to
software • Interaction mechanisms? Yes, incorporate
hardware and software• We want: constraints + benefits
![Page 11: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/11.jpg)
Components & Framework
Framework
• A class library and policies
• Programming Languages• Operating System• DS & Middleware• Body System• Social/political System
Components
• Already existed methods• Language primitives (a,c) • Single processes/programs• Distributed components• Organs• Companies and
organizations
![Page 12: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/12.jpg)
Components & Framework
Framework
1. JavaBeans, COM, CORBA
2. Publish and Subscribe, Linda, JavaSpaces
3. Asynchronous message passing
4. Synchronous message passing
5. Discrete events
6. Continuous time
Interaction Mechanism
1. Unstructured events, no built-in synchronization
2. Event notification, 3. Processes send message through channels
that buffer msgs4. Processes communicate in atomic
instantaneous actions5. Components communicate via signals that
carry events placed in time, which is globally known by all components
6. Processes communicate via continuous-time signals, which are functions on the real numbers.
![Page 13: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/13.jpg)
Component-Based Model of Computation
• Which framework is best? • Your component• States of knowledge• Interaction mechanisms• Specialized, domain dependent!
![Page 14: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/14.jpg)
Component-Based Model of Computation
• Framework problem for embedded system? • We want: as unspecified as possible• Union all? too complex • Choose one? not using all advantages• Use an ADL may get a poor design match• Need a design language, not a descriptive
language!
![Page 15: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/15.jpg)
Component-Based Model of Computation
• The Type System • Ensure software correctness: good! OOP
works, but not for larger structure.• Constrains interface: good!• Ensure compatibility when composing: good!• Static syntax: bad!
![Page 16: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/16.jpg)
Component-Based Model of Computation
• Automata• Use automata to get interface assumptions • Capture dynamic interface properties• Automata give protocols for component
communication • Characterize services that each domain
provides• Use composition and hierarchy of automata
![Page 17: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/17.jpg)
Conclusions
• Components
• Frameworks
• Framework for embedded system
• Type System
• Automata
![Page 19: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/19.jpg)
What is an Interface Automaton?
• It is an automaton that can be used to determine if two interfaces are compatible
• For simplicity, I will refer to an Interface Automaton as P or Q
![Page 20: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/20.jpg)
An Interface Automaton
P = <VP, VPInit, AI
P, AO
P, AH
P, P> :
• VP is a set of states
• VPInit VP is a set of initial states.
• AIP, A
OP, and AH
P are mutually disjoint sets
of input, output, and internal actions.
Let AP = AIP AO
P AHP
P VP AP VP is a set of steps.
![Page 21: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/21.jpg)
Example Interface Automaton
• Vcomp = {0, 1, 2, 3, 4, 5, 6}
• VcompInit = {0}
• AIcomp = {msg, nack, ack} (?)
• AOcomp = {send, ok, fail} (!)
• AHcomp = (;)
comp = { (0,msg,1), (1,send,2),
(2,ack,5), … }
![Page 22: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/22.jpg)
Properties
• An action aAP is enabled at a state vVP if there is a step (v,a,v)P for some vVP
• AIP(v), AH
P(v), AOP(v) are the subsets of
actions that are enabled at state v• Interface automata are not required to be
input-enabled, that is we do not require AI
P(v) = AIP for all states vVP
• Shared(P,Q) = AP AQ
![Page 23: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/23.jpg)
Composition
• Two interface automata P and Q are composable if
AIP AI
Q = , AOP AO
Q =
AHP AQ = , AH
Q AP = • The composition P||Q of the two interface
automata is obtained by restricting the product P Q to its compatible (non-illegal) states
![Page 24: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/24.jpg)
User and Comp
Consider the product of User and Comp…
![Page 25: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/25.jpg)
Black Box Gives: User Comp
6 is an illegal state. Why? …
![Page 26: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/26.jpg)
Illegal States
• Illegal(User, Comp) = { (v,u) Vuser Vcomp | a Shared(User,Comp)
such that :
( a AOuser(v) and a ! AI
comp(u)) or
(aAOcomp(u) and a !AI
user(v)) }
• In User Comp, the output step (6,fail,0) of Comp has no corresponding input in User
![Page 27: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/27.jpg)
User || Comp
User Comp with illegal states removed, we need an environment so that no input will be generated, that will lead to an illegal state
![Page 28: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/28.jpg)
Legal Environment
• Given two composable interface automata P and Q, a legal environment for the pair (P,Q) is an environment for P Q such that no state in Illegal(P,Q) VE is
reachable in (P Q) E
• The existence of a legal environment for the composition of two interfaces indicates that the interfaces are compatible
![Page 29: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/29.jpg)
Environment for User Comp
• Channel is a legal environment for User Comp because the state (6,u), uVChannel is not reachable
![Page 30: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/30.jpg)
In Closing
• There are algorithms to generate the composition of two interface automata
• Two automata are compatible if there exists a legal environment for the composition
• Interface automata provide a concise and formal notation that parallels the natural way of evolving a component-based design
![Page 31: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/31.jpg)
Single-Threaded Interface Automata
By Josh Lessard, [email protected]
Programming Languages Group, School of Computer Science, University of Waterloo
![Page 32: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/32.jpg)
Introduction
• For uniprocessor systems, interface automata are unnecessarily complex
• Take advantage of single active thread of control
• Single-threaded version of interface automata
• Greatly reduces state space and gives rise to smaller automata
![Page 33: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/33.jpg)
Definition
• A single-threaded interface automaton (STIA) P is an interface automaton that satisfies two conditions:
![Page 34: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/34.jpg)
STIA Condition #1
The set VP of states is partitioned into two disjoint sets VP = VO
P VI
P. The states in VO
P are called running, because only internal and output actions are enabled: for all v VO
P, we have AIP(v) = . The states
in VIP are called waiting, because only input
actions are enabled: for all v VIP, we have
AOP(v) = AH
P(v) = .
![Page 35: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/35.jpg)
STIA Condition #2
All output steps must lead to waiting states: for all (u, a, v) O
P, we have v VIP.
Conversely, only output steps can lead to waiting states: for all v VI
P and all (u, a, v)
P, we have a AOP.
![Page 36: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/36.jpg)
STIA Conditions
• Condition 1 eliminates choice between output/internal actions (ie this automaton advancing thread) and input actions (ie some other automaton advancing thread)
• Running states indicate ownership of the single thread of control; waiting states indicate non-ownership
• Condition 2 ensures that an STIA waits for an input precisely after issuing an output action because if there is only a single thread of control, then each output step relinquishes that thread
![Page 37: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/37.jpg)
Single-Threaded Composition
• Special version of composition for STIAs
• Prunes input actions that occur at states where internal or output actions are also enabled
• Can do this because when in a running state, input for this automaton cannot be produced by other automata
![Page 38: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/38.jpg)
Single-Threaded Composition
Consider two composable STIAs P and Q. The single-threaded composition P|||Q is obtained from P||Q by first removing all steps (v, a, u) I
P||Q for which AOP||Q(v) AH
P||Q
(v) , and then removing all states that become unreachable from Vinit
P||Q.
![Page 39: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/39.jpg)
Example
![Page 40: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/40.jpg)
Example
Invalid input steps removed:
![Page 41: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/41.jpg)
Example
Unreachable states removed:
![Page 42: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/42.jpg)
Conclusion
• Four of the nine states were eliminated (nearly 50%)!!!
• Complexity was greatly reduced• When modelling for uniprocessor systems,
STIAs are a good way to remove clutter from diagrams by doing away with states that are unreachable due to the nature of single threaded systems
![Page 43: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/43.jpg)
Summary of our talk
By Real Xu, [email protected]
User Interface Group, School of Computer Science, University of Waterloo
![Page 44: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/44.jpg)
Summary of our talk
• Why Interface Automata?
• What is Interface Automata?
• How to Use Interface Automata Efficiently?
• Why?- What?- How?
• Future work
![Page 45: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/45.jpg)
Why?- What?- How?
![Page 46: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/46.jpg)
Why?- What?- How?
![Page 47: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/47.jpg)
Why?- What?- How?
• I/O Automata [N. Lynch, M.Tuttle 1989]
• A labelled transition system model• Asynchronous concurrent systems• Actions classified: input (labelled), output,
internal
![Page 48: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/48.jpg)
Why?- What?- How?
![Page 49: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/49.jpg)
Why?- What?- How?
I/O Automata
• What does it do?• Component• Input universal• Pessimistic: compatible if
no error can arise• Based on transition
systems
Interface Automata
• How it can be used?• Interface• Input existential• Optimistic: compatible if
errors can be avoided• Based on game theory
![Page 50: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/50.jpg)
Why?- What?- How?
I/O Automata
• Composition is easy: simply compute the product
• Verification is complex: need to verify that the interface are compatible
Interface Automata
• Composition is complex: requires compatibility check
• Verification is easy: none needed generally
![Page 51: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/51.jpg)
Future Work
• How to adapt to object – orientated code?
• How to model dynamic object creation?
• How to connect to the real software?
![Page 52: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/52.jpg)
Acknowledgement• R.E.Johnson, “Frameworks = (Components + Patterns),” Comm. ACM, Oct. 1997, pp.39-42• T.A.Henzinger, “The Theory of Hybrid Automata,” Proc. 11th Symp. Logic in Computer Science, IEEE CS Press, Los Alamitos,
Calif., 1996, pp278-292• L. de Alfaro, T.A. Henzinger. Interface Automata. In Proceedings of the Joint 8th European Software Engineering Conference and
9th ACM SIGSOFT International Symposium on the Foundations of Software Engineering (ESEC/FSE 01)• Luca de Alfaro and Thomas A. Henzinger. Interface Theories for Component-Based Design. Proceedings of the First International
Workshop on Embedded Software (EMSOFT '01), Lecture Notes in Computer Science 2211, Springer-Verlag, 2001, pp. 148-165. • L. de Alfaro, T.A. Henzinger, R. Jhala. Compositional Methods for Probabilistic Systems. In Proceedings of CONCUR 01:
Concurrency Theory, 12th International Conference, Lectures Notes in Computer Science, Springer-Verlag, 2001.• L. de Alfaro, T.A. Henzinger, R. Majumdar. Symbolic Algorithms for Infinite-State Games. Proceedings of CONCUR 01:
Concurrency Theory, 12th International Conference, Lectures Notes in Computer Science, Springer-Verlag, 2001• L. de Alfaro, T.A. Henzinger, F.Y.C. Mang. The Control of Synchronous Systems. Concurrency Theory, Lectures Notes in
Computer Science, Springer-Verlag, 2001• L. de Alfaro, T.A. Henzinger, F.Y.C. Mang. Detecting Errors Before Reaching Them. Computer-aided Verification, Lectures Notes
in Computer Science 1855, pages 186-201, Springer-Verlag, 2000• Nancy Lynch and Mark Tuttle. An introduction to Input/Output automata. CWI-Quarterly, 2(3):219--246, September 1989.
Centrum voor Wiskunde en Informatica, Amsterdam, The Netherlands• Edward A. Lee, "Overview of the Ptolemy Project," Technical Memorandum UCB/ERL M01/11, University of California, Berkeley,
March 6, 2001• Xiaojun Liu, Jie Liu, Johan Eker, and Edward A. Lee, "Heterogeneous Modeling and Design of Control Systems," to appear in
Software-Enabled Control: Information Technology for Dynamical Systems, T. Samad and G. Balas (eds.), New York City: IEEE Press, 2002.
• Edward A. Lee, “What’s Ahead for Embedded Software?” IEEE 33:18-26, 2000• Edward A. Lee, Y. Xiong. System-level Types for Component-based Design. Technical Memorandum UCB/ERL M00/8,
Electronics Research Lab, University of California, Berkeley, 2000
![Page 53: I/O & Interface Automata](https://reader035.fdocuments.us/reader035/viewer/2022062517/5681536d550346895dc17077/html5/thumbnails/53.jpg)
Thanks for involvements and questions and answers!