Software re-engineering


Reorganising and modifying
existing software systems to
make them more maintainable

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 1

Objectives

To explain why software re-engineering is a cost-
effective option for system evolution

To describe the activities involved in the software
re-engineering process

To distinguish between software and data re-
engineering and to explain the problems of data
re-engineering

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 2

Topics covered

Source code translation

Reverse engineering

Program structure improvement

Program modularisation

Data re-engineering

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 3

System re-engineering

Re-structuring or re-writing part or all of a
legacy system without changing its
functionality

Applicable where some but not all sub-systems
of a larger system require frequent
maintenance

Re-engineering involves adding effort to make
them easier to maintain. The system may be re-
structured and re-documented

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 4

When to re-engineer

When system changes are mostly confined to
part of the system then re-engineer that part

When hardware or software support becomes
obsolete

When tools to support re-structuring are
available

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 5

Re-engineering advantages

Reduced risk
• There is a high risk in new software development. There may be
development problems, staffing problems and specification
problems

Reduced cost
• The cost of re-engineering is often significantly less than the
costs of developing new software

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 6

Business process re-engineering

Concerned with re-designing business processes
to make them more responsive and more efficient

Often reliant on the introduction of new computer
systems to support the revised processes

May force software re-engineering as the legacy
systems are designed to support existing
processes

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 7

Fo
rSw sp eS
c
asofrtdEy
i
f
x
iw s
nt
g e
am
sare-tn i
o
e
g nrg D
e
i
m
p
l
r
ss
i
g
n
m
e
t
a
n
d
ia
d
t
i
o
n
g
a
ndR
eN
e
w
s
y
t
m
Forward engineering and re-engineering

U
n
d
e -
n
g
ie
r
d
y
sngitem
ringt
af
o
r
ma
t
o s
y
tm
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 8
 O
rpoignam l enR
g e
The re-engineering process

i v r
sie
ng P
d
o
c
uro
m g
e a
nm
t i
o
n M
o
d
u
l
a
r
i
s
p
r
g
me
d
Da t Or
i
g
n
al
d
a
t
S
o u
rtancsleatiod
enimP
rsptouvgctam P
m
d
rentS r
uol g a
i
s mt
o
n re
n
gi e ri
ng
tproucgtarm
ed Rendgaiterd
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 9
Re-engineering cost factors

The quality of the software to be re-engineered

The tool support available for re-engineering

The extent of the data conversion which is
required

The availability of expert staff for re-engineering

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 10

A
u A ut o
rm
a
t
e
d
p
e
s
r
u
cr
o
g
a
i
nm
Re-engineering approaches

tcdoem
acotendvsouircneAu
tw
o
m a P ro g
a
m
a
e
s
t
r
u
c
tn
d
a
r
i
gt
tihednuraelstrhuacntgreisngarR
ecIhnsitcrruecatsradilnccgohp
lastnugse
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 11
Source code translation

Involves converting the code from one language
(or language version) to another e.g. FORTRAN
to C

May be necessary because of:
• Hardware platform update
• Staff skill shortages
• Organisational policy changes

Only realistic if an automatic translator is
available

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 12

 S y s
tIrdee-ntnieg
m
tfyisoourb
ercdeD S
y
s
t
e
m
r
e
-
n
gt
o
b
i
re
d R
e
-
n
g
i
s
y
te
r
d
m
The program translation process

e
s
i
g
n
t
ra
n
s
l
at
o
r A
u
t
o
m
codens ucio ransleodetrsltecodea
t
i
c
al
y M
a
n
u
al
y
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 13
Reverse engineering

Analysing software with a view to understanding its
design and specification

May be part of a re-engineering process but may also
be used to re-specify a system for re-implementation

Builds a program data base and generates
information from this

Program understanding tools (browsers, cross-
reference generators, etc.) may be used in this
process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 14

 A u
t
o m a ted P
r
o
g
da
img rs
at
mu c r
e
The reverse engineering process

S y
sre-tnegm an
tieorbedanM l ys i S
y
i
n
f
o
rs
t
e
m
a
i
o
aotnuaioln TnD
o
c
u
m
g
e
n
r
ae
n
t
i
o D
a
dt
i
rm s
g ru
ac
m ts r
e
acetrbcielsty
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 15
Reverse engineering

Reverse engineering often precedes re-
engineering but is sometimes worthwhile in its
own right
• The design and specification of a system may be reverse
engineered so that they can be an input to the requirements
specification process for the system’s replacement
• The design and specification may be reverse engineered to
support program maintenance

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 16

Program structure improvement

Maintenance tends to corrupt the structure of a
program. It becomes harder and harder to
understand

The program may be automatically restructured to
remove unconditional branches

Conditions may be simplified to make them more
readable

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 17

Spaghetti logic

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 18

Structured control logic

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 19

Condition simplification

-- Complex condition
if not (A > B and (C < D or not ( E > F) ) )...

-- Simplified condition
if (A <= B and (C>= D or E > F)...

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 20

 P
reosgtaum
tcob
e
rdA
n a
lgrphysbeurialnedrrepG
Automatic program restructuring

P
r
g
eo
g
a
m
n
t
o
rRe
s
t
r
u
c
t
p
o
g
ar
e
d
m
rseanpthion
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 21
Restructuring problems

Problems with re-structuring are:
• Loss of comments
• Loss of documentation
• Heavy computational demands

Restructuring doesn’t help with poor
modularisation where related components are
dispersed throughout the code

The understandability of data-driven programs
may not be improved by re-structuring

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 22

Program modularisation

The process of re-organising a program so that
related program parts are collected together in a
single module

Usually a manual process that is carried out by
program inspection and re-organisation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 23

Module types

Data abstractions
• Abstract data types where datastructures and associated
operations are grouped

Hardware modules
• All functions required to interface with a hardware unit

Functional modules
• Modules containing functions that carry out closely related tasks

Process support modules
• Modules where the functions support a business process or
process fragment

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 24

Recovering data abstractions

Many legacy systems use shared tables and global
data to save memory space

Causes problems because changes have a wide
impact in the system

Shared global data may be converted to objects or
ADTs
• Analyse common data areas to identify logical abstractions
• Create an ADT or object for these abstractions
• Use a browser to find all data references and replace with
reference to the data abstraction

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 25

Data abstraction recovery

Analyse common data areas to identify logical
abstractions

Create an abstract data type or object class for each
of these abstractions

Provide functions to access and update each field
of the data abstraction

Use a program browser to find calls to these data
abstractions and replace these with the new defined
functions

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 26

Data re-engineering

Involves analysing and reorganising the data
structures (and sometimes the data values) in a
program

May be part of the process of migrating from a
file-based system to a DBMS-based system or
changing from one DBMS to another

Objective is to create a managed data
environment

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 27

Approaches to data re-engineering

Approach Description
Data cleanup The data records and values are analysed to improve their quality.
Duplicates are removed, redundant information is deleted and a consistent
format applied to all records. This should not normally require any
associated program changes.
Data extension In this case, the data and associated programs are re-engineered to remove
limits on the data processing. This may require changes to programs to
increase field lengths, modify upper limits on the tables, etc. The data itself
may then have to be rewritten and cleaned up to reflect the program
changes.
Data migration In this case, data is moved into the control of a modern database
management system. The data may be stored in separate files or may be
managed by an older type of DBMS.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 28

Data problems

End-users want data on their desktop machines
rather than in a file system. They need to be able
to download this data from a DBMS

Systems may have to process much more data
than was originally intended by their designers

Redundant data may be stored in different
formats in different places in the system

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 29

 ProF
gileam11 F
i
l
e2 P
ro
Fg
a
m
i
l
e
32P
F
i
l
e4r
o
g
Fa
m
i
l
e
53F
i
l e 6
P rogam
4P
rogam
5P
Br
o
e
c
o
m
eg
a
m
s6Pr
o
ga
m
7
P
rPoga m 2 Prog
a
m
3Pro
g a
m
4 P
r
o
ga
m
5 P
r
o
ga
m
P6
r
o
g
a
m 7
rogam 1 sy L D
a
t
m
n
gb
a
s
e
mn
t d
es
c
r
i
be
so g
idapthycm
asolends
Data
migration
Data problems

Data naming problems
• Names may be hard to understand. The same data may have different
names in different programs

Field length problems
• The same item may be assigned different lengths in different programs

Record organisation problems
• Records representing the same entity may be organised differently in
different programs

Hard-coded literals

No data dictionary

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 31

Data value inconsistencies
Data inconsistency Description
Inconsistent default Different programs assign different default values to the same logical data
values items. This causes problems for programs other than those that created the
data. The problem is compounded when missing values are assigned a
default value that is valid. The missing data cannot then be discovered.
Inconsistent units The same information is represented in different units in different
programs. For example, in the US or the UK, weight data may be
represented in pounds in older programs but in kilograms in more recent
systems. A major problem of this type has arisen in Europe with the
introduction of a single European currency. Legacy systems have been
written to deal with national currency units and data has to be converted to
euros.
Inconsistent validation Different programs apply different data validation rules. Data written by
rules one program may be rejected by another. This is a particular problem for
archival data which may not have been updated in line with changes to
data validation rules.
Inconsistent Programs assume some meaning in the way items are represented. For
representation example, some programs may assume that upper-case text means an
semantics address. Programs may use different conventions and may therefore reject
data which is semantically valid.
Inconsistent handling Some programs reject negative values for entities which must always be
of negative values positive. Others, however, may accept these as negative values or fail to
recognise them as negative and convert them to a positive value.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 32

Data conversion

Data re-engineering may involve changing the
data structure organisation without changing the
data values

Data value conversion is very expensive. Special-
purpose programs have to be written to carry out
the conversion

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 33

 E nti yPnr
o
ag
m a
m
e t
o b
e r- en
g i er
d
D
a
t nD a
l t
ysi
m o d fc ti
on re-fo
r
m
in
g
The data re-engineering process

D a
tnlysiS
rtagD
e L
p
lea1S a erm
t-odrfiCl
e
nhtg
o
n
tangesum VD
mc
al
oiu
l
v
l
n
e
s
o
d
a
t
i
n
r
f
cu
e
age2rytablesS D
c
o
n
v
tage3M a
e t
rsio
n
©Ian Sommerville 2000
odaitfed
Software Engineering, 6th edition. Chapter 28 Slide 34
Key points

The objective of re-engineering is to improve the
system structure to make it easier to understand
and maintain

The re-engineering process involves source code
translation, reverse engineering, program structure
improvement, program modularisation and data re-
engineering

Source code translation is the automatic conversion
of of program in one language to another

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 35

Key points

Reverse engineering is the process of deriving the
system design and specification from its source code

Program structure improvement replaces
unstructured control constructs with while loops and
simple conditionals

Program modularisation involves reorganisation to
group related items

Data re-engineering may be necessary because of
inconsistent data management

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 36