Augmenting CASE tools with hypertext: Desired functionality and implementation issues

Abstract

Information systems have become bigger and more complex as their support has expanded to cover larger business domains, communication and work. At the same time technical design options such as client/server architectures and graphical user interfaces have increased the size and complexity of applications. In addition, pressures to build better systems more quickly have motivated the use of integrated design environments, such as CASE. Several integration approaches such as process modeling, frameworks and hypertext technology have been proposed. Of these we consider the least analyzed, hypertext technology, in this paper. Because of the novelty of hypertext in CASE there are several unresolved issues related to this approach. Present hypertext technology has been mainly applied to nonstructured representations such as text, which is radically different from complex structured representations such as the diagrams and matrices used in CASE. CASE tools also imply that a design object has both representational and conceptual aspect, which has not been investigated in relation to hypertext. In this paper we discuss how hypertext can be incorporated into a metaCASE tool which uses all the common representation paradigms: diagrams, matrices and tables. We also report the implementation and architecture of such an environment.

Managing Evolutionary Method Engineering by Method Rationale

“…Not surprisingly, most of these approaches have developed separate meta-models of design decisions outside specific modeling notations and process models, which are normal products of ME. Suggested tools are standalone tools and are integrated into CASE tools only in an ad hoc manner (see Kaipala (1997) for a different approach).…”

“…While some researchers have formulated conceptual aspects of method rationale (see e.g. Tolvanen, 1998;Kaipala, 1997;Ralyte and Rolland, 2001), no comprehensive analysis of the requirements for tool support has been made. Moreover, the rationale should be captured and integrated in a designer's natural use-context (Fischer et al, 1991).…”

“…This necessitates integration of both CAME and CASE 12 functionality with method rationale capability. Kaipala (1997) was the first to suggest a set of such tools, using the IBIS model (Conklin and Begeman, 1988) for recording design decisions and collecting method use experience. We expand his model by recognizing that, in addition to the model-based ME deliverables, other improvements or refinements of the methods need to be captured in a method rationale as well.…”

“…Some of the ME approaches support linking information about method use situations and contingencies to metamodels based on predefined coarse schemata (Harmsen et al, 1994b;Kaipala, 1997). These approaches fail, however, to explain how such detailed descriptions are obtained, nor do they relate to meta-models or their parts, which would offer enough detail to understand method change.…”

Managing Evolutionary Method Engineering by Method Rationale

“…Not surprisingly, most of these approaches have developed separate meta-models of design decisions outside specific modeling notations and process models, which are normal products of ME. Suggested tools are standalone tools and are integrated into CASE tools only in an ad hoc manner (see Kaipala (1997) for a different approach).…”

“…While some researchers have formulated conceptual aspects of method rationale (see e.g. Tolvanen, 1998;Kaipala, 1997;Ralyte and Rolland, 2001), no comprehensive analysis of the requirements for tool support has been made. Moreover, the rationale should be captured and integrated in a designer's natural use-context (Fischer et al, 1991).…”

“…This necessitates integration of both CAME and CASE 12 functionality with method rationale capability. Kaipala (1997) was the first to suggest a set of such tools, using the IBIS model (Conklin and Begeman, 1988) for recording design decisions and collecting method use experience. We expand his model by recognizing that, in addition to the model-based ME deliverables, other improvements or refinements of the methods need to be captured in a method rationale as well.…”

“…Some of the ME approaches support linking information about method use situations and contingencies to metamodels based on predefined coarse schemata (Harmsen et al, 1994b;Kaipala, 1997). These approaches fail, however, to explain how such detailed descriptions are obtained, nor do they relate to meta-models or their parts, which would offer enough detail to understand method change.…”

A conceptual framework for component context specification and representation in a metaCASE environment

“…Although the presented scenario is simple and uncompleted, as compared with the complex phone development life cycle, masses of contextual information and a number of contextual links have been created and explored. Without the context specification, its hypertext representation, and the supporting functions (Kaipala 1997;Oinas-Kukkonen 1997) like navigation, backtracking, and query functions, the substantial knowledge about the component logic and semantic structure and the design rationale is buried in the development process and difficult to be remembered, retrieved, and reused after the project.…”

Managing Evolutionary Method Engineering by Method Rationale

“…Not surprisingly, most of these approaches have developed separate meta-models of design decisions outside specific modeling notations and process models, which are normal products of ME. Suggested tools are standalone tools and are integrated into CASE tools only in an ad hoc manner (see Kaipala (1997) for a different approach).…”

“…While some researchers have formulated conceptual aspects of method rationale (see e.g. Tolvanen, 1998;Kaipala, 1997;Ralyte and Rolland, 2001), no comprehensive analysis of the requirements for tool support has been made. Moreover, the rationale should be captured and integrated in a designer's natural use-context (Fischer et al, 1991).…”

“…This necessitates integration of both CAME and CASE 12 functionality with method rationale capability. Kaipala (1997) was the first to suggest a set of such tools, using the IBIS model (Conklin and Begeman, 1988) for recording design decisions and collecting method use experience. We expand his model by recognizing that, in addition to the model-based ME deliverables, other improvements or refinements of the methods need to be captured in a method rationale as well.…”

“…Some of the ME approaches support linking information about method use situations and contingencies to metamodels based on predefined coarse schemata (Harmsen et al, 1994b;Kaipala, 1997). These approaches fail, however, to explain how such detailed descriptions are obtained, nor do they relate to meta-models or their parts, which would offer enough detail to understand method change.…”

A conceptual framework for component context specification and representation in a metaCASE environment

“…Although the presented scenario is simple and uncompleted, as compared with the complex phone development life cycle, masses of contextual information and a number of contextual links have been created and explored. Without the context specification, its hypertext representation, and the supporting functions (Kaipala 1997;Oinas-Kukkonen 1997) like navigation, backtracking, and query functions, the substantial knowledge about the component logic and semantic structure and the design rationale is buried in the development process and difficult to be remembered, retrieved, and reused after the project.…”

Managing Evolutionary Method Engineering by Method Rationale

“…Not surprisingly, most of these approaches have developed separate meta-models of design decisions outside specific modeling notations and process models, which are normal products of ME. Suggested tools are standalone tools and are integrated into CASE tools only in an ad hoc manner (see Kaipala (1997) for a different approach).…”

“…While some researchers have formulated conceptual aspects of method rationale (see e.g. Tolvanen, 1998;Kaipala, 1997;Ralyte and Rolland, 2001), no comprehensive analysis of the requirements for tool support has been made. Moreover, the rationale should be captured and integrated in a designer's natural use-context (Fischer et al, 1991).…”

“…This necessitates integration of both CAME and CASE 12 functionality with method rationale capability. Kaipala (1997) was the first to suggest a set of such tools, using the IBIS model (Conklin and Begeman, 1988) for recording design decisions and collecting method use experience. We expand his model by recognizing that, in addition to the model-based ME deliverables, other improvements or refinements of the methods need to be captured in a method rationale as well.…”

“…Some of the ME approaches support linking information about method use situations and contingencies to metamodels based on predefined coarse schemata (Harmsen et al, 1994b;Kaipala, 1997). These approaches fail, however, to explain how such detailed descriptions are obtained, nor do they relate to meta-models or their parts, which would offer enough detail to understand method change.…”

A conceptual framework for component context specification and representation in a metaCASE environment

“…Although the presented scenario is simple and uncompleted, as compared with the complex phone development life cycle, masses of contextual information and a number of contextual links have been created and explored. Without the context specification, its hypertext representation, and the supporting functions (Kaipala 1997;Oinas-Kukkonen 1997) like navigation, backtracking, and query functions, the substantial knowledge about the component logic and semantic structure and the design rationale is buried in the development process and difficult to be remembered, retrieved, and reused after the project.…”