1 / 22

The Re-engineering and Reuse of Software

The Re-engineering and Reuse of Software. Patrick A.V. Hall and Lingzi Jin Vol 1, p.335-351 Presented by: Andrew Wheeler. Overview. Definitions Introduction Historical Background Implementations Challenges Conclusions. Definitions. Re-engineering

ford
Download Presentation

The Re-engineering and Reuse of Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Overview • Definitions • Introduction • Historical Background • Implementations • Challenges • Conclusions

  3. Definitions • Re-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 – ReuseComponent 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 – ReuseComponent 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

More Related