Next: ReadFile
Up: Player Type
Previous: GlobalDataUse

PLBundle

Semantics

Many compilation units export collections of players that have a coherent meaning as a group. For example, abstract data types (ADTs) usually consist of a collection of exported routine definitions, where use of the abstraction requires the use of all or most of the routines. In libraries of support functions there often exist groups of routine and global data definitions that together provide a single type of service, and therefore are used as a collection. For example, in the C standard library, there are many exported functions that provide
input/output services to the user, such as fgets, fprintf, etc., that are used as a group.

When designers think about the architecture of a system, they often think about the use of such collections of players, rather than about individual players. The PLBundle player type in UniCon allows the system designer to create a collection of players, to attach significance to a group of routines and data in an architectural description of a system. The name PLBundle denotes a programing language bundle; the bundle may only contain players of types that have corresponding programming language implementations: GlobalDataDef,
GlobalDataUse, RoutineCall, and RoutineDef players.

The individual players in a PLBundle are defined using the Member property. The value associated with this property has three fields, each of which corresponds to a portion of a UniCon player definition. The first field is the player name, the second is the player type, and the third is the player property list. PLBundle players must contain at least one member player definition, and there is no upper limit imposed for member players in a PLBundle.

Component Types In

A player of type PLBundle can legally be defined in components of the following types:

Computation

General

Module

SharedData

Role Type
Associations

A player of type PLBundle can legally be associated with the following role type in a PLBundler connection:

Participant (of PLBundler connector)

Properties

The following properties can be legally included in the property list of a PLBundle player:

MaxAssocs

The syntax for the MaxAssocs property in a PLBundle player is a single <integer> surrounded by parentheses:

MAXASSOCS (1)

MinAssocs

The syntax for the MinAssocs property in a PLBundle player is a single <integer> surrounded by parentheses:

MINASSOCS (1)

Member

The syntax for the Member property in a PLBundle player is as follows: the value contains three fields, separated by semicolons, with the entire value surrounded by parentheses. The first and second fields consist of a single <identifier> or "string". The third field is a property list, containing properties that are separated by whitespace:

MEMBER (my_player; RoutineDef;

SIGNATURE ("int"; "int")
MINASSOCS (0))
MEMBER ("another_player"; StreamIn; SIGNATURE ("line"))

Implementation Considerations

Most player types in UniCon correspond directly to language constructs or system calls in a given programming language. For a PLBundle player, however, there is no corresponding bundle structure in the underlying implementation. In other words, in the source code implementation of a system, the members of a PLBundle player exist as separate definitions. The UniCon compiler also treats the members of a PLBundle as separate definitions. The PLBundle player type is an abstraction that only has significance in a UniCon architectural description.

Refer to the descriptions of the GlobalDataDef, GlobalDataUse, RoutineCall, and
RoutineDef player types for implementation guidance.