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.

Based on Using RUP to reverse-engineer a legacy system.