Re engineering

Re engineering
• Software Re-engineering is a process of software development which is done to
improve the maintainability of a software system. Re-engineering is the examination
and alteration of a system to reconstitute it in a new form.
• Steps involved in Re-engineering.
• Inventory Analysis 
• Document Reconstruction 
• Reverse Engineering 
• Code Reconstruction 
• Data Reconstruction 
• Forward Engineering 
• 
Dynamic representation
Re engineering
• Re engineering cost factors:
• The quality of the software to be re-engineered
• The tool support available for re-engineering
• The extent of the required data conversion
• The availability of expert staff for re-engineering
Re engineering
• Reengineering is done to transform an existing “lesser or simpler”
system into a new “better” system.
• 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.
• Jacobson and Lindstorm defined following formula:
Reengineering = Reverse engineering + + Forward engineering.
• Reverse engineering is the activity of defining a more abstract, and easier to
understand, representation of the system
• The core of reverse engineering is the process of examination, not a process of
change, therefore it does not involve changing the software under examination.
• The third element “forward engineering,” is the traditional process of moving
from high-level abstraction and logical, implementation-independent designs to
the physical implementation of the system.
• The second element captures alteration that is change of the system.
Reverse and forward engineering
• Reverse engineering, sometimes called back engineering, is a process
in which software, machines, aircraft, architectural structures and
other products are deconstructed to extract design information from
them. Often, reverse engineering involves deconstructing individual
components of larger products. The reverse engineering process
enables you to determine how a part was designed so that you can
recreate it.
• The reverse engineering process is named as such because it involves
working backward through the original design process.
Reverse and forward engineering
• Forward Engineering is a method of creating or making an application
with the help of the given requirements. Forward engineering is also
known as Renovation and Reclamation. Forward engineering is
required high proficiency skills. It takes more time to construct or
develop an application.
• 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.
 • Abstraction and Refinement are key concepts
used in software development, and both the
concepts are equally useful in reengineering.
• Abstraction is concerned with hiding lower levels of
detail; it moves from lower to higher levels. 
• It may be recalled that abstraction enables
software maintenance personnel to reduce the
complexity of understanding a system by:
(i) focusing on the more significant
information about the system; and
(ii) Hiding the irrelevant details now.
• On the other hand, refinement is the reverse
of abstraction.
Reengineering Concepts

Principle of abstraction: The level of

abstraction of the representation of a system
can be gradually increased by successively
replacing the details with abstract information.
By means of abstraction one can produce a
view that focuses on selected system
characteristics by hiding information about
other characteristics.
• Principle of refinement: The level of
refinement of the representation of the system
is gradually decreased by successively
replacing some aspects of the system with
more details.
• Refinement is the movement from higher
levels of detail to lower levels. Both
concepts are necessary in developing
software.
 • A new software is created by
going downward from the
top, highest level of
abstraction to the bottom,
lowest level. This downward
movement is known as
forward engineering.
• Forward engineering follows
a sequence of activities:
1.2 Reengineering Concepts

formulating concepts about

the system to identifying
requirements to designing the
system to implementing the
design.
• Forward Engineering is a
method of creating or making
an application with the help
of the given requirements.
Forward engineering is also
known as Renovation and
Reclamation. Forward
engineering is required high
proficiency skills. It takes
more time to construct or
develop an application.
Reverse and forward engineering

• On the other hand, the upward movement through the layers of abstractions is called
reverse engineering.
• Reverse engineering of software systems is a process comprising the following steps:
(i) analyze the software to determine its components and the relationships among the components,
(ii) represent the system at a higher level of abstraction or in another form.
• Reverse engineering, sometimes called back engineering, is a process in which software,
machines, aircraft, architectural structures and other products are deconstructed to extract
design information from them. Often, reverse engineering involves deconstructing individual
components of larger products. The reverse engineering process enables you to determine
how a part was designed so that you can recreate it.
• The reverse engineering process is named as such because it involves working backward
through the original design process.
• De-compilation is an example of Reverse Engineering, in which object
code is translated into a high-level program.
 Figure 4.1 levels of abstraction and refinement

• 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,
Reengineering Concepts

•
• Requirements,
• Design, and
• Implementation.
• The refinement process:
why? ! what? ! what & how? !
how?
• The abstraction process:
how? ! what & how? !
what? ! why?
 Figure 4.2 Conceptual basis for the
reengineering process

• An optional principle called alteration

underlies many reengineering methods.
• Principle of alteration: The making of some
Reengineering Concepts

changes to a system representation is known

as alteration. Alteration does not involve any
change to the degree of abstraction, and it
does not involve modification, deletion, and
addition of information.
• Reengineering principles are represented by
means of arrows. Abstraction is represented
by an up-arrow, alteration is represented by
a horizontal arrow, and refinement by a
down-arrow.
• The arrows depicting refinement and
abstraction are slanted, thereby indicating
the increase and decrease, respectively, of
system information.
• It may be noted that alteration is non-
essential for 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
A General Model For Software Reengineering

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.
 • The
model in
A General Model For Software Reengineering

Figure
proposed
by Eric J.
Byrne
Figure 4.3 General model of software reengineering

suggests
that
reengine
ering is a
sequence
of three
activities:
– reverse
engine
ering,
re-
design,
and
forwar
d
engine
ering
–
strongl
y
founde
d in
three
principl
es,
namely
,
abstrac
tion,
alterati
on, and
refine
ment.
 • A visual
metaph
or called
horsesh
oe, as
depicted
in Figure
4.4, was
develop
ed by
Figure 4.4 Horseshoe model of reengineering

Kazman
et al. to
describe
a three-
step
architect
ural
reengine
ering
process.
• Three
distinct
segment
s of the
horsesh
oe are
the left
side, the
A General Model For Software Reengineering

top part,
and the
right
side.
Those
three
parts
denote
the
three
steps of
the
reengine
ering
process.
 Now, we are in a position to re-visit three definitions of
reengineering.
• The definition by Chikofsky and Cross II:
Software reengineering is the analysis
and alteration of an operational system
to represent it in a new form and to
A General Model For Software Reengineering

obtain a new implementation from the

new form. Here, a new form means a
representation at a higher level of
abstraction.
• The definition by Byrne: Reengineering
of a software system is a process for
creating a new software from an
existing software so that the new
system is better than the original
system in some ways.
• The definition by Arnold: Reengineering
of a software system is an activity that:
(i) improves the comprehension of the
software system, or (ii) raises the
quality levels of the software, namely,
performance, reusability, and
maintainability.
 • In summary, it is evident that reengineering
entails:
(i) the creation of a more abstract view of the system
by means of some reverse engineering activities,
(ii) the restructuring of the abstract view, and
(iii) implementation of the system in a new form by
means of forward engineering activities.
• This process is formally captured by Jacobson
and Lindstorm with the following expression:
Reengineering = Reverse engineering +
Δ + Forward engineering.
• The element “Δ” captures alterations made to
the original system.
• Two major dimensions of alteration are: change
in functionality and change in implementation
A General Model For Software Reengineering

technique.
• A change in functionality comes from a change
in the business rules,
• Next, concerning a change of implementation
technique, an end-user of a system never
knows if the system is implemented in an
object-oriented language or a procedural
language.
 • 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
A General Model For Software Reengineering

system’s functionality,
but looks for better
qualities of the system.
• Examples of better
qualities are improved
efficiency of execution
and reduced
maintenance costs.
 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.
Types of Change

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.
 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
Types of Change

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.
 Three strategies
that specify the
basic steps of
reengineering
are rewrite,
Software Reengineering Strategies

rework, and
Figure 4.5 Conceptual basis for reengineering strategies

replace.
Rewrite strategy:
This strategy
reflects the
principle of
alteration. By
means of
alteration, an
operational
system is
transformed
into a new
system, while
preserving the
abstraction level
of the original
system. For
example, the
Fortran code of
a system can be
rewritten in the
C language.
 Rework strategy:
• The rework strategy applies
all the three principles.
• Let the goal of a
Figure 4.5 Conceptual basis for reengineering strategies

reengineering project is to
Software Reengineering Strategies

replace the unstructured

control flow constructs,
namely GOTOs, with more
commonly used structured
constructs, say, a “for” loop.
• A classical, rework strategy
based approach is as follows:
• Application of abstraction:
By parsing the code,
generate a control-flow
graph (CFG) for the given
system.
• Application of alteration:
Apply a restructuring
algorithm to the control-
flow graph to produce a
structured control-flow
graph.
• Application of refinement:
Translate the new,
structured control-flow
graph back into the original
programming language.
 Replace strategy:
• The replace strategy
applies two principles,
namely, abstraction and
refinement.
Figure 4.5 Conceptual basis for reengineering strategies
Software Reengineering Strategies

• To change a certain
characteristic of a system:
(i) the system is
reconstructed at a
higher level of
abstraction by hiding
the details of the
characteristic; and
(ii) a suitable
representation for the
target system is
generated at a lower
level of abstraction by
applying refinement.
• Let us reconsider the
GOTO example. By means
of abstraction, a program
is represented at a higher
level without using
control flow concepts.
• Next, by means of
refinement, the system is
represented at a lower
level of abstraction with a
new structured control
flow.
Reengineering Variations
 Figure 4.8 Software reengineering process phases

• The phase
model of
software
reengineerin
g was
originally
proposed by
Byrne and
Gustafson.
• The model
comprises
Phase Reengineering Model

five phases:
analysis and
planning,
renovation,
target
system
testing,
redocument
ation, and
acceptance
testing and
system
transition, as
depicted in
Figure 4.8.
• The labels

• Tasks represent a phase’s

• A major process activity is

further decomposed to reveal

activities, and tasks can be
on the arcs

the detailed methodologies.

represented by each phase.
denote the
possible
information
that flows
from the tail
entities of
the arcs to
the head
entities.
 Analysis and planning:
• Analysis addresses three technical and
one economic issue.
The first technical issue concerns the
Phase Reengineering Model

•
present state of the system to be
reengineered and understanding its
properties.
• The second technical issue concerns the
identification of the need for the system
to be reengineered.
• The third technical issue concerns the
specification of the characteristics of the
new system to be produced.
• The economic issue concerns a cost and
benefit analysis of the reengineering
project.
• Planning includes:
• understanding the scope of the work;
• identifying the required resources;
• identifying the tasks and milestones;
• estimating the required effort; and
• preparing a schedule.
Phase Reengineering Model
 Renovation:
• An operational system is modified into
the target system in the renovation
phase.
• Two main aspects of a system are
considered in this phase:
Phase Reengineering Model

(i) representation of the system.

It refers to source code, but it may
include the design model and the
requirement specification of the existing
system.
(ii) representation of external data.
It refers to the database and/or data files
used by the system. Often the external
data are reengineered, and it is known as
data reengineering.
• An operational system can be renovated
in many ways, depending upon the
objectives of the project, the approach
followed, and the starting representation
of the system.
• It may be noted that the starting
representation can be source code,
design, or requirements.
• Table 4.1 discussed earlier recommends
several alternatives to renovate a system.
 Figure 4.9 Replacement strategies for recording

Renovation:
Example
• A project in which
the objective is to
re-code the system
from C to C++.
• Figure 4.9 shows the
three possible
replacement
strategies.
Phase Reengineering Model

• First, to perform
source-to-source
translation, program
migration is used.
• Second, a high-level
design is
constructed from
the operational
source code, say, in
C, and the resulting
design is re-
implemented in the
target language, C++
in this case.
• Finally, a mix of
compilation and
decompilation is
used to obtain the
system
implementation in C
 Target system
testing:
• In this phase for system
testing, faults are
detected in the target
system.
• Those faults might have
been introduced during
reengineering.
• Fault detection is
performed by applying
Phase Reengineering Model

the target system test

plan on the target
system.
• The same testing
strategies, techniques,
methods, and tools that
are used in software
development are used
during reengineering.
• For example, apply the
existing system-level
test cases to both the
existing and the new
system.
• If the two systems have
identical requirements,
the test results from
both scenarios must be
the same.
 Redocumentation:
• In the redocumentation phase,
documentations are rewritten,
updated, and/or replaced to reflect
the target system.
Phase Reengineering Model

• Documents are revised according to

the redocumentation plan.
• The two major tasks within this
phase are:
(i) analyze new source code, and
(ii) create documentation.
• Documents requiring revision are:
• requirement specification.
• design documentation.
• a report justifying the design
decisions, assumptions made in the
implementation.
configuration.
• user and reference manuals.
• on-line help.
• document describing the
differences between the existing
and the target system.
 Acceptance and system
transition:
• In this final phase, the
reengineered system is
evaluated by performing
acceptance testing.
• Acceptance criteria should
already have been
established in the beginning
of the project.
Should the reengineered
Phase Reengineering Model

•
system pass those tests,
preparation begins to
transition to the new system.
• On the other hand, if the
reengineered system fails
some tests, the faults must
be fixed; in some cases,
those faults are fixed after
the target system is
deployed.
• Upon completion of the
acceptance tests, the
reengineered system is
made operational, and the
old system is put out of
service.
• System transition is guided
by the prior developed
transition plan.