Participants

The class hierarchy corresponding to the BATCHING pattern is shown in figure 3. It follows the OMT notation [13] variant used in [5].

Figure 3: BATCHING

BatchServer

behaves as a façade [5] to services provided by the server. An object of this class is located on the server side. It supplies interpretation facilities to service callers, so that clients can send a program to the server side instead of making direct calls to the server. The execute method is an entry point to the interpreter [5], which interprets the ``batch'' program and returns its results to the client.

ConcreteServer

This class is only present on the server side. It provides the set of entry points that can be called by the client. Note that the ConcreteServer is actually the class (or the set of classes) one has in the server side before instantiating the pattern. It is mentioned here for completeness.

Program

is an abstract class that represents the program to be interpreted. Clients build Program instances and send them to the BatchServer for execution. It is also responsible for maintaining an associated table of variables. The run method of a Program class implements the interpreter needed to run it on the server. The Program is also responsible for performing an orderly program termination when an error occurs. The terminate method is provided as an abstract interface for program termination. The alternate name for BATCHING, namely, COMPOSITECALL, comes from the fact that Program, together with the next couple of classes, is an instance of the COMPOSITE pattern [5].

ControlStructure

is a construct made of Programs. Its purpose is to bundle several Programs together according to some control structure (e.g. sequence, iteration, etc.).

ConcreteControlStructures

represent concrete control structures like conditionals, while constructs, sequences, etc. At the server side, this class is responsible for executing the concrete control structure represented by the class. ConcreteControlStructure constructors can be used at the client side to build complex Programs.

Command

is a Program which represents a single operation. (It resembles the COMMAND pattern shown in [5], hence the name). Examples of concrete Commands can be arithmetic operations, logic operations, or calls to ConcreteServer entry points. The only purpose of BATCHING is to bundle several concrete Commands together using ConcreteControlStructures.

VarTable

keeps the variables of the Program. It provides local storage and also holds any input parameter for the program. Output values from the program are also kept within the VarTable. The table is built at the client using the set of input parameters for the Program. Then, it is used within the server, while the Program is interpreted. The table is finally returned back to the user after completion of the Program. There is a variable table per Program (pairs of VarTable and Program are sent together to the BatchServer). Thus, all components of a concrete Program share a single variable table so that they can share variables.

Var

is an abstract class representing a variable of the program sent to the server. It has some associated storage (bytes, in the figure). Var instances are kept within a VarTable. Variables have a mode, which can be either in (parameter given to the Program), out (result to be given to the user), inout (both), or local (local variable). By including the mode qualifier, this class can be used for local variables as well as for input/output parameters.

ConcreteVar

is a variable of a concrete type (integer, character, etc.). Its constructor is used at the client to declare variables or parameters to be used by the Program. At the server side, instances of this class are responsible for handling single, concrete pieces of data used by the program.