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]
35
Embed
COMP3033 Workbook III - studentnet.cs.manchester.ac.uk
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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.
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)
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
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
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)
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)
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
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
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)
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
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;
GOTOs can be removed from programs by:Introducing new (control) variablesReplicating code/splitting nodesIntroducing new procedures/procedure callsSimplifying conditional statements
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)
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
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
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
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?
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
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
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
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.
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
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
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
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)
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.