4.3 PROCESS AND MODELLING CONFLICTS

We saw, in Chapter 3, the various application areas in which metamodels have been used. In particular, we showed how metamodelling underpinned the development of UML, which offers notational support for work products, and SPEM, which offers notational support for process elements of a methodology but excludes concepts found in the UML for work product descriptions.

A methodology, as we saw in Chapter 1, requires much more than just a modelling language and much more than just a process. Consequently, in our striving for a methodology metamodel, neither a modelling language, such as UML, nor a process modelling language, such as SPEM, is adequate. We need to investigate some combination or integration of these two – some attempts at such integration have indeed been made [3; 16, pp. 300, 305]. Here we review the issues involved and propose some solutions.

Modelling and process concepts are related in a number of ways; for instance, specific work products are created during the execution of a specific work unit, such as a task prescribed by the process. Classes – instances of the UML element Class – are usually created during IdentifyClasses – an instance of the OPF work unit Task. Of course, for any full-scale integration of “product” and “process”, it is necessary that the chosen pair of modelling and process frameworks contain the same (or at least a compatible set of) concepts. An interesting dilemma only becomes apparent once these statements are related to their natural metalevel (in the OMG sense, as described by Figure 2.19).

Despite the fact that both UML-like and SPEM-like metamodelling frameworks essentially use the same architecture (for OMG products, that is the framework of Figure 2.19), such that modelling occurs at level M1, definitions at M2 and enactments at M0, the reality of software development means that a software developer's work occurs at OMG level M1 when they are designing (e.g. drawing a class diagram) but at OMG level M0 when they are using (enacting) the process elements e.g. when they are undertaking the task of creating a class diagram. In other words, as shown in Figure 4.13, the IdentifyClasses task resides at level M0 (the enactment of the ta1:TaskDefinition² (with name = IdentifyClasses) at level M1), whereas the class being defined (in the class diagram) is naturally allocated to OMG level M1 (since Class is a concept defined as part of the UML metamodel at OMG level M2). This means that ic1:IdentifyClasses and cl1:Class are closely connected – actually with an association relationship. As indicated in Figure 4.13, this association relationship, because it crosses metalevel boundaries, linking as it does the M1 cl1 with the M0 ic1, is illegal within the OMG rules of strict metamodelling (see Chapter 2). (Although we have used UML and SPEM as exemplars here, the argument applies to any pair of modelling and process languages that use a strict metamodelling rule to link metalevels.)

Possible solutions to this paradox are explored in a series of papers [1; 2; 3; 4; 5; 6; 7] and summarized here. In this discussion, we make the broad assumption that standardization committees, such as the OMG or the International Organization for Standardization (ISO), are concerned with agreeing and standardizing the semantics of elements at the equivalent of the OMG level M2. The metamodel of level M2 is then generally used by methodologists and method engineers (not software developers). In turn, software developers use the methodologies created at the M1 level with tools that allow them to create M1-level models i.e. they use the rules of the modelling language, they do not create the rules of the modelling language (that, as we have pointed out, is the role of the standardizing committee). This asymmetry further reflects the incompatibilities between the modelling and process domains and does not resolve the dilemma between the use of instantiation and specialization discussed below.

Figure 4.13: Illegal association between the IdentifyClasses task definition and the Class element in UML

An obvious “solution” to the dilemma posed by the level-crossing association relationship in Figure 4.13 is to move the right-hand side (process elements) up one layer (or the left-hand side down a level) – Figures 4.14 and 4.15 respectively. Both realignments eliminate the cross-boundary association. However, both introduce new problems. In Figure 4.14, we can see that the definition of all tasks has been elevated to the standardization level of M2 and that TaskDefinition (and all other semantic definitions of process-focussed concepts) is now part of level M3 (ostensibly the metametamodel). Since a metametamodel should only contain a very small number of concepts [17], this realignment is untenable on all counts. In Figure 4.15, it is clear that the new location of cl1:Class at the M0 level does not allow for instances of this class (the Customer class in this example) to be created at runtime (as the object code for the computer model is executed on the hardware platform). Since, by definition, the M0 level is the bottom-most, utilization of a level M — 1 is not possible. Secondly, the conceptual definition of Class is now moved from the M2 layer down to the M1 layer. If we assume that, in general, the standardization of a modelling language must occur at level M2 and that level M1 refers only to the user (the software developer), then asking the software developer (operating at level M1) to create their own standard definition and semantics for Class is tantamount to inviting disaster (or at least a proliferation of varying and incompatible definitions of Class – and of all other concepts in the modelling language).

Figure 4.14: Vertical realignment by moving the process elements up one layer

Figure 4.15: The illegal associations between layers disappear as elements are re-arranged

Figure 4.16 depicts a third option, which involves not only instantiation but also a generalization relationship. Since generalization can occur within a layer, the model now fits into only two layers: M2 and M1. However, there are now three elements shown within the M2 layer. Since the M2 layer contents are candidates for standardization, such a standard would need to include formal definitions not just of TaskDefinition and IdentifyClasses but also all the other subtypes of TaskDefinition, e.g. a standard for CodingTask, DesignUserInterfaceTask, DevelopBusinessObjectModelTask, etc. – an open-ended set. Furthermore, we have also lost the notion of “people” operating at level M0 since they are now necessarily part of level M1. To rectify this last problem, we could of course decrease all the levels by one, i.e. move Task and Diagram to M1 and IdentifyClasses, Customer, etc. to M0. Unfortunately, this would leave absolutely nothing in the M2 (standardization) layer!

Figure 4.16: A possible solution using generalization (with ideas described in [4])

Before analyzing these possible solutions further, we need first to introduce a second and very important challenge that results from the incorporation of process modelling into the methodological framework i.e. how to define standard characteristics on a meta-element (M2) but resist allocating a value to it until level M0. Remember from Chapter 3 that the standard object-oriented semantics state that when an attribute is declared on a class at any level in the hierarchy, that attribute specification must have a value allocated to it at the next lower metalevel. Thus, with standard object-oriented semantics, it is not possible to define an attribute on an M2 class but refrain from giving it a value until M0.

While this works well for a modelling language, which is essentially defined at OMG level M2 and used at level M1, in standardizing process-focussed model elements, we must note that those process-focussed definitions made at level M2 are only realized (enacted) on real projects at level M0 i.e. two layers lower and one level lower than the M1 enactment layer for modelling [4]. For example, let us suppose that all Tasks, say, must have a specific duration. We therefore need to specify an attribute duration:Time on the M2 class Task. With normal semantics, that means we must allocate a value to duration e.g. duration = 3 weeks at level M1. If we do so, then we condemn all tasks used on an endeavour to take 3 weeks. This is clearly not acceptable. We wish to allocate specific times to specific tasks for a specific endeavour. For example, we want our enacted task do1:DefineOperation to take, for example, 50 minutes (not three weeks). Our ideal (but invalid) diagram to support this desire is shown in Figure 4.17.

Figure 4.17: An invalid UML diagram illustrating the goal of defining an attribute on Task, retaining the definitional state in ta1:Task and only allocating a value (duration = 50) at the lowest (endeavour) level

There are thus two major issues to resolve:

1. allocating the responsibilities of (a) standardization committees, (b) methodologists and method engineers and (c) software developers to appropriate levels or (a better word) domains in the selected framework (e.g. as shown in Figures 2.19 and 2.20)
2. devising a strategy to ensure that attributes can be defined in the standard metamodel but only given values in the Endeavour domain. In this case, two solutions have been proposed: potency and powertypes.

With the assumption that these two issues can in fact be resolved (for details of the use of potency versus powertypes for resolving issue 2, see Chapter 5), the key requirements for a comprehensive methodological framework can now be explored. We will see how a well-defined metamodel is vital for the formal specification and eventual standardization of a contemporary software development methodology, which must provide support for work products that are used in the software development process as well as definitions of the process elements themselves and roles for the members of the development team and their tools. On the one hand, a metamodel can be considered as an abstract construct that accommodates the concepts in which the methodology is based, giving formalized definitions for each one as well as rules for its successful use. On the other hand, a metamodel must allow for extension and adaptation of the methodology, by letting methodologists introduce new concepts based on the aforementioned definitions.

Figure 4.18: Re-arranged layers and sample elements at each level; clabjects are represented as class-object pairs enclosed in grey ellipses (after [19])

Source: Gonzalez-Perez and Henderson-Sellers, 2006, copyright Springer Science and Business Media. Reproduced with permission

Figure 4.18 illustrates how powertype patterns fit into a layered architecture (preferably that of Figure 2.20) – although there is no UML notation for a powertype pattern or a clabject.

Within the layer structure shown in Figure 4.18, metamodel elements are either regular classes for supporting resource methodology elements (objects) or meta-clabjects, which are used to support template methodology elements (clabjects). The UserAttribute and UserAssociation regular classes help support the latter. Table 4.1 shows a summary of these criteria.

Table 4.1: Types of metamodel element(after [19])

Source: Gonzalez-Perez and Henderson-Sellers, 2006, copyright Springer Science and Business Media. Reproduced with permission

Methodology elements can then be created from these metamodel elements. Classes in the metamodel generate regular objects to represent resources while metaclabjects generate clabjects with attached attributes and associations. Resources are intended to be used “as is” during enactment, while templates are intended to be used to introduce project elements. Table 4.2 shows a summary of these criteria.

Table 4.2: Types of methodology element (after [19])

Source: Gonzalez-Perez and Henderson-Sellers, 2006, copyright Springer Science and Business Media. Reproduced with permission

It should be noted that, while some project elements will be instantiated during execution, others will have no representation in the running software system. Conventionally, those project elements that are related to the process side of software development are used for project management, comprising an infrastructure that is certainly not reflected in the software system. In terms of modelling, technology usually dictates the kinds of project elements that are able to be incorporated into a software system. For example, classes are clearly part of a software system, requirements are not. Regardless of the technology, project elements that become part of the software system are instantiated during execution, thus producing a running system. Table 4.3 contrasts various process-and modelling-related project elements in terms of their purpose.

Finally, we must stress the importance of the use of the word “kind” as part of our discussion, since there is a distinct danger that the user or reader might not be readily aware that, in diagrams such as Figure 4.16 (compare with Figure 4.15), the semantics of a concept such as TaskDefinition have changed.

Table 4.3: Types of project element (after [19])

Source: Gonzalez-Perez and Henderson-Sellers, 2006, copyright Springer Science and Business Media. Reproduced with permission

Figure 4.19 compares the semantics of TaskDefinition in Figure 4.16 (left) and Figure 4.15 (right). In Figure 4.16, TaskDefinition describes a set containing many different actual tasks; in Figure 4.15, TaskDefinition is used to denote a different set with a much smaller number of elements. This change in both name and semantics occurs whenever instantiation semantics are substituted by generalization semantics (or vice versa). Atkinson and Kühne [3] characterize this in their discussion about whether specific elements, such as TaskDefinition, should be regarded as a class (generalization semantics) or a metaclass (instantiation semantics).

This ambiguity can be seen as resulting from the fact that many published works focus on very specific layers; for example, “each of the individual activities” [2, p. 45] or “the performance of actions” [34, Section 3.84.1] i.e. words relating to the partitioned type and not relating to the powertype. Typically, authors tend to use simple names, such as Task or Document, in order to refer to key elements in a model. They then use names such as TaskInstance or DocumentInstance to denote specific instances. Continuing with this example, Coding would be a Task (i.e. an instance of the metaclass Task), whereas each particular case of coding (performed by specific people with specific resources) would be an (instance of) TaskInstance. This means that it is not possible to differentiate between, say, Tasks and categories (or kinds) of Task. As we noted earlier, these are two different concepts e.g. [37]. Thus, here we prefer not to follow this overly simplistic convention. Instead, we use simple names for the instances themselves, together with the addition of the suffix “kind” in order to refer to their classifiers. Following this convention, Coding is an instance of TaskKind and each particular case of coding is an instance of Task. As an analogy, consider the statement that GoldenDelicious and GrannySmith are not apples, but rather apple varieties (AppleVariety can be taken here as analogous to TaskKind). The real apples that we can eat are apples (instances of Apple, analogous to instances of Task).

Figure 4.19: Semantic differences between TaskDefinition in Figures 4.16 (left) and 4.15 (right)

Also, we must emphasize again that some elements in a methodology are intended to be used as “templates” at the project level, usually through instantiation, while other elements are designed to be used directly. This difference has, to date, been confounded in all the process metamodels of which we are aware. Here, we refer to the former as template methodology elements and the latter as resource methodology elements. It should be noted that template methodology elements have a dual nature: on the one hand, they are classes available to be instantiated at the project level; on the other hand, they are instances (i.e. objects) of metamodel elements. This dual nature is, of course, a clabject [1], as introduced in Chapter 2, with both a type (or class) facet and an instance (or object) facet.

As a final comment on the role and utilization of models and metamodels in the methodology and method engineering contexts, we would note that, while there is an implicit assumption made by the OMG that standards are typically defined at the M2 or M3 level in which all pre-defined elements reside and that all user-defined elements belong to lower levels [2], it is possible that loosening this rule may have some advantages. For example, it would then become possible to create a standard that has some elements pre-defined at level M2 and others pre-defined at level M1 [2]. Called the “Unified Modeling Library” by Atkinson and Kühne [7], this has strong similarities to the notion of method fragment in a methodbase [11; 40] in situational method engineering. The Unified Modeling Library concept (Figure 4.20) allows both generalization relationships (to superclasses in the M1 layer) as well as instantiation relationships (to classes in the M2 layer). Indeed, this combination of generalization and instantiation parallels that of powertypes as used in ISO/IEC 24744 [26].

Figure 4.20: Library metaphor (after [7])

Source: Atkinson and Kühne, copyright Springer-Verlag, 2005. With kind permission of Springer Science and Business Media