I fully sympathize with your plight. I had to face almost exactly this scenario whilst working on my CS dissertation. Here's what I wrote about about trying to reverse engineer some code:
"During the first half of the project, all I had to go on was a delivery of source code for the original Java Editor, with no accompanying formal documentation. In order to try and gain some insight into this code and understand the existing system better, it seemed appropriate to try and use one of the 'round-trip' engineering tools available in the public domain. Round-trip or reverse engineering is the process of evaluating an existing body of code to capture important information describing a system, and representing that information in a format useful to a developer.
Ideally, I wanted a reverse engineering tool capable of extracting a complete set of design diagrams depicting class contents, structure, inheritance and associations from the source code of the existing system. It would have been particularly beneficial to extract UML class and sequence diagrams for the system I was working on. I was particularly interested in obtaining message sequence diagrams as my manual efforts to understand the code had involved jumping around the maze of source files trying to visualise these mentally.
I attempted to use a number of reverse engineering tools among them, Together/J and CodeVizor, with differing degrees of success. Unfortunately, these tools were only trial versions, much their functionality having been crippled for distribution in the public domain.
Together/J's functionality was severely limited and was capable of analysing a system of Java packages. I was certainly impressed by the way I could specify the root of the set of packages constituting the Java Editor and have Together/J scrutinise every class in the program and render a UML package diagram. After significant reorganisation of this diagram, I was able to see the package structure of the Java Editor.
CodeVizor could produce class diagrams, but only showed a separate singular class hierarchy diagram for each class in the system and not the all-important association between classes.
For an inexplicable reason, it did not occur to me until half way through the project, that I could simply obtain the documentation for the system, by borrowing the copy retained by the Department. Having got hold of this after the Christmas vacation, I had slightly more to go on.
The author of the original system had produced considerable design documentation. The software design was modelled in UML notation and included a basic class association diagram, numerous package diagrams and a collection of state diagrams. However, I felt this documentation fell down by having little or no textual description accompanying these diagrams. A high level discussion of the architecture of the software and the design decisions that had shaped it was absent.
In the end, I found that the only real way to familiarise myself with the existing system was to roll up my sleeves and study the source code. I had to spend a great deal of time just staring at source code and following the sequence of messaging in order to learn what parts of the system were vitally important, what parts might be reused and what parts of the system could be safely abstracted away and not thought about again.
Luckily I was also able to contact the original writer of the Java Editor and this helped a great deal. It is said that a system's architecture is a shared hallucination and only in discussion with the original author of the system and studying the source code was I able to start developing this shared hallucination."
I hope this information will be helpful in that it demonstrates that if there are professional tools out there that do this, they are probably prohibitively expensive and that the only real way to get inside the system is to talk to it's original authors.
Slashdot Mirror
I fully sympathize with your plight. I had to face almost exactly this scenario whilst working on my CS dissertation. Here's what I wrote about about trying to reverse engineer some code:
"During the first half of the project, all I had to go on was a delivery of source code for the original Java Editor, with no accompanying formal documentation. In order to try and gain some insight into this code and understand the existing system better, it seemed appropriate to try and use one of the 'round-trip' engineering tools available in the public domain. Round-trip or reverse engineering is the process of evaluating an existing body of code to capture important information describing a system, and representing that information in a format useful to a developer.
Ideally, I wanted a reverse engineering tool capable of extracting a complete set of design diagrams depicting class contents, structure, inheritance and associations from the source code of the existing system. It would have been particularly beneficial to extract UML class and sequence diagrams for the system I was working on. I was particularly interested in obtaining message sequence diagrams as my manual efforts to understand the code had involved jumping around the maze of source files trying to visualise these mentally.
I attempted to use a number of reverse engineering tools among them, Together/J and CodeVizor, with differing degrees of success. Unfortunately, these tools were only trial versions, much their functionality having been crippled for distribution in the public domain.
Together/J's functionality was severely limited and was capable of analysing a system of Java packages. I was certainly impressed by the way I could specify the root of the set of packages constituting the Java Editor and have Together/J scrutinise every class in the program and render a UML package diagram. After significant reorganisation of this diagram, I was able to see the package structure of the Java Editor.
CodeVizor could produce class diagrams, but only showed a separate singular class hierarchy diagram for each class in the system and not the all-important association between classes.
For an inexplicable reason, it did not occur to me until half way through the project, that I could simply obtain the documentation for the system, by borrowing the copy retained by the Department. Having got hold of this after the Christmas vacation, I had slightly more to go on.
The author of the original system had produced considerable design documentation. The software design was modelled in UML notation and included a basic class association diagram, numerous package diagrams and a collection of state diagrams. However, I felt this documentation fell down by having little or no textual description accompanying these diagrams. A high level discussion of the architecture of the software and the design decisions that had shaped it was absent.
In the end, I found that the only real way to familiarise myself with the existing system was to roll up my sleeves and study the source code. I had to spend a great deal of time just staring at source code and following the sequence of messaging in order to learn what parts of the system were vitally important, what parts might be reused and what parts of the system could be safely abstracted away and not thought about again.
Luckily I was also able to contact the original writer of the Java Editor and this helped a great deal. It is said that a system's architecture is a shared hallucination and only in discussion with the original author of the system and studying the source code was I able to start developing this shared hallucination."
I hope this information will be helpful in that it demonstrates that if there are professional tools out there that do this, they are probably prohibitively expensive and that the only real way to get inside the system is to talk to it's original authors.
Evan