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


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


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


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


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


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)


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


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


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?


System Modernisation

What aspects of a system might be modernised?

Notes


Migration to New H/W Infrastructure

Why?How?

ConsiderConstraints imposed by old/new platformsSoftware architecture – is it portable?Emulators/Compatibility Mode

Example: Transitive Technologies


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


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


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.


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?


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


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


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)


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


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);

}}

}


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


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


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


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


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.


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


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;


Control Flow Graph

1 2 3

5

7

9 10 11 12 13 14

15

17

1819

T F

Notes


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


Control Flow Graph

1 2 3

5

7

9 10 11 12 13 14

15

17

1819

T F


Control Flow Graph T F

5

15

18

1 2 3

5

7

9 10 11 12 13 14

15

17

1819

Notes



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



1 11 12

19

5

15

18

2

5

7

17

18

3

7

9

7

10

5

13

5 7



1

11 12

19

5

15

18

2

5

7

17

18

7 9

7

10

5

13

5 7

Notes


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;


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)


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


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


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


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


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?


Screen Scraping Example


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


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


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?


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


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


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


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


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.


Semi-Decomposable IS Arch.

User interfaces

Applications and Database service



Databases


System interfaces

Notes


Semi-Decomposable IS Arch.

Interfaces and Application Logic

Databases


Database service


Non-Decomposable IS Arch.

Databases

Interfaces, applications and database service



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


Gateways

The principal means of implementing this hybrid IS is through the use of components called gateways

Legacy IS

Target IS



Legacy UI

BalanceNew AccDelete

Target UI

Gateway


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


Types of Gateway

Two basic types of gatewayForward gatewaysReverse gateways

Legacy application modules

Target DB

Forward gateway

Legacy DBTarget

application modules

Reverse gateway

Notes


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


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


Incremental Migration Example

CustDB

File handlingroutines

BatchCustomer

Entry

CustomerMgt

CustomerService UI

MarketingUI

SourceArchitecture CustDB

RDBMS

BatchCust Entry

CustomerMgt

ListMgt

CustomerService UI

MarketingUI

TargetArchitecture

Notes


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


Forward Migration: Step 1

CustomerMgt

CustomerService UI

MarketingUI

BatchCustomer

Entry

CustDB

RDBMS



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




CustomerMgt

CustomerService UI

MarketingUI

CustDB

RDBMS

BatchCustomer

Entry

ListMgt




CustomerMgt

CustomerService UI

MarketingUI

CustDB

RDBMS

BatchCustomer

Entry

ListMgt




CustomerMgt

CustomerService UI

MarketingUI

CustDB

RDBMS

BatchCustomer

Entry

ListMgt

Notes



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


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


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


Reverse Migration: Step 1

CustDB


BatchCustomer

Entry

CustomerMgt

CustomerService UI

MarketingUI

First, migrate application interfacesInstall reversegateways to translate requests for legacy components



BatchCustomer

Entry

ListMgt

MarketingUI

Next, incrementally migrate downwards, installing more reverse gateways as required

CustDB


CustomerService UI

CustomerMgt



BatchCustomer

Entry

ListMgt

MarketingUI


CustDB


CustomerService UI

CustomerMgt

Notes



BatchCustomer

Entry

ListMgt

MarketingUI


CustDB


CustomerService UI

CustomerMgt



BatchCust Entry

ListMgt

MarketingUI

CustDB


CustomerService UI

CustomerMgt




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


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. ……………………………………………………………………………………

……………………………………………………………………………………

…………………………………………………………………………………………

…………………………………………………………………………………………

…………………………………………………………………………………………

…………………………………………………………………………………………

…………………………………………………………………………………………

…………………………………………………………………………………………


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


Example Architecture

BatchCustomer

Entry

MarketingUI

CustomerService UI

ListMgt

CustomerMgt

CustDBCustDB

RDBMSFile handlingroutines


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


The Bottom Line

As a member of maintenance staff, your primary responsibility is to:

KEEP THE BUSINESSUP AND RUNNING


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.

comp3033 workbook iii - studentnet.cs.manchester.ac.uk

Documents