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 Process from 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 Reengineering from 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 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

17. 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

18. Reverse Engineering Process from Sommerville

19. 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

20. 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?

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’s Restructuring 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 Process from 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 Field length 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 Process from 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