1

CSE327: Software Re-engineering

Lecture #: 3
CDF Unit #: 2
Instructor:
Dr. Manzoor Ahmad
manzoorahmad@cuivehari.edu.
pk

COMSATS University Islamabad,

Vehari Campus
 engineering Overview (1/2)
3

This is the process of examining and altering a target system to

implement a desired modification.
Reengineering consists of two steps.
Firstly, reverse engineering is applied to the target system so as
to understand it and represent it in a new form.
Secondly, forward engineering is applied, implementing and
integrating any new requirements, thereby giving rise to a new
and enhanced system.
These two steps can be further broken down as, for example, in
the 8-layer Source Code Reengineering Model (SCORE/RM)
proposed by Colbrook et al.
 4
Re-Engineering Overview (2/2)

This model supports retrospective abstraction of data from source code.

The first five layers - encapsulation, transformation, normalisation,
interpretation and abstraction – constitute reverse engineering.
The remaining three layers - causation, regeneration“ and certification
make up forward engineering. The authors argue that the model has a
number of applications.
Firstly, it provides a mechanism which enables the maintainer to work
through the code and understand its purpose, produce documentation and
modify the code in a way that enhances its maintainability.
Secondly, it supports retrospective specification of a system from the
available source code.
 5
engineering Overview

Reverse engineering is a technique that can be used to carry out

the change.
Reverse engineering alone does not lead to a change in the
program; it simply paves the way for easier implementation of
the desired changes.
Reverse engineering - process of analyzing a subject system to:
 identify the system's components and their interrelationships and
 create representations of the system in another form or at higher
levels of abstraction.
 Goal & 6
Engineering Objectives
The goal of reverse engineering is to facilitate change by allowing a
software system to be understood in terms of what it does, how it works
and its architectural representation. The objectives in pursuit of goal are to:
 To recover lost information
 To facilitate migration between platforms
 To improve or provide documentation
 To provide alternative views
 To extract reusable components
 To cope with complexity
 To detect side effects
 To reduce maintenance effort
 Objectives 7
Engineering & Benefits
 8
Engineering Process

Program stucture
Automated diagrams
analysis
System
System to be Document Data stucture
information
re-engineered generation diagrams
store
Manual
annotation Traceability
matrices
 Levels 9
Engineering (1/2)
Reverse engineering involves performing one or more of the types of
abstraction, in a bottom-up and incremental manner.
It entails detecting low-level implementation constructs and replacing
them with their high-level counterparts.
The process eventually results in an incremental formation of an overall
architecture of the program.
It should be noted that the product of a reverse engineering process does
not necessarily have to be at a higher level of abstraction.
If it is at the same level as the original system, the operation is commonly
known as “redocumentation”.
If the resulting product is at a higher level of abstraction, the operation is
known as 'design recovery' or 'specification recovery
 Levels 10
Engineering (2/2)
 documentation 11
Engineering (1/3)
Redocumentation is the recreation of a semantically equivalent
representation within the same relative abstraction level.
The goals of this process are threefold.
 Firstly, to create alternative views of the system so as to enhance
understanding, for example the generation of a hierarchical data flow or
control flow diagram from source code.
 Secondly, to improve current documentation. Ideally, such
documentation should have been produced during the development of
the system and updated as the system changed.
 Thirdly, to generate documentation for a newly modified program. This
is aimed at facilitating future maintenance work on the system –
preventive maintenance.
 documentation 12
Engineering (2/3)
 documentation 13
Engineering (3/3)
 Design 14
Engineering Recovery (1/3)
Design recovery entails identifying and extracting meaningful
higher level abstractions beyond those obtained directly from
examination of the source code.
This may be achieved from a combination of code, existing
design documentation, personal experience, and knowledge of
the problem and application domains.
The recovered design – which is not necessarily the original
design - can then be used for redeveloping the system (a baseline
for future system modifications).
The design could also be used to develop similar but non-
identical applications.
 Design 15
Engineering Recovery (2/3)
Different approaches, which vary in their focus, can be used to
recover design.
Some draw heavily on programming language constructs
contained in the program text.
They argue that an important aspect of design recovery is being
able to recognize, understand and represent design decisions
present in a given source code.
Program constructs (e.g., control and data structures, variables,
procedures and functions, definition and implementation
modules, and class hierarchies), which vary between
programming languages, enable recognition of design decisions.
 Design 16
Engineering Recovery (3/3)

Other approaches rely on knowledge about the problem and

application domains.
This is based on the premise that success in recovering design
relies more heavily on knowledge about the domain than
knowledge about general and widely applicable components
such as sorts and searches.
A number of models for recovering design have been proposed.
An approach to extract and restructure the design of large
systems, where the term 'large systems' refers to those systems
with inter-modular relations.
 Specification 17
Engineering Recovery (1/3)
In some situations reverse engineering that only leads to the recovery
of the design of the system may not be of much use to an organization
or a software engineer.
In this case, an appropriate approach is to obtain the original
specification of the system through specification recovery.
This involves identifying, abstracting and representing meaningful
higher levels of abstractions beyond those obtained simply by
inspecting the design or source code of the software system.
During this process, the specification can be derived directly from the
source code or from existing design representations through
backward transformations.
 Specification 18
Engineering Recovery (2/3)
Information obtained from other sources such as system and design
documentation, previous experience, and problem and application
domain knowledge can greatly facilitate the recovery process.
Ideally the recovered specification should be represented in a form
that can be re-implemented easily in another programming language
or paradigm.
The specification recovered can also be represented as 'object
classes'. In this case the system is represented as a set of objects
and operations
Object class representation is particularly useful when reverse
engineering is performed with the intent of migrating the current
system to an object-oriented platform.
 Specification 19
Engineering Recovery (3/3)

The specification recovered during reverse engineering can be

put to a number of uses.
Firstly, a fairly representative specification of a system can be
used to support software maintenance without necessarily
requiring access to the source code.
Secondly, the specification assists the maintainer in acquiring the
appropriate level of understanding required to effect a change to
a software system.
Thirdly, if the specification is suitably represented it can be used
in the development or maintenance of similar software systems.
 Conditions 20
Engineering (1/2)
There are no hard and fast rules as to what criteria a program
must fulfil before it may usefully be subject to reverse
engineering.
There are, however, some features which may serve as warning
signs or indicators.
The motives for reverse engineering are usually commercial.
Reverse engineering in itself does not directly lead to
modification of a system.
It simply enables an understanding of a system by representing it
at an equivalent or higher abstraction level.
 Conditions 21
Engineering (2/2)