3.3 METAMODELLING FOR DEVELOPMENT METHODOLOGIES

As we said in Section 3.1, the goal of any software development methodology should be obtaining a valuable, working product, and the process that we need to follow in order to obtain it is simply a necessary evil. If the final product could be obtained magically with very little effort, the process that we often follow would not be followed at all.

Rather than evaluating product and process (and producer) aspects separately, as we have done in Sections 3.1 and 3.2, the joint specification of modelling languages and development processes is, arguably, a better way to define methodologies (Figure 3.7). It allows a better degree of completeness than can be achieved by the separate specification of these two aspects (i.e. process and product), as is done, for instance, in the OMG suite of products. This separates SPEM and UML but then needs to bridge the gap (Figure 3.8).

The ISO/IEC 24744 standard metamodel [20] supports this by using the concept of action. An action represents a usage event of a task upon a work product; in other words, it describes how a specific task acts upon a specific work product, by creating it, reading (but not altering) it, modifying it or destroying it. This approach, clearly based on the classic create, read, update and delete (CRUD) approach to database interfacing, allows for a rich interaction between the process and product side of methodologies, departing from the more traditional way in which they are represented (by SPEM, for instance), which is based in the metaphor of inputs and outputs (Figure 3.9). In this metaphor, each task (or unit of work) is seen as a machine that takes products as inputs and returns products as outputs. This is a poor metaphor for the following reasons. First of all, it does not indicate whether products “going into” the task (inputs) are going to be altered by the process or used but not changed, and does not indicate whether products “coming out” of the task (outputs) are instances that have been created anew or are modified versions of pre-existing products. Secondly, the input–output approach does not provide enough information to ascertain whether a particular output is the same product as a particular input. For example, imagine a refactoring task that takes a source code class as input and outputs a refactored source code class. Is the resulting class the same work product as the initial one or is it a different work product? This modelling approach is unable to capture this information (Figure 3.10).

Figure 3.7: In ISO/IEC 24744, the “process-focussed” metatypes are closely integrated with modelling metatypes

Figure 3.8: SPEM and UML are less well integrated

Figure 3.9: Traditional view of a method as an input-output transformation engine

Figure 3.10: A refactoring task with input and output code products – is the output code the same product as the input code?

Using actions, however, shifts the focus from the task (process) to the products, and each individual usage event is modelled in detail. The methodologist must actively decide to make the refactoring operate in situ, modifying the original code, or to preserve the initial product intact and create a new one with the modifications (compare the two alternatives shown in Figure 3.11, in which actions are depicted as small circles labelled with an uppercase letter).

Since “methodology” is the prime focus of this book, we defer further analysis of this area of application of metamodels to Chapter 5 and later.

Figure 3.11: Using actions to model the interface between process and products; one refactoring task modifies a code product (top) and the other one reads an existing code product and creates a new one (bottom)