Download as pdf or txt
Download as pdf or txt
You are on page 1of 37

Software Reengineering

R Reengineering i i
What is it? g a software to create a more p powerful p product. Rebuilding Who does it? g level: business specialists. p -Organizational -Software level:Software engineers. Why it is important? The rapid change in information technology.

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 b l When tools to support restructuring are readily available il bl

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 y rewrite the documentation for critical systems y focusing on the "essential minimum"

Software Reengineering Process Model - part 2


Reverse engineering
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 p g gp practices are noted and repaired p 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 i called ll d reclamation l i or renovation i 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 g g and Reengineering g g from Sommerville


System specification Forward engineering Existing software system Software re-engineering Understanding and transformation Re-engineered system Design and implementation New system

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
d degree to which hi h humans h are integrated i d with i h automated d 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 d i d from derived f old ld source code d

Reverse Engineering Process from Sommerville


Program stucture diagrams System information store Manual annotation Document generation Data stucture diagrams Traceability matrices

Automated analysis System to be re-engineered

Reverse Engineering Activities part 1


Understanding process
source code is analyzed to at varying levels of detail
system program component pattern statement

to understand d d procedural d l abstractions b i and d overall ll 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 p of equivalence q of interfaces is relevant?

Reverse Engineering Applicability


Reverse engineering often precedes reengineering g g is p preferred Sometimes reverse engineering
if the specification and design of a system needs to be defined prior using them as input to the requirements specification ifi ti process for f a replacement l t systems t if the design and specification for a system is needed to pp p program g maintenance activities support

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 ADTs

Creating ADTs and Objects


Analyze the data common areas to identify logical abstractions Create ADTs 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

Sommervilles Sommerville s Restructuring Approaches


Automated program restructuring Program and data restructuring

Automated source code conversion

Automated restructuring with manual changes

Restructuring plus architectural changes

Increased cost

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


Program to be restructured Analyser and graph builder Graph representation Program generator Restructured program

Automatic Restructuring Problems


Loss of source code comments Loss of documentation Heavy computational demands p with poor p modularization problems p Will not help (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 l be b realistic li i (e.g. ( cost and d time i effective) ff i ) if an automatic translator is available Manual M l fi fine tuning t i of f new code d is i always l required i d

Program Translation Process from Sommerville


System to be re-engineered System to be re-engineered Re-engineered system

Identify source code differences

Design translator instructions

Automatically translate code

Manually translate code

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 h DBMS The goal to create an environment where is managed d not t just j t used d

Data Rengineering Approaches - part 1


Data cleanup
data records and values are analyzed y to improve p quality duplicates removed redundant information is deleted consistent format applied pp 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 h

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 h use of f aliasing li i by b programmers

Field length problems


different field lengths g used for same data item in different programs

Record organization problems


different field orderings used by different programs

Hard-coded literals y No data dictionary

Data Value Inconsistencies


Inconsistent default values used in different programs (e.g. especially missing data codes) Inconsistent I i units i used d for f same quantity i (e.g. ( miles il in i 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 f using i uppercase to convey meaning i in i text strings) i ) Inconsistent handling of negative numbers (e.g. data validation and representation issues)

Data Reengineering Process f from Sommerville ill


Program to be re-engineered Data analysis

Data analysis

Entity name modification Literal replacement Data definition re-ordering Stage 1 Stage 2

Data re-formatting Default value conversion Validation rule modification Stage 3

Data conversion

Change summary tables

Modified data

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 , security, y, archiving, g, and new communications, 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 d f functionality i li of f application li i data models created during reverse engineering are used dt to define d fi classes l

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 b component lib library already l d exists i where components must be built from scratch, it may be b possible ibl t to reuse algorithms l ith and d data d t 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 i interface f into i a series i of f abstractions b i that h have h meaning in the context of a GUI introduce i t d improvements i t that th t make k the th mode d of f interaction more efficient build b ild and di integrate t t th 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 h and d engineering i i risk i k factors f Cost benefit = Cost of reengineering - Cost of maintenance i t

You might also like