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
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:
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 multimodels, 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.
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 multimodel 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 crossmodel relationships in the multimodel, can understand the intertwined semantics of interactions and can make timesteps in the multimodel compatible.
By following these guidelines, designers can incorporate effective MRM into their applications. A multimodel can satisfy its users' requirements if MRM is effective.
UNIFY
with a Specification Methodology
We expect designers of multimodels 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 "plugandplay" fashion. Individual models and multimodels 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 multimodel. The APT and the OIT enable the designer to describe the interactions for the multimodel. 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.
Detonation, any combination of (Collide_Tank1, Collide_Tank2) 
Add compensatory interaction for competitive effects to Dam1 or Dam2; actual damage less than sum of damages 

Ignore Type 1 

Ignore Type 3 

Ignored or Delayed entirely, i.e., no partial effects permitted 
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 multimodel. The dashed arrows represent feedback in the process. We view designing models, constructing a multimodel and achieving MRM as iterative processes. We employed a running example of a PlatoonTanks 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 jointlyexecuting 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 jointlyexecuting 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 multimodel 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 jointlyexecuting models satisfy MRM requirements: multirepresentation interaction (R1), multirepresentation consistency (R2) and costeffectiveness (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 reexamine the construction of jointlyexecuting models.
We list the steps in
UNIFY
for the PlatoonTanks MRE from Chapters 6 and 7. The PlatoonTanks multimodel 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.
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 multimodel application. We present our experience in applying the above process to several models in the appendices. Next, we evaluate
UNIFY
.