Subsections

• 2.1.1 MIL Types
• 2.1.2 Library and Module Types
• 2.1.3 Unit Type
• 2.1.4 System Type
• 2.1.5 Operations

2.1 Overview of ASDL

This section provides an overview of the Z schemas [Spi89] that represent the software types and operations of ASDL . These types and operations embody our perspective on the essential features of component-based software design methodologies, and the overview therefore corresponds to an outline of our position. A more detailed description can be found in [RS96b]. Examples are given to show how this perspective can be used to specify several important aspects of styles that are associated with component-based software development methodologies, including (a) interface and execution semantics, (b) software system evolution, and (c) relationships between different views of a software system.

2.1.1 MIL Types

In previous research [RS94], we have shown how the essential features of a module interconnection language can be specified with Z schemas. These schemas have been incorporated into ASDL with only minor changes. The corresponding MIL types specify the syntax and static semantics of component interfaces and system modules, respectively. The first (Library ) schema specifies a library type that provides a collection of templates that describe the interfaces of computational components. A template consists of ports that are used for sending and receiving data; each port has a set of attributes that represent the direction of data movement, the type of the data, and application-dependent information. Some templates are identified as primitive templates ; these correspond to component interfaces that have been preloaded into the library. Others represent interfaces of encapsulated modules that have been placed in the library.

The second (Setting ) schema specifies a module type based on the library type. It consists of a set of nodes and a set of connections that are defined by shared labels . The nodes represent computational components that are instantiated from library templates. The ports on an instantiated node are called slots . A label shared by two or more slots creates a connection that can be used for data movement between the corresponding nodes.

2.1.2 Library and Module Types

In ASDL , the MIL types have been extended to support the specification of execution semantics. The templates in the extended Library schema have two additional features: object attributes and semantic interpretations . The new schema can be thought of as a semantic library type . The object attributes are specified by a part mapping that provides application-dependent information. The semantic interpretations are specified by an interp mapping that associates a CSP [Hoa85] process with each template. For example, if a template has two ports p and q with direction attributes in and out , respectively, then the CSP process $\mathit{interp}(\tau) =\, ^{*}\!(p ? x \to q ! x \to Skip )$ specifies that the template behaves as a non-terminating copy operation.

The extended Setting schema contains a composition expression that specifies how the components corresponding to the nodes in a module are executed, and a semantic description mapping that assigns a semantic abbreviation to each label used in a module. A composition expression is a restricted type of CSP process in which node names are viewed as processes. For example, it may specify that the components will be executed in parallel. A semantic abbreviation associated with a label represents a communication protocol and may include application-dependent information, such as data transfer rates and timing requirements. For example, it may specify bidirectional asynchronous communication and a maximum buffer size. The execution semantics of a module are derived from the semantic interpretations of the templates underlying the nodes, the composition expression, and the semantic descriptions of the labels that specify the connections between nodes. The extended Setting schema can therefore be thought of as a semantic module type that describes the components of a module and contains the information needed to execute the module. The following examples illustrate the use of library and module types.

(a) The Processing Graph Method (PGM ) [KS95,RS96a] is a component-based software development methodology developed by the US Naval Research Laboratory for signal processing applications. For PGM , a module type corresponds to a graph whose nodes correspond to components that perform signal processing operations. The primitive templates underlying the nodes belong to two categories: transitions that represent computations and data restructuring operations and places that represent data transfers between transitions. Slots of the same port type on nodes instantiated from templates of different category may be connected by directed arcs that indicate data movement.

ASDL can be used to describe the semantics associated with the interfaces of PGM nodes. For example, $part(\tau) = G\_Var(T)$ specifies that is a place template (specifically, a rewritable graph variable that can hold a single token of type T with one input (INPUT) and one output (OUTPUT) port. Its interpretation is a CSP process

that specifies that is willing to receive or send data on the channels that correspond to links to ports on other nodes. The sets R and S index the nodes that are linked to the INPUT and OUTPUT port, respectively.

The interpretation of a transition template enforces PGM 's dataflow methodology, in which the execution of a node instantiated from the template is triggered by the arrival of sufficient data at its input slots. The composition expression specifies the concurrent execution of the components corresponding to the nodes in a module and the semantic description of each label specifies unidirectional synchronous transfer of data.

(b) The composition expression can also describe the dynamic evolution of a module within a component-based development environment. In this case, the alphabet of the process representing the expression includes special event names corresponding to the ASDL operations (see 2.1.5) that are used. For example, the following portion of a composition expression describes the creation of a client node C instantiated from a template and its connection to one of the server nodes S₁ and S₂ using a label L with the semantic abbreviation bac (bidirectional asynchronous communication):

2.1.3 Unit Type

The Setting schema and its associated operations show how a module can be constructed from library components. Such a module is a self-contained computational unit without any external connections. The Unit schema corresponds to a unit type that describes these connections and the associated interface semantics. It includes a set of virtual ports that represent the ``public'' interfaces of the unit and a mapping that gives the attributes of these ports. The schema also includes a connect mapping that describes the links between slots and virtual ports and a virtual_port_descr mapping that describes the semantics of the virtual ports. This information represents the interface semantics of a unit. The Unit schema imposes only a minimal restriction on the interface that requires the direction of data movement to be consistent. Further restrictions are derived from application-dependent information about the desired behavior of units. For example, type consistency requirements may be placed on the connect mapping, and the virtual_port_descr mapping may specify broadcasting or multiplexing behavior for a virtual port. The following example illustrates how unit types can be used to describe an aspect of a hybrid system that includes hardware as well as software.

(c) A computer in a network can be represented as a unit type, where the nodes correspond to sockets, and their connections to virtual ports correspond to the assignment of sockets to services such as ftp or telnet. The interface_attr mapping specifies standard information such as the Internet address and port number. Since a port can be linked to more than one socket, ports must support multiplexing of messages. The semantics of a virtual port p is specified as $\mathit {virtual\_port\_descr}(p) = Receive \, \square \, Send$, where

number(msg) is the local socket number identifying the destination of the message msg , and K corresponds to the computer's set of network connections.

In [RS94], a top-down component-based design methodology was modeled by using a family of generic connector templates. ASDL supports a more straightforward representation of this methodology, since it provides an operation to incorporate a special unit type into an existing module. The included unit corresponds to an empty module. Although this unit is not a node, it has slots that can be used to specify connections to other nodes. The internal structure of such a unit can be constructed later, thereby providing the desired top-down design capability.

2.1.4 System Type

The System schema includes the Library schema as well as architectural state information: the modules and units that have been used to describe logical views of a component-based system, the relationships between units and modules, the connection between the library templates that have been constructed by encapsulating units and the corresponding unit types, and architectural connections between different logical views.

2.1.5 Operations

ASDL provides a number of generic operations that support the incremental specification of the software types by updating the System schema. These serve as guides for the design of application-dependent operations that are constructed by adding new signatures and constraints to existing operations, or by incorporating existing operations into a new operation. The operations include setting operations to create and delete nodes, assign labels to slots, specify a composition expression, and select semantic abbreviations, interface operations to specify virtual ports, attributes, links, and virtual port descriptions, an encapsulation operation to create a new library template from a unit, and relation operations to specify and modify relations between units.

The encapsulation operation creates a new library template from an existing unit type. The virtual ports of the unit type become the ports of the template and the attributes of these ports are derived from the unit's interface. The template's interpretation is derived from the interpretations of the templates underlying the nodes, the composition expression, the abbreviations of labels, and the semantics of the virtual ports. This represents a complex synthesis of the semantics of the entities associated with the unit. In general, it may not be possible to construct a ``closed form'' interpretation of a template, due to the presence of partial and heterogeneous information. The new library template can, in turn, be used to create a node in another module. ASDL permits an application-dependent interpretation of the extent to which the internal structure of the node is visible in the new module. For example, if encapsulation requires that each virtual port is linked to a node in the underlying unit, then one interpretation is that only the resources of the nodes linked to the port can be accessed through the port. On the other hand, if encapsulation permits a virtual port with no links, then another interpretation may allow characteristics of the node to be modified by using the port.