ObjectAid : sources Java vers diagrammes de classes

Ceci est mon 100e article ! \o/

Au début de cette année, j’avais passé plusieurs heures à chercher sur Internet un outil permettant de gérer des diagrammes de classes à partir d’un projet Java existant. Il n’y avait pas beaucoup de critères :

  • être gratuit,
  • être simple,
  • s’intégrer dans Eclipse.

J’avais essayé des tas de mots-clés dans Google et je n’avais rien trouvé. Vraiment rien. J’avais essayé quelques usines à gaz d’Eclipse Modeling sans arriver à un résultat concluant. J’avais alors laissé tomber. La semaine passée, j’ai cherché à faire l’inverse : créer des diagrammes de classes pour pouvoir ensuite générer du code Java. J’ai fais une recherche dans Google et le premier résultat était une discussion stackoverflow expliquant comment… générer des diagrammes de classes à partir de sources existantes. Oui, je suis très sérieux.

C’est ainsi que j’ai découvert ObjectAid. Il ne permet pas de créer de diagrammes de classes pour générer ensuite du code ; il analyse le code existant et l’afficher sous forme de diagrammes de classes. Il est disponible via le Marketplace d’Eclipse. En fait, j’ai vu cet outil lors de mes recherches de début d’année mais j’avais crû qu’il n’était pas gratuit. Il existe en effet des licences payantes mais elles donnent accès à des fonctionnalités supplémentaires. Les fonctionnalités de base sont bien gratuites. Voici la description de l’outil donné par le site officiel :

The ObjectAid UML Explorer is an agile and lightweight code visualization tool for the Eclipse IDE. It shows your Java source code and libraries in live UML class and sequence diagrams that automatically update as your code changes.

L’utilisation de l’outil est triviale. Un tutoriel est disponible ici.

Dans le meilleur des mondes, on devrait faire des diagrammes de classes lors de la phase de conception, écrire le code (ou encore mieux : le générer) et continuer à garder une cohérence entre les diagrammes et le code au fur et à mesure que le projet avance et qu’on fait du refactoring ou que l’on repense certains modules. Dans les faits, on ne fait pas souvent les diagrammes de classes originels et on les garde encore moins souvent à jour. ObjectAid ne permet pas de répondre à la première problématique mais répond complètement à la seconde puisque ses diagrammes se mettent à jour quand on modifie les fichiers sources associés.

Je suis bien content d’avoir trouvé cet outil, il sera très pratique pour donner une meilleure vision d’ensemble de bibliothèques ou de projets, en montrant de manière graphique les liens entre les classes. Juste pour l’exemple, j’ai fait un petit projet avec 3 classes, dont 2 implémentent une interface :

objectaid - project

Et voici le diagramme montrant l’interface et les 2 classes d’implémentation (je n’ai pas ajouté la 3e classe au digramme car je suis libre de mettre les classes que je souhaite, je ne suis pas obligé de mettre tout le projet Eclipse !) :

objectaid - diagramme classes

Publicités

4 Réponses

  1. Je suis de moins en moins convaincu par la transformation directe et automatique entre un langage de programmation et UML, dans un sens comme dans l’autre.

    Si un diagramme UML reprend toutes les informations du code Java, et qu’il est suffisant pour générer du code qui marche, alors le diagramme sera aussi compliqué à lire que le code. Inversement, si on conçoit un diagramme pour faire en sorte qu’il soit clair et lisible, il risque fort de manquer d’informations et du coup on poura au mieux générer un squelette de code à compléter/modifier.

    Du coup, si le diagramme n’apporte pas de lisibilité, pourquoi se faire ch*er avec un outil graphique pour rentrer les infos quand ça va 10 fois plus vite d’écrire le code? Il vaut mieux à mon avis passer du temps à bien structurer le code et à le documenter (Javadoc, etc) pour qu’il soit directement facile à lire.

    UML, c’est bien pour gribouiller un truc vite fait sur un coin de tableau pour réfléchir à une solution. Mais après, il vaut mieux avoir un code propre et lisible, si c’est bien fait, ça se passe de documentation.

    Quand il s’agit de reprendre un code existant et qu’on ne s’y retrouve pas, il est dommage de se limiter à une vue statique en UML. Il existe probablement des outils pour faire un truc un peu plus dynamique. Comme souvent, je ne connaît pas trop les outils Java/Eclipse, par contre pour le C je pense à cscope, cscout, ncc, et aussi doxygen qui peut faire des diagrammes plus intéressants que l’UML (call graphs dans les deux directions, etc).

    Ces outils me semblent plus utiles, avec un raisonement plus malin: on part du code source, qui est relativement facile à comprendre aussi bien pour l’humain que pour l’ordinateur. D’un cồté, on a un compilateur qui génère un binaire pour l’ordinateur. De l’autre, on a un compilateur qui génère la documentation pour l’humain. C’est le concept du « litterate programming »: https://fr.wikipedia.org/wiki/Programmation_lettr%C3%A9e

    J'aime

    20 juillet 2015 à 8:54

    • Je suis d’accord que se limiter à quelques diagrammes de classes pour donner à d’autres une vision d’un projet n’est pas bien. Il existe surement des outils faisant ce que tu décris et si j’ai l’occasion de les trouver, je le rajouterai à ma palette.

      En revanche, je ne partage pas ton point de vue sur le reste. Faire de l’UML et faire du code, ce sont deux tâches non antagonistes. Un digramme avec plein de classes montre les liens entre elles, de manière rapide. La javadoc, aussi claire soit elle, ne permet pas cela.

      De même, il ne faut pas confondre conception, documentation et commentaire dans le code. Pour un projet donné, selon son ampleur, il faut ajuster correctement le curseur pour chacun. Une bonne composante ne permet pas de rattraper 2 compostantes pourries.

      J'aime

      21 juillet 2015 à 9:13

  2. De toutes façons, on sait très bien que la documentation et les commentaires ne seront pas tenus à jour. Si on automatise la génération de la doc à partir du code, je ne pense pas que la documentation apporte grand chose (c’est une paraphrase du code). Si on la fait à la main, on aura jamais le temps de la tenir à jour. Et une documentation pas à jour, c’est pire que pas de documentation du tout.

    Alors, on fait quoi? A mon avis, il vaut mieux passer du temps à écrire des tests unitaires. En faisant ça, n’importe qui peut bricoler le code sans savoir comment il marche, et passer les tests pour vérifier qu’il n’a rien cassé. Du coup, ça permet de se lancer dans un refactoring pour que le code reste simple et lisible facilement.

    Sans tests, personne ne va oser aire de gros changements parce que ça risque de casser les choses. Et c’est là qu’on commence à avoir un code plein de rustines qui va être de plus en plus compliqué à comprendre et « fragile » (avec un changement à un bout qui casse un truc complètement de l’autre côté).

    La base de tests, d’une certaine façon, sert aussi de documentation de l’API: elle montre tout ce qu’on peut et ce qu’on ne peut pas faire avec le bout de code testé.

    Si en plus le code n’est pas trop mal architecturé, que les noms des classes et des méthodes sont biens choisis (ne pas hésiter à mettre des noms un peu longs), alors on n’a pas besoin de plus de documentation que ça.

    Et du coup, avec une base de tests solides, on a le droit de se tromper sur la conception parce qu’on peut refactorer plus tard sans trop de risques de tout casser sans s’en rendre compte. C’est là une clé du développement agile, je pense.

    Sinon, on se met dans un mode de développement plus classique, du genre cycle en V. Là, on fait d’abord toute la conception et la documentation, puis on fait le code. Et parfois, on se rend compte en faisant le code que les choix architecturaux ne sont pas forcément les bons, mais c’est trop tard pour changer. Dans ce mode on passe beaucoup de temps à faire de la conception (ce qui énerve beaucoup le management car y’a pas de code qui avance), puis ensuite, si tout se passe bien on peut écrire le code très vite (plus besoin de réfléchir). Mais si on s’est planté dans la conception, il va falloir bricoler pour que ça marche quand même, pas le temps de revenir à l’étape de départ. Et on se retrouve avec du code qui ne correspond pas exactement à ce qu’on a conçu, et donc, pas maintenable. Il n’y a plus qu’à recommencer le cycle en V depuis le début pour le prochain projet…

    J'aime

    21 juillet 2015 à 10:32

  3. Jingl3s

    Bonjour,

    Je viens rajouter du grain à moudre car je souhaite trouver un outil pour faire du reverse engineering pour identifier des aberrations de choix de programmation non visible avec le code source.

    https://dzone.com/articles/reverse-engineer-source-code-u

    Bonne journée,
    Hugo

    J'aime

    21 janvier 2016 à 6:22

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s