SystemLevel Types for ComponentBased Design Edward A Lee

System-Level Types for Component-Based Design Edward A. Lee Yuhong Xiong Department of Electrical Engineering and Computer Sciences University of California at Berkeley Presented at EMSOFT, Lake Tahoe, October 2001.

Outline n Component-based design n System-level types n Interface Automata n Interaction Types and Component Behavior n Type Checking n Type Order and Polymorphism n Design Tradeoffs n Conclusion Lee & Xiong,

Component-Based Design n Good for designing complex, concurrent, heterogeneous systems n Two levels of interface: data types and n dynamic interaction n n Key aspects of dynamic interaction: communication & execution Lee & Xiong,

Type Systems n Type systems are successful n Safety through type checking n Polymorphism supports reuse (flexible components) n Interface documentation, clarification n Run-time reflection of component interfaces n Data types only specify static aspects of interface n Proposal: n Capture the dynamic interaction of components in types n Obtain benefits analogous to data typing. n Call the result system-level types. Lee & Xiong,

Interaction Semantics n Flow of control issues (“execution model” - Sifakis) n in Ptolemy II, these are defined by a Director class n Communication between components (“interaction model”) n in Ptolemy II, this is defined by a Receiver class Actor interface for execution: fire Receiver interface for communication: put, get, has. Token Lee & Xiong,

Models of Computation n Define the interaction semantics n Implemented in Ptolemy II by a domain n Receiver + Director n Examples: n n n 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,

Receiver Object Model Lee & Xiong,

Formal Interaction Semantics: Use Interface Automata n Automata-based formalism Proposed by de Alfaro and Henzinger n Optimistic n Concise composition n n Compatibility checking Done by automata composition n Captures the notion “components can work together” n n Alternating simulation (from Q to P) All input steps of P can be simulated by Q, and n All output steps of Q can be simulated by P. n Provides the ordering we need for subtyping & polymorphism n n A key theorem about compatibility and alternating simulation Lee & Xiong,

Example: SDF Consumer Actor Inputs: Outputs: f fire f. R Return from fire t Token g get h. T has. Token h. TT Return True from has. Token h. TF Return False from has. Token Lee & Xiong,

Type Definition - SDFDomain Lee & Xiong,

Type Definition - DEDomain Lee & Xiong,

Component Behavior SDF Consumer Actor Lee & Xiong,

Type Checking SDF Consumer Actor in SDFDomain Compose SDF Consumer Actor Lee & Xiong,

Type Checking SDF Consumer Actor in SDFDomain Lee & Xiong,

Type Checking SDFActor in DEDomain Compose SDF Consumer Actor n Empty automata indicating incompatibility Lee & Xiong,

Alternating Simulation SDF to DE DEDomain SDFDomain Lee & Xiong,

System-Level Type Order Defined by Alternating Simulation n Analogous to subtyping n If an actor is compatible with a certain type, it is also compatible with the subtypes Lee & Xiong,

Component Behavior Domain. Polymorphic. Actor Lee & Xiong,

Domain. Polymorphic. Actor is Compatible with DEDomain Compose Poly Actor Lee & Xiong,

So it is also Compatible with SDFDomain Compose Poly Actor Lee & Xiong,

Trade-offs in Type System Design n Amount of property checked vs. cost of checking n Static vs. run-time checking n Example of more static checking: deadlock detection in Dining Philosopher model n Bottom line: static checking of communication protocols a good starting point Lee & Xiong,

Conclusion and Future Work n We capture dynamic property of component n n 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. Lee & Xiong,