It is of course important to try to maintain consistency,

but when this effort forces you into a stupendously ugly theory,

-- Douglas Hofstadter, Gödel, Escher, Bach

For effective MRM, jointly-executing multiple models must be consistent with one another (requirement R2). In Chapter 5, we presented Multiple Representation Entities (MREs) which incorporate concurrent representations of multiple models. A Consistency Enforcer (CE) is a component of an MRE that maintains consistency among concurrent representations. A CE consists of an Attribute Dependency Graph (ADG) that captures dependencies among representations, and application-specific mapping functions that translate attributes. An ADG and mapping functions ensure that the relationships in an MRE hold at all observation times. In this chapter, we present ADGs, discuss how mapping functions relate to them and demonstrate the construction of a CE.

When an interaction changes the value of attributes, a CE ensures that the concurrent representations in an MRE are consistent. The operation of a CE involves traversing an ADG and invoking mapping functions to compute the changes to relevant attributes. A CE maintains internal consistency within an MRE. Constructing a CE involves:

- 1. Constructing an Attribute Dependency Graph
- a. Assigning Nodes to Attributes
- b. Assigning Arcs to Dependencies
- c. Assigning Semantics to Dependencies
- 2. Selecting Mapping Functions

In §6.1, we describe ADGs and introduce an example in order to demonstrate step 1. Also, we introduce four classes of dependencies: cumulative, distributive, modelling and interaction. In §6.2, we discuss the mapping functions that designers must provide for their multi-models (step 2). In §6.3, we describe how a CE can enforce consistency among multiple representations by traversing an ADG and propagating the effects of an interaction. In §6.4, we present various implementation strategies for Consistency Enforcers such as spreadsheets, attribute grammars, mediators and constraint solvers. In this chapter, we assume concurrent interactions are independent, i.e., their effects can be resolved by serialization. We make this assumption in order to explain the operation of a Consistency Enforcer alone. We address dependent concurrent interactions in Chapter 7.

An
Attribute Dependency Graph
captures dependencies among attributes in concurrent representations. When multiple models execute jointly, a change to an attribute may cause other dependent attributes to change. A dependency graph is a natural technique to capture such cause-effect dependencies among attributes. In an ADG, nodes correspond to attributes in a multi-model and arcs correspond to dependencies among the attributes. In the simple ADG shown in Figure 25, the left node corresponds to an attribute `
a`
, and the right node corresponds to an attribute `
b`
. The arc connecting the two nodes shows that `
b`
depends on `
a`
, or `
a`
affects `
b`
. If the value of `
a`
changes, the value of `
b`
may change. If the value of `
b`
changes, there is no requirement for the value of `
a`
to change. For the relationship in the figure, `
a`
is the independent attribute and `
b`
is the dependent attribute. The ADG in Figure 25 does not show *
how*
`
b`
must change when `
a`
changes. A mapping function must encode how `
b`
changes when `
a`
changes. Dependency graphs such as ADGs capture cause-effect relationships in a number of contexts, for example, task execution sequences in Petri nets [Peter77], data dependencies in dataflow models [Dennis80], method invocation in object-oriented design [Rum91] [Shlaer92], and causal relationships in logical time systems [Lam78].

Let `
ModelA`
be a low-resolution model and `
ModelB`
be a high-resolution model. Recalling our definitions from Chapter 3, in ```
UNIFY
```

, a multi-model `
ModelM`
is:

`
ModelM`
is consistent if `
RelM`
, and in turn, `
Relcross-model`
hold ∀`
t`
∈ `
TM`
. Previous MRM approaches do not capture complex cross-model relationships that may hold at different times. In selective viewing, ∀`
t`
∈ `
TM`
, `
ModelM`
(`
t`
) = `
ModelB`
(`
t`
) and `
Relcross-model`
= ∅. In aggregation-disaggregation, at time `
ti`
∈ `
TM`
, `
ModelM`
(`
ti`
) = `
ModelA`
(`
ti`
), and at time `
tj`
∈ `
TM`
, `
ti`
≠ `
tj`
, `
ModelM`
(`
tj`
) = `
ModelB`
(`
tj`
). `
Relcross-model`
≠ ∅ only when a representation level is transitioned, i.e., `
ti`
, `
ti`
+1 ∈ `
TM`
, `
ModelM`
(`
ti`
) = `
ModelA`
(`
ti`
) ∧ `
ModelM`
(`
ti`
+1) = `
ModelB`
(`
ti`
+1) ∨ `
ModelM`
(`
ti`
) = `
ModelB`
(`
ti`
) ∧ `
ModelM`
(`
ti`
+1) = `
ModelA`
(`
ti`
+1).

In ```
UNIFY
```

, an ADG has a node for each attribute `
a`
∈ `
RepM`
, and an arc for each relationship `
r`
∈ `
RelM`
. Recall that `
Relcross-model`
is defined as a set of relationships such that ∀`
r`
: `
P`
→ `
Q`
, `
P`
⊆ `
RepA`
∧ `
Q`
⊆ `
RepB`
∨ `
P`
⊆ `
RepB`
∧ `
Q`
⊆ `
RepA`
. An ADG has an arc for every `
r`
∈ `
Relcross-model`
because `
Relcross-model`
⊆ `
RelM`
. An ADG is a technique for describing attributes in concurrent representations, relationships among those attributes and the semantics of the relationships.

In the following sub-sections, we show how to construct an ADG for an example MRE from jointly-executing battlefield models. Our example is derived from specifications of actual battlefield models [JPSD97] [JTFp97] [RPR97]. The choice of models reflects our familiarity with the domain, not a restriction on the kind of multiple models for which ADGs are relevant. Let `
ModelA`
be a platoon model, `
ModelB`
be a tank model, and `
ModelM`
be a multi-model incorporating these two models. A platoon in `
ModelA`
has attributes for position (Pos), velocity (Vel), firepower (Fire), strength (Str), appearance (App) and formation (Form). A tank in `
ModelB`
has attributes for position (Pos), velocity (Vel), hits (Hits), ammunition (Ammo), damage status (Dam) and fuel level (Fuel). Our MRE, the Platoon-Tanks MRE in Figure 26, is a platoon represented at two levels: the platoon level and the tank level. Therefore, this MRE has attributes for a platoon and its constituent tanks. For ease of exposition, we assume that our platoon can be represented at the tank level by just two tanks. Attributes App, Form, Pos, Vel, Fire, Str ∈ `
RelA`
, and attributes Dam1, Fuel1, Pos1, Vel1, Ammo1, Hits1, Dam2, Fuel2, Pos2, Vel2, Ammo2, Hits2 ∈ `
RelB`
. We will demonstrate the construction of an ADG for this MRE.

The first step in constructing an ADG is assigning nodes to attributes. In principle, a designer may assign a node to any set of attributes `
P`
such that `
P`
⊆ `
RepA`
∨ `
P`
⊆ `
RepB`
. A node can be assigned to any set of attributes that enables a designer to make straightforward decisions about applying the effects of interactions. For example, the designer may assign a node to the set of attributes of a tank. However, such an assignment does not aid the designer substantially in applying the effects of interactions. In practice, since interactions affect *
attributes*
, we expect the designer to assign nodes to attributes such as position and appearance. In a multi-model involving atoms and molecules, nodes could be assigned to atom-level attributes such as orientation and charge, and molecule-level attributes, such as orientation and valence. In a hierarchical autonomous agent model, nodes could be assigned to planner-level attributes such as absolute location and connectedness, and perception-action-level attributes such as relative location, colour and visibility. In our example, we assign a node in the ADG to every attribute in the concurrent representations of `
ModelM`
, i.e., every attribute `
a`
∈ `
RepM`
. In Figure 27, we show all the attributes as nodes labelled with unsubscripted or appropriately-subscripted names.

The second step in constructing an ADG is assigning arcs to dependencies. An arc connecting two nodes represents a dependency between attributes corresponding to the nodes. Since a dependency between two attributes indicates that they are related, arcs in an ADG correspond to each relationship `
r`
∈ `
RelM`
. In Figure 28, we show dependencies for our Platoon-Tanks example. The platoon position depends on each tank position and

The third step in constructing an ADG is to assign semantics to dependencies. Assigning semantics to dependencies enables the construction of appropriate mapping functions for them. One way to assign semantics is to classify dependencies. Mapping functions associated with classes of dependencies have common requirements. Dependencies may be classified according to characteristics specific to an application. We classify dependencies in an application-independent manner into four categories: cumulative, distributive, interaction and modelling. Binary weights, fractional weights and interaction classes are other techniques for capturing semantics of dependencies. Assigning weights to cumulative and distributive dependencies can capture how changes to an attribute contribute or distribute to other attributes. Modelling dependencies already capture semantic information, hence we do not associate any additional semantic information with them. The semantics we associate with interaction dependencies are the classes of interactions (discussed in Chapter 7). The semantics assigned to dependencies vary with applications.

Whole-to-parts and parts-to-whole relationships are common in models, for example, aggregation associations among objects in UML [Alhir98] and OMTR [Rum91], and relationships among objects such as part-whole, consists-of, composition, has-part and contains in other modelling methodologies [Fowler97]. These associations and relationships usually are bidirectional, i.e., a relationship between `
P`
and `
Q`
implies another relationship between `
Q`
and `
P`
. These associations and relationships capture whole-to-parts and parts-to-whole relationships among objects; we capture similar relationships between attributes with cumulative and distributive dependencies.

Cumulative and distributive dependencies capture parts-to-whole and whole-to-parts relationships among attributes respectively.
Cumulative dependencies
are dependencies in which the value of a single attribute is influenced jointly by the value of many other attributes. For a relationship `
r`
∈ `
RelM`
, `
r`
: `
P`
→ `
Q`
, `
P`
, `
Q`
⊆ `
RepM`
, where `
Q`
= 1, ∀`
a`
∈ `
P`
and `
b`
∈ `
Q`
, a cumulative dependency exists from `
a`
to `
b`
.
Distributive dependencies
are dependencies in which the value of a single attribute influences the value of many other attributes jointly. For a relationship `
r`
∈ `
RelM`
, `
r`
: `
P`
→ `
Q`
, `
P`
, `
Q`
⊆ `
RepM`
, where `
P`
= 1, `
a`
∈ `
P`
and ∀`
b`
∈ `
Q`
, a distributive dependency exists from `
a`
to `
b`
. In hierarchical models, cumulative dependencies capture relationships from disaggregate attributes to aggregate attributes, and distributive dependencies capture relationships from aggregate attributes to disaggregate attributes.

Interactions cause changes to attributes.
Interaction dependencies
are dependencies between the sender of an interaction and the attributes changed directly by the interaction. An interaction `
I`
∈ `
IntM`
, may be viewed as a relationship `
r`
: `
P`
→ `
Q`
, where `
Q`
⊆ `
RepM`
, but it is not necessary that `
P`
⊆ `
RepM`
. An interaction dependency captures a cause-effect relationship from attributes of a sender to attributes of a receiver.

Other relationships may exist among attributes. These relationships may be inherent in the nature of the object or process being modelled, and may not be captured conveniently by cumulative, distributive or interaction dependencies. Modelling dependencies are dependencies that are not cumulative, distributive or interaction.

If a pair of attributes has a cumulative dependency between them, they may have a distributive dependency as well. A change to a part may affect the whole and `
a`
, `
a`
1, `
a`
2, ..., `
an`
, `
b`
, `
b`
1, `
b`
2, ..., `
bm`
∈ `
RepM`
. In Table 7, we list how dependency classes can be assigned to combinations of whole-to-parts and parts-to-whole relationships. The first column lists combinations of whole-to-parts and parts-to-whole relationships. The second and third columns list the attribute dependencies and their type. For the relationship {`
a`
} → {`
b`
}, classifying the dependency as either cumulative or dependency is valid since the relationship is one-to-one. One-to-one relationships are degenerate cases of both, whole-to-parts and parts-to-whole relationships.

If an interaction can change an attribute, an interaction dependency exists to that attribute, i.e., ∀`
I`
∈ `
IntM`
, if <`
a`
, δ`
a`
> ∈ `
I.affects`
, where δ`
a`
is a change to attribute `
a`
caused by `
I`
, then an interaction dependency exists to `
a`
. Although many interaction types may change an attribute, we associate only one interaction dependency with the attribute because the identity of the independent attribute is irrelevant. Modelling dependencies have application-dependent semantics.

Our dependency classes are complete and extensible. Cumulative and distributive dependencies capture whole-to-parts and parts-to-whole dependencies, which are common in models. Interaction dependencies capture dependencies from entities outside to entities inside a model. By definition, modelling dependencies are all dependencies that are not cumulative, distributive or interaction. Although the dependency classes are complete, designers can extend them by identifying other classes of dependencies. Additional classes may refine cumulative, distributive or modelling dependencies, thus enabling designers to specify requirements of mapping functions in greater detail. For example, the boards of a T-joint are connected rigidly, whereas the arms of a pair of pliers are connected non-rigidly. Therefore, the cumulative dependencies from the board positions to the T-joint position and from the arm positions to the pliers position can be refined into two classes: rigidly cumulative and non-rigidly cumulative. This refinement enables a designer to specify mapping functions that translate the positions in rigidly and non-rigidly cumulative dependencies differently.

By adding interaction dependencies to the ADG in Figure 28, we obtain the complete ADG shown in Figure 29. Cumulative dependencies capture the relationship from the tank positions to the platoon position. Distributive dependencies capture the converse relationship from the platoon position to the tank positions. Likewise, cumulative dependencies capture the relationship from the tank velocities to the platoon velocity, and distributive dependencies capture the converse relationship from the platoon's velocity to the tank velocities. In the same fashion, cumulative and distributive dependencies capture the relationships among other platoon attributes and tank attributes. Modelling dependencies capture the relationships from the velocities of the platoon and the tanks to the positions of the platoon and the tanks. Likewise, a modelling dependency captures the relationship from the platoon formation to the platoon appearance. An interaction dependency to each attribute captures the effects of interactions with other entities or simulation actions of the platoon and the tanks.

Weighting dependencies with binary or fractional weights captures the semantics of *
contribution*
. The weight on a dependency indicates how much the independent attribute contributes to the dependent attribute. Although the assignment of weights can be construed as part of a mapping function, we view weights as an example of assigning semantics to dependencies prior to the construction of a mapping function.

**
Weights on Cumulative Dependencies**
: Weighting cumulative dependencies captures the manner in which many independent attributes affect one dependent attribute. A cumulative dependency can be weighted according to what fraction of the value of an independent attribute contributes to the dependent attribute. For example, the cumulative dependencies from Hits1 and Hits2 to Str in Figure 29 could be weighted one, indicating that all tanks contribute their hits entirely to the platoon strength. This weighting satisfies the semantic requirement that the platoon strength is the sum of the hits of all tanks. In the case of firepower shown in Figure 30, the cumulative dependencies may be non-unity. If a tank, say Tank1, fights a disaggregate-level battle, then W1 = 0 indicates that Tank1 expends all its ammunition in the disaggregate battle only. If Tank1 could fire at both levels simultaneously (a physical impossibility, but assumed for exposition), and Tank1 allocated 50% of its total ammunition for each engagement, then W1 = 0.5.

**
Weights on Distributive Dependencies**
: Weighting distributive dependencies captures the manner in which one independent attribute affects many dependent attributes. A distributive dependency can be weighted according to what fraction of the change to an independent attribute propagates to the dependent attribute. For example, the distributive dependencies from the tank hits to the platoon strength in Figure 29 could be weighted as shown in Figure 31. If the platoon strength is reduced, fractions of that change propagate to the tank hits. In order to satisfy the semantic requirement that the platoon's strength is the sum of the tank hits, the sum of the propagated fractions must sum to the reduction in the platoon strength. An independent attribute may not affect all its dependent attributes uniformly. For example, either W1 or W2 (but not both) may be zero, meaning that a change to Str does not change the corresponding Hits. This weight could reflect a scenario in which the unaffected tank is shielded from the firepower of the enemy because of barriers, entrenchments or good defensive position.

**
Assignment of Weights**
: The weights on cumulative and distributive dependencies may change during a simulation. For a battlefield simulation, weights may be assigned per engagement. Thus, strength reductions from different enemies may propagate with different sets of weights because of the nature of the enemies' firepower or their positions. In indiscriminate firing situations, weights may be assigned randomly to reflect the fog of war (see §3.4). Alternatively, weights may be assigned depending on the properties of the constituents. For example, boolean attributes signifying the visibilities of disaggregate entities are not fractions of a boolean attribute signifying the visibility of the corresponding aggregate entity. In such cases, boolean weights for distributive dependencies are more appropriate, and the product, rather than the sum, of the distributive weights must be one.

**
Interlinked Dependency Weights**
: The weights on distributive and cumulative dependencies are dependent on one another. The weights on these dependencies must be assigned with due consideration to the meaning of the combination of weights. For example, suppose a designer specifies that a tank, say Tank1, does not fire in a platoon-level battle. Therefore, Ammo1 does not contribute to Fire. Refining the specification further, we can say: If Ammo1 does not contribute to Fire, then a change to Fire does not change Ammo1. For the refined specification, a weight of zero on the cumulative dependency from Ammo1 to Fire captures the *
if*
-part, and a weight of zero on the distributive dependency from Fire to Ammo1 captures the *
then*
-part. Therefore, the specification above can be re-stated as: A zero-weight cumulative dependency from Ammo1 to Fire ⇒ a zero-weight distributive dependency from Fire to Ammo1. If the distributive dependency is zero and the cumulative dependency is non-zero it just means that Tank1 contributed some of Ammo1 to Platoon, but Platoon did not use Ammo1 in this engagement. Other combinations of weights for the cumulative and distributive dependencies are possible for other attributes.

Whether a change to an attribute occurs as a result of another entity's interaction or as a result of simulation activities performed by the MRE, the change originates from interaction dependencies. Since different interactions may change an attribute, a change to an attribute because of an interaction dependency can have different semantics. Although we associate only one interaction dependency per attribute, we say that the semantics of an interaction dependency change with the semantics of interactions. We discuss interaction semantics in Chapter 7.

ADGs capture relationships among attributes in concurrent representations. Designers construct an ADG by assigning nodes and arcs to attributes and relationships in `
RelM`
. Next, they classify dependencies and assign semantics to them. In Figure 29, a cumulative or distributive dependency exists ∀`
r`
∈ `
Relcross-model`
and a modelling dependency exists ∀`
r`
∈ `
RelA`
and ∀`
r`
∈ `
RelB`
. Since `
RelM`
= `
RelA`
∪ `
RelB`
∪ `
Relcross-model`
, a dependency exists in the ADG ∀`
r`
∈ `
RelM`
. For other MREs, `
RelA`
, `
RelB`
and `
Relcross-model`
may contain other combinations of cumulative, distributive and modelling dependencies.

In addition to the relationships in `
RelM`
, the ADG captures interaction dependencies. Interaction dependencies are a starting point for applying the effects of interactions. We discuss applying the effects of interactions in §6.3. After the ADG is constructed, the designer must choose appropriate mapping functions to perform the actual translations among attributes for each dependency. Next, we show how to select these functions.

Mapping functions translate value spaces or changes to values of attributes. An ADG indicates *
which*
attributes must change when an interaction occurs. Mapping functions along with an ADG indicate *
how*
the attributes must change. Mapping functions determine whether a relationship holds, i.e., whether the dependent attributes are consistent with the independent attributes. Determining whether attributes are consistent entails comparing them. The results of the comparison may be exact or within tolerable error.

Mapping functions translate value spaces or changes in the values of attributes. When an attribute changes as a result of an interaction, invoking appropriate mapping functions is necessary to ensure that dependent attributes change as well. Therefore, either the new value of an independent attribute or the change to its previous value must be translated to new values or changes to previous values of dependent attributes.

A mapping function may translate *
value spaces*
among attributes, i.e., the function has the form ∀`
ti`
, `
ti`
+1, `
Q`
(`
ti`
+1) = `
f`
(`
Q`
(`
ti`
), `
P`
(`
ti`
+1)), where `
P`
(`
ti`
+1) is determined by applying the changes Δ`
P`
(`
ti`
) to `
P`
(`
ti`
). For example, a mapping function `
f`
translates tank ammunitions to platoon firepower. Here, `
Q`
= {Fire} and `
P`
= {Ammo1, Ammo2}. An implementation of `
f`
is shown in Figure 32. Since cumulative dependencies connect the ammunitions to the firepower, a mapping function must include the contributions of each tank ammunition to compute the platoon firepower. Accordingly, the mapping function must utilise the weights on the cumulative dependencies.

A mapping function may translate *
changes to values*
among attributes, i.e., the function has the form ∀`
ti`
, Δ`
Q`
(`
ti`
) = `
f`
(`
Q`
(`
ti`
), Δ`
P`
(`
ti`
)), where `
Q`
(`
ti`
+1) is determined by applying the changes Δ`
Q`
(`
ti`
) to `
Q`
(`
ti`
). For example, a mapping function `
g`
translates a change in platoon strength to changes in tank hits. Here, `
Q`
= {Hits1, Hits2} and `
P`
= {Str}. An implementation of `
g`
is shown in Figure 33. Since distributive dependencies connect the strength to the hits, a mapping function must distribute the change in the platoon strength to changes in each tank hits. Accordingly, the mapping function must utilise the weights on the distributive dependencies.

After an ADG has been constructed and mapping functions selected, a CE can maintain consistency within an MRE by traversing the ADG and invoking the appropriate mapping functions. An interaction `
I`
may change the values of any attributes. These changes must propagate to dependent attributes. By traversing an ADG, a CE propagates `
I.affects`
`
I.affects`
+

Ensuring internal consistency within an MRE involves traversing an ADG when a change to any attribute occurs. The effects of an interaction can be applied by traversing an ADG and invoking appropriate mapping functions. In OMTR, a similar concept is called propagation [Rum91]. Initially, an MRE is internally consistent; all relationships in `
RelM`
hold. When an interaction `
I`
occurs, a CE traverses an ADG starting from the nodes corresponding to the attributes in `
I.affects`
. `
I.affects`
is computed from semantic knowledge about the interaction. After the changes in `
I.affects`
are applied, the MRE is temporarily inconsistent. In order to regain the consistency of the MRE, its ADG must be traversed beginning from the nodes corresponding to the attributes in `
I.affects`
. For each arc traversed, a mapping function must be invoked to change dependent attributes.

In Figure 34, we present an algorithm for ADG traversal. The outer loop in the algorithm implicitly assumes that interactions are serialized. The first step in the loop initialises a set, ```
S
```

, which will contain the effects of an interaction `
I`
. The first inner loop includes `
I.affects`
in ```
S
```

. These effects can be represented by tuples, each consisting of an attribute and a change to it. The change to an attribute depends on the semantics of the interaction. Finally, in the second inner loop, for each unvisited element in ```
S
```

, the change to an attribute is applied, and the change to dependent attributes is computed and included in ```
S
```

. Marking an attribute as visited ensures that the effects of an interaction are not re-applied to the attribute. The change to an attribute, ```
a
```

, as a result of the interaction depends on the semantics of the attribute. Attributes dependent on ```
a
```

can be determined from the ADG. For each dependent attribute, a mapping function translates the change to the value of the attribute. If a dependent attribute changes, a tuple consisting of the attribute and its change is included in ```
S
```

to account for `
I.affects`
+.

We step through the algorithm in Figure 34 with an example. Let a tank in our example MRE receive a `
move`
interaction. This interaction changes the position of the tank, say Pos2. Therefore, a tuple consisting of Pos2 and a change to Pos2 is included in ```
S
```

. When the change to Pos2 is applied, the MRE is temporarily inconsistent. In order to regain the consistency of the MRE, a CE must traverse the ADG beginning from the node corresponding to Pos2. The attributes that depend on Pos2 are: Pos, Pos1, Pos2, Form, App, Dam1 and Dam2. Figure 35 shows a sub-graph of the ADG with only the nodes corresponding to attributes connected transitively to Pos2. A CE must invoke mapping functions to translate changes to each of these attributes. For example, the change to Pos may be computed as the centroid of Pos1 and Pos2. If the change to Pos is non-zero, then a tuple consisting of Pos and its change is included in ```
S
```

. In like fashion, the CE propagates the effects of the interaction to each dependent attribute. Figure 36 shows a partial tree corresponding to the propagation of the change to Pos2 to dependent attributes.

The algorithm in Figure 34 includes but intentionally does not make apparent intricate issues in ADG traversal, for example, cyclic dependencies and traversal path. We address these issues next.

Cyclic dependencies among attributes may cause traversal of an ADG to never terminate. For example, when an interaction changes Pos2, a CE changes Pos because of the cumulative dependency from Pos2 to Pos. The CE propagates the change to Pos to Pos1 and Pos2 because of distributive dependencies. Since Pos2 has already changed because of this interaction, the CE must stop the propagation of effects from Pos. If the CE does not stop the propagation of effects, the MRE may never reach a state at which consistency can be evaluated. Although an ADG may have cycles, the propagation of effects must be non-cyclic. It is reasonable for attributes to be mutually dependent. However, cycles should not prevent the graph traversal from terminating.

Reversible mapping functions break cycles in ADG traversal. If reversible mapping functions translate attributes, then the change to some attributes may be null, which breaks the cyclic traversal between them. In case of attributes for which reversible mapping functions cannot ensure zero change, the final condition in Figure 34 should be modified such that a tuple is included in ```
S
```

only when a non-negligible change occurs. Reversible mapping functions ensure that a change to Pos due to an initial change to Pos2 does not affect Pos2 again. Let mapping functions `
f`
and `
g`
translate Pos2 to Pos and Pos to Pos2 respectively. If `
g`
(`
f`
(Pos2)) = Pos2, then `
f`
and `
g`
are reversible. When an interaction changes Pos2, `
f`
changes Pos, and `
g`
ensures that a subsequent change to Pos2 will be zero. In Figure 34, effects are included in ```
S
```

only if necessary. Therefore, the zero change to Pos2 is not included in ```
S
```

, breaking a cyclic traversal. When all cyclic traversals are broken, the traversal of an ADG can terminate. If ADG traversal terminates, an MRE can be consistent before the next observation point.

ADGs enable designers to identify and capture combined semantics of multiple models. Unplanned dependencies are an example of the combined semantics of jointly-executing models. An ADG captures attribute dependencies that may not have been planned by designers of the individual models. For example, the designer of the tank model may not have expected Pos2 and Dam1 to be dependent. However, because of transitive dependencies, these attributes are related, as seen from Figure 36.

An issue with ADG traversal is the order in which a CE propagates the effects of interactions. When an interaction changes an attribute, a CE may change other attributes subsequently. For example, in Figure 36, if an interaction changes Pos2, a CE must change Pos and Form. Suppose the CE changes Pos first. Next, it must change Form (because of the original change to Pos2) and Pos1 (because of the change to Pos). Changing Form first implies a breadth-first traversal of the ADG, whereas changing Pos1 first implies a depth-first traversal. Other traversal orders are possible as well. Ideally, all traversal orders finally must propagate the effects in the same manner. Practically, because of errors accumulated during attribute translation, or because attribute translations are not commutative, different traversal orders may produce different results.

A breadth-first traversal is well-suited for propagating the effects of interactions. For distributive dependencies, the nature of the dependencies requires that effects propagate breadth-first. Moreover, when the comparison for consistency among attributes is inexact, i.e., they are consistent within tolerance, longer paths may accumulate errors that cause reversibility to fail. With breadth-first traversal, a CE chooses the shortest paths between the initial attribute and dependent attributes [Cormen89]. Intuitively, when an interaction changes an attribute, dependent attributes that are "closer" to the attribute in the ADG, i.e., reachable by fewer arcs, are affected more immediately by the interaction. Therefore, a CE should change those attributes earlier.

The algorithm in Figure 34 can be refined to mandate breadth-first traversal. ```
S
```

should be changed to a queue so that tuples are pushed the end of a queue. When selecting attributes dependent on the current attribute ```
a
```

, only attributes connected directly to ```
a
```

must be included. Including only directly-connected attributes and making ```
S
```

a queue ensure that the effects of an interaction are applied breadth-first.

For our example MRE, we show how a CE propagates the effects of a `
move`
interaction to attributes. We indicate the cause of each attribute change as well. Table 8 shows the effects of this interaction. The first column lists the attributes changed by the interaction. The second, third and fourth columns list the change to an attribute, the dependency that caused the change and the interaction or independent attribute for that change. The order in which we list changes to attributes corresponds to a breadth-first traversal of an ADG for our MRE, i.e., a breadth-first traversal of the graph in Figure 36.

Constructing a CE for an MRE is a reasonably straightforward task. A module for a CE may be implemented in a number of ways, as we show in the following sub-sections. We discuss broad implementation details in order to show that the CE is not a "black box" that magically solves consistency maintenance -- one of the hardest problems in MRM.

The most straightforward implementation of a CE is "as-is"; the ADG is instantiated as a graph data structure and mapping functions are function calls associated with each arc in the data structure. This implementation is effort-intensive for the designer but not as naïve as it first seems since it gives the designer the freedom to hand-craft relationships, mapping functions and traversal strategies that are best-suited for an application.

In a spreadsheet, data are organised as tables. Each spreadsheet element is addressed uniquely by row and column number. Each element may consist of a data value or a function. In the latter case, the value of the element is computed by invoking the function on data values or elements specified along with the function.

A CE can be implemented as a spreadsheet that has an element for each attribute in the ADG. The strict organisation of a spreadsheet as rows and columns is inconvenient but not restrictive. Mapping functions are specified by making some elements of the spreadsheet functions of other elements. However, typical spreadsheet functions are awkward for mapping functions. In typical spreadsheets, the function used to compute an element is indistinguishable from the value of the element, i.e., the function and the value for element change jointly. Therefore, if we change the value of an element, we automatically change the function that computes the element as well. Changing a function changes the relationship among elements in the spreadsheet, thus changing the relationship among attributes in the MRE. Changing the relationship may not have been part of the semantics of the interaction. A work-around for this problem involves using multiple elements for an attribute: one for the value and one for each relationship in which this attribute depends on other attributes. Not only is this work-around inelegant, but it also leads to circular references, i.e., elements that refer to one another. Spreadsheets such as *
Excel*
1 permit circular functions. Typically, such functions are invoked iteratively. In the first iteration, the values of elements are computed left-to-right top-to-bottom with initial values for the elements. In the next iteration, the values of the elements are re-computed left-to-right with values from the previous iteration. This process is continued until the number of specified iterations is exhausted. At the end of any iteration, including the final one, the values of some elements may not satisfy all relationships. Therefore, some related attributes may be inconsistent. Cyclic dependencies in an ADG increase the number of circular references in a spreadsheet. Finally, the traversal strategy in a spreadsheet is left-to-right and top-to-bottom, not the desired breadth-first strategy.

A spreadsheet implementation for a CE is suited only for very simple ADGs wherein cyclic dependencies are limited and left-to-right top-to-bottom traversal is sufficient to approximate breadth-first traversal.

An attribute grammar enables specifying meaning to a string derived from a context-free grammar [Knuth68] [Knuth71]. Properties2 associated with non-terminals, and functions associated with productions define the semantic meaning of strings. Synthesised properties are defined solely in terms of the descendents of the corresponding non-terminal symbol, i.e., in terms of the properties of the symbols on the right-hand side of a production. Inherited properties are defined solely in terms of the ancestors of the corresponding non-terminal symbol, i.e., in terms of the properties of the symbols on the left-hand side of a production. Synthesised and inherited properties are duals; synthesised properties alone are sufficient for attribute grammars. Attribute grammars have been used to design language-specific editing environments [Hor86]. Attribute grammars have been extended to include context-sensitive languages [Reps84].

A CE can be implemented as an attribute grammar that has a non-terminal for each attribute in the ADG. The property associated with each attribute is its value. Relationships among attributes are specified as productions in the grammar. Functions associated with each production compute the inherited properties of the non-terminals on the right-hand side of the production. A string derived according to this grammar corresponds to the effects of an interaction.

A number of factors make attribute grammars somewhat awkward for the design of a CE. First, a grammar in which all attributes are non-terminals will never terminate because there are no terminals. Second, attribute grammars disallow cyclic dependencies since such dependencies lead to infinite invocations of productions in a grammar. Third, the traversal strategy in attribute grammars is depth-first. All of these factors can be resolved by having separate grammars for each attribute. In other words, a separate grammar for each attribute in the ADG must specify how a change to the attribute affects dependent attributes. The non-terminal for each attribute is the start symbol for its own grammar. The terminals in each grammar serve merely to break dependency cycles among attributes. Thus attribute grammars can accommodate cyclic dependencies (by having separate grammars for each attribute) yet propagate effects of an interaction non-cyclically (since each grammar has no cycles).

Although the specification of mapping functions and a traversal strategy is non-intuitive, attribute grammars can be used to implement CEs.

A mediator captures behavioral relationships in complex systems [Sull94]. A mediator is a first-class implementation object that realises behaviours external to an Abstract Behavioral Type (ABT). An ABT characterizes a class of objects in terms of its data, operations on data and events that trigger other behaviours.

A CE can be implemented as a number of ABTs whose relationships are realised by mediators. Each attribute in the ADG is an ABT. The value of the attribute is the datum of the ABT. Reading and writing the datum are operations on the ABT. The only event generated by the ABT is when the value of the datum changes. Mediators capture the behavioral relationships among ABTs, i.e., mediators encode the mapping functions among attributes. When an attribute ABT announces an event signifying that its datum has changed, mediators invoke the appropriate operations to ensure that relationships among all attribute ABTs hold.

The benefit of using mediators to design CEs is that consistency maintenance is decoupled from the design of the representation. Mediators, which are instantiated solely for ensuring that relationships among attributes hold at all times, free designers of representations from the concerns of consistency maintenance. Mediators must be designed carefully to ensure that the desired graph traversal strategy is realised by the appropriate attribute ABT events.

Dependencies among attributes may be viewed as constraints [Allen92] [Hill92a] [Horr92]. A constraint restricts the range of a dependent attribute. In the absence of any constraint, the range of a dependent attribute encompasses all values permitted by the type of the attribute. In the presence of a constraint, the range of a dependent attribute is limited by the relationship between the dependent and independent attributes.

A CE can be implemented as a constraint solver. The attributes in an ADG can be the symbols in a constraint-solving system. Mapping functions can be implemented using unification. Constraints define relationships among attributes as well as legal ranges for values of attributes. Many constraint-solving systems solve constraints among boolean or even numerical variables. Constraint solving in the Herbrand universe, which is the union of all symbols in a system, can be complex [Früh92a] [Früh92b] [Jaffar94] [Van96]. However, constraint systems can be simplified in many ways, such as incorporating optimizations [Marr93], exploiting constraint independence [García93], using incremental constraints [Free90], and building linear systems of equations that can be solved in polynomial time for numerical variables [Jaffar92] [Cormen89].

A general constraint solver may be too powerful for the relationships among attributes. We expect the relationships among attributes in a multi-representation model to be simple relationships. Since the multiple models represent the same object or process, typically, the relationships are those of equality (within tolerable error), whole-to-parts or parts-to-whole. Accordingly, the constraints within an MRE may be solved relatively simply. Therefore, a constraint solver specific to the domain of the attributes of the multiple representations would be suited for the design of a CE.

A Consistency Enforcer (CE) maintains internal consistency within an MRE. A CE consists of an Attribute Dependency Graph (ADG) and mapping functions. A CE may be implemented in a number of ways, such as spreadsheets, mediators and constraint solvers.

An ADG captures dependencies among attributes in concurrent representations. Individual attributes and the dependencies among them are the nodes and arcs in an ADG. We classify dependencies into four categories: cumulative, distributive, interaction and modelling. Semantics associated with dependencies capture semantics of relationships among attributes. Classifying dependencies and assigning semantics to them aids the construction of appropriate mapping functions that translate attributes. Traversing the ADG propagates the effects of an interaction to all dependent attributes. When an interaction changes the value of any attribute, traversing the graph and invoking the mapping functions associated with each arc can make the MRE consistent again.

Mapping functions encode application-specific translations of values and changes to values among attributes. Mapping functions must translate attributes and changes to attributes. Also, mapping functions must be composable and reversible and must complete their translations before the next observation point.

As long as single interactions occur or concurrent interactions are always serialized, ADGs and mapping functions maintain consistency in an MRE. In the next chapter, we show the design of an Interaction Resolver to resolve the effects of concurrent interactions. When concurrent interactions occur, we utilise semantic information about the interactions in order to resolve any dependencies among them. The CE applies the effects of the resolved concurrent interactions.