Next: Connector Type
Up: Component
Previous: Establish

Connector

Description

In UniCon software systems are described in terms of two kinds of distinct, identifiable elements: components and connectors.

A connector is an abstraction that represents the locus of definition for a relation among components. A connector mediates interactions among components; that is, it establishes the rules that govern component interactions and specifies any auxiliary implementation mechanisms required for realizing the interactions in the final system. A connector does not in general correspond individually to a compilation unit, but rather manifests itself in the final system as table entries, buffers, instructions to a linker, dynamic data structures, sequences of system calls embedded in source code, initialization parameters, etc.

Components interact with other components in a system in very distinct ways. These distinctions separate component interactions into classes, or types. A connector type captures the semantics of a particular class of interactions, assertions about that class, and the responsibilities and requirements that players in components must satisfy in an interaction from the class.

A connector has a specification, called a protocol, and an implementation. The protocol defines the allowable interactions among a collection of components and provides guarantees about those interactions.

The protocol defines:

the connector type
assertions that constrain the entire connector; these are the commitments about the interaction that the protocol supports (properties)
units of association through which the connector mediates the interactions among components (roles)

A connector type expresses the designer's intention about the general class of connection to be provided by the connector; it restricts the numbers, types, and specifications of properties and roles. In particular some properties may or may not be required for a given connector type; additionally, some roles may require associations with players, some may not require them but constrain them if present, and some may be restricted to match players of certain types.

Properties can be thought of as attributes of a definition which are used to further describe (i.e., specify) it. They are global assertions and constraints that apply to the definition as a whole. There are many places in UniCon where lists of properties are used to further specify a definition. In connector protocols, properties are used to specify information such as rules about timing or ordering.

Roles are the visible semantic units through which the connector mediates the interactions among components. Their types are primitive typing units used to identify the players that must cooperate in a successful interaction. It is through associations of players to roles that interactions of components are mediated by connectors. Roles define the kinds of interactions a connector can establish - the kinds of components that can interact, and the player types that are involved. Roles form the bulk of the protocol.

The implementation of a connector can be primitive or composite, however only primitive implementations are supported at present - we do not fully understand composite implementations in a connector yet. We are currently engaged in research to understand the implementation implications of first-class connectors; we hope to someday use the results to specify and generate connectors and their implementations from specifications in semi-formal notations. This will give us insight into the problem of how to specify connectors with composite and user-defined implementations.

Syntax

The following is the syntax for a connector definition in UniCon:

  <connector> :==  
    CONNECTOR <identifier>
      <protocol>
      <connector_implementation>
    END <identifier>

  <protocol> :==  
    PROTOCOL IS
      TYPE <connector_type>
      <property_list>
      <role_list>
    END PROTOCOL

  <connector_type> :== 
    DataAccess
    | FileIO
    | Pipe
    | PLBundler
    | ProcedureCall
    | RemoteProcCall
    | RTScheduler

  <connector_implementation> :==
    IMPLEMENTATION IS
      BUILTIN
    END IMPLEMENTATION

The properties in a <property_list> are separated by whitespace (i.e., spaces, tabs, and carriage returns). A <property_list> can be empty (in many cases), or it may contain one or more properties. A <property> is a name-value pair that specifies an attribute, an assertion, or a constraint pertaining to a definition. It is used to further specify that definition. The syntax of a property is as follows:

  <property> :== <name> <value>

  <name> :== <identifier>

  <value> :== 
    EMPTY
    | (<value_part>)

The <name> in a property has significance in UniCon (i.e., it conveys meaningful information about a definition); the <value> associates specific information with the property name in the given context. Here, the term context refers to the given language element of the given type (e.g., player, of type GlobalDataDef). The <value> may be NULL, or it may contain a <value_part> enclosed in parentheses. The <value_part> has a syntax that is specific to the property, in a given context. There are eleven common syntaxes for the values of UniCon properties.

The set of properties that can be legally specified in a property list depends on which definition the property list further specifies. For example, the set of properties legal for a protocol property list is different from the set that is legal for an interface property list.

The roles in a <role_list> are separated by whitespace.

Next: Connector Type
Up: Component
Previous: Establish

Comments? Mail the current maintainer of this page.

Author: Gregory Zelesnik

Last Modified: May 12, 1996