Evolution and issues in metaCASE - Semantic Scholar

ELSEVIER

Information and Software Technology 38 (1996) 261-266

Evolution and issues in metaCASE Steven Kelly*, Kari Smolander University of Jyviiskylii, Department of Computer Science and Information Systems, P. 0. Box 35, FIN-40351 Jyviiskylii, Finland

Abstract Customizable CASE environments (metaCASE) have begun to emerge in the marketplace. They offer tools and facilities for flexible method support and adaptation. This paper gives some views on the history of customizable CASE and metamodelling. The most difficult issues on the way to an integrated metaCASE environment are addressed, including representational problems, conceptual problems such as storing and processing recursive structures, method integration problems, and problems in creating repository support for metaCASE. These areas, and the divisions between them, are shown to need further work before a truly integrated metaCASE environment can be produced. Keywords: MetaCASE; CASE

1. Introduction Many scholars have claimed that Computer Aided Software Engineering (CASE) will substantially reduce the costs of developing software, standardize the systems specifications and thereby improve the quality of information systems [ 1,2] However, recent evidence from using CASE tools’ shows that plain application of CASE technology will probably not change the situation substantially, as other dimensions in systems development must also be taken into account. For example, Siltanen [ 31 shows that the attitudes and orientation of IS management affect the impact of CASE. The study by Smolander et al. [ 41 revealed that the introduction of CASE is a major change which fails without the availability of sufficient resources and management attention. Other important factors included were the quality of the tools and their customization capabilities. LeQuesne [ 5 ] (p. 260) argued that changes in working practices and changes in the use of systems development methods should be evolutionary when introducing CASE. This means that CASE tools should have customization capabilities for preserving successful systems development practices when

*Corresponding author. This work is part of the MetaPHOR project, funded by the Academy of Finland. The authors can be reached at the University of Jyvlskyll, {steveklkake}@hyeena.jyu.fi. Kari Smolander now works for Carelcomp, Finland. ‘By CASE tools we mean tools that can help professional information system developers in producing, transforming, maintaining, approving, inspecting, managing, or translating information systems specifications. McClure [ 21 lists some examples of CASE tools which include diagramming tools, screen and report painters, dictionaries and data base management systems for storing technical and project management system information, specification checking tools, code generators, and documentation generators.

09%5849/96/$15.00 0 1996 Elsevier SSDI 0950-5849(95)01051-3

Science B.V. All rights reserved

introducing CASE. By customization capability we mean the ability of the tool to adapt to different systems analysis and design situations. A customizable tool’s languages, functions, and mechanisms can be somehow adapted (or ‘programmed’) to different situations and their particular needs. Despite all these observations, until lately there has been only minor interest in the customization problem and in analysing the connections between systems development methods and practices and CASE. The development of CASE started from such text-based environments as SREM [ 61, PSL/PSA [7], and PDL [ 81. These helped mainly in designing systems and software by offering understandable design languages and centralized data dictionaries, and were to some extent customizable. The design languages could be extended or adapted to the needs of the users and the schema of the data dictionary was largely definable. The advent of powerful workstations and graphical user interfaces has brought, however, a certain inflexibility to the field of CASE. The customization of graphical CASE is not so straightforward a process as the customization of text-based environments, and the specification of graphical design languages is not so simple as the specification of linear design languages. Therefore, the method support of widely used commercial CASE tools is mainly fixed, and limited to the most well-known textbook methods. To enable a flexible customization of the methods in CASE, new approaches and tools are needed. To cater for some of these concerns Bubenko [ 91 introduced the concept of a CASE shell, which would ’ . . include mechanisms to define CASE tools for an arbitrary method or a chain of methods’ (ibid. p. 11). In order to define a method in a CASE shell one must define a conceptual schema of the design objects constituting the method and specify how

262

S. Kelly, K. Smolanderllnformation and Sojiware Technology 38 (19%) 261-266

these design objects are represented to the users of CASE tools. These conceptual and representational specifications form a metamodel and the specification process is called metamodelling. In the following, we will summarize the research that has been done to improve the state of the art in metamodelling and metaCASE’ environments, and what kind of methods and tools have been developed to carry it out. Finally, the most pressing issues in developing metaCASE environments are summarized.

2. Metamodelling The field of metamodelling emerged in the 1980s. As noticed in Teichroew et al. [ lo] , developers of CASE tools soon realized that underlying a system development methodology exists a model of what an information system is. By specifying the underlying model using, say entity-relationship diagrams, it is possible to compare methodologies and to construct methodology support in a CASE tool. Brinkkemper [ 111 defines a metamodel as a conceptual model of a modelling technique. Brinkkemper’s concept of modelling technique is similar to our concept of method, which we understand to embody a set of concepts that determine what is perceived, a set of linguistic conventions and rules which govern how the perception is represented and communicated, and a set of procedural guidelines which state in what order and how the representations are derived or transformed (cf. Smolander et al. [ 121). Both Brinkkemper’s concept of modelling technique and our concept of method consist of a linguistic or a conceptual part which defines the concepts and languages to be used, and a procedural part which defines the procedures and activities embodied in a method or technique3. Brinkkemper calls the linguistic or conceptual part a meta-data model and the procedural part a meta-activity model. The first proposals for meta-data modelling were suggested in Teichroew et al. [lo], which applied the entityrelationship model as a basis for methodology models. Teichroew et al. ‘s proposal was the starting point for the development of the OPRR model [ 131 (see also Sorenson et al. [ 141 for a similar model), in which the concept of role was used to extend the ER model. Other approaches suggested for meta-data modelling include, for example, the modelling of graphical notations with set-theoretical formalisms in RAMATIC [ 151, and the application of NIAM [ 161 to metamodelling [ 171. Meta-activity modelling has produced fewer publications than meta-data modelling. Perhaps .the solutions to the

?We will use the word metaCME instead of CASE shell, in line with the current trend in the field. ‘Brinkkemper, however, leaves out the notion of linguistic conventions that determine, for instance, the notation associated with the concepts. This definition of representational principles is often the most difficult issue when building a metaCASE tool.

problems in me&activity modelling are less commonly agreed, the activities in systems development vary more than its linguistic and conceptual structures, and the practical applications of meta-activity modelling are not so obvious. There are, however, some approaches for metaactivity modelling which include, for example, activity modelling with task structures [ 17,181. In addition, the field of software engineering and programming has focused on software process modelling, the programming of the process of software production [ 191, which can be equated with me&activity modelling. Also the software engineering concept sofrware factory [20] implies the modelling of software processes as some kind of meta-activity model.

3. MetaCASE enfironments Work in metamodelling theory has often been followed by some constructive work in the form of metamodelling environments. These metamodelling environments exploit the theories of meta-data modelling, and therefore they can be easily divided into two categories based on the languages they support. If the description languages that the environment can support are always linear in the sense that they consist of one-dimensional sequences of predefined symbols, the environment is called a text-based environment. If the description languages can be n-dimensional (graphical languages, tables), the environment is called here a graphical one. 3.1. Text-based environments Among the first text-based metamodelling environments was SEM [ 10,21,22] which was a textual environment based on a variation of the entity-relationship datamodel. SEM was composed of two parts: the information systems language definition system (ISLDS) and the systems encyclopaedia management system (SEMS). The definitions made by the language definition system specified the description language to be stored in the systems encyclopaedia management system, in which the information system descriptions were collected. This division between the meta level (ISLDS) and the instance level (SEMS) is characteristic of all metamodelling environments. The architecture of SEM has had a strong influence on most successive metamodelling environments. Particularly, the text-based environments such as Plexsys [ 231, MetaPlex [ 241, and QuickSpec [25] have derived many of their features from SEM. Each of these environments has separated the language definition part (meta level) and the actual information system specification part (instance level) which uses the language defined on the meta level. The meta level itself is based on a still higher level model which can be called the meta-meta model. The meta-meta model in all these environments is some variant of the entityrelationship model.

S. Kelly, K. Smolanderllnformationand Sofware Technology 38 (1996) 261-266

263

The modelling of linear languages has well-established solutions, and therefore the development of text-based environments is easier than the development of graphical environments. Unfortunately, most developers of information systems do not want to use textual design languages. Powerful workstations and windowing systems have offered possibilities of graphical modelling and created a need for visual tools that the textual environments do not meet. 3.2. Graphical environments The availability of cheap graphical interfaces has created new requirements for software engineering environments. The environments must support graphical modelling languages of the user’s choice. The environments should also conform to the conventions of the particular interface used, i.e. the windowing functions, mouse and cut and paste operations should be used in a standardized way. The support of graphical modelling languages in commercial CASE tools is on the whole predefined. They support a few of the known text-book methods and the possibilities for method customization compared to the textbased environments are very limited. One reason for the inflexibility of graphical CASE tools is the nature of graphics. The field of conceptual modelling is well established and has therefore provided sound principles for the modelling of concepts, but the field of graphics has not provided similar principles for the modelling of graphical modelling languages. Although graphical CASE shells are not so widely used yet, there are some environments that offer partial solutions to the modelling of graphical methods. The Swedish CASE shell RAMATIC [ 151 uses set-theoretical constructs to model graphical notations; the British Eclipse [ 261 uses directed graphs to represent design diagrams; and the Finnish MetaEdit [ 121 uses an entity-relationship model extended with the concept of role for the modelling of concepts and their graphical representations in the methods. Its meta-meta model is based on the OPRR model [ 131. Fig. 1 is a presentation of the level structure of MetaEdit: this structure can be generalized to apply to the majority of available metaCASE environments. A metaCASE environment may have several different metamodels, which then determine the methods that are used in modelling information systems.

4. MetaCASE issues So far, we have explored the historical development of metamodelling and metaCASE, and the current state of the art. In this section we will examine some of the more pressing issues facing metaCASE. Dividing them into representational (the way a method looks), conceptual (the underlying data in a model or metamodel), methodological and implementation (repository; the data store) problems, we will identify areas where we feel research or tools are at present

Documents, reports, code

Fig. 1. Level structure

of MetaEdit.

weak, and where they could be extended. These issues in particular have been chosen, because they are required by methods that are currently in use in organizations, either with paper and pencil or with method-specific CASE tools, and yet they are not supported well by existing metaCASE tools. 4.1. Representational

problems

Our experience of building a metaCASE tool has shown that problems concerning the support of the representations used in methods are often more difficult than those concerning methods’ concepts. The meta-metamodel, in this case OPRR, required only four basic concepts, and needed little adaptation during the course of implementation; the need for a general system to support all representations and their associated semantics constantly demanded attention. In this section we will examine some further extensions to the support of different representations needed within the next generation of (meta-) CASE tools. Graph-Matrix-Text. Several methods, many of which are concerned with developing business systems, use matrices rather than graphs (i.e. pictures of graphical symbols connected by lines or curves) as their main representation, such as IBM’s Business Systems Planning [ 271, Andersen Consulting’s Method/l [28,29] , Business Information Analysis and Integration Technique [ 301, and relational modelling [ 311. Support for these methods has largely been restricted to purpose-built, fixed method CASE tools, rather than metaCASE tools. A more common extension to (meta-) CASE tools has been support for the production of textual representations, such as reports. In some specialized systems this has been widened to include hypertext, for instance as a medium for recording design decisions [ 321. There exist still further possibilities of considering (hyper-) text on the same level as graphs and matrices, or of using it to provide an infrastructure for the whole CASE environment [ 33 ] .

264

S. Kelly, K. Smolanderllnformation and Software Technology 38 (19%) 261-266

Conditional graphics. The graphical symbols used in certain models [34,35] can vary not only according to the type of the object, but also according to values contained in the object’s properties, whether it has duplicates, whether it has been decomposed, or the number or type of relationships attached to that object. The need to present different views to support the activities of different developers or phases of development also motivates towards the capability to represent the same object in contextually different ways. Considerations internal to the application itself, such as locking or activity modelling, require additional ways of marking or changing the appearance of objects, over and above the normal visual indication that an object has been selected. These internal characteristics must be represented in as consistent a way as possible, whether the object is currently displayed in a graph, matrix or text form. Specialized behaviour. Most graphical methods attach semantics to the vertical and horizontal direction of flow of relationships or position of objects, with varying degrees of formality. To support or enforce (depending on the level of formality) this feature of the method requires specialized behaviour within the graphical editor, for instance by fixing objects to a grid or constraining the direction of relationships. This behaviour must be made available by the metaCASE tool, and then instantiated with any necessary values by the metamodel. 4.2. Conceptual problems: recursive structures Among the most powerful functions of the human brain are the abilities to group entities, to form hierarchies and abstractions. Consequently, any tool hoping to empower a human designer must support these ways in which people prefer to work, by allowing entities to have a recursive structure, and by providing operations to manipulate those structures consistently. These facilities, where they are present in (meta-) CASE tools, are at present inconsistent, and often tied to the way of thinking of a single method. In this section, a simple, coherent and method-independent approach is presented. Decompose and condense. The decompose operation takes an object which is (or will be) made up of other objects and shows those component objects, along with any associated relationships. There may or may not be a boundary showing the extent of the parent object: if so, moving other objects inside that boundary would add them into the parent object. The reverse operation, condense, shows the parent object of the selected object(s), or, if none yet exists, collects the selected object(s) together into a new object. Both decompose and condense take place without opening any new windows, and therefore other surrounding objects must allow enough space for the operation to be moved: a serious representational problem in a graphical notation, but simple in a matrix.

Explode. The explode operation, as its name suggest, is a somewhat more forceful version of the closely related decompose. When a complex object is exploded, a new window opens or is created, within which further detail of the object is revealed. This definition leads unfortunately to an asymmetry: although for decompose there is a reverse operation, namely condense, for explode there can be no such operation, as the new window exists independently and hence there should be no delete operation available from the creating window. 4.3. Methodological problem: method integration Usually in systems development people use several different methods to achieve intended results. The concepts in these methods are somehow tied together so that the transitions from a method to another (and maybe back) can be successfully executed. In metaCASE environments enforcing these connections between methods leads to difficult problems, and no satisfactory solution is available. Moreover, we must maintain consistency of design information along at least two dimensions (cf. Marttiin et al. [ 361): (1) Horizontal consistency, the consistency between different descriptions on the same level of abstraction, for example between an ER-model and a data flow diagram. (2) Vertical consistency, which is the consistency between semantically equivalent descriptions on different levels of abstraction, for example between an ER-model and an equivalent data base schema. Despite their great importance, systematic studies of the principles of method integration are missing. 4.4. Implementation problem: repository Requirements for a database differ according to its intended purpose, as noted by Brown [ 371 in comparing those for a commercial database with those for a software engineering database. For a multi-user metaCASE tool, the requirements are a witches’ brew of those two, with added peculiarities. Thus, in arriving at a repository and schema for metaCASE, it is essential to take stock of the data needs of such an environment, recognizing where previous work on other kinds of databases can be used, and where new theories and practices must be developed. Table 1 shows the requirements from Brown (p. 39), with those which we feel apply to a metaCASE tool in bold: the precise nature of access patterns will only be possible to determine later, by examining a real multi-user metaCASE and methodology engineering environment in operation. The fixed meta-meta model allows a fixed schema on the conceptual level: we need to store the meta-model for each method, then the conceptual data for each model can be mapped via this to the meta-meta model. By keeping the representational data free-form or unformatted, so no

S. Kelly, K. Smolanderllnformtion Table I MetaCASE comparison,

(bold), commercial and software engineering from Brown [37] (p. 39). emboldening added

Commercial

database

Software

engineering

and Sojiware Technology 38 (19%) 261-266

databases

database

Most information is static and can be described a priori, so the schema is also static and compiled.

Continuous evolution of information-data about the environment itself (tools, methods, etc.), and the products being developed.

Update to the schema is infrequent, and controlled by a group of Database Administrators.

Change to the schema is expected and frequent. Many users will need to change the schema.

Data stored is atomic and fixed-length (e.g. strings and numbers).

Data stored is atomic, but also structured. Could be graphical data, design documents, programs, and so on.

Also, data items may be large and complex,

and of variable

length.

Small number of entity types, with large numbers of instances of each type. Often only simple, fixed relationships between entity types exist.

Many entity types, with fewer instances of each type. Complex relationships may exist between entity types, and new relationships may be created.

Initially loaded with large amount of data. Slow, constant rate of data growth.

Less data initially loaded. Rapid growth of database (both of structure and contents), which slows down after completion of design phase.

Single-valued data items, which are updated in place.

Versions of data items are vital. Dependence on versions, and relationships between versions must be explicitly recorded.

Transactions are short, atomic, and can be used as the basis for concurrent data access.

Long-lived transactions (> hours) which may leave the database inconsistent for long periods. Cannot be conveniently used as locking units.

information about its structure is stored in the repository, the repository schema can remain independent from the tools. Although the meta-meta model will contain a limited number of types, the relationships between those types may be complex. For instance, if the concept of ‘rule’ is supported, this may have connections to virtually every one of those types if the rule is a check on transitive closure; e.g. in OPRR this would require moving between Objects via Roles and Relationships. Transactions are a contentious issue in (meta-) CASE, precisely because of the somewhat hazy nature of their definition in the more mature fields of commercial and software engineering databases. If we take the definition that a transaction is ‘a sequence of operations viewed as an inseparable whole’ then there are two viewpoints: that of the application and that of the user. Perhaps it is better to dispense with the term altogether, and instead use the notions of ‘unit of locking’ for the first viewpoint, and ‘version’ for the second. A system of locking and versions can offer maximum concurrent access, and this can then be restricted, for security or other reasons, by permissions. A locking strategy (or other method of safe concurrent access) should be formulated separately for each kind of

265

data. The data may be conveniently divided into three groups: meta data, containing the types, rules and symbols of the method, model data, which is representational, conceptual, or a combination of the two-for instance the name of an object may be both conceptual and also a graphical label on instances of that object, and user data, such as agent models, configurations, views, and permissions to access data. Whilst the literature [ 13,381 recognizes the need to separate the conceptual from the representational, and the meta data from the model data, these distinctions cannot be maintained as rigidly as would be hoped. If we are to allow customizability of a metamodel with effect for only a single model, or even a single user across multiple models, the boundaries in that dimension become blurred. Similarly, as shown above, there is data which is both conceptual and representational, such as a name which is also visible as a label in a graphical notation. Should this be duplicated with one copy for each, thereby maintaining the distinction, but producing problems of integrity assurance? Should it be considered as a separate type of data, increasing complexity and duplicating operations? Or should it be locked on accesses to it as either kind of data, with ensuing loss of concurrency?

5. Conclusions The field of metaCASE environments, both in terms of products and research, has been around for some time now. The early text-based metaCASE environments, although simpler to make, were not found to meet the needs to which they were addressed. Initial attempts to expand into graphical representations have also proved insufficient for development needs, because of their over-simple meta-metamodels, single editor or tool, and single representational paradigm. Although initially growing slowly, the field has gathered pace. However, in the current surge of interest, it is important that basic issues are re-examined, to provide a common foundation for data interchange and future expansion. Without this, metaCASE stands in danger of missing the wave of free data exchange and communication, leading to either a diverse, dissipated marketplace, or one, possibly two, vendors or schools of thought, whose frameworks are mutually exclusive and opposing. One of the main considerations throughout the history of metaCASE has been to recognize different types of data: conceptual/representational, meta/model, user-definable/fixed. These distinctions, foundational as they are to the whole principle of metaCASE, still require further refinement, in the light of the facts that there are no fixed boundaries between the types, and that parts of individual pieces may well lie on both sides of the divide. These items of data with a mixed type must be examined closely, both because of the difficulty of dealing with them within the current framework of divisions, and also to refine those divisions.

S. Kelly, K. Smolanderllnformation and Software Technology 38 (1996) 261-266

266

References [ I ] Chikofsky, E J and Rubinstein, B L ‘CASE: reliability engineering for information systems’, IEEE Sofnyare (March 1988) pp 11-16 [2] McClure, C CASE is Sofrware Automation Prentice-Hall (1989) [3] Siltanen, A ‘The impact of CASE tools on IS management’, in Spurr, K and Layzell, P (eds) CASE On Trial John Wiley (1990) pp 181-195 [4] Smolander, K, Tahvanainen, V-P and Lyytinen, K ‘How to combine tools and methods in practice-a field study’, in Steinholz, B, Sblvberg A and Bergman, L (eds) Advanced Information Systems Engineering. Proceedings of the Second Nordic Conference CAiSE ‘90, Stockholm, Sweden, 8-10 May 1990, Springer-Verlag (1990)

pp 195-214 [5] LeQuesne, P N Individual and Organizational Factors in the Design of Integrated Project Support Environments PhD Thesis London Business School (1990) [6] Alford, M ‘A requirements engineering methodology for real time processing requirements’, IEEE Trans. on Soft. Eng. Vol SE-3, No 1, (January 1977) pp 60-69 [7] Teichroew, D and Hershey, E A III ‘PSUPSA: a computer-aided technique for structured documentation and analysis of information processing systems’, IEEE Trans. on Soft. Eng. (January 1977) [8] Caine, S H and Gordon, E K ‘PDL-a tool for software design’, in Proc. of the National Computer Conference (1975) AFIPS Press [9] Bubenko, J A Selecting a Strategy for Computer-aided So&are Engineering (CASE) p 23, SYSLAB University of Stockholm, Stockholm (June 1988) [lo] Teichroew, D, Macasovic, P, Hershey, E A III and Yamamoto, Y ‘Application of the entity-relationship approach to information processing systems modeling’, in Chen, P P (ed) Entity-relationship Approach to Systems Analysis and Design North-Holland (1980) pp 15-38 [ 111 Brinkkemper, S Formalization of Information Systems Modelling PhD Thesis, Thesis Publishers, Nijmegen (1990) [12] Smolander, K, Marttiin, P, Lyytinen, K and Tahvanainen, V-P ‘MetaEdit-a flexible graphical environment for methodology modelling’, in Advanced Information Systems Engineering, Proc. of the 3rd Int. Conf CAiSE ‘91, Trondheim, Norway, May 1991, Springer-Verlag (1991) pp 168-193 [ 131 Welke, R J The CASE Repository: More Than Another Database Application Meta Systems Ltd (1988) [ 141 Sorenson, P G, Tremblay, J-P and McAllister, A J ‘The Metaview system for many specification environments’, IEEE Sofrware (March 1988) pp 30-38 [ 151 Bergsten, P, Bubenko, J, Dahl, R, Gustafsson, M Rand Johansson, L-A RAuATIc-a CASE Shell for Implementation of Specific CASE Tools SISU, Stockholm (1989) First draft of a contribution to section 4.4 of the TEMPORA project [ 161 Nijssen, G M and Halpin, T A Conceptual Schema and Relational Database Design: a Fact Oriented Approach Prentice-Hall (1989) [ 171 Wijers, G M, ter Hofstede, A H M and van Gosterom, N E Representation of Information Modelling Knowledge SOCRATES Report 90/09 (November 1990) SERC, Utrecht, The Netherlands. [ 181 Wijers, G M Modelling Support in Information Systems Development PhD Thesis, Thesis Publishers, Amsterdam (1991) [ 191 Osterweil, L J ‘Software processes are software too’, in Proc. of the 9th lnt. Conf on SOJ?. Eng. (1987) pp 180-188

[20] Evans, M W The Software Factory: a Fourth Generation Sofhvare Engineering Environment John Wiley (1989) [ 211 Yamamoto, Y Generation of Sofhyare Life Cycle Support Systems PhD Dissertation, University of Michigan, Ann Arbor (1981) [ 221 ISDOS, Inc. System Encyclopedia Manager, Lanugage Definition Manager: User Manual (SEMLDM Version 1.4.) ISDOS, Inc. (June 1985) [23] Kotteman, J E and Konsynski, B R ‘Dynamic metasystems for information systems development’, in Proc. of the 5th Int. Conf on Information Systems (1984) pp 187-204 [24] Chen, M and Nunamaker, J F Jr ‘METAPLEX: an integrated environment for organization and information systems development’, in DeGross, J I, Henderson, J C and Konsynski B R (eds) Proc. of the 10th lnt. Conf on Information Systems 4-6 December 1989, Boston, Massachusetts (1989) pp 141-151 [25] Welke, R J ‘Metabase: a platform for the next generation of meta systems products’, in Proc. of the 9th Ann. Conf on Applications of Computer-Aided Software Engineering Tools 23-27 May 1988, Ann Arbor, Michigan, Meta Systems Ltd. (1988) [26] Beer, S, Welland, R and Sommerville, I ‘Software design automation in an IPSE’, in Nichols, H and Simpson D (eds) ESEC ‘87: Proc. of the 1st European Soft. Eng. Conf Strasbourg, France 9-11 September 1987 (Lecture Notes in Computer Science),

Springer-Verlag (1987) pp 89-97

[ 271 IBM Corporation Business Systems Planning-Information Systems Planning Guide Publication #GE20-0527-4 (1975) [28] Arthur Andersen Consulting Foundation-Method/I: Information Planning Version 8.0, Chicago (1987) [29] Arthur Andersen Consulting Foundation-Method/l: Documentation Version 8.0, Chicago (1987) [30] Carlson, W M ‘Business information analysis and integration technique (BIAIT): a new horizon’, Data Base (Spring 1979) pp 3-9 [31] Vepslliinen, A P J ‘A relational view of activities for systems analysis and design’, in Decision Support Systems 4 North-Holland (1988) pp 209-224 [32] Pries-Heje, J and Malmorg, L ‘B4CASE-a tool for structuring and recording design rationale’, in Bjerknes, G, Bratteteig, T and Kautz K (eds) Proc. of the 15th IRIS, Department of Informatics University of OSLO, (August 1992) pp 310-324 [ 331 Oinas-Kukkonen, H ‘Hypertext functionality in CASE environments: preliminary findings’, in Hypermedia in Vaasa ‘93, Conference on Computers and Hypermedia in Engineering Education, Vaasa, Finland, 24-26 May 1993 [34] Gane, C and Sarson, T Structured Systems Analysis: Tools and Techniques Prentice-Hall (1979) [35] Booth, G Object-oriented Design with Applications Benjamin/ Cummings (1991) [36] Marttiin, P, Lyytinen, K, Rossi, M, Tahvanainen, V-P, Smolander, K and Tolvanen, J-P ‘Modelling requirements for future CASE: issues and implementation considerations’ in Proc. of the 13th lnt. Conf on Information Systems 13-16 December 1992, Dallas, Texas, pp 9-20 [37] Brown, A W Database Support for So&are Engineering KoganPage (1989) [38] Venable, J R and Truex, D P III ‘An approach for tool integration in a CASE environment’, #C8812 in Proc. of the 9th Ann. Conf on Applications of Computer-Aided Software Engineering Tools 23-27 May 1988, Ann Arbor, Michigan, Meta Systems Ltd. (1988)