1999 by CRC Press LLC

chapter five
CASE
T. M. Rajkumar
Miami University
Contents
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.1.1 Editing tools
5.4.1.2 Programming tools
5.4.1.3 Verification and validation tools
5.4.1.4 Configuration management tools
5.4.1.5 Project estimation and management
5.4.1.6 Reengineering tools
5.4.1.7 Metric tools
5.4.1.8 Housekeeping tools
5.4.1.9 The repository
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 pro-
ductivity 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 auto-
mated 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 trace-
ability 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 sys-
tem makes it easy to create, assemble, and maintain high quality documen-
tation. Because of improved system quality and better documentation, using
CASE often results in reduced software maintenance costs. Also, CASE docu-
mentation 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 analysts 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 used.
5
Apossible 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.
1999 by CRC Press LLC
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 (Chapter 13) or a JAD session (Chapter 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 methods rules.
Support teams of analysts and designers working together on a
project.
Allow the user to navigate freely between different models and sup-
port 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, program-
ming tools, verification and validation tools, configuration management tools,
1999 by CRC Press LLC
1999 by CRC Press LLC
Figure 5.1 Astandard CASE architecture.
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.
5.4.1.1 Editing tools
Editing tools include traditional tools (such as word-processing and pro-
gramming editors) that help in creating documentation and diagramming
tools that provide graphical capabilities such as drawing a data flow diagram
(Chapter 24), entity-relationship diagram (Chapter 26), or class-structure
diagram (Chapter 29).
5.4.1.2 Programming tools
Coding and debugging tools are the standard tools used to compile (or inter-
pret), 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.
5.4.1.3 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 programs input data structures. They also include
tools to manage the results, verify checklists, and run regression checking.
5.4.1.4 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.
5.4.1.5 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 estima-
tion 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 num-
ber of business activities called function points. The basic idea is to deter-
mine problem complexity, code complexity, and data complexity so that a
reasonable estimate can be derived.
1999 by CRC Press LLC
Typical project management tools enable managers to create and use
detailed work plans for resource allocation, identify and track task depen-
dency relationships, implement project tracking, maintain charge-back allo-
cations, and create PERT (Chapter 21) and Gantt (Chapter 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.
5.4.1.6 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 soft-
ware 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
(Chapters 62, 63, and 64) or entity-relationship diagrams (Chapter 26). To
support forward engineering, CASE provides standard software develop-
ment life cycle tools for redesigning the existing system.
5.4.1.7 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.
5.4.1.8 Housekeeping tools
Housekeeping tools generate user accounts, generate and control repository
access privileges, implement backup and recovery, and perform other
housekeeping functions.
5.4.1.9 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.
1999 by CRC Press LLC
Additionally, the repository maintains information about the interrela-
tionships 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 implemen-
tations (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,
Rationals CASE tool allows the import and export of their models to
Microsofts 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 cen-
tral 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 dimensions
4
. 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 devel-
opment 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 tools
6
support diagramming techniques for such
basic object-oriented concepts as classes, inheritance, etc. (Chapter 6). Code
generation and integration with other repositories and tools is also essential.
Many CASE tools support the unified modified language (UML) notation
1999 by CRC Press LLC
(Chapter 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 (Chapters 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 modifica-
tions 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 pro-
vide error checking capabilities. If the CASE tool is to perform error checking,
it must support encapsulation, inheritance, message passing, and other
object-oriented characteristics (Chapter 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 search-
ing by keyword. Various object-oriented CASE tools are intended to help the
analyst or designer visualize and understand the abstraction and specializa-
tion 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 facili-
ties (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.
1999 by CRC Press LLC
An environment must be extensible. New tools are likely to emerge
during the lifetime of the CASE product, and the environment must be capa-
ble 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 intercon-
nectivity exceeds the capabilities of the base operating system.
Examples of environments include IBMs AD/Cycle and Digital
Equipment Corporations 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 Acollection 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 Aset of tools that support the design, implementation,
testing, and maintenance phases of the system development life cycle
(in general the back end).
McCabe statistics Acomplexity metric based on a count of the number
of decisions in a program. An indicator of the testability and maintain-
ability 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 Aset of tools that support the earlier phases (problem
definition, analysis, and design) of the system development life cycle.
Workbench Asingle 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 authors
1999 by CRC Press LLC
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., Aclassification 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.
recommendations. For a more up-to-date list, please visit one of the follow-
ing World Wide Web sites:
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/
Note: In the second URL, there are two underline characters ( __ ) between
Engineering and CASE.
1999 by CRC Press LLC
Table 5.1 ARepresentative 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
LogicWorks ERWIN, BPWIN, OOWIN
IBM CMVC, AD/Cycle