COMPUTER AIDED SOFTWARE ENGINEERING(CASE)

A CASE tool is a generic term used to denote any form of automated support for
software engineering, In a more restrictive sense a CASE tool can mean any tool
used to automate some activity associated with software development. Many
CASE tools are now available. Some of these tools assist in phase-related tasks
such as specification, structured analysis, design, coding, testing, etc. and others
to non-phase activities such as project management and configuration
management. The primary objectives in using any CASE tool are:

1. To increase productivity.
2. To help produce better quality software at lower cost.

CASE ENVIRONMENT
CASE tools are characterised by the stage or stages of software development life
cycle on which they focus. Since different tools covering different stages share
common information, it is required that they integrate through some central
repository to have a consistent view of information associated with the software.
This central repository is usually a data dictionary containing the definition of all
composite and elementary data items. Through the central repository all the CASE
tools in a CASE environment share common information among themselves.
Benefits of CASE
Several benefits accrue from the use of a CASE environment or even isolated CASE
tools.
1. A key benefit arising out of the use of a CASE environment is cost saving
through all developmental phases. Different studies carry out to measure
the impact of CASE, put the effort reduction between 30 per cent and 40
per cent.
2. Use of CASE tools leads to considerable improvements in quality. This is
mainly due to the facts that one can effortlessly iterate through the
different phases of software development, and the chances of human error
is considerably reduced.
3. CASE tools help produce high quality and consistent documents. Since the
important data relating to a software product are maintained in a central
repository, redundancy in the stored data is reduced, and therefore,
chances of inconsistent documentation is reduced to a great extent.
4. CASE tools take out most of the drudgery in a software engineers work. For
example, they need not check meticulously the balancing of the DFDs, but
can do it effortlessly through the press of a button.
5. CASE tools have led to revolutionary cost saving in software maintenance
efforts.

CASE SUPPORT IN SOFTWARE LIFE CYCLE

CASE tools usually provide in the software development life cycle.
Prototyping Support
prototyping is useful to understand the requirements of complex software
products, to demonstrate a concept, to market new ideas, and so on. The
prototyping CASE tool’s requirements are as follows: Define user
interaction. Define the system control flow. Store and retrieve data required
by the system. Incorporate some processing logic. There are several stand
alone prototyping tools. But a tool that integrates with the data dictionary
can make use of the entries in the data dictionary.
Since one of the main uses of a prototyping CASE tool is graphical user
interface (GUI) development, a prototyping CASE tool should support the
user to create a GUI using a graphics editor. It should integrate with the data
dictionary of a CASE environment. If possible, it should be able to integrate
with external user defined modules written in C or some popular high level
programming languages. The user should be able to define the sequence of
states through which a created prototype can run. The user should also be
allowed to control the running of the prototype. The run time system of
prototype should support mock up run of the actual system and
management of the input and output data.

Structured Analysis and Design

A CASE tool should support one or more of the structured analysis and
design technique. The CASE tool should support effortlessly drawing
analysis and design diagrams. The CASE tool should support drawing fairly
complex diagrams and preferably through a hierarchy of levels. It should
provide easy navigation through different levels and through design and
analysis. The tool must support completeness and consistency checking
across the design and analysis and through all levels of analysis hierarchy.

Code Generation
code generation is concerned, the general expectation from a CASE tool is
quite low. A reasonable requirement is traceability from source file to
design data. More pragmatic support expected from a CASE tool during
code generation phase are the following:

The CASE tool should support generation of module skeletons or templates

in one or more popular languages. It should be possible to include copyright
message, brief description of the module, author name and the date of
creation in some selectable format.
The tool should generate records, structures, class definition automatically
from the contents of the data dictionary in one or more popular
programming languages. It should generate database tables for relational
database management systems.
The tool should generate code for user interface from prototype definition
for X window and MS window based applications.
Test Case Generator
The CASE tool for test case generation should have the following features: It
should support both design and requirement testing It should generate test
set reports in ASCII format which can be directly imported into the test plan
document.
ARCHITECTURE OF A CASE ENVIRONMENT
The important components of a modern CASE environment are user
interface, tool set, object management system (OMS), and a repository.

User interface The user interface provides a consistent framework for

accessing the different tools thus making it easier for the users to interact
with the different tools and reducing the overhead of learning how the
different tools are used.
Object management system
Object management system and repository Different case tools represent
the software product as a set of entities such as specification, design, text
data, project plan, etc. The object management system maps these logical
entities into the underlying storage management system (repository). The
commercial relational database management systems are geared towards
supporting large volumes of information structured as simple relatively
short records.
 SOFTWARE MAINTENANCE
Software maintenance denotes any changes made to a software product
after it has been delivered to the customer. Maintenance is inevitable for
almost any kind of product. However, most products need maintenance due
to the wear and tear caused by use. On the other hand, software products
do not need maintenance on this count, but need maintenance to correct
errors, enhance features, port to new platforms, etc.

CHARACTERISTICS OF SOFTWARE MAINTENANCE

There are three types of software maintenance

Corrective: Corrective maintenance of a software product is necessary
either to rectify the bugs observed while the system is in use.
Adaptive: A software product might need maintenance when the
customers need the product to run on new platforms, on new operating
systems, or when they need the product to interface with new hardware or
software.
Perfective: A software product needs maintenance to support the new
features that users want it to support, to change different functionalities of
the system according to customer demands, or to enhance the performance
of the system.

Characteristics of Software Evolution

Lehman and Belady have studied the characteristics of evolution of se ve ra
l software products [1980].
Lehman’s first law:
A software product must change continually or become progressively less
useful. Every software product continues to evolve after its development
through maintenance efforts. Larger products stay in operation for longer
times because of higher replacement costs and therefore tend to incur
higher maintenance efforts.
Lehman’s second law: The structure of a program tends to degrade as more
and more maintenance is carried out on it. The reason for the degraded
structure is that when you add a function during maintenance, you build on
top of an existing program, often in a way that the existing program was not
intended to support. If you do not redesign the system, the additions will be
more complex that they should be.
Lehman’s third law: Over a program’s lifetime, its rate of development is
approximately constant. The rate of development can be quantified in
terms of the lines of code written or modified. Therefore this law states that
the rate at which code is written or modified is approximately the same
during development and maintenance.

SOFTWARE REVERSE ENGINEERING

Software reverse engineering is the process of recovering the design and
the requirements specification of a product from an analysis of its code. The
purpose of reverse engineering is to facilitate maintenance work by
improving the understandability of a system and to produce the necessary
documents for a legacy system.
The first stage of reverse engineering usually focuses on carrying out
cosmetic changes to the code to improve its readability, structure, and
understandability, without changing any of its functionalities. All variables,
data structures, and functions should be assigned meaningful names
wherever possible. Complex nested conditionals in the program can be
replaced by simpler conditional statements or whenever appropriate by
case statements.
After the cosmetic changes have been carried out on a legacy software, the
proces of extracting the code, design, and the requirements specification
can begin. . In order to extract the design, a full understanding of the code
is needed. Some automatic tools can be used to derive the data flow and
control flow diagram from the code. The structure chart (module invocation
sequence and data interchange among modules) should also be extracted.
The SRS document can be written once the full code has been thoroughly
understood and the design extracted.

SOFTWARE MAINTENANCE PROCESS MODELS

software maintenance project are not unique and depend on several factors
such as: (i) the extent of modification to the product required, (ii) the
resources available to the maintenance team, (iii) the conditions of the
existing product (e.g., how structured it is, how well documented it is, etc.),
(iii) the expected project risks, etc. When the changes needed to a software
product are minor and straightforward, the code can be directly modified
and the changes appropriately reflected in all the documents.
r, two broad categories of process models can be proposed.

First model
The first model is preferred for projects involving small reworks where the
code is changed directly and the changes are reflected in the relevant
documents later. ch, the project starts by gathering the requirements for
changes. The requirements are next analysed to formulate the strategies to
 be adopted for code change. At this stage, the association of at least a few
members of the original development team goes a long way in reducing the
cycle time, especially for projects involving unstructured and inadequately
documented code. debugging of the reengineered system becomes easier
as the program traces of both the systems can be compared to localise the
bugs.

Second model The second model is preferred for projects where the amount of rework
required is significant. This approach can be represented by a reverse engineering cycle
followed by a forward engineering cycle. Such an approach is also known as software re-
engineering. The reverse engineering cycle is required for legacy products. During the
reverse engineering, the old code is analysed (abstracted) to extract the module
specifications. The module specifications are then analysed to produce the design. The
design is analysed (abstracted) to produce the original requirements specification. The
change requests are then applied to this requirements specification to arrive at the new
requirements specification. At this point a forward engineering is carried out to produce
the new code. At the design, module specification, and coding a substantial reuse is
made from the reverse engineered products. An important advantage of this approach is
that it produces a more structured design compared to what the original product had,
produces good documentation, and very often results in increased efficiency.
 ESTIMATION OF MAINTENANCE COST
Boehm [1981] proposed a formula for estimating maintenance costs as part of his
COCOMO cost estimation model. Boehm’s maintenance cost estimation is made in terms
of a quantity called the annual change traffic (ACT). Boehm defined ACT as the fraction
of a software product’s source instructions which undergo change during a typical year
either through addition or deletion. where, KLOCadded is the total kilo lines of source
code added during maintenance. KLOCdeleted is the total KLOC deleted during
maintenance. Thus, the code that is changed, should be counted in both the code added
and code deleted. The annual change traffic (ACT) is multiplied with the total
development cost to arrive at the maintenance cost: Maintenance cost = ACT ×
Development cost Most maintenance cost estimation models, however, give only
approximate results because they do not take into account several factors such as
experience level of the engineers, and familiarity of the eng ineers with the product,
hardware requirements, software complexity, etc.
 SOFTWARE REUSE
Software products are expensive. Therefore, software project managers are always
worried about the high cost of software development and are desperately looking for
ways to cut development cost. A possible way to reduce development cost is to reuse
parts from previously developed software. In addition to reduced development cost and
time, reuse also leads to higher quality of the developed products since the reusable
components are ensured to have high quality.

WHAT CAN BE REUSED?

All artifacts associated with software development, including project plan and test plan
can be reused. However, the prominent items that can be effectively reused are:
 Requirements specification
 Design
 Code
 Test cases
 Knowledge
Knowledge is the most abstract development artifact that can be reused. Out of all the
reuse artifacts, reuse of knowledge occurs automatically without any conscious effort in
this direction.

BASIC ISSUES IN ANY REUSE PROGRAM

The following are some of the basic issues that must be clearly understood for starting
any reuse program:
Component creation.
Component indexing and storing.
Component search.
Component understanding.
Component adaptation.
Repository maintenance.
Component creation: For component creation, the reusable components have to be first
identified. Selection of the right kind of components having potential for reuse is
important.
Component indexing and storing Indexing requires classification of the reusable
components so that they can be easily searched when we look for a component for
reuse. The components need to be stored in a relational database management system
(RDBMS) or an object-oriented database system (ODBMS) for efficient access when the
number of components becomes large.
Component searching The programmers need to search for right components matching
their requirements in a database of components. To be able to search components
efficiently, the programmers require a proper method to describe the components that
they are looking for.
Component understanding The programmers need a precise and sufficiently complete
understanding of what the component does to be able to decide whether they can reuse
the component. To facilitate understanding, the components should be well
documented and should do something simple.
Component adaptation Often, the components may need adaptation before they can
be reused, since a selected component may not exactly fit the problem at hand.
However, tinkering with the code is also not a satisfactory solution because this is very
likely to be a source of bugs.
Repository maintenance A component repository once is created requires continuous
maintenance. New components, as and when created have to be entered into the
repository. The faulty components have to be tracked. Further, when new applications
emerge, the older applications become obsolete. In this case, the obsolete components
might have to be removed from the repository.

A REUSE APPROACH
A promising approach that is being adopted by many organisations is to introduce a
building block approach into the software development process. For this, the reusable
components need to be identified after every development project is completed. The
reusability of the identified components has to be enhanced and these have to be
cataloged into a component library. It must be clearly understood that an issue crucial to
every reuse effort is the identification of reusable components.
Domain Analysis
The aim of domain analysis is to identify the reusable components for a problem
domain.
Reuse domain A reuse domain is a technically related set of application areas. A body of
information is considered to be a problem domain for reuse, if a deep and
comprehensive relationship exists among the information items as characterised by
patterns of similarity among the development components of the software product. A
reuse domain is a shared understanding of some community, characterised by concepts,
techniques, and terminologies that show some coherence. Examples of domains are
accounting software domain, banking software domain, business software domain,
manufacturing automation software domain, telecommunication software domain, etc

Evolution of a reuse domain

The ultimate results of domain analysis is development of problemoriented languages.
The problem-oriented languages are also known as application generators. These
application generators, once developed form application development standards. The
domains slowly develop. A s a domain develops, we may distinguish the various stages it
undergoes:
Stage 1 : There is no clear and consistent set of notations. Obviously, no reusable
components are available. All software is written from scratch.
Stage 2 : He re , only experience from similar projects are used in a development effort.
This means that there is only knowledge reuse.
Stage 3: At this stage, the domain is ripe for reuse. The set of concepts are stabilised
and the notations standardised. Standard solutions to standard problems are available.
There is both knowledge and component reuse.
Stage 4: The domain has been fully explored. The software development for the domain
can largely be automated. Programs are not written in the traditional sense any more.
Programs are written using a domain specific language, which is also known as an
application generator.
Component Classification
Components need to be properly classified in order to develop an effective indexing and
storage scheme. We have already remarked that hardware reuse has been very
successful. If we look at the classification of hardware components for clue, then we can
observe that hardware components are classified using a multilevel hierarchy. At the
lowest level, the components are described in several forms—natural language
description, logic schema, timing information, etc. The higher the level at which a
component is described, the more is the ambiguity. This has motivated the Prieto-Diaz’s
classification scheme.
Prieto-Diaz’s classification scheme
Each component is best described using a number of different characteristics or facets.
For example, objects can be classified using the following: Actions they embody. Objects
they manipulate. Data structures used. Systems they are part of, etc. Prieto-Diaz’s
faceted classification scheme requires choosing an n-tuple that best fits a component.
Faceted classification has advantages over enumerative classification. Strictly
enumerative schemes use a pre-defined hierarchy. Therefore, these force you to search
for an item that best fits the component to be classified.
Searching
The domain repository may contain thousands of reuse items. In such large domains,
what is the most efficient way to search an item that A popular search technique that
has proved to be very effective is one that provides a web interface to the repository.
Using such a web interface, one would search an item using an approximate automated
search using key words, and then from these results would do a browsing using the links
provided to look up related items. The developer may follow links to other products until
a sufficiently good match is found. Browsing is done using the keywordto-keyword,
keyword-to-product, and product- to-product links. These links help to locate additional
products and compare their detailed attributes.
Repository Maintenance
Repository maintenance involves entering new items, retiring those items which are no
more necessary, and modifying the search attributes of items to improve the
effectiveness of search. Also, the links relating the different items may need to be
modified to improve the effectiveness of search. The software industry is always trying
to implement something that has not been quite done before. As patterns requirements
emerge, new reusable components are identified, which may ultimately become more
or less the standards. However, as technology advances, some components which are
still reusable, do not fully address the current requirements.
Reuse without Modifications
Reuse without modification is much more useful than the classical program libraries.
These can be supported by compilers through linkage to run-time support routines
(application generators). Application generators translate specifications into application
programs. The specification usually is written using 4GL. The specification might also be
in a visual form. The programmer would create a graphical drawing using some standard
available symbols. Defining what is variant and what is invariant corresponds to
parameterising a subroutine to make it reusable. A subroutine’s parameters are variants
because the programmer can specify them while calling the subroutine. Parts of a
subroutine that are not parameterised, cannot be changed. Application generators have
Application generators have been applied successfully to data processing application,
user interface, and compiler development. Application generators are less successful
with the development of applications with close interaction with hardware such as real-
time systems.

REUSE AT ORGANISATION LEVEL

Reusability should be a standard part in all software development activities including
specification, design, implementation, test, etc. Ideally, there should be a steady flow of
reusable components. In practice, however, things are not so simple. Extracting reusable
components from projects that were completed in the past presents an important
difficulty not encountered while extracting a reusable component from an ongoing
project—typically, the original developers are no longer available for consultation.
Development of new systems leads to an assortment of products, since reusability
ranges from items whose reusability is immediate to those items whose reusability is
highly improbable. Achieving organisation-level reuse requires adoption of the following
steps:
 Assess of an item’s potential for reuse.
 Refine the item for greater reusability.
 Enter the product in the reuse repository
Assessing a product’s potential for reuse Assessment of a components reuse potential
can be obtained from an analysis of a questionnaire circulated among the developers.
The questionnaire can be devised to assess a component’s reusability.
A sample questionnaire to assess a component’s reusability is the following:
Is the component’s functionality required for implementation of systems in the future?
How common is the component’s function within its domain?
Would there be a duplication of functions within the domain if the component is taken
up?
Is the component hardware dependent?
Is the design of the component optimised enough?
If the component is non-reusable, then can it be decomposed to yield some reusable
components?
Can we parametrise a non-reusable component so that it becomes reusable?
Refining products for greater reusability
For a product to be reusable, it must be relatively easy to adapt it to different contexts.
Machine dependency must be abstracted out or localised using data encapsulation
techniques. The following refinements may be carried out:
Name generalisation: The names should be general, rather than being directly related to
a specific application.
Operation generalisation: Operations should be added to make the component more
general. Also, operations that are too specific to an application can be removed.
Exception generalisation: This involves checking each component to see which
exceptions it might generate. For a general component, several types of exceptions
might have to be handled.
Handling portability problems: Programs typically make some assumption regarding the
representation of information in the underlying machine. These assumptions are in
general not true for all machines.
Current State of Reuse
In spite of all the shortcomings of the state-of-the-art reuse techniques, it is the
experience of several organisations that most of the factors inhibiting an effective reuse
program are non-technical. Some of these factors are the following:
 Need for commitment from the top management.
 Adequate documentation to support reuse.
 Adequate incentive to reward those who reuse. Both the people contributing new
reusable components and those reusing the existing components should be
rewarded to start a reuse program and keep it going.
 Providing access to and information about reusable components. Organisations
are often hesitant to provide an open access to the reuse repository for the fear
of the reuse components finding a way to their competitors.