Software Design and Architecture

By: Ashenafi C. and Amsalu T.

AASTU, May 2020

1
 Chapter Seven

Software Reengineering and Reverse

Engineering

2
 Software Change
 Software change is inevitable.
» New requirements emerge when the software is used;
» The business environment changes;
» Errors must be repaired;
» New computers and equipment is added to the system;
» The performance or reliability of the system may have to be improved.
 A key problem for organizations is implementing and
managing change to their existing software systems.

3
 Types of Changes
 Repair software faults
» Changing a system to correct deficiencies in the way meets its
requirements.
 Adapt software to a different operating environment
» Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation.
 Add to or modify the system’s functionality
» Modifying the system to satisfy new requirements.
 Improve the program structure and system performance
» Rewriting all or parts of the system to make it more efficient and
maintainable.

4
 Software Evolution and Software Maintenance
 Generally, software evolution refers to the study and
management of the process of making changes to software over
time.
» In this definition, software evolution comprises:
– Development activities
– Maintenance activities
– Reengineering activities
 Narrow definition of evolution: Sometimes, software evolution is
used to refer to the activity of adding new functionality to existing
software.

 Maintenance refers to the activity of modifying software after it

has been put to use in order to maintain its usefulness.

5
 Software Maintenance
 Modifying a program after it has been put into use.
 Maintenance does not normally involve major changes to the
system’s architecture.
 Changes are implemented by modifying existing components and
adding new components to the system.

6
 Types of Maintenance
 More precisely, even though software doesn’t age in the same was as
physical equipment, it still needs to be:
– fixed (corrective maintenance),
– adapted to changing needs (adaptive maintenance),
– improved in performance or maintainability (perfective
maintenance)
– improved by fixing bugs before they activate (preventive
maintenance)

7
 Maintenance Costs
 Usually greater than development costs.
 Affected by both technical and non-technical factors.
 Increases as software is maintained.
 Maintenance corrupts the software structure so it makes
further maintenance more difficult.
 Ageing software can have high support costs (e.g. old
languages, compilers etc.).

8
 Software Evolution Processes
 Processes for evolving a software product depend on:
» The type of software being maintained;
» The development processes used;
» The skills and experience of the people involved.
 Proposals for change are the drivers for system evolution. Change
identification and evolution continue throughout the system lifetime.

Change identification and

evolution
9
 System’s Evolution Process

Change Impact Release Change System

requests analysis planning implementation release

Platform System
Fault repair
adaptation enhancement

10
 Legacy Systems
 For many systems, the software evolution process is not as
straightforward as described.
» Associated models and documentation of the software may be missing or
hopelessly outdated.
» The new requirements may not be anticipated by the design of the software,
making the resulting changes difficult to implement correctly.
» Such kind of systems are termed as Legacy Systems.
 Legacy systems are old systems that have become significantly
difficult to modify.
» Accumulation of changes have eroded the modularity of the original design.
» The documentation has not been maintained and has become obsolete.
» One or more pieces of its underlying technologies have become obsolete.
 Two complementary techniques are employed to support the continued
evolution of legacy systems:
» Reengineering
» Reverse engineering

11
 Reengineering
 Creating a maintainable system out of an un-maintainable one (at a larger
scale than refactoring).
 Re-structuring or re-writing part or all of a legacy system without
changing its functionality.
 Applicable where some but not all sub-systems of a larger system require
frequent maintenance.
 Re-engineering involves adding effort to make them easier to maintain.
The system may be re-structured and re-documented.
 Advantages of Reengineering
» Reduced risk
– There is a high risk in new software development. There may be
development problems, staffing problems and specification problems.
» Reduced cost
– The cost of re-engineering is often significantly less than the costs of
developing new software.
12
Forward Engineering and Reengineering

13
The Reengineering Process

14
 Reengineering Process
 Source code translation
» Convert code to a new language.
 Reverse engineering
» Analyze the program to understand it;
 Program structure improvement
» Restructure automatically for understandability;
 Program modularization
» Reorganize the program structure;
 Data reengineering
» Clean-up and restructure system data

15
 Reverse Engineering
 In many legacy systems, the only reliable information about the
system is the source code.

 Reverse engineering reconstructs requirements, design models,

test cases and user documentation consistent with the current
state of the source code.

 Reverse engineering is often the initial activity in a reengineering

project.

 Reverse engineering is a process of design recovery.

 Reverse engineering tools extract data, architectural, and
procedural design information from an existing program.
16
 Software Reengineering Approaches
 System Reengineering (Big Bang / LumpSum)
 Incremental (Phase out) Reengineering

17
 System Reengineering
 Fully re-engineer the entire system (data files, source code, new
platform, etc.), validate the functionality, then implement the newly
re-engineered system.

 A major disadvantage to the system re-engineering approach is the

all-or-nothing high risk of failure.
 The re-engineered system must contain no errors that affect key
user functionality. The system’s users expect no less since they
have historically relied on the legacy system.
 In fact, the level of risk for a re-engineered system is perceived as
greater than that for a newly developed system. 18
 Incremental Reengineering
 System sections are re-engineered and added incrementally as new
versions of the system are needed to satisfy new goals. The project is
broken into re-engineering sections based on the existing system’s
sections.
 Advantages
 The components of the system are produced faster.
 It is easier to trace errors since the new components are clearly identified.
 Since intermediate versions are released, the customer can see the progress and quickly
identify any lost functionality.
 Changes to the old system can be easier to deal with, since changes to components that
are not being re-engineered have no impact on the current component.

19
 Cont’d
 Disadvantages
» The system takes longer to complete with multiple intermediate
versions that require careful configuration control.
» The entire structure of the system cannot be altered, only the
structure within the specific component sections being reengineered.
This requires careful identifications of components in the existing
system and extensive planning of the structure of the target system.

 This approach has a lower risk than the Big Bang because as each
component is re-engineered, the risks for that portion of the code can be
identified and monitored.

20