Bse 3105 lecture 4-software re-engineering
Download as PPT, PDF2 likes1,059 views
The document discusses software re-engineering and describes: 1) What software re-engineering is, including restructuring software to facilitate future changes without adding new functionality. 2) The advantages of re-engineering over new development, including reduced risk and cost. 3) When re-engineering should be done, such as when changes are confined to part of a system or hardware/software becomes obsolete.
Bse 3105 lecture 4-software re-engineering
- 1. BIT 3105-LECTURE 4 Software Re-engineering Ref: Somerville 6th Ed Chapter 28 1
- 2. So what is S/W Re-engineering? • We have so far seen that s/w re-engineering is the process of restructuring and reorganizing the software to facilitate future changes without adding new functionality. • It is applicable where some but not all sub-systems of a larger system require frequent maintenance • Re-engineering systems involves adding effort to make them easier to maintain. The system may be re-structured and re-documented 2
- 3. Advantages of S/w Re-engineering • S/w re-engineering has two advantages over more radical approaches to systems evolution – Reduced risk. There is a high risk in new software development. There may be development problems, staffing problems and specification problems. Planning is difficult and delays are expensive – Reduced cost. The cost of reengineering is often significantly less than the costs of developing new software. 3
- 4. When Should Re-engineering be Done? • 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 4
- 5. S/W Re-engineering Vs Conventional Development • Conventional development starts with requirements, and proceeds through the other usual phases. • In re-engineering the old system acts as a specification for the new system. 5
- 6. Factors affecting s/w re-engineering costs? • The cost of re-engineering a s/w can be affected by; – The quality of the software to be re-engineered – The tool support available for re-engineering – The extent of data conversion required – The availability of expert staff • This can be a problem with old systems based on technology that is no longer widely used 6
- 7. So what is involved in S/W Re-engineering? • S/w re-engineering may involve the following; – Source code translation • Converting the code to a new language – Reverse engineering • Analyzing the program to understand it – Program structure improvement • Restructuring the program automatically for understandability – Program modularization • Re-organizing the program structure – Data re-engineering • Cleanup and restructure the system data Note: We cover these in detail in the next slides 7
- 8. The S/w Re-engineering Process Reverse engineering Program documentation Data Original data reengineering Program structure improvement Program modularisation Structured program Reengineered data Modularised Original program program Source code translation 8
- 9. 1. 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 9
- 10. The Program Translation Process 10 Automatically translatecode Design translator instructions Identify source codedifferences Manually translatecode Systemto be re-engineered Systemto be re-engineered Re-engineered system
- 11. 2. Reverse engineering • This involves analysing a software in order to understand its design and specification • It may be part of a re-engineering process but may also be used to re-specify a system for re-implementation • It builds a program database and generates information from this database • Program understanding tools (like browsers, cross-reference generators, etc.) may be used in this process • Reverse engineering often precedes re-engineering but is sometimes worthwhile in its own right – The design and specification of a system may be reverse engineered so that they can be an input to the requirements specification process for the system’s replacement – The design and specification may be reverse engineered to support program maintenance 11
- 12. The Reverse Engineering Process 12 Programstucture diagrams Datastucture diagrams Traceability matrices Document generation System information store Automated analysis Manual annotation Systemtobe re-engineered Note: A traceability matrix is a document, usually in the form of a table, that correlates any two base-lined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.
- 13. 3. 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 • See example on next slide 13
- 14. Example: Code Simplification • Suppose during maintenance, a certain condition was changed to this one below; if not (A > B and (C < D or not ( E > F) ) )... • During program structure improvement, the above complex condition could be simplified as shown below; if (A <= B and (C>= D or E > F))... 14
- 15. Automatic Program Restructuring 15 Graph representation Program generator Restructured program Analyserand graphbuilder Programtobe restructured
- 16. Problems with Program Structure Improvement • 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 16
- 17. 4. Program Modularization • This is 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 • To modularize a program, you have to identify relationships between components and work out what these components do. Browsing and visualization tools help but it is impossible to automate this process completely. 17
- 18. Module Types • Data abstractions – Abstract data types where data structures and associated operations are grouped • Hardware modules – All functions required to interface with a hardware unit. They are closely related to data abstractions and collect together all of the functions which are used to control a particular hardware device. • 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 • Read pages 632-633 of Somerville 6th Edition for more on this. 18
- 19. 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. It will often be the case that several abstractions are combined in a single shared data area. – Create an ADT or object for these abstractions. If the programming language does not have data hiding facilities, simulate an abstract data type by providing functions to update and access all fields of the data. – Use a program browsing system or a cross-reference generator to find all references to data. Replace these with calls to the appropriate functions. 19
- 20. Data Abstraction Recovery • Analyse common data areas to identify logical abstractions • Create an abstract data type or object class for each of these abstractions. That ADT will help to represent a collection of those common data areas. • 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 20
- 21. 5. Data Re-engineering • This 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 • Data re-engineering may not be necessary if the functionality of the system is unchanged • The objective is to create a managed data environment • Read pages 634-638 of Somerville 6th Edition for more on data re-engineering. 21
- 23. 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 23
- 24. Example of re-organizing data 24 Program2 Program3 File1 File2 File3 File4 File5 File6 Program4 Program5 Program6 Program7 Database management system Logicaland physical datamodels describes Program1 Program3 Program4 Program5 Program6 Program2 Program7 Program1 Becomes
- 25. Examples of 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 25
- 26. Data Conversion • Data re-engineering may involve changing the data structure organisation without changing the data values • Data value conversion is very expensive. Special-purpose programs have to be written to carry out the conversion 26
- 27. The Data Re-engineering Process 27 Entityname modification Literal replacement Datadefinition re-ordering Data re-formatting Defaultvalue conversion Validationrule modification Data analysis Data analysis Data conversion Modified data Programtobere-engineered Stage1 Stage2 Stage3 Changesummarytables
- 28. Summary • The objective of re-engineering is to improve the system structure to make it easier to understand and maintain • The re-engineering process involves source code translation, reverse engineering, program structure improvement, program modularisation and data re-engineering • Source code translation is the automatic conversion of program in one language to another 28
- 29. Summary- Cont’d • Reverse engineering is the process of deriving the system design and specification from its source code • Program structure improvement replaces unstructured control constructs with while loops and simple conditionals • Program modularisation involves reorganisation to group related items • Data re-engineering may be necessary because of inconsistent data management 29