Metamodelling for Software Engineering

CHAPTER 5

New Approaches to Metamodelling

We have explained that most metamodelling approaches assume that methodologies are expressed as a collection of interrelated entities that are later enacted in the form of endeavours. These entities are, in turn, obtained from a metamodel, traditionally using object-oriented instantiation. The object-oriented mechanism of instantiation, however, presents multiple deficiencies; as we saw in Chapter 4, for methodology metamodelling, there is a serious problem in the integration of the “product” aspects with the “process” aspects when using traditional, instantiation-based metamodelling, as promulgated by the Object Management Group (OMG), for instance in their four-layer hierarchy (Figure 2.19). This is especially evident when we wish to standardize attributes in the Metamodel domain (M2 in OMG terminology) but not to allocate them values until the Endeavour domain (two layers distant – M0 in OMG terminology). This results from the semantics of the “instance-of” relationship that states that the attributes and associations attached to each element in the metamodel (for instance, UML or SPEM) define how their instances at the next lower level will behave. Attributes of these instances must be allocated (slot) values, which are specified in the metamodel, i.e., an M2 specification (a statement of the name and type) is realized as an M1 level value. However, only the direct (or “shallow”) instances of them can be governed in this way [2]; from ...