Quand on fait du dév, c'est le 1er réflexe à avoir : documenter, pour soi, et pour les autres qui passeront derrière Et c'est seulement quand on se trouve confronté à une situation comme la tienne, que l'on s'aperçoit de l'importance de cette tâche...
Dans le cadre de mes projets j'utilise TopCased, mais seulement l'éditeur UML, donc je ne peux me prononcer sur java2uml.
J'ai obtenu de bonnes choses avec Bouml http://bouml.free.fr/features_fr.html qui est un outil simple, libre et développé par un Français Il possède notamment des fonctionnalités d'analyse de source http://bouml.free.fr/doc/index_javareverse.html et de reverse http://bouml.free.fr/doc/index_javareverse.html.
Il suffit ensuite de drag&droper les classes/interfaces produites dans l'arborescence par un reverse dans les diagrammes de ton choix : les relations (héritage, dépendance, associations...) se modélisent toutes seules.
Sinon, un coup de l'outil javadoc sur les sources peut produire (si les tags javadoc sont utilisés et les commentaires pertinents) une ébauche de doc de ton projet sous forme html.
Enfin, pour des informations plus poussées on a :
- Checkstyle http://checkstyle.sourceforge.net/index.html pour quantifier le respect du code vis-à-vis de règles standard de développement (conventions de nommage tout au long du code, taille des méthodes, complexité...)
- JDepend http://www.clarkware.com/software/JDepend.html pour analyser le nombre des classes, leur couplage, leur ouverture à modifications, les cycles...
De plus, si c'est un projet d'entreprise de type "classique" (Web + persistence, ou bien J2EE/JEE avec du métier à coup d'EJB, ou encore traitements Batch + bus JMS), il y a fort à parier que des patterns "classique" ont été mis en place : le nommage des packages/classes peut fournir des informations, à mettre en relation avec les blueprints de Sun http://java.sun.com/blueprints/patterns/.
Bon courage.
---------------
"Don't look for a reason, look for a way out" - Cube