If you have built castles in the air, your work need not be lost;

that is where they should be. Now put foundations under them.

-- Henry David Thoreau

Chapter 3


Multi-Representation Modelling (MRM) is a means of capturing the combined semantics of jointly-executing models. The joint execution of multiple models brings up issues of conceptual and representational differences among the models. MRM involves the resolution of such differences. MRM includes but is not restricted to models that are executed as computer programs, called simulations. In this chapter, we lay the foundation for discussing our framework, UNIFY , by defining key concepts such as model, representation and interactions. We state and justify assumptions we make in our work and describe our evaluation strategy.

3.1 Model

Modelling is a way to study a phenomenon without undertaking the phenomenon itself. A model captures the semantics of selected concepts, objects and processes of a phenomenon in terms of other well-defined concepts, objects and processes. Objects and processes in a phenomenon are called entities in a model. The representation of an entity is a means of describing the entity and its properties. The representation of a model is the union of the representations of entities. Anything that is not part of the model is part of the model's environment . An attribute is an element of the representation of an entity that captures a property of the entity. A relationship between two attributes indicates how the value of one attribute changes when the value of the other attribute changes. In a valid or consistent model, the relationships among attributes hold , i.e, the values of attributes change in accordance with the relationships among them. Therefore, for each relationship, there must exist functions that translate changes in one attribute to changes in other related attributes. At a given instant of time, the values of the attributes and the relationships among the attributes reflect the phenomenon being modelled.

A model may change over time when the phenomenon it models changes. The state of a model is a set of values such that each member is a well-defined value assigned to an attribute. When the state of a model changes, the values assigned to its attributes may change, although the relationships among attributes continue to hold. Changes in attribute values are caused by interactions. An interaction is a communication between entities. An interaction is initiated by an entity called the sender , and directed towards an entity called the receiver . The sender and receiver may be part of the same model, in which case the interaction is internal. Either the sender or the receiver may be part of the environment or another model, in which case the interaction is external. We do not need to differentiate between internal and external interactions. The effects of an interaction are the changes caused by the interaction to the sender and receiver -- typically, to their attributes. We define interactions more rigorously in §3.2.

The preceding informal notions are characteristic of what model designers routinely assume. Now, we take a more formal view based on Object Modelling Technique [Rum91], Object Oriented Analysis [Shlaer92], Object Model Template [OMT98] and Unified Modelling Language [Alhir98] [Fowler97]. Let Rep be the set of all attributes of all entities in a model. Let Rel be the set of all relationships that hold in the model. Each relationship r Rel is a mapping between sets of attributes belonging to Rep , i.e., r : P Q , where P , Q Rep . Let Int be the set of interactions whose sender, receiver or both are part of the model. We define a model as a tuple of representations, relationships and interactions.

Our model is similar to an object model in Object Modelling Technique (OMTR)1. In OMTR, the object model describes the structure of objects in the system: their identity, attributes, mutual relationships and operations. Rep corresponds to the set of identities and attributes of OMTR objects. Rel corresponds to the set of relationships among OMTR objects. Int corresponds to the union of operations, events and actions as defined in OMTR. An OMTR object operation refers to an interaction for which the receiver is the same OMTR object that defines the operation. In OMTR, a dynamic model is a state diagram describing those aspects of the system concerned with time and the sequencing of operations. External stimuli that may change the model are called events in OMTR. In other words, OMTR events are interactions for which either the sender or receiver is outside the model. Finally, in OMTR, a functional model describes changes within each state of the state diagram in the dynamic model. The changes within a state are called actions in OMTR. OMTR actions are interactions for which the sender and receiver may not be defined in terms of OMTR objects; the sender and receiver both are the "system".

Our model is similar to an information model in Object Oriented Analysis (OOA). In OOA, the information model consists of objects, object attributes and relationships among objects. Rep corresponds to the set of OOA objects and their attributes. Rel corresponds to the set of relationships among OOA objects. An OOA state model is a state diagram in which a transition from one state to another is caused by an OOA event. A process model in OOA describes changes within each state of the state diagram in the state model. These changes are called actions, and are interactions for which the sender and receiver both are the "system". Int corresponds to the union of events and actions as defined in OOA.

In the High Level Architecture [AMG95], models are specified using the Object Model Template (OMT). OMT enables a designer to specify class hierarchies for objects, attributes of classes, interactions and parameters of interactions. Rep corresponds to the set of OMT object instances along with their attributes. OMT enables specifying interactions for which the sender and receiver are distinct OMT object instances, but not interactions for which either the sender or the receiver is outside the model or interactions for which the sender and receiver are the same OMT object instance. Int includes all these interactions, and hence is a superset of the set of OMT interactions. OMT does not include specifications for relationships among objects.

Our model is similar to a model in Unified Modelling Language (UML). In UML, a model consists of entities, relationships among entities and interactions among entities. Rep corresponds to the set of UML objects and their attributes. Rel corresponds to the set of links and associations among UML objects. Int corresponds to the union of scenarios, interactions and object operations as defined in UML. A structural model in UML describes the static behaviour of a model, whereas a behavioral model describes the dynamic behaviour of the model.

All of the above models, including ours, assume that Rep ≠ ∅. If Rep = ∅, then Rel = ∅ as well. Rep ≠ ∅ indicates that representation exists for a model. If Rep ≠ ∅, Rel = ∅ describes a model in which attributes are unrelated.

When a model executes , it simulates the progress of the phenomenon being modelled, implying the passage of time. Accordingly, when a model executes, time becomes an integral part of the model. We define a model at a particular time t as:

As a model executes, its state and the relationships among attributes may change. These changes may happen continuously; however, for most practical executions of models, these changes happen at discrete times. Discretizing time is a common technique in model execution. Accordingly, there exists a sequence of times T = ( t 0, t 1, t 2, ...), such that at each ti , the representation and relationships in Model are defined. At other times, i.e., ∀ tj T , Model ( tj ) may be undefined or may be the same as Model ( ti ) where ti T and ti is the largest instant in T such that ti < tj . The individual times in T may be regarded as observation times at which the model may be verified for consistency. T is monotonically increasing. The interval between two consecutive times is a time-step , denoted by [ ti , ti +1], where ti , ti +1 ∈ T . The durations of time-steps in a particular model may vary, i.e., ∀ ti , ti +1, tj , tj +1 ∈ T , i j , it is not guaranteed that ti +1 − ti = tj +1 − tj .

The execution of a model on a computer is called a simulation . A simulation is a tuple of the representation, relationships, interactions and observation times for that model.

We define representation and relationships for model execution. RepSeq and RelSeq are the sequences of states and relationships that hold during model execution.

Rep ( t ) is a set of values assigned to attributes in Rep at time t , i.e., Rep ( t ) is the state of the model at time t . Rel ( t ) is the set of relationships that hold at time t . A relationship r Rel , r : P Q , P , Q Rep holds at all observation times, i.e., ∀ t T , P ( t ) → Q ( t ), where P ( t ), Q ( t ) ⊆ Rep ( t ). A dependency is an indicator of a relationship between two attributes. The behaviour of a model is the sequence of states of that model [Abadi95] [Lam94] [Hop79]. Consider two models A and B that have the same representation, relationships and interactions. If attributes in A and B have different sequences of values or the same sequences of values but at different times, then A and B have different behaviours. The sequence of states for an entity is a subset of the sequence of states of a model, i.e., the behaviour of an entity is a subset of the behaviour of the model.

3.2 Interactions

In most models, entities and the environment exchange information with one another or influence one another. Models do not execute in isolation; typically, stimuli from the environment may influence behaviour of a model, and conversely, a model may generate stimuli that affect the environment. An interaction is a communication that causes a change in the behaviour of its sender or receiver or both.

Entities cause a change in the behaviour of one another by means of interactions. In other words, interactions cause a change in the sequence of states of entities. We regard interactions with one sender and multiple receivers as multiple instances of an interaction from one sender to one receiver. An interaction that causes a change in the state of its receiver changes the receiver's behaviour. Moreover, an interaction that does not change its receiver's state may well cause a change in behaviour. A receiver must evaluate whether the interaction affects it or not and apply the changes caused by the interaction if necessary. The evaluation and consequent action of the receiver take a finite, non-zero amount of time. Thus, the behaviour of the entity given the occurrence of an interaction is different from the behaviour of the entity if that interaction never occurred. An interaction that changes only the relationships in a model will cause the state of the model to change as well because of the changed relationships. We do not differentiate between interactions that change the state and interactions that change the relationships in a model.

Interactions may cause changes to the values of attributes. The semantics of an interaction and the dependencies among attributes determine the effects of an interaction. When the changes caused by an interaction are applied to individual attributes, the interaction takes effect. For an interaction I , I.affects is the set of tuples of attributes and changes to values of attributes caused by the semantics of I . If I causes only a read to an attribute value, the attribute is not in I.affects . If I causes a write to an attribute value, the attribute and its changes are in I.affects . I.affects + is the set of tuples of attributes and changes to attributes dependent on the attributes in I.affects . I.affects ∗ is the set of attributes transitively changed by I , i.e., I.affects ∗ = I.affects I.affects +.

Concurrent interactions are those interactions that occur during overlapping simulation time intervals. Interactions that occur one after another, i.e., do not overlap in time, are sequential interactions. In logical time systems, two interactions are concurrent if one does not "happen-before" the other [Lam78]. However, by this definition, interactions that occur at different times may be concurrent. In applications involving databases, caches and shared resources, two interactions are concurrent if they occur at overlapping times. We consider interactions as concurrent if they occur during the same time-step. Our definition of concurrence may exclude some concurrent interactions of logical time systems, but includes concurrent interactions in databases and caches. Interactions that occur at the same real time are simultaneous. In practical models, time is discrete, not continuous. Therefore, while real time-steps are of zero duration, time-steps in practical models are of non-zero duration. Thus, many interactions that are not simultaneous but happen to occur during the same time-step will be considered concurrent. The "false simultaneity" introduced by concurrent interactions may be reduced by a finer granularity of time within a model.

Concurrent interactions may be dependent. A dependent interaction is one whose effects are predicated on the occurrence of another interaction. An independent interaction is one that is not dependent on any other interaction. For example, two interactions may be related by cause and effect, i.e., one interaction causes the other. In such a case, the former interaction is independent of the latter, but the latter is dependent on the former. Concurrent interactions may be dependent solely on account of their concurrence, i.e., if the interactions were not concurrent, they would be independent.

With our definition of interactions, we define IntSeq as a sequence of sets of concurrent interactions. Each set contains interactions that occurred during one time-step. Int ( ti ) is the set of interactions that occur in time-step ti . Int ( ti ) k is the k th interaction that occurs in the time-step ti . No ordering is implied by k ; it is used solely to distinguish one interaction from another in that time-step. ∀ ti k , Int ( ti ) k Int . Int ( ti ) consists of ni +1 interactions, i.e.,  Int ( ti ) = ni +1. I J indicates that I and J are concurrent interactions.

Concurrent interactions may cause concurrent changes to entities. Let the effect of an interaction Int ( ti ) k on a state of a model be the change E ( Int ( ti ) k ). E ( Int ( ti ) k ) is the set of changes in Int ( ti ) k.affects ∗. Applying the effect of an interaction is equivalent to computing changes to attribute values caused by the interaction, i.e., applying the effect of interaction Int ( ti ) k on the representation Rep ( ti ) is equivalent to computing a function F ( Rep ( ti ), E ( Int ( ti ) k )). Applying the combined effects of all the interactions in one time-step results in the state of the model at the next time-step.

Applying the effects of concurrent, possibly dependent, interactions is called resolving the effects of the interactions. Let E ( I J ) denote the concurrent effects of interactions I and J , and E ( I ) ⋄ E ( J ) denote their sequential effects. Concurrent interactions can be resolved in different ways including, but not limited to, applying the effects of interactions in an arbitrary order. When interactions are independent, their effects when concurrent are indistinguishable from their effects when sequential.

The effects of concurrent independent interactions can be resolved by applying the effects of individual interactions one after another. This policy for resolving the effects of concurrent interactions is called serialization . If it can be determined that at all time-steps, concurrent interactions are independent, then serialization is a valid policy for resolving the effects of concurrent interactions. When interactions are dependent, their effects when concurrent may not be the same as their effects when sequential. The effects of dependent concurrent interactions may be predicated on the occurrence of one another during the same time-step. In such cases, serialization may resolve the effects of such interactions incorrectly; other policies for resolving the effects are necessary.

3.3 Multi-models

Multiple models of the same phenomenon may execute jointly with one another. Simple, well-designed models executing jointly may capture all the facets required for a particular study of a phenomenon without a designer having to construct one model that captures exactly those facets. Given that the multiple models are simplifications of the same phenomenon, entities common to the models must be correlated or made consistent. However, correlating the entities can become a very significant problem if the models make different assumptions about the processes, objects, environment, the rate of progress of the phenomenon and the accuracy at which the phenomenon is modelled. Inconsistencies among models may undermine the reasons for executing them jointly.

We use the term representation level to describe the level of abstraction of a model. If some models are compositions/decompositions or abstractions/refinements of one another, their representation levels are also called resolution levels or resolutions . An aggregate model is a relatively low-resolution (high-abstraction, low-decomposition) model, whereas a disaggregate model is a relatively high-resolution (low-abstraction, high-decomposition) model. A High Resolution Entity (HRE) is an entity at a low level of abstraction (high decomposition), and a Low Resolution Entity (LRE) is an entity at a high level of abstraction (low decomposition). Classification of an entity as an HRE or LRE depends on its resolution level relative to other relevant entities. The resolution levels form a hierarchy, with the highest level being the most abstract or most aggregate one, and the lowest level being the most refined or most disaggregate one. Aggregation is the composition of a collection of HREs into a single LRE, and disaggregation is the decomposition of an LRE into its constituent HREs.

Multi-representation modelling (MRM) is the joint execution of multiple models of the same phenomenon. We call the union of several models of the same phenomenon a multi-model . A multi-model may consist of several models; however, for ease of exposition, we will consider an example multi-model consisting of two models. If ModelA and ModelB are two models of the same phenomenon, then a multi-model ModelM constructed from them is defined as:

RepA and RepB are called concurrent representations . We construct RepM by including all of the attributes in RepA and RepB , after disambiguating name conflicts. For an attribute a , a RepA a RepB a RepM .

3.3.1 Cross-model Relationships

Relcross-model is the set of relationships required in order to make the multiple models consistent with one another. Since ModelA and ModelB model the same phenomenon, they may represent overlapping sets of objects or processes. In such a case, RepA and RepB must be correlated. Correlating the representations in a multi-model is called consistency maintenance . If Relcross-model = ∅, then ModelA and ModelB are independent of each other because their representations are not related to each other. Then, consistency maintenance reduces to ensuring that the individual models are self-consistent. If Relcross-model ≠ ∅, the representations of the models are related. A cross-model relationship r Relcross-model is a mapping r : P Q such that P RepA Q RepB P RepB Q RepA . We construct RelM by including all of the relationships in RelA , RelB and Relcross-model , i.e., for a relationship r , r RelA r RelB r Relcross-model r RelM .

3.3.2 Mapping Functions

A mapping function associated with a relationship among attributes translates the changes in one attribute to changes in related attributes in such a manner that the relationship continues to hold. We assume that designers can construct appropriate mapping functions for each relationship in Relcross-model . Mapping functions encode application-specific semantics about the relationships among representations. Mapping functions are necessary for any MRM approach, including ours.

A requirement for mapping functions is that at every observation time, they must ensure that a relationship holds by translating value spaces or changes in values of attributes, as necessary. ∀ r Relcross-model , r : P Q , P , Q RepM , a mapping function f may exist such that, if P ( ti ) → Q ( ti ) holds, then P ( ti +1) → Q ( ti +1) holds. For example, f may be of the form ∀ ti , ti +1, Q ( ti +1) = f ( Q ( ti ), P ( ti ), Δ P ( ti )), where Δ P ( ti ) is the set of changes to values in P ( ti ). Since f ensures that r holds ∀ ti TM , f must complete its computation within a time-step. In other words, a lower-bound value for an observation time ti +1 is the sum of the value of ti and the time taken for f to complete.

All mapping functions must be composable . If mapping functions f and g translate attribute sets P to Q and Q to R respectively, invoking f and g in succession must translate P to R . Attribute relationships are transitive, i.e., P Q Q R P R . Composable mapping functions capture transitive dependencies among attributes. If mapping functions are composable, the effects of an interaction propagate to all dependent attributes.

Mapping functions must be reversible . Consider mapping functions f and g : ∀ ti , ti +1, ti +2, Q ( ti +1) = f ( Q ( ti ), P ( ti ), Δ P ( ti )) and P ( ti +2) = g ( P ( ti +1), Q ( ti +1), Δ Q ( ti +1)). If no interactions occur during the time-steps [ ti , ti +1] and [ ti +1, ti +2], then invoking f and g in succession must result in P ( ti +2) = P ( ti ) within tolerable approximation. Reversibility is desirable for mapping functions because it ensures that a change does not propagate back to an attribute. Therefore, if Q changes as a result of a change to P , then reversible mapping functions ensure that P does not change again as a result of the change to Q .

3.3.3 Time-Steps

We assume that the time-steps of ModelA and ModelB are compatible. Compatible time-steps means that if TA , TB and TM are the sequences of times associated with ModelA , ModelB and ModelM respectively, then ModelA and ModelB are defined for all times in TM . TM is constructed by interleaving TA and TB . Accordingly, times that are common to both TA and TB (albeit labelled differently) are included in TM only once. If TM = TA TB , then ModelA must be defined for all times in TB and ModelB must be defined for all times in TA . If TM = TA TB , then ModelA and ModelB are defined for all t TM . Figure 6 shows two ways to construct TM .

No matter how TM is constructed, some interactions in each of IntA and IntB must be re-organised as if occurring in time-steps defined by times in TM . For example, let t 0 A , t 1 A , t 2 A TA . If t 1 A TM , then interactions occurring in the time-step [ t 1 A , t 2 A ] must be re-organised as if occurring in [ t 0 A , t 2 A ]. This re-organisation increases "false simultaneity". In like fashion, let t 0 A , t 1 A TA , and t 0 B TB such that t 0 A < t 0 B < t 1 A . If t 0 A , t 1 A , t 0 B TM , then interactions occurring in [ t 0 A , t 1 A ] must be re-organised into two sets, one occurring in [ t 0 A , t 0 B ], and the other occurring in [ t 0 B , t 1 A ]. This re-organisation decreases "false simultaneity". If TM = TA = TB :

3.4 Evaluation

In this dissertation we will show how UNIFY , our approach for consistency maintenance among concurrent representations satisfies R1, R2 and R3, our requirements for effective MRM.

A model must satisfy its users' requirements. Examples of user requirements are the accuracy of the model, the detail captured by the model and the rate at which the model progresses. The most accurate model of a phenomenon is the phenomenon itself; practical models are simplifications that may fail to imitate the phenomenon in some respects. The Turing test [Turing50] for a model is whether end-users are satisfied that the model captures the facets required for study. Likewise, for a multi-model, end-users must determine whether it meets their requirements. A multi-model can satisfy its users' requirements if its constituent models satisfy the users' requirements and the joint execution of the multiple models is effective.

Satisfactory multi-model Satisfactory models + Effective joint execution
Our work concentrates on effective joint execution of multiple models. In contrast, OMTR, OOA and UML guide a designer in constructing a model to meet users' requirements.

Requirements for models and multi-models must indicate how users can be satisfied. For training models, training experts may indicate satisfaction by assessing how well the model reflects reality. A term used often in the training community is fair fight , which signifies an engagement in which no party can deduce and utilize information about the training system (that they could not deduce in a real situation) to gain an unfair advantage. For example, due to an artifact of simulation, an aircraft may be perceived for some time after having been destroyed. This artifact could be employed to draw additional fire and thus force consumption of ammunition without sustaining losses. Similarly, crews in tank simulators have been reported to identify other tanks as being controlled by computer-generated forces rather than by humans by tracking their movements. The fair-fight concept is relevant to modelling since models approximate reality and there is potential to exploit knowledge of these approximations. In MRM, where a basic theory is still developing, arbitrary design choices may violate the fair-fight concept.

It is important to understand the difference between an unfair fight and what military analysts call the fog of war . The fog of war refers to circumstances -- typically large numbers of concurrent events -- that make it difficult to maintain a coherent picture of the battle, leading to unexpected events. Unfair fights, on the other hand, result from shortcomings in the design of a system and have no counterparts in a real-life phenomenon. Often, inconsistencies in a model are assessed incorrectly as being a part of the fog of war. While creating simulations that pass the Turing test is difficult, an important goal of designers should be to reduce the discrepancies that cause a simulation to fail the test [Petty94].

Our work concentrates on the effectiveness of joint execution of multiple models. Our approach, called UNIFY , is meant to guide designers towards effective MRM. Whether an MRM approach is effective or not can be evaluated on the basis of how well it meets three requirements, listed in §1.3 and below:

The interactions that occur in ModelM must be the interactions that could occur either in ModelA or in ModelB , i.e., IntM must be IntA IntB . If IntM meets this condition, it means that the joint execution of both models does not restrict the execution of either model. Effective joint execution of multiple models requires that entities at different representation levels initiate and receive interactions that may cause their behaviour to change. Many MRM approaches do not satisfy R1. For example, in selective viewing, if ModelB is the most detailed model, then the only interactions permitted in IntM are the ones in IntB . In aggregation-disaggregation, in each time-step of TM , either interactions in IntA or interactions in IntB , but not both are permitted. In Chapter 7, we present a taxonomy for resolving the effects of concurrent interactions in order to accommodate multi-representation interaction.

RelM must hold at all observed times in the multi-model. Moreover, it must be the case that Relcross-model ≠ ∅, or else consistency maintenance and joint execution are too trivial to be interesting. In Chapter 6, we present a technique for maintaining consistency among multi-models by showing how to construct Relcross-model . Application-specific mapping functions associated with each relationship in Relcross-model must be supplied by the designer. The mapping functions are required for consistency among multiple representations. Consistent representations are necessary for the consistent behaviour of a multi-model since the state of an entity influences its behaviour [Lam94]. Motivating the choice of finite automata for designing systems, Hopcroft et al . say [Hop79]:

The state of the system summarizes the information concerning past inputs that is needed to determine the behaviour of the system on subsequent inputs.

The inputs and state of a finite automaton are interactions and representation of a model. Since the multiple representations in a multi-model determine the behaviour of the multi-model, maintaining consistency among the representations is required for effective joint execution.

Simulation costs and consistency costs tend to be trade-offs, as we will see in Chapter 9. Simulation cost is the expenditure of resources in order to simulate entities, possibly at multiple representation levels. Consistency cost is the expenditure of resources in order to ensure that the multiple models meet consistency requirements. The resources expended may be computational, network or memory. In selective viewing, simulation costs are high whereas consistency costs are low since only the most detailed model is executed at all times. In aggregation-disaggregation, simulation costs are relatively low whereas consistency costs are high since the representations must be kept consistent when transitioning among models. We measure simulation cost and consistency cost for UNIFY , selective viewing and aggregation-disaggregation, and show how UNIFY reduces the total cost of simulation and consistency maintenance.

3.5 Assumptions and Rationale

Our approach for effective MRM, UNIFY , makes some assumptions about jointly-executing models. We have presented these assumptions in context earlier in this chapter; we discuss them in detail here.

Existence of representations : A representation exists for an entity and can influence the behaviour of the entity.

Typical models have representations; most designers consider representing entities in a model natural and intuitive. In some contexts, researchers claim that entities must not have a representation at all. For example, Brooks's description of subsumptive behaviour in autonomous agents involves agents maintaining no representation [Brooks86]. However, a representation is beneficial towards an agent's operation [Brill96]. Generally, entity state influences entity behaviour [Abadi95] [Lam94] [Hop79]. Therefore, our assumption about the existence and influence of representation is reasonable. We have not investigated in any detail the consequences of eliminating this assumption. Davis's work on variable-resolution process models is closer to a non-representational approach than our work [Davis92] [Davis98].

Existence of satisfactory models : Individual models meet their users' requirements.

The problem of linking independently-designed components into a composite system is hard enough without the additional complexity of the components falling short of meeting their individual requirements [Allen98]. Simply put, a bad model cannot be improved by jointly executing it with other models. Accordingly, we limit the scope of our work to the joint execution of models that meet their users' requirements.

Existence of mapping functions : There exist mapping functions to translate the representation of one model to the representation of other models.

Mapping functions are application-specific methods that capture the semantics of relationships among representations. Since capturing these semantics is essential for consistency of a multi-model, mapping functions are necessary for any approach to MRM. Since mapping functions are application-specific, instead of specifying their semantics, we derive requirements for their use from example multi-representation models. Mapping functions must translate attribute values and changes to attribute values from one representation to another. Additionally, they must complete their translations in a time-bound manner so that the multiple models appear consistent at all observed times. The specifications of consistency and observed times depend on the application.

Existence of policies for concurrent interactions : There exist policies for resolving the effects of dependent concurrent interactions.

Designers must resolve the intertwined semantics of interactions in order to be able to relate them to one another. Concurrent interactions that are dependent on one another may have effects that cannot be captured by serialization or any other straightforward policy. Designers must decide beforehand how the effects of dependent concurrent interactions must be resolved and subsequently applied. Without a clear understanding of the semantics of interactions, designers cannot expect any MRM approach to be effective. Therefore, similar policies are necessary for any approach to MRM.

Existence of compatible time-steps : The time-steps at which the models execute are compatible.

When multiple models execute jointly, the multiple simulation times must be compatible. Simulation time is a fundamental property of most models. Simulation time is tied to the progress of the phenomenon being modelled. Simulation time may or may not be real, logical, linearly-increasing, monotonic or uni-dimensional. If the multiple models adopt the same sequences of times, they are likely to be compatible and may be expected to execute jointly with few problems. However, the greater the variance between the sequences of times among the multiple models, the greater the difficulty of ensuring effective joint execution.

Alternative approaches, such as selective viewing and aggregation-disaggregation, cannot guarantee effective MRM even if they make similar assumptions as above because they continue to violate R1, R2 or R3. Therefore, we believe that our assumptions are reasonable for a framework for effective MRM.

3.6 Chapter Summary

MRM, the joint execution of multi-models, presents users with combined semantics that may not be captured by the independent execution of the multiple models. MRM requires designers to invest effort to ensure that the combined semantics meet users' expectations. In particular, ensuring that representations of multi-models are consistent when concurrent interactions may occur is crucial for effective MRM.

UNIFY is a framework for designers who require multi-models for their applications. Even if designers are capable of constructing individual models that meet their users' requirements, they can find constructing multi-models difficult. Designers can construct multi-models by ensuring that the joint execution of the multiple models is effective. An approach for effective MRM must satisfy the requirements of multi-representation interaction, consistency and cost-effectiveness.

In the next chapter, we identify problems with aggregation-disaggregation, a popular approach to MRM. After analyzing why these problems occur, we make some general observations about MRM.

1. Rumbaugh et al use the acronym OMT for Object Modelling Technique. To resolve a name conflict with the High Level Architecture Object Model Template, we refer to Rumbaugh's Object Modelling Technique as OMTR and the HLA Object Model Template as OMT.