Solution finale – UML-Kandinsky
publicité
Disposition graphique de diagrammes sous Open ModelSphere Présentation finale GLO-3002 David Poulin-Gagnon Louis-Vincent Guay Philippe Létourneau Gabriel Roy-Lortie Qu’est-ce qu’Open ModelSphere (OMS)? • Connu auparavant sous le nom de SILVERRUN ModelSphere • Logiciel open source sous licence GPL, mais de plus en plus de ses composants sont sous licence LGPL • Modélisation de tous types de diagrammes UML et de modèles de données • Permet de faire du reverse engineering • Projet dirigé par Grandite • Neosapiens inc., notre client, participe activement à son développement www.ulaval.ca Projet à réaliser • Problématique • OMS ne permet pas de disposer automatique un diagramme de façon acceptable • L’utilisateur doit donc disposer lui-même le diagramme après un reverse engineering avant qu’il ne soit utilisable • Besoin • Un diagramme rapide à lire et à parcourir • Un diagramme facile à comprendre www.ulaval.ca 3 Projet à réaliser • Développer un plugiciel (plugin) de disposition automatique de diagrammes pour le logiciel de modélisation UML OpenModelSphere • Idéalement, le plugiciel doit être sous licence LGPL • Principalement utilisé pour disposer un diagramme après une opération de reverse engineering www.ulaval.ca 4 Objectifs • Implanter un ou plusieurs algorithmes de disposition de diagrammes • Critères des algorithmes • Fonctionner pour les diagrammes de classes et les diagrammes de modélisation relationnelle de données • Être performant et s’exécuter rapidement • Éviter le croisement des arêtes et la superposition des tables/classes • L’espace occupé par un diagramme doit être minimal www.ulaval.ca Contraintes et difficultés du projet • Problème très complexe • La disposition automatique de diagrammes est un problème NP-Complet • Il n’y a pas de solution miracle permettant de disposer tous les diagrammes parfaitement • Les algorithmes avancés sont majoritairement issus de documents et de thèses de doctorat assez complexes • Peu d’implantation • Domaine de recherche très actif en constante évolution • Par conséquent, peu de librairies de disposition graphique sont disponibles • Bien comprendre le problème est essentiel! www.ulaval.ca Architecture logicielle • OMS possède déjà une certaine architecture pour la disposition de diagrammes : • Représentation du diagramme dans l’application à l’aide de métadonnées • Construction d’une abstraction du diagramme (Graph) pour la disposition • Les algorithmes de disposition peuvent alors manipuler les nœuds et les arêtes à l’aide du Graph • Possibilité pour l’utilisateur de choisir les algorithmes de disposition qu’il désire • Seules les métadonnées mises à jour par les algorithmes sont conservées • Le Graph est jeté après chaque disposition www.ulaval.ca Architecture logicielle - suite • L’équipe n’a pas modifié cette architecture • Le type Graph a cependant été modifié et bonifié par l’intégration de la librairie JGraphT • Les algorithmes ont été implantés de telle façon que le comportement de l’application n’a pas été modifié www.ulaval.ca Stratégie de test • Tests d’acceptations • 7 cas de test d’acceptation ont été identifiés en début de projet • Utilisés tout au long du développement pour évaluer l’atteinte des demandes • Tests unitaires • Absence de tests unitaires dans OMS • L’équipe et Neosapiens ont convenu que des tests unitaires seraient un atout pour le développement du plugiciel • Utilisation de JUnit et Mockito • Vérification de la couverture de code avec EclEmma www.ulaval.ca Solutions envisagées • Tentative d’utilisation de la librairie JGraphX pour la disposition • Échec • Les algorithmes disponibles ne fonctionnaient pas bien • L’algorithme de disposition en damier qui motivait l’utilisation de cette librairie n’était finalement pas implanté • Mentionnons au passage que l’architecture de cette librairie était d’une rare médiocrité… • Algorithme de Sugiyama • Algorithme d’Arevalo • Algorithme UML-Kandinsky www.ulaval.ca Solution finale - JGraphT • Intégration de JGraphT pour la représentation d’un Graph • Simplifie la manipulation des nœuds et des arêtes • Les représentations des graphes de cette librairie sont generic • Le type des nœuds et des arêtes est donc indépendant du type de graphe utilisé • Les nœuds n’ont plus besoin de connaitre leurs voisins c’est le Graph qui s’occupe de tout. • Particulièrement utile étant donné que les nœuds et les arêtes étaient déjà définis dans le plugiciel www.ulaval.ca Solution finale - Sugiyama • Bien connu dans le domaine de la disposition de diagrammes • Permet de tracer un graphe avec des arêtes le plus droit possible tout en évitant les croisements • Approprié pour l’héritage des classes puisque le diagramme résultant est dirigé du bas vers le haut • Plusieurs implantations disponibles, mais l’équipe en a développé une sur mesure afin de faciliter l’intégration à OMS www.ulaval.ca Solution finale – Sugiyama (suite) • Algorithme en 4 étapes 1. Retrait des cycles 2. Mise en couche (layering) 3. Ordonnancement des nœuds 4. Assignation des coordonnées • Implémenté avec succès! www.ulaval.ca Solution finale - Arevalo • Compacte les clusters (ensemble de nœuds) ce qui minimise l’espace occupé par le diagramme • Fonctionnement simple • Chaque cluster est délimité par un rectangle • Les rectangles sont emboités de gauche à droite et de haut en bas • L’algorithme permet de définir une marge qui ne sera pas occupée autour de chaque cluster • Utilisé en tandem avec Sugiyama • Implémenté avec succès! www.ulaval.ca Solution finale – UML-Kandinsky • Algorithme conçu par Markus Eiglsperger en 2003 pour la disposition de diagrammes de classes UML • Fonctionne en 3 étapes : 1. Planarisation • Élimine le croisement des arêtes 2. Orthogonalisation • Dispose les nœuds en damier 3. Compaction www.ulaval.ca Solution finale – UML-Kandinsky (suite) • Seule documentation disponible : thèse de doctorat • Très lourd à démarrer • Beaucoup d’heures passées pour comprendre le fonctionnement des diverses étapes • Et à chercher les algorithmes qui n’étaient pas décrits dans la documentation • Seule la planarisation a été complétée • Plusieurs semaines auraient été encore nécessaires pour les 2 autres étapes • Néanmoins une avenue à explorer www.ulaval.ca Solution finale - Bilan des tests • Tests unitaires • Plus de 200 tests • Près de 80% de couverture de code • Tests d’acceptations • 3 dont les attentes ont été réalisées • 3 qui le sont partiellement • 1 qui ne répond pas aux attentes • Le plugiciel est un bon départ même si toutes les attentes des tests d’acceptations n’ont pas été réalisées www.ulaval.ca 17 Démonstration • Une petite démo en direct! www.ulaval.ca 18 Post-mortem - déroulement • Le projet a été divisé en 2 phases 1. 2. Recherche de librairies et d’algorithmes de disposition de diagrammes (State of the arts) Développement du plugiciel : l’implantation des algorithmes • Le développement a été découpé en 3 itérations de 3 semaines chacune • Revue de projet • À la fin de chaque itération • La progression du projet en fonction des tests d’acceptation • L’orientation à prendre pour la prochaine itération www.ulaval.ca Post-mortem – rôle des participants • David : Chargé de projet • Identifier les tâches à accomplir et les distribuer aux membres de l’équipe • Rédiger les revues de projet et la charte de projet • Développement sur Arevalo et la planarisation d’UML-Kandinsky • Gabriel • Implémentation de Sugiyama • Intégration de JGraphT • Développement sur la planarisation d’UMLKandinsky www.ulaval.ca Post-mortem – rôle des participants (suite) • Philippe • Intégration et essai de JGraphX • Javadoc et revue de code • Développement sur l’orthogonalisation de UML-Kandinsky • Louis-Vincent • Rédaction des documents sur la conception • Intégration de JGraphT • Développement sur l’orthogonalisation et la compaction d’UML-Kandinsky www.ulaval.ca Commentaires du client • Très satisfait des résultats • Appréciation de l’inclusion de tests unitaires • La fonctionnalité sera probablement incluse dans la prochaine version de Open ModelSphere • « La qualité des échanges avec les membres de l'équipe était également excellente et me laisse une impression d'avoir travaillé avec des gens professionnels. » Neosapiens www.ulaval.ca Bons coups • Algorithme de Sugiyama et d’Arevalo • Bons résultats vs le temps d’implantation • Code propre et respectant les standards d’OMS • Inclusion de tests unitaires • Bonne tentative de compréhension d’UMLKandinsky malgré la lourdeur de la tâche • Plugin fonctionnel et performant = objectif atteint! www.ulaval.ca Erreurs • L’équipe aurait dû pousser un peu plus les recherches en début de projet • L’implantation de Sugiyama a été faite from scratch alors qu’il existe plusieurs implantations Java LGPL disponibles. • Rien d’autre de majeur à signaler! www.ulaval.ca Conclusion • Questions/commentaires? www.ulaval.ca
