Resolving Conflicts

With merge integration, matched elements appear once in the composed design.^[5] This worked smoothly in Figure 6-16 and its output illustrated in Figure 6-17, where, for example, the crystals attribute was declared private and as type int in every input theme where it was specified. However, there is considerable potential for matching elements to have different values for any of the properties of their respective constructs. For example, what visibility should the crystals attribute have if any one of the input themes had defined it as protected or public?A0What if the duel theme had defined the Player class as a leaf class while each of the others said it was a root? Clearly, you need a means to specify how to resolve such conflicts. Theme/UML supports three different mechanisms to allow you to state what should happen when a conflict arises: defining theme precedence, specifying default values, and explicitly specifying values for a specific conflict.

^[5] We exclude the single exception, operations, from the discussion here, as managing conflict does not arise in the same way.

Theme Precedence

You may indicate an order of precedence for the participating themes by adding an n.prec tag to the composition relationship ends, where n indicates precedence in ascending order. For example, in Figure 6-22, the duel theme has the highest precedence, and the distribute-crystals theme has the lowest precedence. Where a conflict arises, the specification from the highest order precedence theme is chosen. Of course, this precedence order could be further refined with precedence specifications on composition relationships between lower level components of the themes.

Figure 6-22. Resolving conflict with theme precedence.

Default Values

With another tag on a composition relationship, you can also give default values for any UML construct's properties. For example, you can say that for attributes, the default value for visibility is private; for multiplicity it is *; and so on. The following tag gives defaults for select properties from attributes and can be attached to a composition relationship. The properties are named as they are in the construct's UML metamodel description. All of the properties of all kinds of constructs can be added to this tag, defining a default value for each.

 resolve ( Construct ( property=value; property=value; ..)            Construct ( property=value; property=value; ..)           ....) 

If there are any properties not listed in the tag that result in conflict, a further attempt to reconcile the conflict is made from any precedence tags.

Explicit Values

If you are aware of a specific conflict between two elements that match, and you have a preference for how the element should look in the composed design, you may attach a further tag to the composition relationship so indicating. For example, the following tag resolves an assumed conflict between the crystals attribute in the Player classes and indicates what values crystals should have in the composed design. Again, properties are named as they are in the construct's UML metamodel description.

 resolve ( Player.crystals (visibility=private;                            multiplicity=*; ..)            Element_name ( property=value;                          property=value; ..)            ....) 

If there are no explicit listings for a conflict, further attempts to reconcile a conflict are in the order of a search for a default-value specification for that construct, followed by precedence tags.