PLBundler

Semantics

The PLBundler connector type supports the abstraction for connections of bundles of routine and data definitions, calls, and uses to other such bundles. Concretely, the PLBundler connector connects two or more PLBundle players. It abstracts from ProcedureCall and DataAccess connectors in the same way that the PLBundle player abstracts from the corresponding player definitions.

In the implementation of the abstraction, the UniCon compiler makes connections between individual Member players within the PLBundles. The compiler connects RoutineCall players in one PLBundle with their corresponding RoutineDef players in another PLBundle, and GlobalDataUse players in one PLBundle with their corresponding GlobalDataDef players in another.

The system designer can control how the UniCon compiler performs the connections by specifying the Match property in the property list of a PLBundler connector instantiation. The value of the Match property has two distinct forms. The first form consists simply of the word "by_name". This is the default value if the Match property is not specified in a PLBundler connection. If matching by name is specified, the compiler looks through every player in the PLBundler connection and attempts to find a match, based on player names, for every GlobalDataUse and RoutineCall player that it encounters. The second form of the Match property value is a comma-separated list of relations. A relation is a pair of player names, separated by a comma and enclosed in parentheses, that represent a connection to be made. The names in the relations must identify players or members of players in the PLBundler connection in which the Match property appears. With this form, the names of the players in the relations do not have to match. The name mismatches in this case will be resolved in the underlying system implementation.

If the value of the Match property is used to specify relations (i.e., it has the second form, as described above), then any RoutineCall or GlobalDataUse player in a PLBundler connection that is not connected explicitly in a relation will be automatically matched by name with a corresponding RoutineDef or GlobalDataDef player in the connection.

When performing matching by name, the UniCon compiler will report all instances of
GlobalDataUse and RoutineCall players that do not have corresponding matches in the connection.

Role types

Participant

a bundle of programming language entities: routine definitions and calls, and global data definitions and uses

Properties

InstFormals (P)

The syntax for an InstFormals property in a connector of type
PLBundler is a comma-separated list of <parameter>s enclosed in parentheses. A <parameter> consists of an <identifier>, followed by a `=', followed by a <complex string> or the language keyword NODEFAULT. A <complex string> is a simple "string" or a sequence of "string"s concatenated by the `&' character:

INSTFORMALS (first_parameter = "an initial value",

second_parameter = "a much" &
"longer initial value that " &
"will not fit on one line",
third_parameter = NODEFAULT)

Match (I)

The syntax for a Match property in a connector of type PLBundler is either the word "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.

MATCH (by_name)
MATCH ("by_name")
MATCH ((my_application.stack_adt.pop_call,

my_stack.stack_adt.pop_definition),

(my_application.stack_adt.push_call,

my_stack.stack_adt.push_definition),

(my_application.stack_adt.stack_init_call,

my_stack.stack_adt.stack_init_definition),

(my_application.stack_adt.stack_is_empty_call,

my_stack.stack_adt.stack_is_empty_definition))

Semantic Checks

Implementation Semantics

Author: Gregory Zelesnik

Last Modified: May 12, 1996