Upload
gwylan
View
36
Download
4
Embed Size (px)
DESCRIPTION
System-Level Types for Component-Based Design. Edward A. Lee Yuhong Xiong. Presented at EMSOFT, Lake Tahoe, October 2001. Outline. Component-based design System-level types Interface Automata Interaction Types and Component Behavior Type Checking Type Order and Polymorphism - PowerPoint PPT Presentation
Citation preview
Department of Electrical Engineering and Computer SciencesUniversity of California at Berkeley
System-Level Types forComponent-Based Design
Edward A. LeeYuhong Xiong
Presented at EMSOFT, Lake Tahoe, October 2001.
Lee & Xiong, 2
Outline
Component-based design System-level types Interface Automata Interaction Types and Component Behavior Type Checking Type Order and Polymorphism Design Tradeoffs Conclusion
Lee & Xiong, 3
Component-Based Design Good for designing complex, concurrent,
heterogeneous systems Two levels of interface:
data types and dynamic interaction
Key aspects of dynamic interaction: communication & execution
Lee & Xiong, 4
Type Systems Type systems are successful
Safety through type checking Polymorphism supports reuse (flexible components) Interface documentation, clarification Run-time reflection of component interfaces
Data types only specify static aspects of interface
Proposal: Capture the dynamic interaction of components in types Obtain benefits analogous to data typing. Call the result system-level types.
Lee & Xiong, 5
Interaction Semantics Flow of control issues (“execution model” - Sifakis)
in Ptolemy II, these are defined by a Director class Communication between components (“interaction model”)
in Ptolemy II, this is defined by a Receiver class
produceractor
consumeractor
IOPort
Receiver
Director
Actor interface for execution: fireReceiver interface for communication: put, get, hasToken
Lee & Xiong, 6
Models of Computation Define the interaction semantics Implemented in Ptolemy II by a domain
Receiver + Director Examples:
Communicating Sequential Processes (CSP): rendezvous-style communication
Process Networks (PN):asynchronous communication
Synchronous Data Flow (SDF):stream-based communication, statically scheduled
Discrete Event (DE):event-based communication
Synchronous/Reactive (SR):synchronous, fixed point semantics
Lee & Xiong, 7
Receiver Object ModelIOPort
FIFOQueue
1..1
1..1
«Interface»Receiver
+get() : Token+getContainer() : IOPort+hasRoom() : boolean+hasToken() : boolean+put(t : Token)+setContainer(port : IOPort)
0..1 0..n
QueueReceiver
NoRoomException
throwsNoTokenException
throws
PNReceiver
«Interface»ProcessReceiver
CSPReceiver
SDFReceiver
ArrayFIFOQueue
1..11..1
DEReceiverMailbox
CTReceiver
Lee & Xiong, 8
Formal Interaction Semantics:Use Interface Automata Automata-based formalism
Proposed by de Alfaro and Henzinger Optimistic Concise composition
Compatibility checking Done by automata composition Captures the notion “components can work together”
Alternating simulation (from Q to P) All input steps of P can be simulated by Q, and All output steps of Q can be simulated by P. Provides the ordering we need for subtyping & polymorphism
A key theorem about compatibility and alternating simulation
Lee & Xiong, 9
Example: SDF Consumer Actor
fR Return from fireg gethT hasToken
f firet TokenhTT Return True from hasTokenhTF Return False from hasToken
Inputs: Outputs:
Lee & Xiong, 10
Type Definition - SDFDomain
produceractor
consumeractor
IOPort
Receiver
Director
Lee & Xiong, 11
Type Definition - DEDomain
Lee & Xiong, 12
Component BehaviorSDF Consumer Actor
Lee & Xiong, 13
Type CheckingSDF Consumer Actor in SDFDomain
ComposeSDFDomain SDF Consumer Actor
Lee & Xiong, 14
Type CheckingSDF Consumer Actor in SDFDomain
Lee & Xiong, 15
Type CheckingSDFActor in DEDomain
Empty automata indicating incompatibility
ComposeDEDomain SDF Consumer Actor
Lee & Xiong, 16
Alternating SimulationSDF to DE
SDFDomain DEDomain
Lee & Xiong, 17
System-Level Type OrderDefined by Alternating Simulation
Analogous to subtyping If an actor is compatible
with a certain type, it is also compatible with the subtypes
NaT
PN
SDF
DE
CSP
DP
Lee & Xiong, 18
Component BehaviorDomainPolymorphicActor
Lee & Xiong, 19
DomainPolymorphicActor is Compatible with DEDomain
ComposeDEDomain Poly Actor
Lee & Xiong, 20
So it is also Compatible with SDFDomain
ComposePoly ActorSDFDomain
Lee & Xiong, 21
Trade-offs in Type System Design
Amount of property checked vs. cost of checking
Static vs. run-time checking
Example of more static checking: deadlock detection in Dining Philosopher model
Bottom line: static checking of communication protocols a good starting point
Lee & Xiong, 22
Conclusion and Future Work We capture dynamic property of component
interaction in a type system framework: system-level types
We describe interaction types and component behavior using interface automata.
We do type checking through automata composition.
Subtyping order is given by the alternating simulation relation, supporting polymorphism.
We can reflect component state in a run-time environment, providing system-level reflection.