Next: MaxAssocs
Up: Property
Previous: MapsTo

Match

Description

The Match property is used to further specify an abstraction bind and an instantiation of a connector of type PLBundler. In both cases it is used to specify pairs of players that get matched up together in the bind, or connection.

The Match property for an abstraction bind is used when the external player is of type PLBundle. Specifying the Match property in any other type of abstraction bind will be reported as an error by the UniCon compiler. This property specifies how the Member players of the PLBundle are matched to the players in the value of the MapsTo property. This matching is necessary because the UniCon compiler must know ultimately how each player in the interface of a component is implemented. This applies to the Member players of external PLBundle players as well. The Match property is used to provide the UniCon compiler with the mapping of the Member players to the MapsTo list entries.

In the abstraction bind, there are two forms of syntax for the value of the Match property. The first form is simply the keyword by_name. This is actually the default value if no Match property is specified. In this case, the UniCon compiler generates a list containing the players in the PLBundle. It then generates a list containing the players in the MapsTo property. If a player in a MapsTo property is a PLBundle, then the Member players are added to the list rather than the player itself. The UniCon compiler then processes the list of players from the MapsTo property. For each of these players, it searches the list of Member players from the external PLBundle player for a matching player (by looking for a name match). If it finds a match, the UniCon compiler attempts to bind the two players. If no match is found, the compiler does not bind them. In both cases, the compiler continues until each player in the MapsTo list has been examined. In the end, if there are any Member players in the external PLBundle that have not been bound, the UniCon compiler will report errors.

The second form of syntax for the value of the Match property for an abstraction bind is a list of relations. A relation is a comma-separated pair of player names. Each pair represents a specific match that the system designer has explicitly specified. The names of the players in each pair need not match. With this form of syntax for the Match property, the UniCon compiler binds each pair of players, regardless of whether or not the player names match. Then, it uses the Match (by_name) algorithm outlined above to form binds from the remaining players not specified in explicit matches.

The Match property for a PLBundler connector instantiation has the same two forms of value syntax as those of the abstraction bind: the value by_name, and a list of relations. The algorithm for matching with relations in a PLBundler connector instantiation is identical to the algorithm for matching with relations in an abstraction bind. The UniCon compiler treats each pair as an attempt at a connection with the appropriate connector type. For example, if a relation specifies a pair of players where one is of type RoutineDef and the other is of type RoutineCall, then the UniCon compiler will attempt to connect them with a ProcedureCall connector. The compiler will report appropriate error messages for any pairs that do not specify well-formed connections. Name mismatches are allowed in relations; the UniCon compiler will fix these mismatches at runtime by renaming both identifiers in the source code to a third, common identifier. This is done using C language macros, specified on the command line with the -D option during the source code compile of each file involved in the connection. When explicit matching using relations is completed, the
UniCon compiler attempts to create matches from the remaining players in the connection using the Match (by_name) algorithm for PLBundler connector instantiations outlined below.

For PLBundler connector instantations, the Match (by_name) algorithm is slightly different than the one for abstraction binds. This is because there may potentially be more than two sets of players involved that get matched one-for-one. There can potentially be many more than two participants in a PLBundler connection. Strewn throughout these participants, for example, may be many calls or uses of a particular routine or global data definition. A match must be made from these mini-sets of players that all share the same name. The algorithm is further compilated by the fact that not all participants in a PLBundler connection are PLBundle players; they can also be GlobalDataDef, GlobalDataUse,
RoutineCall, and RoutineDef players.

The algorithm for matching by name in a PLBundler connector instantiation proceeds as follows. Every Member player of every PLBundle participant, and every other participant in the PLBundler connection, is placed in a list. This list of players is sorted by name. The UniCon compiler then attempts to make a connection from each set of players with the same name from that list. The compiler will report errors associated with malformed connections. For example, each connection must have exactly one definition (i.e., RoutineDef or GlobalDataDef player) and at least one corresponding RoutineCall or GlobalDataUse player. Each set must also exclusively contain players of compatible types; all players must correspond to routine players, or they all must correspond to global data players.

Property Lists

The Match property can legally be specified in the property list in the following UniCon language elements:

<abstraction_bind>
<establish>
<instantiation> of a connector

Value Syntax

The syntax of the value part of the Match property is either the keyword by_name, optionally enclosed in double-quotes, or a comma-separated list of relations, enclosed in parentheses. A relation is a comma-separated pair of player names, enclosed in parentheses. A player name can either be two or three dot-separated <identifier>s. The first
<identifier> names a component instantiation, the second names a player in the component instantiation named by the first, and the third (if present) names a Member in a PLBundle player named by the second.

Required Rule

Optional

The default value of the Match property is the keyword: by_name.

Merge Rule

MERGE

More than one specification of the Match property in a single property list is treated as a single specification with the union of all values in all of the specifications. However, if more than one Match property is specified, they must all have the same value syntax. In other words, they must all have the value by_name, or they must all be lists of relations.

Semantic Checks

The following are the semantic checks performed on the value of the Match property:

If the value of the Match property is not a list of relations, it must be the keyword by_name.

If the value of the Match property is a list of relations, each of the two player names in each relation are subjected to the following semantic checks:

The first <identifier> in each dot-separated pair or triple representing a player name must name a component that has been previously instantiated in the composite implementation.
The second <identifier> in each dot-separated pair or triple must name a player in the interface of the component instantiation named by the first <identifier>.
If an item in the Match list is a triple of <identifier>s, the second <identifier> must name a player of type PLBundle.
If an item in the Match list is a triple of <identifier>s, the third
<identifier> must name a player in the PLBundle player named by the second <identifier>.

Example

The following are examples of specifications of the Match property. Assume for the first two examples that main.sort_routines is a PLBundle that contains exactly four routine calls that have corresponding routine definitions with the same name in the PLBundle sort.sort_routines.

  ESTABLISH C-PLBundler WITH 
    main.sort_routines AS participant
    sort.sort_routines AS participant
    /* with no Match attribute,
      Match (by_name) is assumed */
  END C-PLBundler

The following is equivalent to the above example:

  ESTABLISH C-PLBundler WITH 
    main.sort_routines AS participant
    sort.sort_routines AS participant
    MATCH (by_name)
  END C-PLBundler

Now, assume that main.sort_routines is a PLBundle player containing the following RoutineCall playerts: bubble, quick, merge, and sort. Also, assume that sort.sort_routines is a PLBundle player containing corresponding RoutineDef players with the following names: bubble_sort, quick_sort, merge_sort, and sort.

  ESTABLISH C-PLBundler WITH 
    main.sort_routines AS participant
    sort.sort_routines AS participant
    MATCH ((main.sort_routines.bubble,
        sort.sort_routines.bubble_sort),
      (main.sort_routines.quick,
        sort.sort_routines.quick_sort),
      (main.sort_routines.merge,
        sort.sort_routines.merge_sort))
  END C-PLBundler

In the above example, the UniCon compiler uses the Match (by_name) algorithm to form a ProcedureCall connection with the sort routines from each PLBundle player.

Lastly, the example below shows the Match property in an abstraction bind. Assume that the component in which this bind is defined has an external PLBundle player named Sort_Bundle. Assume further that this player defines five RoutineDef Member players: bubble, quick, merge, sort, and topological. Assume that the player
utilities.topological is a RoutineDef player.

  BIND Sort_Bundle TO ABSTRACTION
    MAPSTO (sort.sort_routines, 
       utilities.topological)
    MATCH ((Sort_Bundle.bubble,
        sort.sort_routines.bubble_sort),
      (Sort_Bundle.quick,
        sort.sort_routines.quick_sort),
      (Sort_Bundle.merge,
        sort.sort_routines.merge_sort))
  END C-PLBundler

In the above example, the UniCon compiler uses the Match (by_name) algorithm to bind Sort_Bundle.sort to sort.sort_routines.sort, and to bind Sort_Bundle.topological to utilities.topological.