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

2. 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

3. 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

4. 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.

5. 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 Actor interface for execution: fire Receiver interface for communication: put, get, hasToken

6. 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

7. Lee & Xiong, 7 Receiver Object Model

8. 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

9. Lee & Xiong, 9 Example: SDF Consumer Actor fRReturn from fire gget hThasToken ffire tToken hTTReturn True from hasToken hTFReturn False from hasToken Inputs: Outputs:

10. Lee & Xiong, 10 Type Definition - SDFDomain

11. Lee & Xiong, 11 Type Definition - DEDomain

12. Lee & Xiong, 12 Component Behavior SDF Consumer Actor

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

14. Lee & Xiong, 14 Type Checking SDF Consumer Actor in SDFDomain

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

16. Lee & Xiong, 16 Alternating Simulation SDF to DE SDFDomain DEDomain 

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

18. Lee & Xiong, 18 Component Behavior DomainPolymorphicActor

19. Lee & Xiong, 19 DomainPolymorphicActor is Compatible with DEDomain Compose DEDomain Poly Actor

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

21. 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

22. 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.