System-Level Types for Component-Based Design Paper by: Edward A. Lee and Yuhong Xiong Presentation by: Dan Patterson

Outline 1 Introduction 2 Ptolemy II – A Component-Based Design Environment 3 Overview of Interface Automata 3.1 An Example 3.2 Composition and Compatibility 3.3 Alternating Simulation 4 System-Level Types 4.1 Type Definition 4.2 System-Level Type Order and Polymorphism 4.3 Type Checking Examples 4.4 Reflection 5 Trade-offs in Type System Design 6 Conclusion and Future Work

1. Introduction Modern polymorphic type systems have led to considerable improvements in development productivity and software quality. Component-based design helps to handle complexity. Type systems ensure component compatibility by detecting mismatch at component interfaces. This paper extends type systems to capture the dynamic aspects of component interaction. The design of system-level types shares the same goals and trade-offs with the design of a data-level type system.

1. Introduction Researchers formed a polymorphic type system at the system-level through an approach similar to subtyping, where the interaction types were organized in a partial order to facilitate the design of polymorphic components and simplify type checking. Because no type system can capture all the properties of programs and keep the language flexible, certain compromises have to be made as to what properties to include in the system They chose to check the compatibility of communication protocols as the starting point because they are the central piece of many models of computation and it can be done efficiently.

2 Ptolemy II – A Component-Based Design Environment Ptolemy II is a system-level design environment that supports component-based heterogeneous modeling and design. Components are called actors, the channel of communication is implemented by a receiver. Ptolemy II is implemented in Java and the methods of the receiver are defined in a Java interface Receiver. Only assumption made is that of a producer/consumer model. Each actor interacts with the receivers in the following domains: Communicating Sequential Processes (CSP) Process Networks (PN) Synchronous Data Flow (SDF) Discrete Event (DE)

3.1 Overview of Interface Automata - An Example Interface automata model for an implementation of the consumer actor. Important that not all inputs always enabled. In SDF domain actor assumes that its fire() method will not be called again if it is inside the this method.

3.1 Overview of Interface Automata An Example / Fig. 2 ?=input !=output ;=internal Fire() method Invocation return Get() method Invocation Token return Token() method Invocation Return true Return false Start Fire() called Calls get() Token rec’d Fire() returns

3.2 Overview of Interface Automata Composition and Compatibility If two interface automata have disjoint transitions except for 1 input and output, they can be composed. This shared input and output is called a shared transition, and it is taken synchronously as an internal transition of the composition. Illegal states and states that can reach illegal states through output or internal transitions are pruned out. Compatibility: Two automata are compatible if their composition is not empty. Yields a straightforward algorithm for type checking.

3.2 Overview of Interface Automata Composition and Compatibility F.3,4 Two (artificial) director automata The composition of the artificial directors with the SDF Actor

3.3 Overview of Interface Automata Alternating Simulation For two interface automata P and Q, there is an alternating simulation relation from Q to P if: All the input steps to P can be simulated by Q. All the output steps of Q can be simulated by P.

4.1 System-Level Types – Type Definition / Fig 5 If not SDF, can’t assume that token present when fired. If token not present, returns to state 0. Simple example of domain-polymorphism. Interface w/ director Interface w/ receiver

4.1 System-Level Types – Type Definition / Fig 6 Interface automaton modeling the director and receiver for SDF domain Put() method call return “Director interface” “Receiver interface”

4.1 System-Level Types – Type Definition / Fig 7 Type signature for DE domain Actor may be fired without a token being put into the receiver at its input

4.1 System-Level Types – Type Definition / Fig 8 Type signature for CSP domain. Each actor runs on its own thread, and communication is synchronous Get() before put() Put() before get()

4.1 System-Level Types – Type Definition / Fig 9 Type signature for PN domain. Each actor runs on its own thread, and communication is asynchronous Get() before put() Put() before get()

4.2 System-Level Types – Order and Polymorphism In the set of all domain types, the alternating simulation relation induces a partial order, or system-level type order. Automaton lower in the hierarchy can simulate all the input steps of the ones above it, and the automaton higher in the hierarchy can simulate all the input steps of the ones above it. SDFDomain is a subtype of DEDomain and all others above it. NaT = Not a Type and DP = Domain Polymorphic

4.3 System-Level Types – Type Checking Examples / Figs.11-2 Composition of SDFActor with SDFDomain – because nonempty, they are compatible Composition of SDF Actor with DE domain – empty because incompatible because actor may call get() when there is not token in the receiver

4.3 System-Level Types – Type Checking Examples / Fig 13 Composition of DEDomain with PolyActor, which checks presence of token before reading from receiver

4.3 System-Level Types – Type Checking Examples / Fig 14 Since SDFDomain is below DEDomain in the system-level type order, PolyActor can work in the SDFDomain. As a sanity check, here is composition of SDFDomain with PolyActor.

4.4 System-Level Types - Reflection Another interesting use of automata is to reflect the component state in a run-time environment. Runs in parallel with a component, making a transition when component does that reflects what state the component is in Can obtain state of component by querying automaton.

5 Trade-offs in Type System Design Scope can be broadened from examples by adding actors, making a more detailed director, and adding features like deadlock freedom – but this increases the cost of type checking. Also there is a trade-off between static and run- time type checking – by increasing run-time checking, some of the burden can be taken off of static checking. Completely relying on run-time type checking makes it merely a debugging tool.

6 Conclusion and Future Work Interaction types and component behavior are described by interface automata, and type checking is done through automata composition. By having a domain polymorphic approach, a component may be compatible with multiple interaction types. Relation among the interaction types is captured by a system-level type order using the alternating simulation relation of interface automata. The system can be extended and design involves a set of trade-offs Reflection automata can provide information on when mutation is safe, and can be powerful debugging tools. Type system may facilitate the design of new components or Ptolemy II domains. It might be possible to show that the composition of a domain director and a group of actors behaves like a polymorphic actor in other domains.