Modelling CASE Environments in Systems Development by Kalle Lyytinen Kari Smolander Veli-Pekka Tahvanainen ( University of Jyviiskylii Department of Computer Science Jyviiskylii, Finland ( Abstract Computer Aided Systems Engineering (CASE) envirorunents are pushed into market place daily. Novel features are being added to them, and the area is growing rapidly. However, we lack a more profound understanding of the relationhips between CASE envirorunents and systems development process in general. In this paper we try to make some preliminary steps to bridge this gap. We propose a general framework to analyze and explore systems development process. Using this • framework we define the concept of a CASE envirorunent and discuss its role and functions in systems development. Four aspects: organizational, communicational. technical and metalogical are formulated which can be used to identify the effects of CASE upon systems development. The idea of a CASE shell, a design envirorunent for the metalogical aspect and which can be used to "locate" and "program" CASE envirorunents in three other aspects is introduced. We notify 17 dimensions of modifiability in CASE envirorunents and show how these can be used to influence the use of a CASE envirorunents in communicational. organizational and technical aspects. Finally, some \ research issues raised by our study are discussed. Keywords: Metamodelling, CASE shells 1. Introduction Computer Aided Systems Engineering (CASE) is a booming activity in infonnation systems. Numerous CASE products are being marketed and new products are launched nearly daily. And, even more there are pro- grams that are sold as CASE environments, but which hardly can be considered such. The reneissance of CASE has created an expanding and rapidly growing research activity (cf Chikofsky 1988; Penedo et al 1988; Bubenko 1988; Lockemann & MayI' 1986). New research topics arc opened just as tool integration in CASE. CASE architectures. database interfaces and techniques associated with CASE, standards. CASE evo- lution, integration of knowledge representation techniques, or quality assurance methods in CASE. Surpris- ingly. there is no abundance of research concerning the concept and principles of CASE in relation to systems development in general. In this paper, we have set out on this topic. The general goal of this paper is to clarify the concept of a CASE environment, and to layout a framework to study their impacts on systems development. In particular. we want to explore how Ule modifiability of CASE environments achieved by the exploitation of CASE shells can ( be used to "reprogram" and "reorganize" system development processes for greater adaptability and produc- tivity. AIUlOugh most of the present work is concerned with CASE on a very general level, and alUlOugh we have deliberately avoided making any claims about what might be Ule scope of CASE, we are nevertheless mostly concerned with so-called upper case i.e. CASE in the early stages of systems development. ( The paper is organized as follows. First, we present a framework for modelling and metamodelling which has its roots in classic epistemology. Based on this we state some necessary conditions for a CASE environment, and discuss the differences between system development tools and a CASE environment. In Ule third section we present three aspects and one "meta-aspect" from which a sounder classification of CASE environments can be derived and which does not apply arbitrary groupings of some technical features found in CASE environments. The fourOl section discusses at some length possible and necessary features of a CASE shell. i.e. an environ- ment Um! can be used to generate customized CASE environments, and thus to "program" I Ule systems development process. We also show how these features arc related to Ule three aspects of CASE enviromnents presented. LasUy. some research implications are summarized: what should be the proper focus of CASE research in near future, and what problems need to be tackled in order to make most use of CASE environments and in particu- lar of CASE shells. 2. A conceptual framework for systems development In this scction we propose a conceptual franlework which helps to illuminate the nature of systems devclop- ment process. Basic concepts that clarify various elements and functions in systems development process are exposed. Then. we will use the framework to shed light on the role of a CASE enviromllent in a systems development process and suggest two criteria to define the concept CASE more accurately. 2.1. A model of Systems Development Generally speaking, systems development can be defined as an inquiry and change process that concerns a specific field of actioll called here a field of phellomella (Lyytinen 1987). This inquiry and change process is social in nature, i.e. it involves more than two people who may take part in this process in different roles. In order to explore the nature of Ulis process wc must distinguish Ulree fundamental domains of systems develop- ment: (I) the real world, i.e. the basic "stuff" of inquiry and change: organizations, dala, communications, I The word' 'program" docs not mcan that we would prefer a rigid approach to system developmellt, where every step is exactly prescribed and tll8t remains unchanged from one development situation to another. However, we do assume here, that all systems work exhibits some systematical pattern, although tllC particular tasks and thcir sequence may change from time 10 time. activities, computers, files and the like; (2) conceptualizations of the real world, i.e. organizational theories, theories of data and its modelling, or concepts used to understand and interpret the "rcality" , and (3) descrip- tiollS of these conceptualizations, i.e. representations of organizational activities, data flows, data structures, algorithms etc. In more detail we should distinguish between (figure I): • afield ofphenomena, i.e. a set of states of things in the real world, "reality". • a conceptllal strllcture, a model in the beholder's mind, which conditions and affects how the field of phenomena is conceived by him as certain objects, events and so on. • a level of abstraction, a level of granularity related to the conceptual structure. The level of abstraction determines which sorts of objects are constituted in the field of phenomena, and which parts therein are considered to be relevant in different stages of systems development. • a target system, which is formed from a part of the field of phenomena when seen through a pmticular ( conceptual structure on a particular level of abstraction. • a description language, a notation, in which the the target system is represented and communicated. The framework thus distinguishes between the "reality" of systems development (that is or will be analyzcd and changed), the developers' concepts and theories of it (conceptual structure), their "matching" as a particu- ( lar "target system", and various representations made out of the target system in description languages. Con- sider an inventory system. The field of phenomena consists of all possible things that can happen and take Concept structure I I I t-- ........ " Defines I f AbSlraClion: Field of \ ' \ I . } level I phenomena , , , I I \ \ \ . ( ' ,. ,-.,- ........' Descriptions Target system Prescriptions representations Instructions Machine Figure I. A Model of Systems Development 2 place in the inventory systcm. The conceptual structure is formed by the concepts and UleOlies Ule developers (systems analysts) have about the role of information systems in the inventory systems and all concepts that help to understand. explain and predict Ule behavior of the system. The conceptual structure is thus partly con- stituted by "methods" and "approaches" of systems development learned and used by systems analysts, partly by the knowledge they have about inventory systems and their role in organizational action. The target system is a particular "model" of an inventory system derived by the analyst when the conceptual structure is "matched" with the inventory control problem in a particular setting. Description languages are notations that the analysts use to represent the target system for analysis, communication and review such as a data flow model of the current inventory system. Although these clements are represented here as independent factors of a development situation, they in fact are not independent, and therefore each one of them must be understood only in relation to the oUler elements. The distinctions arc Ums not absolute. and Uley need to be made only when necessary. For example, Ule con- ceptual structure and the level of abstraction are mutually dependent, but neiUler of Ulem can be explained by and reduced to the other. One and the same conceptual structure can convey several levels of abstraction, and ( one and the same level of abstraction can be found in several different conceptual structures. For example, some data models can include conceptual structures of data on several levels of abstraction (storage dependent, and independent concepts). In the same vein, represcntations of target systems can be read on several levels of abstraction depending on which conceptual structure is being applied. For example. a piece of program code can be read as a represen- ( tation of scmiotie relationships (salary-field denotes to real salaries). as a representation of a fonnal expression (salary-field has five integers and two decimals), or as a model of computer memory assignment (a salary-field takes one word of the main memory). Finally, Ule same conceptual structure can be dressed into different description languages i.e. the same target system can have several semantically equivalent representations (see for example Venable & Truex 1988). 2.2. Description languages in system development The main focus and interest in systems development lies naturally in description languages as Uley make the conceptualizations of the field of phenomena shareable among the members of the development group. In oUler words. only through description languages systems development as social activity is possible. This obvi- ous conclusion becomes clear if we look at any book or research article on systems development. A majority of Ule literature discusscs new and better ways to describe the target systems. The other components of our framework help to wlderstand that the descriptions are of some field of phenomena and Ulat they arc based 011 some more or less explicit conceptualizations, "Uleories" , of the field of phenomena. Thc representations of target systems in description languages serve several important functions in systems development. First U1CY are a mealls of commullicatioll. Second, thcy are a means of allalysis, ullderstalldillg alld predictioll of the structure and behavior of Ule target systems. In oUlcr words, descriptions are instrumen- tal in inquiring Ule field of phenomena and obtaining knowledge of it and communicating this knowledge to othcr participants during U1C development process. Therefore. it is necessary to consider in more detail the types of communications and types of analysis Ulat take place in systems developmcnt. First, the communications can have eiUler a descriptive or prescriptive purposc. In brief, the representations of target systems can eiUler describe states of things as U1CY are here and now (or have becn in Ule past). or they can prescribe statcs of things Ulat are intcnded to takc placc in the future. (Onc might suggcst an intermediatc state. a description of a systcm to come. This could however be counted as a special case of description.) An examplc of representations having dcscriptive purpose is a representation of data flows in thc current systcm. An example of prescriptive representation is U1C logical data flow modcl of thc futllre systcm. Another dimcnsion in our analysis of communications is whethcr the communication takes place betIVcell peo- ple or betlVeell people alld compmers. In thc former case thc communication ciUlcr clarifics. or explains thc structure and behavior of U1C target sys- tcm. Somctimes U1C communications can also prcscribe behaviour of thc people taking part in the target sys- tem (uscrdocumcntation). In the lattcr case the communication is not communication in a true scnsc. it is 3 raUler a way of instructing the behaviors to the computer system (i.e. programming in Ule real machine- oriented meaning). In Ule inquiry mode (as opposed to the communication mode discussed above) Ule representations serve as a means to acquire, analyze and synthetize knowledge of a field of phenomena. This means that the representa- tions enable checking the validity of Ule knowledge obtained. Several levels of correctness can be dis- tinguished: the syntactic correctness. semantic consistency of the representations. Uleir correspondence with developer's intentions and desires. or their pragmatic usefulness in proposing changes into the field of phenomena. In practice, the representafions of a target system can be used in several types of communications and inquiry at Ule same time. For example. a piece of program source code may be considercd (I) to serve descriptive communications. as it describes the functioning of the computer as well as the infor- mation system at a (quite low) level of abstraction. (2) to serve prescriptive communications. in stating how Ule computer should work; (3) it may also be called an illStructive description from the human programmer to the computer; (4) it also serves to communicate information between people about the functioning of the system; and (5) finally. it may also be an object to study Ule syntactic and semantic correctness of the program (program ( verification) or to higlight Ule usefulness of the program to its users (aiUJOugh rarely). 2.3. The nature of system development process Using this framework as a starting point we can now interpret Ule design process as an inquiry and change pro- cess that involves matching of conceptual structures with Ule field of phenomena for the purpose of description I and prescription (concerning both human beings and computers). It is an inquiry to the extent it involves the matching of the conceptual structures (interpreting a set of observations Ulrough a theory) WiUl a field of phenomena to yield a set of target systems and their representations in a host of description languages Ulat can be communicated, analyzed, and manipulated by a group of people involved in the development process. It is a change process to the extent it involves the matching of a conceptual structure WiUl a field of phenomena to generate a new field of phenomena and communicating, analyzing and manipulating Ulese phenomena UJrough prescriptive representations. Usually the description (or a systematic pattem followcd by developcrs) of how thc matching takes place and how the descriptions are derived is called a method. 2 When a method is supportcd by some instrumcnt (a template. a questionnaire. or a computer program) this is called a development tool. 3 Representations of target systems in systems development (both in the descriptive and prescriptive sense) can be an object of a high variety of activities. Representations can be: produced, automatically or by hand. ( ) trallSformed. e.g. from a level of abstraction to anoUler (by people or by computer). maintained. i.e. when minor changes are made to them by people. approved or inspected by a group of people. managed; i.e. named. ordered, accessed. sccured. or subjected to version control, translated, e.g. from one description language to anoUler. A systems development process forms thus a sequence of (partly) paralIcI activities whcre each activity takcs some representations of target systcms as an input and produces new representations of target systems as an 1 We do not want to make here a distinction between 8 method and a tcclmique as is sometimes done. In our opinion, the concepts of "rnclltoo" • "tcchnique" and "methodology" arc so hopelessly blurred that clear distinctions between tllcm arc very difficult to make and to discuss them here any further would be beside tJ\C point. J For example, slnlcturcd analysis involves a conceptual structure (consisting or conceplS like data now, store etc.), a description language (graphical symbols and syntax) that are "matched" with some application domain (a field of phenomena). The method of SA involves in what sequence the representations are derived (current physical system model, logical model etc). TIlC tools of SA would include tcmplates, an editor to write down and edit lexts (minispccs), or a CASE tool to draw SA diagrams and to store them. 4 output. Improvements in systems development can be achieved in at least three ways: (I) by deciding on which target systems are selected (for description and prescription) and how Uley are represented (a question of methods). (2) by affecting in what sequence and in what organizational form different sorts of activities (i.e. taking different representations as input and producing different representations as outputs) should be carried out (me question of phase models and project organization). (3) and by adopting new facilities into use to carry out such activities (me question of tools). As Ulese improvements are highly intcrdependent, a more encompassing notion of systems developmelll met/w- dology (SOM) has emerged. Though no satisfactory and wholly accepted notion of systems development memodology exisl, we can define a systems development meUlOdology as an orgallized collectioll of cOllcep- t/wl structures, descriptioll lallguages, activities. prescriptiollS for pallerllS of activities, orgallizatiollal fOT/IIS, alldfillally facilities that help to carry out activities. The purpose of a SOM is to help Ule development group to inquire and change some field of phenomena, mat is to perceive, generate, assess, control and carry out change actions in a set of target systems. Using me ftameworkjust presented we can more easily grasp Ule concept of a CASE environment. In brief, a CASE environment "implements" a specific SOM in a computer supported and readable form. A CASE ( environment is a generic facility mat supports several activities mat take target system representations as inputs and produces oUler types of target system reprensentations as outputs according to a SOM. 4 The phrase "implemellls" a specific SOM is here essential. It implies mat not any type of computer implemented activity mat deals WiUl target system descriptions forms a CASE environment (consider using a text-processor). More specific requirements can be derived from me phrase' 'implements a SOM" This will be discussed next. 3. Some steps towards a more precise definition of CASE Formal definitions of a CASE concept abound in Ule literature (Chikofsky 1988; Bubenko 1988; Penedo et al 1988). We are not striving here for a formal definition. Instead, our model of systems development hclps to suggest some clear criteria which a CASE cnvironment must satisfy. In oUler words we will providc two necessary and sufficicnt features, for a "true" CASE system. First, a CASE environment must implemcnt several conceptual structures. s This requircment is necessary. if ( me cnvironment is to support any memodology (SOM) at all, because all methodologies contain in a more or less explicit form a multitude of conceptual structures to describe. interpret and prescribe a field of phenomena. 6 This means mat Ule CASE envirorunent should encapsulate some "knowledge" of how descrip- tion languages are used and how to derive target system representations in Ulem and what criteria detetmine Uleir validity. This requirement distinguishes CASE environments from drawing programs or text fonnallcrs Ulat do not have any conceptual structure behind meir use i.e. Uley just help to draw some figures which can • Note that this is 8 very broad' 'definition" and could include for example reverse engineering and automatic programming. .s We think that this criterion to support several conceptual structures distinguishes CASE environments from CASE tools that provide often quite comprehensive support for a particular method. 6 There arc several different ways how conceptual structures in a SOM can be connected. The most usual situation is, that no conceptual structure is disjoint from the other conceptual structures i.e. that each conceptual structure has at least one common concept with some other conceptual structure. A more stringent requirement is Lhat all conceptual structures have at least one common concept. Usually this situation prevails with conceptual structures on the same level of abstraction (cf different steps in SA, which all use the concept of process). In some other occasion conceptual structures on different levels of abstraction can have one or a set of common concepts by which they are connected. The concept of concept sharing corresponds in systems development process a subsetting of target system representations by similarity. Another way to connect conceptual structurc.~ is to provide mapping mechanisms by which a concept is mapped onto a set (or a powerset of) conceptual structures (cf a mapping of an ERA-schema into a relational schema). The concept of concept mapping corresponds in a systems development process a transformation by some tool from one target system rcrcsentation to another target system representation. 5 not be further interpreted by programs. When this criterion is used it is also questionable, whether a 4GL can be considered a CASE environment, because their primary focus is instructing (programming) the computer (though on a quite high level). A stronger requirement is, whether the CASE environment can be customized to new and different conceptual structures, or variations of one conceptual structure. This makcs CASE environments modifiable, a feature of CASE shells, as we shall show in section 5. Secolld, a CASE environment should embrace several levels of abstraction and transitions between them. Thus, if the CASE environment implements conceptual structures and description languages that all belong to one level of abstraction, it is not a true CASE environment. In this situation, the environment docs not support the inquiry and the change process as it moves from one abstraction level to another e.g. from more organiza- tion oriented conceptual structures to more machine oriented ones. This becomes perhaps more understand- able, if one thinks that a level of abstraction often coincides with a definite phase of the systems development process. So, for example, target system descriptions during the requirement specification phase and the source code (Dart et al. 1987) (descriptions of computer behaviors) both describe the system at distinct Icvels of abstraction. This requirements threatens the status of integrated programming support environments (IPSE) ( qua CASE environments, because they usually help to produce and maintain the source code. However, if an IPSE does produce or make use of higher-level reprcsentations and provides functions for their maintenance it should be considered a "true" CASE environment. All in all, to reiterate the two requirements for a CASE environment are: ( (I) it has to embed several conceptual structures and descriptions languages embedded in a SDM, and (2) it has to support several levels of abstraction at which the development process takes place and sUpp0l1 activities that concern target system representations on tilatlevel. Clearly, these two criteria form a minimum, and more restrictive conditions can be proposed. However, even with tilese two conditions several tools marketed as CASE environments can be left outside tile field of CASE. More restrictive criteria that can be considered are the following: (I) Does tile environment support only production and maintenance of target system representations that describe or prescribe for human beings i.e. is it a mere analysis and design tool, or docs it also generate I instructions or parts of instructions to the computer i.e. does it involve back-end functions? (2) Does the environment implement and maintain a model of a necessary pattern of activities to be canied out during the development process, i.e. does it have a representation of actitivities and tileir relation- ships (phase model) that can be used to guide and monitor the development process? (3) Does the environment implement and maintain a model of tile organizational fornl of the development process i.e. does it model a set of roles and their relationships to activities so tilat it can be used to guide, coordinate and monitor various activities during the development process? (4) What sorts of activities related to target system representations does tile environment support in addition to producing and maintaining them? Does the environment support tranfonnation, translation, and review activities? How well can it support the management of various versions of representations, define access controls, and order tilem in different ways? (5) Does the environment make use of existing descriptions and implementations? Does it have e.g. reverse engineering or code reuse facilities? (Of course, not only program code but various other fonns of descriptions can be reused. (E.g. cf. Madhavi et aI., 1985.)) Each of tilese defines a new aspect that must be considered if a CASE environment is to support wholly a specific SDM. 4. How to classify CASE tools There are several perspectives which can be used to analyze CASE environments (in other words there are ailernative conceptual structures to interpret tile field of CASE). These perspcctives suggest ailemative ways to classify CASE environments as tiley select a different set of properties which can be used as a basis for 6 classification. For example. one can choose a single property or a set of technical features in a CASE environ- ment. A single property could be the type of description language implemented by the CASE environment (graphica1/linear). A set of technical features could be operating systems where it can be run. type of the DBMS embedded in the CASE environment. programming language interfaces. 4 GL interfaces. data dic- tionaries supported etc. Although these classifications are useful (e.g. Dart et al. 1987). especially when acquiring a CASE environment, their problem is that they lack a more profound theoretical foundation and produce quite haphazard classifications. Moreover. a great number of single properties and features can be enumerated leading to a cumbersome and unstructured taxonomy which often obscures the essential differ- ences between various CASE environments. We believe that a more fruitful way is to view CASE enviromnents as to form an integral part within a larger infonnation systems development environment. In this approach a CASE environment is not conceived solely as a technical object with clearly identifiable technical features. Instead. we focus on the functions and role of a CASE environment in systems development. i.e. how it helps to represent target systems and to communi- cate these representations to various stakeholders during the development process and how it helps to carry out various inquiring activities. The "help" implies here that the environment makes system development activi- ties easier to carry out and/or that their outcomes have higher quality (less errors, more efficient prescriptions. easier to modify the descriptions etc). In addition, a CASE environment can be used to monitor and manage the development activities and to keep track of the consumption of scarce organizational resources. Our framework of systems development illustrates that the classification of CASE environments is a multi- ( dimensional problem. It is not possible to divide CASE environments into some distinct (disjoint and exhaus- tive) classes and say, for example, that there are five kinds of CASE environments. Instead, we are obliged to think of a rich variety of aspects of information systems development and how they relate to the use of CASE environments. In the following, four aspects are defined which we believe, are essential in classifying the use of CASE environments in different systems development situations. These are: a communicational. an organi- zational, a technical. and a metalogical aspect. 4.1. The communicational aspect In the communicational aspect the central issue is the exchange of target system represemations among the developers (including end-users' representatives). The communicational aspect focuses on the type and inten- sity of communications during systems development i.e. how and what types of target system representations are shared by the members of the development group (or others concerned). The major purpose in the com- municational aspect is to understand how the developers can attain a common understanding of the relevant target systems and their behaviors. To analyze the communicational aspect in more depth three subdimensions can be applied (fig. 2). These are: supportcd activities, type of users, and mode of communication. Each par- ticular CASE environment can be situated somewhere in the space fOrmed by these three dimensions. Supported activities are those systems development activities which are supported by a CASE environment. The activitics subdimension covers the following issues: • which activities are supported: creation, transformation, management, review. or translation of represen- talions; and • in which phase (activity sequence) of the systems development process. The type of users subdimension delineates two issues. First, a CASE envirorunent can support communica- tions between several users simultaenously, or it can be used only by one user. In tile latter situation tile envirorunent can support merely inquiry tilat relates to an individual analyst's or end-user's activity. Second, a CASE environment can distinguish between several types of users i.e. different roles adopted during the development process. Typical roles arc a manager, a project leader, an analyst, and an end-user? If user-to- user communications arc allowed they can take place wiUlin users acting in the same role or between users having a different role. 7 We usc here the term "end-user" to differentiate betwccn CASE users and users of lhe information system (end-users). 7 Type of Users Supported )--------t~~ Activities ( Mode of / Communication Figure 2. Dimensions of the Communicational Aspect ( The mode of commullicatioll subdimension illustrates communication forms and structure. The communica- tions can in one extreme support several forms of communication ranging from visual forms (pictures etc.) and textual communication upto oral communications. In the other extreme the communication form is fixed only to one (usually textual communication). Another aspect is that communication can be highly structured or it can have a more free-form structure. An example of highly-structured communications are communications through a common description (data) base where the communication takes place through updating and query- ing a shared description base. An example of free-form communication is the electronic mail. Semi-formal communications that are situated in-between these two extremes are also possible (such as prestructured proto'l cols for a set of dialogues). 4.2. The organizational aspect In the organizational aspect, the central focus is in cOll/rol. TIle aspect delineates those qualities of CASE environments by which it is possible to manage and control systems development process. Since the use of a CASE environment always takes place in an organization, Ole nature of Ole CASE environment (whether it is imended for one or multiple users) has litOe influence on Olis aspect. Three subdimensions under OIC organiza- tional aspect can be noted (figure 3). The first dimension, cOll/rollperjormallce. defines the primary organizational strategy to use a CASE environ- ment: to which amount it is used to control the development process, and to which extent it is applied to carry out Ole actual systems development activities. TIlis distinction is clearly visible for exanlple in tools Olat help to carry out analysis and design tasks, and those that are used for project managcmcnt purposes. The second dimension, compellillg/volitiollal. tells how a CASE environment guides analysts' or oOler developers' work. A CASE environment can force a devcloper to act stricOy in a predefined way or it can givc him morc freedom so Olat he or she can use methods being supported in ways he or she sccs as best fitting to the situation. For example, some environments state a strict sequence of stcps in which the targct system representation is to be derived (considcr some SA-based tools), or the represcntation order is totally free (e.g. PSL/PSA). The third dimension, lJierarclJicall/ateral, defincs how the use of a CASE environmcm is organizcd. If Ole organizational environmcnt is hicrarchical. a set of rolcs is assumcd which have clcarly dcfined command, authority, and reporting relationships. In this situation the communication flows either upwards or downwards in a hierarchy. Typical examples of hierarchical communication modcls arc projcct managcmcnt models. which can state sevcral hierarchicallaycrs of control. In a latcral organizational situation OIC flow of communi- cation is horizomal, and oftcn volitional and it docs not prcsuppose a hicrarchical comnHlIld structurc. 8 Compelling! Volitional Control/ Perfonnance Hierarchical/ Lateral Figure 3. Dimensions of the Organizational Aspect 4.3. The technical aspect ( The technical aspect suggests in all likelihood the most straightforward and common way to classify CASE environments. This aspect focuses on features that affect how systems developmelll is carried alit and what activities must necessarily take place. The subdimensions under the technical aspect are the following: design principles, the level of abstraction, the application area, and the interface (fig. 4). The first dimension, the design principles focuses on generic stucturing mechanisms to relate conceptual struc- tures in different methods together. Usually each CASE environment applies some generic design principle to connect different target system representations and to ease the move from one to another. Examples of typical design principles are data-centered or process-centered design principles. Some CASE environments can even support several desing principles simultaneously, or mix them. The level of abstraction concerns UlOse abstraction levels Umt are being supported in Ule CASE environment. The scope of abstraction in a CASE environment may range from overall design (a high-level abstraction) to machine-oriented design (a low-level abstraction). Several levels are supposed to be covered by a CASE environment (cf. LockemaIUl & Mayr 1986). Level of Abstraction \ Interface Design Design Principle Application Area Figure 4. Dimensions of the Technical Aspect 9 The applicatioll area discloses the types of target systems for which the CASE environment can be used. Examples of application areas are embedded systems, officc systems, expert systems etc. Each application usually requires some specialized conceptual structures to be adopted that help inquiry and problem-solving acitivities in that specific field of phenomena. Examples of such specific conceptual structures are dynamie aspects, concurrency and communication mechanisms in embedded systems, different types of data, excep- tions, and distributed nature of applications in office systems and so forth. The illteiface desigll determines the visible features of the CASE environment. The subdimensions of Ule inter- face design are: interaction mode (interactive, batch), interaction style (command language, menu-driven, icon-based), and functionality (facilities for query and report generation, programming tools) (cf. Dart et aI. 1987). It is clear that the technical aspects of a CASE environment are closely related to thosc conceptual structures and description languages that have been chosen as a basis to develop Ule CASE environment. This leads us to the next aspect which is mainly interested in how CASE environments and conceptual structures can be fitted together i.e. the metalogical aspect. ( 4.4. The metalogical aspect One can consider the metalogical aspect as a meta-aspect for all the previous aspects, i.e. Umse aspects that ( affect how the CASE environment is used in system development situations, which activities are being sup- ported, how the development group is organized and so forth. 'TIle metalogical aspect Ums concems the "second order" analysis, design and change of system development situations by "programming" the CASE environment. The metalogical aspect focuses on how a CASE environmcnt and a chosen particular conceptual structure can be made logically consistent so that Ule CASE environment can serve to develop target system representations, analyze and communicate them in some preconceived manner that corresponds to the chosen conceptual structure. In general, the metalogical aspect defines how easily a CASE environment can be cus- tomized along the three aspects (and their subdimensions) so Ulat it can better satisfy the developer's desires and needs. If a CASE environment can be extensively customized in all three aspects the developers can by themselves locate the CASE cnvironment in all three oUler dimensions. If Um modification is possible in several aspects we can talk about CASE shells i.e. environments that help to customize CASE environments to support an arbitrary methodology or to add a new mcUlod to the existing collection of methods. Usually these methods have some common parts in Uleir conceptual structure. A general research question in the metalogical aspect is what levels of customization are possible and what customization strategies are useful in different situations? This points out the need to consider in more detail the concept of CASE shells and different levels of customization achieved by them. This will be clarified in Ule next section. 5. CASE shell environments A key issue in the metalogical aspect is the ability to create CASE shells 8 i.e. programs, that generate CASE environments WiUI specific features. We shall now examine Um concept of CASE shells more closely and take a take fresh look how they are relate to UIC framework we have presented above. Most currenUy marketed CASE cnvironments support only a rigid set of conceptual structures and therefore do not qualify as CASE shells. However, it is quite common Ulat they offer some functionality that is typical for CASE shells. One typieal feature offered is that the notation used to represent Ule chosen target system is cus- tomizable, so that different symbols are permittcd ( "boxological sugar"). In this case the customization con- cerns only the technical aspect, and thercin only Ule interface dcsign (interaction form). To distinguish CASE shells more clearly from CASE environments a more Umrough analysis is needed. STIte term 'CASE shell' was coined by Dubcnko (1988), who intended it to be lIsed in a similar manner as when talking about an expert system shell. TIlcrcrorc, the term 'shell' here should not be mixed with e.g. an alternative command interpreter. Possible synonyms would be a 'CASE environment generator' or a 'McLhodology Engineering Envlrorunclll' (d. Kumar & Welke, 1988). 10 5.1. Three dimensions of the concept CASE shell In principle, we can distinguish thrcc components of a CASE environment that can be changed. These three comp