Software Reengineering CIS 376 Bruce R Maxim UMDearborn

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

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

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

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 structures need to be transformed to objects or ADT’s

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

Sommerville’s Restructuring Approaches

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

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

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

Automatic Program Restructuring from Sommerville

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

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

Program Translation Process from Sommerville

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

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

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

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

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)

Data Reengineering Process from Sommerville

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

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

Forward Engineering Object-Oriented Architectures - part 2 • create class hierarchies, object-relationship models, object-behavior models and begin objectoriented 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

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

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