4.7      Prototypes

(1)   Prototypes represent parameterization of component type, component implementation, and feature group type declarations.  They allow classifiers and features to be supplied when a component type, component implementation, or feature group is being extended or being used in a subcomponent declaration.  The component classifier prototypes can be referenced in place of classifiers in feature declarations, in subcomponent declarations.  The feature prototypes can be referenced in abstract feature declarations. Prototypes can also be referenced as actuals in prototype bindings; this allows parameterization via prototype to be propagated down the system hierarchy.

Syntax

prototype ::= 
    defining_prototype_identifier : 
      ( component_prototype 
      | feature_group_type_prototype 
      | feature_prototype ) 
      [ { { prototype_property_association }+ } ] ; 
 
component_prototype ::= 
    component_category [ unique_component_classifier_reference ] [ [] ]
 
feature_group_type_prototype ::=
    feature group [ unique_feature_group_type_reference ]
 
feature_prototype ::=
    [  in | out ] feature [unique_component_classifier_reference ]
 
prototype_refinement ::= 
    defining_prototype_identifier : refined to 
      ( component_prototype  
      | feature_group_type_prototype 
      | feature_prototype ) 
      [ { { prototype_property_association }+ } ];
 
prototype_bindings ::=
    ( prototype_binding { , prototype_ binding }* )
 
prototype_binding ::=
    prototype_identifier => 
      ( component_prototype_actual | component_prototype_actual_list
      | feature_group_type_prototype_actual | feature_prototype_actual )
 
component_prototype_actual ::=
    component_category 
         ( unique_component_classifier_reference [ prototype_bindings ]
           | prototype_identifier ) 
 
component_prototype_actual_list ::=
    ( component_prototype_actual { , component_prototype_actual }* )
 
feature_group_type_prototype_actual ::=
      ( feature group unique_feature_group_type_reference [ prototype_bindings ] )
      | (feature group feature_group_type_prototype_identifier ) 
 
feature_prototype_actual ::=
     ( (( in | out | in out) ( event | data | event data ) port ) | 
      ( ( requires | provides ) 
          ( bus | data | subprogram group | subprogram ) access )
          [ unique_component_classifier_reference ] )
      | ( [  in | out ] feature feature_prototype_identifier )
 
      
 
 

Naming Rules

(N1)     The prototype identifier on the left-hand side of a prototype binding must exist in the local namespace of the classifier for which the prototype binding is defined.

(N2)     The prototype identifier on the right-hand side of a prototype binding, if present, must exist in the local namespace of the classifier that contains the prototype binding.

(N3)     Unique component classifier references must exist in the public section of the package being identified in the reference.

(N4)     Unique feature group type references must exist in the public section of the package being identified in the reference.

Legality Rules

(L1)      The component category declared in the component prototype binding must match the component category of the prototype being referenced, i.e., they must be identical, or the declared category component category of the prototype must be abstract.

(L2)      The component category of the optional component classifier reference in the prototype declaration must match the category in the prototype declaration.

(L3)      If the component prototype only specifies a component category, then any component type and component implementation of that category is acceptable; in the case of the category abstract any component type and component implementation of any category is acceptable.

(L4)      If the component prototype declaration includes a component classifier reference, then the classifier supplied in the prototype binding must match according to the Prototype_Substitution_Rule property. This property specifies the rules to be applied to determine an acceptable classifier supplied to the prototype.  This property can be associated with a prototype declaration or the enclosing component type or component implementation.  The rules are the same as those of the Classifier_Substitution_Rule property.

(L5)      The category of the component implementation that contains the prototype declaration places restrictions on the set of acceptable categories for the prototype declaration and the supplied classifiers.  The nesting rules for each category are defined in the respective component category section of this document.  For example, if the component implementation is a thread group implementation, then the prototype referenced in a subcomponent declaration must be of the category thread group, thread, subprogram, subprogram group, data, or abstract.

(L6)      If the direction is declared for feature prototypes, then the prototype actual satisfies the direction according to the same rules as for feature refinements (see Section 8); in the case of ports the direction must be in or out;  in the case of data access, the access right must be read-only for in and write-only for out;  in the case of bus access, subprogram access and subprogram group access the direction is ignored.

(L7)      In the case of feature group prototypes, the supplied feature group types must match the declared feature group type, if any.  The Prototype_Substitution_Rule property rules apply to feature group types instead of component types.

(L8)      A classifier supplied in a feature prototype binding must match the classifier of the prototype declaration, if present, according to the Prototype_Substitution_Rule property rules.

(L9)      Component prototypes declared with square brackets specify that they expect a list of component classifiers. These prototypes can only be referenced in subcomponent array declarations.  The component classifier list supplies the classifiers for each of the elements in the component array.

(L10)   The component category of the classifier reference or prototype reference in a prototype binding declaration must match the category of the prototype.

(L11)   If a direction is specified for an abstract feature in a prototype declaration, then the direction of the prototype actual must match that declared in the prototype.

(L12)   Component prototype bindings must only bind component prototypes, feature group prototype bindings must only bind feature group prototypes, and feature bindings must only bind feature prototypes.

(L13)   Component prototype refinements must only refine component prototypes, feature group prototype refinements must only refine feature group prototypes, and feature refinements must only refine feature prototypes.

Standard Properties

Prototype_Substitution_Rule: inherit enumeration (Classifier_Match, Type_Extension, Signature_Match)

 

Semantics

(2)   Prototypes can specify a parameterization of component classifiers that can be referenced in feature declarations or in subcomponent declarations.  The same prototype can be referenced several times in a component type and its component implementations to indicate that the same actually supplied classifier is to be used. The supplied component classifier may include prototype bindings if the classifier has unbound prototypes.  Such a component classifier is effectively an unnamed extension of the classifier being referenced (see Section 4.5). 

(3)   Prototypes can specify a parameterization of abstract features (feature) as well as feature group types for feature groups.  The prototype binding of an abstract feature can supply concrete features 

(4)   Prototypes can only be bound once.  Prototypes can be referenced in prototype bindings, i.e., bound classifiers and features can be passed down the component hierarchy.

(5)   The prototype declaration specifies constraints on the component category, on the feature kind, and on the classifier that can be supplied.  The Prototype_Substitution_Rule property specifies whether the match requires matching classifiers, allows classifier substitution, or allows any classifier with matching signature.

(6)   A prototype refinement can increase the constraints on classifiers to be supplied.  The newly specified category, classifier, and array dimensions must satisfy the same matching rules as the prototype bindings. 

Examples

(7)   This example defines a generic component with a flow through one in port and one out port.  The abstract component type specifies the data type used on the port as one prototype and an incoming abstract feature as second prototype.  This allows us to supply an event data or data port as the incoming port for this pattern. The outgoing port has been fixed to be a data port.  The example also defines a primary/backup redundant implementation of the flow component as a pattern.  It has a single prototype, namely the component that is to be implemented as a dual redundant component.  This prototype is used to specify that both copies of the subcomponent are of the same classifier.  It takes the data type prototype as its prototype actual to ensure that the data type of the pattern and the data type of the supplied control prototype will match.  These abstract components are then refined into a controller process and its dual redundant instantiation as a system.

package PrototypeExample

public

-- a generic component interface with one in and one out port

abstract flowComponent

prototypes

dt: data;

incoming: in feature;

features

 insignal: in feature incoming;

 outsignal: out data port dt;

end flowComponent;

 

-- a dual redundant component pattern

abstract implementation flowComponent.primaryBackup

prototypes

  control: abstract flowComponent;

subcomponents

  primary: abstract control;

  backup:abstract control;

connections

  inprimary: feature insignal -> primary.insignal;

  inbackup: feature insignal -> backup.insignal;

  outprimary: port primary.outsignal -> outsignal;

  outbackup: port backup.outsignal -> outsignal;

modes

  Primarymode: initial mode;

  Backupmode: mode;

end flowComponent.primaryBackup;

 

data signal

end signal;

 

data implementation signal.unit16

end signal.unit16;

 

-- a controller to be realized as dual redundant system

process controller extends flowComponent ( dt => data signal.unit16,

                             incoming => event data port signal.unit16 )

end controller;

 

-- the dual redundant controller system interface

system DualRedundantController extends

       flowComponent (dt => data signal.unit16,

                             incoming => in event data port signal.unit16)

end DualRedundantController;

 

-- the dual redundant instance of the controller

system implementation DualRedundantController.PrimaryBackup

    extends flowComponent.primaryBackup (control => process controller)

end DualRedundantController.PrimaryBackup;

end PrototypeExample;