Software

Reengineering

Dr. Ruqia Bibi

1
A GENERAL MODEL FOR
SOFTWARE REENGINEERING
(Recap)
 The process is formally captured with the following
expression:

Reengineering=Reverse engineering + Δ + Forward

engineering.

 “Δ” captures alterations made to the original system.

2
Types of Changes
 Based on the type of changes required, system
characteristics are divided into groups:

 Recode:
 Rephrasing
 normalization, optimization, refactoring,
 Program translation
 compilation, decompilation, and migration

 Redesign
 Restructuring the architecture;
 Modifying the data model of the system;
 Replacing a procedure or an algorithm with a more efficient one.

3
Types of Changes
 Based on the type of changes required, system
characteristics are divided into groups:

 Re-specify:
 change the form of the requirements
 change the scope of the requirements.

 Rethink.:
 manipulating the concepts embodied in an existing system to
create a system that operates in a different problem domain.

4
Software Reengineering
Strategies
Strategies are founded on three fundamental principles in software
engineering, namely, abstraction, alteration, and refinement

 Rewrite strategy:
 principle of alteration.
 operational system is transformed into a new system while
preserving the abstraction level of the original system.
 Rework strategy:
 based on the principles of abstraction, alteration, and refinement
 Replace strategy:
 applies two principles, namely, abstraction and refinement

5
6
Rework Strategy Example
 Let the goal of a reengineering project be to restructure the control
flow of a program.

 Specifically, we want to replace the unstructured control flow

constructs, namely GOTOs, with more commonly used structured
constructs, say, a “for” loop.

 A classical, rework strategy-based approach to doing that is as

follows:

7
Rework Strategy Example
 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 CFG to produce a structured
CFG.

 Application of refinement:
 Translate the new, structured CFG back into the original
programming language.

8
Re-engineering Variations
 The reengineering strategies and the change types can be combined to
create different process variations. Three process factors cause variability in
reengineering processes:
 the level of abstraction of the system representation under consideration;
 the kind of change to be made: rethink, respecify, redesign, and recode; and
 the reengineering strategy to be applied: rewrite, rework, and replace.

 Possible variations in reengineering processes have been identified in Table

below.
 The table is interpreted by asking questions of the following type: If A is the
abstraction level of the representation of the system to be reengineered and
the plan is to make a B type of change, can I use strategy C?

9
10
11
Source Code Reengineering
Reference Model

12
Source Code Reengineering
Reference
Encapsulation: Model
 A reference baseline is created from the original source code.
 The goal of the reference baseline is to uniquely identify a version of a
software and to facilitate its reengineering.
 Configuration management.
 Analysis
 Parsing
 Test Generation
 Transformation
 To make the code structured, its control flow is changed
 Rationalization of control flow
 Isolation
 Procedural granularity (sizing of the procedures, by using the ideas of
high cohesion and low coupling.)

13
Source Code Reengineering
Reference
Normalization:: Model
 Data and their structures are scrutinized
 Data reduction
 Data representation.

 Interpretation
 deriving the meaning of a piece of software is started in this layer.
 Functionalization
 eliminates global variables and/or
 Introduces recursion and polymorphic functions.

 Program reading
 annotating the source code with logical comments.

14
Source Code Reengineering
Reference
Abstraction: Model
 The annotated and rationalized source code is examined by means
 of abstractions to identify the underlying object hierarchies
 Object identification (separate the
 data operators and (ii) group those data operators with the data they manipulate.)
 Object interpretation: (Application domain meanings are mapped to the objects
 identified above.)

 Causation
 Specification of actions: services provided to the user.
 Specification of constraints: limitations within which the software
correctly operates.
 Modification of specification: The specification is extended and/or
reduced to accurately reflect the user’s requirements.

15
Source Code Reengineering
Reference
 Regeneration:
Model
 Re-implementing the source code using the requirements and the
functional specifications
 Generation of design, Generation of Code and Test Generation

 Certification
 Newly generated software is analysed to establish that it is
 operating correctly;
 performing the specified requirements;
 Consistent with the original code

16
Source Code Reengineering
Reference
 Model
Improvements in the software as a result of reengineering are
quantified by means of the metrication element.

 The metrication element is described in terms of the relevant

software metrics before executing a layer and after executing the
same layer.
 The specification, constraints, and implementation details of both
the old and the new versions of the software are described in the
documentation element.

 The repository database is the information store for the entire

reengineering process, containing the following kinds of information:
metrication, documentation, and both the old and the new source
codes

17
18
Source Code Reengineering
Reference
 Model
The interfaces among the elements are shown in Figure.
 For simplicity, any layer is referred to as (N)-layer, while its next lower
and next higher layers are referred to as (N−1)-layer and the (N+1)-
layer, respectively.

 The three types of interfaces are explained as follows:

 Metrication/function: (N)-MF—the structures describing the metrics

and their values.
 Documentation/function: (N)-DF—the structures describing the
documentation.

 Function/function: (N)-FF—the representation structures for source

code passed between the layers.

19
Phase Reengineering Model
 The model comprises five phases:

Analysis and planning

 Present state of the system to be reengineered and understanding
its properties.
 identification of the need for the system to be reengineered.
 specification of the characteristics of the new system to be
produced.
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: (i) representation of the system and (ii) representation of
external data

20
Phase Reengineering Model
Target system testing,
faults are detected in the target system.

Re-documentation,
documentations are rewritten, updated, and/or replaced to reflect the target
system.
The two major tasks within this phase are
 (i) analyze new source code
 (ii) create documentation

Acceptance testing and system transition

The reengineered system is evaluated by performing acceptance testing
Should the reengineered system pass those tests, preparation begins to transition

to the new system

21
Phase Reengineering Model

22
CODE REVERSE ENGINEERING
 In the context of software engineering, reverse engineering is a
process to

 identify the components of an operational software;

 identify the relationships among those components; and

 represent the system at a higher level of abstraction or in another

form.

 In other words, by means of reverse engineering one derives

information from the existing software artifacts and transforms it into
abstract models to be easily understood by maintenance personnel

23
CODE REVERSE ENGINEERING

24
CODE REVERSE ENGINEERING
 Six key steps in reverse engineering, as documented in the IEEE Standard
for Software Maintenance are:

 partition source code into units;

 describe the meanings of those units and identify the functional units;

 create the input and output schematics of the units identified before;

 describe the connected units;

 describe the system application; and

 create an internal structure of the system

26
Summary

Any Questions?

27