Next: Connection
Up: Composite Implementation
Previous: Composite Implementation

Instantiation

Description

The <instantiation> statement is used to create the instances of components and connectors that will be used in a configuration description in the composite implementation of a component.

More than one instance of the same element (i.e., a component or a connector) may be used in the implementation of a single component, so UniCon definitions are considered to be templates from which instances can be created. In other words, a new instance of a component or connector is created from a given definition each time that component or connector is instantiated in a composite implementation. Each instantiation makes a copy of the component or connector described by the definition. When a component is instantiated, its players are instantiated as well. Similarly, when a connector is instantiated, its roles are instantiated too.

The first <identifier> in an <instantiation> is the name of the instance. All instance names in a composite implementation must be unique. The second
<identifier> is the name of the component or connector as it appears in its UniCon definition.

When instantiating a component, the keyword INTERFACE is required after the first <identifier>. When instantiating a connector, the keyword PROTOCOL is required.

When instantiating a component, all of the properties in the <interface> property list that further specify the component definition apply to the instantiated component as well. However, the designer may further constrain the component instantiation by specifying properties in the <instantiation> property list. The properties in the instantiation and the properties in the definition are merged into a single list of properties, which is then used to specify the instantiation. Any duplicate specifications of the same property are resolved according to the merge rule for that property. In the case of a merge rule value of REPLACE, the value of the instantiation property overrides that of the definition property. In the case of the merge rule value of ERROR, the value of the instantiation property is ignored and a warning is issued by the UniCon compiler (i.e., the value of the definition property is used). In the case of a merge rule value of MERGE, the values of the definition property are merged with the values of the instantiation property, and the instantiation property is used.

The semantics for the property list for connector instantiations are the same as for component instantiations except that it is the <protocol> property list that is merged with the instantiation property list instead of the <interface> property list.

NOTE: Not all properties that are legal in an <interface> property list of a component definition are legal in the <instantiation> property list, and vice versa. The same is true about connectors. Refer to the individual component type descriptions for more information about the properties that are legal in either of these property lists.

Syntax

The following is the syntax for an <instantiation> statement:

<instantiation> :==
  USES <identifier> <interface_or_protocol> <identifier>
    <optional_end_instantiation_syntax>

<interface_or_protocol> :== 
  INTERFACE | PROTOCOL

<optional_end_instantiation_syntax> :== 
  EMPTY
  |
  <property_list> 
  END <identifier>

Syntactically, the END <identifier> statement is disallowed unless a property list has been specified in the <instantiation>.

Example

The following are four examples of instantiations. The first two are instantiations of
SchedProcess components. Notice that they contain property lists making the <optional_end_instantiation_syntax> required. The third is an instantiation of a component for which further specification with an <instantiation> property list is not necessary. The fourth is an instantiation of an RTScheduler connector. It requires further specification with a property list:

  USES RTClient INTERFACE Real_Time_Client
    PRIORITY (10)
    PROCESSOR ("TESTBED.XX.CMU.EDU")
    ENTRYPOINT (client)
  END RTClient

  USES RTServer INTERFACE Real_Time_Server
    PRIORITY (11)
    PROCESSOR ("TESTBED.XX.CMU.EDU")
    RPCTYPEDEF (new_type; struct; 12)
    RPCTYPESIN ("unicon.h")
  END RTServer

  USES libmachrt INTERFACE Mach_Real_Time_Library

  USES RTM_RTScheduler PROTOCOL Real_Time_Scheduler
    ALGORITHM (rate_monotonic)
    PROCESSOR ("TESTBED.XX.CMU.EDU")
    TRACE (RTClient.load.trigger,
        RTClient.load.segment1,
        RTServer.load.segment,
        RTServer.load.segment2)
  END RTM_RTScheduler

Next: Connection
Up: Composite Implementation
Previous: Composite Implementation

Comments? Mail the current maintainer of this page.

Author: Gregory Zelesnik

Last Modified: May 12, 1996