What tools should I use to visualize structure of my code?

Question

I have an application written in Java. In is stored in several files. It uses different classes with different methods. The code is big and complicated. I think it would be easier to understand the code if I have a graphical model of the code (some kind of directed graph). Are there some standard methods for visualization of code. I am thinking about usage of UML (not sure it is a correct choice). Can anybody recommend me something?

ADDED:

I consider two possibilities:

1. Creating the graph by hands (explicitly).
2. Creating graph in an automatic way. For example to use some tools that read the available code and generate some graph describing the structure of the code.

ADDED 2:

It would be nice to have something for free.

Answer 1

Some plugins I know for Eclipse:

Architexa

http://www.architexa.com/

nWire

http://www.nwiresoftware.com/

If you want to reverse engineer the code, you should try Enterprise Architect

Answer 2

JUDE Community UML used to be able to import Java, but it is no longer the case. It is a good, free tool.

If your app is really complex I think that diagrams won't carry you very far. When diagrams become very complex they become hard to read and lose their power. Some well chosen diagrams, even if generated by hand, might be enough.

You don't need every method, parameter, and return value spelled out. Usually it's just the relationships and interactions between objects or packages that you need.

Answer 3

have you tried Google CodePro Analytix ?

it can for example display dependencies and is free (screenshot from cod.google.com):

Answer 4

The most important tool you should use is your brain, and it's free.

There's no reason why you have to use any sort of standard method of visualization, and you can use whatever media you like. Paper, whiteboard, photoshop, visio, powerpoint, notepad: all of these can be effective. Draw a diagram of classes, objects, methods, properties, variables - whatever you think is useful to see in order to understand the application. The audience is not only other members of your team, but also yourself. Create diagrams that are useful for you to look at and quickly understand. Post them around your workspace and look at them regularly to remind yourself of the overall system architecture as you build it.

UML and other code documentation standards are good guidelines for the types of diagrams you can do and the information you should consider including. However, it is overkill for most applications and basically exists for people who can't take personal responsibility for documenting without standards. If you follow UML to the letter, you'll end up spending way too much time on your documentation instead of creating your application.

Answer 5

Here is a non UML Tool which has very nice visualization features.

You can mapping the lines of code per class / method to colors / side lenght of rectangles. You can also show the dependencies between the classes.

http://www.moosetechnology.org/

The nice thing is, you can use Smalltalk scripting for displaying what you need: http://www.moosetechnology.org/docs/faq/JavaModelManipulation

Here you can see how such a visualization looks like: http://www.moosetechnology.org/tools/moosejee/casestudy

Answer 6

I tried using a number of UML tools and found that the reverse-engineering capabilities in most UML tools were not helpful for understanding code. They focus on designing needs and reverse-engineering capabilities often just ends up showing huge pictures of lots of useless information. When I was working on the Microsoft Office codebase, I found using a pen-and-paper more helpful that the typical design/modelling tools.

You typically want to think about doing this in a number of ways:

1. Use your brain: Someone else mentioned it - there is no substitute to actually trying to understand a code base. You might need to take notes down and refer back to it later. Can tools help? Definitely. But don't expect them to do most of the work for you.
2. Find documentation and talk to co-workers: There is no better way than having some source describe the main concepts in a codebase. If you can find someone to help you, take a pen and paper, go to him and take lots of notes. How much to bug the other person? In the beginning - as much as is practical for your work, but no amount is too little.
3. Think about tools: If you are new to a part of a project - you are going to be spending a significant amount of time understanding the code, so see how much help you can get automatically. There are good tools and bad tools. Try to figure out which tools have capabilities that might be helpful for you first. As I mentioned above, the average UML tool focuses more on modeling and does not seem to not be the right fit for you.
4. Time vs Cost: Sure, free is great. But if a free tool is not being used by many people - it might be that the tool does not work. There are many tools that were create just as an exploration of what could be done, but are not really helpful and therefore just made available for free in hopes that someone else will adopt it. Another way to think about it, decide how much your time is worth - it might make sense to spend a day or two to get a tool to work for you.

Once there, keep these in mind when going trying to understand the project:

1. The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another. Tools like Lattix and Architexa can be really helpful here.
2. The Core: Try to figure out how the code works with regards to the main concepts. Class diagrams are exceptionally useful here. Pen-and-paper works often enough here, but tools can not only speed up the process but also help you save and share such diagrams. I think AgileJ and Architexa are your best bets here, but your average UML tool can often be good enough.
3. Key Use Cases: I would suggest tracing atleast one key use case for your app. You likely can get the most important use cases from anyone on your team, and stepping through it will be really helpful. Most IDE's are really helpful here. If you try drawing them, then sequence diagrams arethe most appropriate. For tools here I think MaintainJ, JDeveloper and Architexa are your best bets here.

Note: I am the founder of Architexa - we build tools to help you understand and document Java code, but I have tried to be unbiased above. My intention is to suggest tools and options given that this is what I focused on as part of my PhD.