In this section we shall apply the results of the method analysis to evaluate the modeling power of several proposed metamodeling languages. Evaluation of modeling power implies evaluation of the constructs languages offer for metamodeling. Similar kinds of assessments or comparisons have been carried out by Welke (1988), Venable (1993), Saeki and Wenyin (1994), and Harmsen and Saeki (1996). In the following sections we shall first review existing comparisons in terms of their focus to clarify how they differ from our evaluation. This is followed by an assessment of a set of metamodeling languages using the metamodeling constructs identified. The section concludes with a discussion of how well semantic data models can serve as a metamodeling language from the perspective of modeling power, and in what way they should be extended to describe method knowledge more completely.

In his early study Welke (1988) analyzed the modeling power of binary, ER, and OPRR models to compare how adequate they are as metamodels for a repository (i.e. as metaschema). The focus was especially on how completely each metamodel can represent method knowledge, and hence it is close to our approach. The suitability of different metamodels is demonstrated by using structure charts as an example. In conclusion, the limitations of each metamodeling language are discussed and an extended OPRR model, called WOPRR, is briefly proposed for modeling larger methods and more complex techniques. Smolander (1991) has extended the analysis of the OPRR model based on experiences gained building OPRR-based metamodeling tools. Limitations of OPRR are identified in two areas. First, OPRR does not provide possibilities to model n-dimensional structures, such as the complex objects discussed earlier. Second, OPRR does not provide concepts for defining the connections between multiple connected techniques that form a whole method.

Venable (1993) concentrates on modeling complex objects, especially in situations of complex covering aggregation in which an aggregate covers both entities and their relationships. The modeling language proposed, named CoCoA, is compared with a number of other data modeling languages, such as the ER model (Chen 1976), entity-category-relationship model (Elmasri et al. 1985), class model of OMT (Rumbaugh et al. 1991), and NIAM (Wijers et al. 1992). Although the comparison covers languages used for IS modeling, many of them including CoCoA have also been used for method modeling (Grundy and Venable 1996). In the comparison two criteria, the richness and problem domain correspondence, are relevant to us here. Richness refers to there being sufficient semantic concepts to describe relevant aspects of the problem domain, i.e. method knowledge. Problem domain correspondence specifies whether the constructs of the metamodeling language correspond to the aspects of the problem domain (i.e. methods). The analysis reveals a limited support for modeling integrated techniques and demonstrates how complex covering aggregation is relevant in metamodeling. In CoCoA, a complex covering aggregation is mostly used for specifying which object types and relationship types are components of a technique.

Saeki and Wenyin (1994) point out some limitations in ER-based metamodels: how to describe constraints and hierarchical structures (i.e. complex objects). Based on their evaluation, they suggest Object-Z as a language for method modeling. Object-Z can describe knowledge and rules related to the decomposition of processes in data flow diagrams, and constraints of relationships, such as data flows between stores. Although their study reveals the need for supporting specifications of constraints of method knowledge, no classification of relevant constraints or even other constraint types is mentioned.

Finally, in a study by Harmsen and Saeki (1996) four different metamodeling languages are compared. Some languages included in their study also address process modeling, but all of them include meta-data modeling. The focus of their comparison is on a wider framework of languages for method engineering. Because of the breadth and generality of their framework, the study does not reveal how well meta-data modeling languages can represent method knowledge and how it is related to metamodel-based modeling tools.

Although these studies present comparisons of metamodeling languages, our analysis complements them in the following ways. First, we focus on languages for meta-data modeling in relation to tools. To our knowledge only Welke (1988) has compared metamodeling languages in relation to CASE, and especially to a repository. Second, and perhaps more importantly, these earlier comparisons were carried out on a relatively general level, since most of them do not address detailed requirements for metamodeling. Finally, in line with our inductive approach, our comparison is based on a set of constructs found essential in modeling a large number of methods. Still, the inductive approach limits our analysis to those aspects of metamodeling that are relevant in modeling the chosen set of methods.

As described in Chapter 3, several languages for method engineering (i.e. metametamodels) have been proposed and even implemented into tool environments. In this section our goal is to analyze a set of metametamodels according to the proposed essential constructs. The selected metamodeling languages were already discussed in Section 3.3.3. They were selected because of their focus on meta-data modeling, and intention for use as a metametamodel in an adaptable modeling tool. Thus, we excluded all those metamodeling languages which focus on method representation only and do not enable metamodel-based adaptation of modeling tools such as CASE tools. Furthermore, those parts of the metametamodels which do not focus on modeling techniques were excluded. Hence, from MEL we analyzed only the constructs for specifying product fragments and from ASDM we analyzed only its deliverable model.

Because not all the tools applying the selected metamodeling languages were available to complement our study the assessment is partly biased: it is unclear how the metametamodels proposed can actually serve as a metamodeling language for customizable modeling tools. This observation emphasizes the need for such a tool-related comparison (Tolvanen et al 1996). Tools for MEL (Harmsen 1997), CoCoA (Venable 1993) and NIAM were not available as they exist at the design level only, or include partial implementations for the researcher’s purposes only. The most common metametamodels implemented into tools (CASE Outlook 1989), such as ER (Mercurio et al. 1990) and OPRR (Meta Systems 1989, Smolander 1991, Marttiin et al. 1993, MetaCase 1994) are widely described from a tool point of view, and also tool-related implementations have been carried out for GOPRR (Kelly et al. 1996), and ASDM (Heym 1993). The last environment supports only method modeling but not the implementation of modeling tools based on the metamodels developed. We furthermore acknowledge the differences in versions of languages and their evolution, as well as differences in supporting even the same language (e.g. Quickspec and MetaEdit for OPRR) (Marttiin et al. 1993, Smolander et al. 1991). In the analysis we tried to focus on only one metametamodel version which is close to the tool environment. Also, additional grammatical extensions made for the notations of metamodeling languages, such as proposed by ter Hofstede (1993) for NIAM, are excluded, since they could be available for other metamodeling languages as well for directly enforcing certain integrity constraints.

In the following we describe the results of evaluation. The results are also summarized in Table 4-6: the vertical axis includes the metamodeling constructs and the horizontal axis includes the metamodeling languages. A cross means that the metamodeling language meets the requirement and a cross in brackets that the current support is limited. It is obvious that the evaluation of the metamodeling languages is not as clear-cut as Table 4-6 depicts.

TABLE 4-6 Support for metamodeling constructs in different metamodeling languages.

Identity of types is considered a relevant construct in most metamodeling languages, except in ASDM, CoCoA and MEL. Most languages, however, specify identity of object types only, and they do not distinguish the identity based on the scopes discussed in Section 4.4.1.1. OPRR allows one identifier for object types only, but GOPRR allows identifiers to be defined for other types as well (i.e. graph, relationship, and role types). NIAM normally uses a single identifier specified in parentheses above the entity name but also other keys, distinguished by ‘+’, are possible.

Uniqueness of property type instances is considered in ER, OPRR, NIAM and GOPRR, but inadequately on the scope side. A common extension to ER models for schema design is a uniqueness constraint. In OPRR identifying properties are expected to be unique globally (i.e. inside the scope of a method). In NIAM, the uniqueness of label types can be defined by a reference scheme named in parentheses under the name of the object type. In addition to this identifier description, the uniqueness of label types can be described by a uniqueness constraint attached to a role of the label type connecting an object type to the label type. Thus, the use of the same label for many object types allows for uniqueness inside the scope of a dependent type. Likewise, in GOPRR the property can be unique among the instances of related types.

Mandatory property types are identified explicitly in NIAM only. This is achieved by a total role constraint attached to an entity (Nijssen and Halpin 1989) or an object (ter Hofstede et al. 1993) type connected to a label type. Some other metamodeling languages include the possibility to define mandatory properties with other constraints. For example, in MEL (Harmsen 1997) a required clause can be used to define that certain properties must be available in other modeling techniques. In CoCoA the constraint could be supported through a simple aggregation with minimum cardinality one but this would lead to complex structures if all mandatory values had to be specified as aggregations and optional properties as a normal attribute. A common extension in the ER model (Teorey 1990) for defining constraints for attributes and database implementation considerations is the restriction of null values.

Since semantic data models underpin the design of database schema, various data types are widely recognized and supported, including basic data types such as integer, Boolean, and string. Basically only two weakly supported modeling constructs are encountered: properties with a specified grammar, and collections. On the grammar side, CoCoA, NIAM, OPRR, and GOPRR support more complex data types based on predefined values or intervals for possible values. On the collection side, GOPRR has an explicit collection data type which can have any of the basic data types as components, or even other types of the method. CoCoA allows the definition of attributes (also called properties) as an aggregate of other attributes, and with the simple covering aggregation entity types may have components of other entity types. For the same purpose NIAM has been extended by power types (ter Hofstede et al. 1993).

The cardinality constraint is handled only in GOPRR by separate cardinality values for both minimum and maximum cardinality. Moreover, since the cardinality constraints are effective in the scope of a model GOPRR adequately supports modeling of all possible binary and n-ary relationships. Although other metamodeling languages allow n-ary relationships to be specified it is only supported at the type level. For example, in CoCoA a relationship can consist of more than two roles (i.e. type level), but it can not be specified whether instances of a specific role type are necessary (i.e. instance level). In NIAM the modeling of a cardinality constraint requires that the relationship is considered as an object type (as in ter Hofstede 1993, p 45) leading to difficulty in implementing a method support based on the metamodel: there would be no way to distinguish the appearance of objects from relationships if they are of the same type. Subtyping of entities could be applied here, as in the reference model of Heym (1993). In spite of this, the relationships of methods considered as object types can have an occurrence frequency constraint on the related role type to include both minimum and maximum cardinality.

A multiplicity constraint is supported by ER, ASDM, OPRR, CoCoA and NIAM. ER and ASDM support only maximum multiplicity (called there cardinality) whereas CoCoA, MEL, and OPRR allow to specify minimum and maximum multiplicity. NIAM supports minimum multiplicity with a value of one (i.e. mandatory participation in a role) by a total role constraint, and maximum multiplicity with a value of one (i.e. instances of a role must be unique) by an uniqueness constraint. Other multiplicity values for maximum multiplicity can be supported by attaching the additional occurrence constraints for roles. This possibility is not allowed for minimum multiplicity (Weber and Zhang 1996) as required to model some methods (such as service charts in which a condition must participate in at least two role instances of the same type). The scope of the multiplicity constraint is left undefined in all metametamodels and assumed implicitly (once not specified) to cover either a scope of a method or a model. CoCoA, however, can capture an aggregation of role types together with the related relationship type and therefore supports both scopes of the multiplicity constraint. If a role type is only part of a single technique the scope for the constraint is a model. If the same role can also be part of multiple techniques (overlapping according to terminology of CoCoA) CoCoA could also restrict to the scope of the method. In principle support for specifying a scope among a limited set of techniques could be supported as well, although this was not recognized essential among the analyzed methods.

Multiplicity over several roles is only supported by NIAM, via a total role constraint attached to two or more roles connected to the same object type. NIAM, however, does not explicitly define a scope for this constraint and it is applied by metamodelers (i.e. ter Hofstede 1993) only for the scope of a model.

Cyclic relationships can be modeled with all metamodeling languages, but only in NIAM can a direct recursion be forbidden by defining the cyclic relationship (called homogenous binaries by Nijssen and Halpin (1989, p 183)) as irreflective, and an indirect recursion by defining the relationship as asymmetric. In contrast, no method has relationships which are reflective, or symmetric, i.e. none of the object type instances must be related to itself via a cyclic relationship, nor does any connection between two object type instances necessitate another instance of the same relationship type with different role types.

Modeling the multiplicity of types is not supported in any of the metamodeling languages analyzed. Thus, it is not possible to specify rules for restricting the number of instances of a given type (i.e. how many instances of an object or relationship type must or can occur in the scope of a model or a method).

Most metamodeling languages focus on modeling single techniques only. Accordingly, only a few of them distinguish constructs for modeling multiple interconnected methods adequately.

Inclusion is supported in ASDM, CoCoA, MEL, and GOPRR, although in CoCoA (Venable 1993, p 116) it is applied only in integrating similar types of techniques from different methods. All of them allow the modeling of many-to-many relationships of the inclusion: the same type can be part of multiple techniques, and a technique can consist of multiple types. Because of the deficiency of NIAM in this matter it has been extended with schema types by ter Hofstede et al. (1993).

One of the most weakly supported constructs in metamodeling languages is the modeling of complex objects. Only ASDM, CoCoA and GOPRR support some structures of complex objects: ASDM provides a structural entity type; GOPRR provides decomposition, instance reuse, and nested data types for modeling complex objects. The last of these, however, does not address complex objects other than by allowing a component to be modeled as a property of an aggregate object (i.e. simple covering aggregation as in CoCoA). CoCoA provides complex covering aggregation to model an aggregate object type and its components as object and relationship types. As mentioned above, NIAM has been extended (cf. ter Hofstede 1993) with a schema type also applicable for modeling complex objects. In the following we assess the modeling support according to the various structures of complex objects (cf. Table 4-4).

In ASDM, entity types resulting from recursive aggregations expect that the component (called the structural entity type) must belong to exactly one aggregate type (called the fundamental entity type). In contrast, in CoCoA and GOPRR component elements are not dependent on the existence of an aggregate object. Thus, they can not adequately specify methods which apply top-down modeling only, such as functional decomposition (Yourdon 1989a) or a composite (Booch and Rumbaugh 1995). However, connected components, which are recognized as essential in all structures of complex objects, can be modeled. The third dimension, mandatory component objects, can be modeled only in CoCoA. In GOPRR components are optional, but in CoCoA both mandatory and optional components can be specified by a cardinality constraint for the covering aggregation, namely one for mandatory and zero for optional components. In relation to the exclusive-shared dimension of complex objects, GOPRR and CoCoA support only the shared dimension by allowing the same instance of a component type to belong to more than one aggregate object. As a result, they can not adequately specify methods which apply complex objects with an exclusivity constraint, such as the clusters of BON (Walden and Nerson 1995), functional decomposition (Yourdon 1989a), composite (Booch and Rumbaugh 1995) or nested state diagrams (Rumbaugh et al. 1991, Booch et al. 1997).

The fifth dimension of recursive complex objects is supported adequately both in CoCoA and GOPRR since only recursive complex objects need to be perceived. In CoCoA recursive complex objects are modeled by using the same names for the aggregate and the component. Hence, the same instance of an entity type is added twice to the CoCoA diagram. In GOPRR, non-recursive complex objects can also be described by having two different graph types (i.e. techniques), one containing the aggregate type and another for the component types. Moreover, the graph type for components should not include the aggregate object type. Because this approach requires two different graph types the choice of the modeling technique beforehand would not be ideal.

The metamodeling languages studied do not make any type level distinctions between relationships of an aggregate or a component. Thus, they all satisfy the sixth type of complex structure, i.e. independent relationships for aggregate object types. The final requirement in modeling complex types is aggregated relationships. This was not supported in any of the metamodeling languages studied.

The third essential construct in modeling interconnected methods is the explosion from a type of one technique into another technique. For this metamodeling requirement GOPRR includes an explicit explosion construct; CoCoA does not provide such a construct explicitly and most of the CoCoA metamodels are based on techniques of a similar type in which the connection is based more on inclusion and use of the same types among several techniques rather than explosion structures between techniques (cf. Venable 1993, Grundy and Venable 1996). Relationships which are outside the domain of complex objects can, however, be distinguished as explosion relationships (see the CoCoA example in Section 3.3.3.5). NIAM does not provide support for explosions because it does not consider multiple techniques at all. Therefore, NIAM has been extended with PSM (ter Hofstede 1993) to support explosions by a relationship from an object type in one schema type to another schema (i.e. technique). These relationships are usually distinguished from other relationships by naming the roles (c.f. ter Hofstede 1993, p 33, 45) since they are represented with the same notation and constraint types. Hence, like CoCoA, NIAM/PSM does not provide any explicit type level construct.

None of the metamodeling languages for describing explosions is adequate. First, no distinction is made about the scope of explosions. The metamodeling languages analyzed thus do not distinguish between explosion of a type instance in a model or among all models. Other deficiencies in the metamodeling languages can be illustrated by various alternatives of explosion structures, namely type of the explosion source, cardinality of the explosion, exclusive or shared explosion target, and dependent/independent explosion target. Each of these characteristics was described in Section 4.4.2.3 and will be applied in the assessment below. Both GOPRR and extended NIAM (ter Hofstede 1993) support explosion structures from object types only, and thus can not adequately model explosion from property types, e.g. from a service to service charts (as in Coad and Yourdon 1991a), or from relationship types, e.g. from a transition to a data flow diagram (as in Rumbaugh et al. 1991). Mandatory explosion is supported in NIAM/PSM only with the extended graphical constructs (ter Hofstede 1993): a total role constraint on the role of the object type participating in an explosion relationship. In principle, other NIAM constraints for roles, such as uniqueness and occurrence frequency constraint, could also be used for describing other necessary cardinality rules. To our knowledge, however, NIAM has not been used to model such an explosion cardinality (cf. ter Hofstede 1993, ter Hofstede et al. 1993). If extended in such a way, exclusion of explosion links could also be described with the exclusion constraint of NIAM added to all role types of explosion relationships. While the cardinality of explosion links is unspecified in GOPRR, mandatory explosion links can not be modeled. Also, many-to-many relationship between instances of object types and graph types are allowed.

Polymorphism is not supported at all in MEL, NIAM, ER and ASDM. For example, ASDM allows the same property type for one entity type only. Other languages address it only partially.

CoCoA offers an entity alias which supports polymorphism among entity types only. No entity alias, however, was found from the methods analyzed as none of them includes different types which have exactly the same instance information. The entity alias seems to have be added into CoCoA mainly to support integration of similar kinds of modeling techniques (cf. Grundy and Venable 1996). Moreover, CoCoA does not specify the functionality of such an alias if an aliased entity occurs in a complex covering aggregation. For example, would it have the same relationship instances as well?

OPRR supports dependencies between elements at the level of single valued properties only (Smolander et al. 1991, MetaCase 1994). A reference property type links to instances of the same, or another property type. Since the property type referred to may be named differently on the metalevel and belong to a different object, relationship, or role type, some structures of polymorphism can be supported with OPRR. These include methods which apply polymorphism in a single technique and share single valued (string) property types independently. Sharing of single property values can be supported among multiple type instances by using the reference property type for each type. Since any instance of the referred property can be used as a value for a referring property, the reference scope is the whole method.

GOPRR extends the support of polymorphism found from OPRR to multiple techniques as well as to more complex data types than string or other basic data types. If such more complex data types would be used, necessitating the use of instances of object, relationship or role types, the polymorphism is supported for multiple values. In GOPRR the sharing of a single instance as a property type is called property sharing. GOPRR does not specify any dependency to the property sharing, and it is allowed wherever the same property type is reused.

Support for metamodeling of polymorphism can be analyzed through the support for each kind of polymorphism structure: the coverage over one or more techniques, the number of property type instances shared, the number of types related, and the dependency. The metamodeling languages do not make a difference between polymorphism with instances of one technique or a whole method. OPRR provides support for sharing one property value only; and GOPRR extends this to sharing of multiple connected property values through sharing non-property types. This necessitates that all interconnected properties of a polymorphism structure are collected into a single type. Sharing the same property values can not be limited into two or any other number of instances. As a result, for example balancing rules of SA/SD requiring correspondence between two type instances only can not be modeled. These balancing rules state that an instance of an entity name can belong to only one item in the data dictionary. Finally, none of the metamodeling languages recognizes dependencies among polymorphism structure.

Although metamodels represent a great deal of static method knowledge and customizable CASE tools can automate them they are not complete. First, our metamodeling efforts with GOPRR (and OPRR, Tolvanen and Rossi 1996) show that it has limited support for modeling the rule parts of method knowledge. Second, none of the languages provides adequate support for metamodeling. The obvious reason is the limited metamodeling capabilities of the selected data modeling approach. As a result, we need to discuss the limitations of method modeling using conceptual data models. This topic is especially important because other languages for metamodeling, such as Object-Z (Saeki and Wenyin 1994) or LISA-D (ter Hofstede et al. 1993) have been proposed, which could solve alone, or as extensions, limitations of data model based languages. To guide the development of languages for capturing method knowledge or to find other complementary approaches, we illustrate in the following some key constraint types for metamodeling languages which were not addressed with semantic data models.

The analysis of the limitations of data model based metametamodels is supported by our method modeling studies. First, methods include transformations in which models based on one technique are transformed to another model. This is typical in vertical integration of techniques. According to our metamodeling approach this would necessitate changing the types of instances. For example, in a transform-centered design (Yourdon and Constantine 1989) a network model of processes can be transformed into a synchronous structure chart. Similarly, a data transformation based design approach used in JSD (Cameron 1989) applies generation of initial process structures from the definitions of the data structures. This is especially relevant in CASE tool based methods since they can automate error-prone routines, such as transformations. Transformations, however, are examples of method knowledge that needs information both about meta-data models for retrieving or changing design information (cf. Brinkkemper et al. 1989) and about process models (cf. Marttiin 1998, Marttiin et al. 1996) for guiding and executing the transformation.

Another type of method knowledge that can not be captured with static metamodeling constructs is heuristic rules and recommendations. For example, some object-oriented methods include recommendations on the breadth and depth of inheritance hierarchies, the number of public operations for a class (Booch 1991), or that a single state model should not specify states of more than one class (e.g. Embley et al. 1992).

Third, dynamic relationships among the instances of the same or different type can not be described with data models. Examples of these dynamic aspects in method knowledge are the numbering of an instance based on the number of its creating activity (Lundeberg et al. 1981), or that functions participating in a call relationship can not have child diagrams (FIPS 1993a). Similarly, in Yourdon (1989a, p 283) possible values for a condition in a state transition can not be found among the properties of the related control process, but from the flows it participates in: the possible values for the condition are only those names of flows which are coming into the control process. This type of polymorphism could not be supported with the proposed constructs. Extensions of methods closer to the constructs of programming languages would raise similar requirements. For example, an action defined in a state diagram of a single class should be characterized as a private method, and a message between objects as a public method, in the corresponding method definition of the receiving class. Similarly, modeling of method overloading would not be possible with the proposed metamodeling constructs. The extension of the metametamodels and metamodeling languages in this direction is, however, questionable. Some of the dynamic rules on naming, especially on the identifier side, originate from pen-and-paper oriented methods (e.g. Lundeberg et al. 1981) and are not necessary in computer-aided environments. Thus, there would not be a need to support these in metamodels either.

Fourth, none of the metamodeling techniques support grammar specification for formal textual descriptions, such as process specifications, data dictionaries (Yourdon 1989a), or textual grammars (Walden and Nerson 1995). These are especially important to better integrate modeling tools and models into other tasks of ISD, such as generating prototypes, program code, or visualizing available data and program structures.

Because of these limitations other metamodeling approaches, such as rule-based languages or predicate logic, could be more suitable as extensions and need to be studied in relation to the criteria proposed here. Various other type of languages for metamodeling could also be tested to specify essential constructs of metamodeling.