Strategy for reverse engineering legacy C# code (C# code)
This topic provides a roadmap to ease the process of reverse engineering legacy code using C# Code Reverser, aimed at first time users of the Reverser. It describes the steps required for the most common usage patterns, and highlights possible pitfalls. It assumes that you are familiar with the UML, C# and compiler concepts.
When to reverse engineer code
There are three common scenarios (use cases) for reverse engineering code:
• To reverse in existing handwritten code (a.k.a. 'legacy' code) to better visualize, understand and document it than is possible with just code. This will also enable further software development to be done in the more productive environment of Modeler.
• To reverse in existing code into a model to generate code using a different language.
• To reverse in a library interface.
What the Reverser does when it reverse engineers code
The Reverser does its work in two stages:
• It parses the code files selected for reverse engineering and reports any errors. It is important that you correct parsing errors before continuing.
• It then performs the actual reverse engineering to update the Class Model from the selected code files.
Important Considerations
The subsections that follow detail the issues – the solutions are in the final section.
Dealing with very large projects
Even after you have excluded standard libraries from your reversing, some projects are still very large. As the Reverser checks each item it is reversing against the existing model (or what it has already reversed in the case of legacy reversal), the speed at which reversing proceeds decreases as model size increases. As a result of this, for very large projects it is often a good idea to split the project up along natural interfaces and place each smaller project in a separate directory.
Each smaller project can then be reverse engineered into a separate package, so the directory mappings for each project can specify what is within the scope of each smaller project, and what is not. If you have co-dependencies, the first package you reverse engineer may need to be reverse engineered again after the subsequent packages are reverse engineered, so that all references are modeled in the model as links.
We recommend that you create a separate Model Settings File for each smaller project in the model.
As the question 'How large is very large (when it comes to reversing)' is affected by so many factors (number of modules, size of modules, connectivity between modules, code style, power of computer and length of wait that is acceptable) it is best determined by experiment and experience – try it on your model and see. As a real 'finger in the air' estimate, though, the upper limit for a manageable reversal is of the order of a few hundred modules or a hundred thousand lines of code.
Do you want to reverse engineer function bodies
Through the 'Reverse Engineer Code Bodies' check box on the Reverse Engineering Options 1 page, you can choose to either reverse engineer function bodies or not.
Shared or personal model settings files
Model Settings Files record Reverser settings used for reverse engineering code. By default, the Model Settings File for a model is saved locally to your Modeler installation folder. You can you can save a Model Settings File to a shared directory, so that everyone uses the same settings for reverse engineering code. All users that use a shared Model Setting File must use the same paths for #defines and files parsed.
In addition, you can use Model Settings Files to maintain different configurations, such as, code with and without debug constructs.
Order of Operations for Reversing
Note that there is considerably more information for the tool operations that follow in the help.
Decide on your projects and their contents
Consider the earlier subsection 'Dealing with very large projects'.
Decide whether to reverse into one or a number of destination packages. If you decide on several then you need to decide how to split up the source code between the projects. After you have decided on the split you will probably need to move files around, to make sure that each project has its own distinct directory or directories, from which it reverses into its Class Model. If you don't do this (that is, if some directories contain class definitions meant to go to different projects) you will end up with classes defined in more than one project, which will cause problems at integration time.
If you split a large project into several projects, create a model settings file for each project.
All following steps are on a 'per project' basis
Decide on the root directory
The root directory defines what code the Reverser is treating as application code (code within the root directory) and what code is treated as library and external code (code outside the root directory).
Set up your compiler #defines for the Reverser
On the Reverse Engineering Options 2 page, you must specify the pre-processor variables (equivalent to the #define statements in the code) needed to resolve how to reverse code segments within #ifdef and similar directives, and how to resolve macro substitutions.
 |
If you have code that causes Reverser parsing errors but is valid for your compiler, you can hide that code from the Reverser parser through the RTS_SYNC_INVOKED #define. RTS_SYNC_INVOKED is automatically defined when the Reverser is running, so you can make the code that causes parsing errors conditional using #ifndef RTS_SYNC_INVOKED so that the Reverser ignores it.
|