The goal of a reengineering project is to restructure a legacy software system so that some of its quality attributes are improved. This restructuring could imply a change in the technological framework, such as a migration to an SOA framework. Whatever the technology, the reverse-engineering project should assess the feasibility of the restructuring. In fact, even if the target of the reverse-engineering is to remodel a system, it must also prototype the migration of some key component to the new architecture to check that it is possible.
The inception phase is intended to assess the feasibility of the project. In particular, the project manager should check that a sufficient number of users can be accessed and queried, that the current database tables and source code are accessible, and that the proper tools are known and available (for example, for recording the execution trace). Then some critical parts of the system should be reverse-engineered and the migration path to the new platform validated. Finally, the majors risks must be understood. At the end of the inception phase, the go/no-go decision can be made.
The elaboration phase is intended to reverse-engineer the critical parts of the system and redocument their high-level architecture. In particular, the actual grouping paradigm of the classes (files) of the legacy code, if any, should be known. Moreover, the reverse-engineering environment and tools should be put in place. At the end of the inception phase, the architecture of the critical part to reverse-engineer should be documented.
During the construction phase, all the components in the scope of the project are reverse-engineered. Then, at end of the inception phase, the system is fully redocumented.
During the transition phase, the models and documentation of the legacy system are transferred to the team that will forward-engineer the new system.
Summarizing of the main tasks and working products of the process are in the table below. The elements marked as italic are out of the standard RUP.
| Discipline | Task | Product |
|---|---|---|
| Business Modeling | Detail a Business Use Case | Business Use Cases |
| Business Modeling | Find Business Workers and Entities | Business Analytics Model |
| Business Modeling | Detail a Business Entity | Business Entry |
| Requirements | Develop Vision | Vision |
| Requirements | Find Actors and Use Cases | System Use-Cases Model |
| Requirements | Find Actors and Use Cases | Supplementary Specifications |
| Requirements | Prioritize the Use Cases | Reverse-Engineering Requirement Attributes |
| Requirements | Detail in Use Cases | Use Case |
| Analysis & Design | Database Analysis | Data Model |
| Analysis & Design | Use Case Analysis | Analysis Model |
| Implementation | Analyze the Implementation Model | Implementation Model |
| Implementation | Define Execution Details | Execution Case |
| Implementation | Run the Use Cases | Execution Trace |
| Implementation | Analyze the Call Graph | Extended Set of Functions |
| Implementation | Map Function to Implementation Model | Software Architecture Document |
| Implementation | Validate the Hypothetical Architecture | Software Architecture Document |
| Implementation | Rebuild the High Level Architecture | Software Architecture Document |
| Project Management | Develop Business Case | Business Case |
| Project Management | Identify and Assess Risks | Risk List |
| Project Management | Assess Iteration | Iteration Assessment |
It was shown that most of the tasks and work products that you need on our reverse-engineering process are found in the RUP toolbox or are close to them. It is worth mentioning the central role played by the use-case model in this work as in any RUP-based software development project. First, the use cases help us to redocument the business process model that is supported by the software. Second, the use cases help us build a hypothetical architecture of the legacy system. Third, the use cases are the source of scenarios to be run to gather the execution trace of the system. In some sense, the use-case model lets us make the link between the high-level business function and the low-level code that implement these functions.
One of the key problems in reverse-engineering a legacy software system is to understand the code and build an architectural representation of it.