The shell model allows us to illustrate the tool support addressed in this thesis: ISD tools include at least a part of method knowledge. Typically tools contain parts of the conceptual structure as their schema definition, support modeling with certain notations, or support the process definition and management (Odell 1996). Tool support is important for our research questions because tools can ensure that method knowledge is also applied and does not remain only as method descriptions (i.e. described method vs. method in use).

While the shell model concentrates mainly on the “deep-structure” of the method knowledge behind ISD tools, the tools also provide support for the surface and physical structures of methods (Wand 1996)[9]. Deep structure denotes those aspects of method knowledge which reflect the domain under development, whereas surface structure and physical structure deal with properties of modeling tools. Surface structure describes user-interface characteristics of an ISD tool, such as how method knowledge behind a modeling technique is visible in dialogs, menu commands and reports. This resembles the notational part of method knowledge. Physical structure denotes the technical means applied in the implementation of the ISD tool.

In this section our focus is on tools which support the use of methods, i.e. way of supporting (Wijers 1991). This formed the third italicized part in our definition of ISD (cf. Section 2.1). First, we briefly characterize ISD tools in terms of how they support different phases and tasks of ISD. Second, we describe relationships between methods and tools in more detail through the concept of method-tool companionship. This allows us to explain how tools can support modeling techniques. This is relevant for our research questions, since we seek to apply metamodels in specifying modeling techniques enacted by ISD tools. Thus, it is possible to describe the underlying elements of methods (i.e. a metamodel) on which these tools are based (Teichroew et al. 1980). This focus also means that we believe that the use of metamodeling in local method development is most beneficial when related to customization of tools. Naturally, metamodeling can be applied for reasons other than local method development (cf. Brinkkemper 1990), but local method development aiming only to specify and compare methods takes us only half-way, because the usefulness of a method is realized only when it is applied. Using metamodels without considering their support in ISD tools would be the same as designing an IS without implementing it.

Since the 1970’s numerous attempts have been made to support methods via computer tools (i.e. software applications) (Bubenko et al. 1971, Waters 1974, Teichroew and Hershey 1977). Technological developments have lead to a large number of tools that cover nearly all tasks of ISD. At the same time the term CASE (Computer-Aided System Engineering) has been extended to denote all types of computer tools from business modeling and requirements capture to implementation tools.

The concept of CASE is broad and it includes compilers, project management tools, and even editors[10]. In this thesis we examine CASE tools (and methods) in the context of modeling. These modeling tools are usually used to support early phases of ISD. As already mentioned, the term method is restricted in this thesis to mean that part of the method knowledge that it is possible to capture into a formalized part of a tool. Types of methods and tools deployed during different phases of ISD are described in Table 2-2.

As shown in the table, support for business process re-engineering and development include both methods and tools (cf. Spurr et al. 1994). On the method side, process maps, workflow models, task structures and action diagrams are applied (Harrington 1991, Goldkuhl, 1992, Lundeberg, 1992). On the tool side, computing power is applied for example to benchmark, compare, and simulate business processes through models. GDSS (Group Decision Support Systems), CSCW (Computer Supported Cooperative Work) and requirements engineering tools can be used in gathering information and organizing it into a structured format so that it can be used in later phases of ISD. The methodical aspects of these tools rely on brain-storming, interviews and cooperation. In the system analysis and design phases the upper-CASE tools support methods such as conceptual data modeling (ER models and derivatives) and structured analysis and design (e.g. data flow diagrams, decomposition diagrams and state transition diagrams). Most CASE products nowadays focus on supporting object-oriented methods, and recently tool support has been extended towards business modeling (Wangler et al. 1993). In this thesis we also concentrate on business modeling methods which, to a large extent, lack computer support (Stegwee and Van Waes 1993).

TABLE 2-2 Examples of methods and tools in the phases and tasks of ISD.

The relationship between methods and tools is most obvious in the construction phase: program code written in a high-level language is compiled into machine code. The availability of compilers renders programming methods and languages practicable, because there is little point in writing first in some programming language and then making a translation by hand. During construction and maintenance, computer aided tools can support version control, configuration management, and reverse engineering.

Though the technical realization of the companionship between tools and methods can vary, the need to integrate tools and methods is obvious (Forte and Norman 1992). On the one hand, tools mechanize operations prescribed by methods by storing system representations, transforming representations from one type of model to another, and displaying representations in varying forms. On the other hand, tools empower users by enhancing correctness checking and analytical power, by freeing them from tedious documentation tasks, and by providing multi-user coordination (access and version control). None of these features could be easily available in manual method use. The companionship between tools and methods has also evolved in response to technical innovations (Norman and Chen 1992). These require extensions to existing methods or entirely new types of methods to support their development (e.g. to cope with distributed systems (Olle 1994)), or then allow new types of methods because technical innovations can be applied (e.g. simulation of state models).

CASE tools do not provide the same level of support for all types of method knowledge. For example, there are more tools that support model building, representation and checking than there are tools that guide processes or provide group support (Tolvanen et al. 1993). Naturally, some aspects of methods lend themselves more easily to automation than others (Olle et al. 1991). Nevertheless some method knowledge need to be present in an ISD tool. The presence of methods can also be viewed using CASE tool support functionality, i.e. each type of functionality necessitates different method knowledge. In the following these are discussed based on support for four different design steps (Olle et al. 1991): abstraction, checking, form conversion and review. Olle et al. (1991) also include a step for decision making, but since it can only be supported through other steps and can not be automated (cf. Olle et al. 1991) we exclude it from the analysis of method-tool companionship.

1) Abstraction deals with CASE tool support for capturing and representing aspects of object systems. The majority of steps in design deal with abstractions, and thus it is also the most supported step (Olle et al. 1991). On the level of method-tool companionship this requires that a tool includes all the modeling related parts of the conceptual structure and employs notational representations for them in modeling editors.

2) Checking of system descriptions is needed to ensure that models are syntactically consistent with method knowledge. Hence, this design step can be carried out only after some aspects of the object system have been abstracted into models. Checking operates mostly on the conceptual structure and deals with constraints and rules of the method (also called verification rules (Wijers 1991)). Although some checking activities can be carried out by using alternative representation forms, such as matrixes for cross-checking, checking operates mostly on the non-notational concepts. Therefore, to achieve companionship this requires that the conceptual structure of the method includes not only concepts related directly to representation (i.e. abstraction) but also include information to carry out checking. For example, in most object-oriented methods, the link between a state model and a class in a class model is vaguely defined (one good exception is Embley et al. 1992): A state model can include states from several classes and therefore a tool can not analyze whether all attributes of the class have values during its life-cycle. To carry out this type of checking, the method specifications should include a reference from each state to a corresponding class, or have state models that are used for instances (i.e. objects) of a single class only (as in Embley et al. 1992).

These type of rules concerning the conceptual structures of methods are largely absent, because most methods are developed from a “pen-and-paper” mindset. As a result, we do not have many methods which are developed specially for CASE environments and take full advantage of automation. Furthermore, in methods which apply multiple modeling techniques, the need for checking is stressed. Also, if multiple tools are used, method integration is a prerequisite of successful tool integration.

3) Form conversion deals with transforming results from one phase or task to another, e.g. analysis models to design models. During a form conversion an underlying conceptual structure, a notation, or a representation form changes. Examples of such conversions, found in many CASE tools, are model analysis, reporting functions, and code generation. To support these, the conceptual structure should include types and constraints which are not necessarily required for the abstraction or checking steps. For example, to generate program code (e.g. C++ or Java) from a class model each operation representing a method in generated code should include return types as well as access levels (i.e. public, private, protected). These constructs are often missing from conceptual structures of text-book methods. As a result, CASE vendors need to extend methods in order to provide additional tool functionality. It should be noted that not all conversions can be fully automated, but rather often require human interaction.

4) Review deals with semantic validity of system descriptions, whereas checking focuses on syntactic properties of the model. Because the review step is often carried out together with the users or experts in the object system domain, the notation part of method knowledge is emphasized here. To ensure that models describe all relevant parts of the system, the notation should be sufficient to represent them. Naturally, the adequate support of the notation reflects the underlying conceptual structure.

Since the effectiveness of the tool is always dependent on the method it is important how a method or its parts are implemented in a tool. In other words, which aspects and which level of detail of method knowledge are supported. In our research, this means that the applicability of methods is partly dictated by how well the tool supports their techniques. Hence, method-tool companionship is based mainly on supporting the conceptual structure and its related notation, and secondly the modeling process and design objectives. The modeling process is relevant because the user interface (i.e. interface structure (Wand 1996)) dictates how the tool can be used and thus affects processes related to modeling: how models are created, how they are accessed, etc. The design objectives are relevant to method-tool companionship because tools should also support generation of design alternatives or produce solutions automatically.

In the majority of current CASE tools method integration has been implemented only partially. Tool developers have concentrated more on producing technical solutions such as repositories and intelligent knowledge-based support in their products, while the methodical part has been given a lower priority. Hardly any CASE tool developers have introduced methods which have been developed especially for CASE environments (Tolvanen and Lyytinen 1993). Furthermore, methods which have been coded as a part of a tool, what we call method-dependent CASE, do not allow the further development or extension of methods according to the situation specific needs. We believe that this technically-driven development of CASE has partly led to the rigidity and weak support of users’ native methods.

In our opinion the promise of CASE tools does not lie in the long run in the automated support of old “pen and paper” methods, but in innovative and new uses of computer based methods. Against this backdrop the surprisingly slow diffusion of CASE tools is also more understandable. Research into introducing CASE in an organization reveals that the main problems in the introduction are not the technical changes, but the methodical and cultural changes which the use of the new tool will inevitably cause (Aaen et al. 1992, Aaen 1992, Loh and Nelson 1989, Smolander et al. 1990). These observations are obvious, because the effective use of CASE tools is not possible without an adequate experience and knowledge of method use (Humphrey 1989). Introducing method-dependent CASE tools causes changes in the way of working and in the use of methods. Limited possibilities to adapt the tool into an organization’s own standards has often led to growing dissatisfaction among users (Wijers and van Dort 1990).

In contrast to the tool-driven approach, one should select tools so that they fit into the local domain and ISD situations. Several studies of CASE tools (see e.g. Marttiin et al. 1995, Smith et al. 1990) speculate that tool development will lead to method-independent CASE tools, instead of tool-driven development. In the same vein, Bubenko (1988) examines several alternative strategies for selecting CASE tools and introduces seven possible ways to exploit CASE. Four of these, building your own CASE tool, ordering your own CASE tool, integrating several tools and experimentations with research prototypes, (others are wait and see, limited experimentation and buying a method specific CASE tool) allow the adaptation of organizations’ methods with the tools. Whereas these researchers have pointed out the demand for flexible CASE support, the technological point of view has still been dominant. Therefore, the opportunities for flexibility in CASE-supported ISD is still at most modest. This problem is discussed from the viewpoint of tool adaptation in Chapter 3.

[9] Originally Wand (1996) used the taxonomy of deep, surface and physical structures to identify aspects of IS, but because ISD tools are also ISs, we use it here to define method knowledge in ISD tools.

[10] The need to identify characteristics of different CASE products has lead to several classifications (cf. Chen et al. 1989, Nilsson 1989, McClure 1989) where boundaries are quite fuzzy, like upper- (front-end), lower- (back-end) and mid-CASE as well as toolkits, workbenches and integrated CASE environments. It is also possible to classify tools based on the level of integration: drawing tools without a repository support, project repository-based tools, and organization-wide repository-based tools.