1. Introduction
In a previous post I came to the conclusion that reverse-engineering might be needed the most by new team members working in an already established project.
This covers the scenario when knowledge is not widespread and there is little time to get “the full picture” of what’s going on before being asked to be a contributive member of the team.
The only possibility is to go through the code and try to understand what the team has come up with over the lifetime of the project. Of course, experienced and /or talented programmers could be able read and understand the code fast, but they would still need to rebuild all the discussions with the customers, if they want to understand what the system is supposed to do. For the latter, some diagrams can definitely help.
In principle, reverse-engineering should be used to bring source code into a Model Driven Development process and, for this reason, it should be necessary only once. However, I have seen the process applied either just once to create some diagrams and produce some kind of documentation, or by having someone doing it regularly from the source code, just to maintain the diagrams in sync with the code. I normally call the output of the latter case UML “pictures” or “paintings“and not “diagrams“, because they are not used to communicate among stakeholders before or during development, but probably only for some contractual clause.
Instead, I’ll identify some clear objectives that, depending on the size of the project, can be achieved relatively quickly. We are going to use our tools
- to identify all the entities defined in the source code to implement the system
- to model the most important relations between the defined entities.