The SEDRIS Data Representation Model
APPENDIX A - Classes
Interface Template

Class Name: Interface Template

Superclass - <SEDRIS Abstract Base>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

NOTE: An <Interface Template> instance is always a component of a <Model> or <Environment Root> instance. The scope of that <Model> / < Environment Root> is hereafter referred to as 'the given scope' in this definition.

Provides, for the given scope, a means of accessing all <Variable> instances within that scope, thus allowing manipulation of the affected <Control Link> instances' targets. These <Variable> instances are associated with the <Interface Template> in an ordered list; each is also aggregated by at least one < Control Link> instance in the given scope.

  1. For a <Model> that is instanced by some object MI (either a <Feature Model Instance> or a <Geometry Model Instance>), values are specified for each of the <Variable> instances associated with the <Model>'s <Interface Template> as follows.

    Each such value is specified by an < Expression> that is aggregated by MI. The <Model Instance Template Index> instance lying between the <Expression> and MI specifies the particular <Variable> instance being set by specifying its index within the ordered list of the <Model>'s < Interface Template>.

    Note that the <Expression> may be a <Variable> in the instancing scope, or a <Function> of some kind, not just a <Literal>.

  2. For an <Environment Root> instance, an <Interface Template> provides a means for 'environmental' <Variable> instances to be accessed by the user, such as a <Variable> for EAC_WIND_SPEED.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

Example

  1. Consider a <Model> representing a tank, which is made up of separate tank body, turret and cannon submodels, each instanced by the tank <Model> itself. The turret can be dynamically rotated and the cannon can be dynamically elevated. Both movements can be controlled separately.

    Both movements are rotations, so each of the turret and cannon submodels have <Rotation> instances at appropriate points in their hierarchies. Each of these <Rotation> instances aggregates a <Rotation Control Link>, which in turn aggregates a <Variable> that specifies the current rotation. The values supplied for these <Variable> instances shall be adjusted from outside the submodels that contain them. Consequently, the <Variable> in each submodel shall be associated with its submodel's <Interface Template>.

    However, the turret and cannon rotations shall be controlled from outside the entire tank <Model>. Therefore, it shall be possible to set rotation values via the tank <Model>'s own <Interface Template>, so the tank <Model> shall contain a turret-rotation <Variable> and a cannon-elevation <Variable>, and these <Variables> shall be associated with the tank <Model>'s own < Interface Template>. Each of the two <Variables> is also aggregated by the < Geometry Model Instance> that instances the submodel to which they relate.

    Finally, it is necessary to tie the <Variables> in the tank <Model> to the equivalent <Variables> in each of the submodels. This done using the < Model Instance Template Index> link object for each of the tank <Variables>. The <Model Instance Template Index> link object associated with the tank <Model>'s turret-rotation <Variable> references the equivalent <Variable>'s entry in the turret <Model>'s < Interface Template> and the < Model Instance Template Index> link object associated with the tank <Model>'s cannon-elevation <Variable> references the equivalent <Variable>'s entry in the cannon <Model>'s <Interface Template>.

    So, the tank <Model>'s <Interface Template> allows the turret rotation and cannon elevation to be set from outside the <Model>. The values set in the tank < Model> will then themselves set values in the <Variables> within the turret and cannon submodels, thereby rotating the turret and elevating the cannon as required.

  2. A building <Model> that may be instanced on terrain polygons that are at various different orientations. Each building wall shall meet the terrain, leaving no gaps. This means that the lengths of the building's walls shall be adjusted by different amounts in each instance to match the slope of the ground.

    The location of each <Vertex> of a <Polygon> can be adjusted by using an <LSR Location 3D Control Link> aggregated by the <LSR Location 3D> that specifies the <Vertex>'s location. Each <LSR Location 3D Control Link> would itself aggregate a <Variable>, which would specify the new location value. These <Variables> shall be set separately for each instance to match the terrain upon which the instance is positioned. This calls for the <Variables> to be set from outside the building <Model> so all of these <Variables> in the building <Model> shall be associated with the <Model>'s <Interface Template>.

    When the building is instanced, via a <Geometry Model Instance> GMI, the <Variable> instances' values can be set for GMI using <Expression> instances aggregated by GMI. As the terrain on which GMI will stand is known and fixed, these <Expression> instances could be <Literal> instances. Each <Literal> instance is related to the <Variable> for which it is specifying a value by the associated < Model Instance Template Index>, which references the <Variable> via the building <Model>'s < Interface Template>.

FAQs

No FAQs supplied.

Constraints

Associated with (two-way)

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.

Field Elements

SE_String description;

Prev: Inline Colour. Next: Internal Feature Face Ring. Up:Index.

Last updated: October 1, 2002 Copyright © 2002 SEDRIS™