For a student project I need to extend a Java project.
The problem is that this project doesn't have a lot of comments and it's hard to analyze it.
I'm searching for something to generate a class diagram and, if possible, a sequence diagram.
I have already tried umbrello (but there are some bugs with big classes) and agilej but the project has a lot of packages and sub-packages and I did not find how to generate the diagram recursively.
Are there other tools to do this?
Thank you in advance.
In Eclipse you have the option to set the package presentation to Flat or Hierarchical. In the flat mode you see the fully qualified name of each package under the src/ folder, and in the hierarchical mode you have to expand to see src/com/mypackage etc. In AgileJ when you are in flat mode (the default mode for Eclipse) then whatever you drag from the package explorer, be it a project, folder, library, Java source file, class or whatever, it will recurse down through the ownership tree and add the classes which it finds as you would expect it to do.
The anomaly you describe in you question - not recursing through the sub-packages - happens when you have the package explorer in hierarchy mode. In this case what happens is that the class diagram just receives notification of a drop of a package - but it has no way of knowing the package presentation mode of the package explorer or even if the drag originated from the package explorer.
So if you really want to recurse down through a hierarchy of packages, and for some reason don't want to multiple select them with the package explorer in flat mode, then the easiest thing to do is switch to the Resource perspective and in the Navigator view find the folder which is the parent of all the packages you want to include then drag that onto the class diagram. That will kick off a recursive search for classes down through the sub-packages.
Please note that if you drag in a large enough number of classes (the exact threshold is configurable) then it will offer to filter them down - for example you might want to filter out unit tests or generated classes. If you try to add a really large number of classes (again, it is configurable, but by default it is 200) then you'll be blocked - but what is the point of a single class diagram with 200 classes on it, it will only result in an unreadable class diagram.
Another eclipse plugin is called 'metrics', which you can find on sourceforge. It can provide a bunch of information about a Java project, both in textual and graphical form.
Related
I want to understand the packing methodology in real big projects.
Suppose we have a package com.abc.xyz, and for this, we really have a path like com/abc/xyz.
Is it possible to have multiple same package names in different directory structure like:
Directory path 1:
/home/user1/project/module1/src/java/com/abc/xyz
Directory path 2:
/home/user1/project/module2/src/java/com/abc/xyz
And finally when we create jar for the whole project, do we create jar with respect to com directory?
When some application uses import com.abc.xyz, how does it know which directory path's package it is referring to?
And finally, is there any good book/resource which gives guidelines about packaging, how to divide project into modules, package names etc.
One more thing, does a project have common package base name like in above case:
com.abc.xyz (e.g., org.apache.hadoop ).
Thanks,
Vipin
Packages created in different source directories are the same package, as far as the classloader is concerned. It also doesn't matter if the class files are in the same jar or different jars. The JVM does not discriminate based on where the source code came from.
(Of course if you have two jars loaded by different classloaders those are going to be treated differently.)
One case where you frequently have different source trees with the same package is when you have tests in a different directory (using the usual Maven convention where the code is under src/main/java and the tests are in src/test/java) but with the same package as the code that they exercise. These tests are able to exercise protected and package-private parts of the code under test, because they're in the same package as that code.
The path of directories inside the jar should start at the root of the package. (The topmost directory should be /, then one called com or org or whatever, etc.) Packages do form a tree-like structure, and when you put your code in a filesystem you end up having a hierarchy of packages, but the language itself doesn't recognize a concept of "subpackage" (except that packages that start with java are special and get special treatment by the classloader).
Organizing code into packages is done differently by different people. Some people like to organize their code by layer (putting all controllers in one package, all services in another package, all daos in still another package), some like to organize their code by feature.
Package-by-layer is the conventional way of organizing code, it seems to be the preferred practice in the Java community. One consequence of this is that when code implements a feature as a vertical slice at right angles to the package structure (as it may require a new controller endpoint, maybe a new service method, etc.), so closely-related bits of code for the same feature end up scattered across different directories. The Java Practices website makes an interesting case for package-by-feature:
Package By Feature Package-by-feature uses packages to reflect
the feature set. It tries to place all items related to a single
feature (and only that feature) into a single directory/package. This
results in packages with high cohesion and high modularity, and with
minimal coupling between packages. Items that work closely together
are placed next to each other. They aren't spread out all over the
application. It's also interesting to note that, in some cases,
deleting a feature can reduce to a single operation - deleting a
directory. (Deletion operations might be thought of as a good test for
maximum modularity: an item has maximum modularity only if it can be
deleted in a single operation.)
Here's an SO question asking about package by feature or layer.
Yes, you could make duplicate packages in separate directories, but I can't think of a good reason to do it. If the classes within the package have the same names you can certainly get namespace collisions. I am not sure what "module" means in this context but I'd recommend
com.abc.module1.xyz
com.abc.module2.xyz
instead. Those would be distinct packages to the classloader. You can still keep your /home/user1/project/module1/ directory structure up front, that doesn't matter.
From 2 modules you will have two seperate jar files: module1.jar and module2.jar. Both will be loaded into ClassLoader when application starts.
When some application uses import com.abc.xyz, how does it know which directory path's package it is referring to?
Classloader will handle that. http://www.javaworld.com/article/2077260/learn-java/the-basics-of-java-class-loaders.html
If you trying to develop multi module application i recommend you to check Maven tool:
http://maven.apache.org/
Why maven? What are the benefits?
For guidance for package organization you can just google 'java packages' phrase.
http://www.tutorialspoint.com/java/java_packages.htm
https://www.facebook.com/Niranthara-Jaya-JavaSocial-Media-Apps-Software-Project-Management-244119296136021/
This page is for people who wish to know how to work with real world Java projects. Send a message to this page and check out the articles.
When my project grows too big, it also get harder to recognize the growing number of classes. I'm looking for a plugin for eclipse, that makes it easier to differentiate the classes by assigning icons or colors to them.
Alternatively I'm looking for any tools, plugins or advice to see through the jumble of classes.
(Currently I'm only using packages for grouping classes)
You should be using packages to the full extent. That means, whenever you find that at least 2 classes in an already existing package share a common aspect, think about moving them into yet another sub package.
Over time, this can lead to quite long package names like org.eclipse.product.addon.technology.ui.someview.listeners. As those are not easy to browse, use the compressed package name display of Eclipse, which allows you to replace any package path by an arbitrary string (only for display in the package explorer). So your very long package names get shortened like here:
I've been working on an Android app in Eclipse, and it's gradually grown in complexity to the point where I find it difficult to locate individual classes in the Package explorer.
Java isn't my strong point, I come from a Visual Studio/C Sharp background, so my first thought was to move logical groups of classes into new packages, a bit like creating a new code folder in Visual Studio.
I created a new package, com.mycompany.myapp.activities and dragged all the Activity.java files into here.
The whole thing went pretty badly, I got tons of import errors, resources failed to build, and so on. The auto refactor tool messed up my Manifest file pretty badly too. It just doesn't seem like it was designed to work that way - I ended up moving them all back, and wasted two hours fixing it.
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them? I'd like to make a folder for 'Data Model', one for 'Activities', one for 'Interfaces' and so on.
How would I go about doing this? Or am I thinking about this the wrong way?
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them?
AFAIK, no. You just need to fix up stuff related to moving your code into packages.
I got tons of import errors
Your app's R.java is generated into your application package (com.mycompany.myapp), and any classes in that same package get R via auto-import. Code residing in other packages needs to import that class (e.g., import com.mycompany.myapp.R). Hence, if you refactor a class from your app's package to a sub-package, you need to add the import.
resources failed to build
That seems unlikely, as resources know nothing about Java packages. However, without any details, it is difficult to provide you with concrete assistance.
The auto refactor tool messed up my Manifest file pretty badly too
You would need to adjust your <activity> elements to ensure they point to the newly-repackaged classes. Ditto for any other components that you repackage (e.g., services). Beyond that, without any details, it is difficult to provide you with concrete assistance.
It just doesn't seem like it was designed to work that way
Certainly, moving activities into other packages is supported. Whether the ADT plugin handles all aspects of it with aplomb is another issue. If you come up with concrete repeatable scenarios where the ADT plugin is not doing the right thing, file an issue at http://b.android.com.
I know that there is the option to have links to source code under your src directory instead of having the source code files directly in your Eclipse project.
When is this case i.e. links for source code is best used?
I always found it more convenient to have the source code inside the Eclipse project
I can think of two possible use cases for this.
The first would be if you want to keep your source and IDE meta-data separate. For example it may be that some developers use Eclipse and some IntelliJ. In this case you would probably only want the source of the project to be stored in SCM, as otherwise, one set of developers are going to have to remove meta-data before importing the project. If they just link to the source, they can maintain there own meta-data for there IDE. Obviously this isn't an issue if everyone uses the same IDE.
The second use case would be dependencies. Say for example your working on two different projects A and B where A depends on B. If your not using a dependency management tool or willing to build and import the Jar from B to A each time you modify it, you could link to the source in B instead.
I'm sure there are plenty of other use cases floating around.
In addition to what Kingamajick mentions, you could have a structure that causes overly long path names.
Windows can only handle so much (256 characters? in older versions), and a deep package structure easily breaks that limit.
So, having your classes in a shallow directory near the top allows you to have your workspaces deeper down, and still leaves some room to wiggle.
Other scenarios; You have source code which is common for several OS:es, but the Eclipse projects are specific for each OS.
You can also create a form of linked resources that are relative to an environment variable. I've used that for situations where the version control system (ClearCase) adds user-specific catalognames.
I have an enum that has two dependencies. These two are in different projects (Im coding in Java). I want to show this dependency ina UML diagram but how can I show what projects these classes are from? (I know for packages you can put it like this: Package :: pkgName).
Any ideas would be helpful. Thanks
What tool are you using?
In Rational Rose, if you this structure:
Folder1
|___Class1
Folder2
|___ClassDiagramX
and the ClassDiagramX shows Class1 then you'll see a small "stereotype" like note indicating "from Folder1" in the box representing Class1.
That should be sufficient.
There are other options using fancy-colorful-notes, but I don't care so much for them.
--edit--
Without knowing the tool I can't really say what you can and can not do. From UML pov, I don't know of any defined convention, so whatever conveys what you wan to can be used. Class diagram is a representation and does not affect the meta-data of the class (e.g. which project it belongs to). So as long as the "class" is in the correct package, it's doesn't matter how it's "shown" in the class diagram.
E.g. in the class-diagram you can put up 2 big squares in the background showing / grouping classes from each project and dependency arrows running across these groups.
OR
"add the line" if that's possible in your tool.
If you use Eclipse and java then you have a feature which allow to join two different projects. I mean open the package explorer and click on the project name then select join, or merge with I don't really remember the exact title of the menu but it is easy to find.
Once your both projects have been joined your can create a class diagram and just drag drop inside the same diagram two classifiers coming from different projects.
Project in the sense of "a set of planned activities and deliverables, with common goal" can not be reasonably encoded in UML.
Project in the sense of "a set of related files and metadata that allows an IDE to compile and run a program" is out of scope for UML, as this is a development environment artifact and not application design artifact.
For example, you can decide to use multiple projects for each module of your app or a single project for all modules. This will not change your design, only the instructions for the IDE - it's even possible that different team members have different project configurations, especially if some use Eclipse, others IntelliJ IDEA and some EMACS.
On the other hand, if you still want to denote logical sets of classes, you do have options - the formal way would be to use tagged values. Alternatively, I often use colors (for example, green for public API, yellow for extension points/SPI and red for implementation classes; or blue for low-latency multicast component, green for guaranteed messaging components).
You may also use a separate component diagram, showing which class belongs to which component (remember not to build uber-diagrams, but instead aim for simplicity and showing only the relevant facets of the design)
This was a generic advice, but the answer you need is very context-specific. I can get more concrete if you can describe in more detail what are the classes in question, what are the projects (how do you delineate between them) and the overall architecture of the system.