Software Re-Engineering in Software Engineering SE28

7,745 views

Published on

Published in: Technology, Business
1 Comment
4 Likes
Statistics
Notes
  • As a management instructor I appreciate viewing the function of others. This is probably the greatest demonstration on planning I've viewed.
    Sharika
    http://winkhealth.com http://financewink.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
7,745
On SlideShare
0
From Embeds
0
Number of Embeds
85
Actions
Shares
0
Downloads
278
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Software Re-Engineering in Software Engineering SE28

  1. 1. Software re-engineering <ul><li>Reorganising and modifying existing software systems to make them more maintainable </li></ul>
  2. 2. Objectives <ul><li>To explain why software re-engineering is a cost-effective option for system evolution </li></ul><ul><li>To describe the activities involved in the software re-engineering process </li></ul><ul><li>To distinguish between software and data re-engineering and to explain the problems of data re-engineering </li></ul>
  3. 3. Topics covered <ul><li>Source code translation </li></ul><ul><li>Reverse engineering </li></ul><ul><li>Program structure improvement </li></ul><ul><li>Program modularisation </li></ul><ul><li>Data re-engineering </li></ul>
  4. 4. <ul><li>Re-structuring or re-writing part or all of a legacy system without changing its functionality </li></ul><ul><li>Applicable where some but not all sub-systems of a larger system require frequent maintenance </li></ul><ul><li>Re-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented </li></ul>System re-engineering
  5. 5. <ul><li>When system changes are mostly confined to part of the system then re-engineer that part </li></ul><ul><li>When hardware or software support becomes obsolete </li></ul><ul><li>When tools to support re-structuring are available </li></ul>When to re-engineer
  6. 6. Re-engineering advantages <ul><li>Reduced risk </li></ul><ul><ul><li>There is a high risk in new software development. There may be development problems, staffing problems and specification problems </li></ul></ul><ul><li>Reduced cost </li></ul><ul><ul><li>The cost of re-engineering is often significantly less than the costs of developing new software </li></ul></ul>
  7. 7. Business process re-engineering <ul><li>Concerned with re-designing business processes to make them more responsive and more efficient </li></ul><ul><li>Often reliant on the introduction of new computer systems to support the revised processes </li></ul><ul><li>May force software re-engineering as the legacy systems are designed to support existing processes </li></ul>
  8. 8. Forward engineering and re-engineering
  9. 9. The re-engineering process
  10. 10. Re-engineering cost factors <ul><li>The quality of the software to be re-engineered </li></ul><ul><li>The tool support available for re-engineering </li></ul><ul><li>The extent of the data conversion which is required </li></ul><ul><li>The availability of expert staff for re-engineering </li></ul>
  11. 11. Re-engineering approaches
  12. 12. Source code translation <ul><li>Involves converting the code from one language (or language version) to another e.g. FORTRAN to C </li></ul><ul><li>May be necessary because of: </li></ul><ul><ul><li>Hardware platform update </li></ul></ul><ul><ul><li>Staff skill shortages </li></ul></ul><ul><ul><li>Organisational policy changes </li></ul></ul><ul><li>Only realistic if an automatic translator is available </li></ul>
  13. 13. The program translation process
  14. 14. Reverse engineering <ul><li>Analysing software with a view to understanding its design and specification </li></ul><ul><li>May be part of a re-engineering process but may also be used to re-specify a system for re-implementation </li></ul><ul><li>Builds a program data base and generates information from this </li></ul><ul><li>Program understanding tools (browsers, cross-reference generators, etc.) may be used in this process </li></ul>
  15. 15. The reverse engineering process
  16. 16. Reverse engineering <ul><li>Reverse engineering often precedes re-engineering but is sometimes worthwhile in its own right </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>The design and specification may be reverse engineered to support program maintenance </li></ul></ul>
  17. 17. Program structure improvement <ul><li>Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand </li></ul><ul><li>The program may be automatically restructured to remove unconditional branches </li></ul><ul><li>Conditions may be simplified to make them more readable </li></ul>
  18. 18. Spaghetti logic
  19. 19. Structured control logic
  20. 20. 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)...
  21. 21. Automatic program restructuring
  22. 22. Restructuring problems <ul><li>Problems with re-structuring are: </li></ul><ul><ul><li>Loss of comments </li></ul></ul><ul><ul><li>Loss of documentation </li></ul></ul><ul><ul><li>Heavy computational demands </li></ul></ul><ul><li>Restructuring doesn’t help with poor modularisation where related components are dispersed throughout the code </li></ul><ul><li>The understandability of data-driven programs may not be improved by re-structuring </li></ul>
  23. 23. Program modularisation <ul><li>The process of re-organising a program so that related program parts are collected together in a single module </li></ul><ul><li>Usually a manual process that is carried out by program inspection and re-organisation </li></ul>
  24. 24. Module types <ul><li>Data abstractions </li></ul><ul><ul><li>Abstract data types where datastructures and associated operations are grouped </li></ul></ul><ul><li>Hardware modules </li></ul><ul><ul><li>All functions required to interface with a hardware unit </li></ul></ul><ul><li>Functional modules </li></ul><ul><ul><li>Modules containing functions that carry out closely related tasks </li></ul></ul><ul><li>Process support modules </li></ul><ul><ul><li>Modules where the functions support a business process or process fragment </li></ul></ul>
  25. 25. Recovering data abstractions <ul><li>Many legacy systems use shared tables and global data to save memory space </li></ul><ul><li>Causes problems because changes have a wide impact in the system </li></ul><ul><li>Shared global data may be converted to objects or ADTs </li></ul><ul><ul><li>Analyse common data areas to identify logical abstractions </li></ul></ul><ul><ul><li>Create an ADT or object for these abstractions </li></ul></ul><ul><ul><li>Use a browser to find all data references and replace with reference to the data abstraction </li></ul></ul>
  26. 26. Data abstraction recovery <ul><li>Analyse common data areas to identify logical abstractions </li></ul><ul><li>Create an abstract data type or object class for each of these abstractions </li></ul><ul><li>Provide functions to access and update each field of the data abstraction </li></ul><ul><li>Use a program browser to find calls to these data abstractions and replace these with the new defined functions </li></ul>
  27. 27. Data re-engineering <ul><li>Involves analysing and reorganising the data structures (and sometimes the data values) in a program </li></ul><ul><li>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 </li></ul><ul><li>Objective is to create a managed data environment </li></ul>
  28. 28. Approaches to data re-engineering
  29. 29. Data problems <ul><li>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 </li></ul><ul><li>Systems may have to process much more data than was originally intended by their designers </li></ul><ul><li>Redundant data may be stored in different formats in different places in the system </li></ul>
  30. 30. Data migration
  31. 31. Data problems <ul><li>Data naming problems </li></ul><ul><ul><li>Names may be hard to understand. The same data may have different names in different programs </li></ul></ul><ul><li>Field length problems </li></ul><ul><ul><li>The same item may be assigned different lengths in different programs </li></ul></ul><ul><li>Record organisation problems </li></ul><ul><ul><li>Records representing the same entity may be organised differently in different programs </li></ul></ul><ul><li>Hard-coded literals </li></ul><ul><li>No data dictionary </li></ul>
  32. 32. Data value inconsistencies
  33. 33. Data conversion <ul><li>Data re-engineering may involve changing the data structure organisation without changing the data values </li></ul><ul><li>Data value conversion is very expensive. Special-purpose programs have to be written to carry out the conversion </li></ul>
  34. 34. The data re-engineering process
  35. 35. Key points <ul><li>The objective of re-engineering is to improve the system structure to make it easier to understand and maintain </li></ul><ul><li>The re-engineering process involves source code translation, reverse engineering, program structure improvement, program modularisation and data re-engineering </li></ul><ul><li>Source code translation is the automatic conversion of of program in one language to another </li></ul>
  36. 36. Key points <ul><li>Reverse engineering is the process of deriving the system design and specification from its source code </li></ul><ul><li>Program structure improvement replaces unstructured control constructs with while loops and simple conditionals </li></ul><ul><li>Program modularisation involves reorganisation to group related items </li></ul><ul><li>Data re-engineering may be necessary because of inconsistent data management </li></ul>

×