SOFTWARE ENGINEERING

MODULE 3
SOFTWARE MAINTENANCE
 Software maintenance is a part of the Software Development Life
Cycle. Its primary goal is to modify and update software application
after delivery to correct errors and to improve performance.
Software is a model of the real world. When the real world changes,
the software require alteration wherever possible.

 Software Maintenance is an inclusive activity that includes error

corrections, enhancement of capabilities, deletion of obsolete
capabilities, and optimization
 Need for Maintenance

• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.
• Accommodate programs so that different hardware, software,
system features, and telecommunications facilities can be used.
• Migrate legacy software.
• Retire software.
• Requirement of user changes.
• Run the code fast
Types of Software Maintenance
 There are three types of software maintenance, which are described as
follows:

1. Corrective Maintenance

2. Adaptive Maintenance

3. Perfective Maintenance
 Types of Software Maintenance
1. Corrective:

Corrective maintenance of a software product is necessary either to rectify the

bugs observed while the system is in use.

2. 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.

3. 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.
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.

 Reverse engineering is becoming important, since legacy software products

lack proper documentation, and are highly unstructured.

 Even well-designed products become legacy software as their structure

degrades through a series of maintenance efforts.
 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.
 A way to carry out these cosmetic changes is shown schematically in Figure
13.1.

 A program can be reformatted using any of the several available prettyprinter

programs which layout the program neatly.

 Many legacy software products are difficult to comprehend with complex

control structure and unthoughtful variable names.

 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
process of extracting the code, design, and the requirements specification can
begin.
 These activities are schematically shown in Figure 13.2.

 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
 Before discussing process models for software maintenance, we need to analyse
various activities involved in a typical software maintenance project.

 The activities involved in a 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.)

iv. 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.
 However, more elaborate activities are required when the required changes are not
so trivial.

 Usually, for complex maintenance projects for legacy systems(outdated computing

software or hardware that is still in use), the software process can be represented
by a reverse engineering cycle followed by a forward engineering cycle with an
emphasis on as much reuse as possible from the existing code and other
documents.

 Since the scope (activities required) for different maintenance projects vary
widely, no single maintenance process model can be developed to suit every kind of
maintenance project.

 However, two broad categories of process models can be proposed.

 First Model

 Second model
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.

 This maintenance process is graphically presented in Figure 13.3.

 In this approach, 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.

 The availability of a working old system to the maintenance engineers at the

maintenance site greatly facilitates the task of the maintenance team as they get a good
insight into the working of the old system and also can compare the working of their
modified system with the old system.
➢ Also, debugging of the re-engineered system becomes easier as the program
traces of both the systems can be compared to localize 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. This process model is

depicted in Figure 13.4.

 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.
 The efficiency improvements are brought about by a more efficient design.
However, this approach is more costly than the first approach.
 An empirical study indicates that process 1 is preferable when the amount of
rework is no more than 15 per cent (see Figure 13.5).
 Besides the amount of rework, several other factors might affect the decision
regarding using process model 1 over process model 2 as follows:

• Re-engineering might be preferable for products which exhibit a high

failure rate.

• Re-engineering might also be preferable for legacy products having poor

design and code structure.
ESTIMATION OF MAINTENANCE COST
 We had earlier pointed out that maintenance efforts require about 60 per cent of
the total life cycle cost for a typical software product.

 However, maintenance costs vary widely from one application domain to another.

 For embedded systems, the maintenance cost can be as much as 2 to 4 times the
development 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.
 Thus, the code that is changed, should be counted in both the code added and
code deleted.

 where, KLOCadded is the total kilo lines of source code added during
maintenance. KLOCdeleted is the total KLOC deleted during maintenance.
 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 engineers with the product,
hardware requirements, software complexity, etc.
 General form of the COCOMO expressions. The basic COCOMO model is a single
variable heuristic model that gives an approximate estimate of the project
parameters.
 The basic COCOMO estimation model is given by expressions of the following
forms:
 Effort = a1 × (KLOC)a2 PM
 Tdev = b1 × (Effort)b2 months
 where,
 KLOC is the estimated size of the software product expressed in Kilo Lines Of
Code.
 a1, a2, b1, b2 are constants for each category of software product.
 Tdev is the estimated time to develop the software, expressed in months.
 Effort is the total effort required to develop the software product, expressed in
person- months (PMs).
OBJECT MODELLING USING UML
Module 3
 Once a good design has been arrived at, it is easy to code it using an object-
oriented language.

 It has now even become possible to automatically generate much of the code from
the design by using a CASE tool.

 In order to arrive at a satisfactory object-oriented design (OOD) solution to a

problem, it is necessary to create several types of models.

 But, one may ask: “What has modelling got anything to do with designing?”

 Let us answer this question in the following:

• Note that any design is a model of the solution, whereas any model of the problem is
an analysis model.

• In the context of model construction, we need to carefully understand the distinction

between a modelling language and a design process, since we shall use these two
terms frequently in our discussions.

• Modelling language: A modelling language consists of a set of notations using which

design and analysis models are documented.

• Design process: A design process addresses the following issue: “Given a problem
description, how to systematically work out the design solution to the problem?” In
other words, a design process consists of a step by step procedure (or recipe) using
which a problem description can be converted into a design solution. A design
process is, at times, also referred to as a design methodology.
• A model can be documented using a modelling language such as Unified
Modelling Language (UML).

• Over the last decade, UML has become immensely popular. UML has also been
accepted by ISO as a standard for modelling object-oriented systems.

• In this Chapter, we primarily discuss the syntax and semantics of UML. However,
before discussing the nitty- gritty of the syntax and semantics of UML, we review
a few basic concepts and terminologies that have come to be associated with
object-orientation.
BASIC OBJECT-ORIENTATION CONCEPTS
 The principles of object-orientation have been founded on a few simple
concepts. These concepts are pictorially shown in Figure 7.1.
Basic Concepts
➢ Objects
 In the object-oriented approach, it is convenient to imagine the working of a software in
terms of a set of interacting objects.

 This is analogous to the way object manipulations take place in a real-world manual
system for getting some work done.

 For example, consider a manually operated library system. For issuing a book, an issue
register needs to be filled up and then the return date needs to be stamped on the book.

 In an object-oriented library automation software, analogous activities involving the book

object and the issue register object take place.

 Each object in an object-oriented program usually represents a real-world entity such as a

library member, a book, an issue register, etc.
 However while solving a problem, it becomes advantageous at times to consider certain
conceptual entities (e.g., a scheduler, a controller, etc.) as objects as well. This
simplifies the solution and helps to arrive at a good design.

 A key advantage of considering a system as a set of objects is the following:

 When the system is analysed, developed, and implemented in terms of objects, it

becomes easy to understand the design and the implementation of the system, since
objects provide an excellent decomposition of a large problem into small parts.

 Each object essentially consists of some data that is private to the object and a set of
functions (termed as operations or methods ) that operate on those data.

 This aspect has pictorially been illustrated in Figure 7.2. Observe that the data of the
object can only be accessed by the methods of the object.

 Consequently, the only access point to the data for the external objects is through the
invocation of the methods of the object.
 In fact, the methods of an object have the sole authority to operate on the data
that is private to the object.

 In other words, no object can directly access the data of any other object.
Therefore, each object can be thought of as hiding its internal data from other
objects.

 However, an object can access the private data of another object by invoking the
methods supported by that object.

 This mechanism of hiding data from other objects is popularly known as the principle
of data hiding or data abstraction.

 Data hiding promotes high cohesion and low coupling among objects, and therefore
is considered to be an important principle that can help one to arrive at a reasonably
good design.
 As already mentioned, each object stores some data and supports certain
operations on the stored data.

 As an example, consider the libraryMember object of a library automation

application.

 The private data of a libraryMember object can be the following: • name of the
member

• membership number
• address
• phone number
• e-mail address
• date when admitted as a member
• membership expiry date
• books outstanding
 The operations supported by a libraryMember object can be the following:
• issue-book
• find-books-outstanding
• find-books-overdue
• return-book
• find-membership-details
 The data stored internally in an object are called its attributes, and the
operations supported by an object are called its methods.
 Class
 Similar objects constitute a class. That is, all the objects constituting a class possess similar
attributes and methods.

 For example, the set of all library members would constitute the class LibraryMember in a library
automation application. In this case, each library member object has attributes such as member
name, membership number, member address, etc. and also has methods such as issue-book,
returnbook, etc.

 Once we define a class, it can be used as a template for object creation.

 Let us now examine whether a class supports the two mechanisms of an ADT.

 Abstract data:

The data of an object can be accessed only through its methods. In other words, the exact way data is stored
internally (stack, array, queue, etc.) in the object is abstracted out (not known to the other objects).
 Data type:

In programming language terminology, a data type defines a collection of data values and a set
of predefined operations on those values. Thus, a data type can be instantiated to create a
variable of that type.

 We can instantiate a class into objects.

 Therefore, a class is a data type. It can be inferred from the above discussions that a class
is an ADT. But, an ADT need not be a class, since to be a class they need to support the
inheritance and other object-orientation properties.

 Methods
The operations (such as create, issue, return, etc.) supported by an object are implemented in
the form of methods. Notice that we are distinguishing between the terms operation and
method. Though the terms ‘operation’ and ‘method’ are sometimes used interchangeably,
there is a technical difference between these two terms which we explain in the following.
 An operation is a specific responsibility of a class, and the responsibility is
implemented using a method. However, it is at times useful to have multiple methods
to implement a responsibility.

 In this case, all the methods share the same name (that is, the name of the
operation), but parameter list of each method is required to be different for enabling
the compiler to determine the exact method to be bound on a method call. We
therefore say that in this case, the method name is overloaded with multiple
implementations of the operation.
 Class Relationships

• Classes in a programming solution can be related to each other in the following

four ways:

 Inheritance

 Association and link

 Aggregation and composition

 Dependency
 Inheritance
 The inheritance feature allows one to define a new class by incrementally extending
the features of an existing class.

 The original class is called the base class (also called superclass or parent class ) and
the new class obtained through inheritance is called the derived class (also called a
subclass or a child class ).

 The derived class is said to inherit the features of the base class.

 An example of inheritance has been shown in Figure 7.3.

 In Figure 7.3, observe that the classes Faculty, Students, and Staff have been derived
from the base class LibraryMember through an inheritance relationship (note the
special type of arrow that has been used to draw it).
 The inheritance relation between library member and faculty can alternatively be
expressed as the following—A faculty is a type of library member.

 So, the inheritance relationship is also at times called is a relation.

 A base class is said to be a generalisation of its derived classes. This means that
the base class should contain only those properties (i.e., data and methods) that
are common to all its derived classes.
 For example, in Figure 7.3 each of the derived classes supports the issue-book
method, and this method is supported by the base class as well.
 In other words, each derived class is a specialised base class that extends the
base class functionalities in certain ways.

 Each derived class can be considered as a specialisation of its base class because it
modifies or extends the basic properties of the base class in certain ways.
 Therefore, the inheritance relationship can be viewed as a generalisation-
specialisation relationship.

 Two important advantages of using the inheritance mechanism in programming

include code reuse and simplicity of program design.

Association and link
 Association is a common type of relation among classes. When two classes are

associated, they can take each others help (i.e. invoke each others methods) to serve
user requests.
 More technically, we can say that if one class is associated with another

bidirectionally, then the corresponding objects of the two classes know each others
ids (identities).
 As a result, it becomes possible for the object of one class to invoke the methods of

the corresponding object of the other class.

 Binary association:
 Consider the following example. A Student can register in one Elective

subject. In this example, the class Student is associated with the class
ElectiveSubject. Therefore, an ElectiveSubject object (e.g. Machine Learning)
would know the ids of all Student objects that have registered for the Subject
and can invoke their methods such as printName, printRoll and enterGrade.

 The association relationship can either be bidirectional or unidirectional. That is,

both the associated classes know each other (store each others ids).
• n-ary association

• Binary association between classes is very commonly encountered in design problems.

• However, there can be situations where three or more different classes can be involved
in an association.

• As an example of a ternary association, consider the following—

• A person books a ticket for a certain show. Here, an association exists among the classes
Person, Ticket, and Show. This example of ternary association relationship has
pictorially been shown in Figure 7.5(b).
• A class can have an association relationship with itself. This is called recursive
association or unary association. As an example, consider the following—two students

may be friends. Here, an association named friendship exists among pairs of objects of

the Student class. This has pictorially been shown in Figure 7.5(c).

 In unary association, two (or more) different objects of the same class are linked by

the association relationship. When two classes are associated, the relationship

between two objects of the corresponding classes is called a link.

• An association describes a group of similar links. Alternatively, we can say that a link

can be considered as an instance of an association relation.

Composition and aggregation
 Composition and aggregation represent part/whole relationships among objects.

 Objects which contain other objects are called composite objects.

 As an example, consider the following—A Book object can have upto ten Chapters. In
this case, a Book object is said to be composed of upto ten Chapter objects.

 The composition/aggregation relationship can also be read as follows—A Book has upto

ten Chapter objects (shown in Figure 7.6).

 The composition/aggregation relationship is also known as Has-a relationship.

 Aggregation/composition can occur in a hierarchy of levels.

 That is, an object contained in another object may itself contain some other
object.

 Composition and aggregation relationships cannot be reflexive.

 That is, an object cannot contain an object of the same type as itself.
Dependency
 A class is said to be dependent on another class, if any changes to the latter class
necessitates a change to be made to the dependent class.
 A dependency relation between two classes shows that any change made to the
independent class would require the corresponding change to be made to the
dependent class.
 Dependencies among classes may arise due to various causes.

 Two important reasons for dependency to exist between two classes are the following:

 A method of a class takes an object of another class as an argument.

 A class implements an interface class. In this case, dependency arises due to the
following reason. If some properties of the interface class are changed, then a
change becomes necessary to the class implementing the interface class as well.
Abstraction
 Abstraction is the selective examination of certain aspects of a problem while
ignoring all the remaining aspects of a problem.

 In other words, the main purpose of using the abstraction mechanism is to consider
only those aspects of the problem that are relevant to a given purpose and to
suppress all aspects of the problem that are not relevant.

 The abstraction mechanism allows us to represent a problem in a simpler way by

considering only those aspects that are relevant to some purpose and omitting all
other details that are irrelevant.

 An important advantage of the principle of data abstraction is that it reduces

coupling among various objects, Therefore, it leads to a reduction of the overall
complexity of a design, and helps in easy maintenance and code reuse.
Encapsulation
 The data of an object is encapsulated within its methods. To access the data

internal to an object, other objects have to invoke its methods, and cannot directly

access the data.

 This concept is schematically shown in Figure 7.8.

 Observe from Figure 7.8 that there is no way for an object to access the data

private to another object, other than by invoking its methods.

 Encapsulation offers the following three important advantages:

 Protection from unauthorized data access: The encapsulation feature protects an
object’s variables from being accidentally corrupted by other objects. This protection

includes protection from unauthorized access and also protection from the problems that

arise from concurrent access to data such as deadlock and inconsistent values.

 Data hiding: Encapsulation implies that the internal structure data of an object are
hidden, so that all interactions with the object are simple and standardized. This

facilitates reuse of a class across different projects. Furthermore, if the internal data or

the method body of a class are modified, other classes are not affected. This leads to

easier maintenance and bug correction.

 Weak coupling: Since objects do not directly change each others internal data, they
are weakly coupled. Weak coupling among objects enhances understandability of the

design since each object can be studied and understood in isolation from other objects.
Polymorphism
 Polymorphism literally means poly ( many ) morphism (forms).

 Remember that in Chemistry, diamond, graphite, and coal are called polymorphic forms

of carbon.

 That is, though diamond, coal, and graphite are essentially carbon, they behave very

differently.

 In an analogous manner in the object-oriented paradigm, polymorphism denotes that an

object may respond (behave) very differently even when the same operation is invoked

on it depending on the exact polymorphic object to which the call gets bound.

 There are two main types of polymorphisms in object-orientation

 Static polymorphism: Static polymorphism occurs when multiple methods
implement the same operation. In this type of polymorphism, when a method is

called (same method name but different parameter types), different behavior

(actions) would be observed. This type of polymorphism is also referred to as static

binding, because the exact method to be bound on a method call is determined at

compiled-time (statically).

 Dynamic polymorphism: Dynamic polymorphism is also called dynamic binding. In

dynamic binding, the exact method that would be invoked (bound) on a method call

can only be known at the run time (dynamically) and cannot be determined at

compile time. That is, the exact behaviour that would be produced on a method call

cannot be predicted at compile time and can only be observed at run time.
Advantages and Disadvantages of OOD
 In the last couple of decades since OOD has come into existence, it has found
widespread acceptance in industry as well as in academic circles.

 The main reason for the popularity of OOD is that it holds out the following
promises:

 Code and design reuse

 Increased productivity

 Ease of testing and maintenance

 Better code and design understandability enabling development of large programs

Disadvantages of OOD
The following are some of the prominent disadvantages inherent to the object paradigm:

 The principles of abstraction, data hiding, inheritance, etc. do incur run time
overhead due to the additional code that gets generated on account of these
features. This causes an project-oriented program to run a little slower than an
equivalent procedural program.

 An important consequence of object-orientation is that the data that is

centralized in a procedural implementation, gets scattered across various objects
in an object-oriented implementation. Therefore, the spatial locality of data
becomes weak and this leads to higher cache miss ratios and consequently to
larger memory access times. This finally shows up as increased program run time.