Software Reengineering CIS 376 Bruce R Maxim UM Dearborn 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 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 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 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 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 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 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 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 Reengineering Process from Sommerville Program documentation Original program Modularised program Original data Reverse engineering Program modularisation Source code translation Data reengineering Program structure improvement Structured program Reengineered data 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 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 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 Forward Engineering and Reengineering from Sommerville System specification Design and implementation Ne w system Understanding and transformation Re engineered system Forward engineering Existing software system Software re engineering 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 Reverse Engineering Concepts part 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 Reverse Engineering Concepts part 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 Reverse Engineering Process from Sommerville Automated analysis System to be re engineered Manual annotation Program stucture diagrams System information store Document generation Data stucture diagrams Traceability matrices Reverse Engineering Activities part 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 Reverse Engineering Activities part 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 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 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