Matching Design Elements

The game design has multiple base themes that share many of the same game concepts. For example, player, location, and game appear in many of the base themes, each with specifications from the perspective of the requirements for which the theme is responsible. We now need to identify those shared concepts so that they will be composed together.

The composition relationship specification in Figure 6-13 does not indicate that any of the themes share concepts, and so it specifies that all elements in each of the three input themes will appear separately in the composed Game theme. Because we have not said otherwise, the composition therefore considers any elements with the same name as a clash, which it resolves through renaming. For example, recall from Chapter 5 that each of these three themes has a class called Player. As specified in Figure 6-13, the composition does not recognize these as the same concept and so considers these class names as clashing. Therefore, in the composed game theme, the three classes in the input themes will correspond to three classes that are renamed to start.Player, enter-location.Player, and distribute-crystals.Player. This clearly is not satisfactory. Fundamentally, the class Player represents the same core concept in each of the themes and should be a single class in the output. Stating this can be achieved in one of two ways: explicitly with an additional composition relationship or implicitly by adding another tag to the main composition relationship.

Explicit Matching

One way you can identify elements that provide designs for the same domain concepts is by explicitly drawing a composition relationship between them. Composition relationships can be defined between design elements of the same type to state that those elements match and therefore should be composed. Figure 6-14 illustrates using multiple composition relationships to specify matching of concepts.

Figure 6-14. Explicit matching of design elements.

In Figure 6-14, a subset of the duel and enter-location themes is shown, both of which have a class called Player. There are three composition relation ships here. The one marked 1^[3] is the obligatory composition relationship that specifies the themes to be composed. The composition relationship marked 2 is between the matching classes in Figure 6-14 and indicates that they should be composed. Each element of the matched classes will be added to the composed result, with name clashes resolved through renaming. If this is not what you wantfor example, if there are elements at a smaller level of granularity (like attributes) that represent the same conceptthen you draw more composition relationships. For example, the Player classes in Figure 6-14 both have an attribute crystal, which should be matched in the composition. The composition relationship marked 3 captures this matching.

^[3] The numbering in Figures 6-14, 6-15, and 6-16 is for illustration, and is not part of the Theme/UML notation.

Another example in Figure 6-15 illustrates a subset of the start, distribute-crystals, and setup-NPC themes, all of which have classes called Location, Game, and Vector. There are six composition relationships here! As you can see, the more explicit matching to be done, the more difficult it is to read what is happeninga problem we address in the next section.

Figure 6-15. Elements with more than one relationship.

First, though, notice that the relationship (marked 2) between the Game classes is a three-way one, while there are two relationships each between the Vector classes (relationships 3 and 4) and the Location classes (relationships 5 and 6). The effect of composition in both these styles is the same. In all cases, because we have drawn these composition relationships, the three classes match (one from each theme) with the three matching classes composed in the result.

This leads us to an important rule. A design element may compose to only one result, so using multiple composition relationships in the manner of Vector and Location is transitive. In other words, if start.Location matches distribute-crystals.Location, and distribute-crystals. Location matches setup-NPC.Location, then start.Location also matches SetupNPCs.Location. All three classes therefore match and will be composed.

Implicit Matching

Explicitly matching elements with a composition relationship for every match is particularly useful when elements do not have the same name. However, as you can imagine (and is illustrated in Figure 6-15), it is likely to get laborious (and messy!) quite quickly. You can also define a rule for the composition relationship that specifies that identically named elements should match. You can do this by adding a match[name] tag to a composition relationship.

By adding a match[name] tag, you can state that any elements within matching elements that have the same name should also be considered to match. In effect, you are saying that classes within themes that have the same name should be matched; attributes within matching classes that have the same name should be matched; and so on.

Figure 6-16 illustrates this tag for the composition relationship previously shown in Figure 6-13.

Figure 6-16. Implicit matching of design elements.

The composition relationship marked 1 is the obligatory composition relationship that specifies the themes to be composed. We have attached the match[name] tag here, indicating that identically named elements (and which are of the same type) match. In Figure 6-15, a match[name] tag on the composition relationship between the themes would remove the need for all the other composition relationships and also cover all other elements that match by name that are not illustrated.

You can still use an explicit composition relationship between elements you want to match that are not captured by the match[name] tag. For example, from Figure 6-16, if the designer of the setup-NPC theme had decided to name the class to handle locations Place,^[4] then you could explicitly draw a relationship between them that indicates that these should match, as illustrated in the composition relationship marked 2.

^[4] The design in Chapter 5 does not have location information in a class called Placewe just use it here as an example.

Of course, it is also possible that, by coincidence, there are elements that have the same name that should not be matched. In a manner similar to explicitly matching elements, you can also explicitly unmatch elements. This is achieved with a composition relationship with a dontMatch tag between the elements that you don't want matched. Automatic renaming of the elements will occur in the composed design.

Rules for Concept Matching with Composition Relationships

One of the most important characteristics of a design element to think about when considering the syntactic validity of a composition relationship is whether it is a container for other elements and/or a component of another element. For example, attributes and operations are contained in a class; classes are contained in a theme; and so on. The container/component relationships between design elements are important to the composition process in determining what elements match and also in determining what the namespace of composed elements should be. On now to the rules, the first two of which we have already stated:

• A composition relationship may only be drawn between elements of the same type.

• In order to match design elements, it is first necessary to draw a composition relationship between two or more of the themes in which they are contained.

• Two (or more) design elements may be matched (either implicitly or explicitly) only if their containers are matched. Every composed element must have a namespace, and this rule ensures that there is no confusion over to which container a composed element belongs.

• Each design element may be matched in only one set of matching elements. This means that every design element may be composed into only one result in the composed design. This rule is defined so that there is no confusion with references in the composed result. For example, recall that the setup-NPC.Location class in Figure 6-15 was involved in two composition relationships with other Location classes. Let's say that there is an attribute of type Location somewhere in the setup-NPC theme design. In the composed theme, this attribute's type will be the Location type that is composed of all three Location classes.

• Aspect themes are allowed an exception to the "match-once" rule. Behavior defined in a crosscutting theme may be composed with many different elements specified to replace templates used in the crosscutting behavior. See Chapter 5, "Theme Design," for different rules for aspect themes that avoid reference confusion.