Software Evolution and Maintenance

A Practitioner’s Approach

Chapter 4
Reengineering

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.1 General Idea
• Reengineering is the examination, analysis, and restructuring of
an existing software system to reconstitute it in a new form, and
the subsequent implementation of the new form.
• The goal of reengineering is to:
• understand the existing software system artifacts, namely,
specification, design, implementation, and documentation, and
• improve the functionality and quality attributes of the system.
• Software systems are reengineered by keeping one or more of the
following four general objectives in mind:
• Improving maintainability.
• Migrating to a new technology.
• Improving quality.
• Preparing for functional enhancement.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.2 Reengineering Concepts

• Abstraction and Refinement are two essential concepts used to

manage complexity and improve understanding during the reengineering process..

Abstraction: the process of simplifying complex software by identifying and

representing only the essential features while hiding unnecessary details.

Purpose in Reengineering:

 To help understand the system at a higher conceptual level.

 To extract design-level views (e.g., architecture, data flow) from code.
 Used heavily in reverse engineering to move from code to models.

Example: Extracting class diagrams from object-oriented code

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.2 Reengineering Concepts
Refinement: the process of adding details to an abstract representation to
eventually create a fully functional, low-level system.

Purpose in Reengineering:

 Used during forward engineering.

 Converts abstract designs or models into detailed code.
 Helps rebuild the software in a new environment or using modern techniques.

Example: Turning a high-level design (like a UML class diagram) into actual source
code

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.2 Reengineering Concepts
• Forward engineering: A new software is created by going
downward from the top, highest level of abstraction to the bottom,
lowest level.
• Forward engineering follows a sequence of activities: formulating
concepts about the system to identifying requirements to designing
the system to implementing the design.
• Reverse engineering the process of extracting knowledge or
design from existing software without having access to its original
design documentation.(i) analyze the software to determine its
components and the relationships among the components,

• Decompilation is an example of Reverse Engineering, in which

object code is translated into a high-level program.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.2 Reengineering Concepts

Aspect Reverse Engineering Forward Engineering

Direction Code → Models Models → Code

Understand & document existing

Purpose Build new or improved system
code

Activity Type Analysis Construction

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

Comparison between Forward Software Engineering and
Software Reengineering
Aspect Forward Software Engineering Software Reengineering
The process of analyzing, modifying, and improving existing
Definition The process of developing new software systems from scratch.
software.

Improve or adapt an existing system to enhance performance,

Objective Build a new system to meet user requirements.
maintainability, or adaptability.

Starts with existing source code and system documentation (if

Starting Point Starts with user requirements and design specifications.
available).

Reverse engineering, code restructuring, data migration,

Common Activities Requirements gathering, design, coding, testing, deployment.
documentation update.

Output A brand-new software system. An improved or restructured version of the existing system.

Typically lower cost than building a new system; lower risk if done
Risk and Cost Often higher risk and cost due to development from scratch.
well.

Time Requirement Generally longer since it involves full-cycle development. Often shorter, depending on the extent of reengineering required.

Legacy system modernization, performance improvement,

Use Cases New product development, when no previous system exists.
technology upgrades.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.2 Reengineering Concepts
• The concepts of abstraction and refinement are used to create models of software
development as sequences of phases, where the phases map to specific levels of
abstraction or refinement, as shown in Figure 4.1.
• The four levels are:
– Conceptual,
– Requirements,
– Design, and
– Implementation.

Figure 4.1 levels of abstraction and refinement

© IEEE, 1992
• The refinement process:
why? ! what? ! what & how? ! how?
• The abstraction process:
how? ! what & how? ! what? ! why?

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.3 A General Model For Software Reengineering
• The reengineering process accepts as input the existing code of a
system and produces the code of the renovated system.
• The reengineering process may be as straightforward as translating
with a tool the source code from the given language to source code
in another language.
• For example, a program written in BASIC can be translated into a
new program in C.
• The reengineering process may be very complex as explained
below:
• recreate a design from the existing source code.
• find the requirements of the system being reengineered.
• compare the existing requirements with the new ones.
• remove those requirements that are not needed in the renovated system.
• make a new design of the desired system.
• code the new system.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.3 A General Model For Software Reengineering
• The model in Figure 4.3 proposed by Eric J. Byrne suggests that
reengineering is a sequence of three activities:
– reverse engineering, re-design, and forward engineering
– strongly founded in three principles, namely, abstraction, alteration, and
refinement.

Figure 4.3 General model of software reengineering © IEEE, 1992

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.3 A General Model For Software Reengineering

• Another common term used by practitioners of reengineering is rehosting.

• Rehosting means reengineering of source code without addition or reduction of
features in the transformed targeted source code.
• Rehosting is most effective when the user is satisfied with the system’s
functionality, but looks for better qualities of the system.
• Examples of better qualities are improved efficiency of execution and reduced
maintenance costs.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.3.1 Types of Change
Based on the type of changes required, system characteristics are divided into
groups: rethink, respecify, redesign, and re-code.
Recode:
• Implementation characteristics of the source program are changed by re-coding it.
Source-code level changes are performed by means of rephrasing and program
translation.
• In the latter approach, a program is transformed into a program in a different language.
On the other hand, rephrasing keeps the program in the same language
• Examples of translation scenarios are compilation, decompilation, and migration.
• Examples of rephrasing scenarios are normalization, optimization, refactoring, and
renovation.
Redesign:
• The design characteristics of the software are altered by re-designing the
system. Common changes to the software design include:
(i) restructuring the architecture;
(ii) Modifying the data model of the system; and
(iii) replacing a procedure or an algorithm with a more efficient one.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.3.1 Types of Change
Respecify:
• This means changing the requirement characteristics of the system in two ways:
(i) change the form of the requirements, and
(ii) change the scope of the requirements.

Rethink:
• Re-thinking a system means manipulating the concepts embodied in an existing
system to create a system that operates in a different problem domain.
• It involves changing the conceptual characteristics of the system, and it can lead
to the system being changed in a fundamental way.
• Moving from the development of an ordinary cellular phone to the development
of smartphone system is an example of Re-think.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 • 4.4.1 Reengineering Approaches
There are five basic approaches to reengineering software systems.
Each approach advocates a different path to perform reengineering.
Several considerations are made while selecting a particular
reengineering approach:
 Objectives of the project;
 Availability of resources;
 The present state of the system being reengineered; and
 The risks in the reengineering project.

• The five approaches are different in two aspects:

(i) the extent of reengineering performed
(ii) the rate of substitution of the operational system with the new
one.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.4.1 Reengineering Approaches
Big Bang Approach
• The “Big Bang” approach replaces the whole system at once.(Immediate
Implementation)
• Once a reengineering effort is initiated, it is continued until all the objectives
of the project are achieved and the target system is constructed.
• This approach is generally used if reengineering cannot be done in parts.
• For example, if there is a need to move to a different system architecture, then
all components affected by such a move must be changed at once.
• The advantage is that the system is moved into its new environment all at
once.
• The disadvantage of Big Bang is that the reengineering project becomes a
monolithic task, which may not be desirable in all situations.
• In addition, the Big Bang approach consumes too much resources
(Employees, systems, process,…) at once for large systems, and takes a long
stretch of time before the new system I visible.(Massive Organizational
Impact)

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.4.1 Reengineering Approaches
Incremental Approach
• In this approach a system is reengineered gradually, one step closer to the
target system at a time.
• For a large system, several new temporary versions are produced and
released.
• Successive temporary versions satisfy increasingly more project goals than
their preceding versions.
• The advantages of this approach are as follows:
(i) locating errors becomes easier, because one can clearly identify the
newly added components, and
(ii) It becomes easy for the customer to notice progress (forward
movement), because interim versions are released.
• The disadvantages of the incremental approach are as follows:
(i) with multiple interim versions and their careful version controls, the
incremental approach takes much longer to complete, and
(ii) even if there is a need, the entire architecture of the system cannot be
changed.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.4.1 Reengineering Approaches
Partial Approach
• In this approach, only a part of the system is reengineered and then it is integrated
with the non-engineered portion of the system.
• One must decide whether to use a “Big Bang” approach or an “Incremental”
approach for the portion to be reengineered.
• The following three steps are followed in the partial approach:
• In the first step, the existing system is partitioned into two parts: one part is
identified to be reengineered and the remaining part to be not reengineered.
• In the second step, reengineering work is performed using either the “Big
Bang” or the “Incremental” approach.
• In the third step, the two parts, namely, the not-to-be-reengineered part and the
reengineered part of the system, are integrated to make up the new system.
• The advantage of reducing the scope of reengineering to a level that best matches
an organization’s current need and desire to spend a certain amount of
resources.(less time and costs less. )
• A disadvantage of the partial approach is that modifications are not performed to
the interface between the portion modified and the portion not modified.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.4.1 Reengineering Approaches
Iterative Approach
• The reengineering process is applied on the source code of a few procedures at
a time, with each reengineering operation lasting for a short time.
• This process is repeatedly executed on different components in different stages.
• During the execution of the process, ensure that the four types of components
can live together for the operational continuity of the system:
– old components not reengineered,
– components currently being reengineered,
– components already reengineered, and
– new components added to the system.
• There are two advantages of the iterative reengineering process:
(i) it guarantees the continued operation of the system during the execution of
the reengineering process, and
(ii) the maintainers’ and the users’ familiarities with the system are preserved.
• The disadvantage of this approach is the need to keep track of the four types of
components during the reengineering process.
• In addition, both the old and the newly reengineered components need to be
maintained.

Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik

 4.4.1 Reengineering Approaches
Evolutionary Approach
• In the ”Evolutionary” approach components of the original system are
substituted with re-engineered components.
• In this approach, the existing components are grouped by functions and
reengineered into new components.
• Software engineers focus their reengineering efforts on identifying functional
objects regardless of the locations of those components within the current
system.
• As a result, the new system is built with functionally cohesive components as
needed.
• There are two advantages of the “Evolutionary” approach:
(i) the resulting design is more cohesive, and
(ii) the scope of individual components is reduced.
• A major disadvantage:
(i) all the functions with much similarities must be first identified throughout
the operational system.
(ii) next, those functions are refined as one unit in the new system.
Software Evolution and Maintenance (Chapter 4: Reengineering) © Tripathy & Naik