Integration Options

Theme/UML supports two different kinds of integrationmerge and override. Merging themes is probably what you will use the most often, as it ensures that all structure and behavior defined in individual themes is incorporated into the composed design. You may find override integration useful, though, in later versions of the design. With override, you can have a new theme that has a more up-to-date design for an application and specify that it should replace a previous version.

In this section, we restrict our discussion to the integration of only concept-sharing (or base) themes. Many of the principles are relevant for composing crosscutting themes with base themes, but as there are additional policies for crosscutting themes, we deal with them together later.

Merge Integration

As we've said, there is no upper limit to the number of themes that can be merged. The underlying principle is that each theme involved contains a design that is relevant in the composed design and should be added. In a sense, a merged theme is the union of all the input themes. At the simplest level, this means that every design element from every participating theme will be added separately to the composed result.

However, we spent some time talking about how concepts may be shared across base themes, and therefore match, and we saw how we can specify matching between elements. When matching elements are container types, all the component elements for each of the matched containers are merged into the composed container. For example, Figure 6-17 shows a subset of the composed result of the composition relationship in Figure 6-16. All the attributes and operations in the Player and Game classes appear in the corresponding composed classes.

Figure 6-17. Merged container classes.

Figure 6-17 also illustrates an example of matching elements that are components (and that do not contain other elements). In general, matched component elements appear only once in the composed design. For example, the crystal attribute in the Player classes need appear in the composed Player class only once.

Merging Operations

Merging design elements works this way for structural elements such as containers and attributes. However, operations work a little differently. Bearing in mind that different behavior is generally modularized into separate themes, we think it's useful to be able to specify that some set of operations match in that they should be executed together. A classic example here is when you have matching classes with different attributes and each has a print() method that prints attribute values. When such classes are composed, you would like all the information printed, and therefore, when print() is executed on the composed class, all print() operations from the matching classes should be executed.

This is the basis for the semantics of merging matching operations in Theme/UML. When operations with the same name match, the input operations are renamed (prepended with their theme name) to avoid confusion, and the original name is used to generate a sequence diagram that executes each of the operations in sequence. This is the default behavior for matched operations.

However, this default behavior may not always be what is required. Indeed, in our Game example, we need to change this default for the duel()operations. Notice operations duel(), enter-location.duel(), and duel.duel()in the composed design in Figure 6-17. Matching could have been avoided with an explicit composition relationship between the two duel() operations with a dontMatch tag, but in fact, we don't need enter-location.duel() at all. This duel() method was just a placeholder; it contained no real functionality. It was simply how the designer of enter-location indicated when a duel should happen. Here's an example of where override integration is useful, and we discuss it in more detail in the "Combining Integration Policies" section later.

The semantics for merging operations does come in handy for us in the Crystal Game for some operations that don't have the same name. Consider, for example, the start, setup-NPC, and distribute-crystals themes. From the requirements, you can see that there is a lot of work to be done when a game is started, much of which we have modularized into separate themes. Here is where you can say, "Group these operations together, and execute them sequentially," or, in Theme/UML shorthand, "Merge these operations."

Figure 6-18 illustrates a specification of matching operations. When operations are merged (whether or not they have the same name), the order of execution of the sequence of matching operations is generated randomly. If the order of operation is important to you, you can specify a sequence diagram defining the order that can be attached to the composition relationship, as illustrated in Figure 6-18.

Figure 6-18. Merging operations.

Another example from the game relates to the order in which dueling between players or a challenge from an NPC to a player happens. Though we did not provide a design for the challenge theme identified in Chapter 5, you may recall from Figure 4-13 in Chapter 4 that at the end of our analysis stage, R71 was not associated with any particular theme. R71 related equally to two themes, duel and challenge, and described which operation came first: dueling or the challenge. Assuming a challenge Theme/UML design, you could merge duel() and challenge() operations, and attach a sequence diagram (similar to the one in Figure 6-18) that specifies that the duel should precede the challenge.

You're probably wondering by now what happens when there are conflicting parameters in merged operations, or what happens if one or more of the operations returns a value. In the first instance, the general rule for matching operations is that they must have the same signature (not just match by name). On execution, values input to the composed operation may be used in the calls to each of the matching, renamed operations. We've made one exception to this rule. Where one of the matching operations has parameters whose values may be used in other matching operations with a subset of the parameters in the called operations, these operations may be defined as matching. In this case, you must attach a sequence diagram to the composition relationship indicating how the operations are called. If you don't do this, the operations won't be matched.

As for operations with return values, the default behavior is that the value from the last operation executed is returned. If you want different behavior, you must specify that in a sequence diagram on the composition relationship.

Elements That Don't Have a Match

In general, design elements that don't match other design elements are simply added to the composed design in the appropriate namespace. For example, classes that do not match any other classes appear, with all their components unchanged, in the composed theme; attributes that do not match any other attributes in their matching classes are simply added to the composed class; and so on.

Override Integration

Override integration means that the elements in one theme (the overridden theme) are replaced by the elements in another theme (the overriding theme). This is very straightforward for elements that are not containers. For such elements, think of it as a simple deletion of the overridden element and an insertion of the overriding element.

For container elements, it's a little more complicated. Matching becomes important here, and overriding happens to matched elements only. Any elements contained in an overridden container that don't have a matching element in the overriding container are added to the composed design. Of course, such elements are inserted into the overriding container (as the overridden container is deleted). Other than that, you can think of all overridden elements as deleted with the overriding elements inserted.

The notation is a single arrowhead at the end of the composition relationship that denotes the element to be overridden.

See Figure 6-19 for a contrived example from the game. Let's say we have a Version 2 design of the duel theme. As it turned out in Version 1, players spent so long haggling over their wagers that game progress was too slow. Therefore, we want to change wagering to be a simple wager of crystals. This means that everything to do with wagering magic items is no longer needed, and the behavior for duel() and wagerAccepted() that contained some reference to magic items is changed. In keeping with the principles of Theme/UML, the duel-V2 theme contains the fully redesigned wagering process (including the attributes it needs).

Figure 6-19. Override integration.

The composition relationship in Figure 6-19 specifies that every matching element in the duel theme should be overridden by its matching element in the duel-V2 theme. Any behavioral specifications for the signals will override matching behavioral specifications so that there is no behavior that deals with magic items for wagering. However, if you look at the duel theme design in Chapter 5, there are a lot of design elements (classes, relationships, operations, and signals) that will remain when the matched elements are overridden. Recall that elements that don't have an overriding match are added to the composed design. This is not what we want in this case, as wagering is no longer a required part of the design. Theme/UML allows you to explicitly say that unwanted elements should be deleted. These elements can be listed in a new section at the bottom of the package box, as illustrated in Figure 6-19.

Figure 6-20 illustrates the composed result of the specification in Figure 6-19. As you can see, any design element not matched appears in the output, and all elements listed for deletion are no longer included.

Figure 6-20. Overridden duel theme.

Override Rules

Rules for specifying composition relationships with override integration are a little more restrictive than for merge integration. The first of which we have already stated, the rules are as follows:

• A composition relationship with override integration must be one-to-one. In other words, one design element overrides another design element.

• A design element may be overridden only once in a single composition specification.

• Overriding and overridden design elements may not participate in any other merge or override composition. This rule is defined so that there is no confusion with references in the composed result.

Combining Integration Policies

Different integration policies can be used within the same composition specification. Recall our rule that for any composition: you first have to define a composition relationship between the themes to be composed. Then, you may further refine matching and integration with additional composition relationships between the components of the theme container. A composition relationship specified between container elements applies to all components within that container unless a further composition relationship is defined at a lower level. Therefore, the integration specification of the composition relationships does not have to be the same, since application of either merge or override is unambiguous.

For example, in Figure 6-21, the composition relationship between themes enter-location, duel, and start defines merge integration, with a match[name] matching policy. Any elements that have the same name (within same-name matching containers) will be merged. However, recall our difficulty with the default semantics for merging operationswe do not want both the duel() operations from the enter-location and duel themes. From the design in Chapter 5, enter-location.Player.duel() was defined to allow the designer to state where the dueling should happen when a player enters a location. We described this as analogous to referencing an abstract method whose detailed specification is provided using a composition relationship, instead of the usual generalization relationship. We therefore would like that specification to be overridden by the real duel behavior as specified in duel.Player.duel(). This is defined by the composition relationship between them. If the start theme had a duel() operation in its Player class in this example (hard to imagine, we know, as that would probably be a very poor theme design!), then it would not match with the other duel() operations in enter-location.Player or duel.Player because their composition relationship takes precedence over the higher level merge composition relationship that matches Player classes. As always, renaming would occur to avoid a name clash.

Figure 6-21. Combining integration policies.

Where the theme-level composition relationship is specified with override integration, only two themes participate in the composition. Any further composition relationships with merge integration must be defined between elements from only those two themes. This is an implication of our rule that states that you must first select the themes to participate in the composition. To remind you, this gives a context for the composition process to indicate the namespace for composed elements. Where you have more than two themes that you want to be composed with a combination of integration strategies, you should define the theme-level composition relationship with merge integration, and then define the override integration requirements at a finer level of granularity.