Woe to the author who always wants to teach;

The secret of being a bore is to tell everything.

-- Voltaire, De la Nature de l'Homme

Chapter 8

Applying UNIFY : A Process

In this chapter, we present guidelines and a process for applying our techniques to achieve effective MRM. Designers can apply UNIFY by reading this chapter first and referring to preceding chapters when necessary. We presented Multiple Representation Entities (MREs) as a means of maintaining concurrent representations (Chapter 5). A Consistency Enforcer (CE) maintains internal consistency within an MRE (Chapter 6). An Interaction Resolver (IR) resolves the effects of dependent concurrent interactions on an MRE (Chapter 7). Here, we present a process for applying the techniques in UNIFY . By following these steps, designers can achieve effective MRM in their applications:

  1. 1. Construct an MRE from the representations of jointly-executing models.
  2. 2. Capture dependencies among the attributes with an ADG.
  3. 3. Select mapping functions for each dependency.
  4. 4. Classify interactions according to a taxonomy.
  5. 5. Select policies for resolving the effects of concurrent interactions.
  6. 6. Construct a CE and an IR for the MRE.

We expect designers to construct solutions for their MRM applications based on general guidelines. In §8.1, we justify each guideline briefly. Since UNIFY is intended to aid designers of multi-models, in §8.2 we show how UNIFY can be used in conjunction with a familiar modelling methodology. In §8.3, we explain how to apply the techniques in UNIFY with the example application employed in previous chapters.

8.1 Guidelines for MRM Designers

We present guidelines for achieving effective MRM using UNIFY . We justify each guideline briefly and refer to earlier sections in this dissertation for detailed explanations. We assume that a designer desires to construct a multi-model from models that meet their users' requirements. For each model, the designer must identify the representation of entities, relationships among attributes and interactions that change the state of entities. We assume the designer can identify the cross-model relationships in the multi-model, can understand the intertwined semantics of interactions and can make time-steps in the multi-model compatible.

  1. G1: Represent entities at levels at which they can interact.
    This guideline arises from FO-1 in §4.2. For effective MRM, entities should interact at a representation level at which their semantics are compatible (see Figure 9 in Chapter 4).
  2. G2: Maintain concurrent representations for jointly-executing models.
    Maintaining concurrent representations means preserving them at all times and permitting interactions to change them. MREs maintain concurrent representations (see Chapter 5). Designing MREs can ensure that entities interact at levels at which their semantics are compatible.
  3. G3: Make the time-steps of the multiple models compatible.
    If jointly-executing models have compatible time-steps, neither violates any assumptions made by another during any time-step. Achieving compatible time-steps may involve executing some models at finer or coarser time-steps (see §3.3.3). Accordingly, the attributes in the models may be augmented with tolerance values, which determine acceptable variances in the values of the attributes at overlapping simulation times (see §4.2.4).
  4. G4: Capture cross-model relationships.
    Capturing relationships among representations involves determining the semantics of attributes that are part of the representations. Attributes with overlapping semantics are likely to be related to one another. Relationships among models can be captured by Attribute Dependency Graphs and mapping functions (see Chapter 6).
  5. G5: Propagate the effects of an interaction to all representation levels.
    An interaction affects the attributes at its own representation level as well as related attributes at other representation levels (see FO-2 in §4.2.2). Propagating the effects of interactions to all relevant attributes ensures that multiple representations are consistent.
  6. G6: Select mapping functions for each relationship between representations.
    These functions translate value spaces or changes in values among related attributes. Mapping functions must satisfy the properties time-bounded completion, composability and reversibility (see §6.2).
  7. G7: Identify semantics characteristics of interactions.
    In §7.5, we presented a taxonomy of interactions, consisting of four classes, in order to reduce the complexity of resolving concurrent interactions. Alternative taxonomies are possible. Classifying an interaction involves understanding its semantics, i.e., its effects on its sender and receiver.
  8. G8: Select policies for resolving the effects of dependent concurrent interactions.
    The effects of concurrent interactions may depend on one another (see FO-3, §4.2.3, §7.3). In §7.5.4, we presented example policies for resolving the effects of dependent concurrent interactions. Specifying policies for resolving interactions involves capturing the semantics of their concurrent occurrence.

By following these guidelines, designers can incorporate effective MRM into their applications. A multi-model can satisfy its users' requirements if MRM is effective.

8.2 Using UNIFY with a Specification Methodology

We expect designers of multi-models to achieve effective MRM by employing UNIFY in conjunction with a specification methodology. W e augment an existing specification methodology so that designers can build on familiar modelling techniques when they apply UNIFY . Specification methodologies such as OMTR [Rum91], OOA [Shlaer92] and UML [Alhir98] support specifying model representations and relationships, but not the effects of interactions. In contrast, OMT [OMT98] supports specifying the effects of an interaction in terms of its parameters, its sender, its receiver and the attributes it affects. Since resolving the effects of concurrent interactions is one of the hardest problems in MRM, we regard the support for interactions in OMT suitable for MRM. We augment OMT by permitting designers to specify attribute relationships, interaction types and policies for resolving concurrent interactions.

In the Department of Defense's High Level Architecture (HLA) initiative, multiple models may execute together in a "plug-and-play" fashion. Individual models and multi-models are specified using a methodology called the Object Model Template (OMT). In OMT, individual models, or federates, are specified by tables describing their interface. These tables together are called the Federate Object Model (FOM) for that federate. The FOM for a particular model has the following tables:

The OCST and the APT enable a designer to construct the representations for a multi-model. The APT and the OIT enable the designer to describe the interactions for the multi-model. In OMT, the only relationships that can be determined are those of base class and derived class [Strou91]. These relationships capture neither attribute relationships nor complex entity relationships. Furthermore, although in OMT a designer can specify the effects of an interaction, the designer cannot specify effects of concurrent interactions.

We augment OMT with tables that permit a designer to capture relationships among attributes and specify policies for resolving the effects of concurrent interactions. The inability to express entity relationships is a serious shortcoming in OMT. The class hierarchy captured by the OCST captures static entity relationships such as inheritance, but not the dynamic relationships among entities, for example, relationships of configuration. Therefore, we augment OMT with an Attribute Relationship Table (ART). This table lists each attribute dependency, its class and specifications for its associated mapping function. In OMT, the OIT and APT permit interactions to be specified in detail. We augment the OIT in OMT with a column for specifying the class for each interaction. Once the class for an interaction has been specified, policies for resolving the effects of concurrent interactions can be formulated. We augment OMT with a table, the Concurrent Interactions Table (CIT), which permits a designer to specify such policies. The CIT permits a designer to specify policies in terms of combinations of classes of interactions or individual interactions. Table 11 is an ART and Table 12 is a CIT for the example application developed in Chapters 6 and 7. With these additions, designers can employ OMT and UNIFY to incorporate MRM into their applications.

Example Attribute Relationship Table

Dependency

Type

Specification

Hits1 → Str

Cumulative

Str is the weighted sum of Hits1 and Hits2. Changes to Str are distributed to Hits1 and Hits2 according to weights on the dependencies.

Hits2 → Str

Cumulative

Str → Hits1

Distributive

Str → Hits2

Distributive

Ammo1 → Fire

Cumulative

Fire is the weighted sum of Ammo1 and Ammo2. Changes to Fire are distributed to Ammo1 and Ammo2 according to weights on the dependencies.

Ammo2 → Fire

Cumulative

Fire → Ammo1

Distributive

Fire → Ammo2

Distributive

Pos1 → Pos

Cumulative

Pos is the centroid of Pos1 and Pos2.

Pos2 → Pos

Cumulative

Pos → Pos1

Distributive

Pos → Pos2

Distributive

Vel → Pos

Modelling

Position Pos changes with Velocity Vel according to physical laws.

Vel1 → Pos1

Modelling

Vel2 → Pos2

Modelling

Example Concurrent Interactions Table

Concurrent Interactions

Condition

Policy

Move_Platoon, any combination of (Move_Tank1, Move_Tank2)

All received

Ignore all except Move_Platoon

Detonation, any combination of (Collide_Tank1, Collide_Tank2)

All received

Add compensatory interaction for competitive effects to Dam1 or Dam2; actual damage less than sum of damages

Type 0, Type 1

All received

Ignore Type 1

Type 2, Type 3

All received

Ignore Type 3

Any Interaction

Ignored or Delayed

Ignored or Delayed entirely, i.e., no partial effects permitted

8.3 Process for Effective MRM

UNIFY can be summarised by the process diagram in Figure 48. The unshaded boxes represent steps in the process of applying UNIFY , whereas the shaded boxes represent steps in the design of models or a multi-model. The dashed arrows represent feedback in the process. We view designing models, constructing a multi-model and achieving MRM as iterative processes. We employed a running example of a Platoon-Tanks MRE in Chapters 6 and 7 in order to explain our techniques for effective MRM. Here, we present the process of applying those techniques.

UNIFY does not address the design of individual models. However, the steps in UNIFY depend on the successful completion of steps in the design of individual models. For example, constructing an MRE requires that the designer identify the representations of jointly-executing models, ModelA and ModelB. Conversely, constructing an MRE may provide insights into identifying representations of the models. Likewise, constructing an ADG and selecting mapping functions for an MRE requires that the designer identify the relationships within and among jointly-executing models. In the design of a model, identifying relationships can be carried out in parallel with identifying interactions. In like fashion, in UNIFY , constructing an ADG and selecting mapping functions can be carried out in parallel with classifying interactions and selecting policies for resolving concurrent interactions. In practice, these steps may be carried out sequentially; however, their relative order is unimportant.

Verification and validation (V&V) is an important step in the design of models. V&V is undertaken to ensure that a model is effective, i.e., meets its users' requirements. V&V for a multi-model depends on V&V for constituent models as well as V&V for MRM. V&V for constituent models is outside the scope of our work. V&V for MRM involves ensuring that jointly-executing models satisfy MRM requirements: multi-representation interaction (R1), multi-representation consistency (R2) and cost-effectiveness (R3). The MRE approach satisfies R3. If R1 and R2 are not satisfied, a designer must iterate through the process of achieving MRM. In turn, the designer may have to re-examine the construction of jointly-executing models.

We list the steps in UNIFY for the Platoon-Tanks MRE from Chapters 6 and 7. The Platoon-Tanks multi-model captured the combined semantics of a Platoon model and a Tank model. We employed UNIFY in order to achieve effective joint execution of the Platoon and Tank models. The steps we undertook in the process of employing techniques in UNIFY are listed below along with the sections in which we performed each step.

  1. 1. Construct an MRE for the jointly-executing models: §6.1. The Platoon-Tanks MRE captured the concurrent representations of a Platoon and two Tanks. The MRE could interact at either or both representation levels at any time.
  2. 2. Capture dependencies among the attributes in the MRE: §6.1. An ADG captured the dependencies among Platoon and Tank representations. By classifying and weighting dependencies, we captured their static and dynamic semantics.
  3. 3. Select mapping functions for each dependency: §6.2. We selected mapping functions to translate values or changes in values among Platoon and Tank attributes. These mapping functions ensured that the Platoon-Tanks MRE was internally consistent at all observation times.
  4. 4. Classify interactions: §7.6.2. We classified the interactions in the Platoon and Tank models according to our taxonomy. This classification enabled us to capture the semantics of interactions.
  5. 5. Select policies for resolving concurrent interactions: §7.6.2. We selected policies for capturing the dependencies among concurrent interactions. These policies resolved the effects of dependent concurrent interactions.
  6. 6. Construct a CE and an IR for the MRE: §6.3 and §7.6.2. A CE consists of an ADG and application-specific mapping functions, whereas an IR consists of policies for resolving the effects of interactions. We presented processes for the operation of a CE and IR for the Platoon-Tanks MRE. A CE and IR maintain internal consistency within an MRE when concurrent interactions occur.

The above steps constitute a process for achieving effective MRM for an application. The process and the techniques employed in each step are part of UNIFY , our approach for effective MRM. We demonstrated how to apply UNIFY to a multi-model application. We present our experience in applying the above process to several models in the appendices. Next, we evaluate UNIFY .