Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Extensible Type System for Component-Based Design

Similar presentations

Presentation on theme: "An Extensible Type System for Component-Based Design"— Presentation transcript:

1 An Extensible Type System for Component-Based Design
Yuhong Xiong Advisor: Professor Edward A. Lee Department of Electrical Engineering and Computer Sciences University of California at Berkeley Type system for Ptolemy II.

2 Component-Based Design
Good for designing complex, concurrent, heterogeneous systems Two levels of interface: data types and dynamic interaction: communication & execution We propose a type system to address the constraints at these two levels Let me first describe a general issue. We all know that component-based design is good for designing complex, heter. systems. In this approach, when we interconnect the components to form a system, we naturally want the interfaces of components to be compatible in some sense. There are at least two levels of compatibility: data types and dynamic behavior. For data types, if these two components communicate through some sort of message passing using typed data, the type here at this port must be compatible with the type here. For example, if this component expects to receive doubles, this one should either send out doubles, or something that can be converted to doubles. Otherwise, they won’t be able to work together. In addition, components may have internal states, such as a parameter that the user can set to configure the component. In this case, there may also be type constraints between the type of the parameter and the type of the port. At the behavioral level, (if components communicate through message passing,) there are many different ways for the components to send and receive messages. For example, their communication can be synchronous or asynchronous. Therefore, we also want the communication protocols used by the components to be compatible. Because of these constraints, we need a system that allows us to specify the constraints and ensure that they are satisfied.

3 Data Type Lattice Organize all types in a lattice structure
This example lattice specifies lossless type conversion relation General String Boolean Scalar Long Complex Double Now let me get to the detailed formulation of our system. We organize all the types into a lattice structure called type lattice. This picture is an example of a type lattice. The relation in this lattice is the subtyping relation among various types. There are two kinds of subtyping relations, ad hoc subtyping and the traditional OO style subclassing. Ad hoc subtyping is essentially the type conversion relation. For example, an int can be converted to a double, and it can also be converted to complex. Using standard lattice terminology, a type A is less than a type B if there is an upward path from A to B. For example, Int is less than Double. Two types can be incomparable. For example, Complex and Boolean are incomparable. Int Unknown

4 Type Compatibility Rule
sendType  receiveType Static type checking Type conversion Double Double Complex Double Complex Boolean Given the type lattice, we can define a simple type compatibility rule, which says that the type of an output port here, must be either the same as the type of the connected input, or be less than the type of the input. According to this rule, this topology is well typed, but this one has two type errors. In particular, the type here, Complex, is greater than the type here, and Complex and Boolean are incomparable. These kinds of errors can be detected statically before the model executes. OK OK

5 Type Constraints a  g b  g g  Complex Int  a g  Complex g a Complex Int b Double  b In addition to the constrains specified by the actors, the interconnection of components also imply constraints. (Constraint by type compatibility rule ) For example, across this connection, we naturally want the type here, int, to be less than or equal to the type here, alpha. Similarly, we have this, and this constraints. Now the problem of type resolution becomes one of solving a set of inequalities. We need an algorithm for that. Double Efficient algorithm (Rehof & Mogensen) can find least solution

6 Structured Types (arrays and records)
Goals: Arbitrary element types. E.g. (int)array, ((int)array)array, array of records, records containing arrays, … Type constraints between element types and the types of other objects in system Questions: Order relation among structured types? Structured types admitted by the inequality solving algorithm? Convergence on infinite lattice? The thing we want to support with structured types are the following: First, we want to support arbitrary element types. For example, we can have an array of int, or an array of array of int, which can be viewed as 2-D arrays. We can also have an array of record, or record containing arrays. Basically, we want to allow the structured types to be arbitrarily nested. Second, we want to be able to specify type constraints between the element types of a structured type, and the type somewhere else in the system. For example, we want to be to able to say: I want the type of a parameter to be an array, and I want the element type of this array to be the same as the type of another port. To support these goals, we need to answer some questions. First, we need to give the various array and record types an order relation so that they fit into the type lattice; second, we need to check whether structured types can be handled by the inequality solving algorithm we use; in addition, since there are an infinite number of array and record types, their addition makes the type lattice infinite. So we need to check whether type resolution always converges. Now, let’s look at these 3 questions one by one.

7 Actors Manipulating Structured Types
SequenceToArray ArrayToSequence ArrayAppend ArrayElement ArrayExtract ArrayLength RecordAssembler RecordDisassembler RecordUpdater a a Array SequenceToArray item {item: a Array, val: b Array} RecordAssembler b val SequenceToArray b Array

8 Monotonic Functions in Type Constraints
Example: AbsoluteValue Actor Works for Int, Long, Fix, Double, Complex Output type is the same as the input, unless input is Complex Output type is Double when input is Complex a b Complex Complex f f f(a)  b, where f(a) = Double if a = Complex = a otherwise Double Double f Int Int

9 Behavioral Type Data types only specify static aspects of interface
Proposal: Capture the dynamic interaction of components in types Use interface automata (de Alfaro & Henzinger) Obtain benefits analogous to data typing Call the result behavioral types Experimental platform: Ptolemy II The above is a type system that controls the data type at the component interface. There are other dynamic properties in the interface, such as the protocols used by a component to interact with other components. We suggest to augment the the type system to capture some of these properties, using the communication protocols as a start. To do this, we need a way to describe the communication protocols, or types, and an ordering relation between these types. We suggest to describe the protocols using automata, and the ordering relation between them is the simulation relation. At the early stage of this work, have a starting point.

10 Interaction Semantics
Flow of control issues in Ptolemy II, these are defined by a Director class Communication between components in Ptolemy II, this is defined by a Receiver class Actor interface for execution: fire Receiver interface for communication: put, get, hasToken

11 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

12 Example: Synchronous Dataflow (SDF) Consumer Actor Type Definition
communication interface Such actors are passive, and assume that input is available when they fire. execution interface Inputs: Outputs: f fire t Token hTT Return True from hasToken hTF Return False from hasToken fR Return from fire g get hT hasToken

13 Type Definition – Synchronous Dataflow (SDF) Domain
receiver interface director interface

14 Type Checking – Compose SDF Consumer Actor with SDF Domain

15 Type Checking – Compose SDF Consumer Actor with DE Domain
Empty automaton indicates incompatibility Composition type has no behaviors

16 Subtyping Relation Alternating Simulation: SDF  DE
DE Domain SDF Domain

17 Behavior-Level Type Lattice – Defined by Alternating Simulation
domain polymorphic Subtyping relation Shown here for a few Ptolemy II domains If an actor is compatible with a certain type, it is also compatible with the subtypes discrete events communicating sequential processes process networks synchronous dataflow unknown

Download ppt "An Extensible Type System for Component-Based Design"

Similar presentations

Ads by Google