Chapter 9
Software Maintenance
 2004 by SEC
Chapter 9
Software Maintenance
9.1 Software Evolution
9.2 Types of Software Maintenance
9.3 Maintenance Techniques
9.4 The Management of Maintenance
9.5 Qualities in Maintenance
9.6 Reengineering, Reverse Engineering and Forward
Engineering
Exercise
2
 2004 by SEC
9.1 Software Evolution
3
 2004 by SEC
Software Evolution

It is impossible to produce system of any size which do not
need to be changed. Once software is put into use, new
requirements emerge and existing requirements changes as the
business running that software changes.

Parts of the software may have to be modified to correct
errors that are found in operation, improve its performance or
other non-functional characteristics.

All of this means that, after delivery, software systems always
evolve in response to demand for change.
4
 2004 by SEC
Program Evolution Dynamic

Program evolution dynamic is the study of system change.
The majority of work in this area has been carried out by
Lehman and Belady. From these studies , they proposed a sets
of laws concerning system change.
Law
Continuing change
Description
A program that is used in real-world environment
necessarily must change or become progressively
less useful in that environment.
Increasing complexity
As an evolving program changes, its structure
tends to become more complex. Extra resources
must be devoted to preserving and simplify the
structure.
5
 2004 by SEC
Program Evolution Dynamic (cont’d)
Law
Large program evolution
Organizational stability
Conservation of familiarity
Description
Program evolution is self-regulation process.
System attributes such as size, time between
release and the number of report errors are
approximately invariant for each system
release
Over a program’s lifetime, its rate of
development is approximately constant and
independent of the resources devoted to the
system development
Over the lifetime of system, the incremental
change in each release is approximately
constant.
6
 2004 by SEC
Software Evolution Approaches

There are a number of different strategies for software
change.[SOM2004]
– Software maintenance
– Architectural transformation
– Software re-engineering.

Software maintenance
– Changes to the software are made in response to changed requirements
but the fundamental structure of the software remains stable. This is
most common approach used to system change.
7
 2004 by SEC
Software Evolution Approaches (cont’d)

Architectural transformation
– This is a more radical approach to software change then maintenance as
it involves making significant change to the architecture of the system.

Software re-engineering
– This is different from other strategies in that no new functionality is
added to the system.
– System re-engineering may involve some structural modifications but
dose not usually involves major architectural change.
8
 2004 by SEC
9.2 Types of Software Maintenance
9
 2004 by SEC
Software Maintenance

Software maintenance is the general process of changing a
system after it has been diverted.

The change may be simple changes to correct coding errors,
more extensive changes to correct design errors or significant
enhancement to correct specification error or accommodate
new requirements.
10
 2004 by SEC
Maintenance Characteristics

We need to look at maintenance from three different
viewpoints: [PRE2004]
– the activities required to accomplish the maintenance phase and the
impact of a software engineering approach (or lack thereof) on the
usefulness of such activities
– the costs associated with the maintenance phase
– the problems that are frequently encountered when software
maintenance is undertaken
11
 2004 by SEC
Types of Maintenance

Maintenance to repair software faults
–

Maintenance to adapt software to a different operating
environment
–

Changing a system to correct deficiencies in the way meets
its requirements
Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation
Maintenance to add to or modify the system’s functionality
–
Modifying the system to satisfy new requirements
12
 2004 by SEC
Fault repair
(17%)
functionality
addition or
modification
(65%)
software
adaption
(18%)
Maintenance effort distribution .[SOM2004]
13
 2004 by SEC
Development vs. Maintenance
not directly linked to the
real world
freedom
defects have no immediate
effect
methods available
standards may be enforced
directly driven by the real
world
constrained by existing
system
defects disrupt production
system not using current
methods
shifting standards, if any
14
 2004 by SEC
Maintenance Examples

Y2K
– many, many systems had to be updated
– language analyzers (find where changes need to be made)

Anti-Virus Software
– don't usually have to update software, but must send virus definitions
15
 2004 by SEC
Maintenance Examples (cont’d)

Operating System Patching
– Microsoft, Apple, Linux/Unix
– OS is core to use of computer, so it must be constantly maintained

Commercial Software in General
– customers need to be informed of updates
– updates have to be easily available - web is good tool
16
 2004 by SEC
The Maintenance Process

Maintenance process vary considerably depending on the
types of software being maintained, the development
processes used in an organization and people involved in the
process.
Change
requests
Impact
analysis
Release
planning
Fault
repair
Flat form
adaptation
Change
implementation
System
release
System
enhancement
Overview of the Maintenance Process .[SOM2004]
17
 2004 by SEC
Change Requests

Change requests are requests for system changes from users,
customers or management

In principle, all change requests should be carefully analysed
as part of the maintenance process and then implemented

In practice, some change requests must be implemented
urgently
–
Fault repair
–
Changes to the system’s environment
–
Urgently required business changes
18
 2004 by SEC
Change Implementation
P ro po sed
chan ges
R equ irem en ts
anal y si s
R equ irem ent s
u pd at in g
S oftw are
develop ment
Change implementation. [SOM2004]
19
 2004 by SEC
Emergency Repair
C h an ge
requ est s
An al y ze
so urce code
M o di fy
s ou rce co de
Deli ver mo difi ed
sy stem
Emergency repair [SOM2004]
20
 2004 by SEC
Why is Maintenance Inefficient?

Factors adversely effect maintenance
– Lack of models or ignorance of available models (73%)
– Lack of documentation (67.6%)
– Lack of time to update existing documentation (54.1%)

Other factors (1994 study)
– Quality of original application
– Documentation quality
– Rotation of maintenance people
21
 2004 by SEC
Why is Maintenance Inefficient?
(cont’d)

More factors (Yip ’95 study)
– Lack of human resources
– Different programming styles conflict
– Lack of documentation and tools
– Bad maintenance management
– Documentation policy
– Turnover
22
 2004 by SEC
9.3 Maintenance Techniques
23
 2004 by SEC
Architectural Evolution

There is a need to convert many legacy systems from a
centralised architecture to a client-server architecture

Change drivers
–
Hardware costs. Servers are cheaper than mainframes
–
User interface expectations. Users expect graphical user interfaces
–
Distributed access to systems. Users wish to access the system
from different, geographically separated, computers
24
 2004 by SEC
Distribution Factors [SOM2004]
Fa ct or
Bu sine ss
im po rtan c e
S ys tem a ge
S ys tem struc tu re
H ardw are
procu re men t
pol ici e s
D escr ipti on
Re turns on the inv e stmen t of di stribu ting a legacy syste m
dep e nd on it s im po rtan c e to the bu sine ss and how long i t
w il l r em a in i m po rtan t. If di stribu tion p rovid e s m ore e ff ic ien t
suppo rt for stab le bu sine ss proce ss es then it i s mo re like ly to
be a co st-eff ec tiv e evolu tion strategy.
Th e olde r t he sys tem the mo re d iff icu lt i t w ill b e to mod if y
its ar chi tec ture bec a us e previou s ch a nge s w ill h a ve deg ra ded
th e str uctu re of the syste m .
Th e mo re m odula r t he sys tem, the ea sier it w ill be to chang e
th e arch ite c tu re. If th e appl ica tion log ic, th e dat a
m a nage m ent a nd the u ser in terf ac e o f th e sy ste m a re clo sely
in tertw in e d, it w ill be d iff icu lt to sepa ra te fun c tion s f or
m igrat ion.
A ppli c at ion di stribu tion m a y be ne c essa ry if the re is
co m pany pol icy to re plac e expen siv e ma infr am e compu ters
w ith c heap er ser ve rs. .
25
 2004 by SEC
Legacy System Structure

Ideally, for distribution, there should be a clear separation
between the user interface, the system services and the
system data management

In practice, these are usually intermingled in older legacy
systems
26
 2004 by SEC
Legacy System Structures [SOM2004]
Us er i nt erface
S ervi ces
Dat abas e
Ideal m o del for di st rib ut io n
Us er i nt erface
S ervi ces
Dat abas e
R eal leg acy s ys tem s
27
 2004 by SEC
Layered Distribution Model [SOM2004]
P resen tat io n
Dat a v ali dat io n
Int eracti on co nt rol
Ap pl i cat io n serv ices
Dat abas e
28
 2004 by SEC
Legacy System Distribution [SOM2004]
Des kt op P C cli en ts ru nn in g ap pl icat io n
L ega cy sy stem
Ap pl i cat io n
s erv ices
Dat abas e
M i dd leware lay er (wrap per)
Us er i nt erface
Leg acy sy st em
C h aract er t erm in als
29
 2004 by SEC
Distribution Options

The more that is distributed from the server to the client, the
higher the costs of architectural evolution

The simplest distribution model is UI distribution where
only the user interface is implemented on the server

The most complex option is where the server simply
provides data management and application services are
implemented on the client
30
 2004 by SEC
Distribution Option Spectrum
[SOM2004]
S erver: Int eracti on co nt rol
Dat a v ali dat io n
S ervi ces
Dat abas e
S erver: S ervi ces
Dat abas e
C l ient : P resen tat io n
C l ient : P resen tat io n
Int eracti on co nt rol
Dat a v ali dat io n
S erver: Dat abas e
C l ient : P resen tat io n
Int eracti on co nt rol
Dat a v ali dat io n
S ervi ces
Increasi ng co st
and effort
31
 2004 by SEC
User Interface Distribution

UI distribution takes advantage of the local processing
power on PCs to implement a graphical user interface

Where there is a clear separation between the UI and the
application then the legacy system can be modified to
distribute the UI

Otherwise, screen management middleware can translate
text interfaces to graphical interfaces
32
 2004 by SEC
User Interface Distribution [SOM2004]
S creen des crip ti on s
Des kt op P C cli en ts w it h
GU I i nt erface
L ega cy sy stem
Ap pl i cat io n
s erv ices
Dat abas e
S creen m anag em ent
m i dd leware
Us er i nt erface
33
 2004 by SEC
UI Migration Strategies [SOM2004]
St ra tegy
Imp lem e nta tion
u sing th e w indow
m a nage m ent
sys tem
Imp lem e nta tion
u sing a w eb
b row ser
A dva nt age s
A cc e ss to a ll UI f unc tion s so no
rea l restri ct ions on UI de sign
Be tte r UI pe rf o rm ance
D isadva nt age s
P la tf orm dep e ndent
M ay be m o re di ffi cul t to ach ieve
in terf ac e con siste ncy
P la tf o rm ind e penden t
Lo w er tr ain ing co sts due to u ser
fam il iarity w ith th e WWW
E a sier to a chi e ve int erf ac e
con siste ncy
P oten tia lly poo rer UI
pe rf o rm anc e
Int erf ac e des ign i s con strained
by th e f ac ili tie s p rovid e d by web
brow ser s
34
 2004 by SEC
9.4 The Management of Maintenance
35
 2004 by SEC
Model of Maintenance Effort
Model of maintenance effort M = p + K^(c-d) [PRE2004]

M = total maintenance effort over entire lifecycle

p = productive efforts: analysis, design, code, test

c = complexity due to lack of structured design and documentation

d = degree of familiarization with the system

K = empirically determined constant
36
 2004 by SEC
Model of Maintenance Effort (cont’d)
Model of maintenance effort M = p + K^(c-d)

Cost of maintenance increases exponentially.

Costs are reduced by structured development

Costs are reduced by giving the maintenance team time to become
thoroughly familiar with the system
37
 2004 by SEC
What Affects the Maintainability of an
Application?

Application age
– (software rust?) older programs were probably worse written and have
probably been patched more

Size
– measured in KLOC, number of input/output files

Programming language
– 4gls are supposed to produce more maintainable code than 3gls
38
 2004 by SEC
What Affects the Maintainability of an
Application? (cont’d)

Processing environment
– files harder to maintain than databases, real-time harder than batch

Analysis and design methodologies
– well designed software is supposed to be much easier to maintain

Structured programming
– there is conflicting evidence whether this really helps
39
 2004 by SEC
What Affects the Maintainability of an
Application? (cont’d)

Modularization
– (central thesis of all the oo techniques) small reasonably self contained
pieces of code should be easier to maintain

Documentation generation
– maintenance of documentation is as expensive as maintenance of code

End-user involvement
– some researchers believe when end users are more involved
maintenance decreases
40
 2004 by SEC
What Affects the Maintainability of an
Application? (cont’d)

Maintenance management
– scheduling and the attitudes of management to affects productivity
41
 2004 by SEC
Problems in Managing Maintenance

Changing priorities
– chaotic nature of maintenance requests, the length of maintenance tasks
causing new requests to come along before an ongoing task is done.

Inadequate testing methods
– lack of time set aside for testing, of comprehensive test data, of
rigorous testing requirements as a standard for signing off.

Performance measurement difficulties
– how do you measure individual or group performance?

System documentation incomplete or non-existent
– training takes a long time for learning an application so programmers
get stuck on one piece of software.

Adapting to the rapidly changing business environment
– hardware and software also become obsolete.
42
 2004 by SEC
Problems in Managing Maintenance
(cont’d)

From survey of 60 US & Canadian companies in Software
Maintenance News 1992
– These are the consequence of the lack of mature tools and techniques
for software maintenance and its management.
– We need predictive models of maintenance to estimate how much effort
needs to go into it.
– By and large maintainers work in isolation and are not closely
managed. Each one has to learn from personal experience good
methods of working.
43
 2004 by SEC
Maintenance Prediction

Maintenance prediction is concerned with assessing which
parts of the system may cause problems and have high
maintenance costs
–
Change acceptance depends on the maintainability of the
components affected by the change
–
Implementing changes degrades the system and reduces its
maintainability
–
Maintenance costs depend on the number of changes and costs of
change depend on maintainability
44
 2004 by SEC
Maintenance Prediction (cont’d)

Predicting the number of changes requires and
understanding of the relationships between a system and its
environment

Tightly coupled systems require changes whenever the
environment is changed

Factors influencing this relationship are
–
Number and complexity of system interfaces
–
Number of inherently volatile system requirements
–
The business processes where the system is used
45
 2004 by SEC
Maintenance Prediction (cont’d)

Predictions of maintainability can be made by assessing the
complexity of system components

Studies have shown that most maintenance effort is spent on
a relatively small number of system components

Complexity depends on
–
Complexity of control structures
–
Complexity of data structures
–
Procedure and module size
46
 2004 by SEC
Maintenance Prediction (cont’d)


Process measurements may be used to assess maintainability
–
Number of requests for corrective maintenance
–
Average time required for impact analysis
–
Average time taken to implement a change request
–
Number of outstanding change requests
If any or all of these is increasing, this may indicate a
decline in maintainability
47
 2004 by SEC
Maintenance Costs

Usually greater than development costs (2* to
100* depending on the application)

Affected by both technical and non-technical
factors

Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.

Ageing software can have high support costs
(e.g. old languages, compilers etc.)
48
 2004 by SEC
Maintenance Costs (cont’d)

Time and money (software that costs £ 10 a line to develop costs £ 400 a
line to maintain)

Organizations become maintenance bound and cannot produce new
software

Customer dissatisfaction when seemingly legitimate requests for repair or
modification cannot be addressed in a timely manner

Reduction in overall software quality as changes introduce latent errors in
the maintained software

Upheaval caused during development efforts when staff must be “pulled”
to work on a maintenance task
49
 2004 by SEC
Development/Maintenance Costs [SOM2004]
S y st em 1
S y st em 2
0
50
1 00
Dev elo pm en t cos ts
1 50
2 00
2 50
3 00
3 50
4 00
4 50
5 00
$
M ain ten ance cos ts
50
 2004 by SEC
Maintenance Cost Factors

Team stability
–

Contractual responsibility
–

The developers of a system may have no contractual responsibility
for maintenance so there is no incentive to design for future change
Staff skills
–

Maintenance costs are reduced if the same staff are involved with
them for some time
Maintenance staff are often inexperienced and have limited domain
knowledge
Program age and structure
–
As programs age, their structure is degraded and they become
harder to understand and change
51
 2004 by SEC
Change Management

Change is a fact of life for large software. A defined change
management process and associated CASE tools ensure that
these changes are recorded and applied to the system in a
cost-effective way.

The change management process should come into effect
when the software associated document is put under the
control of the configuration management team.
Change management procedures should be designed to ensure
that the costs and benefits of change are properly analyzed
and changes to a system are made in a controlled way.

52
 2004 by SEC
Change Management Process
Request change by completing a change request form
Analyze change request
If change is valid then {
Assess how change might be implemented
Assess change cost
Record change request in database
Submit request to change control board
53
 2004 by SEC
Change Management Process (cont’d)
If change is accepted then{
Repeat{
make changes to software
record changes and link to associated change request
submit changed software for quality approval}
Until{
software quality is adequate
create new system version}}
else
{reject change request}}
54
 2004 by SEC
Change Request Form [SOM2004]
Project: Proteus/PCL-Tools
Change requester: I.Sommerville
Number: 23/94
Date: 1/9/98
Requested change: when a component is selected from the structure, display the name of the file
where it is stored.
Change analyzer: G.Dean
analysis Date:10/9/98
Components affected: Display-icon.Select, Display-icon.Display
Associated component: File Table
Change assessment: Relatively simple to implement as a file name table is available. Requires
the design and implementation of a display field. No changes to associated components are
required.
Change priority: Low
Change implementation:
Estimated effort: 0.5 days
Date to CCB: 15/9/98
CCB decision date: 1/11/98
Change implementor:
Date of change:
Date submitted to QA:
QA decision:
Date submitted to CM:
comments
CCB- change control board
55
 2004 by SEC
9.5 Qualities in Maintenance
56
 2004 by SEC
Maintenance Side Effects

In this context a side effect implies an error or undesirable
behavior that occurs as the result of a modification.

the three major areas are[PRE2004]
– code
– data structures
– documentation
57
 2004 by SEC
Documentation Side Effects



These consist of the failure to update documentation so that it
no longer matches the code.
If the user doesn’t know about changes frustration is
inevitable.
The entire documentation should be reviewed before rerelease
58
 2004 by SEC
Coding Side Effects

Any change can cause side-effects but these tend to be more
error prone a subprogram is deleted or changed

A statement label is deleted or modified

An identifier is deleted or modified

Changes are made to improve execution performance
59
 2004 by SEC
Coding Side Effects (cont’d)

Logical operators are modified

Files are opened or closed

Design changes which translate into major code changes

Changes are made to logical tests of boundary conditions

These may be caught in testing or cause software failure
during operation.
60
 2004 by SEC
Data Side Effects

Data side effects occur as the result of modifications made to
a data structure. The most error-prone are:
– redefinition of local and global constants
– redefinition of record or file formats
– Incr. or decr. in size of array or other data structure
– modification of global data
– re initialization of control flags and pointers
– rearrangements of parameters (especially in I/O)
61
 2004 by SEC
9.6 Re-engineering, Reverse
Engineering and Forward Engineering,
62
 2004 by SEC
Software Rejuvenation

Re-documentation
– Creation or revision of alternative representations of software

at the same level of abstraction
– Generates:


data interface tables, call graphs, component/variable cross
references etc.
Restructuring
– transformation of the system’s code without changing its behavior
63
 2004 by SEC
Software Rejuvenation (cont’d)

Reverse Engineering
– Analyzing a system to extract information about the behavior and/or
structure
 also Design Recovery - recreation of design abstractions from
code, documentation, and domain knowledge
– Generates:
 structure charts, entity relationship diagrams, DFDs, requirements
models

Re-engineering
– Examination and alteration of a system to reconstitute it in another
form
– Also known as renovation, reclamation
64
 2004 by SEC
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
65
 2004 by SEC
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
66
 2004 by SEC
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
67
 2004 by SEC
Forward Engineering and Reengineering [SOM2004]
S y st em
s pecifi cat io n
Des ig n and
i m pl em en tat io n
Ne w
s ys tem
Un ders tan di ng an d
t rans fo rm at io n
R e-eng in eered
s ys tem
F o rw ard eng in eerin g
Ex is t in g
s oft ware s ys tem
S o ftware re-eng in eerin g
68
 2004 by SEC
The Re-engineering Process [SOM2004]
P ro gram
d ocum en tat io n
Ori gi nal
p ro gram
M o du laris ed
p ro gram
Ori gi nal d ata
R evers e
eng in eerin g
P ro gram
m o du laris ati on
S o urce co de
t ran sl ati on
Dat a
reen gin eeri ng
P ro gram
s tru ct ure
i m prov em ent
S t ructu red
p ro gram
R eeng in eered
d at a
69
 2004 by SEC
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
70
 2004 by SEC
Re-Engineering Approaches [SOM2004]
Aut om ated p rogr am
rest ruct uri ng
Au to m at ed s ou rce
cod e co nv ersi on
P ro g ram an d d at a
rest ruct uri ng
Au to m at ed r est ruct uri ng
wi t h m anual ch ang es
Rest ruct uri ng p lu s
archi tect ural chan ges
Increased co st
71
 2004 by SEC
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
72
 2004 by SEC
The Program Translation Process
[SOM2004]
S y st em to b e
re-eng in eered
Iden ti fy so urce
cod e d ifferences
Des ig n trans lat or
i ns tru ct io ns
S y st em to b e
re-eng in eered
Re-eng in eered
s ys tem
Au to m at ically
t rans la t e cod e
M anu al ly
t rans la t e cod e
73
 2004 by SEC
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
74
 2004 by SEC
Spaghetti Logic [SOM2004]
S ta rt:
G et (T im e-on , T im e -o ff, T im e , S e tt ing , T em p , Sw itc h)
if S w itch = o ff g oto of f
if S w itch = o n go to on
g ot o Cn trl d
o ff: if H ea ti n g-sta tu s = on g ot o Sw -o ff
g ot o l oo p
o n: if H ea ti n g-sta tu s = of f g ot o Sw -o n
g ot o l oo p
C ntrl d : if T im e = T im e-on g oto on
if T im e = T im e-off g oto o ff
if T im e < T im e-on g oto S ta rt
if T im e > T im e-off g oto S ta rt
if T em p > S e tt ing th en g oto of f
if T em p < S e tt ing th en g oto o n
S w -off: H ea ting -s tat us := o ff
g ot o Sw itc h
S w -on : H ea ting -s ta tu s := on
S w itc h : S w itc h -h ea ting
lo op :
g ot o S ta rt
75
 2004 by SEC
Structured Control Logic [SOM2004]
lo o p
-- T he G et statem en t fi n ds v al ue s for t h e g iv en v ariab le s fr om th e sy stem ’s
-- e nv iro nm e nt.
G et (T im e-on , T im e -o ff, T im e , S e tt ing , T em p , Sw itc h) ;
c as e Sw itc h o f
w h en On = > if He at ing -s ta tus = o ff the n
S w itc h -h ea ting ; H e ating -s ta tu s := o n ;
e n d if ;
w h en O ff = > if H ea ting -s ta tus = on the n
S w itc h -h ea ting ; H e ating -s ta tu s := of f ;
e n d if;
w h en Co nt rolled = >
if T im e > = T im e-on a n d T im e < = Ti m e -o ff the n
if T em p > S etti n g a n d He at ing -s ta tus = o n the n
S w itc h -h ea ting ; He at ing -s ta tus = o ff;
e ls if T em p < S etti n g a n d He at ing -s ta tus = o ff the n
S w itc h -h ea ting ; He at ing -s ta tus := o n ;
e n d if;
e n d if ;
e n d c as e ;
e n d loo p ;
76
 2004 by SEC
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)...
77
 2004 by SEC
Automatic Program Restructuring
[SOM2004]
P rog ram t o b e
rest ruct ured
Rest ruct ur ed
p rog ram
An aly ser an d
g rap h b u il der
P rog ram
g en erat or
Grap h
repr esen tat io n
78
 2004 by SEC
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
79
 2004 by SEC
Module types

Data abstractions
–

Hardware modules
–

All functions required to interface with a hardware unit
Functional modules
–

Abstract data types where data structures and associated operations
are grouped
Modules containing functions that carry out closely related tasks
Process support modules
–
Modules where the functions support a business process or process
fragment
80
 2004 by SEC
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
81
 2004 by SEC
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
82
 2004 by SEC
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
83
 2004 by SEC
Approaches to Data Re-engineering
[SOM2004]
Approach
Data cleanup
Data extension
Data migration
Description
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.
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.
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.
84
 2004 by SEC
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
85
 2004 by SEC
Data Problems (cont’d)

Data naming problems
–

Field length problems
–

Names may be hard to understand. The same data may have
different names in different programs
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
86
 2004 by SEC
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
87
 2004 by SEC
The Data Re-engineering Process
[SOM2004]
Dat a
anal y si s
P rog ram t o b e re-eng in eered
Dat a
analy si s
En ti ty n am e
m o di fi cat io n
Dat a
re-fo rm at ti ng
Li teral
repl acem ent
Defau lt v alu e
conv ersi on
Dat a defi ni ti on
re-ord eri ng
Vali dat io n ru le
m o di fi cat io n
S t age 1
S t age 2
C h an ge su m m ary t ab l es
Dat a
conv ersi on
S t age 3
M od ifi ed
d at a
88
 2004 by SEC
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
89
 2004 by SEC
The Reverse Engineering Process
[SOM2004]
P rog ram s tu ctu re
d iag ram s
Au to m at ed
anal y si s
S y st em
i nfo rm at io n
s to re
S y st em to b e
re-eng in eered
M anu al
ann ot at io n
Do cum en t
g en erat io n
Dat a st uct ure
d iag ram s
Traceab il it y
m at ri ces
90
 2004 by SEC
References


[PRE2004] Roger S. Pressman. Software Engineering: a practitioner’s
approach, 6th edition. McGRAW-HILL, 2004.
[SOM2004] Ian Sommerville. Software Engineering, 7th edition. Addison
Wesley, 2004
91
 2004 by SEC
Descargar

Chapter 9 Software Maintenance