<ch4 toc ch6>

5 Computer aided software engineering (CASE)

5.1 Purpose
5.2 Strengths, weaknesses, and limitations
5.3 Inputs and related ideas
5.4 Concepts
5.4.1 CASE architecture
5.4.2 Workbenches
5.4.3 Object-oriented CASE tools
5.4.4 CASE environments
5.5 Key terms
5.6 Software
5.7 References

5.1 Purpose

The analysis, design, development, testing, and maintenance of software are complex processes that must be managed and controlled. Computer aided software engineering (CASE) is a technology that aids in this process. CASE can be broadly defined as a set of automated tools that assist in the entire software engineering process. Properly used, CASE tools help improve productivity during the development process and the quality of the resulting system.

5.2 Strengths, weaknesses, and limitations

The major benefit attributed to CASE is improved productivity. When used properly, CASE significantly reduces development time. A major reason is automation. CASE replaces many tedious manual procedures with automated tools.

Another major benefit of CASE is improved quality. CASE tools help enforce style conventions, validate syntax, perform consistency checks across models, generate highly maintainable code, and improve quality. CASE can also be used to track the progress of a project and maintain traceability from analysis, through design and implementation.

CASE aids in managing the ripple effects that result from a change to a model. In response to a change, CASE makes the necessary changes in all affected models, so the analyst does not have to redraw the diagrams. Consequently, the analyst is more likely to try more alternatives and develop better solutions.

A secondary benefit of CASE is better documentation because the system makes it easy to create, assemble, and maintain high quality documentation. Because of improved system quality and better documentation, using CASE often results in reduced software maintenance costs. Also, CASE documentation provides a new form of corporate memory that survives staff changes and the limits of paper documentation.

Some CASE tools are based on a specific methodology or do not support the modeling conventions required by a given project. As a result, they sometimes force the users to adopt and use the approach imposed by the CASE tool. It is the analyst’s responsibility to choose the right tool for the application. The application should not be forced to fit the tool.

While most research indicates that CASE helps in the development process and improves productivity, various studies have shown that CASE is often not used uniformly across the organization, is used by only one group, or is never used5. A possible reason is that the perceived complexity outweighs the advantages of using the CASE tool. Given proper training, if users perceive that CASE tools provide them a relative advantage they are likely to use them voluntarily. Also, management commitment and support is essential.

The benefits of using CASE are rarely achieved unless the CASE tools are implemented correctly and managed carefully. CASE is not an end in itself. The real goal is not a successful CASE implementation, but the improvement of the software development process. Without continuous improvement in the software development process, CASE may be more detrimental than beneficial.2

Successfully implementing CASE tools requires that a structured or object-oriented systems methodology be in place. The CASE tool is used to facilitate the chosen business methodology, not to replace it. Unless the organization realigns its CASE technology goals with its business goals, the results are likely to be disappointing.

5.3 Inputs and related ideas

CASE incorporates and integrates many of the tools described in Parts III, IV, V, and VI. CASE tools are sometimes used during the information gathering and problem definition stage, particularly to support conducting a feasibility study (# 13) or a JAD session (# 14).

Unlike CASE, a programming environment supports programming activities and provides little or no support for analysis and design.

5.4 Concepts

CASE is a mechanism for automating system development methodologies. CASE tools typically:

  Support the notation conventions of a specific development method and enforce the method’s rules.
  Support teams of analysts and designers working together on a project.
  Allow the user to navigate freely between different models and support automatic transformations from one stage to the next where appropriate.
  Support activities across the life cycle, from requirements to code.
  Support maintenance of traceability and configuration management information to help management control the development process.
  Support checking and testing the internal consistency of models.
  Support testing to ensure that a model is consistent with the real-world problem it represents.

5.4.1 CASE architecture

CASE is an environment that supports the software engineering process. The environment usually consists of distinct tools, such as editing tools, programming tools, verification and validation tools, configuration management tools, metrics and measurement tools, project management tools, housekeeping tools, reengineering tools, and miscellaneous tools.3 These tools are linked via the central repository, the most critical component in a CASE environment. Figure 5.1 shows a standard CASE architecture.

Figure 5.1  A standard CASE architecture. Editing tools

Editing tools include traditional tools (such as word-processing and programming editors) that help in creating documentation and diagramming tools that provide graphical capabilities such as drawing a data flow diagram (# 24), entity-relationship diagram (# 26), or class-structure diagram (# 29). Programming tools

Coding and debugging tools are the standard tools used to compile (or interpret), run, and debug a program. Code generators are tools that write code from a high-level specification of an application. For example, in an object-oriented application a code generator might write the code for the class given the object-class diagrams. In a visual programming environment, a code generator might write the code for the underlying interface given a user interface. Restructuring tools help in analyzing and reformatting existing code by removing unnecessary go-to statements or other unreachable portions of code. Verification and validation tools

Verifiers ensure that the syntax is correct. Validation tools ensure that the requirements are correct and the product functions are the functions desired or requested by the customer.

Within this classification is a variety of tools. Static analyzers generate cross-references, check for syntax, and enforce standards on a program without executing the code. Dynamic analyzers, such as tracers and profilers, monitor program execution. Comparators check for differences or similarities between files; they are used for checking test output and expected program results. Correctness proof assistants support formal techniques to help prove mathematically the correctness of the code and evaluate the consistency between the code and the specification. Test management tools (Part VII) include test case generators that generate a variety of input test data based on the test criteria and the program’s input data structures. They also include tools to manage the results, verify checklists, and run regression checking. Configuration management tools

Configuration management tools help coordinate and manage software development. Version management tools help maintain the various versions of code and ensure that the correct copy of the code is incorporated in subsequent work. Librarians control the checkin and checkout of software from the repository.

Building an application involves preprocessing, compiling, and linking a variety of software components. Configuration builders ensure that the correct version of each component or piece of software is included in the finished product. These tools become critical when the same product is being built for different target platforms such as Unix or Windows because they keep track of the components used for each target platform.

When changes are made to one software component, other components are affected. If a given component is used in multiple software projects or by multiple designers or developers, then the changes must be synchronized across all developers and projects to ensure that all products continue to work correctly. Change control monitors help with this synchronization. Project estimation and management

Developers and planners have expressed concern over their inability to accurately predict costs and estimate efforts, human resource requirements, and project duration. CASE provides modules that can help in the estimation process. For example, the COCOMO model (constructive cost model)1 is integrated into some CASE software. Function point models are common, too. The scope of the necessary effort can be estimated by counting the number of business activities called function points. The basic idea is to determine problem complexity, code complexity, and data complexity so that a reasonable estimate can be derived.

Typical project management tools enable managers to create and use detailed work plans for resource allocation, identify and track task dependency relationships, implement project tracking, maintain charge-back allocations, and create PERT (# 21) and Gantt (# 20) charts.

A third sub-class of project management tools (email, bulletin boards, shared whiteboards) supports group work and may include tools to record various decisions taken during the system development process. Reengineering tools

Legacy code (for example, old programs that must be modified for Year 2000 compliance) often lack structure, and in some cases, the source code may not even exist. Reengineering is the process of revising application software using a CASE tool. With reverse engineering, the existing application software is studied to understand its design. Forward engineering involves a complete redesign of the system to take advantage of new technologies such as client server computing.

CASE provides several tools to support reverse engineering. Documenters read the program code and generate high-level information about the system, such as cross-referencing information. Restructurers change the unstructured code into something more structured. Analyzers evaluate the strength and weaknesses of the system. Diagrammers read database code and generate such graphical tools as hierarchy diagrams (#s 62, 63, and 64) or entity-relationship diagrams (# 26). To support forward engineering, CASE provides standard software development life cycle tools for redesigning the existing system. Metric tools

Metric tools collect data on programs and program execution; for example, evaluating a set of code based on such metrics as McCabe statistics. Other tools are used to gather program run-time statistics. Housekeeping tools

Housekeeping tools generate user accounts, generate and control repository access privileges, implement backup and recovery, and perform other housekeeping functions. The repository

All the tools are integrated via the repository. The repository is a holding area for storing and integrating diagrams, descriptions, specifications, test data, and other items relevant to the development process. The repository allows users and developers to share information, supports team-based developmental activities, provides a mechanism for integrating a diverse set of CASE tools, and maintains a secure source of storage for software resources.

Additionally, the repository maintains information about the interrelationships between the various (logical and physical) models, and even with models related to implementations outside the repository (such as within programs). For example, if a logical definition of a process is related to its implementations, a repository can search for and retrieve all the implementations (programs, etc.) of that process in the MIS application environment.

Repository models must be open and extensible (in other words, they must accommodate other vendors’ tools). The market is currently moving toward standardization, and CASE vendors are starting to provide hooks to allow their models to be stored in other vendors’ repositories. For example, Rational’s CASE tool allows the import and export of their models to Microsoft’s repository product. Vendors are also starting to provide access to the data in their repositories via the World Wide Web.

Typically a separate repository is maintained for each project and a central repository maintains the details for all projects. Version control software is used to check in and check out the various project repositories from the central repository.

5.4.2 Workbenches

Integration in a CASE environment takes place along four dimensions4. Data integration ensures that the data are managed in a consistent manner across the entire environment. Control integration allows for combining the various tools and functions according to the needs of the project and the environment it supports. Presentation integration allows the users to see a consistent interface across the entire tool spectrum. Process integration ensures that tools interact effectively in support of a specific process.

Workbenches provide integration for only a portion of the system development life cycle. Upper CASE tools support the earlier phases (problem definition, analysis, and design), but provide little or no support for the back end (code generation, implementation, etc.). Lower CASE tools support the design, implementation, testing, and maintenance phases of the system development life cycle (in general the back end). Typical lower CASE tools include application generators for dialogue design, screen painting, code generation, etc. They provide little or no support for the earlier phases of the development life cycle. Both upper and lower CASE tools work in conjunction with implementational or programming workbenches (editors, compilers, debuggers, test tools, etc.).

5.4.3 Object-oriented CASE tools

Object-oriented CASE tools6 support diagramming techniques for such basic object-oriented concepts as classes, inheritance, etc. (# 6). Code generation and integration with other repositories and tools is also essential. Many CASE tools support the unified modified language (UML) notation (# 29). The UML, a standard approved by the Object Management Group, integrates the notation used in various object-oriented methods such as Booch, OMT, or Objectory (#s 29 and/or 66) into a single object-oriented modeling language.

An object orientation requires changes in the way CASE tools operate, however. For example, a CASE code generator must not only generate object-oriented code in languages such as C++ or Java, but also allow for modification of such code by the programmer. Any programmer modifications must be synchronized with the underlying diagrams, so the CASE tool must have the ability to maintain bi-directional synchronization between the graphical models and the generated code. In other words, the code, whether generated by the CASE tool or the programmer, must be integrated with the CASE tool.

Object-oriented CASE tools must support consistency checks and provide error checking capabilities. If the CASE tool is to perform error checking, it must support encapsulation, inheritance, message passing, and other object-oriented characteristics (# 6), and users must be able to view an object on screen, and not rely simply on the diagramming techniques.

Browsing capabilities and the need to hide and reveal portions of the model are unique to object-oriented CASE tools. Browsing is essential because object-oriented development stresses reuse, which means the designer must find potentially reusable classes rather than reinventing the wheel. Reuse librarian software (a library of components and query retrieval mechanisms) helps retrieve software components for reuse.

Much of this browsing does not fit such standard techniques as searching by keyword. Various object-oriented CASE tools are intended to help the analyst or designer visualize and understand the abstraction and specialization process during class definition and classification. For example, the analyst might browse through a hierarchy or might wish to determine all classes that use a specific class or all the component classes in a given class.

To make the browsing process more effective, the analyst might want to hide or expand certain details. For example,6 the analyst may require that the CASE tool support hiding or revealing the attributes or operations in an object class, the relationships between object classes, parameters of messages between object classes, or sequences of messages between a specified group of collaborating object classes

5.4.4 CASE environments

The term environment is reserved for the complete set of automated facilities (such as the operating framework) required to support all the activities in the systems development life cycle, including facilities that allow users to switch easily from one activity to another. An environment must support reusability of tool components, ease of tool integration, prototyping, and support for system development life cycle activities in big multi-user, multi-project software environments.

An environment must be extensible. New tools are likely to emerge during the lifetime of the CASE product, and the environment must be capable of augmenting its tool capabilities and integrating the new tools easily. Extensibility is more easily achieved when the environment is open. An environment must also support interconnectivity, the smooth integration and maintenance of multiple users working on various projects over a network. The infrastructure needed to provide extensibility and interconnectivity exceeds the capabilities of the base operating system.

Examples of environments include IBM’s AD/Cycle and Digital Equipment Corporation’s Cohesion. These two environments provide basic tools, workbenches, and an integrating platform that lets other companies enrich the environment with additional products or tools.

5.5 Key terms

CASE (computer-aided software engineering) —
A set of automated tools that assist in the entire software engineering process.
Environment —
A collection of tools and workbenches that support the entire software process.
Forward engineering —
Completely redesigning a system to take advantage of new technologies such as client server computing.
Lower CASE —
A set of tools that support the design, implementation, testing, and maintenance phases of the system development life cycle (in general the back end).
McCabe statistics —
A complexity metric based on a count of the number of decisions in a program. An indicator of the testability and maintainability of software.
Reengineering —
The process of revising application software using a CASE tool.
Repository —
An integrated holding area where diagrams, descriptions, specifications, test data, and other items are stored and integrated. The repository is the most critical component in a CASE environment.
Reverse engineering —
The process of studying the existing application software to understand its design.
Tool —
Software that supports a specific task in the software development process.
Upper CASE —
A set of tools that support the earlier phases (problem definition, analysis, and design) of the system development life cycle.
Workbench —
A single application that integrates several tools, providing a consistent user interface, consistent invocation of tools and tool-sets, and access to a common data set from a repository (data integration).

5.6 Software

Several software companies and their CASE products are listed in Table 5.1. This list is by no means comprehensive nor does it represent the author’s recommendations. For a more up-to-date list, please visit one of the following World Wide Web sites:

Table 5.1 A Representative List of CASE Products

Company Products

Microsoft Visual Modeler, Visual Source Safe
Rational Rational Rose
Digital Equipment Corp. Cohesion
Intersolv Excelerator II, PVCS
Andersen Consulting Foundation
Sterling Software Composer
Popkin Software System Architect
Hewlett Packard Softbench
Oracle Designer
PowerSoft Power-Designer

  1. http://www.qucis.queensu.ca/Software-Engineering/vendor.html
  2. http://www.yahoo.com/Business_and_Economy/Companies/ Computers/Software/Programming_Tools/Computer_Aided_ Software_Engineering__CASE/

In the second URL, there are two underline characters ( __ ) between Engineering and CASE.

5.7 References

1.  Boehm, B. W., Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.
2.  Boone, G., Establishing the context of continuous improvement for technology transfer, in The Impact of CASE Technology on Software Process, Cooke, D. E., Ed., World Scientific, Singapore, 1994, 215.
3.  Fuggetta, A., A classification of CASE technology, IEEE Comput, 26(12), 25, 1993.
4.  Thomas, I. and Nemjeh, B. A., Definition of tool integration for environments, IEEE Soft, 9(2), 29 1992.
5.  Tuhari, I., Why are CASE tools not used?, Commun. ACM, 30(10), 94, 1996.
6.  Yourdon, E., Whitehead, K., Thomann, J., Oppel, K., and Nevermann, P., Mainstream Objects: An Analysis and Design Approach for Business, Yourdon Press, Upper Saddle River, NJ, 1995, 101.
<ch4 toc ch6>