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.
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
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.
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
AbSlraClion: fField of \ ., ,I } level I phenomena , ,.
I
system representations
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
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 ( ( 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) (2) (3) (4) (5) to serve descriptive communications. as it describes the functioning of the computer as well as the information system at a (quite low) level of abstraction. to serve prescriptive communications. in stating how Ule computer should work; it may also be called an illStructive description from the human programmer to the computer; it also serves to communicate information between people about the functioning of the system; and 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).
Using this framework as a starting point we can now interpret Ule design process as an inquiry and change process that involves matching of conceptual structures with Ule field of phenomena for the purpose of description matching of the conceptual structures (interpreting a set of observations Ulrough a theory) WiUl a field of I and prescription (concerning both human beings and computers). It is an inquiry to the extent it involves the 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. output. (I) (2) Improvements in systems development can be achieved in at least three ways: by deciding on which target systems are selected (for description and prescription) and how Uley are represented (a question of methods). 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 o f CASE
Formal definitions of a CASE concept abound in Ule literature
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 description 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. ( ( 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
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) (2) (3) (4) (5)
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
instructions or parts of instructions to the computer i.e. does it involve back-end functions?
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?
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?
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?
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.
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 multidimensional problem. It is not possible to divide CASE environments into some distinct (disjoint and exhaustive) 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 representalions; 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.
( Type of Users )--------t~~ Supported
Activities ( (
Mode of / Communication The mode of commullicatioll subdimension illustrates communication forms and structure. The communications 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 querying 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 p r o t o ' 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. Compelling!
Volitional Interface
Design Application
Area
Level of
Abstraction Hierarchical/
Lateral 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
Design Principle
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)
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.
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'
In a "conventional" CASE environment the conceptual structures are fixed and therefore they can at most sup
port syntactic extension and partial notational variation. lt may, of course, allow some variation in notations.
Obviously, a CASE environment that also serves as a CASE shell must permit to change its underlying con
ceptual structures. There are different approaches to achieve this. EiUler, the shell docs not convey any fixcd
conceptual structures, but instead provides only a set of primitivc tools from which more elaborated conceptual
structures can be built (i.e. a sct of conceptual constructor operators). In Ulis situation the dClivcd conceptual
structures and description languages in Ule CASE cnvironmcnt are unrelatcd to U1C primitives found on Ule
CASE shelllevcl. Or, there is somc basic sct of conceptual structures, from which Ule various concept struc
tures are derived (i.e. the conceptual structure being "transfonned" is mapped onto conceptual structures pro
vided by the CASE shell). In this case the conceptual structures on the level of CASE shell and on the level of
CASE environment are related by subsetting and mapping operators. An example of this approach is SEM that
is based on PSL
The functions component of a CASE shell'must therefore render several types of modifications into functional ity of the CASE environment. At least the following types of modifications can be distinguished: a query definition facility determines to what extent the environment enables extracting descriptions from a description base under different conditions and formats; a report definition facility defines to what extent the environment suppo11S specification and execution of report specifications that are derived from the description base; an inference definition facility defines to what extent and what types of inferences the environments enables to make on extracted descriptions; a storage definition facility defines to what extent and what types of descriptions (type, fonnat) can be stored in the description base and how their connections can be implemented and managed; a usage definition facility defines to what extent and what types of uses of the environment can be described, supported and coordinated by the environment.
The first four facilities together are instrumental in modifying support provided by the CASE environnlent in such tasks as consistency checking, verifying correctness of descriptions, or design aid. They are also needed in specifying customized documentation for different groups of IS uscrs. Finally, they are necessary, if thc environment is to enforce systematic application of methods i.e. to derive target system representations in a step-by-step manner, or to transform target system representations from one representation to anotiler using heuristic or algorithmic techniques. The inference definition facility may also be needed in defining and sup porting ways to use the descriptions to derive solutions to encountered design problems (use of heuristics and knowledge representation schemes). control and management, requirements tracking mechanisms, or specification of responsible persons to main- I Storage definition facilities ease modification of such important functions of a CASE environment as version tain and approve target system reprentations (review and control management).
Usage definition facility can be uscd to configure such features of the CASE environment as access rights, access control or guidance mechanisms to use the environment in different situations. The usage definition facility determines also the style and mode of interaction. 5.1.3. The mechanism component of a CASE shell The mechanism component of a CASE shell is needed to configure the CASE envirorunent using different sys tems components including the underlying DBMS, target DBMSs, interfaced data dictionaries, 4GL's, com munication protocols etc. The scope of modifiability in this component defines the openness and poI1ability of the CASE envirorunent. Thus, the mechanism component defines the internal and external interfaces by which the functions and support of the environment are provided. Several types of mechanisms can be distinguished: Export/Import definition mechanisms define the extent and ease by which target system representa tions can be exported from the environment or imported into the environment. In otiler words, to what extent can the enviromnent be easily interfaced with otiler components of an IS resource management environment. Typical components of such an envirorunent are: data dictionaries (e.g. IRDS), data base management systems (e.g. SQL), otiler CASE enviromnents, text processing systems (ODA, DCA, Ven tura), application generators, or source code control systems.
Data Management Definition Mechanisms define tile extent and ease by which the target systems represcntations can be stored and managed in different data base management systcms i.e. the portability of the CASE environment over different DBMS.
Interface Definition Mechanisms define the extent and ease by which the interface dcsign of the environment can be adopted into different interface standards (prcscntation Managcr, X-Windows, tenni nal compatibility); Data Communication Definition Mechanisms define tile extent to which the environment supports various data communication protocols (TCP/IP, OSI, XAOO) etc. Operating System Interface Mechanisms define UlC extent to which Ule environment can be run under diffcrent operating systems (OS/2, UNIX).
The distinguished UJreC components of a CASE shell make possible a metalogical design of a rich variety of CASE environments. Depending on the degree of modifiability provided by the CASE shell, different aspects of CASE environments can be changed, and "programmed" To obtain a more refined picture of the depth and scope of Ule "programmability" of CASE environments we shall analyze in more detail Ule degree of modifiability of CASE shells. Results of this analysis are depicted in tables I, 2, and 3. The tables show how a subcomponent of a CASE shell (rows) can be used to "design" different aspects of a CASE envil'Onment and its usc (columns). Table I illustrates the relationship for the linguistic component, table 2 for Ule functions componcnt, and table 3 for the mechanisms component, respectively.
When we study the tables we can note the following. The level of modifiability provided by existing CASE
environments such as notational variation, and notational modifiability are not powerful enough to allow for
real "design" of the CASE environment. The possibility to extend the description languages used, and espe
cially facilities to define new languages, and to specify translations from one language to another are here
essential. Only these components can help to generate a sufficienUy flexible envirorunent, i.e. to change
design principles, to cover several (or new) levels of abstraction, to adopt Ule environment to new application
areas, and Ulereby also to affect Ule interface of the CASE environment; all requirements Ulat are needed to
have a complete development environment modifiability
When we study the functions component, we can see Utat the modifiability of Ule structure component must be supplemented with a powerful and flexible CASE "programming" environment. This environment must offer query and report specification facilities. Moreover, the inference facility must implement in addition to com mon arithunetic operators also logical inference and other inference mechanisms (rule-based environments)
Activities Users Communication Perfonnance Volitional Lateral Principle Abstraction Area Design + + + + employed in knowledge based systems. Only in this way can the scope of supported activities be extended to include new organizational aspects, and to encapsulate technical aspects such as more effective design princi ples for adoption to different application areas. Finally, only in this way can the interface design be flexibly configured and designed.
The mechanism aspect is obviously the least important in generating a rich variety of different types of CASE environments. Its key purpose is to serve as a platform for portability and openness (which are important technical and economic concerns). For example the data communication protocols supported by the CASE environment can be decisive in defining the scope and type of communications that can take place through the CASE enviromnent. 6. Research Implications The framework presented above poses several interesting research questions. Here we shall discuss some of Ulem in a preliminary fashion. A more detailed analysis of Ule research implications must be done in papers to come. The following two research issues will be treated: Ule currelll focus in the CASE research, and Ule role of CASE shells in the CASE research. 6.1. The focus of the CASE research In our opinion, currelll CASE research is often too narrowly focused. Many of the current research projects concentrate on a single technical feature of the CASE environments such as a desirable architecture, user inter face, application of knowledge representation techniques, object-based management techniques and so forth. What we lack is a UlOrough understanding of how these well motivated teclmical advances can improve the state of art in systems development. To achieve Ulis we need more Uleoretical and empirical studies on the nature of systems development and how CASE enviromnents can affect it. In Ulis paper we have made some initial steps in Utis direction by showing that CASE environments arc to be looked upon from a wider perspec tive which includes:
Organizational aspects i.e. organizational fornls recognized and supported by the CASE environment;
Communicational aspects i.e. type and intensity of interactions that are needed in systems development among different developers and how these are changed and supported by the CASE envirolllllent; Technical aspects i.e. what target system representations, in what role (descriptive/prescriptive/instructive), and on what levels of abstraction are supported; and what is the ease and type of use offered by the environment for these descriptions.
A ease in point is that the introduction of CASE envirolllllents will have a substantial effect in all three aspects,
whereas the research in the past has mainly focused on the last one. Examples of effects that may result from
introducing a CASE environment are:
new organizational forms and strategies for systems development including building up a new distri
buted physical envirolllllent for system development, enhanced use of physical capabilities such as
video-technologies, decision rooms etc (Ule organizational aspect);
new modes and types of interactions for systems development which include automatic dialogue
protocols for review, aceeptanee and decision-making, enhanced communication capabilities within Ihe
development group (semi-structured e-mail), or ease of communicating through a shared description base
(the communicational aspect);
new target system representations and their manipulation to enhance creative and skillful systems
development. This includes the ease of deriving new versions of target system descriptions, the ease of
their verification and validitation, and tutorial support in using various meUlOds (the technical aspect).
Very little is known of Ulese effects and Uley have been scarcely studied. The most researched area seems
currently to be Ule lasl one, though mOSI of the results obtained are not outcomes of a substantial and sys
tematic scientific study
CASE environments offer a promise for "programming" the system development process in a truly different way than achieved by proposing a methodology that does not have any computer support. As not all systems development is similar, Ulere is a continual need for adjusunent and "reprogramming" the CASE ( ( ( environment. Therefore, the concept of a CASE shell seems to be very central in adjusting and "reprogram ming" Ule systems development process. The discussion of the different components of a CASE shell pro vides a starting point to examine in more detail the scope and depth of "reprogramming" offered by various environments. Several observations can be made: an extensive modifiability of description languages is needed if one wants to affect in a deep sense the technical, organizational and communicational aspects of the CASE environment. the CASE shell must provide means to change the functionality of the CASE environment i.e. it must offer high-level constructs to program the CASE environment.
Thus, the functionality and the linguistic power of CASE shells are essential if any deeper variability in CASE
environments is hoped for. We believe also, that this is what we urgenUy need, as Ule majority of Ule methods
Ulat are supported by CASE environments have been inherited from the 70's (including structured methods,
ERA-modelling etc.). Yet, their usability and support in developing new types of applications (e.g. office
infoffilation systems) may be inadequate. This necessitates that new methods should be easy to integrate into
the existing environments and it should also be easy to build tools to support their use.
Acknowledgements Thanks to Heinz Klein, Pasi Kuvaja and (especially) John Venable for useful comments on the /irst version of this paper.
Bubcnko, Janis A., Selecting a strategy for computer-aided software engineering (CASE), SYSLAB University of Stockllolm, Stockholm (June 1988).
Chikofsky, Elliot J., "Software Technology People," IEEE Software, pp. 8-10 (March 1988). (