Next: Player Type
Up: Component
Previous: General

Player

Description

A player is a visible semantic unit in the interface of a component through which the component can interact with other components, request and provide services, or be influenced by external state and events. More concretely, a player is a named entity in the interface of a component that can be associated with a role (a named entity in the protocol of a connector) in a connection during system construction. It is through the connections of players that components interact with each other in a system.

A player definition contains:

the player type
attributes, requirements, and constraints that apply to the player as a whole (properties)

Players behave in identifiable, distinct ways. Because of this, they play distinct roles in connections. For example, a procedure call connection requires two players that each play a different role. One plays the role of caller, and the other plays the role of definer. These distinct behaviors separate players into categories, or types. A player type captures the semantics of a player's behavior and specifies the kinds of roles a player can play in connections.

Players are further specified by properties in the property list of the player definition. Properties can be thought of as attributes of a definition which are used to further describe (i.e., specify) it. For players, they are attributes, requirements, and constraints that apply to the player as a whole. There are many places in UniCon where lists of properties are used to further specify a definition. In players, properties are used to specify information such as the signature of the arguments in a routine definition, the port in a Unix process through which a stream player will communicate, or the number of player/role associations that are allowed for a given player in a component.

Syntax

The following is the syntax for a player definition:

  <player> :==    
    PLAYER <identifier> IS <player_type>
    <optional_end_player_syntax>

  <player_type> :== 
    GlobalDataDef
    | GlobalDataUse
    | PLBundle
    | ReadFile
    | ReadNext
    | RoutineCall
    | RoutineDef
    | RPCCall
    | RPCDef
    | RTLoad
    | StreamIn
    | StreamOut
    | WriteFile
    | WriteNext

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

Players can be defined with and without properties. In the latter case, the player definition appears as follows:

  PLAYER my_read_player IS ReadNext

Notice that if no properties are specified in a player definition (i.e., the property list is empty), the END statement is omitted.

In the former case, the player definition appears as follows:

  PLAYER my_input_player IS StreamIn
    SIGNATURE ("line")
    PORTBINDING (stdin)
  END my_input_player

The END statement is required in this case. The <identifier> in the END statement must be identical to the <identifier> following the keyword PLAYER.

Next: Player Type
Up: Component
Previous: General

Comments? Mail the current maintainer of this page.

Author: Gregory Zelesnik

Last Modified: May 12, 1996