1. The Re-engineering and Reuse of Software
Patrick A.V. Hall and Lingzi Jin
Vol 1, p
Presented by: Andrew Wheeler

2. Overview Definitions Introduction Historical Background
Implementations
Challenges
Conclusions

3. Definitions Re-engineering Reuse Reverse engineering
The combination of reverse engineering and forward engineering
The concept of “redoing” a software system
Reuse
Using a given piece of software to solve more than one problem
Reverse engineering
The tools and methods used to understand software
Figuring out a software system for potential redeployment

4. Introduction
Software re-engineering and reuse are concerned with maximizing software usage for any given development effort
Both are used to maximize profit and minimize turnaround time
Software re-engineering and reuse also help minimize staff
The more code you can reuse the less code you have to write and rewrite

5. Introduction (cont)
Reuse not only applies to using a piece of software:
Reuse designs and ideas thrown out during design phase
May have use in other applications
Reverse engineering and reuse can help recover lost investment
Time has already been placed into designing it the first time around.

6. Historical Background - Reuse
Reuse dates back to sharing of algorithms through publications
Reuse of high level language and packages
Textbook publications
Use of macros and similar assembly instructions
Subroutine entry and exit
For loops, if blocks, arithmetic

7. Historical Background – Reuse (cont)
Reuse associated with flexibility
Parameterization
Build scripts

8. Historical Background - Re-engineering
Flow-charting tools have been around for awhile
Now evolved into UML and sequence diagrams
Cross reference listings of variables
Helps understand large pieces of software
Originally designed to help maintain COBOL legacy systems around 1980s

9. Implementations – Reuse
Integration into lifecycle
Building phase to construct the reusable components into a library
Incorporating those reusable components into the building of a software system
Time required to account for integration issues

10. Implementations – Reuse Component based
Central to reuse
Design for “plug and play”
Which components comes from domain analysis
File Input/Output component not needed for a system that won’t write to disk

11. Implementations – Reuse Component based
Give clear descriptions and classifications
Avoid over generalization
Map instead of tree
Object oriented programming lends itself to reuse
Objects are often in reusable component form
Inheritance provides contexts for reuse
Sorted Map inherits from Map
Size or granularity

12. Implementations – Reuse
Reuse in design
Component or components could fulfill a requirement based on specifications
If multiple components are used then requirements must be broken down further
Logging utility = Time utility + Format utility + File utility + Process input utility
Identification, evaluation, modification, and integration
White-box reuse
Reuse with simple modifications of code
Frameworks

13. Implementations – Reuse
MIL – Module Interconnection Languages – Prieto-Diaz, et. al (1986)
Going beyond procedure calls in code
Helps in system building another higher language
Design with reuse involves transforming the outputs of one components to the inputs of another

14. Implementations – Re-engineering
Reverse engineering involves abstracting the current system and revealing the nature of the system
Describe the system to a non technical person
Documentation of class methods and members could be used during the process
Outlining tools and sequence diagrams have been in use for many decades

15. Implementations – Re-engineering
Use of formal transformations
Gather details about an efficient algorithm that may be difficult to understand
Use of wide spectrum language - Ward
An interactive system to abstract details of implementation into Z language and implement Z language in code language of choice

16. Implementations – Re-engineering
Use of reverse engineering back to specifications – Lano, et. al
Used to reverse engineer COBOL applications
Using good coding practices helps the re-engineering process
Self documenting code
Knowledge of higher level domain concepts helps re-engineering
Knowing for what purpose the software system was used

17. Implementations – Re-engineering
Using design patterns in code
Helps to know the purpose for a software system and helps the forward process by knowing how to build the system
Object-oriented programming facilitates the reverse-engineering process
Components of the high level systems share the names of the objects

18. Implementations – Domain Analysis
Identify the major concepts and the relationships between the concepts
Usage of components is determined by the domain in which they will be used
Determine if components needed have already been built
Helps guide the production of components for better reuse
Adequate domain models help scope the components and their usage

19. Challenges of Re-engineering and Reuse
Personnel issues
“Why buy when you can build?”
Reuse doesn’t always mean buying
Contrast to electronic engineering
Build your own microprocessor?
Payoff issues
Rewarding someone for building a reusable component by royalties?

20. Challenges of Re-engineering and Reuse
Economical issues
Payoff occurs after component production
Most companies are geared towards producing a system
Gain another contract and reduce turnaround time from reuse
Accounting treats software as consumable and not capital
Concept of making software reusable capital like a desk

21. Challenges of Re-engineering and Reuse
Legal issues
Protection against physical piracy and intellectual piracy
Use of proprietary software remedies certain issues

22. Conclusions
Software reuse, re-engineering, and reverse engineering are cutting-edge methodologies
Product Line and Battle Command Product Line
Technology has caught up to these practices
UML
There is a future in adding reuse to the software lifecycle
Economic gains must be established