With a toolkit, developers are supported by a rather loosely-coupled collection of tools, each of which serves a specific, well-defined, task. The analogy with a carpenter is obvious. His toolkit contains hammers, screwdrivers, a saw, and so on. These tools each serve a specific task. However, they are not 'integrated' in the way a drill and its attachments are.

The prime example of a toolkit environment is UNIX. UNIX may be viewed as a general support environment, not aimed at one specific programming language, development method, or process model. UNIX offers a number of very convenient, yet very simple, building blocks with which more complicated things can be realized (Kernighan and Mashey, 1981):

In this way, users are led to try to reach their goals by gluing existing components together, rather than writing a program from scratch. A disadvantage of UNIX is that there is little consistency in interfaces and the choice of command names. For different programs, the '-k' option, say, may well mean something rather different. To stop a dialog, you may try kill, stop, quit, end, leave, and a few others. If you get tired, CTRL-C is likely to work too.

The average UNIX user knows only a fairly limited subset of the available commands and tools (Fischer, 1986). It is quite likely that, after a while, a workable set of commands will be known and used, and then the learning process stops. Inevitably, the facilities offered under UNIX are far from optimally used.

In UNIX, the different tools have minimal knowledge of the objects they manipulate. Various integrated and process-centered environments have been built on top of UNIX. They make use of the attractive features of UNIX, but try to overcome its disadvantages by imposing more structure.

Besides tools that support the individual programmer, UNIX also offers support for programming-in-the-large, through configuration management and system build facilities such as SCCS and Make. These are discussed in Section 15.3.2.

Nowadays, most software is developed interactively, changes are made interactively, and programs are tested and executed interactively. Much research in the area of language-centered environments is aimed at developing a collection of useful, user-friendly, effective tools for this type of activity. Since most of these environments focus on supporting programming tasks, this type of environment is often called a programming environment. To emphasize their graphic capabilities to manipulate program constructs, they are sometimes called visual programming environments.

Environments that are built around a specific programming language exploit the fact that a program entails more than a mere sequence of characters. Programs have a clear structure. This structure can be used to make the editing process more effective, to handle debugging in a structured way, and so on. Knowledge of properties of the objects to be manipulated can be built into the tools and subsequently used by these tools. Well-known early examples of language-centered environments are Interlisp and the Smalltalk-80 environment.

Present-day language-centered environments generally come with a host of components that considerably ease software development. Examples of such environments include Microsoft Studio .NET and Eclipse. The support offered ranges from a set of APIs for generating user interfaces (such as Swing), to facilities for handling persistence (EJB) or creating Web applications (Ajax). The richness of features comes with a price: a rather long learning curve.

This section is devoted to CASE products that support (parts of) the software development process. Depending on the scope of the set of tools available, such an environment is called an Analyst WorkBench (AWB), a Programmer WorkBench (PWB), a Management WorkBench (MWB), or an Integrated Project Support Environment (IPSE); see also Figure 15.1. The acronym CASE (Computer-Aided Software Engineering) is often used to indicate any type of tool support in the software development process. The qualified terms Upper CASE and Lower CASE refer to tool support during the analysis-design and implementation-test phases, respectively.

Figure 15.1. Scope of tool sets

In the ideal case, the choice of a specific set of tools will be made as follows. First, a certain approach to the software development process is selected. Next, techniques are selected that support the various phases in that development process. As a last step, tools are selected that support those techniques. Some steps in the development process may not be supported by well-defined techniques. Some techniques may not be supported by tools. Thus, a typical development environment will have a pyramid shape as in Figure 15.2.

In practice, we often find the reverse conical form: a barely developed model of the development process, few well-defined techniques, and a lot of tools. In this situation, the benefits of the tools are limited at best. To paraphrase the situation: for many a CASE, there is a lot of computer-aided and precious little software engineering.

Figure 15.2. Support in a typical development environment

Programmer WorkBenches

A programmer workbench consists of a set of tools to support the implementation and test phases of software development. The term originated in the UNIX world (Dolotta et al., 1978). The support offered by UNIX mainly concerns these types of activity. Many programming environments constructed around a certain programming language also support these phases in particular. In a PWB, we find tools to support, among others:

• editing and analysis of programs;

• debugging;

• generation of test data;

• simulation;

• test coverage determination.

The tools that support teamwork on large projects deserve our special attention. In a typical environment, a group of programmers will be working on the same system. The system will have many components, developed, tested, and changed by different people. During the evolution of the system, different versions of components will result. Automatic support for the control of such a set of components, both technically and organizationally, is a sheer necessity.

One of the early systems for configuration control is the source code control system (SCCS), originally developed for IBM OS and best known from UNIX. SCCS enables the user to keep track of modifications in files (which may contain such diverse things as program code, documentation, or test sets). The system enables the user to generate any version of the system. New versions can be generated without old versions being lost. Important aspects of SCCS are:

• no separate copies of versions are kept: only the modifications (so-called deltas) to previous versions are stored;

• access to files is protected: only authorized users can make changes;

• each file is identified by author, version number, and date and time of modification;

• the system asks the user for information on the reason for a change, which change was made, where, and by whom.

Figure 15.3 illustrates the main operations provided by SCCS. Within SCCS, all information is kept in s-files. The operation create creates the s-file for the first time. If the original file is named prog, then the SCCS file is named s.prog. The operation get yields a read-only copy of the file requested. This read-only copy can be used for compiling, printing, and so on. It is not intended to be edited. The operation edit retrieves a copy to be edited. SCCS takes care of protection in the sense that only one person can be editing a file at one time. Finally, the delta operation stores the revised version of the file edited.

Versions of SCCS files are numbered, 1.1, 1.2, 1.3, 2.1, etc. The number to the left of the period is the major version number (release number). The number to the right of the period is the minor version number. The first version is numbered 1.1. By default, get and edit retrieve the latest version of a file, while delta results in an increase of the minor version number. If an older version is required or the major version number is to be increased, this must be specified explicitly.

Figure 15.3. Main operations of SCCS

The above scheme results in a linear sequence of versions. SCCS also provides the possibility of creating branches (forks), as illustrated in Figure 15.4. For example, starting from version 1.2 we may create versions 1.3, 1.4, etc to represent normal development of a system component, and versions 1.2.1.1, 1.2.1.2, etc to represent bug fixes in version 1.2. In SCCS, the merging of development paths must be done manually.

Figure 15.4. Forking and merging of development paths

When different versions of the same system are maintained in this way, the need to automate the construction of new executable versions arises. Make is a tool that does this (Feldman, 1978). Make uses a description of the various components of a system and their mutual dependencies. When generating a new executable system, Make inspects the date and time of the latest changes to components and only recompiles components when needed (i.e. components that have been changed since the last compilation). A tool such as Make not only saves machine time, but also ensures that the most recent version of each component is used.

The basic functionality of configuration control systems has not fundamentally changed since the development of SCCS in the early 1970s. Rather than keeping a copy of each version, SCCS and similar systems only keep track of what has changed from the previous version (the deltas). Nowadays, disk storage is not an issue and many software configuration systems use simple zip-like compression instead of deltas. Additional features offered in present-day systems are mainly directed at increasing the flexibility and usability of such systems:

• The ability to symbolically tag file versions: If the repair of some bug requires changes in a number of modules, each of these revised modules may be given the same tag, say bug27. In a subsequent build of the system, this tag bug27 may then be used to reference file versions in which this bug has been taken care of. This frees the user from the need to remember that the bug concerns version 1.12 of module A, version 1.3.1.7 of module B, etc.

• The ability to automatically merge branches: This is by no means a foolproof operation and should be used with care. The possibility of merging branches hinges on the availability of appropriate merge tools. If changes are made in disjoint parts of a file, merge tools can generally merge these changes fully automatically.

• Flexible support for multiple developers working on the same system: In SCCS, only one person can be editing a file at a time. This rather restrictive scheme is known as reserved checkout. It may unnecessarily restrict the work in a team. For example, one developer may check out a file he is not going to work on until next week. However, the fact that he did so prevents other developers from working on that file during this week. In another model, known as unreserved checkout, each developer has a working copy of a file. After a while, one developer writes back his updated copy of that file, and other developers will be notified if they want to do the same. These other developers will then, one by one, have to merge their changes with the already updated copy.

• Management of workspaces: Checked-out files are put in a workspace. This may be as simple as the home directory of a developer, or more complex and supported by additional tools. For instance, as well as the files a developer is about to change, files that are needed to compile and test changes may be automatically downloaded.

• Support for communication within a development team: For example, if one developer checks out a file someone else is already working on, he may be given a notification of this, so that the developers can start a dialog and coordinate their activities. The latter type of support connects the pure archival function of configuration control systems with the communication and coordination functions of workflow management systems.

Language-centered environments, as discussed in Section 15.2, support the individual developer. These environments are dominated by issues of software construction. The emphasis is on tools that support software construction: editors, debuggers, compilers, etc. Toolsets that offer configuration management and system build facilities such as those offered by SCCS and Make can be classified as belonging to the family model of software development environments: a great deal of freedom is left to individual developers, while a number of rules are agreed upon to regulate critical interactions between developers.

Most programmer workbenches offer this family type of support. For example, Make assumes that files whose names end in .c are C source files. Members of the development family follow this rule and may even have agreed upon further naming conventions. The development environment however has no way of enforcing those rules. It is up to management to make sure that the rules are followed.

In a process-centered software engineering environment (PSEE), a description of the software development process is shared by the tools that make up the environment. Not surprisingly, developments in process-centered environments are closely tied to developments in process modeling, and vice versa. For example, the kinds of description used in process modeling (state transition diagrams, Petri nets, and so on) are also the formalisms used in PSEEs. Process modeling is discussed in Section 3.7.

As with an integrated environment, a process-centered environment may cover the complete life cycle. As with an IPSE, a PSEE tends to be geared towards supporting tasks from a specific part of the software development life cycle. Since back-end activities (implementation and testing) are somewhat easier to structure and formalize, work on process modeling and PSEEs has concentrated on modeling and supporting back-end activities.

Figure 15.5 gives a model of the process of conducting a code review. The notation is that of Petri nets. In Section 3.7, this same figure was used to explain the role of different formalisms in process modeling. Here, we discuss its role in a process-centered software engineering environment.

Figure 15.5. Petri net view of the review process

If the developer indicates that some piece of code is ready for review, the environment is notified and comes into a state as indicated in Figure 15.5. Parallel to the coding activity, management schedules a review meeting. Once this is done, the place^[29] labeled review scheduled is marked. The support environment then 'knows' that the review can be held and may offer support for doing so. In this way, the environment guides the developers and other participants through the steps of the review process, alerts them when certain actions are required, maintains status information of code products and other pieces of information, etc. Thus, PSEEs provide support for software development by automating routine tasks, invoking appropriate development tools, and enforcing rules and practices.

Formal models of a software process are rigid. In practice, this rigidity is a hindrance, since there will always be exceptions. For example, the minutes of a review meeting might get lost, management may decide to skip a certain review meeting, a review meeting may have to be rescheduled because some participant was ill, etc. The Petri model of Figure 15.5 cannot cope with these situations. A number of them can be accommodated by making the model more complex. But the model will never cover all situations. There is thus a need to be able to intervene. Some PSEEs, for example, offer a way of updating process models on the fly. A fully satisfactory solution is difficult to find and the rigidity of formal models is likely to continue to conflict with the requirements of flexibility in process support.

This holds even more where it supports the early stages of software development. A designer or requirements engineer is not helped by an environment that dictates the detailed order of process steps to be taken. Broadly speaking, we may distinguish two types of activity: the unstructured, creative, and cooperative activities that characterize the early stages of software development; and the repetitive and structured activities that characterize the later stages. A similar dichotomy may be observed in PSEEs. Those that focus on the early stages have much in common with groupware and computer-supported cooperative work (CSCW) systems. These PSEEs support coordination of activities, such as access to and sharing of information, and cooperation activities, such as communication between people and scheduling meetings. This type of support is becoming increasingly important in present-day multisite development; see also Chapter 20. PSEEs focusing on the later stages have much in common with workflow management and configuration control systems. Present-day configuration control systems not only offer the basic versioning and access capabilities known from systems such as SCCS (see Section 15.3.2) but they also offer ways to define and enact software configuration tasks and policies. Some even claim that configuration management tools are the 'real' PSEEs (Conradi et al., 1998).

Developments in the area of (integrated) collections of tools move very fast. For many a facet of the software development process, good tools are available. In this chapter, we have discussed the major developments as regards computer-aided software engineering (CASE). We have done so using a simple, one-dimensional classification of CASE products, which expresses the parts of the life cycle they support:

We have further classified environments according to the mechanism that ties together the tools that make up the environment:

Though environments are supposed to cover the entire life cycle, they tend to emphasize certain parts of the process. They then contain tools specifically geared at supporting tasks from that part of the process, augmented by a more general, and often limited, support for the other parts. For example, language-centered environments tend to focus on the implementation and testing stages.

One of the major impediments to the widespread use of tools is their rigidity. Software tools are driven by formal models of what can and cannot be done. A tool for requirements engineering is likely to enforce certain rules of well-formedness on the diagrams it handles. A tool to support the testing process is likely to prescribe a certain order of process steps. The requirements engineer, though, may well want to play with ill-formed diagrams for a while. Likewise, the tester may want to deviate from the pre-established order of steps if circumstances require this. The tension between the demands for flexibility of tool users and those for formality of tool builders is one of the major challenging research themes in this area.

In a retrospective of PSEE research, Cugola and Ghezzi (1998) refer to this tension as the minimalist versus maximalist approaches. In a maximalist approach, the goal is to model all possible situations. A minimalist approach is more lightweight and acknowledges that humans play a decisive role in the decision process. A further corollary is that tools should support cooperation rather than automation.

An interesting open question is whether tools really help. Studies of tool adoption and usage show mixed results. Some conclude that tools offer real improvements, while others conclude that users have not found tools to be helpful. There are definitely certain impediments to tool adoption. Tools cost money, sometimes a lot of money. There is also a learning curve for tool users. Finally, there is quite a gulf between the state of the art as reported in this chapter and actual practice.

For many an organizational problem, automation seems to be the panacea. Likewise, the use of tools is often seen as panacea for our problems in software engineering: CASE as prosthesis. Tools, though, remain mere tools. Within the software development process, other factors play a role as well. If the tools do not fit the procedures used within your organization, they are likely to have a far from optimal effect. Also, tools cannot make up for an ineffective development method or badly qualified personnel. Good people deliver good products and mediocre people deliver mediocre products, irrespective of the tools they use.

An early taxonomy of CASE products is given in (Dart et al., 1987). Fuggetta (1993) extended this framework with a category of 'process-centered environments'. The latter classification is used in this chapter. Additional dimensions for classifying CASE products are given in (Lott, 1993). Lundell and Lings (2004) discuss how perceptions of CASE have changed over the years. The sociological paradigm (individual, family, etc.) for the user scale stems from (Perry and Kaiser, 1991).

(Barstow et al., 1984) is a collection of seminal articles on programming environments, including the UNIX toolkit approach and early language-centered environments such as Interlisp. The Source Code Control System (SCCS) is described in (Rochkind, 1975). The state of the art in configuration management is reflected in (Estublier et al., 2005). Building tools have not changed much since Make (Feldman, 1978). A recent development in this area in the Java world is Ant (Serrano and Ciordia, 2004).

In the 1980s, tool research focused on creating integrated environments. (Tahvanainen and Smolander, 1990) is an annotated bibliography of articles on software engineering environments from that period. Subsequent research in the area of tools focused on PSEEs. The state of the art in this area is reflected in (Fuggetta and Wolf, 1996) and (Ambriola et al., 1997). The case for more flexibility in software engineering environments is made in (Jankowski, 1994), (Cugola et al., 1996), (Jarzabek and Huang, 1998), and (Cugola and Ghezzi, 1998).

Tool integration issues are addressed in (Sharon and Bell, 1995). Tools assessment is the topic of (Software, 1996b). Studies of tool adoption and usage can be found in (Iivari, 1996) and (Post et al., 1998).