6.9 EXTENDING THE ISO/IEC 24744 METAMODEL

The basic usage of the metamodel has been described above. Figure 6.18 shows a simple powertype pattern for Task/*Kind, resulting in a methodology clabject called ValidateRequirementsTask.

Figure 6.18: A powertype pattern in the task domain (after [14])

Source: ISO

Suppose that this particular methodology requires that all validate requirements tasks need to be explicitly controlled as to whether they need signing off by the users or not. In other words, some enacted validate requirements tasks will require signing off while others will not, and this must be recorded according to the methodology. Since ValidateRequirementsTask is a specialized form of Task, then an additional attribute to store this information can be added in a straightforward manner (Figure 6.19). This new attribute represents the fact that some, but not all, requirement validation tasks, when actually performed in the Endeavour domain, will need signing off before the requirements can be considered validated. The methodologist captures this by incorporating this new NeedsSignOff attribute into the class facet of the method fragment. In programming language terms, this is known as “programming by difference” – a key strategy in the object-oriented paradigm. When this method fragment is instantiated for an endeavour, it and all the other (standard) attributes are allocated values (object vrt1 in Figure 6.19).

Figure 6.19: Adding a new attribute to a class in the Method domain (after [14])

Source: Henderson-Sellers and Gonzalez-Perez, 2006, copyright LNI. Reproduced with permission

A more important kind of extensibility is when the metamodel itself needs extending by the addition of a new class. Since the structure is built upon pow-ertypes and since powertypes (in the Metamodel domain) are linked to entities in the Method domain by both generalization and instantiation semantics, we can use the former (generalization semantics) to create an intermediate layer between the standardized metamodel (here ISO/IEC 24744) and the Method domain.

For example, suppose that the method currently being engineered needs to contain tasks which can be measured for performance. The method engineer recognizes the need for a MeasuredTask concept that they find they need to add to the SEMDM. To do this, the method engineer refines the standard Task/*Kind powertype pattern provided by the metamodel and creates a MeasuredTask/*Kind subtype of it (Figure 6.20). This new metamodel class incorporates the necessary infrastructure to manage performance measurement of tasks. The powertype pattern is ready to be subtyped. Two new classes (called extension classes) are introduced, each being a subtype of the classes involved in the original powertype pattern (called standard classes). In Figure 6.20, Mea-suredTask is subtyped from Task and MeasuredTaskKind is subtyped from TaskKind. These two new classes are related in a powertype pattern in just the same way that their superclasses (here Task and TaskKind) are related i.e. the powertype pattern relationship between the extension classes parallels the standard one in the metamodel.

The new MeasuredTask class has a Performance attribute, which captures the fact that, in the Endeavour domain, all measured tasks will have a performance value attached to them. Similarly, MeasuredTaskKind carries a Measurement-Guidelines attribute. For each particular kind of measured task, this contains information explaining how performance is to be measured. Notice too how the attributes introduced at the metamodel extension level take values and are used in the Method and Endeavour domains.

Once the extension powertype pattern has been introduced, any method engineer can use it in the conventional way, deriving method fragments from it as explained in previous sections. In other words, the combination of the two upper layers in Figure 6.20 act as a single “Metamodel” domain for this enhanced metamodelling approach.

The mechanism described here is in stark contrast to the invention of the notion of profiles and stereotypes in the UML. There, the metamodel cannot be extended without changing the M2-level metamodel, which itself has been standardized and is essentially immutable [13]. Using powertype patterns, as in SEMDM, an equivalent extensibility is accomplished without damaging the original metamodel whilst, at the same time, permitting user-defined extensions (akin to a profile in UML space) and staying within the standard. This further means that a methodology generated from a metamodel plus extension is as well supported by the tools as one created from the standard metamodel alone. Furthermore, conventional, well-known, object-oriented building blocks, such as attributes and specialization, are used to extend the metamodel, rather than artificial constructs such as stereotypes and tagged values, as, for instance, in the UML.

Figure 6.20: Metamodel extension followed by usage (after [14])

Source: Henderson-Sellers and Gonzalez-Perez, 2006, copyright LNI. Reproduced with permission