3.2 METAMODELLING FOR PROCESSES

Some of the terminological problems relevant to software development methodologies were identified in Chapter 1; in particular, the terms method and methodology were discussed. We have also noted that, in the method engineering community, it is common to consider a methodology as having two aspects: product and process. Forgetting for the moment that this ignores the roles that people play in the development process, we can say that this terminology, aimed at the level of methodological description and definition, tries to discriminate what is being manipulated (work products) from the ways and times that these manipulations occur (process). Since the creation and maintenance of work products in a vacuum is impossible, and thus a process component of a methodology is identified as being vital, it is common for methodologies to be referred to, confusingly and incorrectly, as simply “processes”. Such confusion is confounded by the observation that in other software engineering areas, the word “process” is used distinctly differently. For example, in the US industry, a process typically refers to the enactment (of a methodology), also known as a process model, which is in many ways similar to the software process improvement (SPI) area of software engineering since capability assessment is always evaluated by observing a process in action (i.e. when it is being enacted). For our present discussion, we tend to consider a method in terms of process, product and producer components (Figure 3.3). In this section, we discuss the process and the producer to complement the discussion on product in Section 3.1.

Figure 3.3: Three interconnected meta-elements (Producer, Work Product and WorkUnit) (after [4])

Source: Finesmith and Henderson-Sellers, 2002, reproduced from The OPEN Process Framework, The OPEN series, by permission of Pearson Education Ltd

From a methodological perspective, a process to follow can be specified by describing the tasks, activities, techniques, actions, etc. that should be performed, when and how they are expected to be performed, on which work products, and by which people or roles. Different approaches and standards use different terminology, but all of them boil down to the same basic notion of work units being performed by producers on work products (Figure 3.3).

From a metamodelling perspective, while a modelling language for work products can easily be prescribed and used within the confines of a two-level hierarchy, the language that we need for process requires three levels since we need to include the enactment of that process on real projects (Figure 3.4).

Figure 3.4: Three “layers” are needed to describe the process focus (after [16])

Source: Henderson-Sellers, 2006, copyright LNI. Reproduced by permission

That enactment is often called the “process” with the middle layer entity known as the “process model”. There are also two kinds of “process”. Software developers read the process model description and apply it to their particular project. They may apply it, for instance, in terms of construction of a software development plan – they choose (and document) which tasks, techniques, etc. are going to be used. Then they create the software following this plan in real time – the dynamic aspect of Figure 3.4. Even if no planning is done, there remains a dichotomy between the static and dynamic aspects in terms of the temporal line.

Some examples of a process-focussed approach are OMG's SPEM [30] and the OPEN Process Framework (OPF) [4]. Both have at their core the tripartite description of Figure 3.3. SPEM focuses on describing the process aspect of methodologies only, not considering modelling language aspects at all; as we explained in Section 3.1, this is hardly sustainable, since function without structure results in highly ambiguous outcomes. OPF originally had its own metamodel, highly influential on SPEM, but has more recently expanded its process focus to a more methodological focus (see Section 3.3) by its adoption of the ISO/IEC 24744 [20] standard metamodel, which specifies process in close connection to products, and which is described in full detail in Chapter 6. As a flavour of what such metamodels contain, Figures 3.5 and 3.6 show snippets of the OPF and SPEM process-focussed metamodels, laid out in a similar fashion to facilitate comparisons.

Figure 3.5: The architecture of the OPF including the major metaclasses (adapted from [17])

Source: Henderson-Sellers and Gonzalez-Perez, 2005, copyright Elsevier. Reproduced with permission

Figure 3.5 shows WorkUnit with its two main subtypes of Activity and Task, Activities being at a coarser granularity than Tasks. All WorkUnits have associated preconditions and postconditions, following the contract-driven ideas of [23] applied to methodologies [11]. Techniques delineate how a Task should be performed; Roles state by whom (or what). Roles are responsible for producing WorkProducts, which are, in turn, closely associated with WorkUnits.

Figure 3.6: The architecture of the SPEM including the major metaclasses (but hiding the cardinalities) (after [17])

Source: Henderson-Sellers and Gonzalez-Perez, 2005, copyright Elsevier. Reproduced by permission

Conventions include advice and guidance, and are modelled as kinds of WorkProduct (in contrast to the more independent Guidance in SPEM as seen in Figure 3.6). OPF also includes an explicit Language class. Since UML is ambiguous about its various whole–part relationships [1], we have used OML-style annotations [5] for non-configurable whole–part relationships [15; 25], such as the epsilon in a circle.

Figure 3.6 shows the major classes in the SPEM metamodel. Only work units and producers are shown here. Work Definition is the most abstract of these work unit classes with a major subtype named Activity, which itself consists of a number of Steps. The performer of this work unit is the Process Role, which is a kind of Process Performer. There is also a whole–part relationship from Process Performer to Work Definition but this is hard to defend or explain satisfactorily since it would not appear to be reasonable to conceptualize a part of a Process Performer (typically a person) as being a Work Definition (e.g. an Activity or a Phase). Finally, work definitions have preconditions and postconditions (called goals) as constraints. All the classes in Figure 3.6 inherit from ModelElement, which means that a Guidance can be attached to any of the process components shown in the figure.

There are also classes used to categorize: the WorkProductKind metaclass categorizes Work Products and the GuidanceKind class categorizes Guidance elements. An instance of GuidanceKind might be ToolMentor, Technique or a Guideline. Since these examples (and others like them) are necessarily part of the methodology definition, they do not need to be frozen into the metamodel definition. Thus, flexibility is provided for the software developer by the use of these GuidanceKind and WorkProductKind metaclasses.

There is a second, non-orthogonal (to Activity) set of Work Definitions – those associated with temporal sequencing: Iteration, Phase and Lifecycle. Of these, Lifecycle is associated with the Process metaclass and both Process and Discipline (a categorization for Activities) are modelled as kinds of Process Component.

Although the top part of Figure 3.5 has some similarity to the equivalent portion of SPEM, the connection to WorkUnit in OPF is not one of generalization, as in SPEM, but of association via an abstract superclass called Stage. The names and granularities of the subtypes of Stage are not identical to SPEM. Here, Build, Phase and Cycle are intervals and Milestone is a point in time. In fact, the treatment of time in the process is the major distinction between these two process-focussed metamodels. (SPEM is also set as a kind of UML since it is a profile of that modelling language.)