2 Requirements for a CASE Environment

  `` A great programmer writes many languages well (English not least among them!), knows more then one operating system, and understands the benefits and limitations of each. He carries the benefits over into his other environments, and borrows approaches to overcoming the limitations.''  
David Boundy, [Bou91] The process of software development is a quite complex task. Therefore numerous tools have been developed over time to aid the software engineer's work. Some tools for building a project were introduced in Chapter 1. Others are automatic code generators like the parser generator YACC and the lexical analyzer LEX, which are well known. These utilities are very useful for developing software but do not take into account all requirements of a CASE environment. Additional functionality is needed to connect and pass necessary information between different tools.

In the early days of software development only assemblers were available. During the 1970s compilers, interpreters and symbolic debuggers have been developed. These tools introduced different high level programming languages adapted for specific software problems which are platform independent. This made it easier to concentrate on the problem instead of the actual implementation. Today's state of the art software development uses source code control systems to synchronize the development between different programmers and automatic code generators to create source code from high level descriptions of the problem[Fis91]. The requirements for a CASE environment are:

Project Definitionproject The definition of a project under development, a so called ``working project'' has to be simple. To lower the complexity of large projects, these are split into smaller sub-projects or modules. The dependences between projects form an acyclic graph. Sub-projects can be used by multiple parents whereas a module is part of only one project. This approach enforces a specific structuring and allows reuse of projects. Project and dependence definition ought to be system independent to allow development on different platforms at the same time, e.g., to develop under UNIX and VMS without the need of changing the project description. Specifying the same information multiple times for different systems is error-prone, therefore platform dependent files should be created from a common source.

Implicit relations between files, e.g., include dependences should be handled automatically. This information always has to be up-to-date and no programmer intervention should be required.

Building a Projectbuild The building of a project should be fast and comfortable for the developer. Only a minimum set of resources should be used, e.g., building of files which are not needed for the goal has to be avoided. This requires full dependence information across module and project boundaries. Two different building modes are useful:

1. A batch mode for compilation ``over night'' or rebuilding full projects. This mode can be used to implement the global design loop of a project. With this loop the syntactical correctness of a project can be checked. Functionality can only be tested by running selftests.
2. An interactive mode with fast response for updating projects with small changes only. This ensures a short local design loop for each developer.

Both modes allow to update either a single file, a module, a single project, or any combination of them. The known dependences can be checked either locally in one module, within one project or across project boundaries.

In order to shorten the building process the update actions can be parallelized and executed out of order on a cluster of computers.

Multiple Developer Accessmultiple Today the size of projects requires that multiple developers work on the same set of source files. Each developer introduces local modifications in contrast to a common global code repository during development. Conflicts caused by modifications of the same source by different programmers must be handled automatically whenever possible. A history mechanism in the repository is required to track down changes. This is important in case an incompatible change was made.

The same mechanism can be used to tag a release (see release) in the code repository for later reconstruction. This allows to check for bugs reported by external users for a specific version.

Multiple Language Supportlanguage Many large scale software products are written in more than one implementation language. An orthogonal set of rules is required to support the different languages. This allows to select the language best suited for solving a specific problem within one project.

The language binding between these different domains is an error-prone task which should be automated by the environment. Additional information required by the binding tool has to be added by the developer to the source code, e.g., by special comments.

Automatic Code Generationcodegen Tools for automatic code generation from descriptions minimize the coding size for the developer. Standard tools under UNIX are

• YACC to create a parser from a short state description,
• LEX to create a lexical analyzer.

Often scripts written in different languages like AWK and PERL are also used for automatic code generation. A special case of automatic code generation is language binding (see language).

Use of External Resourcesexternal External resources are required if there are object files, libraries, and/or programs which are used within a project but not available as source code, e.g., a third party product. Using these resources must be simple.

Global installation (see install) of projects created by the environment are a special case of external resources. Reusing a stable global version of a project increases the speed of the building process.

Global Installationinstall Users can work with the programs of a global installation of a project without conflict with the developers who continue to work on their local version. Only a stable version of a project should be installed globally and marked in the code repository.

The structure of a global installation should be common for all projects which are controlled by the environment. This makes it easier especially for unexperienced users to use a project.

A global installed version of a project can be used by developers as an external resource without any further definitions. A local version of the project must override the global one.

Releasesrelease Releases are used to transfer projects either by source code or in binary form to external users. Usually releases are marked by a major and a minor number. For small corrections an additional patch level number is used. Three types of releases can be distinguished:

1. In a major release new or incompatible extensions in the functionality have been added. It cannot replace a previous major release without rebuilding projects depending on the new release.
2. A minor release includes new or corrected functions, but no incompatibilities in the functional interface exist. Therefore a minor release can replace a previous one.
3. A patch release corrects bugs in the functionality.

Major and minor releases usually consist of a full set of files of the project. A patch release in contrast has only information about differences to the last version. This reduces the amount of data to be transferred for a bug fix. The patch data created by the patch releases has to be applied by the external user to his installation to get a full working project.

Each file belonging to the release is marked in the code repository to allow later reconstruction.

Software Qualityquality With increasing size and complexity of a software product it becomes more and more difficult to achieve a high standard in software quality. The following list contains some methods for achieving higher software quality. Furthermore the environment must be open to include in a simple manner new methods to increase software quality.

1. Automated Testing: the programs of a project are tested with a set of input data. The generated output is then compared to a valid data set. Usually a set of files must be created for different platforms.
2. Code Analyzers: these tools check the correct definition and use of the functional interface of a project. If possible this should be cross checked against the formal specification of the project.
3. Code Coverage: this method checks which parts of the code were never used during one or multiple executions. The goal of a 100% code coverage is very hard to reach. Special care must be taken for parts of code which are never executed because they may still have unrecognized bugs.
4. Forced Error Simulation: a method to force the program into special states to execute error handling code. During normal operation this code is not reached and not tested.
5. Run Time Checker: special utilities to check the execution of the program. Mainly used for finding memory access errors, uninitialized memory accesses, and bad function parameters.
6. Debug Macros: macros to check the requirements of the functional interface are used during development. These are turned off for the fast release version.

Graphical User Interfacegui A graphical user interface can be used as front end to control the tool, but it is not really required for the functional operation of a CASE environment. Of course a nice and easy to use environment is much more likely to be accepted by programmers than a command line oriented tool.

An additional intuitive and context sensitive help system should be added to make the usage of the tools easier.