Before analyzing and describing requirements for metamodeling languages we shall first clarify our research method. We discuss how ISD methods were selected for the study, how they were modeled, and how they were adapted into a modeling tool. Each of these steps is described in the following subsections in more detail.

In the selection of ISD methods we used several criteria. First, we chose methods which are well-known or widely-used. This criterion ensures that the metamodeling constructs are needed for modeling most of the methods used today. Second, because we focus on representing method knowledge in modeling tools, only those methods that could be supported through computer-aided modeling tools were selected[16]. In fact, the selected methods are already supported by another computer-aided environment, either in a method-dependent CASE tool or in a metaCASE environment. Availability of tool support also shows that the selected methods are known, and that they have users. Otherwise there would hardly be such tools available.

Third, the primary criterion for method selection was to find a set of ISD methods which represent diverse approaches and exploit different kinds of conceptual structures. This selection criterion ensures that the metamodeling constructs identified are valid for a wide variety of methods, not just, for example, for modeling object-oriented methods. Therefore the chosen methods include data modeling techniques, IS planning techniques, structured design and analysis methods, object-oriented methods, and business modeling methods. The relatively large number of object-oriented methods included can be explained by the fact that they include more techniques and have richer conceptual structures than other methods (Rossi and Brinkkemper 1996). As a consequence, it is expected that the modeling of object-oriented methods will necessitate the use of more powerful metamodeling languages. Table 4-1 provides a summary of the selected methods together with their individual modeling techniques (i.e. each method consisting of one or more techniques).

TABLE 4-1 Methods selected for metamodeling.

The structure of the metamodeling process is summarized in Figure 4-1. The universe of discourse is that of the selected methods, in contrast to modeling the “real world”. Each method was examined and modeled using a metamodeling language in a metaCASE tool. The outcome of the metamodeling effort, i.e. the metamodel produced, was adapted into a tool environment and validated by trying out the method in system modeling.

 

FIGURE 4-1 Structure of method modeling.

Like any modeling task, metamodeling is driven by a number of objectives. In our case metamodeling was based on a content analysis of the published method literature. We tried to follow as closely as possible the method descriptions given in the reference books (cf. Table 4-1) rather than deviating slightly to better suit an envisaged use situation. Content analysis can be defined as a process of identifying, coding and categorizing primary patterns in data (Patton 1990). In our metamodeling study, relevant data about methods was first collected and identified through the method literature. The method literature basically describes the concepts, languages, notations and possible requirements in building tool support for a method. Second, the data was classified into distinct types, allowing us to simplify and systematize the conceptual structure of methods. In our case the classification was based on the metamodeling languages. Naturally, a metamodeling language with a given classification schema restricts our view of methods. Third, the methods were documented as completely as possible via the metamodels.

Another objective for the metamodeling task was the method-tool companionship: the metamodeling task was conducted by examining how selected methods could be supported by a tool. Therefore, the metamodels were “executable” and implemented into a modeling tool (see Section 4.2.3).

The actual method modeling was conducted in two phases. In the first phase, winter 1992-1993, we analyzed a set of methods and developed a set of tentative metamodels (reported in Tolvanen and Rossi 1996). The second phase took place in 1995-1996, when we analyzed and modeled the same methods in more detail. We thus modeled the methods twice. During the first round, we limited our focus to modeling individual techniques and their conceptual structures, whereas in the second phase we focused on method integration, i.e. how different techniques could be combined to form a “whole” method. Because of our interest in tool-supported methods we applied two metamodeling languages that are supported by metaCASE tools, OPRR (Welke 1988, Smolander 1992) and GOPRR (Marttiin et al. 1995, Kelly et al. 1996) respectively[17]. These metamodeling languages were applied because of the tool support available for metamodeling and testing the metamodels (cf. Section 4.2.3), because they succeeded relatively well in the metamodeling exercise (cf. Section 3.3), and because our own metamodeling experience was mostly with these languages.

During method modeling we distinguished the following set of tasks that OPRR (Tolvanen and Lyytinen 1993) and GOPRR related metamodeling must follow. These tasks, applied in several successful metamodeling efforts (cf. Tolvanen and Lyytinen 1993, Rossi and Brinkkemper 1996, Hillegersberg et al. 1998), provided a more detailed view of the classification process of content analysis as adapted to metamodeling. These tasks are:

1) Identification of the techniques in the method. Because each method can consist of one or more techniques we first need to identify them (as listed in Table 4-1). Most often an ISD method proposes a number of separate techniques with different concepts and supporting notations, but a technique can also include concepts that are shared with other techniques. For example, in Embley et al. (1992) an object-behavior model (used for describing a life-cycle of a single object through state transitions) can include interaction relationships which are also applied in object-interaction models. Some techniques can also be subsets of other richer and more complex techniques in the same method. For example, in Fusion (Coleman et al. 1994) and in MOSES (Henderson-Sellers and Edwards 1994) an inheritance graph includes only a subset of the concepts used within an object model.

2) Identification of object types. The modeling of an individual technique starts with resolving what kind of object (or entity) types a technique recognizes. Object types can be defined as basic elements of a technique that can exist independently of other types in a technique. Examples of object types in a data flow diagram are ‘process’, ‘store’, and ‘external’.

3) Determination of properties for each object type. Each object type has zero to many properties that characterize object type instances. Since object types typically account for the majority of properties of a technique and properties can be shared with other types (Rossi and Brinkkemper 1996), this task is distinguished as a separate task. Identification of properties that belong to types other than object types are discussed in task 6. Examples of property types are ‘identifier’ and ‘name’ for an object type ‘process’.

It must be noted that in GOPRR a property type can have an internal structure, an identity constraint, and a local name. For example, the property type ‘operations’ is of collection data type, and refers to the ‘operation’ object type which it contains. This object type in turn consists of other property types such as an ‘operation name’ and a ‘return type’ (cf. Figure 3-11). In addition to defining a set of property types, one of them can be defined as an identifying property type. In GOPRR, the identifying property defines which property type is used as the non-property type’s name. For example, a name of a class comes from its ‘class name’ property type, rather than from e.g. its attributes (i.e. the ‘attributes’ property type). When attached to non-properties, a property type can be re-labeled in the context of the attached non-property. This allows to define property sharing between non-property types: instances of two or more non-property types can refer to the same property values (cf. Kelly 1997).

4) Determination of relationships. Object types are connected to each other through a number of relationship types. This task deals with the identification of those relationship types that connect object types. Examples of relationship types are ‘data flow’ in a data flow diagram and ‘inheritance’ in a class diagram. It must be noted that these can not be defined as an object type in GOPRR because that would lead to incorrect method definitions: in the context of data flow diagrams this would allow data flows which are unrelated to processes.

5) Determination of roles. After object and relationship types have been identified, connections between these types need to be established. In the metamodeling languages we applied, these connections are specified by using role types. Examples of the role types are ‘sender’ and ‘receiver’ connected to the ‘data flow’ relationship type, and ‘subclass’ and ‘superclass’ connected to the ‘inheritance’ relationship type.

6) Allocation of properties to relationship types and role types. As with object types, relationship and role types can also have properties. These can typically be allocated to relationship or role types after all types have been identified.

7) Determination of metamodels for individual techniques deals with making all possible connections between the object, relationship and role types in a single technique. The connections can be further specified according to the cardinality: a minimum and a maximum number of instances of a role type a relationship type instance can have.

8) Determination of linkages between separate techniques is needed to form a whole method. Thus, the previous steps are carried out for each technique individually. In general, these linkages define interactions between techniques in two directions: horizontal and vertical (Lyytinen et al. 1991). In the horizontal direction connections or constraints between types or instances in different techniques are specified. For example, data stores in data-flow diagrams are redefined for cross-checking with ER models. The vertical direction refers to linking semantically equivalent descriptions at two consecutive levels of abstraction, such as connecting an ER model with its representation in a relational schema, or transforming a data flow diagram into a structure chart (Yourdon 1989a).

9) Determination of the representational part of the method. The use of methods in modeling tools necessitates the specification of notations such as graphical symbols. The representations are needed because the descriptions derived using the method are created, compared, and communicated by humans (Harel 1988). Accordingly, we must define symbols and location information for the elements of the method. Examples of symbols are bubbles for processes (Yourdon 1989a), and a cloud for classes (Booch 1991). Examples of location include placing elements in the horizontal axis of a matrix and drawing superclasses above subclasses in a diagram. Typically representations are expected to correspond one-to-one to the types specified in a metamodel (Venable 1993). The representation aspect in a modeling tool also includes dialogs, menus, and toolbars: to be used in a tool these must be defined for the method as well.

10)Analysis and evaluation of the metamodel. Because method specifications in the literature are often inconsistent, ambiguous and informal there are several alternative ways to model a method. At this step different modeling alternatives, or even versions of metamodels, are analyzed and assessed based on the available method descriptions and modeling tools developed, to ensure that all knowledge of a method is captured in the metamodel. At the same time, we also discuss limitations of the metamodel and point out constructs for modeling ISD methods more completely with a metamodeling language.

Metamodeling, however, is not as straightforward a process as described above. Rather it is an iterative process in which alternative ways to model method knowledge are tried out, analyzed and compared on the basis of their results (Tolvanen and Lyytinen 1993). For example, when several options for understanding and modeling methods were available (e.g. because of poor or imprecise descriptions of methods) we often tried several alternatives. This naturally led to iteration between metamodeling tasks, and developing and testing many versions of metamodels (at least two versions of each technique were developed). Some of these metamodeling alternatives are discussed in Section 4.3, in which the metamodels of three methods are represented. Also some pieces of the methods already modeled by others (such as in Olle et al. 1991, Welke 1988, Brinkkemper 1990, Smolander 1992, ter Hofstede 1993, Venable 1993, Hong et al 1993, Kinnunen and Leppänen 1994, Marttiin et al. 1993, Ebert and Süttenbach 1997, Süttenbach and Ebert 1997, Booch and Rumbaugh 1995) were used to suggest alternative metamodeling decisions and help validate that all parts of the method knowledge were captured.

Although the inductive research approach followed allows us to generalize requirements for metamodeling languages, it also raises some problems. The first one deals with the expressive power of the chosen metamodeling languages (i.e. OPRR and GOPRR). Their predefined classification schemata will influence our view of methods. Second, the metamodeling languages applied could not describe all method knowledge. However, those parts of the method knowledge which we were not able to classify according to the metamodeling language, and thus not described in the metamodels, were recorded into a diary. These additional descriptions were attached into the metamodels as free-form descriptions and are also partly discussed in Section 4.3 when we evaluate the metamodels. In fact, most aspects of methods which could not be modeled are generalized as requirements for metamodeling languages in Section 4.4. Because the tools were driven by the metamodels developed, these unclassified aspects of methods were not taken into consideration during the tool implementation.

As mentioned above, method modeling included an examination of how the selected methods could be modeled and supported by a modeling tool. Consequently, methods were adapted into two metaCASE tools, called MetaEdit (Smolander et al. 1990, MetaCase 1994) and MetaEdit+ (Kelly et al. 1996, MetaCase 1996a, 1996b). By adaptation we mean a representation of a given method in a tool in such a way that the CASE tool can support modeling tasks as prescribed by the method (Tolvanen and Lyytinen 1993). In the selected metaCASE tools the adaptation is relatively easy and straightforward since metamodels are almost directly applicable as method specifications in the tool.

More important than the tool support, however, was the possibility to validate the metamodels. In every modeling task, the lack of correspondence between the real-world and the model raises a question of validity. Correspondence between ISD methods and metamodels is no exception. In our case, tool-related metamodeling offered mechanisms to ensure an equivalence between the metamodels at the type level (i.e. IRD definition level) and system models at the instance level (i.e. IRD level) by modeling with the method: each element in a model must have a corresponding element in the metamodel. In this sense, the metamodels include only those concepts that are essential, and can be supported by a modeling tool. This also confirms that the metamodels are as complete as possible. Accordingly, the method examples shown in the following sections include both the type level definitions (i.e. metamodels) as well as some instance level descriptions (i.e. models). Similarly, Wijers (1991) claims that complete metamodels are so complex that a full verification of them without tool support is unmanageable. Tool support allowed us to check that metamodels were complete in terms of the metamodeling language used, and to make queries on the metamodels (e.g. what kind of relationships are possible between selected objects, what properties are shared between elements of a technique, etc.). The method specifications described in the following section were produced by querying the metamodels that were stored in the repository.

[16] The excluded methods typically focus on early phases of ISD, such as blackboard and brainstorming based methods. Similarly, methods related to project management, configuration management etc. are excluded from our study.

[17] These languages are discussed in Section 3.3.3, in the appendix, and in Tolvanen and Rossi (1996).