Class Diagram Tool For Hundreds Of Classes? 13
St0rk asks: "I am trying to make sense of someone else's Java code. He is another programmer in my team, but uses different programming style that generates tons of classes (just as the tick books say ;-). We are talking about 300 files, and approximately 430 classes here. I am looking for a tool/package/program that can take a relatively big amount of OO source code (Java classes) and build useful diagrams/documentation.
Please note that I used 'useful.' Most of the tools out there can produce some hierarchy diagrams, but they either get too unreadable when one is dealing with so many classes, or miss too much (for example when a class A has a Vector that is going to be filled with objects of type B, there won't be a link between A and B genereated).
It would be great if I can good prints as well. Any suggestions based on real life experience? (Rational Rose is too expensive, BTW)"
TogetherJ (Score:2)
Try JVision (Score:2)
This tool supports forward and reverse engineering of classes, and pretty good diagraming support. It's a lot faster than ArgoUML, and a lot cheaper than TogetherJ or Rational Rose
ArgoUML (Score:2)
hiro
Break it down (Score:2)
LXR + Hyperbolic web visualizer (Score:2)
I would then try to browse the source with a hyperbolic web visualization tool, such as Inxight [inxight.com] or Webviz [umn.edu] from the Geometry Center (RIP). Apparently there are many such visualization tools. Perhaps one will work well with LXR output.
Same question, C++ (Score:2)
Free (beer) - Good
Commercial - If I can eval it for the job
---
I'd give ObjectDomain a try... (Score:1)
...even though I'm fairly sure the end result won't be particularly readable. :)
It's an excellent UML modelling tool though, with easily customizable Python scripts for code generation.
I couldn't live without it! Check it out at http://www.objectdomain.com [objectdomain.com].
Re:TogetherJ (Score:1)
The whiteboard edition is all you need to do serious work. The pay versions are even better.
UML doclet (Score:1)
Re:Try SNiFF+ (Score:1)
I'll second that. I've used SNiFF+ for a couple of years now. It may be clunky at times (especially on the Windows platform) but it is an industrial-strength tool - unfortunately with an industrial-strength price-tag.
Try SNiFF+ (Score:1)
Re: (Score:1)
reverse engineering. (Score:1)
"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