5.3 COMPARISON OF POWERTYPE MODELLING AND POTENCY

It is interesting to briefly undertake a side-by-side comparison of the two approaches described in the previous sections: both arguably successful solutions to the challenge of deep characterization. In Figure 5.13, the powertype pattern on the left-hand side uses one more class than the potency approach shown on the right-hand side. It provides a class with an attribute b:B that is allocated a value of b = b1 in the lower layer, exactly like the potency approach (the potency of attribute b is shown as equal to 1). For attribute a:A, which does not require a value until the lowest (Endeavour) domain, the powertype approach has to introduce an additional class with an explicit generalization relationship followed by an instantiation down to the Endeavour domain. This gives a value a = a1. The exact same result is provided in the potency approach by a second attribute a:A but with an enhanced potency value of 2. This is decremented in the class in the Method domain and then again to reach a value of potency = 0 in the lowest of these three layers, thus indicating that a value attribution must be made (here a = a1).

Figure 5.11: Adding a stereotype (virtual submetatype) to the UML metamodel (after [10])

Source: Henderson-Sellers and gonzalez-Perez, 2005, copyright JOT. Reproduced with permission of ETH, Zürich

The potency approach has the advantage of having one less class to consider and the potency idea is not limited to the three layers that we have used in this example, as is the powertype approach. However, the use of an additional class in the powertype approach allows an explicit differentiation between two very different classes (xxx and xxxKind, as illustrated in Figure 5.10), that are by necessity convoluted in the potency approach. It is important to stress that these two classes, i.e. those representing entities of a type and categories of such entities, are cognitively different concepts, and therefore two different classes should be used to represent them. Secondly, in the potency approach there is an implicit introduction of a generalization relationship (as noted above) hidden within the instance-of relationship overlaid by a potency decrement; in the powertype approach, the necessary generalization relationship (which after all is responsible for the ability of either of these approaches to transmit attributes unchanged) is explicit.

Figure 5.12: Taking the stereotype of Figure 5.11 and turning it into a powertype (after [10])

Source: Henderson-Sellers and gonzalez-Perez, 2005, copyright JOT. Reproduced with permission of ETH, Zürich

However, if we were to try to add potencies to a modelling language using the OMG architecture of Figure 2.19, some extensions would be necessary [2]. Similarly, the addition of powertypes to this architecture is also arguably unrealistic if strictly applied (although potentially compatible with the modifications proposed by [4]) and hence requires the newer architecture of Figures 2.20 and 5.7. Use of this latter architecture means that it becomes possible to keep the whole of the powertype pattern [10] (e.g. Task and TaskKind) totally within the Metamodel domain, with the clabject generated from the pattern in the Method domain.

Figure 5.13: Comparison of two approaches (powertype modelling and potency) for the transmittance of data from the metamodel layer through the methodology layer to the project layer (adapted from [7])

Source: gonzalez-Perez and Henderson-Sellers, 2006, copyright Springer Science and Business Media. Reproduced with permission