1. Software Re-Engineering
COSC 6431
V. Tzerpos

2. 1/2/2019
Legacy Systems
Older software systems that remain vital to an organization
2-Jan-19
COSC6431

3. Legacy Systems
Software systems that are developed specially for an organization 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 essential for the normal functioning of the business.
2-Jan-19
COSC6431

4. Legacy System Replacement
There is a business risk in scrapping a legacy system and replacing it with a modern system:
Legacy systems rarely have a complete specification.
Business processes rely 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.
2-Jan-19
COSC6431

5. Lehman’s Second Law
“The entropy of a software system increases with time unless specific work is executed to maintain or reduce it”
Lehman’s Law of Continuing Growth: “The functional capability of most software systems must be continually increased to maintain user satisfaction over the system lifetime”
2-Jan-19
COSC6431

6. Legacy System Change Systems must change in order to remain useful.
Changing legacy systems is often expensive:
Different parts of the system are implemented by different teams.
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.
2-Jan-19
COSC6431

7. The Legacy Dilemma
It is expensive and risky to replace the legacy system.
It is expensive to maintain the legacy system.
Businesses may choose to extend the system lifetime using techniques such as reverse engineering.
2-Jan-19
COSC6431

8. Example of a Legacy Application System
2-Jan-19
COSC6431

9. After Re-engineering … Database-centred System
2-Jan-19
COSC6431

10. Legacy System Design
Most legacy systems were designed before object-oriented development was used.
Rather than being organized as a set of interacting objects, these systems have been designed using a function-oriented design strategy.
2-Jan-19
COSC6431

11. Legacy System Assessment
Organizations that rely on legacy systems must choose a strategy for evolving these systems:
Replace the old system with a new one.
Continue maintaining the system.
Transform the system by re-engineering to improve its maintainability.
The strategy chosen should depend on the system quality and its business value.
2-Jan-19
COSC6431

12. Legacy System Categories
Low quality, low business value
These systems should be scrapped
Low-quality, high-business value
Should be re-engineered or replaced.
High-quality, low-business value
Replace, scrap, or maintain.
High-quality, high business value
Continue in operation using normal system maintenance.
2-Jan-19
COSC6431

13. Cost/Benefit factors for RE
Current annual maintenance cost
Current annual operation cost
Current annual business value
Predicted annual maintenance cost after RE
Predicted annual operation cost after RE
Predicted annual business value after RE
Estimated re-engineering costs
Estimated re-engineering time
Expected life of the system
2-Jan-19
COSC6431

14. Software Maintenance Managing the processes of system change 2-Jan-19
1/2/2019
Software Maintenance
Managing the processes of system change
2-Jan-19
COSC6431

15. Maintenance is Inevitable
1/2/2019
Maintenance is Inevitable
The system requirements are likely to change while the system is being developed because the environment is changing.
When a system is installed in an environment it changes that environment and therefore changes the system requirements.
2-Jan-19
COSC6431

16. Types of Maintenance Perfective maintenance Adaptive maintenance
1/2/2019
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.
2-Jan-19
COSC6431

17. Distribution of Maintenance Effort
1/2/2019
Distribution of Maintenance Effort
2-Jan-19
COSC6431

18. 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.
2-Jan-19
COSC6431

19. 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.
2-Jan-19
COSC6431

20. System Documentation Requirements document
System architecture description
Program design documentation
Source code listings
Test plans and validation reports
System maintenance guide
2-Jan-19
COSC6431

21. 1/2/2019
Maintenance Costs
Usually greater than development costs (2* to 100* depending on the application).
Affected by both technical and non-technical factors.
Maintenance corrupts the software structure so makes further maintenance more difficult.
Aging software can have high support costs (e.g., old languages, compilers etc.)
2-Jan-19
COSC6431

22. Maintenance Cost Factors
1/2/2019
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.
2-Jan-19
COSC6431

23. Maintenance Cost Factors
1/2/2019
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.
2-Jan-19
COSC6431

24. 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.
2-Jan-19
COSC6431

25. Maintenance Measurements
1/2/2019
Maintenance Measurements
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.
2-Jan-19
COSC6431

26. Maintenance Measurements
1/2/2019
Maintenance Measurements
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.
2-Jan-19
COSC6431

27. Process Measurements Number of requests for corrective maintenance.
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.
2-Jan-19
COSC6431

28. Software Re-engineering
Reorganizing and modifying existing software systems to make them more maintainable.
2-Jan-19
COSC6431

29. 1/2/2019
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.
2-Jan-19
COSC6431

30. Re-engineering Advantages
Reduced risk
There is a high risk in new software development.
Reduced cost
The cost of re-engineering is often significantly less than the costs of developing new software.
2-Jan-19
COSC6431

31. 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.
2-Jan-19
COSC6431

32. Possible Re-Engineering activities
Source code translation
Reverse engineering
Program structure improvement
Program modularization
Data re-engineering
2-Jan-19
COSC6431

33. 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
Organizational policy changes
Only realistic if an automatic translator is available.
2-Jan-19
COSC6431

34. Reverse Engineering
Reverse Engineering is the process of determining how a system works by analyzing its internal constituents and/or its external behavior.
In the software world one would say that reverse engineering is trying to figure out how a system works by:
Inspecting the source code and documentation (if it exists)
Exercising the executable programs and observing their behavior.
2-Jan-19
COSC6431

35. The Reverse Engineering Process
2-Jan-19
COSC6431

36. Reverse Engineering
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.
2-Jan-19
COSC6431

37. Why is Reverse Engineering Important/Necessary?
Most software that is developed is not “from scratch”.
Understanding someone else’s source code, specifications, designs, is difficult.
Why is this so?
What makes software more difficult to understand than a toaster or a car?
2-Jan-19
COSC6431

38. Software Maintenance Problem
A company hires a bright software developer to maintain a system.
The project manager points the developer to a source code directory and says “become an expert in the system as soon as possible”.
The IBM Tobey back-end compiler project allowed for a 1 year learning curve (but this is quite rare).
2-Jan-19
COSC6431

39. Program Structure Improvement
Maintenance tends to corrupt the structure of a program. It becomes harder to understand.
The program may be automatically restructured to remove unconditional branches.
Conditions may be simplified to make them more readable.
2-Jan-19
COSC6431

40. Program Modularization
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-organization.
2-Jan-19
COSC6431

41. Recovering Data Abstractions
Many legacy systems use shared tables and global data to save memory space.
This causes problems because changes have a wide impact in the system.
Shared global data may be converted to objects:
Analyse common data areas to identify logical abstractions.
Create an object for these abstractions.
Find all data references and replace them with reference to the data abstraction.
2-Jan-19
COSC6431

42. Data Re-engineering
Involves analyzing and reorganizing 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.
2-Jan-19
COSC6431

43. Data Problems Data naming problems Field length 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.
Hard-coded literals
2-Jan-19
COSC6431

44. Reverse Engineering Research
The focus has been primarily on the development of tools to help software developers understand software quicker and with less effort.
Not much work has been done on RE methods, however.
2-Jan-19
COSC6431

45. Sherlock Holmes Analogy
“We have developed good detective tools (e.g., magnifying glasses, fingerprint matchers, etc) but we have little insight on how to train someone to be a good detective (e.g., guidelines, processes, etc)” S. Mancoridis
2-Jan-19
COSC6431

46. Progress Has Been Made In …
Source code analysis
Program tracing and profiling
Automatic modularization (software clustering)
But still a research area in its infancy …
2-Jan-19
COSC6431

47. Lecture schedule Sep 10: Introduction, administrivia Sep 17: No class
Sep 24: Static and dynamic analysis, program representation, etc.
Oct 01: Refactoring
Oct 08: Software clustering
Oct 15: Evaluation of clustering techniques
2-Jan-19
COSC6431

48. Lecture schedule Oct 22: Software evolution
Oct 29: Design Pattern Detection
Nov 05: Re-Engineering Patterns
Nov 12: No class (WCRE)
Nov 19: Special topics (e.g. data reverse engineering, binary reverse engineering, visualization)
Nov 21: Research paper presentations
Nov 28: Project presentations
2-Jan-19
COSC6431

49. Grading 10% - Participation (paper discussion) 20% - Assignment
20% - Research paper presentation
25% - Project report
25% - Project presentation
2-Jan-19
COSC6431

50. Workload September: 1 paper a week
October: Assignment + 1 paper a week
November: 1 paper to present + project
2-Jan-19
COSC6431