This definition includes all kinds of computer-based support for any of the managerial, administrative, or technical aspects of any part of a software project.

What Is a CASE Tool?
Since the early days of writing software, there has been an awareness of the need for automated tools to help the software developer. Initially the concentration was on program support tools such as translators, compilers, assemblers, macro processors, and linkers and loaders. However, as computers became more powerful and the software that ran on them grew larger and more complex, the range of support tools began to expand. In particular, the use of interactive time-sharing systems for software development encouraged the development of program editors, debuggers, code analyzers, and program-pretty printers.

As computers became more reliable and in greater use, the need for a broader notion of software development became apparent. Software development came to be viewed as:

• A large-scale activity involving significant effort to establish requirements, design an appropriate solution, implement that solution, test the solution's correctness, and document the functionality of the final system.

• A long-term process producing software that requires enhancement through out its lifetime. The implications of this are that the structure of the software must enable new functionality to be added easily, and detailed records of the requirements, design, implementation, and testing of the system must be kept to aid maintainers of the software. In addition, multiple versions of all artifacts produced during a project must be maintained to facilitate group development of software systems.

• A group activity involving interaction among a number of people during each stage of its life. Groups of people must be able to cooperate, in a controlled manner, and have consistent views of the state of the project.

This view of "programming in the large" resulted in a wide range of support tools being developed. Initially, the tools were not very sophisticated in their support. However, two important advances had the effect of greatly improving the sophistication of these tools:

• Research in the area of software development processes gave rise to a number of software design methods (e.g., Jackson Structured Programming, the Yourdon Method) that could be used as the basis for software development. These methods were ideally suited to automated tool support in that they required step-by-step adherence to methods, had graphical notations associated with them, and produced a large number of artifacts (e.g., diagrams, annotations, and documentation) that needed to be recorded and maintained.

• .....personal workstations and personal computers. These machines have relatively large memory storage capacities, fast processors, and sophisticated bit-mapped graphics displays that are capable of displaying charts, graphical models, and diagrams.

We refer to all of the above tools as CASE tools and posit the following definition:

A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process.

Other authors have attempted to make finer-grained distinctions between differ ent classes of CASE tools along a number of dimensions. The most common distinctions are:

• Between those tools that are interactive in nature (such as a design method support tool) and those that are not (such as a compiler). The former class are sometimes called CASE tools, while the latter class are called development tools.

• Between those tools that support activities early in the life cycle of a soft ware project (such as requirements and design support tools) and those that are used later in the life cycle (such as compilers and test support tools). The former class are sometimes called front-end CASE tools, and the latter are called back-end CASE tools.

• Between those tools that are specific to a particular life-cycle step or domain (such as a requirements tool or a coding tool) and those that are common across a number of life-cycle steps or domains (such as a documentation tool or a configuration management tool). The former class are sometimes called vertical CASE tools, while the latter class are called horizontal CASE tools.

Unfortunately, all these distinctions are problematic. In the first case, it is difficult to give a simple and consistent definition of `interactive' that is meaningful. For example, some classes of compilers prompt the user for information. In the second and third cases, there is an assumption about the methods and approaches in use (e.g., object-oriented software development, or prototype-oriented development), hence our use of the broader, inclusive definition of a CASE tool.

What Is a CASE Environment?
The first generation of CASE tool developers concentrated to a large extent on the automation of isolated tasks such as document production, version control of source code, and design method support. While successes have been achieved in supporting such specific tasks, the need for these `islands of automation' to be connected has been clearly recognized by many first generation CASE tool users. For example, a typical development scenario requires that designs be closely related to their resultant source code, that they be consistently described in a set of documentation, and that all of these artifacts be under centralized version control. The tools that support the individual tasks of design, coding, documentation, and version control must be integrated if they are to support this kind of scenario effectively.

In fact, such tools are more often used as components in a much more elaborate software development support infrastructure that is available to software engineers. A typical CASE environment consists of a number of CASE tools operating on a common hardware and software platform. Also note that there are a number of different classes of users of a CASE environment. Some users, such as software developers and managers, wish to make use of CASE tools to support them in developing application systems and monitoring the progress of a project. On the other hand, tool integrators are responsible for ensuring that the tools operate on the software and hardware platform available, and the system administrator's role is to maintain and update the hardware and software platform itself.

Also note that software developers, tool integrators, and system administrators interact with multiple CASE tools and environment components that form the software and hardware platform of the CASE environment. It is these interactions, among the different CASE environment components and between users and those components, that are the key elements of a CASE environment. In many respects the approach toward the management, control, and support of these interactions distinguishes one CASE environment from another. We can define a CASE environment by emphasizing the importance of these interactions:

A CASE environment is a collection of CASE tools and other components together with an integration approach that supports most or all of the interactions that occur among the environment components, and between the users of the environment and the environment itself.

The critical part of this definition is that the interactions among environment components are supported within the environment. What distinguishes a CASE environment from a random amalgamation of CASE tools is that there is some thing that is provided in the environment that facilitates interaction of those tools. This `something' may be a physical mechanism such as a shared database or a message broadcast system, a conceptual notion such as a shared philosophy on tool architectures or common semantics about the objects the tools manipulate, or some combination of these things.

The range of possible ways of providing the `glue' that links CASE tools together inevitably leads to a spectrum of approaches to implementing a CASE environment. One of the main points we make in this book is that there are many ways to build a CASE environment. While many people concentrate on the selection of CASE tools and components when assembling a CASE environ ment, they largely ignore the need to support the interactions among those components. We concentrate less on which components should be chosen, and much more on how the selected components can be made to work together effectively. Whether a chosen approach to component interaction is appropriate in a given context will depend on many overlapping factors: the needs of the organization in question, the available resources, and so forth. A detailed assessment of these related factors and constraints is necessary to determine the CASE environment most suited to the problem at hand.