Software Reengineering

1. Software Reengineering CIS 376 Bruce R. Maxim UM-Dearborn

2. System Reengineering • Restructuring or rewriting part or all of a system without changing its functionality • Applicable when some (but not all) subsystems of a larger system require frequent maintenance • Reengineering involves putting in the effort to make it easier to maintain • The reengineered system may also be restructured and should be redocumented

3. When do you decide to reengineer? • When system changes are confined to one subsystem, the subsystem needs to be reengineered • When hardware or software support becomes obsolete • When tools to support restructuring are readily available

4. Business Process Reengineering • Concerned with redesigning business processes to make them more responsive and more efficient • Often relies on the introduction of new computer systems to support the revised processes • May force software reengineering of legacy computer systems which designed to support existing processes

5. Business Process Reengineering Principles - part 1 • Organize around outcomes, not tasks. • Have the people who use the output of a process, perform the process. • Incorporate information processing work into the work that produces the raw information. • Treat geographically dispersed resources as though they were centralized.

6. Business Process Reengineering Principles - part 2 • Link parallel activities instead of integrating their results. • Put the decision point where the work is performed and build control into the process. • Capture the data once, at its source.

7. Business Process Reengineering Model - part 1 • Business redefinition • business goals identified in the context of key drivers • cost reduction • time reduction • quality improvement • empowerment • Process identification • processes critical to achieving business goals are identified and prioritized

8. Business Process Reengineering Model - part 2 • Process evaluation • existing processes are analyzed and measured • process costs and time are noted • quality/performance problems are isolated • Process specification and design • use-cases are prepared for each process to be redesigned (these use-case scenarios deliver some outcome to a customer) • new tasks are designed for each process

9. Business Process Reengineering Model - part 3 • Prototyping • used to test processes before integrating them into the business • Refinement and instantiation • based on feedback from the prototype, business processes are refined • refined processes then instantiated within a business system

10. Reengineering Processfrom Sommerville

11. Software Reengineering Process Model - part 1 • Inventory analysis • sorting active software applications by business criticality, longevity, current maintainability, and other local criteria • helps to identify reengineering candidates • Document restructuring options • live with weak documentation • update poor documents if they are used • fully rewrite the documentation for critical systems focusing on the "essential minimum"

12. Software Reengineering Process Model - part 2 • Reverse engineering • process of design recovery • analyzing a program in an effort to create a representation of the program at some abstraction level higher than source code • Code restructuring • source code is analyzed and violations of structured programming practices are noted and repaired • revised code needs to be reviewed and tested

13. Software Reengineering Process Model - part 3 • Data restructuring • usually requires full reverse engineering • current data architecture is dissected • data models are defined • existing data structures are reviewed for quality • Forward engineering • sometimes called reclamation or renovation • recovers design information from existing source code • uses this design information to reconstitute the existing system to improve its overall quality or performance

14. Forward Engineering and Reengineeringfrom Sommerville

15. Reverse Engineering • Analyzing software with a view to understanding its design and specification • May be part of the reengineering process • May be used to specify a system for prior to reimplementation • Program understanding tools may be useful (browsers, cross-reference generators, etc.)

16. Reverse Engineering Conceptspart 1 • Abstraction level • ideally want to be able to derive design information at the highest level possible • Completeness • level of detail provided at a given abstraction level • Interactivity • degree to which humans are integrated with automated reverse engineering tools

17. Reverse Engineering Conceptspart 2 • Directionality • one-way means the software engineer doing the maintenance activity is given all information extracted from source code • two-way means the information is fed to a reengineering tool that attempts to regenerate the old program • Extract abstractions • meaningful specification of processing performed is derived from old source code

18. Reverse Engineering Processfrom Sommerville

19. Reverse Engineering Activitiespart 1 • Understanding process • source code is analyzed to at varying levels of detail • system • program • component • pattern • statement • to understand procedural abstractions and overall functionality

20. Reverse Engineering Activitiespart 2 • Understanding data • internal data structures • database structure • User interfaces • what are the basic actions (e.g. key strokes or mouse operations) processed by the interface? • what is a compact description of the system's behavioral response to these actions? • what concept of equivalence of interfaces is relevant?

21. Reverse Engineering Applicability • Reverse engineering often precedes reengineering • Sometimes reverse engineering is preferred • if the specification and design of a system needs to be defined prior using them as input to the requirements specification process for a replacement systems • if the design and specification for a system is needed to support program maintenance activities

22. Data Abstraction Recovery • Many legacy systems make use of shared tables and global data structures to save space • Results in tightly coupled systems that are very hard to change • Shared data structures need to be transformed to objects or ADT’s

23. Creating ADT’s and Objects • Analyze the data common areas to identify logical abstractions • Create ADT’s or Objects for each abstraction • Provide functions or methods to update each field in the data abstraction • Use a program browser to find all references to these data structures and replace them with the new function or method calls

24. Sommerville’sRestructuring Approaches

25. Restructuring Benefits • Improved program and documentation quality • Makes programs easier to learn • improves productivity • reduces developer frustration • Reduces effort required to maintain software • Software is easier to test and debug

26. Types of Restructuring - part 1 • Code restructuring • program logic modeled using Boolean algebra and series of transformation rules are applied to yield restructured logic • create resource exchange diagram showing • data types • procedures • variables shared between modules • restructure program architecture to minimize module coupling

27. Types of Restructuring - part 2 • Data restructuring • analysis of source code • data redesign • data record standardization • data name rationalization • file or database translation

28. Automatic Program Restructuring from Sommerville

29. Automatic Restructuring Problems • Loss of source code comments • Loss of documentation • Heavy computational demands • Will not help with poor modularization problems (e.g. related components widely dispersed throughout the source code) • The understandability of data driven programs may not be improved by restructuring

30. Source Code Translation • Involves converting the code from one language (or language version) to another • May be necessary because of • hardware platform updates • staff skill shortages • organizational policy changes • May only be realistic (e.g. cost and time effective) if an automatic translator is available • Manual fine tuning of new code is always required

31. Program Translation Processfrom Sommerville

32. Data Reengineering • Involves analyzing and reorganizing data structures or data values used in a program • Might be part of the process of migrating from a file-based system to a DBMS or changing from one DBMS to another DBMS • The goal to create an environment where is managed not just used

33. Data Rengineering Approaches - part 1 • Data cleanup • data records and values are analyzed to improve quality • duplicates removed • redundant information is deleted • consistent format applied to all records • normally does not require and program changes

34. Data Reengineering Approaches - part 2 • Data extension • data and programs are reengineered to remove data processing limits (e.g. size or field widths) • data itself may need to rewritten to reflect program changes • Data migration • data is moved to modern DBMS • data might be stored in separate files or an older DBMS

35. Data Problems • Data naming problems • names be hard to understand • heavy use of aliasing by programmers • Field length problems • different field lengths used for same data item in different programs • Record organization problems • different field orderings used by different programs • Hard-coded literals • No data dictionary

36. Data Value Inconsistencies • Inconsistent default values used in different programs (e.g. especially missing data codes) • Inconsistent units used for same quantity (e.g. miles in one program kilometers in another) • Inconsistent validation rules (e.g. different standards used to reject values as bad) • Inconsistent representation semantics (e.g. multiple ways of using uppercase to convey meaning in text strings) • Inconsistent handling of negative numbers (e.g. data validation and representation issues)

37. Data Reengineering Processfrom Sommerville

38. Forward Engineering Client/Server Architectures • application functionality migrates to each client computer • new GUI interfaces implemented at client sites • database functions allocated to servers • specialized functionality may remain at server site • new communications, security, archiving, and control requirements must be established at both client and server sites

39. Forward Engineering Object-Oriented Architectures - part 1 • existing software is reverse engineered so that appropriate data, functional, and behavioral models can be created • use-cases are created if reengineered system extends functionality of application • data models created during reverse engineering are used with CRC modeling as a basis to define classes

40. Forward Engineering Object-Oriented Architectures - part 2 • create class hierarchies, object-relationship models, object-behavior models and begin object-oriented design • a component-based process model may be used if a robust component library already exists • where components must be built from scratch, it may be possible to reuse algorithms and data structures from the original application

41. Forward Engineering User Interfaces • understand the original user interface and how the data moves between the user interface and the remainder of the application • remodel the behavior implied by the existing user interface into a series of abstractions that have meaning in the context of a GUI • introduce improvements that make the mode of interaction more efficient • build and integrate the new GUI

42. Economics of Reengineering • Cost of maintenance = cost annual of operation and maintenance over application lifetime • Cost of reengineering = predicted return on investment reduced by cost of implementing changes and engineering risk factors • Cost benefit = Cost of reengineering - Cost of maintenance