1.3 WHAT IS METAMODELLING?

The term “metamodel” is, evidently, a qualified variant of “model”. This suggests that metamodelling is a specific kind of modelling. In fact, metamodelling is the act and science of creating metamodels, which are a qualified variant of models. The difference between a regular model (one that is not a metamodel) and a metamodel is that the information represented by a metamodel is itself a model. The prefix “meta-”, in Greek, means “higher” or “posterior”. In epistemology and other branches of philosophy, the prefix “meta-” is often used to mean “about its own category”; in our case, “meta-” means that the model that we are building represents other models i.e. a metamodel is a model of models [8; 14]. This relationship is often described as paralleling the Type–Instance relationship. In other words, the metamodel (Type) and each of the models (Instances) are of “different stuff” and are described using different languages (natural or software engineering languages). Such type models therefore use classification abstraction – which leads to a metamodelling hierarchy.

One might indeed argue that modelling skills and techniques should be independent of the subject being modelled; a good modeller should be able to model an aeroplane, a business or a social group using the same skills and techniques (given the appropriate domain knowledge). If this is true, then the fact that a metamodel represents another model rather than “real-world” information should not be a reason to use a new term (“metamodelling”) rather than the usual one (simply “modelling”). Following this line of reasoning, metamodelling should not be more special than aeroplane modelling or business modelling. However, there is one aspect that makes metamodelling a very special kind of modelling: the subject of metamodelling is models; in other words, the input and output artefacts of a metamodelling job are “made of the same stuff”, i.e. they are of the same type. This gives metamodelling a recursive nature that makes it much more complex than other modelling areas in which the subject being modelled is of a different nature, making it especially tricky. As a simple but pervasive example, consider the Class class in UML. Parsing this phrase (“the Class class in UML”) is already complex, since it involves a certain degree of recursiveness. The fact that UML contains a class named “Class” can bring up questions such as: is the Class class the same as the Class class in MOF [13]? What do we mean by “the same” here? Answering these questions is far from trivial.

The description of metamodelling and metamodels that we have provided so far is not especially related to methodologies; in fact, any model that provides the language to represent models is a metamodel. For example, any modelling language is a metamodel, according to this definition, since a modelling language, by definition, represents any possible model that can be expressed with it. The link to methodologies comes from the fact, explained earlier in this chapter, that methodologies are models of endeavours. If a methodology is a model, creating that methodology is modelling, whereas creating the language concepts used to describe the methodology is metamodelling. Consequently, the language that we use to express a methodology is a metamodel. Although the concepts of metamodel and metamodelling are not necessarily tied to methodologies (as specific kinds of model), this book is about software development methodologies; therefore we will focus on this particular application of metamodelling. According to this, we can say that:

We can also say:

The rest of this book describes the characteristics that a good metamodel must present and gives advice on constructing and using one. Since a metamodel is a specific kind of model, the first step is to introduce the necessary modelling and metamodelling concepts that, used as building blocks, will allow us to reason about models (and metamodels) with minimal ambiguity. This is the focus of Chapter 2.