TANDEM ARCHITECTURE
Introduction
Tandem is a framework designed to aid the rapid development of VR applications.  It provides a starting point for the basic requirements of VR applications so that developers don't have to spend time designing and implementing these features. It places emphasis on object-oriented design and takes advantage of advanced language features that appear in standardized C++.  It requires full template support and for this reason is currently available only for the SGI IRIX 6.5.3 platform.
Tandem's architrecture places a strong emphasis on the use of design patterns both in documenting the framework and in solving key design issues. 

Tandem is designed for collaborative VR, hence much of its design was done with distributed computing environments in mind.  Consequently many components are searchable by string and/or are geared for interaction with network events.  Tandem currently uses the services of CavernSoft to enable its networking module with its own TcNetCav layer. CavernSoft provides several broker like features that make distributed designs easier to develop.

 Class Naming Conventions Throughout the design and implementation there are two conventions which I have used.
Tandem Core classes are prefixed by Tc. 
Those core classes made available to developers are abstract and hence can only be used through inheritance. 
Tandem Development classes are prefixed by Td and are meant to be instantiated within an application.
In classes that are not directly part of the Tandem Core following Tc or Td is the module to which a given class belongs, currently Net, Gfx or Ut. 

As an example the TcActionEvent class is from the Tc module and is included by the compiler directive
#include <Tandem/Tc/TcActionEvent.hxx>
Clients must inherit from the TcActionEvent class.

An instance of the TdGfxPfObject class is instantiated directly and is from the Gfx module.

Tandem Core The Tandem Core is comprised of a set of classes that support the core features of a Tandem application.  These classes are not meant to be used directly.  One can inherit from certain core classes if additional functionality or specialization is required.

The Tandem Core classes are divided into the following categories corresponding to the directory structure: Tc, Gfx (Graphics), Net (Network), and Ut (Utility).

In addition there are several logical packages which have evolved from the analysis and design of Tandem but are not mapped to unique directories.
These are TcApp (TcApplication), TcEx (TcExecution), TcAv (TcAvatars), TcInteraction, TcTracker and TcTrav (TcTraveler). 
These form the highest level of Tandem's architecure.

Please refer to the following diagram.

TcApp This module is the foundation of a Tandem application. It is made of the following classes:
TcApplication
TcLoader
TcExControl
TcAvatarManager
TcInteractionManager
TcNetManager
This module makes use of both Template Method and Factory method. The TcApplication is responsible for creating these classes through factory methods, and plays the role of creator.  Ownership of these classes remains with TcApplication and consequently it is also responsible  for destroying them.
Please refer to the following diagram.
TcEx The TcExcecution module is a logical separation of concerns, rather than a module that is distinct from the others.  It is made of classes that are created by the TcApplication class. The TcExControl class  encapsulates the main thread of control for a Tandem application.  The other classes passed to it are the TcInteranctionManager, TcNetManager,  TcGfxManager and the TcAvatarManager.  TcExControl contains a template method whose  functionality is supported by the aggregation of these classes.
TcGfx This module is reponsible for all core Tandem graphics. It maintains a hierarchical structure of TcGfxComponent classes using the Composite pattern. This hierarchical structure maintains associations between TcGfxComponents, user behavior and data classes as well as display library components. This functionality is supported by various abstract base classes that clients must inherit from. The Gfx module provides a group of adapter classes derived from TcGfxDspLibComponent. These adapt the components of a display library for use within Tandem. Tandem includes a set of development Performer adapters for this purpose. (See TcActionEvent, TcUserComponent , TcGfxDspLibComponent and TcGfxVisitor  for further details on how to extend the TcGfxComponent hierarchy.) 
The Gfx module also maintains iterators for traversing its structures. In addition it is reponsible for initializing the desired graphics display library (currently implemented using Performer 2.2 and CAVElib) . 
IIt also interacts with TcTraveler to control the users viewpoint while travelling through a Virtual Environment.
Refer the following diagrams:
Graphics Manager
Graphics Iterators
Graphics Component Hierarchy
Graphics Performer Component Adapters
TcNet This module is responsible for making Tandem applications collaborative and distributed. It is composed of three main components. The principle class is the Network manager which is an aggregation of a NetworkEventManager and a NetworkConnectionManager. 
The NetworkEventManager is the processor of network events passed between a Tandem Client Application and the NetworkConnectionManager.  It packages Client requests into NetworkEvents to be sent over the network. It also unpackages incoming network events and distributes them to the approriate modules. 
The ConnectionManager is the shipper/receivier. It knows nothing about the semantics of a Network event, or its data. It knows simply how to send and receive events over a connection. 
This design is similar to the Broker pattern, particularily with respect to the client and client proxy as well as the server and server proxy, since these classes can be used in both client and server applications.
See the TcNet diagram.
TcInteraction This module plays two key roles that comprise several layers of interaction within Tandem. 
The first is to  create and update core interactions and provide hooks for client interactions.
The second is to maintain a collection of classes that enable development of user interactions. 
Core Interactions
Core interaction updates are handled by the InteractionManager.  This aggregate class is comprised of an InputManager, TrackerManager, a GraphicsIntersectionManager and a Traveler.  These classes enable the updateInteractions() factory method to update trackers, input devices and intersections once per iteration of the control loop.
The view point is updated through a strategized algorithm encapsulated in TcTravelScheme and associated with TcTraveler.
After the core interactions are updated control is passed to client classes.
This is done through the use of factory and template methods that enable extension of the TcInteractionManager.
See the following class diagram.
Developing  Interactions In Tandem
Tandem provides a collection of classes that enable the development of various behavior and interaction metaphors that commonly occur in collaborative VR. 
These are separted into three categories:
  • ActionEvents
  • Actions & ActionHandlers
  • Visitors/Controllers
ActionEvents
An Action Event is an event that triggers an Action. They are based on the command pattern and may be associated with any TcGfxComponent. They are the foundation for two graphics interactions: triggered events and iterative events. The former occurs asynchronously, while the latter occurs once per iteration as in the case of an animated graphic event.

Actions & Handlers
Actions and Handlers are based on the Multicast pattern, a variation of Observer.
Actions are defined by clients by inheriting from TcAction. Each class derived from TcAction automatically generates and encapsulate a nested template class Handler from which action handlers must inherit. 
When an Action occurs all registered handlers are automatically notified. Handlers can be configured for both implicit handling (automatic registration with action instances) or explicit handling (user controlled registration) and can dynamically register and unregister interest in an action.

Visitors/Controllers
These components are modelled after the visitor pattern and are designed to extend the behavior of the Tandem Graphics Component hierarchy. The term controller is chosen because they are a mechanism used to carry out an action.  Both actions and handlers may use Visitors and Controllers to carry out the occurrence of or response to a given action. 
An example is the TdTransformController. This controller is used to transform (scale, rotate, translate) a dynamic graphics component. Clients may also develop their own controllers based on the visitor pattern.

These entities do not necessarily have to be used in this configuration, this is only a description of how they were conceived.  They may be used as design contructs in contexts that may not have anything to do with interactions. For example the Actions and Actions handlers work very nicely in any situation where you want a publish-subscribe relationship. The nice feature of the Action and Action Handlers is that they work well in both one-to-many and many-to-one subject to listener configurations.
See the following diagram.

TcUt This is a collection of utility classes used by Tandem core classes. It contains things like Tandem Utility strings, and hashtables. Clients could potentially use these classes if they needed them. TcUtStrings and TcUtVector3f classes are serialized through the use of CavernSoft.
See the following diagram

Tandem Home

Last updated Saturday October 2, 1999