Object Model Representation

There are multiple ways a FOM can be represented (the older OMT format, or the newer XML-based format introduced with 1516). As such, having a single way to represent an object model internally removes the need to consider specification-specific differences.

Portico has its own internal representation of a HLA object model. This java-based, in-memory model is used throughout Portico to identify the various components of the FOM for a federation. It also has the ability to convert between the language of 1516 and 1.3 (that is, it understands that the  attribute and the   attributes are the same thing).

Figure 1 below shows an overview of the components in the object model. All classes reside in the  package.



All object, attributes, interactions and parameters in a FOM are represented by Metadata classes. Each of these classes provides simple  method access to the relevant FOM data (name, handle, etc...) for each type.

The class
The  class is the main container for a FOM. It holds references to each of the object and interaction classes in the FOM (which in turn hold references to each of their attributes and parameters). It also holds other potentially useful information, such as the version of the fed file that was used to create the model (1.3 or 1516).

The  class provides a number of helper methods to make commons tasks easy. For example, methods are provided to fetch the object or interaction root classes, or the "privilege to delete" attribute.

Classes within the model are stored in an index by handle, but you can still fetch a class by name. If you do, the  class will automatically translate between the vocabulary of the 1.3 and 1516.

The Metadata Classes
There isn't really much to say about the metadata classes, except that they contain all the relevant FOM information used by the RTI. The javadoc contains all the relevant usage information a developer may require, but ostensibly it is all self-explanatory.

Extras: Locking the Object Model
A HLA object model is a static entity. Once it has been created, it cannot be altered or extended. However, the idea of dynamic FOMs has been around in the HLA research community for quite some time now. So as not to rule this out as a future feature, the Portico  class contains a "locked" variable.

When a FOM-parser created a new instance, the last thing it should do it lock the model. This will prevent any further changes from being recorded (you can try and add/remove classes, but the model won't allow it). However, there are methods to lock and unlock the model, so if someone wants to experiment with dynamically changeable FOMs, support is provided.

The default status for a Portico object model is locked, as required by the HLA specification.