Metamodelling for Software Engineering

2.5 INFRASTRUCTURE

We began this chapter saying that metamodels, methodologies and endeavours are all expressed as models, and that a language to represent them needs to be found. Chapter 1, at the same time, established that methodologies must serve as “templates” from which endeavours can be obtained, and metamodels, in turn, must be able to generate methodologies and also represent, to a certain extent, endeavours (Section 1.2.3). Conversely, metamodels themselves need to be defined. The traditional approach here is to introduce a metametamodelling layer that supports the various metamodels. In other words, a high-level model for which the SUS is metamodels. Such a metametamodel would contain a minimal set of concepts from which could be generated metamodels. Of course, this could rapidly become an infinite regression, so the OMG, for example, state that the metametamodel (M3 in their terminology) is its own metamodel, thus introducing ambiguity [18]. As an alternative, and one that supports the non-linear (linguistic versus ontological) hierarchies proposed in [5] and discussed in detail in Chapter 4, Figure 2.21 suggests that there should be a modelling infrastructure, seen as orthogonal to the metalevel hierarchy, that supports modelling at any “abstraction level”. This is called the Xome⁷ Modelling Infrastructure, or XMIS (see Figure 2.22, which also shows the chain of representation relationships between the various software engineering domains). Since the three domains ...