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

F
o
rSw sp eS
asofrtdEy
c
 wi
fns t
g eam
xairse­t n i
o
e
g nrg D
e
i
m
p
l
U
n
d
e
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
­
n
g
ie
r
d
Forward engineering and re­engineering

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
i
The re­engineering process

v r
sie
ng P
d
o
c
uro
m g
e a
nm
t io
nM
o
d
u
p
rl
a
r
i
s
e
g
md
Da t Or
i
g
n
al
 
d
a
t
S
o u
rtancslea tiod
enimP
rsptouvgctam P
m
d
rentS r
uol g a
i
s m
to
n r
en
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
tcdoem A ut o
rm
a
t
e
d
 
p
e
s
r
u
cr
o
g
a
i
n
a cotendv souircneAm
u
tw
o
m
Re­engineering approaches

a P ro g
a
m
 
a
e
s
t
r
u
c
tn
d
 
a
r
i
gt
tih edn uraelstrhuacntgreisngarR
ecIhnsitcrruecatsradiln
g
  ccohp
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
 fyi stoourb
ercdeD S
y
s
t
e
m
r
e
­
n
g 
t
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
co dens ucio ransle odetrslte codea
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
S y
sre­tnegm A u
t
o
a
n
 iteorbedanM lmya
s t
iedS
ys
t
e
m D
o
c
u
me
n
t P
r
o
g
d
D
aa
i
tm
 g
s  
rs
a
ut
m
cu tc r
e
r
e
The reverse engineering process

i
n
f
o
ra
i
o
aotnuaioln Tng
e
n
r
ai
o di
rm g ram s
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
 ctob
e
rdA
n a
lgrphysbeur ialnedrrepG
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

 P roF
gilea m
 11Fi
l
e 
2 P
ro
Fg
a
i
l
em
 
2
 
3 Fi
l
e
 
4 P
r
o
g
F
ia
m
 
3
l
e
 
5 F
il e 6
P rogam
 4Progam
 5B P
recom
o
g am
 es6P rogam
 7
P
rP
o
g a
 rogamm 2 Pr
og
am
 
3 Pro
g a
m 
4 P ro
g
a
m  
5 P
r
o
gam 
P
r6
og
am   7
 1 sy L D
ma
t
n
gb
a
s
e
m
nt d
e
sc
r
i
b
es o g
idapth ycm
asol ends
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 n ti yP
 nr
o
a g
m a
em  
to b
e
 
r
­ en
g i er
d
D
a
t nD a
l t
ys
i
D a
tnlysiS m
rtagD o
e
p d
L fc
er
le a1t­ oadrfimt
lion
entgonS r
De
c­fo
r
m
i
u
l
 
v
l
n
e
s
on
g
u
e D
c
o
n
v a
e t
r
si
on
The data re­engineering process

C t
a
g
e
 
2
hange sum Vmal
oid
a
t
i
n
r
f
c S
t
a
g
e
 
3
rytables Modaitfed
©Ian Sommerville 2000  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