BUILDING AND SUSTAINING

MAINTAINABILITY
Unit-4
 Definitions
• High level language - a computer programming language that is
similar to a natural language and that requires each statement to be
translated or interpreted into machine language prior to execution
• Impact analysis - the determination of the major effects of a
proposed project or change.
• Object oriented programming - computer programming in which
code and data pertaining to a single entity (object) are encapsulated,
and communicate with the rest of the system via messages
• Quality assurance - the systematic monitoring and evaluation of
aspects of a project, service or facility to ensure that necessary
standards of excellence are being met.
 Quality Assurance
• Quality is widely defined as 'fitness for purpose' and this encompasses
most of what many people mean when they talk about quality.
• building maintainability into a system and, as such, maintainability will
not be looked at as a quality factor by itself but rather as something
which is affected by the other quality factors –
• fitness for purpose
• correctness
• portability
• testability
• usability
• reliability
• efficiency
• integrity
• reusability
• interoperability.
• Another important issue which impacts upon
the quality of a system is the appropriate use
of standards
• There are also quality standards specifically
adapted to the software process
• UK's TICKIT-relates quality issues directly to software
production
• IEEE (STD) 1219-1993 -Standard for Software
Maintenance
 1.Fitness for Purpose
• Fitness for purpose - does the product do the
job it was intended to do -is an obvious
criterion by which to measure quality. In order
to see what it means in terms of the
maintainability of a system it is necessary to
look at how it is measured
 2.Correctness
• There is as yet no way of proving a system to be
correct. Nonetheless ,there is much that can be
done towards decreasing the level of errors in a
system
• Building correctness into a system has the
obvious advantage that less time will be spent
on corrective maintenance.
• A maintenance-conscious life-cycle model will
help maintain the correctness of a system.
 3.Portability

• Portability encompasses many things, for example moves between

hardware platforms, for example porting a system from a VAX to a PC;
• operating systems, for example from Windows to LINUX to widen a
market, from VAX/VMS to Windows when an organisation moves from
a VAX base to a PC base;
• programming languages, for example upgrading a system from DOS
basedto Windows-based by rewriting in a different language or
rewriting a system to adhere to a new in-house standard, for example
Fortran 77 to ANSI C
• countries, for example an organisation may wish to widen its market
for a product from the UK to Europe. The product would need to be
available in all European languages.
 4.Testability
• system that is easy to test is also easier to
change effectively because it is easier to test
the changes made.
• It does not automatically follow that a system
that is hard to test will be harder to change per
se but if the system cannot be tested
effectively, it is hard to engender confidence
that modifications have been carried out
successfully.
 5.Usability
• If a system for any reason is not used, it may
as well not exist.
• Maintenance is only an issue for a system that
is used and that evolves with use.
 6.Reliability
• Varying degrees of importance can be attached to
reliability, depending upon the application.
Building in a high degree of reliability can be
costly and is not always necessary. The reliability
of an air traffic control system, for instance, must
be greater than for a word processing package.
• Reliability is closely allied to trust. If a customer
has no trust in a system, he or she will not use it.
 7.Efficiency
• The efficiency of a system, how it makes use of
a computer's resources ,is not always easy to
quantify. A requirements specification will
often specify speed and storage requirements
and response times, but there is often an
implicit assumption that a system will make
'the most efficient‘ use of the available
resources
 8.Integrity

• The integrity of a system can be interpreted in

two ways:
• 1. Is the system safe from unauthorised
access?
• 2. Can system integrity be guaranteed from a
configuration management point of view?
• Has the system been built from a consistent
and reproducible set of modules?
 9.Reusability
• Reusability is a factor that is absolutely central
to the maintainability of a system
 10.Interoperability
• The ability of a system to interact with other
systems is a very important factor.
• People want to be able to move data between
applications without loss. There was a time
when it was all but impossible to move a
document between word processors without,
at the very least, losing all formatting
information
 Fourth-Generation Languages
• In the early days of computing, programming
was undertaken mainly by professional
programmers
• Conventional programming languages were an
option, but required significant investment of
time and effort to learn.
• The tools to enable users to achieve these
objectives were fourth-generation languages
(4GLs).
classification of programming languages
• The use of the term 'fourth-generation languages' stemmed from the
classification of programming languages according to their generations.
• The use of first-generation languages entails programming computers using
binary notation. These languages require a good understanding of low-level
details of the machine such as physical storage locations and registers.
• Second-generation languages were an improvement of the first
generationones. Instead of specifying the physical location in the computer,
symbolic addresses are used to designate locations in memory .Second-
generation languages are slightly less machine dependent
• Third-generation languages, also known as high-level languages, are more
independent of the machine than second-generation languages and as such
their use does not require knowledge of the machine instruction set
 disadvantages
• high-level languages in comparison with their predecessors, they
still present several difficulties which include
• Writing and debugging programs is a significantly slow, difficult
and expensive process
• Many of them can only be used effectively by professional
programmers. If there is a dearth of the relevant professionals,
projects will be significantly slowed
• The implementation of changes to complex software systems is
slow ,difficult-and hence can greatly increase maintenance costs.
• Several lines of code need to be written to solve a relatively
small problem, thereby impeding programmer productivity
 examples
• Some 4GLs are described as non-procedural languages
because they allow the user to specify 'what' the
application is to do but not in detail 'how' this is to be
achieved.
• Examples of non-procedural languages include application
generators, database query languages and form designers.
• procedural languages include Pascal,Modula-2, Cobol, and
C. Certain 4GLs, however, sometimes combine the
characteristics of both non-procedural and procedural
languages.
Properties of Fourth-Generation Languages
• Martin and McClure [186, 188] in a survey carried out in the early 1980's
provided an extensive list of these characteristics.
• They are easy to use
• They can be employed by non-professional programmers to obtain results.
• They use a database management system directly
• They require an order of magnitude fewer instructions than other
conventional languages such as Cobol.
• Where possible, they use non-procedural codeWhere possible, intelligent
default assumptions about what the userwants are made.

• They are designed for on-line operations

• They encourage or enforce structured code
 Impact on Maintenance
• By virtue of the above characteristics, the use of
4GLs to develop and maintain applications
impacts on software maintenance in many ways
• increased Productivity
• Reduction in Cost
• Ease of Understanding
• Automatic Documentation
• Reduction in Workload
Weaknesses of Fourth-Generation Languages

• In spite of the above potential benefits to

maintenance, these language sdo have
weaknesses which include the following.
• Application-Specific
• Proprietary
• Hyped Ease of Use
• Poor Design
 Object-Oriented Paradigms
• Early procedural programming is analogous to the 'waterfall'
model. It developed in much the same way. It was appropriate to
early software development contexts.
• Originally, computers were used to solve well-defined,
mathematically based problems. The idea of following a sequence
of instructions was appropriate and relevant. Early programs
written in machine code or assembler were the 'code-and-fix' and
'quick-fix' of programming languages. Simple sequences of
instructions were fine for simple and clearly defined problems.

• The object-oriented paradigm was developed to handle the design,

development and maintenance of industrial-strength software
 Algorithmic decomposition
• was one of the most popular approaches used by
software engineers and usually came under the
guise of 'top-down structured design'. Here, the
system is perceived as a process - or a collection
of algorithms - and during decomposition,
• The process is broken down into sub-processes
each of which in turn is represented as
procedures, functions or modules depending on
the programming language.
 the design (or algorithmic
decomposition) of a spelling checker system yields the output given

• This approach to software development and

maintenance has a number of weaknesses.
• Firstly the output from each phase of the life
cycle is represented in a different form or
language
• Secondly, issues of abstraction and
information hiding are not necessarily dealt
with properly
Algorithmic decomposition of a spell checker
system
 Decomposition to Aid Comprehension
• Object-oriented decomposition is the approach in which the
system is viewed as a collection of objects that interact to
perform a higher-level function
• The objects communicate with each other through message-
passing; that is, sending instructions on the service that is
required. Object-oriented decomposition involves abstracting
these objects and operations from the problem domain
• the object, Spelling Checker,first issues a message, Get Words, to
another object, Document,requesting words. After receiving the
words, Spelling Checker then instructs another object, Dictionary,
to check the spelling of the words.This is achieved by passing the
message, Lookup.
Object orientation of a spell checker system
Impact on Maintenance
 .4 Approaches
• Migration to object-oriented platforms can be approached in a number of
ways.
• The first is to rewrite the whole system. In other words, throwaway the
current system and start from scratch, but develop the new system from an
object-oriented perspective
• The second approach to migration, especially appropriate in the early days of
moves to object-oriented systems, was to use object oriented analysis as a
'springboard'; that is, perform object-oriented analysis of the existing system
and implement it using a mainstream but non-object-oriented language such
as Cobol or C and then migrate to a suitable object-oriented language at some
later time
• The third, and possibly the approach preferred by most organisations, is that
which permits organisations to reap the benefits that object orientation offers
as well as securing the investment that has been made in their existing systems
 Retraining Personnel
• An are a that has been neglected is the
retraining of personnel – analysts ,designers
and programmers - already involved in main
stream technologies or programming
languages, such as structured programming
and Cobol
Maintenance Tools
UNIT - IV
 Definitions

• Tool - implement or device used to carry out

functions automatically or manually.
• Software maintenance tool - an artifact used
to carry out automatically
• a function relevant to software change.
 Criteria for Selecting Tools
• There are several vendors developing and
marketing a wide variety of tools that claim to
support software maintenance.
• To acquiring a tool for software maintenance
work, there are a number of factors that
should be taken into consideration:
Capability
• This is one of the most important criteria to
consider when evaluating a tool.
• The tool must be capable of supporting the
task to be performed.
• When a technique or method is to be supported
by a tool, it is necessary to ensure first that it
works without a tool. that is, by hand.
• "if a technique doesn't work without automation,
it won't work with automation“ - By Davis
Features
• The features expected of any potential tool need to
be considered.
• Example: a useful word processor will need to
provide not just an editor, but also other features
such as a spelling checker, thesaurus, drawing and
search facilities.
• Similarly in maintenance, particular features may be
required of a tool.
• The importance of each of these features should be
rated and the tool selected accordingly.
Cost and benefits
• The cost of introducing a tool needs to be
weighed against the benefits.
• The benefits that the tool brings need to be
evaluated in terms of indicators such as product
quality, productivity, responsiveness, cost
reduction, and extent of overlap or dichotomy
between different groups with respect to their
way of doing things
Platform
• The platform refers to the specific hardware and
software environments on which the tool runs.
• Examples include: IBM mainframe and mini
platforms such as MVS and AS/400 respectively;
PC-based operating systems such as Macintosh
OS,MS-DOS and Windows; and LINUX and UNIX
variants.
• The platform where the tool is to be mounted
needs to be considered.
Programming language:
• This refers to the language that will be used
to write the source code.
• Examples include Java, Ada, C, C++,Cobol,
Fortran, Modula-2, Lisp and Prolog. To be on
the safe side, it is important to obtain a tool
that supports a language that is already (or is
likely to become) an industry standard.
Ease of use
• The ease with which users can get to grips with
the tool determines, to some extent, its
acceptability.
• Usually, a tool that has a similar 'feel' to the tools
that users are already familiar with tends to be
accepted more easily than one which is radically
different.
• For example, introducing a command-driven tool
into a menu-driven environment will cause more
problems for the users than a menu driven tool
 Openness of architecture
• The ability to integrate a tool with others from different
vendors plays a major role in its extensibility and
flexibility.
• Another reason for selecting a tool with an open
architecture is that in very complex maintenance
problems a single product from one vendor may not be
capable of performing all the required tasks.
• CASE tools provide support for code analysis but lack
the capability of extracting business rules from the
code.
Stability of vendor
• It is important to consider the reputation of
the vendor before acquiring a tool.
• It is essential to look into the background of
any company being considered as a supplier of
a tool. If the tool is one with an open
architecture then this factor may not be so
important.
 Organizational culture
• Organizations usually have a particular way
which they operate; a working culture and work
patterns.
• In order to increase the chances of the tool being
accepted by the target users , it is essential to take
such culture and work patterns into
consideration
 Taxonomy of Tools
• The categories of tasks for which tools will be
discussed are:
Program understanding and reverse engineering
Testing
Configuration management
Documentation and measurement
 Tools for Comprehension and Reverse
Engineering
• Program understanding and reverse engineering have been
combined because they are strongly linked.
• Program understanding involves having a general knowledge of
what a program does and how it relates to its environment;
identifying where in the system changes are to be effected; and
knowing how the different components to be modified work.
• Reverse engineering goes a step further by enabling analysis and
different representations of the system to promote that
understanding.
• Tools for reverse engineering and related tasks such as
redocumentation, design recovery, specification recovery and
reengineering also achieve the same goal
 Tools for Comprehension and Reverse
Engineering
• Examples of program understanding and
reverse engineering tools include
 Program slicer
 Static analyzer
 Dynamic analyzer
 Cross- referencer
Program Slicer
• The tool used to support slicing is known as a
program slicer
• The program slicer also displays data links and
related characteristics to enable the programmer
to track the effect of changes.
Static Analyzer
• A static analyzer allows derivation of this
information through careful and deep examination
of the program text. Some authors also refer to this
type of tool as a 'browser‘
• Generally, a static analyzer:
Allows general viewing of the program text - serves as a
browser;
Generates summaries of contents and usage of selected
elements in the program text such as variables or
objects.
Dynamic Analyzer
• A tool that can be used to support this process is
known as a dynamic analyzer.
• Generally, the dynamic analyzer allows a
maintainer to trace the execution path of
the system while it is running - it acts as a tracer.
• This permits the maintainer to determine the
paths that will be affected by a change and
those through which a change must be made
Data Flow Analyzer
• A data flow analyzer is a static analysis tool that allows
the maintainer to track all possible data flow and control
flow paths in the program and also to backtrack.
• This is particularly important when there is a need for
impact analysis:
• studying the effect of a change on other parts of the
system. By tracking the flow of data and control, the
maintainer can obtain information such as where a
variable obtained its value and which parts of the
program are affected by the modification of the variable.
• Generally, a data flow analyzer also:
• Allows analysis of program text to promote
understanding of the underlying logic of the
program;
• Assists in showing the relationship between the
different components of the system;
• Provides pretty-printers that allow the user to
select and display different views of the system.
Cross-Referencer
• The cross-referencer is a tool that generates
an index of the usage of a given program
entity. For example, it can produce
information on the declarations of a variable
and all the sections in the program in which it
• has been set and used.
 Dependency Analyser
• A dependency analyzer helps the maintainer
to analyze and understand the
interrelationships between entities in a
program.
• This tool is particularly useful in situations
where logically related entities, such as
variables, may be physically far apart in the
program.
• Generally, a dependency analyzer:
can provide capabilities that allow a maintainer to
set up and query a database of the dependencies
in a program. Information on
dependencies can also be used to determine the
effect of a change and to identify redundant
relationships between entities .
provides a graphical representation of the
dependencies in a program where the node in the
graph represents a program entity and an arc
represents the dependency between entities.
 Transformation Tool
• A transformation tool converts programs
between different forms of representations,
usually between text and graphics; for
example, transforming code to visual form and
vice versa
• The tool usually comes with a browser and
editor, which are used to edit the program in
any of its representations.
 Tools to Support Testing
• 1 Simulator
• Using a test simulator, a controlled
environment is set up for the testing to take
place. The system to be tested is simulated in
this environment and the appropriate set of
tests carried out. The set-up and components
of the environment will depend on the type of
application being tested.
 2.Test Case Generator
• Sets of test data used to test the functionality
of the system undergoing modification are
produced.
• The test data can be obtained from the
system as well as data files.
• The tool that assists in generating test data is
called a test data generator
 3.Test Paths Generator
• Prior to undertaking integration and unit
testing, it is important to know all the
potential data flow and control flow paths that
may have been affected by a change
• This information enables the maintainer to
carryout the appropriate set of tests to ensure
that a change has achieved the desired effect.
Tools to Support Configuration Management

• Effective configuration management is not

possible without the aid of some kind of
automated support tools in most maintenance
environments
• Keeping track of the objects produced during
modification to a software system is not a
trivial task. There may be thousands of files -
source files, binary files - and an enormous
amount of as sociated documentation.
 Scm
• Configuration management and version
control support tools act as a repository for
the objects that make up a software system. A
specific configuration is created by taking
objects - usually particular versions of source
files - out of a central repository and putting
them into a private work area.
 1.Source Code Control System
• Creation of a history file for a source code file on a
UNIX platform would involve the following steps:
• Renaming the original source code file in the
current directory.
• Creating the history file in the SCCS subdirectory.
• Performing an 'sees get' on the renamed source
code file to retrieve a read-only copy of the initial
version.
2.Other utilities
 Other Tasks
• Documentation
• As stressed throughout this book, the importance of documentation
for software maintenance cannot be over emphasised. Its importance
is reflected in the observation that lack of documentation is
considered to be one of the major problems that software maintainers
face
• Complexity Assessment
• A complexity quantifier is a tool used to measure the complexity of a
program. Such complexity measures are usually based on factors such
as the underlying algorithm of a program or its structure. Tools that
automatically generate, for example, McCabe's cyclomatic number can
be used to pinpoint where the software is too complex to be reliable
and to quantify the number of tests needed
 The Past and Present
• With time, software systems increasingly became an
integral part of the fabric of many organisations,
grew bigger and more complex, and their
maintenance consumed a significant proportion - up
to 70% - of the software life-cycle budget for these
organisations
• The two factors of rising maintenance costs and a
reduction in resources for development of new
systems marked a turning point in the treatment
and perception of software maintenance issues
 Research Areas
• 1.Classification
• Classification is a classic aid to understanding,
and classifying the elements of software
maintenance helps towards a deeper
understanding of the processes involved. Such
classification is not as straightforward as it
might appear. We have covered the topic to a
degree within this text,but work on effective
classification is on-going
2.Software Experience Bases
 3.Software Reuse
• Software reuse is an area of great potential
benefit to the software industry.
• Many of the reasons it is not yet achieving its
potential have not been fully explored - the
management of the reuse process, there
presentation of information appropriate to
reuse, the legal considerations and so on.
4.Support Tools
5.Software measurement
 6.Program Comprehension
• Teasley [265] provides thought-provoking insights
into areas of programmer behaviour that are
both very important and largely unexplored. She
argues that any comprehension task is affected
by three
major elements:
• 1. Who is doing the comprehending?
• 2. What are they comprehending?
• 3. Why do they want to comprehend?