Java to UML tool - need some advice
Hi there,
I'm developing a UML case tool as part of my final year project for my BSc degree in Computer Science, the aim of this tool is to covert Java source code into a UML Class diagram.
When given a directory containing the current project files (*.java files), the system is then intended to analyse the source files in that directory and draw a UML Class diagram which shows the Inheritance and Associations.
Just to mention, I have so far managed to get the source code analysis done using a Doclet (via JavaDoc) and I can get the methods, variables etc for each class. These have been stored in relevant data structures.
Hoever, the most difficult part is the actual layout and construction of the class diagram and I would apprecaite any advice or assistance anyone is willing to provide..
Thanks in advance,
Regards
Tony
This is similar to something I've recently done. well, not entirely.
The question at hand is how do you convert related objects into a visual representation?
Can the items be expressed in a tree of sorts? Can you create a hierarchy of nodes from the items?
Take that tree, or relation of items, convert them into components (panels, for instance). Use a layout manager to space them where they need to go (you may need multiple visual levels, each level needing its own layout manager).
Then traverse through the items. Find where it's visually sitting. Find the items connected to it, and find where they are visually sitting. Create the logic to draw a line from one to the next with the appropriate adornments.
I suppose you could use some of the graphing/charting packages out there to help you with this, but I don't know if that's violating what you're responsible for.
my 2cents.
one of the caveats in doing this yourself is that when drawing lines connecting the nodes you may cross over other components that are visually "in the way". How do you route the line around them?
(you'd think I'd fully realize a thought before hitting "Post")Check out the argouml tool mentioned throughout these forums. I believe it's open source and does ERDs. You might find logic in there you can borrow from.
Thanks a lot Jarreth, I very much appreciate your comments.Just to let you know I've now managed to draw some class diagrams (i.e for individual classes) so now the next stage will be working on the layout of a multiple-class diagram.
Jarreth, as you have been involved in a project of a similar nature, I would appreciate if you could answer some of the following questions for me.
First of all, as I mentioned above.. the way my programis supposed to work is the user selects a Project directory (and all the .java files in the directory (excluding sub directories) ) are then analysed and a UML class diagram is drawn to represent the system.
Would you say this is an ideal way to go about it ?
I have looked at some existing programs and it appears they require the user to select the main Java class and a class diagram is drawn to represent the inheritance, associations etc with that given class acting as the central class in the diagram.
Which approach is the better and more useful? I would greatly appreciate any comments or advice from anyone, please help me :-)
Another thing I have noted is my program will not cater for packages and as I mention above, it will only draw a UML class diagram for a given set of java classes located in the same directory (i.e. has to be default package)... would this be reasonable ?
Thanks.
Regards,
Tony.
Just to further add, I would appreciate any suggestions or ideas as to any additional features I could possibly implement in my program.
The program is intended to be an OO Documentation Tool and its main function is to convert Java source code to UML Class diagrams.
The UML Class diagram will include Inheritance and Associations.
Other features that I have decided to implement are:
- Facility to generate custom HTML documentation ( tables listing the variables, methods (including parameter details, visibility etc) etc for each class). I have also managed to convert the java source code into HTML, with colored keywords etc.
- facility to view the source code of each java class in the main program, alongside the diagram.
- facility to save the uml class diagram as a GIF and JPEG image file.
That's just about it at the moment, I'm scratching my head trying to think of other possible ideas.
One idea I have thought about is possibly extending the system to cater for C++ classes but I think that might turn out to be a little over ambitious.
Please please give me some ideas, I need them.. :)
> Jarreth, as you have been involved in a project of a
> similar nature, I would appreciate if you could answer
> some of the following questions for me.
>
> First of all, as I mentioned above.. the way my
> programis supposed to work is the user selects a
> Project directory (and all the .java files in the
> directory (excluding sub directories) ) are then
> analysed and a UML class diagram is drawn to represent
> the system.
>
> Would you say this is an ideal way to go about it ?
What better way to analyze the source code than to read it? I would suggest maintaining an internal database of your analyzed data, along with the original file date - then you could know when a class representation is out of date in comparison to its source code (don't forget to walk the dependency chain!)
> I have looked at some existing programs and it appears
> they require the user to select the main Java class
> and a class diagram is drawn to represent the
> inheritance, associations etc with that given class
> acting as the central class in the diagram.
>
> Which approach is the better and more useful? I would
> greatly appreciate any comments or advice from anyone,
> please help me :-)
Either way could be argued as being the "better" route. If you have a directory littered with 50 source files, and only 4 of them are at all connected or related or dependent, then what will you achieve by charting all 50?
If your goal is to diagram everything, what good is it to just chart the 4 classes that are connected?
Perhaps giving the user a choice in the matter might be the high road.
>
> Another thing I have noted is my program will not
> cater for packages and as I mention above, it will
> only draw a UML class diagram for a given set of java
> classes located in the same directory (i.e. has to be
> default package)... would this be reasonable ?
>
Let's look at a base case scenario (very simplistic, indeed).
If my "main" class has a String[] entity, which would show in a ERD as a 1..* line between the 2 classes, and knowing that my main class doesn't reside in java.lang.... What good would the resulting diagram be?
that's just my 2cents. your mileage may vary. (=
> Jarreth, as you have been involved in a project of a
> similar nature, I would appreciate if you could answer
> some of the following questions for me.
>
> First of all, as I mentioned above.. the way my
> programis supposed to work is the user selects a
> Project directory (and all the .java files in the
> directory (excluding sub directories) ) are then
> analysed and a UML class diagram is drawn to represent
> the system.
>
> Would you say this is an ideal way to go about it ?
What better way to analyze the source code than to read it? I would suggest maintaining an internal database of your analyzed data, along with the original file date - then you could know when a class representation is out of date in comparison to its source code (don't forget to walk the dependency chain!)
> I have looked at some existing programs and it appears
> they require the user to select the main Java class
> and a class diagram is drawn to represent the
> inheritance, associations etc with that given class
> acting as the central class in the diagram.
>
> Which approach is the better and more useful? I would
> greatly appreciate any comments or advice from anyone,
> please help me :-)
Either way could be argued as being the "better" route. If you have a directory littered with 50 source files, and only 4 of them are at all connected or related or dependent, then what will you achieve by charting all 50?
If your goal is to diagram everything, what good is it to just chart the 4 classes that are connected?
Perhaps giving the user a choice in the matter might be the high road.
>
> Another thing I have noted is my program will not
> cater for packages and as I mention above, it will
> only draw a UML class diagram for a given set of java
> classes located in the same directory (i.e. has to be
> default package)... would this be reasonable ?
>
Let's look at a base case scenario (very simplistic, indeed).
If my "main" class has a String[] entity, which would show in a ERD as a 1..* line between the 2 classes, and knowing that my main class doesn't reside in java.lang.... What good would the resulting diagram be?
that's just my 2cents. your mileage may vary. (=
> The program is intended to be an OO Documentation Tool
> and its main function is to convert Java source code
> to UML Class diagrams.
if it's only intended to document existing code, rather than aid in design and development, please ignore future comments ;)
> That's just about it at the moment, I'm scratching my
> head trying to think of other possible ideas.
- allowing the user to add new classes, relate them to existing classes, and then generate code for them (think CASE, think Rational, etc)
- allowing for an integration with an external document that handles requirements (ie, Requisite)
> One idea I have thought about is possibly extending
> the system to cater for C++ classes but I think that
> might turn out to be a little over ambitious.
>
might be too ambitious to start with, yes.. but, if engineered properly, what's to keep it from analyzing any OO language, or even DDL ?
Thanks for all your comments Jarreth, its nice to know there are some people around here willing to give some advice and help to others. :)
I've made some progress on the diagram, managed to get a class drawn for each class file given, together with the reverse engineered class data, i.e. vars and methods.
One problem I'm finding with this "directory" approach is the diagram is turning out to be too cluttered and I'm ending up with a BufferedImage of size 5000 X 5000 pixels when drawing all the classes (no arrows connecting them yet) from my second year project (which had around 40 java classes)..
Perhaps I could put a restriction on the max num of classes in a diagram, as I personally think it makes no sense to draw a UML class diagram with like 40-50 classes because it lacks clarity and the whole purpose of this program is to make visualizing source code easier..
I am therefore considering a limit of say 10-15 classes, would you say this is reasonable ?
Well automatic layouting will be a tough task to cover - as even experienced modelers do have problems in arranging the classes correctly.
I think having a closer look at graph-theory and public implementations of layout algorithms for electronic boards may be a good idea.
Maybe I should get more a little more specific here ;-)
When doing a manual layout, I usually tend to put the root class of an inheritance tree to the top of the diagram and classes that have the most dependencies to the center of it.
Have you thought of patitioning the diagram automatically?
Sometimes you find classes that act as a Facade (cf. Design Patterns, Gamma et al.) to a group of related classes which can be easily put into a sub-diagram. You may open this sub-diagram by double clicking on the Facade class.
Hope this helps a little bit :)))
