Processes as Objects

In Triveni, the class Expr captures the abstract notion of behavior. Expr enriches the structure of the encapsulated state in objects in two ways. (Figure 1 summarizes the following discussion.)

  

Figure 1: The Expr class

  

Figure 2: Rules of Battle

Battle is an n-player variation of the 2-player board game Battleship. New players cannot join the game once it has begun. A player loses by manually aborting the game or when all his/her ships are destroyed.

Oceans. Each player has a collection of ships on an individual ocean grid. The n ocean grids are disjoint. Each player's screen displays all n oceans, but a player can see only his/her own ships. A player's ships are confined to the player's ocean.

Ships. Each ship occupies a rectangular sub-grid of the player's ocean and sinks after each point in its grid area has been hit. There are two kinds of ships:

1.

Battleships that can move on the surface of the player's ocean.

2.

Submarines that can dive, but remain at a stationary position with respect to the player ocean's surface.

Moves. A player can move as fast as the user-interface/reflexes allow. Player i can make 4 kinds of moves:

1.

Fire a round of ammunition on a square of another player j's ocean by clicking on it. The ammunition may hit a previously unhit point on one of player j's ships, in which case an X is displayed at that point in player j's ocean on all players' screens. No information is reported in case of a miss. The X marks are static; when a wounded battleship moves, or a wounded submarine dives, it does not affect previously displayed X marks on players' screens. When a ship is sunk, its position is revealed to all players.

2.

Impart a velocity to a battleship that lasts until it receives another velocity command.

3.

Make a submarine dive for a game-specific interval of time.

4.

Raise a shield over his/her entire ocean for a game-specific interval of time, during which player i's ships are invulnerable. When a player raises an ocean-wide shield, his/her ocean becomes dim on the screens of all players. Each player has a limited supply of shields.

1.

The Communicator interface captures reactivity, i.e. interaction with the environment. The environment uses the Observer interface to send inputs to Expr and the Observable interface to receive outputs from Expr. Thus, instances of Expr can be used as embedded systems in the host programming language if the communication is arranged via the Observer pattern.

2.

Expr supports the encapsulation of autonomous state, such as system clocks, that can evolve even in the absence of interaction with the environment. The environment interacts with the encapsulated autonomous program by the control operations indicated by the Controllable interface -- started via start(), suspended via suspend(), resumed via resume(), and stopped via stop(). The Controllable interface corresponds closely to the control operations allowed on threads in Java -- in particular, existing Java threads that conform to the Communicator interface for any event exchange can be used as Exprs.

The different kinds of state in Expr can interact. This discussion is best carried out in the context of a concrete example.

Example 1  

Consider the class of players in the Battle game. The user interface of the player is a reactive subcomponent of the player. The number of available shields can be modeled as an instance variable, say numshields. The timer that measures the duration of shielding evolves autonomously.

The activation of the shielding (i.e. the initiation of the autonomous state) is caused reactively by inputs from the user interface. This activation affects the variable numshields. The end of the period of shielding, as detected by the autonomously evolving clock object, causes a stimulus (in the form of brightening of this player's ocean) to the reactive subcomponents in other players.

The become method in Expr follows standard object-oriented techniques. It allows an Expr to assume the behavior of another Expr and is useful for refining the inherited behavior in subclasses of Expr.

  

Figure 3: Inheritance Example

Example 2  

In the design of Battle that follows, a class called Ship is used to factor out the common behavior of Battleship and Submarine, namely the handling of opponent fire. (See Figure 3.) A Battleship is constructed from a Ship by adding instance variables and behavior to handle movement in terms of direction and speed. A sketch is as follows (detailed design is in Section 3.5):

 

  class Battleship extends Ship {
    Direction dir;
    int speed;
    Battleship(initial_status) {
      super(initial_status); // initialize receiver 
      Expr e = // construction of new behavior 
               // from inherited behavior
      become(e); // assume new behavior 
  }}