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

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
Program stucture
diagrams
Automated
analysis
System
information
store
System to be
re-engineered
Manual
annotation
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 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
Automated progr am
restructuring
Automated source
code conversion
Program and data
restructuring
Automated r estructuring
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
Restructur ed
program
Analyser and
graph builder
Program
generator
Graph
repr esentation
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
System to be
re-engineered
Identify source
code differences
Design translator
instructions
System to be
re-engineered
Re-engineered
system
Automatically
transla te code
Manually
transla te 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 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
Data
analysis
Program to be re-engineered
Data
analysis
Entity name
modification
Literal
replacement
Data definition
re-ordering
Stage 1
Data
re-formatting
Default value
conversion
Validation rule
modification
Stage 2
Change summary tables
Data
conversion
Stage 3
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
• 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