COMP3033 Workbook III - studentnet.cs.manchester.ac.uk
Transcript of COMP3033 Workbook III - studentnet.cs.manchester.ac.uk
Course Notes for
COMP30332
SOFTWARE EVOLUTION
Part III
2009/2010 Academic Session
Suzanne M. Embury Room KB 2.105
Department of Computer Science University of Manchester
Oxford Road Manchester M13 9PL
U.K.
Telephone: (0161) 275 6128 Fax: (0161) 275 6236
E-Mail: [email protected]
Part III: Evolution of Legacy Systems
The modern business environment requires organisations to be flexible and open to change if they are to gain and retain their competitive edge. One important factor that affects how quickly an organisation can change its working practices and policies is the ease with which it can modify its information systems, to support the new way of working. Unfortunately, many organisations are saddled with aging computer systems that are extremely difficult to change. Such systems are known as “legacy systems”. In this group of lectures, we will look more closely at the legacy system phenomenon, and at some techniques for helping them to evolve in step with the changing business environment.
Lectures 11 to 14. Legacy Systems: Challenges and Opportunities
In these lectures, we introduce the notion of a legacy system, and discuss why such systems present a major technical and managerial challenge for today’s businesses. We examine the range of options available for converting legacy systems into efficient, reliable and flexible systems, able to support a rapidly changing business. In particular, we consider how risk may be controlled in such projects by migrating functionality incrementally rather than in bulk.
CS333 Software Evolution © University of Manchester 2001
The Legacy Dilemma
Legacy System
Notes
COMP3033 Software Evolution © University of Manchester 2006
To Change or Not to Change?
Faulty maintenance → dire consequencesLost revenue/market share, legal consequences
Inability to change → dire consequencesInability to modify an inventory system so that it handled 9 digit part numbers, rather than 6, led to the bankruptcy of the company involved (Martin & McClure, 1983)Supplier of DB system had 23 full-time “fire-fighters” for that one system, but frequent overnight “incidents” led to ever increasing customer dissatisfaction (Calow 1990)
Notes
COMP3033 Software Evolution © University of Manchester 2006
Recap: Barriers to Change
A typical legacy systemis large (millions of lines of code)is old (typically more than 10 years old)runs on old hardware (e.g. old mainframe technology, terminal-style UIs)is built using old technology (e.g. COBOL, IMS, …)is very fragile, after years of increasingly desperate maintenanceis poorly documented and poorly understoodbased on stovepipe design
CS333 Software Evolution © University of Manchester 2001
Maintenance Bound
Some organisations found themselves in the position of being maintenance bound
Software Budget
Need to maintain
current system functionality
Need to expand functionality to support new
business ideas
CS333 Software Evolution © University of Manchester 2001
The Legacy Challenge
An organisation in a maintenance bound state cannot react to changes in market
Cannot implement new ideas to get aheadCannot implement competitors’ ideas to stay ahead
Organisations with more modern ISs are often much more “nimble”
Example: MCI friends and family programmeExample: CRM and mass customisationBusiness process re-engineering (BPR)
Notes
COMP3033 Software Evolution © University of Manchester 2006
The Legacy Opportunity
Legacy systems can be a major assetParticularly in terms of their dataExample: BT and their customer database
New marketing techniques, such as churn analysis
Also, in terms of system integrationExample: just-in-time stock management
Integrate inventory systems with order handling systems to support high efficiency warehouse management/production schedules
Heritage Systems
COMP3033 Software Evolution © University of Manchester 2006
Options?
How can we make our legacy systems easier to evolve?
Perform preventive maintenance to improve maintainability
Rebuild the system from scratch (as if current system did not exist)
COMP3033 Software Evolution © University of Manchester 2006
Early Attempts
Legacy environment
Target environment
A DC
BELegacy
applications A DC
BE Target
applications
F
Users
Cut over when target
system complete
Users
Notes
COMP3033 Software Evolution © University of Manchester 2006
Why this Approach Fails
Brodie and Stonebraker (1995)1. A better system must be promised2. Business conditions never stand still3. Specifications rarely exist4. Undocumented dependencies frequently exist5. Legacy IS can be too big to cut over data6. Management of large projects is hard7. Lateness is seldom tolerated8. Large projects tend to bloat9. Homeostatis is prevalent10. Analysis paralysis sets in
COMP3033 Software Evolution © University of Manchester 2006
Options?
How can we make our legacy systems easier to evolve?
Perform preventive maintenance to improve maintainability
Modernise the system
Rebuild the system from scratch (as if current system did not exist)
Costs?
Risks?
Benefits?
COMP3033 Software Evolution © University of Manchester 2008
System Modernisation
What aspects of a system might be modernised?
Notes
COMP3033 Software Evolution © University of Manchester 2006
Migration to New H/W Infrastructure
Why?How?
ConsiderConstraints imposed by old/new platformsSoftware architecture – is it portable?Emulators/Compatibility Mode
Example: Transitive Technologies
COMP3033 Software Evolution © University of Manchester 2006
Migration to New S/W Infrastructure
Why?How?
Time consuming (costly)Error prone (risky)
Software tools can helpTurn non-viable modernisation effort into viable one
COMP3033 Software Evolution © University of Manchester 2006
Source Code Translation
Tools to assist in the process of translating code written in one language into “equivalent”code written in anotherExamples
COBOL-74 to COBOL-85FORTRAN to CC to Java
Translate the following COBOL program into Java
Notes
COMP3033 Software Evolution © University of Manchester 2006
Example COBOL CodeDATA DIVISION.
01 WS-NUMBER PIC 9(2).02 WS-FACTORIAL PIC 9(15) VALUE 1.
PROCEDURE DIVISION.
1000-FACTORIAL.DISPLAY “Enter a number: ”.ACCEPT WS-NUMBER.IF WS-NUMBER < 1
GOTO 1000-EXITEND-IF.PERFORM UNTIL WS-NUMBER <= ZERO
MULTIPLY WS-FACTORIAL BY WS-NUMBERSUBTRACT 1 FROM WS-NUMBER
END-PERFORM.DISPLAY “The answer is: ”.DISPLAY WS-FACTORIAL.
1000-EXIT.EXIT.
COMP3033 Software Evolution © University of Manchester 2010
Points to Note
What did you notice about translating this code?
What would be easy for a software tool to do?
What would be more of a challenge for a completely automatic software translator?
COMP3033 Software Evolution © University of Manchester 2006
Points to Note (1)
There is not one correct translationA many-to-many mapping between programs
All languages have same basic capabilitiesBut some things are more effort in some languages than others
We need to translate:Data structures and typesAtomic statementsComplex statements (seq, alt, iter)Program organisation statements (e.g. modules, classes, packages)
Notes
COMP3033 Software Evolution © University of Manchester 2006
Points to Note (2)
Not even a one-to-one correspondence between data types
E.g. PIC 9(15) maps to which Java data type?99999999999999910 =
111000110101111110101001001100011001111111111111112
Requires 50 bits, so use a long
E.g. PIC 9(2) maps to which Java data type?
9910 = 11000112
Requires 7 bits, therefore use a byte
COMP3033 Software Evolution © University of Manchester 2006
Points to Note (3)
Nor a one-to-one correspondence between atomic/complex statements
How did you deal with the GOTO statement?Did you combine the two final DISPLAY statements into one for the Java translation?How did you translate ACCEPT into Java?
Often get round these problems by using specially defined libraries/packages that give nearer equivalents (see example translation)
COMP3033 Software Evolution © University of Manchester 2006
Points to Note (4)
The most difficult part is to add program organisation that is not already present
E.g. How did you translate the code to a Java class declaration?
Often, cannot match the semantics exactlyE.g. COBOL semantics are very complex, and often unintuitive and unhelpful (e.g. ALTER)So – you cannot trust the automatic translationYou must test thoroughly afterwards
Notes
COMP3033 Software Evolution © University of Manchester 2006
Possible Translation to Javaimport translate.io.InStream
public class Factorial {public static void main(String[] args) {
System.out.println("Enter a number: ");short number = InStream.getInteger;
if(number > 0) {long factorial = 1;for(short i = number; i > 0; i--)
factorial = factorial * i;System.out.println("The answer is: "+factorial);
}}
}
COMP3033 Software Evolution © University of Manchester 2006
Restructuring
Source code translation tools can speed up the migration of individual programs
But, the translated program is often as poorly structured as the original
The idea of migration is to improve the maintainability of the code
Remove the bad effects of poor initial design and years of maintenance
We need a tool to help us restructure the code according to modern/structured programming styles
COMP3033 Software Evolution © University of Manchester 2006
Goto Considered Harmful
Classic paper by Edsger Djikstra (1968)Structured programming
major development in the history of programming and programming languagesReplace GOTO with structured control constructs such as WHILE-DO, REPEAT-UNTIL, CASE, …Lots of evidence to suggest that structured programs are less error prone that unstructured onesLots of evidence to suggest that structured programs are easier to understand and change than unstructured ones
Notes
COMP3033 Software Evolution © University of Manchester 2006
Goto Considered Unnecessary
It has long been known that goto’s are not strictly necessary in programming languages
E.g. Peterson, Kasami and Tokura (1973) showed that every program can be converted into a program that contains no goto statements, provided that the language can support:
if-then-elsewhile-do and repeat-until with multiple exit points (i.e. break statements)
Modern languages don’t even support GOTOE.g. Java
COMP3033 Software Evolution © University of Manchester 2006
Recognising Structured Control
It is relatively easy to restructure code with goto’s into equivalent code using structured control constructs.
First, construct the control flow graph for the programThen, look for standard “patterns”corresponding to structured control constructsFinally, rebuild the program from the CFG
COMP3033 Software Evolution © University of Manchester 2006
Example1 1000-FACT.2 ACCEPT WS-NUMBER.3 1000-TEST-EXIT.4 IF WS-NUMBER < 15 GOTO 1000-DISPLAY-RESULT6 END-IF.7 MULTIPLY WS-FACT BY WS-NUMBER.8 SUBTRACT 1 FROM WS-NUMBER.9 GOTO 1000-TEST-EXIT.10 1000-DISPLAY-RESULT.11 DISPLAY WS-FACT.12 1000-EXIT.13 EXIT.
COMP3033 Software Evolution © University of Manchester 2006
Spaghetti Code
But – dealing with true spaghetti code is more challengingExamples:
Jumping into the middle of loopsJumping between nested loops at different levelsJumping into conditional statements
Look at the following program, and try to figure out what it does
COMP3033 Software Evolution © University of Manchester 2006
Spaghetti Code ExampleStart: get(Time-on, Time-off, Time, Setting, Temp, Switch);
if Switch = off then goto off;if Switch = on then goto on; goto Cntrld;
off: if Heating-Status = on goto Sw-off; goto loop;on: if Heating-Status = off goto Sw-on; goto loop;Cntrld: if Time = Time-on goto on;
if Time = Time-off goto off;if Time < Time-on goto Start;if Time > Time-off goto Start;if Temp >= Setting then goto off;if Temp < Setting then goto on;
Sw-off: Heating-Status := off; goto Switch;Sw-on: Heating-Status := on;Switch: Switch-Heating;Loop: goto Start;
COMP3033 Software Evolution © University of Manchester 2006
Control Flow Graph
1 2 3
5
7
9 10 11 12 13 14
15
17
1819
T F
Notes
COMP3033 Software Evolution © University of Manchester 2006
Spaghetti Elimination
GOTOs can be removed from programs by:Introducing new (control) variablesReplicating code/splitting nodesIntroducing new procedures/procedure callsSimplifying conditional statements
A
B
C
D
if A thenif B then
Lc: Cend-if
elsegoto Lc
end-ifD
A
B
C1
D
C2
if A thenif B then
C1
end-ifelse
C2
end-ifD
COMP3033 Software Evolution © University of Manchester 2006
Control Flow Graph
1 2 3
5
7
9 10 11 12 13 14
15
17
1819
T F
COMP3033 Software Evolution © University of Manchester 2006
Control Flow Graph T F
5
15
18
1 2 3
5
7
9 10 11 12 13 14
15
17
1819
Notes
COMP3033 Software Evolution © University of Manchester 2006
Control Flow Graph T F
1 2 3 9 10 11 12 13 14
15
18
19
5
15
18
5
15
18
5
15
18
7
17
18
7
17
18
7
17
18
Temp >= Setting
Temp < Setting
COMP3033 Software Evolution © University of Manchester 2006
Control Flow Graph T F
1 11 12
19
5
15
18
2
5
7
17
18
3
7
9
7
10
5
13
5 7
COMP3033 Software Evolution © University of Manchester 2006
Control Flow Graph T F
1
11 12
19
5
15
18
2
5
7
17
18
7 9
7
10
5
13
5 7
Notes
COMP3033 Software Evolution © University of Manchester 2006
Regenerated Codewhile true do
get(Time-on, Time-off, Time, Setting, Temp, Switch);case Switch of
“off”: switch-off;“on”: switch-on;else: if Time = Time-on switch-on;
if Time = Time-off switch-off;if Time-on < Time < Time-off
if Temp >= Settingswitch-off
elseswitch-on
end-if;end-case;
end-while;
proc switch-offif Heating-Status = on
Heating-Status := off;Switch-Heating;
end-if;
proc switch-onif Heating-Status = off
Heating-Status := on;Switch-Heating;
end-if;
COMP3033 Software Evolution © University of Manchester 2006
Limitations of Restructuring
Restructuring is a very useful toolBut it has its limitations:
Sometimes, the restructuring algorithm goes too far and the result is less readable than the originalThe code will now look unfamiliar to the maintenance programmers, who might have been quite familiar with it before restructuring.Restructuring can make a mockery of comments, as the code they were written for no longer existsIt’s hard to restructure completely automatically, and some user input is still required (e.g. procedure names)
COMP3033 Software Evolution © University of Manchester 2010
Re-modularisation
So far, we’ve considered restructuring at the level of individual statementsHowever, code can also be poorly structured in terms of its overall organisation
Poor separation into modules, packages or classesOriginal design okay, but subsequent changes in requirements mean that it’s no longer adequate
Changing to a new module/class structure is time consumingAutomatic refactoring based on CG/DDG
Notes
COMP3033 Software Evolution © University of Manchester 2006
Limitations of Re-Modularisation
Re-modularisation is useful when maintaining programs that contain explicit structuring commandsBut, many legacy systems are written in languages which do not provide any explicit support for this higher-level structuring
Some don’t even support procedures and functions!The original design structure will be implicit in the structure of the code, not explicitAny original design will have been obscured by subsequent evolution activities
COMP3033 Software Evolution © University of Manchester 2006
Design Recovery
In order to comprehend and change such code, we need to understand its structure (design)Documentation/staff missing/inaccurateOnly reliable source of information is the code itselfSo, we need tools to help us recover this design information from an analysis of the codeThis is known as Reverse Engineering
COMP3033 Software Evolution © University of Manchester 2006
Forward/Reverse Engineering
RequirementsSpecification
SystemDesign
Imp. &Unit Test
Integration &System Test
Operation &Maintenance
Req. Spec.
Design
Code
Impl.
Forward Engineering
Reverse Engineering Impl.
Req. Spec.
Design
Notes
COMP3033 Software Evolution © University of Manchester 2006
Modernisation of Interfaces
Why?
How?Again, a layered system architecture helpsMiddle-layer treated like an API if possibleOtherwise?
Have to construct wrappersScreen-scraping to fake an API?
COMP3033 Software Evolution © University of Manchester 2006
Screen Scraping Example
COMP3033 Software Evolution © University of Manchester 2010
More Radical Modernisation
When the main costs of the legacy system are associated with the application code itself, then more radical modernisation is often needed.
This is like rebuilding from scratch, but we want to keep the costs and risks as low as possible.
Answer:
Notes
COMP3033 Software Evolution © University of Manchester 2006
Re-engineering
Req.Spec.
SystemDesign
Imp. &UnitTest
Integ &SysTest
Op. &Maint.
Forward Engineering
ReverseEngineeringTechniques
Existing implementation (plus documentation)
Spec for new functionality
Spec for existing
functionality
Design for existing
functionality
COMP3033 Software Evolution © University of Manchester 2006
Re-engineering
Claim:Re-engineering is faster and less risky than a straight rebuildReverse engineering of specification and design is faster, and less error prone than rewriting them from scratch
But, many re-engineering projects have failed disastrouslyWhy?
COMP3033 Software Evolution © University of Manchester 2006
Approaches to Migration
Cold TurkeyExperience in general software development shows that all-or-nothing approaches rarely succeedYou learn about your biggest mistakes during cut over – this is too late!
Chicken LittleBrodie and Stonebraker suggest that it is better to migrate the legacy system in a piecemeal fashionIn general software development, incremental approach is less risky
Notes
COMP3033 Software Evolution © University of Manchester 2006
Example
Large US corporation had 12 centres, supporting around 800 simultaneous users
Wished to replace old terminals with workstations, plus new GUIBut, can’t replace 800 computers overnight!So, followed a phased approach, and migrated 4 service centres at firstFound that users hated the new GUIs – they had not been consultedBegan again, with user involvementPhased approach meant that the problem was detected early, and was cheaper to correct
COMP3033 Software Evolution © University of Manchester 2006
Incremental Migration
RamificationsWhen we replace a component, the existing (legacy) components must continue to operate as beforeIn addition, the new component must operate as if in the completed target environmentSometimes, we will want to keep both the legacy and the target component operating in tandem
How easy all this is to achieve depends on the legacy IS architecture
COMP3033 Software Evolution © University of Manchester 2008
IS Components
ISs typically consist of:Interfaces
With humansWith other systems
ApplicationsPerforming business functions
Data management serviceAllows the state of the IS to persistE.g. a DBMS
These components may be well-modularised, or all mixed up together with one another
Notes
CS333 Software Evolution © University of Manchester 2001
Decomposable IS Architecture
Databases
Foreign ISs End users
System interfaces User interfaces
Database service
C:> accntbalancefull=truenum=36233
Fetching recordPlease wait
Application modules
Decomposable IS Architectures More and more people are coming to the conclusion that fully decomposable architectures are most suitable for supporting evolution in the long term.
“The basic idea is to exploit the fact that components can evolve at their own speed (so long as they don’t break the interface [requirements]). Application logic and data components should be split along business process boundaries to allow business processes to change with minimal disruption to other business processes. We could put fast-changing parts into their own components and slower changing parts into other components. In practice, presentation logic will almost certainly change at its own (fast!) speed and should be isolated out. At the other end of the spectrum, database logic, especially data such as customer data or product data that is used everywhere, will change slowly and should be behind the protective wall of a component interface to ensure its integrity stays intact.” p.17, Britton 2001.
CS333 Software Evolution © University of Manchester 2001
Semi-Decomposable IS Arch.
User interfaces
Applications and Database service
C:> accntbalancefull=truenum=36233
Fetching recordPlease wait
Databases
Foreign ISs End users
System interfaces
Notes
COMP3033 Software Evolution © University of Manchester 2010
Semi-Decomposable IS Arch.
Interfaces and Application Logic
Databases
Foreign ISs End users
Database service
CS333 Software Evolution © University of Manchester 2001
Non-Decomposable IS Arch.
Databases
Interfaces, applications and database service
Foreign ISs End users
CS333 Software Evolution © University of Manchester 2001
The Target IS
Obviously, we want the target IS to be fully decomposableDuring migration, we select elements of the legacy IS, for incremental re-engineering in the target IS
Until the target IS is complete, the organisation’s IS is a hybrid of the legacy and the partially constructed target ISBoth work together to keep the business functioning during the migration
Notes
CS333 Software Evolution © University of Manchester 2001
Gateways
The principal means of implementing this hybrid IS is through the use of components called gateways
Legacy IS
Target IS
C:> accntbalancefull=truenum=36233
Fetching recordPlease wait
Legacy UI
BalanceNew AccDelete
Target UI
Gateway
CS333 Software Evolution © University of Manchester 2001
Role of Gateways
Insulate components from changes made in other components
E.g. legacy UI used with target application modules
Translate requests/responses between formats required by components
E.g. COBOL data structures to relational data
Coordinate updates made through different components, to maintain consistency
E.g. propagate updates made through target UI to legacy IS database
CS333 Software Evolution © University of Manchester 2001
Types of Gateway
Two basic types of gatewayForward gatewaysReverse gateways
Legacy application modules
Target DB
Forward gateway
Legacy DBTarget
application modules
Reverse gateway
Notes
CS333 Software Evolution © University of Manchester 2001
Example Migration
XYZ plc wishes to migrate its customer information system away from COBOL and IDMS, towards a client-server/RDBMS based architectureThis requires
Replacement of UIs with web-based GUIsAdditional functionality to be added to standard account management applicationsNew database, based on relational technology, but no new data is to be stored as yet
COMP3033 Software Evolution © University of Manchester 2010
Migration Strategies
The first task is to determine whether the legacy IS is decomposable or not
In this example: a hybrid of fully decomposable and semi-decomposable
Next, we must select a migration strategyForward migrationReverse migrationGeneral migration
CS333 Software Evolution © University of Manchester 2004
Incremental Migration Example
CustDB
File handlingroutines
BatchCustomer
Entry
CustomerMgt
CustomerService UI
MarketingUI
SourceArchitecture CustDB
RDBMS
BatchCust Entry
CustomerMgt
ListMgt
CustomerService UI
MarketingUI
TargetArchitecture
Notes
CS333 Software Evolution © University of Manchester 2001
Forward Migration
First, migrate the DB in one stepCreate and load target DBCreate forward gatewayInstall gateway to divert legacy applications to target DB, and away from legacy DB
Now entire IS works as before, but accesses and stores data in the target DBMS, not in the legacy DBMS
CS333 Software Evolution © University of Manchester 2002
Forward Migration: Step 1
CustomerMgt
CustomerService UI
MarketingUI
BatchCustomer
Entry
CustDB
RDBMS
CS333 Software Evolution © University of Manchester 2004
Forward Migration: Step 2
Next, incrementally migrate the application modules and their interfaces, removing legacy applications as you go
CustomerMgt
CustomerService UI
MarketingUI
CustDB
RDBMS
BatchCustomer
Entry
ListMgt
Notes
CS333 Software Evolution © University of Manchester 2004
Forward Migration: Step 3
Next, incrementally migrate the application modules and their interfaces, removing legacy applications as you go
CustomerMgt
CustomerService UI
MarketingUI
CustDB
RDBMS
BatchCustomer
Entry
ListMgt
CS333 Software Evolution © University of Manchester 2004
Forward Migration: Step 4
Next, incrementally migrate the application modules and their interfaces, removing legacy applications as you go
CustomerMgt
CustomerService UI
MarketingUI
CustDB
RDBMS
BatchCustomer
Entry
ListMgt
CS333 Software Evolution © University of Manchester 2004
Forward Migration: Step 5
Next, incrementally migrate the application modules and their interfaces, removing legacy applications as you go
CustomerMgt
CustomerService UI
MarketingUI
CustDB
RDBMS
BatchCustomer
Entry
ListMgt
Notes
CS333 Software Evolution © University of Manchester 2004
Forward Migration: Step 6
Finally, when all legacy components are replaced and all gateways are removed, the migration is complete
BatchCust Entry
CustomerService UI
CustDB
RDBMS
CustomerMgt
MarketingUI
ListMgt
COMP3033 Software Evolution © University of Manchester 2008
The Business Case
At each stage, how did we decide what component to migrate next?
Decision based on:
In the exam, need to refer to all of these factors for full marks
CS333 Software Evolution © University of Manchester 2002
Reverse Migration
First, migrate the target interfaces and applications
Create and install target applications + interfacesCreate reverse gatewayInstall gateway to divert target applications to the legacy database
Now entire IS provides some new functionality, but is still operating to the original legacy database
Notes
CS333 Software Evolution © University of Manchester 2005
Reverse Migration: Step 1
CustDB
File handlingroutines
BatchCustomer
Entry
CustomerMgt
CustomerService UI
MarketingUI
First, migrate application interfacesInstall reversegateways to translate requests for legacy components
CS333 Software Evolution © University of Manchester 2005
Reverse Migration: Step 2
BatchCustomer
Entry
ListMgt
MarketingUI
Next, incrementally migrate downwards, installing more reverse gateways as required
CustDB
File handlingroutines
CustomerService UI
CustomerMgt
CS333 Software Evolution © University of Manchester 2005
Reverse Migration: Step 3
BatchCustomer
Entry
ListMgt
MarketingUI
Next, incrementally migrate downwards, installing more reverse gateways as required
CustDB
File handlingroutines
CustomerService UI
CustomerMgt
Notes
CS333 Software Evolution © University of Manchester 2005
Reverse Migration: Step 4
BatchCustomer
Entry
ListMgt
MarketingUI
Next, incrementally migrate downwards, installing more reverse gateways as required
CustDB
File handlingroutines
CustomerService UI
CustomerMgt
CS333 Software Evolution © University of Manchester 2005
Reverse Migration: Step 5
BatchCust Entry
ListMgt
MarketingUI
CustDB
File handlingroutines
CustomerService UI
CustomerMgt
Next, incrementally migrate downwards, installing more reverse gateways as required
CS333 Software Evolution © University of Manchester 2005
Reverse Migration: Step 6
Finally, migrate the legacy data to the new data management system, and remove the last gatewayCutover is very risky for this migration strategy!
BatchCust Entry
ListMgt
MarketingUI
CustDB
RDBMS
CustomerService UI
CustomerMgt
Notes
CS333 Software Evolution © University of Manchester 2005
Forward vs Reverse Migration
Both migration strategies took the same number of stepsBoth produced the same final systemSo, what’s the difference?
BenefitsCostsRisks
Discuss with your neighbours what differentiates these two strategies. You can make notes in this space. ……………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
CS333 Software Evolution © University of Manchester 2002
General Migration
Both forward and reverse migration require that the DB be migrated in one stepThis is risky – we would prefer to be able to migrate the DB incrementally, as well as the applications and interfacesBy using a combination of these strategies, we can achieve this, at the expense of greater complexity of the system (plus additional effort writing and maintaining gateways)
Notes
CS333 Software Evolution © University of Manchester 2002
Example Architecture
BatchCustomer
Entry
MarketingUI
CustomerService UI
ListMgt
CustomerMgt
CustDBCustDB
RDBMSFile handlingroutines
CS333 Software Evolution © University of Manchester 2001
Evolution in the Long Term
In the examples, the gateways were always removed for the final systemIn reality, some gateways may become permanent parts of the system
Because we don’t dare to retire the legacy componentBecause we never complete the planned migration due to changing business requirements
Allows systems to be continuously evolved, over the long term
Notes
COMP3033 Software Evolution © University of Manchester 2006
The Bottom Line
As a member of maintenance staff, your primary responsibility is to:
KEEP THE BUSINESSUP AND RUNNING
CS333 Software Evolution © University of Manchester 2001
Take Home Message
Acknowledgements
Much of the material presented in these lectures was taken from Migrating Legacy Systems, by Mike Brodie and Mike Stonebraker (1995). A further useful source of practical advice on modernisation is Modernising Legacy Systems, by Robert Seacord, Daniel Plakosh and Grace Lewis (2003). For details of how to formulate business cases for system modernisation projects, see Reifer (2002).
Self Test 3: Evolution of Legacy Systems 3.1 Which of the following characteristics are part of the definition of a legacy system?
a. The system is very difficult to maintain. b. The system has a great many users. c. The system is performing a useful function for its organisation. d. The system has not been modified since it was installed. e. The system has an old-fashioned terminal-style interface.
3.2 Which of the following is not one of the expected benefits of the Chicken Little
approach to system re-engineering?
a. Some improvement or new functionality can be delivered to the client in a relatively short time-scale.
b. If the current increment fails, then only a limited amount of rework needs to be done.
c. The needs of all users can be satisfied in a short time scale. d. Cut-over of each individual step is less risky.
3.3 The target architecture of any re-engineering project should be:
a. fully decomposable, b. semi-decomposable, c. non-decomposable, or d. none of the above.
3.4 A code restructuring tool would be of direct benefit to the maintainers of a system in
which of the following situations?
a. The code to be maintained is well designed, but is written in a legacy language. Your organisation now employs very few people with skills in this language.
b. The system is unable to meet the performance targets (i.e. transactions processed per second) demanded of it by the organisation which owns it.
c. Problems with poor design of the user interface to the system are suspected to be the cause of the large amount of inaccurate data that is entering the system, and filtering through to downstream systems.
d. The system is very brittle (i.e. fails when even simple changes are made) due to the effects of years of emergency maintenance work, which have obscured the original system design.
3.5 Which of the following are important factors in the decision of which migration
strategy should be adopted for a given Chicken Little system re-engineering project?
a. The time required to perform a cold turkey migration of any databases involved.
b. The stage in the project at which the machine(s) on which the target architecture can run will become available.
c. The amount of new data that must be stored by the target system that is not currently stored by the legacy system.
d. The budget that is available for retraining staff to use the target system. e. The amount of end-user involvement in the project.
Sample Exam Question 3 3 You are in charge of a project which aims to re-engineer an order picking
system in use at an equipment supplier. The system takes details of orders for configurations, and issues instructions to warehouse staff, describing which parts need to be collected for each order and where in the warehouse they can be found. Once collected, the parts are placed on a conveyor belt, which transports them to another part of the warehouse where they will be assembled into the completed configurations. The system is regarded as mission critical for the company. The existing system is based around a set of dumb terminals and printers installed at various locations around the company’s warehouse. The overall architecture of the system is shown in the figure below.
Details of orders are entered into the system by means of a continuous batch process (the Order Update System), which scans the main company database at regular intervals for any new orders that are ready for picking, extracts information about the parts required and caches them locally as flat files (the Local Order Store). These flat files also record details of the current inventory of parts and their locations in the warehouse. When a member of warehouse staff is ready to process a new order, he or she consults the Order Picking System, using one of the dumb terminals. The system then searches for the most urgent unprocessed order, determines where the parts should be selected from and then prints a list of instructions for the member of staff to carry out. As the parts are retrieved, they are loaded onto a conveyor belt to be transported to the assembly floor. The warehouse staff member then uses the Order Picking System to record which parts have been successfully located and (when ready) the dispatch of the complete order for assembly. Finally, the Order Picking System updates the inventory and the order status in the main company database.
Local Order Store
Main Company
DB
Order Update System
To Archives
Order Picking System
The Order Picking System is also used to update the stock levels in the inventory when new parts are delivered to the warehouse. In fact, the Local Order Store is currently the only place where the company stores computerised details of the parts it has in stock, and it is therefore backed up every night to a tape store. Details of completed orders remain in the Local Order Store for one week, in case there are any queries or amendments to be made, after which time they are deleted from the system. The company has two principal motivations for wishing to migrate this system. First, it is a mission critical system for the company, but the current implementation is slow, less than reliable and difficult to maintain. Second, the company would like to implement a more pro-active management system for its stock, which would predict shortages and order in parts ahead of time. The current flat file system cannot support this new functionality. The target system will therefore replace the current flat file store and off-line archive with a modern database management system. The front end will be replaced by a PC-based GUI, that displays details of multiple orders that are awaiting completion and that thus gives warehouse staff more responsibility and control over their time. Since the groups of staff who manage deliveries of stock are completely different from those who handle order picking, a separate front end is required for inventory management that can be used independently of the order picking system. Orders will still enter the system through the batch-scanning of the main company database, but they will now be retained in the Order Picking Database for at least two years, as they form the raw data on which the stock fluctuations will be predicted.
a) Design a fully-decomposable architecture for the new system and illustrate it by drawing a diagram that shows the new components to be built, their relationship to one another and any links with any existing components that will be retained. Use this diagram to explain how your architecture will fulfil the requirements outlined above.
6
b) Since the order picking system is mission critical for your company, you decide to minimise the risks involved in its migration by adopting an incremental “Chicken Little” strategy. Based on the information given about the existing and required systems, would you recommend a forward migration strategy, a reverse migration strategy or a general (hybrid) migration strategy for this project? Justify your answer by making clear reference to the aspects of the system description that led you to your answer. (6 marks)
6
c) Based on the recommendation you made in answer to part c) of this question, describe the steps you would take in order to incrementally migrate to your proposed target architecture. For each major step, you should draw an architecture diagram, showing the role, type and placement of any gateways and the order in which the new components are to be brought into operation.
8
References Used in Part III 2001 C. Britton
IT Architectures and Middleware, Addison-Wesley.
1995 M.L. Brodie and M. Stonebraker Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach, Morgan Kaufmann Publishers, Inc.
1992 J.H. Cross, E.J. Chikofsky and C.H. May Jr. Reverse Engineering, in Advances in Computers, Vol. 35, pp. 199-254.
1968 E.W. Dijkstra Go To Statement Considered Harmful, in Communications of the ACM, Vol. 11(3), March, pp. 147-148.
1973 W.W. Peterson, T. Kasumi and N. Tokura On the Capabilities of While, Repeat and Exit Statements, in Communications of the ACM, Vol. 16(8), pp. 503-512.
2002 D. Reifer Making the Software Business Case: Improvement by the Numbers, Addison-Wesley, Boston MA.
2003 R.C. Seacord, D. Plakosh and G.A. Lewis Modernising Legacy Systems, The SEI Series in Software Engineering, Addison-Wesley.