In this chapter, we have analyzed conceptual structures of methods and proposed essential constructs for metamodeling languages. These constructs were derived from the analysis of ISD methods by modeling the methods and by validating the metamodels by adapting them into a modeling tool. Our focus on metamodeling has captured static aspects of method knowledge for adapting a tool. The constructs are not required only to represent method knowledge, but also to “execute” the methods in a computer-aided modeling tool. Each construct of a metamodeling language supports the implementation of a certain part of the conceptual structure of a method into a modeling tool.

The proposed constructs were divided into two categories, those for modeling a single technique and those for modeling a whole method. In modeling a single technique, four constructs deal with modeling property types, including their identity, uniqueness, mandatory and data type. One construct, type multiplicity, deals with the number of instances of a given type. Four of the constructs deal with connections between objects, namely cyclic relationships, cardinality, multiplicity of single role type, and multiplicity over several role types. Required constructs for modeling interconnected techniques were classified into four aspects: inclusion for specifying the types used in each technique; complex objects for describing types which are treated as being “combined” without explicit relationships; explosion for modeling links between types and different techniques; and polymorphism for specifying the types of a method whose instances share the same values. These constructs are specific for the field of method modeling only, and no suggestions were made of their applicability in other domains.

The analysis of method knowledge together with the proposed metamodeling constructs also serves as a vehicle for assessing existing metamodeling languages. In short, CoCoA and GOPRR seemed to be most comprehensive for specifying method knowledge behind modeling techniques. NIAM also succeeded well but only while modeling single techniques.

In general, the assessment reveals that the current methodical support for method engineering is modest. While in recent years some progress has been made in outlining conceptual and theoretical principles for metamodeling and several metamodel-based tools have been developed (for a survey see Tolvanen et al. 1996) we argue that the available metamodeling languages, mostly based on data models (CASE Outlook 1989), do not provide adequate support for all aspects of method engineering. For example, metamodeling methods offer limited constructs for modeling interconnected techniques. Moreover, we identified conceptual structures of methods which could not be represented with the proposed metamodeling languages adequately or even at all. As a result, we have pointed out some areas for improvement.

It must be noted that we did not discuss method knowledge that could be supported already by all the languages, since this can be found directly from the metamodels. Similarly, during the assessment of the metamodeling languages we did not evaluate which language is more suitable for metamodeling, nor did we try to eliminate the constructs offered by these languages although some of them offered constructs which we did not find essential. This was especially the case with NIAM (see also Weber and Zheng (1996) for the construct overload) since the constraints for equality and exclusion were not found to be essential. These constraints along with some other might, however, be needed in modeling other methods, or if different interpretations of method knowledge and their tool support need to be made. The refinement of available languages for metamodeling, however, is outside the scope of our study.

Finally, various interpretations of method knowledge and its modeling deserve a closer examination. Like all modeling, our metamodeling effort was influenced by alternative interpretations of the method knowledge. Two major reasons for the interpretations and alternative versions of metamodels were tool adaptation and incomplete, or even inconsistent, method descriptions.

First, on the tool adaptation side, method developers have not considered enough possibilities of computer-aided tools but rather maintained the pen-and-paper mentality. Moreover, most remarks on tool use were made on the representational side, rather than on the conceptual side of method knowledge. As a result, in tool adaptation some aspects of method knowledge could be modeled differently. For example, there is no need to introduce additional textual pages separate from diagrams to view and edit more detailed information about the elements of a diagram (e.g. Lundeberg et al. 1981, Goldkuhl 1992) if such information can be added directly to the elements. Similarly, models do not need property types for entering reference information, such as how many representations of this instance exist (Gane and Sarson 1978), or whether the process is decomposed or not. Also the identity of instances does not need additional reference numbers, such as process identifiers, or information codes, widely used in pen-and-paper based methods (e.g. Yourdon 1989a, FIPS 1993a, Lundeberg et al. 1981). The balancing rules applied in many methods (e.g. Yourdon 1989a) could also be implemented differently: instead of referring to names in a polymorphism, we could refer to actual instances. Why refer just to a value of a property type, if the whole instance of an object type or a relationship type is available. These modeling options are typically related to the support provided by a modeling language, or a tool.

Second, a major reason for alternative metamodels was inadequate or even inconsistent method descriptions. As a result, we need to make our own decisions on what specific concepts and rules mean. For example, in most of the object-oriented methods, except OSA (Embley et al. 1992), it is unclear whether a state model can include states of more than one object. Instead of providing methods for systematizing ISD, method developers should apply (meta)methods to systematize ISD methods (Parsons et al. 1997).