1.2 METAMODELLING NEEDS

Metamodelling is not an end in itself; it is a means to achieve a different end, namely, in the context of this book, the delivery of methodologies that are as useful as possible within any given set of constraints. The usefulness of a methodology is given by a combination of, at least, two elements: its content and its form. The content aspect refers to what the methodology says; for example, a methodology that prescribes a waterfall lifecycle for a four-person team used to agile development is unlikely to be highly useful. Similarly, an extremely agile and coding-oriented methodology would be of little utility to a large, formal organization that works with highly distributed teams of dozens of people. As we said, methodologies must be fit for purpose; adjusting the contents of the methodology to the characteristics of its users is essential for this. Since the characteristics of the users vary from time to time, from organization to organization and even from project to project, it is impossible to “freeze” methodological content; as we have discussed, one size does not fit all.

1.2.1 Language

There is a second aspect to utility: the form of the methodology. This means how the methodology is expressed, regardless of what it says. A linguistic simile can be used. The content of a methodology is like the meaning of what I utter; since I utter different sentences at different times, depending on myriad conditions, it is impossible to predict what I will say next. The form of a methodology, on the other hand, is like the language I use to utter my words. I can certainly change my language, but it is possible to fix a particular language and utter almost anything using it. Similarly, it is possible to choose what language we want to use to express methodologies, and express any necessary methodology using it. Agreeing on a language and “freezing” it has the advantage that all the stakeholders will know how to interpret what I say. Usually, the agreed-upon language is a language known by all the parties involved; it offers the ability to be able to express with richness of detail any foreseeable meaning. Of course, some languages are better than others at expressing very specific things; for example, some natural languages cannot express the difference between green and blue colours [12, pp. 330–34], whereas others are extremely rich in their colour-related vocabulary. This is why selecting the optimal language to express something is not a trivial task; as in the linguistic simile, the language in which a methodology is expressed can enhance or hinder the ability of people to understand it and, as a consequence, to use it [4].

The most immediate language used to express a methodology is natural language, e.g. English or Spanish. For example, the Catalysis approach [6] has been expressed using English for the most part. Natural language is readily understandable by humans but hardly intelligible by computers (at least not currently). This means that Catalysis can be easily assimilated by a human but only manipulated by a computer after tedious translation work. Natural language is highly ambiguous with some words having a multitude of meanings, even in one context. Natural language is also linear, meaning that it takes the form of a sequence of symbols. This means that complex, non-linear structures must be “serialized” and flattened into a sequential equivalent. For example, consider a bidimensional matrix of figures printed on a sheet of paper. The only way to dictate it to another person is to read it row by row or column by column; in either case, it is being serialized into a sequential form.

A methodology is a much more complex structure than a bidimensional matrix of figures; it is composed of numerous concepts that refer to each other in complicated ways. A methodology can be visualized as a mesh of nodes interconnected by arcs. It is possible to serialize it onto paper and describe it in natural language (as was done in the early object-oriented methodology books, for instance), but any non-local reference must be maintained by hand. For example, imagine that the chosen serialization strategy consists of listing the complete process specification first, followed by all of the product specification. Process elements will necessarily refer to product elements; then the necessary links, in the form of notes or citations, will need to be created. If a product element changes its name later, it will be necessary to search for all the references to it and update them accordingly. Also, completeness must be checked by hand. Are all the product elements referred to in the process section? Are all the product elements created and used by at least one process element? If not, there is a consistency defect in the methodology. With natural language, the only way to check this is by hand. Such maintenance of non-trivial methodologies is daunting.

As an alternative to natural language, a modelling language can be used. This idea may appear odd at first, but we must recall that a methodology is a systematic way of doing things, i.e. the specification of the work to be done. In other words, a methodology describes how a software development team is expected to behave during an endeavour. From this point of view, a methodology is a model of the future endeavours that are conceivably possible, like the blueprints of a building are a model of any future buildings that conform to them.

Methodologies are models (indeed, some authors refer to them as “process models”) and, therefore, a suitable modelling language rather than a natural language can be used to express a methodology, gaining in accuracy, reducing ambiguity and gaining the possibility of expressing their complex, non-linear structures of information, with no need for serialization. The ideal modelling language used to express methodologies must be generic enough so that any conceivable methodology can be expressed but, at the same time, concrete enough so that major methodological concepts can be treated with specific semantics. For example, some authors have used the Unified Modeling Language (UML) [15] as a language to express methodologies. UML is a generic object-oriented language described by a number of class diagrams. By the very nature of object orientation, UML is multi-purpose – although at the same time limited to the set of concepts its authors chose to include. Almost anything that we can think of can be represented as a class. This is useful but, at the same time, means that representing something as a class says very little about that something. A domain-specific language (DSL), on the other hand, would have first-order language elements that correspond to the major concepts of the subjects being modelled. For example, a DSL for software development methodologies would probably include elements such as Task, Team and Product whereas a DSL for a software architecture model might focus instead on classes, patterns, components and quality evaluation.

1.2.2 What to Represent

If a methodology is to be expressed as a model of all the elements necessary to execute an endeavour, we need to study what an endeavour is made of in order to determine what aspects must be included in a methodology. Traditionally, three major aspects have been identified: processes, products and people [7].

The process aspect is concerned with the work that must be done. Usually, this is stated in terms of tasks, steps, activities, techniques, processes, breakdown elements or some other types of work-related elements. In general, these elements can be named, collectively, “work units”. The product aspect, on the other hand, is concerned with the artefacts that must be produced or used during the endeavour. This is often expressed in terms of models, documents, hardware or software items, etc., all of them collectively named “work products”. Finally, the people aspect is related to the organizational structures that actually perform the endeavour, usually in terms of people, roles, teams and tools. All of these elements can be grouped under the name “producers”.

The relationships between these three major aspects (Figure 1.2) can be summarized in a single sentence: work products are the result of work units performed by producers. However, the true relationships that exist between these aspects are more rich and complex than this sentence may suggest. First of all, work products are not just the result of work units but can also be the starting point of work units. For example, a needs statement that acts as raw material from which requirements are specified and, eventually, a system is built, is a product that must be represented by a methodology, but is not created during the endeavour. From an intuitive point of view, we can say that:

Figure 1.2: The three major aspects that any methodology must represent

This means that any artefact that is involved with the endeavour, either because it is created during it or because it is used (and possibly modified), is considered as a work product. Of course, the final system, which comprises the ultimate objective of the methodology, is also a work product.

Secondly, we said that work units are performed by producers. This is true but, from a project management perspective, we must acknowledge that work units may be defined well in advance before a producer actually performs them. For example, a project plan usually includes the tasks and activities that are expected to be performed within the project. Consequently, we can say that

We said that producers perform work units. Since work units can be planned in advance, it is better to define the relationship between producers and work units in terms of responsibilities rather than actual performance. In other words, we can say that

This means that any person or team that has the responsibility to execute work units in an endeavour is considered a producer.

In summary, a methodology must describe work products, work units and producers. But, how should elements of these kinds be represented? The chosen representational form must satisfy two purposes. First of all, it must be able to supply the appropriate information to methodology users about the elements. For example, the specification of a task should include its name, its purpose and possibly a description of the steps to be taken. The specification of a producer, on the other hand, should include a name and a collection of responsibilities. Secondly, and in addition to information about each element, the representational form must be adequate so that methodology users can instantiate the methodology elements for use in their endeavour. In other words, most methodology elements need to serve as templates to create related endeavour elements. For example, the specification of a particular task kind must not only describe the tasks of such a kind but must also serve as a template from which actual tasks of that kind can be created in the endeavour. Similarly, a specification of a particular work product kind not only describes work products of that kind but must also be able to generate specific work products of that kind in the endeavour.

1.2.3 Summary of Metamodelling Needs

In this section we have explained that a methodology needs to be useful to its users. In order to achieve this, the following needs have been identified:

• The methodology contents must be purpose-fit, i.e. optimally adjusted to the users' needs, including organization, project and product aspects.
• The methodology must be expressed using a specialized modelling language, so that it is minimally ambiguous and easily processed by computers.
• The methodology must deal with three major aspects: work products, work units and producers, as well as the relationships between them.
• The methodology must describe the endeavour and also serve as a template so that the endeavour can be generated from it.

How should metamodelling help us address the needs described in the previous section? Let us analyze each need in turn.

With regard to methodology contents, metamodelling must ensure that organization, project and product requirements of the future users of the methodology are taken into account, and that the methodology contents are established according to them. Different requirements usually mean different solutions and, therefore, metamodelling must be able to deliver optimal methodologies for each project, domain or organization upon demand.

Regarding the modelling language, metamodelling must provide a language (generic or, more likely, domain-specific) that offers the necessary expressiveness so that any conceivable methodology can be appropriately specified. As few assumptions as possible should be made about the organization, project and product aspects of the future users when defining this language.

The modelling language must be able to describe at least the three major aspects of the methodology (kinds of work products, work units and producers). Also, the modelling language must be able to express concepts that, on the one hand, carry information (so that the methodology can be described) and, on the other hand, act as templates (so that endeavour elements can be generated from them).

A very important point must be made here. We have said that the modelling language used to represent the methodology should be able to express concepts such as kinds of work products, kinds of work units and kinds of producers. From a cognitive perspective, this means categorizing work products, work units and producers into well-defined groups, which, in turn, involves having a clear notion of the concepts of work product, work unit and producer. If the modelling language lacks the concept of work product, for example, how could it implement the concept of work product kind? Again, from a cognitive perspective, the only way to implement a categorization of a concept is based on that particular concept. The consequence of this is very clear: the modelling language must also be able to describe the endeavour-level, uncategorized counterparts of the methodology-level, categorized concepts that we have mentioned above.