Legacy Systems. Older software systems that remain vital to an organisation. Legacy systems. Legacy system replacement

Transcription

1 Legacy Systems Older software systems that remain vital to an organisation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 1 Legacy systems Software systems that are developed specially for an organisation have a long lifetime Many software systems that are still in use were developed many years ago using technologies that are now obsolete These systems are still business critical that is, they are essential for the normal functioning of the business They have been given the name legacy systems Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 2 Legacy system replacement There is a significant business risk in simply scrapping a legacy system and replacing it with a system that has been developed using modern technology Legacy systems rarely have a complete specification. During their lifetime they have undergone major changes which may not have been documented Business processes are reliant on the legacy system The system may embed business rules that are not formally documented elsewhere New software development is risky and may not be successful Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 3

2 Legacy system change Systems must change in order to remain useful However, changing legacy systems is often expensive Different parts implemented by different teams so no consistent programming style The system may use an obsolete programming language The system documentation is often out-of-date The system structure may be corrupted by many years of maintenance Techniques to save space or increase speed at the expense of understandability may have been used File structures used may be incompatible Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 4 The legacy dilemma It is expensive and risky to replace the legacy system It is expensive to maintain the legacy system Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re-engineering. This is covered in Chapters 27 and 28 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 5 Legacy system structures Legacy systems can be considered to be sociotechnical systems and not simply software systems System hardware - may be mainframe hardware Support software - operating systems and utilities Application software - several different programs Application data - data used by these programs that is often critical business information Business processes - the processes that support a business objective and which rely on the legacy software and hardware Business policies and rules - constraints on business operations Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 6

3 Legacy system components Support software Uses Application software Embeds knowledge of Business policies and rules Runs-on Runs-on Uses Uses Constrains System hardware Application data Business processes Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 7 Layered model Socio-technical system Business processes Application software Support software Hardware Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 8 System change In principle, it should be possible to replace a layer in the system leaving the other layers unchanged In practice, this is usually impossible Changing one layer introduces new facilities and higher level layers must then change to make use of these Changing the software may slow it down so hardware changes are then required It is often impossible to maintain hardware interfaces because of the wide gap between mainframes and client-server systems Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 9

4 Legacy application system Program 1 Program 2 Program 3 File 1 File 2 File 3 File 4 File 5 File 6 Program 4 Program 5 Program 6 Program 7 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 10 Database-centred system Program 1 Program 2 Program 3 Program 4 Database management system describes Logical and physical data models Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 11 Transaction processing Account queries and updates Teleprocessing monitor Serialised transactions Accounts database ATMs and terminals Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 12

5 Legacy data The system may be file-based with incompatible files. The change required may be to move to a database-management system In legacy systems that use a DBMS the database management system may be obsolete and incompatible with other DBMSs used by the business The teleprocessing monitor may be designed for a particular DB and mainframe. Changing to a new DB may require a new TP monitor Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 13 Legacy system design Most legacy systems were designed before object-oriented development was used Rather than being organised as a set of interacting objects, these systems have been designed using a function-oriented design strategy Several methods and CASE tools are available to support function-oriented design and the approach is still used for many business applications Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 14 Legacy system assessment Organisations that rely on legacy systems must choose a strategy for evolving these systems Scrap the system completely and modify business processes so that it is no longer required Continue maintaining the system Transform the system by re-engineering to improve its maintainability Replace the system with a new system The strategy chosen should depend on the system quality and its business value Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 15

6 System quality and business value Business value 9 High business value Low quality 10 Low business value Low quality High business value High quality Low business value High quality System quality Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 16 Legacy system categories Low quality, low business value These systems should be scrapped Low-quality, high-business value These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available High-quality, low-business value Replace with COTS, scrap completely or maintain High-quality, high business value Continue in operation using normal system maintenance Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 17 Business value assessment Assessment should take different viewpoints into account System end-users Business customers Line managers IT managers Senior managers Interview different stakeholders and collate results Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 18

7 System quality assessment Business process assessment How well does the business process support the current goals of the business? Environment assessment How effective is the system s environment and how expensive is it to maintain Application assessment What is the quality of the application software system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 19 Business process assessment Use a viewpoint-oriented approach and seek answers from system stakeholders Is there a defined process model and is it followed? Do different parts of the organisation use different processes for the same function? How has the process been adapted? What are the relationships with other business processes and are these necessary? Is the process effectively supported by the legacy application software? Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 20 Environment assessment Factor Questions Supplier Is the supplier is still in existence? Is the supplier financially stable and stability likely to cont inue in existence? If the supplier is no longer in business, are the systems maintained by so meone else? Failure rate Does the hardware have a high rate of reported failures? Does the support software crash and force system restarts? Age How old is the hardware and software? The older the hardware and support software, the more obsolete it will be. It may still function correctly but th ere could b e significant economic and bu siness benefits to moving to more modern systems. Performance Is the performance of the system adequate? Do performance problems have a significant effect on system users? Support What local support is required by th e hardware and software? If there requirements are high costs associated with this support, it may be worth considering system replacement. Maintenance What are the costs of hardware maintenance and suppo rt software costs licences? Older hardware may have high er maintenance costs than modern systems. Support software may have h igh annual licensing costs. Interoperability Are there problems interfacing the system to other systems? Can compilers etc. be used with current versions of the op erating system? Is hardware emulation required? Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 21

8 Application assessment Factor Understandability Questions How difficult is it to unde rstand the source code of the current system? How complex are the cont rol structures which are used? Do variables have meaningful names that reflect their function? Documentation What system documentation is available? Is the documentation complete, consistent and up -to-date? Data Is there an explicit data model for the system? To what extent is data duplicated in different files? Is the data used by the system up-to-date and consistent? Performance Is the performance of the application adequate? Do performance problems have a significant effect on system users? Programming language Configuration management Test data Personnel skills Are modern compilers available for the programming language u sed to develop the system? Is the programming language still used for new system development? Are all versions of all parts of the system managed by a configuration management system? Is there an explicit description of the versions of components that are used in the current system? Does test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system? Are there people available who have the skills to maintain the application? Are there only a limited number of people who understand the system? Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 22 System measurement You may collect quantitative data to make an assessment of the quality of the application system The number of system change requests The number of different user interfaces used by the system The volume of data used by the system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 23 Software maintenance Managing the processes of system change Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 24

9 Software maintenance Modifying a program after it has been put into use Maintenance management is concerned with planning and predicting the process of change Configuration management is the management of products undergoing change. Covered in the following chapter Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 25 Maintenance is inevitable The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements! Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements. Systems MUST be maintained therefore if they are to remain useful in an environment Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 26 Types of maintenance Perfective maintenance Changing a system to make it meet its requirements more effectively Adaptive maintenance Changing a system to meet new requirements Corrective maintenance Changing a system to correct deficiencies in the way meets its requirements Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 27

10 Distribution of maintenance effort Corrective maintenance (17%) Adaptive maintenance (18%) Perfective maintenance (65%) Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 28 Evolving systems It is usually more expensive to add functionality after a system has been developed rather than design this into the system Maintenance staff are often inexperienced and unfamiliar with the application domain Programs may be poorly structured and hard to understand Changes may introduce new faults as the complexity of the system makes impact assessment difficult The structure may be degraded due to continual change There may be no documentation available to describe the program Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 29 Maintenance management Maintenance has a poor image amongst development staff as it is not seen as challenging and creative Maintenance costs increase as the software is maintained The amount of software which has to be maintained increases with time Inadequate configuration management often means that the different representations of a system are out of step Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 30

11 Staff motivation Relate software development to organizational goals - maintenance rationale Relate rewards to organizational performance Integrate maintenance with development Create a discretionary preventative maintenance budget Plan for maintenance early in the development process Plan to expend effort on program maintainability Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 31 The maintenance process Maintenance is triggered by change requests from customers or marketing requirements Changes are normally batched and implemented in a new release of the system Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 32 The maintenance process Change requests Impact analysis System release planning Change implementation System release Perfective maintenance Adaptive maintenance Corrective maintenance Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 33

12 Change processes Change requests Analyze source code Modify source code Deliver repaired system Fault repair process Change requests Change analysis Requirements updating Software development Iterative development process Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 34 System documentation Requirements document System architecture description Program design documentation Source code listings Test plans and validation reports System maintenance guide Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 35 Document production Structure documents with overviews leading the reader into more detailed technical descriptions Produce good quality, readable manuals - they may have to last 20 years Use tool-generated documentation whenever possible Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 36

13 Program evolution dynamics Program evolution dynamics is the study of the processes of system change After major empirical study, Lehman and Belady proposed that there were a number of laws which applied to all systems as they evolved There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 37 Lehman s laws Law Description Continuing change A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment. Increasing complexity As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. Large program evolution Program evolution is a self-regulating process. System attributes such as size, time between releases and the number of reported errors are approximately invariant for each system release. Organisational stability Over a program s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development. Conservation of Over the lifetime of a system, the incremental change familiarity in each release is approximately constant. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 38 Maintenance costs Usually greater than development costs (2* to 100* depending on the application) Affected by both technical and non-technical factors Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.) Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 39

14 Development/maintenance costs System 1 System $ Development costs Maintenance costs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 40 Maintenance cost factors Module independence It should be possible to change one module without affecting others Programming language High-level language programs are easier to maintain Programming style Well-structured programs are easier to maintain Program validation and testing Well-validated programs tend to require fewer changes due to corrective maintenance Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 41 Maintenance cost factors Documentation Good documentation makes programs easier to understand Configuration management Good CM means that links between programs and their documentation are maintained Application domain Maintenance is easier in mature and well-understood application domains Staff stability Maintenance costs are reduced if the same staff are involved with them for some time Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 42

15 Maintenance cost factors Program age The older the program, the more expensive it is to maintain (usually) External environment If a program is dependent on its external environment, it may have to be changed to reflect environmental changes Hardware stability Programs designed for stable hardware will not require to change as the hardware changes Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 43 Maintenance metrics Measurements of program characteristics which would allow maintainability to be predicted Essentially technical, how can technical factors above be quantified Any software components whose measurements are out of line with other components may be excessively expensive to maintain. Perhaps perfective maintenance effort should be devoted to these components Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 44 Maintenance metrics Control complexity Can be measured by examining the conditional statements in the program Data complexity Complexity of data structures and component interfaces. Length of identifier names Longer names imply readability Program comments Perhaps more comments mean easier maintenance Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 45

16 Maintenance metrics Coupling How much use is made of other components or data structures Degree of user interaction The more user I/O, the more likely the component is to require change Speed and space requirements Require tricky programming, harder to maintain Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 46 Process metrics Number of requests for corrective maintenance Average time required for impact analysis Average time taken to implement a change request Number of outstanding change requests If any or all of these is increasing, this may indicate a decline in maintainability Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 47 Maintenance metrics Log maintenance effort on a per component basis Choose set of possible metrics which may be related to maintenance Assess possible metrics for each maintained components Look for correlation between maintenance effort and metric values Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 48

17 Software re-engineering Reorganising and modifying existing software systems to make them more maintainable Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 49 System re-engineering Re-structuring or re-writing part or all of a legacy system without changing its functionality Applicable where some but not all sub-systems of a larger system require frequent maintenance Re-engineering involves adding effort to make them easier to maintain. The system may be restructured and re-documented Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 50 When to re-engineer When system changes are mostly confined to part of the system then re-engineer that part When hardware or software support becomes obsolete When tools to support re-structuring are available Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 51

18 Re-engineering advantages Reduced risk There is a high risk in new software development. There may be development problems, staffing problems and specification problems Reduced cost The cost of re-engineering is often significantly less than the costs of developing new software Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 52 Business process re-engineering Concerned with re-designing business processes to make them more responsive and more efficient Often reliant on the introduction of new computer systems to support the revised processes May force software re-engineering as the legacy systems are designed to support existing processes Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 53 Forward engineering and re-engineering System specification Forward engineering Design and implementation New system Existing software system Software re-engineering Understanding and transformation Re-engineered system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 54

19 The re-engineering process Original program Program documentation Modularised program Original data Reverse engineering Source code translation Program modularisation Data reengineering Program structure improvement Structured program Reengineered data Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 55 Re-engineering cost factors The quality of the software to be re-engineered The tool support available for re-engineering The extent of the data conversion which is required The availability of expert staff for re-engineering Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 56 Re-engineering approaches Automated program restructuring Program and data restructuring Automated source code conversion Automated restructuring with manual changes Restructuring plus architectural changes Increased cost Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 57

20 Source code translation Involves converting the code from one language (or language version) to another e.g. FORTRAN to C May be necessary because of: Hardware platform update Staff skill shortages Organisational policy changes Only realistic if an automatic translator is available Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 58 The program translation process System to be re-engineered System to be re-engineered Re-engineered system Identify source code differences Design translator instructions Automatically translate code Manually translate code Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 59 Reverse engineering Analysing software with a view to understanding its design and specification May be part of a re-engineering process but may also be used to re-specify a system for re-implementation Builds a program data base and generates information from this Program understanding tools (browsers, cross-reference generators, etc.) may be used in this process Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 60

21 The reverse engineering process System to be re-engineered Automated analysis Manual annotation System information store Document generation Program stucture diagrams Data stucture diagrams Traceability matrices Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 61 Reverse engineering Reverse engineering often precedes reengineering 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 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 62 Program structure improvement Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand The program may be automatically restructured to remove unconditional branches Conditions may be simplified to make them more readable Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 63

22 Spaghetti logic Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch) if Switch = off goto off if Switch = on 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 Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 64 Structured control logic loop -- 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 then Switch-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 then Switch-heating; Heating-status = off; elsif Temp < Setting and Heating-status = off then Switch-heating; Heating-status := on ; end if; end if ; end case ; end loop ; Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 65 Condition simplification -- Complex condition if not (A > B and (C < D or not ( E > F) ) ) Simplified condition if (A <= B and (C>= D or E > F)... Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 66

23 Automatic program restructuring Program to be restructured Restructured program Analyser and graph builder Program generator Graph representation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 67 Restructuring problems Problems with re-structuring are: Loss of comments Loss of documentation Heavy computational demands Restructuring doesn t help with poor modularisation where related components are dispersed throughout the code The understandability of data-driven programs may not be improved by re-structuring Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 68 Program modularisation The process of re-organising a program so that related program parts are collected together in a single module Usually a manual process that is carried out by program inspection and re-organisation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 69

24 Module types Data abstractions Abstract data types where datastructures and associated operations are grouped Hardware modules All functions required to interface with a hardware unit Functional modules Modules containing functions that carry out closely related tasks Process support modules Modules where the functions support a business process or process fragment Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 70 Recovering data abstractions Many legacy systems use shared tables and global data to save memory space Causes problems because changes have a wide impact in the system Shared global data may be converted to objects or ADTs Analyse common data areas to identify logical abstractions Create an ADT or object for these abstractions Use a browser to find all data references and replace with reference to the data abstraction Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 71 Data abstraction recovery Analyse common data areas to identify logical abstractions Create an abstract data type or object class for each of these abstractions Provide functions to access and update each field of the data abstraction Use a program browser to find calls to these data abstractions and replace these with the new defined functions Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 72

25 Data re-engineering Involves analysing and reorganising the data structures (and sometimes the data values) in a program May be part of the process of migrating from a file-based system to a DBMS-based system or changing from one DBMS to another Objective is to create a managed data environment Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 73 Approaches to data re-engineering Approach Data cleanup Data extension Data migration Description The data records and values are analysed to improve their quality. Duplicates are removed, redundant information is deleted and a consistent format applied to all records. This should not normally require any associated program changes. In this case, the data and associated programs are re-engineered to remove limits on the data processing. This may require changes to programs to increase field lengths, modify upper limits on the tables, etc. The data itself may then have to be rewritten and cleaned up to reflect the program changes. In this case, data is moved into the control of a modern database management system. The data may be stored in separate files or may be managed by an older type of DBMS. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 74 Data problems End-users want data on their desktop machines rather than in a file system. They need to be able to download this data from a DBMS Systems may have to process much more data than was originally intended by their designers Redundant data may be stored in different formats in different places in the system Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 75

26 Program 1 Program 2 Program 3 File 1 File 2 File 3 File 4 File 5 File 6 Program 4 Program 5 Program 6 Program 7 Becomes Program 3 Program 4 Program 5 Program 6 Program 2 Program 7 Program 1 Database management system describes Logical and physical data models Data migration Data problems Data 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 literals No data dictionary Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 77 Data value inconsistencies Data inconsistency Inconsistent default values Inconsistent units Inconsistent validation rules Inconsistent representation semantics Inconsistent handling of negative values Description Different programs assign different default values to the same logical data items. This causes problems for programs other than those that created the data. The problem is compounded when missing values are assigned a default value that is valid. The missing data cannot then be discovered. The same information is represented in different units in different programs. For example, in the US or the UK, weight data may be represented in pounds in older programs but in kilograms in more recent systems. A major problem of this type has arisen in Europe with the introduction of a single European currency. Legacy systems have bee n written to deal with national currency units and data has to be converted to euros. Different programs apply different data validation rules. Data written by one program may be rejected by another. This is a particular problem for archival data which may not have been updated in line with changes to data validation rules. Programs assume some meaning in the way items are represented. For example, some programs may assume that upper-case text means an address. Programs may use different conventions and may therefore reject data which is semantically valid. Some programs reject negative values for entities which must always be positive. Others, however, may accept these as negative values or fail to recognise them as negative and convert them to a positive value. Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 78

27 Data conversion Data re-engineering may involve changing the data structure organisation without changing the data values Data value conversion is very expensive. Specialpurpose programs have to be written to carry out the conversion Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 79 The data re-engineering process Program to be re-engineered Data analysis Data analysis Entity name modification Literal replacement Data definition re-ordering Data re-formatting Default value conversion Validation rule modification Data conversion Stage 1 Stage 2 Stage 3 Change summary tables Modified data Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 80