Post on 16-May-2020
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 1
CO7206System Reengineering
4.2 Software Reengineering
Most slides are Slides by Ian Sommerville
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 2
ObjectivesTo explain why software re-engineering is a cost-effective option for system evolutionTo 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 3
Software re-engineering
Reorganising and modifying existing software systems to make them more maintainable
"the examination of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.
[ElliotChikofsky and JamesCross, Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software 7(1):13-17, 1990.]
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 4
Topics coveredSource code translationReverse engineeringProgram structure improvementProgram modularisationData re-engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 5
Re-structuring or re-writing part or all of a legacy system without changing its functionalityApplicable where some but not all sub-systems of a larger system require frequent maintenanceRe-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented
System re-engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 6
When system changes are mostly confined to part of the system then re-engineer that partWhen hardware or software support becomes obsoleteWhen new ways of accessing are needed, but its functionality remains When tool support is are available
When to re-engineer
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 7
Re-engineering advantagesReduced 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 8
Business process re-engineeringConcerned with re-designing business processes to make them more responsive and more efficientOften reliant on the introduction of new computer systems to support the revised processesMay force software re-engineering as the legacy systems are designed to support existing processes
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 9
Forward engineering and re-engineering
Understanding andtransformation
Existingsoftware system
Re-engineeredsystem
Design andimplementation
Systemspecification
Newsystem
Software re-engineering
Forward engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 10
Forward engineering and re-engineering
“Forward engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system." [ElliotChikofsky and JamesCross, Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software 7(1):13-17, 1990.]
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 11
The re-engineering process
Reverseengineering
Programdocumentation
Datareengineering
Original data
Programstructure
improvement
Programmodularisation
Structuredprogram
Reengineereddata
ModularisedprogramOriginal
program
Source codetranslation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 12
Re-engineering cost factorsThe quality of the software to be re-engineeredThe tool support available for re-engineeringThe extent of the data conversion which is requiredThe availability of expert staff for re-engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 13
Re-engineering approaches
Automated restructuringwith manual changes
Automated sourcecode conversion
Restructuring plusarchitectural changes
Automated programrestructuring
Program and datarestructuring
Increased cost
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 14
Source code translationInvolves converting the code from one language (or language version) to another e.g. FORTRAN to CMay 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 15
The program translation process
Automaticallytranslate code
Design translatorinstructions
Identify sourcecode differences
Manuallytranslate code
System to bere-engineered
System to bere-engineered
Re-engineeredsystem
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 16
Reverse engineeringAnalysing software with a view to understanding its design and specificationMay be part of a re-engineering process but may also be used to re-specify a system for re-implementationBuilds a program data base and generates information from thisProgram understanding tools (browsers, cross-reference generators, etc.) may be used in this process
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 17
Reverse engineering“Reverse engineering is the process of analyzing a subject system with two goals in mind:
(1) to identify the system's components and their interrelationships; and,
(2) to create representations of the system in another form or at a higher level of abstraction."
[ElliotChikofsky and JamesCross, Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software 7(1):13-17, 1990.]
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 18
The reverse engineering process
Data stucturediagrams
Program stucturediagrams
Traceabilitymatrices
Documentgeneration
Systeminformation
store
Automatedanalysis
Manualannotation
System to bere-engineered
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 19
Reverse engineering“Design recovery is a subset of reverse engineering in which domain knowledge, external information, and deduction or fuzzy reasoning are added to the observations of the subject system." The objective of design recovery is to identify meaningful higher-level abstractions beyond those obtained directly by examining the system itself. [ElliotChikofsky and JamesCross, Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software 7(1):13-17, 1990.]
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 20
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 and reengineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 21
Program structure improvementMaintenance tends to corrupt the structure of a program. It becomes harder and harder to understandThe program may be automatically restructured to remove unconditional branchesConditions may be simplified to make them more readable
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 22
Program Restructuring“Restructuring is a transformation from one form of representation to another at the same relative level of abstraction." The new representation is meant to preserve the semantics and external behaviour of the original.
[ElliotChikofsky and JamesCross, Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software 7(1):13-17, 1990.]
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 23
Spaghetti logicStart: Get (Time-on, Time-off, Time, Setting, Temp, Switch)
if Switch = off goto offif Switch = on goto ongoto Cntrld
off: if Heating-status = on goto Sw-offgoto loop
on: if Heating-status = off goto Sw-ongoto loop
Cntrld: if Time = Time-on goto onif Time = Time-off goto offif Time < Time-on goto Startif Time > Time-off goto Startif Temp > Setting then goto offif Temp < Setting then goto on
Sw-off: Heating-status := offgoto Switch
Sw-on: Heating-status := onSwitch: Switch-heatingloop: goto Start
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 24
Structured control logicloop
-- The Get statement finds values for the given variables from the system’s-- environment.
Get (Time-on, Time-off, Time, Setting, Temp, Switch) ;case Switch of
when On => if Heating-status = off thenSwitch-heating ; Heating-status := on ;
end if ;when Off => if Heating-status = on then
Switch-heating ; Heating-status := off ;end if;
when Controlled =>if Time >= Time-on and Time < = Time-off then
if Temp > Setting and Heating-status = on thenSwitch-heating; Heating-status = off;
elsif Temp < Setting and Heating-status = off thenSwitch-heating; Heating-status := on ;
end if;end if ;
end case ;end loop ;
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 25
Another Spaghetti logicSTART:
GOTO MAMMALSDOG:
WALK THE DOGGOTO CAT
MAMMALS:GOTO DOG
FISH:FEED THE FISHCOVER THE BIRDGOTO FROG
CAT:PUT OUT THE CATGOTO FISH-AND-FOWL
FISH-AND-FOWL:GOTO FISH
FROG:SING TO THE FROG
EXIT.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 26
Another structured control logic
START:CALL FUNCTION DOGCALL FUNCTION CATCALL FUNCTION FISHCALL FUNCTION BIRDCALL FUNCTION FROGEXIT.
DOG:WALK THE DOGRETURN
CAT:PUT OUT THE CATRETURN
FISH:FEED THE FISHRETURN
BIRD:COVER BIRD CAGERETURN
FROG:SING TO THE FROGRETURN
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 27
Condition simplification
-- Complex conditionif not (A > B and (C < D or not ( E > F) ) )...
-- Simplified conditionif (A <= B and (C>= D or E > F)...
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 28
Automatic program restructuring
Graphrepresentation
Programgenerator
Restructuredprogram
Analyser andgraph builder
Program to berestructured
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 29
Restructuring problemsProblems 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 codeThe understandability of data-driven programs may not be improved by re-structuring
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 30
Program modularisationThe process of re-organising a program so that related program parts are collected together in a single moduleUsually a manual process that is carried out by program inspection and re-organisation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 31
Data re-engineeringInvolves analysing and reorganising the data structures (and sometimes the data values) in a programMay be part of the process of migrating from a file-based system to a DBMS-based system or changing from one DBMS to anotherObjective is to create a managed data environment
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 32
Approaches to data re-engineeringApproach DescriptionData cleanup The data records and values are analysed to improve their quality.
Duplicates are removed, redundant information is deleted and a consistentformat applied to all records. This should not normally require anyassociated program changes.
Data extension In this case, the data and associated programs are re-engineered to removelimits on the data processing. This may require changes to programs toincrease field lengths, modify upper limits on the tables, etc. The data itselfmay then have to be rewritten and cleaned up to reflect the programchanges.
Data migration In this case, data is moved into the control of a modern databasemanagement system. The data may be stored in separate files or may bemanaged by an older type of DBMS.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 33
Data problemsEnd-users want data on their desktop machines rather than in a file system. They need to be able to download this data from a DBMSSystems may have to process much more data than was originally intended by their designersRedundant data may be stored in different formats in different places in the system
Data migration
Databasemanagement
system
Logical andphysical
data models
describes
File 1 File 2 File 3 File 4 File 5 File 6
Program 2 Program 3
Program 4 Program 5 Program 6 Program 7
Program 1
Program 3 Program 4 Program 5 Program 6
Program 2 Program 7
Program 1
Becomes
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 35
Data problemsData 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 literalsNo data dictionary
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 36
Data value inconsistenciesData inconsistency DescriptionInconsistent defaultvalues
Different programs assign different default values to the same logical dataitems. This causes problems for programs other than those that created thedata. The problem is compounded when missing values are assigned adefault value that is valid. The missing data cannot then be discovered.
Inconsistent units The same information is represented in different units in differentprograms. For example, in the US or the UK, weight data may berepresented in pounds in older programs but in kilograms in more recentsystems. A major problem of this type has arisen in Europe with theintroduction of a single European currency. Legacy systems have beenwritten to deal with national currency units and data has to be converted toeuros.
Inconsistent validationrules
Different programs apply different data validation rules. Data written byone program may be rejected by another. This is a particular problem forarchival data which may not have been updated in line with changes todata validation rules.
Inconsistentrepresentationsemantics
Programs assume some meaning in the way items are represented. Forexample, some programs may assume that upper-case text means anaddress. Programs may use different conventions and may therefore rejectdata which is semantically valid.
Inconsistent handlingof negative values
Some programs reject negative values for entities which must always bepositive. Others, however, may accept these as negative values or fail torecognise them as negative and convert them to a positive value.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 37
Data conversionData re-engineering may involve changing the data structure organisation without changing the data valuesData 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 38
The data re-engineering process
Entity namemodification
Literalreplacement
Data definitionre-ordering
Datare-formatting
Default valueconversion
Validation rulemodification
Dataanalysis
Dataconversion
Dataanalysis
Modifieddata
Program to be re-engineered
Change summary tables
Stage 1 Stage 2 Stage 3
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 39
Key pointsThe objective of re-engineering is to improve the system structure to make it easier to understand and maintainThe re-engineering process involves source code translation, reverse engineering, program structure improvement, program modularisation and data re-engineeringSource code translation is the automatic conversion of of program in one language to another
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 40
Key pointsReverse engineering is the process of deriving the system design and specification from its source codeProgram structure improvement replaces unstructured control constructs with while loops and simple conditionalsProgram modularisation involves reorganisation to group related itemsData re-engineering may be necessary because of inconsistent data management