VISUAL PARADIGM. E. Partie pratique TRANSFORMATION DE MCD EN MLD ITÉRATIVE. Document version 1

Transcription

1 HEG Arc - Haute école Arc Gestion Travail de Bachelor d'informaticien de gestion VISUAL PARADIGM TRANSFORMATION DE MCD EN MLD ITÉRATIVE E. Document version 1 Créé le : Modifié le : Réalisé par : Informaticien de gestion S adresse à : M. Pierre-André Sunier M. ou Mme l expert-e HEG Arc Neuchâtel (archives) Restitué le : 06 juillet 2012

2 TABLE DES MATIÈRES 1. INTRODUCTION AVANT-PROJET PLANIFICATION ANALYSE DE RISQUES TECHNOLOGIES UTILISEES L UTILITÉ CONCRÈTE DU PLUG-IN LA TRANSFORMATION SANS PLUG-IN Stéréotype «ORM Persistable» Gestion des clés primaires Accent sur les diagrammes Gestion de l incrémentale Généralisation et spécialisation Associations 1-n LA MAITRISE DU PROCESSUS ANALYSE DE L EXISTANT DOCUMENTATION STRUCTURE FONCTIONNEMENT GENERAL STRATEGIE DE RECUPERATION DÉTERMINATION DES CONVENTIONS DE NOMMAGE REGLES DE MODELISATION REGLES DE PROGRAMMATION JAVA DÉFINITION DE L ARCHITECTURE DU PLUG-IN STRUCTURE GENERALE PAQUETAGES ET CLASSES PRINCIPALES MAPPING ENTRE L API ET LE PLUG-IN Utilisation de la spécialisation Lien de composition et implémentation Usage de la composition UTILISATION DE L HERITAGE GESTION DES COLLECTIONS MODELE DE DOMAINE ÉTABLISSEMENT DE LA PROCÉDURE DE TESTS Page - 1 -

3 8. IMPLÉMENTATION DE LA GESTION DES MESSAGES ET LOGS POSSIBILITES D AFFICHAGES DES MESSAGES A L UTILISATEUR Utilisation de la console de Visual Paradigm Autres techniques d interaction SOLUTIONS EXPLOREES POUR L ECRITURE DE LOGS Gestionnaire fourni avec Open API Utilisation du paquetage «util.logging» de Java Utilisation d une librairie externe DEVELOPPEMENT SUR MESURE STRUCTURATION DU RÉFÉRENTIEL FONCTIONNALITES OFFERTES PAR LE LOGICIEL PRISE EN CHARGE DES MODELES PRISE EN CHARGE DES SOUS-SYSTEMES RESTRICTIONS D UTILISATION COMPORTEMENT DU PLUG-IN Objets à transformer Lieu de destination IMPLÉMENTATION DE LA TRANSFORMATION INCRÉMENTALE STOCKAGE DES PROPRIETES D OBJETS Solutions envisagées Solution retenue GESTION DU CHARGEMENT DES OBJETS EN MEMOIRE IMPLEMENTATION DE LA TRANSFORMATION INCREMENTALE DES UIDS RESULTATS OBTENUS ANALYSES PRODUITES FONCTIONNALITES DU PLUG-IN LIVRE Exemple d une entité «Adresse» Exemple d un référentiel DIFFERENCES PAR RAPPORT AUX RESULTATS SOUHAITES ANALYSES ET DÉVELOPPEMENTS FUTURS ADMINISTRATION DU PROJET CONCLUSION PERSONNELLE Page - 2 -

4 1. INTRODUCTION La logique veut que la partie pratique montre la démarche entreprise pour parvenir à l aboutissement du travail. Corollairement, les chapitres sont ordonnés en fonction de la période à laquelle le travail suscité a été réalisé. Le premier introduit le projet en présentant la planification, l analyse de risques ainsi que les technologies utilisées. S ensuit une présentation concrète des raisons pour lesquels le développement d un plug-in pour Visual Paradigm est nécessaire. Étant donné qu une ébauche de plugiciel a été programmée antérieurement, son étude a été incontournable et est expliquée dans le chapitre qui présente l analyse de l existant. La dernière partie mise en place avant de réellement programmer le plugiciel consiste en la détermination des conventions de nommages, car il est bien clair pour moi que cela devait être réalisé en amont. Vient alors les chapitres qui traitent de l implémentation, par un commencement avec une explication détaillée de l architecture logicielle et de la façon de manipuler les objets métiers. Une description du processus qu il est nécessaire d effectuer pour tester chaque méthode est donnée, avant d arriver aux détails d implémentation de la gestion des messages et logs qui ont été, d après moi, un des éléments constituant le socle de base nécessaire au bon développement de l application. Enfin, l analyse des possibilités d implémentation de la gestion d une structure du référentiel telle qu on la souhaite est explicitée et, pour clôturer les notions de programmation, l explication technique de la mise en œuvre de certaines règles de transformation incrémentale se trouve dans un des derniers chapitres. Le rapport pratique se termine avec une présentation des résultats obtenus et notamment des explications sur leurs différences avec ceux qui étaient initialement souhaités, ainsi qu avec un listage des améliorations futures, un détail de l administration du projet mise en place et une conclusion personnelle. Bien que du code de programmation soit quelquefois présenté, le code source n est, généralement, pas expliqué. Un privilège a été donné sur les commentaires qui y sont intégrés, de façon à ce que les explications servent en premier lieu à celui qui le consulte, l utilise ou le complète. Avant de laisser le lecteur débuter la lecture de cette partie, je souhaite notifier qu il est fortement recommandé d avoir lu la partie théorique préalablement pour s assurer d une bonne compréhension des concepts utilisés, qui ne seront pas réexpliqués. Page - 3 -

5 2. AVANT-PROJET 2.1 Planification Les méthodologies de développement agile, axées en premier lieu sur le développement logiciel et qui sont apparues dans les années 1990, nous ont enseigné le besoin de considérer que les tâches se réalisent au travers de toutes les phases du projet, et non durant une seule. Ainsi, le degré d occupation de chacune varie en fonction des différentes étapes. À titre d exemple, la tâche d analyse ne se contente pas d être faite avant l implémentation, mais également au cours de celle-ci, à raison de 20 % peut-être. Le travail de Bachelor consistant en un développement logiciel, il semble pertinent de s adapter à cette philosophie qui sort des habitudes traditionnelles. Ainsi, le séquencement des tâches n existe plus réellement et plusieurs d entre elles s exécutent en parallèle. Dans le tableau de planification ci-après, l abondance d une couleur représente le taux d occupation que je consacre à la tâche. Semaines Initialis ation Apprentissa ge Mise en place de l'infrastructure Analyse et modélis ation Réécriture du plug-in Développ. de la transformation incrémenta le Tes ts unitaires et de recettes Rédaction de la demande de ratification Rédaction des rapports Gestion de projet Finalisation et trans mission des livrables Prérequis à la réalisation du projet Analyse Travail effectif Tests Administration charge de travail Avec une telle pratique, il est bien clair que le positionnement de jalons devient difficile. Les diverses échéances imaginables ne sont pas déterminées précisément et cela reflète bien une réalité où les durées des tâches ne sont pas expressément connues et où il est particulièrement difficile de planifier la construction complète du logiciel. Page - 4 -

6 Dans une méthodologie telle qu Agile UP, les dates telles que je les ai mises ci-dessus ne sont pas indispensables. Néanmoins, dans la pratique, des indicateurs de temps sont souvent demandés, que ce soit sous la forme d une graduation à la semaine ou au mois, ce qui permet d offrir une ligne directrice. Dans mon cas, le choix a été de séquencer hebdomadairement pour être suffisamment précis, sans pour autant être contraignant avec un suivi jour après jour. Bien que cette planification fournisse une aide en donnant une ligne directrice, j ai, de manière tout à fait personnelle, quelques doutes quant à son réel but dans le cadre d une activité comme celle-ci. En considérant que les objectifs et les délais ont été fixés à l avance, il est irrémédiable de devoir la construire de manière à ce que toutes les tâches puissent être placées avant la date d échéance. Si des estimations du temps précises et nécessaires à la réalisation des diverses tâches avaient été effectuées, elles auraient été superflues ; tout au plus auraient-elles permis de se rendre compte que le temps à disposition ne suffisait pas. Cependant, j approuve l utilité d une planification et je la conseille à chacun qui effectue un projet, même dans ces conditions. Dans un cas comme celui-ci, le but n est plus de déterminer la date possible d aboutissement du projet, mais d offrir une vision globale des tâches à réaliser et de leur séquencement. La personne qui travaille maîtrise ainsi mieux ce qu il lui reste à faire et peu, en plus de cela, réagir activement au regard du respect ou non de ce qu elle a planifié. Enfin, notez que le plan effectivement réalisé ne sera pas présenté dans ce rapport, mais le sera lors de la défense orale du travail de Bachelor. En effet, il peut s avérer intéressant de mesurer l écart et de voir si l estimation qui a été faite était réaliste ou non. Page - 5 -

7 2.2 Analyse de risques Le but de ce chapitre est de recueillir les principaux risques qui pourraient entraver l obtention de certains objectifs du projet. Par projet, il est entendu celui qui consiste à réaliser entièrement le plug-in de transformation de MCD en MLD, et non uniquement le présent travail de Bachelor. Cette analyse s axe avant tout sur la prise de conscience des risques et non sur la mise en œuvre effective de mesures permettant de les réduire. L obtention de la liste ci-dessous ne s est pas faite à l aide d outils qui assurent l exhaustivité, car la priorité n a pas été fixée ici. 1. Impossibilité de retrouver les objets du référentiel avec Open API : Parmi les plus grands risques figure celui où il serait purement et simplement impossible de récupérer les objets souhaités dans le référentiel. En effet, il se pourrait qu aucune méthode ne soit fournie pour permettre la récupération d objets de type «Entite», «Attribut» ou encore «Association». Le projet serait ainsi techniquement infaisable. Toutefois, ce risque a été fortement réduit voir supprimé par l implémentation d une ébauche du plug-in par M. Sunier, car celle-ci avait pour but, justement, de vérifier la faisabilité technique. 2. Impossibilité de créer de nouveaux objets dans le référentiel avec Open API : Il se peut que les fonctionnalités de création de nouveaux objets ne soient pas offertes par l API. Par exemple, l on pourrait imaginer qu il soit impossible de créer un nouvel objet «Table» ou, de manière plus pointue, qu on ne puisse pas créer une contrainte de clé primaire étendue sur plusieurs colonnes avec Open API. De façon similaire au risque précédent, celui-ci a été traité lors de la création de l ébauche du plug-in. 3. Une mise à jour de Visual Paradigm ne permet plus la prise en charge de plug-in : Un risque qui pourrait s avérer fatal s il se réalisait serait que l éditeur décide de ne plus accepter la prise en charge de plug-in dans de futures versions de son produit. Cela semble toutefois invraisemblable, car les clients ayant déjà développé des plugiciels seraient purement mis en péril. 4. Le lien entre les objets du MCD et du MLD n est pas correctement gérable : Pour permettre au plug-in de savoir si une table provenant d une entité existe déjà, un lien est nécessaire entre ces deux objets. Il se pourrait qu il en soit de même pour d autres objets, tels que les associations ou les liens de spécialisation. Ces liens entre MCD et MLD peuvent créer des difficultés de gestion. En effet, il faut considérer que, par exemple, l utilisateur final puisse renommer ou supprimer une table, de même qu une entité. L algorithme doit pouvoir maitriser ce genre de situations. Ainsi, il existe bel et bien un risque de ne pas réussir à gérer correctement les liens entre ces deux modèles. Une analyse réalisée préalablement, lors du travail personnel, a permis de réduire quelque peu sa vraisemblance, car une solution qui semble fiable a été apportée. 5. La gestion des multiples modèles n est pas possible : Il est souhaitable que plug-in prenne en charge, au sein d un même projet Visual Paradigm, plusieurs modèles. Plus d informations sur le sujet sont disponibles dans la partie théorique, au chapitre «Multiples modèles». Cela pourrait être irréalisable si, par exemple, il n existe aucun type de conteneur qui pourrait être utilisable dans le contexte de séparation de modèles, ou que ces conteneurs ne peuvent pas être travaillés à l aide de l API. L impact ne serait pas très grave, car la fonctionnalité n est pas essentielle ; elle pourrait être contournée simplement par l utilisation de plusieurs projets. Cependant, sa mise en place apporterait une réelle plus-value. Page - 6 -

8 6. La prise en compte des sous-systèmes n est pas possible : Un système conséquent devrait être séparé en sous-systèmes, de façon à améliorer la lisibilité, la recherche d éléments et la conception. Pour plus d informations quant à la définition et l utilité des sous-systèmes, le lecteur peut parcourir le chapitre «Soussystèmes» de la partie théorique. La prise en compte de cette problématique se réalise à l aide de simples «répertoires» qui doivent permettre d organiser les éléments d un même modèle. Ici, le risque est que, au même titre que pour les multiples modèles, il n existe pas de container adéquat pour la prise en charge des sous-systèmes. En outre, il est également possible qu Open API ne fournisse pas des méthodes pour travailler avec ces répertoires. L impact est, ici également, négligeable vis-à-vis du projet entier, car il ne s agit que d une petite fonctionnalité souhaitée parmi tant d autres. 7. Aucune référence qui définit les règles de transformation itérative et incrémentale n est trouvable : La gestion des règles de la transformation itérative et incrémentale peut devenir très difficile. À titre d exemple, l on peut imaginer que l utilisateur supprime, après qu une transformation automatique ait déjà été effectuée, une association de généralisation entre deux entités déjà existante, et qu il la remplace par une relation «n..n». Comment l algorithme devra-t-il être écrit pour gérer une telle possibilité? Ainsi, la méthode la plus sage est de se baser sur des analyses déjà faites sur ces règles de gestion itératives et incrémentales. Cependant, je n ai pas la certitude qu il est facile d en obtenir. De simples recherches sur Internet m ont fait rendre compte que, effectivement, cela ne semble pas être un sujet souvent abordé. Si le risque se produit, l impact serait alors de nous obliger à redéfinir ces règles, ce qui prendrait un certain temps, et ce qui ne nous assurerait pas, au premier abord, de prendre en considération tous les cas et subtilité qu il peut exister. Toutefois, cela ne remettrait pas en cause le projet en soi, raison pour laquelle je considère l impact comme étant limité. 8. La gestion des attributs en tant qu objets multiplie la quantité de code : L on peut se poser la question de l impact que cela pourrait avoir de devoir gérer chaque attribut d entité en tant qu objet de programmation, ce qui pourrait s avérer nécessaire pour gérer l incrémental. La quantité de code à réaliser pourrait, en effet, augmenter fortement. Cependant, j ai relativement confiance au modèle objet qui devrait me permettre d éviter toute redondance dans le code, et donc, de potentiellement éviter ce risque. La matrice présentée en page suivante s inspire des recommandations présentées dans la méthodologie de gestion des risques EBIOS 1. Elle positionne chaque risque de cette liste en fonction de sa vraisemblance et de sa gravité. Le placement de chacun est effectué en considérant l état des risques au moment où le travail de Bachelor débute. 1 [INT-24] Page - 7 -

9 4. Critique 1. Impossibilité de retrouver les objets 2. Impossibilité de créer de nouveaux objets 3. VP ne permet plus de créer des plug-ins 3. Importante 4. Le lien entre objets du MCD et MLD n est pas correctement gérable Gravité 2. Limité 8. La gestion des attributs multiplie le code 7. Aucune référence qui définit les règles n est trouvable 1. Négligeable 5. La gestion des multiples modèles est impossible 6. La gestion des soussystèmes est impossible 1. Minime 2. Significative 3. Forte 4. Maximale Vraisemblance Dans une gestion des risques complète, tous ceux se trouvant dans les zones rouges et orange devraient être réduits au moyen de mesures, afin d être transposés en zone verte. Dans le cas présent, ce sont des analyses faites durant mon travail de Bachelor, de même que dans de futurs travaux, qui permettent et permettront de vérifier et traiter ces risques. En se concentrant tout de même un peu plus sur les risques en zone rouge, l on voit que trois sont susceptibles de poser problème. De manière plus pragmatique, les risques 1 et 2 pourraient être supprimés, car leur vraisemblance n est pas «Minime», mais plutôt «Inexistante». Finalement, c est surtout le risque portant le numéro 3 qui pourrait faire l objet d une analyse approfondie. Il serait, par exemple, intéressant de consulter le site Internet de Visual Paradigm dans le but de rechercher des informations qui pourraient prouver l importance que l éditeur porte envers Open API ou, tout simplement, prendre contact avec lui, le but étant, bien sûr, de s assurer que le risque ne se produise pas. En l état actuel, les risques ne sont pas traités, mais simplement pris. Page - 8 -

10 2.3 Technologies utilisées Pour mener à bien mon travail, un certain nombre de programmes ou de technologies ont été utilisés. La liste ci-dessous présente chacune d elles. Dans un souci de compréhension des incompatibilités qui pourraient survenir lors de futures mises à jour, les versions sont également indiquées. Java Development Kit u3 Eclipse Java EE IDE for Web Developers, version Helios Service Release 2, build Visual Paradigm Suite 5.2 et librairie OpenAPI de la même version Visual Paradigm For UML 8.2 en édition professionnelle Plugin Eclipse pour disposer du client SVN : o Subversive SVN Connectors o Subversive SVN Team Provider o SVNKit Implementation Moteur de scripts de déploiement Ant Subversion a servi à la programmation en fournissant un client d accès à un serveur de versions. Ant a été utilisé pour améliorer la productivité lors de la réalisation de tests, et sera aussi décrit ultérieurement, au chapitre 6.6. Page - 9 -

11 3. L UTILITÉ CONCRÈTE DU PLUG-IN Le contexte de la partie introduction a déjà suffisamment expliqué l utilité du plug-in. Ici, l accent est placé sur des tests réalisés de manière concrète. Le point suivant montre donc quelques exemples de transformations qui ne correspondent pas à ce que l on souhaite, alors que celui d après détaille plus pragmatiquement les avantages liés à maîtriser le processus de transformation. 3.1 La transformation sans plug-in Cela a clairement été dit, la transformation que Visual Paradigm propose ne convient pas aux besoins de l école, car les règles de modélisation strictes et approuvées ne sont toutes respectées. Les titres suivants en donne quelques exemples réalisés avec la version de l outil qui a été précisée dans les technologies utilisées STEREOTYPE «ORM PERSISTABLE» Le premier élément dérangeant est que toute classe doit être stéréotypée «ORM Persistable» pour qu elle soit transformée. Cela revient un peu au «MCD» qui a été retenu pour le plugiciel, mais il n est pas très éducatif de demander à un étudiant de placer ce premier stéréotype peu significatif sur une entité de modélisation des données pour que la classe soit prise en compte. En effet, il faut tout de même replacer le problème dans son contexte et les cours de modélisation sont déjà données durant la première année du cycle d études, période où les notations UML ne sont pas encore acquises. En outre, le cours «Atelier de Génie Logiciel», qui enseigne Oracle Designer et risque de se pencher davantage sur Visual Paradigm par la suite, se réalise durant la deuxième année où, ici aussi, les élèves peuvent difficilement comprendre le stéréotype qui demande, avant tout, d avoir acquis quelques notions sur le «mapping objetrelationnel» 2. L utilisation de ce stéréotype peut donc rendre les apprenants confus envers ce qu on leur demande de réaliser concrètement dans le cadre d exercices où Visual Paradigm serait utilisé. Figure 1 : Table stéréotypée «ORM Persistable» GESTION DES CLES PRIMAIRES L outil reconnaît le stéréotype «PK» d un attribut et affecte la clé primaire sur la colonne correspondante générée. Par contre, il n est pas capable de transformer une entité associatives convenablement, car il ajoute un identifiant s il elle ne dispose pas d attribut «PK». La règle qui consiste à créer une clé primaire sur les deux colonnes de clé étrangères n est donc pas respectée. En plus de cela, le MCD est modifié dans le but d ajouter les attributs manquants. Il en créer ainsi de nouveaux qui portent le nom ID, ce qui ne correspond pas à ce que l école souhaite, puisque ce dernier devrait être nommé Numero dans ce cas. Par ailleurs, le nom des attributs stéréotypés «PK» n est pas repris pour la génération de la colonne de clé primaire qui se nommera toujours ID. 2 [INT-25] Page

12 Après plusieurs essais, j en ai conclu qu il était possible de définir le nommage des colonnes de clé primaire, et de modifier ID par Numero. L inconvénient est que cela n est malheureusement pas pris en considération pour l ajout de l attribut dans le modèle conceptuel, qui ce amène, au final, à disposer d un attribut ID du côté du modèle conceptuel, qui génère une colonne Numero au niveau logique. Figure 2 : Exemple de transformation d identifiants Comme le montre cette image, le MCD est adapté avant d effectuer la transformation. Si l on se penche sur la transformation de l entité Localite qui dispose d un attribut Numero, l on remarque que la colonne de clé primaire créé porte le nom Numero2. Cela est dû, je suppose, au fait que cet attribut est transformé au préalable et que, de ce fait, le nom est déjà utilisé au moment où l algorithme de transformation souhaite créer la nouvelle colonne de clé primaire. Le comportement général est donc étrange et cela n inspire pas une grande confiance. Selon moi, il pourrait existe mieux en termes de cohérence globale. Page

13 3.1.3 ACCENT SUR LES DIAGRAMMES Pédagogiquement, il s agit bien d un modèle que l on transforme, et non d un diagramme. Bien que l on puisse demander une génération des éléments uniquement montrés dans un diagramme, ce serait, d après moi, une erreur de dire que l on transforme un diagramme. Pourtant, c est bien en se basant uniquement sur les diagrammes que Visual Paradigm opère. Ainsi, une transformation se lance en effectuant un clic droit sur un diagramme et en sélectionnant «Synchronized to Entity Relationship Diagram». La boîte de dialogue suivante apparaît alors : Figure 3 : Une transformation se fait d un diagramme à un autre Concrètement, Visual Paradigm nous demande dans quel nouveau diagramme on souhaite que les tables soient créées. Ce diagramme est alors considéré comme étant la «Master view», et une suppression d une table depuis ce dernier va automatiquement la supprimer du référentiel. Bien que cela puisse servir aux novices ne comprenant pas le concept de modèle, cela est très gênant dans notre cas, voir même mauvais d un point de vue éducatif. Alors que l outil nous propose de créer un nouveau diagramme vers lequel les nouveaux objets du MLD seront placés, il ne se base pas uniquement sur celui qui a été utilisé pour lancer la transformation, mais, étrangement, sur tout le projet. Au final, il n est donc nullement possible de ne transformer qu une partie du projet, et la gestion des multiples modèles et sous-systèmes seraient purement et simplement impraticable GESTION DE L INCREMENTALE S il est un des points que l outil semble gérer convenablement, il s agit de la transformation incrémentale. En admettant que l on renomme une colonne, il va demander, à la prochaine génération, si la colonne doit bien être renommée. Dès que le l on accepte, le nom de l attribut est adapté également. Le cas échéant, le nom de la colonne est bien maintenu, mais l attribut non renommé! C est ce dernier comportement qui est opportun et il semblerait donc que la question posée soit quelque peu erronée : il aurait été préférable de demander si l attribut devait être renommé, et non la colonne. Le fait est que, malgré cette petite erreur, on a la certitude que le lien entre chaque attribut et colonne, de même qu entre chaque entité et table, est conservé. Page

14 Figure 4 : Visual Paradigm demande si la colonne doit être renommée. Il parle, en fait, de l attribut Dans le cas où l on accepte la demande, le nom de l attribut est donc adapté. Cela revient quelque peu à faire du «reverse engineering», ce qui ne poserait pas spécialement de problème, du moment que l on sait comment répondre pour adopter le comportement souhaité. Enfin, à l inverse, c est-à-dire lorsque c est le nom d un attribut qui est manuellement modifié, la question est également posée. Dans un tel cas, la réponse se doit d être toujours à «Yes», étant donné que le modèle généré dépend pleinement du modèle conceptuel. La case à cocher «Don t ask me again» pourrait être utilisé pour éviter à ce que la question soit reposée à chaque utilisation. Concernant l ajout ou la suppression d attributs, tout semble se dérouler correctement selon les règles émises dans la partie théorique. La colonne s ajoute ou se supprime dans la table en conséquence GENERALISATION ET SPECIALISATION Un comportement par défaut est adopté sans possibilité de paramétrage, et il s avère que ce n est pas celui qui a été retenu lors de l analyse des possibilités de transformations d une généralisation-spécialisation dans la partie théorique. Figure 5 : Transformation d entités spécialisées Il opte pour le modèle «Une seule table», mais ajoute une colonne supplémentaire utilisée pour stocker le type d enregistrement réel. Celui qui avait été sélectionné, c est-à-dire «Une table par entité», n est donc pas implémenté ASSOCIATIONS 1-N Un des grands points où Visual Paradigm échoue alors qu il ne devrait pas, c est sur la gestion des associations «1-n». Alors qu il est capable de transformer une table associative, bien que ce ne soit pas effectué de manière tout à fait correcte, il ne créé tout simplement aucune colonne de clé étrangère dans ce cas. Page

15 Figure 6 : Transformation d une association «1-n» Un comportement de la sorte ne serait tout simplement pas acceptable pour être employé dans le cadre d une application en production ou, plus simplement, dans celui de l enseignement de concepts aux étudiants. 3.2 La maîtrise du processus Ainsi, la seule solution envisageable était de développer un plug-in, ce qui nous permet une maîtrise totale du processus. Son avantage découle des exemples cités avant. Ainsi, cela rend possible l adaptation du comportement souhaité en fonction de la politique de l entreprise ou, en l occurrence, de la HEG Arc de Neuchâtel. L on peut ainsi, par exemple, décider soi-même si l on souhaite qu une colonne de clé primaire soit créée dans le cas où aucun attribut de type «PK» n est présent dans une entité. L on peut aussi implémenter le patron de conception approprié qui définit la transformation d une généralisation-spécialisation, de même que la transformation d une pseudo-entité associative 3, par exemple. L écriture d un plug-in permet aussi d apporter la gestion des multiples identifiants naturels pouvant s étendre sur plusieurs attributs, ainsi que de nouvelles fonctionnalités rarement vues dans les AGL (pour ma part), comme la gestion des contraintes inter-associatives, qui fait l objet du travail de Bachelor de M. Sester. Enfin, il est bien clair que l on ne sait pas quels sont les plans de Visual Paradigm quant à l évolution de sa fonctionnalité de synchronisation d un diagramme de classes en ERD. De par le simple fait que cela soit considéré comme une synchronisation met un doute sur la pertinence réelle que pourra amener à terme cette possibilité. Ainsi, utiliser tout de même cela implique un risque énorme quant aux changements pouvant être amenés avec les nouvelles versions. En effet, il ne serait pas jouable de mettre à jour le programme si des règles de transformations se modifient, alors même qu il est utilisé pour maintenir un système en production. Ce problème est évincé grâce à la réalisation du plugiciel, bien que cela apporte d autres risques comme cela a été détaillé dans l analyse de risques. 3 La définition de la pseudo entité associative a été donnée dans le chapitre «5.2 Associations 1-n». Page

16 4. ANALYSE DE L EXISTANT 4.1 Documentation L ébauche du plug-in que M. Sunier avait développée ne m a pas été fournie avec une documentation particulière. Cependant, quelques éléments de concepts globaux sont décrits dans le document «Description du comportement du plug-in HE-Arc de transformation de MCD en MLD» 4. L application n étant pas complète (c est bien la raison pour laquelle on parle d une ébauche), il n existe pas de document descriptif de l architecture logicielle ou de la structure des différentes classes. En outre, la Javadoc n est pas présente. Dans la plupart des cas, il y a donc une absence de commentaires des classes, méthodes et attributs dans le code source. 4.2 Structure Le plugiciel existant se trouve à mi-chemin entre les approches «objet» et «classique». Effectivement, bien que le code ait été, dans un premier temps, réalisé de manière purement procédurale, des classes permettant d identifier des objets ont été créées dans une seconde phase. Le but avait été de transformer la structure pour la rendre «objet». Le travail n a cependant pas été abouti et l ébauche du plugiciel se trouve actuellement entre deux états. Les classes orientées «objet» ont été placées dans le paquetage mcd, qui comprend les sous-paquetages domain et utils. Les autres classes, qui s occupent d exécuter l algorithme de transformation à proprement parlé, se trouvent dans transformmcdprofondeur. Classes orientés programmation «objet» Classes orientés programmation «procédurale» Figure 7 : Distinction des classes de paradigmes différents 4 [INT-26] Page

17 Les méthodes présentes dans les classes orientées «objet» sont composées d un nombre relativement conséquent d instructions, ce qui limite quelque peu les possibilités de maintenance du fait de la difficulté de compréhension que cela engendre. L algorithme propre de transformation se trouve dans les classes orientées «procédurale» qui, bien que n étant qu au nombre de deux, regroupent une partie importante des instructions du plug-in. 4.3 Fonctionnement général Le point de départ se trouve dans la méthode performaction de la classe TransformeMcdActionControleur, qui se charge alors, lui-même, d effectuer l algorithme au niveau global. Au départ, un objet de type MCD est instancié et utilisé pour charger tous les objets nécessaires du projet en mémoire. Ceci va instancier les diverses classes présentes dans le paquetage domain, ce qui donne lieu à de nouveaux objets qui seront utilisés par la suite, durant la réalisation des diverses transformations. Dès lors que cela est fait, la difficulté de l API est masquée, car seuls ces objets nouvellement créés ont vacation à être utilisés. Figure 8 : Représentation de l interfaçage par les classes orientées «objet» Dès lors que tous les éléments du projet Visual Paradigm sont chargés en mémoire, la méthode réalise un algorithme qui transforme les objets du MCD en objets logiques, et ce, dans un ordre approprié, de façon à gérer correctement les dépendances. Le diagramme d activité de la page ci-après, repris rigoureusement du document descriptif de l ébauche de plug-in 5, montre les grandes étapes de cet algorithme. Le principe de fonctionnement repose sur une boucle qui traite tout ce qui n a plus de dépendance envers un objet n ayant pas encore été transformé. Dès lors qu une entité est transformée, elle est «marquée» comme étant traitée et c est alors une nouvelle itération qui se fait. Concrètement, la boucle devrait s arrêter au moment où tout a été transformé. Si l on analyse le code, l on remarque que, en fait, elle s exécute simplement dix fois. Cela n est pas un problème en soi, car le plug-in n était, bien entendu, qu une ébauche. 5 [INT-26] Le diagramme se trouve en page 3 du document. Page

18 Figure 9 : Algorithme de transformation qui tient compte des dépendances Cela assure de n avoir jamais d erreur qui peut survenir à cause d une transformation d entité qui dépend d une autre et dont cette dernière n a pas encore donné lieu en la création d une table. En effet, il est, par exemple, impossible de créer une colonne de clé étrangère qui pointe vers une table non existante 4.4 Stratégie de récupération Dès le début du projet et avec l accord du directeur de travail, il a été définit que le plug-in devait être entièrement réécrit. De par l absence de commentaire et de documentation, mais également du fait que tout n a pas été réalisé selon le paradigme «objet», j ai donc décidé de repartir sur un projet totalement nouveau. Cependant, il n est point question d abandonner le travail conséquent qui a déjà été fait sur le plug-in existant. Tout d abord, les divers concepts et idées mises en place seront repris. À titre d exemple, l algorithme présenté au-dessus ne sera bien entendu pas reconstitué ; le but n est pas de réinventer la roue. Ensuite, le plugiciel représente une source importante d instructions techniques pouvant servir à résoudre un problème. L idée est, par exemple, d aller consulter le code pour déterminer comment une action particulière s effectue avec Open API. En effet, le manque de documentation fournie avec l API oblige fréquemment à rechercher des classes et méthodes soi-même pour parvenir à l action souhaitée. Page

19 5. DÉTERMINATION DES CONVENTIONS DE NOMMAGE L analyse de l existant a permis de partir sur quelques bases nécessaires avant de débuter la programmation. Cependant, à ce stade, il n est pas encore pertinent d amorcer cette dernière avant que des règles de nommages soient définies. Le code ne serait pas forcément conforme d une classe à l autre, la langue de programmation même pas définie et tout devrait, peut-être, être corrigé dans un second temps si des conventions venaient à être faites ultérieurement. Pour cette raison, un travail de fixation des règles m a semblé indispensable. De manière générale, les conventions de nommage facilitent la lecture, quel que soit l objet concerné. Deux axes de règles sont à traiter dans le cadre de ce projet : celles liées à la modélisation et celles de la programmation en Java. Ces premières servent à définir comment l on doit nommer les associations, les contraintes et autres objets de modélisation, pour que le plug-in puisse être implémenté dans leur respect. Ces secondes règles définissent principalement la façon dont le code de programmation doit être écrit. 5.1 Règles de modélisation Le modèle conceptuel de données ne compte pas énormément de conventions, car je n ai pu en déterminer que deux seules. Ce sont, en premier lieu, le nom des entités qui doit toujours être mis au singulier et, en second lieu, la colonne de clé primaire qui doit se nommer «Numero». En plus de ces éléments, l on pourrait citer toutes les pratiques de modélisation, mais ce n est pas le but de ce chapitre. Pour plus d informations quant à cela, je recommande un document de M. Sunier qui introduit très bien les concepts de modélisation 6. Selon moi, il convient de ne pas confondre les conventions de nommages avec les règles d utilisations du plug-in. En effet, ces dernières pourront ultérieurement faire l objet d un document spécifique, servant avant tout à l utilisateur final. Ces règles comporteraient notamment le besoin de spécifier les stéréotypes «MCD», «PK» et «UID», de même que l ajout de valeurs marquées pour permettre la prise en charge du développement itératif et incrémental. Le tableau ci-après détaille les conventions de nommage à utiliser pour la modélisation logique des données. Description Nommage Colonne de clé étrangère <Table-shortname>_Numero Colonne de clé étrangère avec rôle <Table-shortname>_<Destination-role>_Numero Clé primaire PK_<Table-name> Clé étrangère FK_<Source-table-shortname>_<Dest-table-shortname> Clé étrangère avec rôle FK_<Source-table-shortname>_<Dest-role>_<Dest-table-shortname> Contrainte d unicité UK_<Table-shortname>_<Column-name1>{_<Column_namex>} Contrainte de vérification CHK_<Table-shortname>_<Column-name1>{_<Column_namex>} Figure 10 : Règles de nommage des objets du modèle logique de données L utilisation des noms courts sert à prévenir les erreurs liées à la longueur trop importante que pourrait constituer le nom des colonnes ou contraintes. Malgré cela, ce risque, bien que diminué, existe toujours. Des règles de nommages plus sophistiquées, qui prennent en considération la longueur finale des noms obtenus, devront être réalisées par la suite. 6 [INT-27] Page

20 Enfin, citons que, dans tous les cas, les noms des entités, tables, attributs et colonnes doivent être écrits en minuscules, mais commencent par une majuscule. Le non-respect de cette convention n empêche cependant pas le plug-in de fonctionner, mais a l avantage de définir un langage commun entre modélisateurs et développeurs liés à ce projet. Soulignons que l algorithme de transformation repose, évidemment, sur ces conventions pour déterminer les noms des objets à créer. 5.2 Règles de programmation Java Appliquées à la programmation, les conventions de nommage permettent une meilleure lisibilité du code pour qui poursuit ou maintient le développement du travail réalisé. De manière générale, ce sont ici les conventions Java d Oracle anciennement de Sun qui sont employées 7. En dehors de ces règles, d autres sont ajoutées dans le but de délimiter l usage du langage à notre problématique. La première convention concerne la langue. C est l anglais qui est demandé par le directeur de travail, à l exception des termes qui proviennent de la modélisation des données, où le français est privilégié, du fait qu il offre un vocabulaire plus riche. C est aussi pour que les élèves puissent retrouver les termes qu ils ont appris durant leur formation que la langue de Molière est employée dans ce contexte. En effet, il est probable que le plug-in sera maintenu et complété par de futurs travaux d élèves. Enfin, la deuxième convention évoque la façon de commenter le code. Premièrement, chaque classe doit contenir un commentaire descriptif permettant la génération de la Javadoc. Il en est de même pour les différentes méthodes de classes. Si certains attributs s avèrent non explicites, il est recommandé de les documenter également. Ces commentaires doivent expliquer de manière simple et compréhensible ce que réalise la classe ou la méthode, ou ce que représente l attribut. Finalement, les algorithmes difficiles à concevoir ou les instructions peu compréhensibles dans le contexte doivent être rattachés à une explication commentée. 7 [INT-28] Page

21 6. DÉFINITION DE L ARCHITECTURE DU PLUG-IN Le chapitre relativement conséquent de la définition de l architecture décrit cette dernière globalement, présente les paquetages de l application, détaille l analyse des solutions envisagées pour lier les classes de l API avec du plug-in, définit les règles à utiliser pour gérer les collections d objets et, finalement, présente le modèle de domaine ou, autrement dit, les principales classes de la couche métier. 6.1 Structure générale Le choix de repartir d une base propre pour l écriture du plug-in m ouvre les portes et me permet d'opter pour l architecture logicielle qui me semble la plus pertinente. La séparation en différentes couches offre une vue d ensemble qui facilite la compréhension du fonctionnement général de l application. Selon ma vision, trois couches à utiliser peuvent être décernés en ce qui concerne le plugiciel à développer pour Visual Paradigm : la présentation, les services ainsi que le cœur de l application, c est-à-dire le «business» ou, en français, la couche métier. Voici une brève description de ces trois couches : La couche de présentation s occupe essentiellement de l interface graphique et de la logique de navigation entre les différents écrans. Elle peut parfois elle-même être divisée en sous-couches, notamment si l on emploie le pattern «Modèle-Vue-Contrôleur». Cela n est toutefois pas utile dans ce projet, car peu d éléments seront présents dans cette couche. La couche de services permet d offrir des méthodes qui effectuent des enchainements d actions ; ces méthodes sont regroupées par système ou ensembles d éléments ayant attrait à une même problématique. En faisant l analogie avec un salon de coiffure, le salon en lui-même est un service qui offre différentes opérations : la coupe de cheveux, le lavage, le coiffage, la vente de produits, etc. Dans le cadre du développement d un programme de gestion, lors de l analyse des besoins d un client, les différents cas d utilisations ressortis peuvent, par ailleurs, faire l objet d opérations présentes dans un service. Le pattern «Service Layer» de M. Martin Fowler décrit très bien l utilité d employer ce niveau applicatif 8. La couche métier, s axe, quant à elle, sur les objets de bases nécessaires au fonctionnement de l application, respectivement des services. Dans la littérature, l on retrouve fréquemment cette couche sous le nom de «Domain Model», comme c est le cas dans l ouvrage cité précédemment de M. Fowler. Ici, toute la puissance du modèle objet peut être utilisée, car la décomposition des objets permet d atteindre une granularité fine de la représentation du métier. Les notions telles que l héritage ou le polymorphisme peuvent notamment enrichir la sémantique à ce niveau. L architecture que j ai établie avant d amorcer la phase de développement se base donc sur ces trois couches décrites. Des informations complémentaires sont ajoutées dans le diagramme de la page suivante, afin d apporter le détail suffisant et permettre une compréhension de l idée que je souhaite transmettre. 8 [OUVR-01] Page

22 Figure 11 : Représentation des couches applicatives Au niveau de l interface, peu de classes doivent être faites dans le cadre du projet. Les seuls éléments présents dans la couche de présentation sont ceux liés à la mise en place de l action dans la barre de menu de Visual Paradigm, et l appel à la méthode de transformation du modèle via une action. La console, servant à retourner des informations de type texte à l utilisateur, sera utilisée pour informer ce dernier en cas de besoins. Une seule grande méthode occupera la tête de la couche de services. C est elle qui aura la charge d effectuer la transformation du modèle conceptuel en modèle logique. Cependant, il est évident que tout le travail ne lui reviendra pas. Elle va faire appel à plusieurs opérations du même service qui vont lui permettre de transformer des éléments particuliers du modèle. À titre d exemple, il est imaginable de disposer d une méthode qui s occupe spécifiquement de la transformation des entités spécialisées. Enfin, chose que je n ai pas représentée sur le diagramme ci-dessus, diverses méthodes supplémentaires, certainement de type «private», pourront être ajoutées dans cette couche, de manière à séparer les responsabilités et à éviter un nombre d instructions trop important, et donc à maintenir une bonne compréhension du code. Selon les dires d un de nos enseignants, le Dr Belkoniene Abdelkader, la citation suivante s applique également à la programmation : «Diviser pour régner» 9 De par ce principe, dès que cela est possible, je recommande de séparer le code en méthodes, chose que j essayerai au maximum de respecter pour le développement architectural du plug-in. Il n est cependant pas évident de déterminer à l avance lesquelles elles seront, car cela dépend principalement des besoins qui surviennent lors de l implémentation. Pour cette raison, je n émettrai aucun détail supplémentaire sur d éventuelles sous-couches supplémentaires nécessaires à ce niveau-là. La surcouche métier, quant à elle, encapsulera en partie Open API. Elle contiendra les objets non existants dans l API ainsi que de nouvelles classes simplifiées et adaptées spécifiquement à la modélisation des données. Le but est de masquer la complexité de l API au travers d elles, et de permettre l ajout de nouvelles fonctionnalités. 9 [INT-29] Page

23 6.2 Paquetages et classes principales Un diagramme qui représente les paquetages principaux, les relations et dépendances entre ceux-ci ainsi que les classes et méthodes principales me semble être le bon moyen pour offrir une première vision concrète de la structure mise en place. Dans le schéma ci-dessous, l utilisation des stéréotypes UML permet de distinguer les deux paquetages principaux : celui qui contient des classes développées pour le plug-in, estampillé avec «plug-in», et celui fournit avec OpenAPI, affichées «openapi». Figure 12 : Architecture globale montrant les classes et méthodes principales Sur la partie gauche figure le paquetage «racine» présent dans la librairie d Open API. Il contient l interface VPPlugin qui est essentielle, puisque la création d une classe qui l implémente va permettre de définir les éventuelles instructions à effectuer au moment où Visual Paradigm charge le plug-in en mémoire lors de son démarrage. Page

24 Le lancement de traitements, en l occurrence l exécution de la transformation de MCD en MLD dans notre cas, se fait depuis l interface graphique, lors du clic sur un bouton. Chaque bouton lance alors une action dont le comportement est programmé dans la classe McdToMldController, visible sur le diagramme ci-dessus. La couche de services décrite précédemment est mise en œuvre par la création d un paquetage services. De façon générale, chaque service est un Singleton 10. Ce paquetage contient une interface qui définit les méthodes principales du plug-in. Ces cinq méthodes servent à l exécution de la transformation d éléments présents au niveau MCD en objets du MLD. Elles se différencient par l étendue de leur champ d action : l une est prévue pour transformer toutes les entités du projet, l autre uniquement celles d un modèle, la suivante se charge de travailler à l intérieur d un paquetage seulement et les deux dernières s occupent de transformer une seule entité ou toutes celles d un diagramme. Cela permet de prendre en charge ce qui sera analysé dans le chapitre «Structuration du référentiel». La classe McdToMldTransformationImpl se charge de l implémentation de l interface et nécessite de détenir les méthodes spécifiées dans le diagramme pour parvenir à son but. Elles permettent de séparer les grandes étapes de la transformation, qui a été détaillée à la Figure 9 et qui apporte une gestion correcte des dépendances. La raison pour laquelle ces méthodes acceptent en paramètres des objets entites, qui sont des collections d entite, est de rendre ces premières génériques, de façon à ce qu elles soient utilisables par chacune des procédures définies dans l interface McdToMldTransformation. En effet, en passant l ensemble des entités devant être transformées, le champ d action peut ainsi être réduit à souhait, et il devient aisé d effectuer la transformation autant pour un modèle, un répertoire ou encore un diagramme seulement, et ce, sans redondance de code. À titre d exemple, executetransformation(repertoire) ne fait qu appeler consécutivement les méthodes présentes dans la classe d implémentation du service, de façon à ce que l algorithme de gestion des dépendances soit respecté. À chaque fois, l ensemble des entités du répertoire est passé en paramètre, ce qui permet à la méthode de ne transformer que ceux-là. La partie «business» est, de manière générale, utilisée par les services et utilise elle-même le «business» de l API, présent dans le paquetage domain. Le chapitre ci-après analyse plus profondément cet aspect. 10 [OUVR-02] Singleton est un patron de conception très connu et a été proposé déjà lors du commencement de la programmation orienté objet. Page

25 6.3 Mapping entre l API et le plug-in Les classes d Open API, comme IClass, IAttribut, IDBTable ou encore IDBColumn ne disposent pas de toutes les méthodes que nous souhaitons. En effet, le but du plug-in consiste, finalement, à apporter de nouvelles fonctionnalités à ces objets. Par exemple, l on souhaite pouvoir, à partir d une entité, la transformer en une table. Étant donné que nous ne disposons pas du code source, il nous est impossible d ajouter de nouvelles méthodes au sein de ces classes. De nouvelles doivent donc forcément être créées, ce qui implique, en quelque sorte, une redondance des informations : d un côté l API dispose de ses propres classes et, de l autre, le plug-in disposera également de nouvelles classes ayant la même signification. À titre d exemple, une classe nommée Table sera forcément nécessaire, alors qu il en existe pourtant bien une appelée IDBTable dans Open API. La redondance devant être évitée le plus possible, une analyse particulière sur la meilleure façon d effectuer la correspondance ou, autrement dit, le «mapping» entre les classes métiers de l API et celles du plugiciel s avère être la solution la plus sûre. Notons que cette analyse architecturale se porte entièrement sur la couche métier, car toutes les classes devant faire l objet d une correspondance représentent des éléments concrets de la réalité, tels que les entités, les tables, les attributs ou encore les colonnes. Pour cette étude, trois solutions ont été examinées UTILISATION DE LA SPECIALISATION La solution idéale consisterait en l utilisation d un lien de spécialisation-généralisation, réalisable à l aide de l héritage en Java, entre la classe d Open API qui implémente l interface, et notre classe qui souhaite étendre les fonctionnalités par l ajout de méthodes. Par exemple, l on pourrait imaginer qu une classe ClassImpl, qui implémente IClass, soit étendue par Entite. Figure 13 : La spécialisation représente la solution par excellence pour étendre les fonctionnalités d une classe De cette façon, Entite hériterait de toutes les méthodes de IClass et pourrait proposer ses propres ajouts spécifiques au plug-in. Malheureusement, bien que l API s intitule «Open API», aucune classe d implémentation ne semble être accessible par le développeur. Certainement que celles-ci sont embarquées dans Visual Paradigm lui-même et non au sein de cette API. En tous les cas, aucune classe n est listée dans la Javadoc, seules des interfaces le sont. Le parcours au travers des paquetages de l API nous montre également que cette dernière ne contient que des interfaces et, d après mes recherches, aucune mention n est faite sur la documentation en ligne quant au fait de pouvoir accéder aux classes sources. De ce fait, cette solution n est pas réalisable. Page

26 6.3.2 LIEN DE COMPOSITION ET IMPLEMENTATION Les interfaces ne pouvant évidemment pas être étendues par des classes à l aide de liens d héritage en Java, il n est possible d utiliser que des «relations» d implémentation. En procédant ainsi, nous sommes forcés d implémenter toutes les méthodes, chose qui est simplement impossible. Par contre, il est judicieux de placer un attribut de type IClass dans l entité, ce qui permettrait d implémenter les méthodes de manière à ce qu elles agissent comme des passerelles. Figure 14 : Remplacement de la spécialisation par une composition et implémentation Sur cette image, la méthode en rouge n est pas présente dans l interface, et équivaut donc à une extension des fonctionnalités offertes à l origine. Voici ce qu adviendrait, par exemple, de la méthode getname() qui se comporterait comme passerelle : public String getname(){ return this.instanceiclass.getname(); } En essayant de mettre en œuvre cette idée, le problème majeur du lien d implémentation ressort rapidement : ce n est pas moins que 260 méthodes qu il serait nécessaire de traiter de la sorte, uniquement pour la classe Entite. Le travail serait donc long et répétitif. De plus, une évolution des méthodes de IClass obligerait à adapter ces «passerelles». Pour ces raisons, cette solution n est, selon mon analyse personnelle, de loin pas la plus adéquate USAGE DE LA COMPOSITION La solution définitive devient presque évidente, puisqu il suffit, à partir de la précédente, de supprimer le lien d implémentation pour que les inconvénients disparaissent. Figure 15 : Extension des fonctionnalités d une interface à l aide d une composition Page

27 Un avantage intéressant que cette variante apporte réside dans le libre choix des méthodes à proposer au sein de la classe développée. Comme on le voit sur la figure ci-dessus, addport(port:iport) n est pas proposé dans Entite, car cette méthode n a de sens que dans le contexte d utilisation d une réelle classe de programmation, et non d une entité comme nous la considérons dans notre contexte. Ainsi, il devient possible de réduire l utilisation des classes métiers du plug-in au strict usage pour lequel elles ont été prévues. Évidemment, l analyse s est portée uniquement sur le cas «IClass Entite», mais le résultat s applique à l ensemble des objets métiers, dont en voici quelques exemples : Figure 16 : Architecture retenue pour la couche métier Une classe dédiée uniquement à la création d instances a été réalisée. Tout développeur se devra de passer par celle-là afin de garantir son efficacité. Cela reprend la façon de procéder dans Open API. Comme nous l avons vu au travers de IModelElementFactory, des fabriques sont également proposées pour obtenir des instances de classes. L avantage de procéder de la sorte se trouve dans l apport d une non-redondance des instructions de création d objets. L instanciation d une table, par exemple, ne se résume souvent pas uniquement en l instruction new Table(). Il est nécessaire, en plus de cela, d y joindre le nom de la nouvelle table. Au lieu que cette instruction d affectation soit réalisée par le constructeur de la classe Table, elle l est par la fabrique. Cette idéologie fait partie d un patron de conception nommé Factory, que Wikipedia explique relativement bien [INT-30] Page

28 Une problématique importante à soulever ici est celle de la distinction des fabriques qui vont réellement créer de nouveaux objets dans Visual Paradigm, de celles qui ne vont que créer un objet métier du plug-in, en se basant sur un autre qui est déjà existant dans le projet. En effet, pour pouvoir utiliser les méthodes additionnelles d une entité, il sera nécessaire de disposer en mémoire, par exemple, d un objet Entite, et non seulement d un IClass. Ainsi, certaines méthodes de fabrication ne font, finalement, qu encapsuler un objet déjà existant, pour en retourner un nouveau qui correspond, cette fois, à un de ceux qui se situent dans la surcouche métier. J ai qualifié ce genre de méthode de «wrapper». Ainsi, en prenant l exemple de la classe Table, il existe deux méthodes bien distinctes dans la fabrique : createtable(string name) : Se charge de créer réellement une nouvelle table dans le référentiel. wraptable(idbtable) : Se charge d instancier une Table, en y affectant, par voie de composition, une table déjà présente dans Visual Paradigm. L appel des méthodes de type «wrapper» ne vont pas donc créer de nouveaux objets dans le référentiel, alors que les autres, oui. 6.4 Utilisation de l héritage Il existe des méthodes qui s appliquent à plusieurs types d objets comme, par exemple, celles qui permettent de récupérer ou de définir le nom de l objet, ou celle qui retourne son identifiant. Autant une entité, une table, un modèle, un répertoire, un attribut qu une colonne peuvent, par exemple, effectuer ces actions. Cela est normal, car les développeurs d Open API ont maximisé l utilisation de l héritage. L interface IModelElement représente un type d objet générique, qui peut autant être, par exemple, IDBTable que IClass. De par l avantage que l héritage représente, j ai décidé de reproduire le mécanisme, qui peut être expliqué à l aide du diagramme suivant : Figure 17 : Exemple d utilisation de l héritage avec des éléments de modèles génériques Page

29 L attribut qui composait les classes concrètes ne s y trouve plus, mais a été déplacé dans une seule classe générique, appelé ModelisationElement. Dès lors, c est l héritage de cette dernière qui va permettre à toutes les autres de disposer de l attribut IModelElement. Les méthodes getname(), setname() ou encore getid() ne sont plus répétées, mais présentes à un seul endroit. Seulement, disposer d un attribut générique ne permet plus d utiliser les méthodes spécifiques. C est un réel problème, car, pour une entité, l on aimerait bien disposer d une fonction qui, par exemple, lui ajoute un nouvel attribut. Il n existe qu une solution à cela : utiliser le «cast» 12. Pour éviter à ce que chaque appel de l attribut nécessite d effectuer un «cast», le plus simple est d adapter les accesseurs et de les utilisés au sein même de la classe. Voici un exemple d une méthode d ajout d un attribut, qui a besoin d accédé à l attribut de classe de type IClass réel : public void addattribut(attribut attribut){ this.getvpentite().addattribute(attribut.getvpattribut()); } public IClass getvpentite(){ return (IClass) this.vpmodelisationelement ; //cast IModelElement to IClass } public void setvpentite(iclass vpentite){ this.vpmodelisationelement = vpentite ; //no change needed here } Cette façon de faire ne pose pas de problèmes et permet, en définitive, une utilisation efficace de l héritage. 6.5 Gestion des collections Les méthodes qui s appliquent à un objet particulier se situent dans les classes métiers présentées avant. En revanche, il en existe certaines qui doivent s appliquer non pas sur un seul objet, mais sur plusieurs. C est par exemple le cas d une méthode qui transformerait un ensemble d entités en tables. Pour gérer ces situations, il existe trois possibilités différentes. La première est de ne rien prévoir de particulier, et de laisser les développeurs effectuer eux-mêmes des boucles quand cela est nécessaire, de même que les laisser utiliser, à leur guise, des objets de type HashMap. Forcément, cela impliquerait de voir apparaître de la redondance de code, chose que je déconseille quand ça peut être évité. La deuxième solution est de créer des classes utilitaires, qui se chargent de gérer des problématiques particulières. Par exemple, il existerait une classe UtilEntite qui comporterait une méthode de transformation d une collection d entités. Ce genre de classes ne s instancie généralement qu une seule fois, car elle s apparente à un service, bien qu elle fasse tout de même partie de la couche métier de l architecture. Utiliser cette solution ne respecte pas entièrement, selon mon opinion, les principes de la programmation objet. 12 [INT-31] Le cast est une conversion de type, expliqué en bas de la page de cette page Internet. Page

30 Enfin, la troisième solution est de créer de nouvelles classes qui représentent des collections d autres classes métier. L on aurait, par exemple, une classe Entites, qui s instancierait dès que l on détient un ensemble d entités. Cette classe hériterait de HashMap, car elle-même est une collection. Cette solution est celle qui me semble la plus pertinente et c est pourquoi je la retiens. Voici ce qu il advient, concrètement, de la classe Entites : public class Entites extends HashMap<String,Entite> { public Entites(){ super(); } } public void transformtotables(){ for(entite entite : this.values()){ entite.transformtotable(); } } Le choix du type de collection se pose également. Les deux classes en vogue actuellement sont la HashMap pour les collections de types «clé-valeur», et l ArrayList pour les tableaux dynamiques, où chaque valeur est identifiée par sa position. Pour permettre de récupérer un objet spécifique parmi un ensemble, il est donc nécessaire de connaître la clé si la première de ces classes est utilisée, ou la position si c est la seconde. En suspectant que l algorithme de transformation ait besoin, à un moment précis, de récupérer une table parmi toutes celles présentes dans un modèle, par exemple, quel serait alors l élément qui lui permettrait d identifier cette classe? La position dans la collection ne semble pas utile dans ce cas, car le parcours complet de cette dernière est inévitable. Par contre, c est bien l identifiant de la table qui peut être utilisée, toujours nommé id dans les objets de Visual Paradigm. Comme celui-ci est de type String, la clé de la HashMap doit donc également être de type String. Ainsi, pour respecter cette idéologie, toute utilisation d un ensemble d objets métier doit être faite à l aide d une nouvelle classe qui hérite de HashMap et qui a pour clé l identifiant des objets qu il contient. Page

31 6.6 Modèle de domaine Le modèle de domaine est un sous-ensemble de l application qui contient des classes objets servant à représenter la logique métier. Il définit un comportement de programmation à adopter, qui dit que tous les objets s interconnectent entre eux et que chacun d eux représente un «individu» ayant une signification à lui seul. «Domain Model» est un patron de conception de M. Fowler. Il cite : «A Domain Model creates a web of interconnected objets, where each object represents some meaningful individual, whether as large as corporation or as small as a single line on an order form.» 13 Cette manière de concevoir le modèle objet est celle que j ai opté pour implémenter le plug-in. Il faut avouer que, la plupart du temps, ce sont ces principes-là qui sont enseignés et préconisés. Bien que cela provienne de mon analyse personnelle, je dirais que tous les professeurs que j ai eu l occasion d avoir se basent sur ce principe. Si le modèle de domaine réalisé est composé de classes telles que Entite, Table, Attribut ou encore Colonne, c est parce que la logique métier repose, dans le cadre de mon projet, essentiellement sur des objets qui ont attrait à la modélisation. Chaque classe représente donc une chose bien concrète et significative. Finalement, déterminer les classes d un modèle de domaine revient presque à ressortir les entités de modélisation des données d un système. Ce sont avant tout les liens qui diffèrent entre les deux, car la réalisation d un modèle de domaine utilisera les fonctionnalités présentes dans les langages de programmation. Souhaitant limiter au maximum la redondance dans le code source, j ai utilisé au maximum les possibilités offertes par Java. Le diagramme de la page suivante, qui détaille les classes que j ai jugées intéressantes à présenter, montre que j utilise notamment l héritage, comme cela a été dit, de même que l association bidirectionnelle. Si l on observe le diagramme de la Figure 18, l on remarque qu il n y a aucune liaison entre l entité et l attribut, la table et la colonne ou encore la table et la contrainte. Pourtant, une entité est bien composée d attributs, par exemple. En fait, si l on retourne à la Figure 17, il est aisé de voir que, finalement, le lien est bien présent. Seulement, c est l API qui le gère. Depuis le plug-in, les attributs d une classe se récupèrent en faisant appel à la méthode getattributs() de la classe Entite, qui, elle, va ensuite se charger de récupérer les IAttribut de la IClass liée pour finalement utiliser un «wrapper» de la fabrique dans le but de retourner une collection d objets de type Attribut. public Attributs getattributs(){ Attributs attributs = null; Iterator<IAttribute> itvpattributs = getvpentite().attributeiterator(); attributs = Factory.getInstance().wrapAttributs(itVpAttributs); return attributs; } 13 [OUVR-01] Phrase reprise dans l introduction du patron de conception du bouquin référencé, p Page

32 Figure 18 : Représentation des principales classes du modèle de domaine Page

33 Je ne vais pas expliquer chaque élément du diagramme, celui-ci étant, à mon sens, suffisamment parlant en tant que tel. Par contre, je souhaite émettre quelques remarques sur les associations bidirectionnelles. En programmation, une telle association s effectue en réalisant une composition croisée. En reprenant l exemple de l entité, celle-ci détiendrait donc un attribut de type Table, alors que cette dernière détiendrait, à son tour, un attribut de type Entite. C est cela qui permet d atteindre chacun des objets par celui qui est à l opposé de l association. La mise en place de ce mécanisme doit se faire de manière rigoureuse, car il est important de bien affecter les valeurs des deux côtés à la fois, et non d un seul. En l état actuel, la navigation implémentée n est pas bidirectionnelle. Il n est, pour l heure, pas encore possible d obtenir un objet du modèle conceptuel depuis un autre du modèle logique. Bien sûr, cela devra être possible à terme pour, par exemple, permettre le «reverse engineering», qui consiste à récupérer ce qu il existe au niveau logique, pour le remonter dans le modèle conceptuel. Pour conclure avec ce modèle de classes, j émets toute mon attention sur le terme «Contrainte» utilisé pour la table située en haut à droite. Pour mon simple travail, il ne porte pas à confusion, car il ne peut s agir que d une contrainte de table. Par contre, lorsque le plugiciel regroupera les travaux de M. Sester, il existera des contraintes inter-associatives qui, elles, seront déjà spécifiées au niveau conceptuel. Ainsi, il sera nécessaire de réviser les titres des classes en conséquence pour éviter toute confusion. Page

34 7. ÉTABLISSEMENT DE LA PROCÉDURE DE TESTS Dès les premières méthodes écrites, je me suis vite rendu compte de la complexité que cela engendrait d effectuer un simple test. De faire, j ai souhaité la décrire, pour deux raisons. La première est que cela peut servir à quiconque souhaite développer un plug-in pour Visual Paradigm ; il n aurait alors pas besoin d effectuer une série de recherches et pourrait simplement se rendre compte, en lisant ceci, qu il n y a d autres choix que de réaliser le processus que je décris ensuite. La seconde, et certainement la plus importante, est avant tout pour me défendre vis-à-vis du temps de développement que j ai pu consacre pour, parfois, ne réaliser que peu de fonctionnalités. En effet, tester ce qu on programme avec Open API est, en résumé, vraiment contraignant, pour ne pas dire pire. Initialement, il était prévu que des tests unitaires soient réalisés, pour permettre de tester indépendamment chaque méthode. L utilisation de frameworks tel que JUnit 14, qui est pris en charge par Eclipse et Netbeans en standard, aurait facilité les procédures de tests. Toutefois, il est une chose importante que je n avais pas considérée lorsque j effectuais la planification : toutes les méthodes d Open API ne peuvent être exécutées qu au moment où le plug-in est chargé entièrement dans Visual Paradigm. En effet, comment cela se pourrait que l on puisse tester une méthode qui va créer une nouvelle table, en étant uniquement dans l environnement de développement intégré (EDI)? C est techniquement impossible, et l utilisation de tels framworks n est simplement pas envisageable. De fait, tester une méthode nécessite la réalisation de toute une procédure. J ai réalisé le diagramme d activités cidessous afin de comprendre plus concrètement les actions à entreprendre. Figure 19 : Procédure permettant de tester une méthode 14 [INT-32] Page

35 Voici une explication détaillée de chaque activité : 1. En premier lieu, il est essentiel de prévoir un appel de la méthode à tester dans le point d entrée du plug-in, sans quoi elle ne pourrait être lancée depuis Visual Paradigm. 2. Puisque nous n avons aucune maitrise sur les exceptions générées par Java dans l environnement d exécution de Visual Paradigm, il nous est impossible de les récupérer. Cela implique que l on ne peut pas savoir à quel endroit une méthode génère une erreur. La deuxième action à réaliser est alors de placer des repères, qui sont soit des sorties d affichages pour l utilisateur, soit de l écriture de logs. 3. Le plugiciel étant prêt pour effectuer le test de la méthode, il peut être compilé. Fort heureusement, l EDI effectue cette action automatiquement, dès qu une classe modifiée est sauvegardée. 4. Les classes compilées doivent être copiées dans le répertoire «plugins» qui se trouve à l emplacement où Visual Paradigm a été installé. Pour améliorer la productivité et me permettre d outrepasser cette action manuelle, j ai réalisé un script à l aide du moteur de déploiement automatique Ant. Celui-ci peut être réutilisé par toute personne développant un plug-in pour Visual Paradigm, car il permet de copier automatiquement des classes à l endroit souhaité. La personne qui s y intéresse peut le consulter dans les annexes du rapport. 5. Visual Paradigm doit être démarré pour que le plug-in soit chargé en mémoire. 6. En lançant le plug-in, cela va exécuter la méthode à tester si le point 1 a bien été réalisé. 7. En fonction des points de repère placés, la lecture des messages affichés ou des logs va permettre de décerner si la méthode a bien fonctionné, ou si elle s est arrêtée à un endroit particulier. 8. Si le test n a pas abouti, cela signifie qu elle a généré une erreur. Le processus pourra donc recommencer, mais, avant cela, il est nécessaire de quitter Visual Paradigm. En effet, le maintenir ouvert empêcherait le chargement du plug-in mis à jour après que des modifications lui soient apportées. 9. En fonction de l interprétation du résultat du test, la méthode est corrigée de façon à ce que la défaillance soit, en l espérant, supprimée. Ainsi la procédure reprend et de nouveaux points de repère doivent être placés, pour peaufiner la rechercher de la source du problème ou pour vérifier le fonctionnement des corrections. 10. Lorsqu elle fonctionne enfin, la méthode peut se voir retirer les points de repère qui ont permis de discerner les problèmes. Ce que l on peut retenir de cette démarche est que le temps nécessaire à la recherche des bogues est bien plus long que si un framework tel que JUnit avait pu être employé. Alors que, en temps normal, les EDIs nous permettent de trouver rapidement la provenance des erreurs, c est ici tout l inverse et il arrive souvent qu une dizaine d itérations de la procédure décrite ci-dessus soient nécessaires, uniquement pour déterminer la ligne source du problème. Dans la pratique, le développement prend au final rapidement du retard dès qu une méthode implémentée ne fonctionne pas correctement au premier essai. Page

36 8. IMPLÉMENTATION DE LA GESTION DES MESSAGES ET LOGS Une des premières implémentations faites a été celle-ci, qui consistait à prévoir un système fiable pour gérer les exceptions, les messages et les logs. Si j ai souhaité effectuer ceci en amont, c était avant tout pour éviter que le code doive être réadapté au moment où cette gestion serait amenée. De plus, cela permet de fournir des outils pratiques pour celui qui continuera de développer le plug-in. De par l analyse présentée dans la partie théorique, la mise en œuvre d une classe centralisatrice de la gestion des messages, de même qu une gestion des logs permettant de tracer les exceptions survenues lors de l utilisation du programme, s avère nécessaire. Ce chapitre présente, dans l ordre, les solutions envisagées pour gérer les messages, les logs et la solution retenue et implémentée. 8.1 Possibilités d affichages des messages à l utilisateur L API de Visual Paradigm regroupe la gestion des éléments de présentation dans une interface nommée ViewManager, accessible à l aide de cette instruction : ViewManager viewmanager = ApplicationManager.instance().getViewManager(); Elle offre plusieurs méthodes qui permettent d afficher des informations, voir d interagir, avec l utilisateur UTILISATION DE LA CONSOLE DE VISUAL PARADIGM Exemplifié dans l aide en ligne, l affichage direct de messages de type «String» à l utilisateur, fait à l aide de la console présente dans la partie inférieure de la fenêtre de Visual Paradigm, est la méthode la plus classique et simple pour envoyer des messages d information. Figure 20 : Console de Visual Paradigm Il convient peut-être de préciser que la sortie des messages par défaut de Java ne s effectue pas ici. Ainsi, une instruction System.out.print ne donnera pas lieu à l écriture d une ligne dans cette console. Pour ce faire, il est nécessaire d utiliser le gestionnaire de vues : viewmanager.showmessage(string message); Page

37 8.1.2 AUTRES TECHNIQUES D INTERACTION En dehors de l affichage de simples messages, il semblerait que l interface ViewManager offre des possibilités d utilisation de composants SWING et AWT, qui sont deux frameworks permettant de réaliser des interfaces utilisateurs à l aide de Java. Figure 21 : Exemple de l obtention d un composant AWT à partir du ViewManager Si les fonctionnalités permises par ces deux frameworks sont réellement utilisables, les possibilités d interaction avec l utilisateur deviennent infinies. L on peut imaginer invoquer une fenêtre d avertissement lorsqu une erreur survient, afficher en surbrillance les informations importantes, ou encore utiliser des tableaux pour lister les éléments transformés. Cependant, l apprentissage de SWING ou AWT ne se fait pas en quelques heures, et me lancer dans ces aspects qui sortent quelque peu de mon cahier des charges serait, selon mon estimation, une erreur de ma part. Lors de la réalisation d une itération supplémentaire concernant le développement et l amélioration du plug-in, il serait intéressant d effectuer une analyse poussée pour permettre une meilleure intégration de ce dernier au sein de Visual Paradigm. 8.2 Solutions explorées pour l écriture de logs GESTIONNAIRE FOURNI AVEC OPEN API La documentation de Visual Paradigm 15 ne fournit aucune indication sur une solution prévue de gestion des logs. Après diverses recherches dans les classes et paquetages d Open API, il semblerait qu aucune structure n ait été mise en place dans le but de permettre aux développeurs de plugiciel de gérer leurs logs. Pourtant, une zone dédiée semble être mise en place dans l interface d utilisation de Visual Paradigm. Elle est accessible à l aide d un onglet qui remplace l affichage du contenu de la console : Figure 22 : Zone qui semble être dédiée aux logs dans VP 15 [INT-08] Page

38 Il y a trois explications possibles : la première est que cette fonctionnalité est présente dans l outil, mais l API ne permet pas de l utiliser, ce qui est fort crédible en considérant que tous n est pas permis dans un plug-in. La seconde est que la fonctionnalité est en cours d intégration et qu une mise à jour du programme devra permettre de disposer des fonctionnalités nécessaires. Enfin, n omettons pas la possibilité où la fonctionnalité est bien présente, mais je ne parviens pas à la trouver du fait du manque cruel de documentation. Dans tous les cas, il m est impossible de retenir cette solution UTILISATION DU PAQUETAGE «UTIL.LOGGING» DE JAVA Depuis Java 1.4, un gestionnaire de logs est intégré à la Standard Edition. Seulement, il existe un bogue sur la version 7.0, que j utilise dans mon environnement Eclipse. Le problème empêche la suppression de la sortie des logs dans System.out. Concrètement, cela signifie que, même lorsque l on configure le mode d écriture dans des fichiers uniquement, tout est affiché dans la console Java. L effet néfaste est néanmoins atténué dans notre contexte, car ces informations ne s affichent pas dans Visual Paradigm. Cependant, cela reste très dérangeant, car nous ne maîtrisons pas ce que le programme fait de ces messages envoyés à tout va et qui semblent se perdre. Utiliser ce gestionnaire dans ces circonstances serait donc peu louable et nécessiterait un approfondissement de recherche. Enfin, un deuxième argument me mène à la décision de ne pas opter pour cette solution. C est de la difficulté engendrée pour parvenir à configurer une nouvelle sortie de logs, non pas dans des fichiers, mais dans la console de Visual Paradigm. En effet, l avantage de l utilisation d un gestionnaire de logs complet est qu il permet en général et c est le cas ici de gérer, en plus de l écriture dans les fichiers, l écriture dans plusieurs types de sorties, dont la fameuse console Java qui nous pose problème. Ainsi, permettre l ajout d une sortie vers le ViewManager pourrait être délicat, voire impossible. Bien que je ne conserve pas cette variante, il ne s agit pas de l oublier définitivement, mais de suivre les mises à jour de Java pour attendre une correction du bogue, de même que d approfondir la recherche pour paramétrer le gestionnaire de logs de façon à ce qu il puisse être intégré correctement à Visual Paradigm UTILISATION D UNE LIBRAIRIE EXTERNE Plusieurs fournisseurs proposent des librairies abouties de gestion des logs. Une des plus connues est Log4J d Apache. Des essayes m ont permis d arriver à la conclusion qu il est effectivement possible d intégrer de nouvelles libraires qui sont des fichiers d archives ayant pour extension.jar à Visual Paradigm. Pour se faire, il «suffit» de placer lesdits fichiers dans le répertoire «lib» présent à la racine du dossier où l outil a été installé, et d adapter le fichier plugin.xml. Dès ce moment, ils seront chargés lors du démarrage du programme. L inconvénient, bien entendu, est que le démarrage se retrouve alourdi davantage, tant des fonctionnalités même pas soupçonnées sont souvent offertes avec ce genre de librairies. Bien que cela soit infime, je pense que ça a son importance au regard du temps de démarrage déjà nécessaire sans l installation d aucun plugiciel. Enfin, je ne connais pas, à titre personnel, Log4J ou tout autre remplaçant. Pour ces raisons, mon choix ne s est pas non plus porté sur cette option. Page

39 8.3 Développement sur mesure Le choix s est arrêté sur un développement sur mesures. Les avantages sont la maitrise et la personnalisation des comportements, ainsi que la possibilité d apporter une gestion efficace et centralisée des messages et des logs. Le diagramme de classes suivant présente la structure mise en place : Figure 23 : Classes de gestion des messages et des logs L architecture représentée ici prend en charge deux cas d utilisation. Le premier survient lorsque le client (entendons par là une classe Java qui utilise une méthode) souhaite transmettre un message quelconque à l utilisateur du plug-in. Il va alors utiliser la classe MessagesManager. En paramètre est fournie une information additionnelle au message : le niveau d importance. Ce niveau doit être choisi parmi la liste de valeurs présentes dans l énumération 16 WarningLevel, visible ci-dessus. Il va permettre à la méthode showmessage de décider si l importance est suffisante pour que le message soit effectivement envoyé à l utilisateur. Le niveau d importance depuis lequel les messages doivent être affichés est défini dans la propriété WARNING_LEVEL_TO_SHOW du fichier de paramètres plugin.properties. Ce paramètre sera alors chargé au démarrage de Visual Paradigm et affecté à la variable statique portant le même nom. Si cela intéresse le lecteur, j ai mis en annexes une copie de ce fichier. Enfin, la classe WarningLevelManager est simplement employée pour déterminer si un niveau donné est supérieur à un autre. 16 [INT-33] La page Internet montre un exemple simple d utilisation d une énumération en Java. Page

40 Le bénéfice de ce mécanisme réside dans la personnalisation des niveaux d importances. Lors du développement, j utilise, par exemple, un niveau «DEBUG_MODE» pour afficher différentes étapes de mes algorithmes, pour me permettre de vérifier le comportement des instructions faites. Dès lors que le développement est terminé, il suffit alors de modifier la constante à un niveau d importance supérieur, pour que tous les messages d aide au débogage ne s affichent plus. Ce mécanisme est également utilisé pour la gestion des logs, comme le montre le diagramme de classes de la Figure 23. Le concept est identique, à la différence près que la méthode d enregistrement d un log s appuie sur une nouvelle classe créée, qui permet l écriture d un message dans un fichier donné, qui se trouve lui-même dans un répertoire personnalisable. Par défaut, un dossier nommé «logs» se créer à la racine du plug-in, et les fichiers s ajoutent automatiquement dedans, avec le format de nom «aaaa.mm.jj.log». Le choix de créer un fichier par jour a pour but d éviter des erreurs dues à un volume trop important de données dans un seul fichier. Notons que, en cas de besoin, ce format peut être modifié aisément à l aide du fichier plugin.properties. En tous les cas, des logs devraient être supprimés après une longue et forte période d utilisation du programme, de façon à gommer tout risque d erreur. Pour conclure, une classe «maîtresse» a été implémentée afin de permettre le deuxième cas d utilisation, à savoir la déclaration d une exception par le client. Ceci est illustré à l aide d une flèche «use» dans le schéma précédent. Le scénario d usage est le suivant : 1. Le client traite une exception. Il appelle alors la méthode declareexception, en indiquant le niveau d importance. 2. La méthode va se charger de transmettre l information au gestionnaire de messages ainsi qu au gestionnaire de logs. 3. Si le niveau d importance est suffisamment élevé d après le gestionnaire de messages, le message de l exception sera affiché à l utilisateur. 4. De la même façon, si ce niveau est suffisamment haut d après la constante définie dans le gestionnaire de logs, l exception sera «loggée» dans un fichier. De cette façon, tout développeur de l application peut (et doit) utiliser cette classe maîtresse ExceptionsManager pour déclarer ses exceptions. La politique d affichage et de logs est alors centralisée, et personnalisable à souhait. Pour conclure, notons que ces classes de gestion, qui sont postfixées par «Manager», sont des Singleton 17 et sont placées dans le paquetage ch.hegarc.visualparadigm.plugin.mcdmld.utils. 17 [OUVR-02] Page

41 9. STRUCTURATION DU RÉFÉRENTIEL Une des implémentations importantes du projet a été celle qui consistait à prendre en charge les multiples modèles et sous-systèmes au sein d un même projet Visual Paradigm. Alors que ces notions ont été définies dans la partie pratique, ce chapitre se charge d analyser comment elles ont pu être mises en pratique. Il est à noter que le code n est pas présenté, car, finalement, rien d intéressant n est ressorti en dehors des explications faites dans les points qui suivent. 9.1 Fonctionnalités offertes par le logiciel Lors de la création d un nouveau projet à l aide de Visual Paradigm, le navigateur de diagrammes est affiché par défaut. Cependant, il est possible d atteindre l explorateur de modèles qui est, en fait, le référentiel du projet, en cliquant sur l onglet adéquat. Figure 24 : Le navigateur de diagrammes (à gauche) et l explorateur de modèles (à droite) Lorsque l on ajoute des éléments dans un diagramme, les éléments de modèles sont automatiquement créés s ils n existaient pas. Cependant, ils sont placés directement dans le projet et non dans un modèle spécifique. La figure cidessus montre la possibilité d avoir des objets à la racine du projet, au travers des éléments «1-Classe» et «2-Entité». Les classes, que nous utilisons en tant qu entités, sont représentées par, alors que les tables, dénommées «entités» par Visual Paradigm, sont affichées à l aide de. Tous ces objets peuvent être placés dans des modèles ( ) ou des paquetages ( ). Comme on peut le voir, une imbrication de ceux-ci est aussi faisable, avec autant de niveaux que l on souhaite. Cela est surprenant, mais ça reflète bien la liberté offerte par l outil. Page

42 Pour représenter ces possibilités offertes à l aide d un diagramme UML, j ai réalisé le schéma suivant : Figure 25 : Usage possible avec Visual Paradigm L avantage de cette imbrication est de pouvoir structurer le projet de manière à prendre en charge les notions de multiples modèles et de sous-systèmes présentés précédemment. 9.2 Prise en charge des modèles Si l on souhaite pouvoir disposer de plusieurs modèles dans un projet pour représenter, lorsque cela est nécessaire, le système existant, le nouveau à mettre en place et celui qui tient compte des contraintes de réalisation, il est nécessaire de prévoir et de fixer la structure du référentiel à respecter. De manière tout à fait sensée, il est évident que les modèles proposés par Visual Paradigm peuvent être utilisés en tant que «modèles» au sens où je l explique dans la partie théorique. Une vérification à l aide de quelques lignes de code m a permis de considérer qu effectivement, il est possible de gérer les modèles existants, idéaux et réels, en utilisant les éléments «modèles» de Visual Paradigm. Figure 26 : Test des identifiants de deux classes portant le même nom et se trouvant dans des modèles différents Le test montre que les deux classes «Intervenant» visibles dans l image de gauche ci-dessus sont bien différentes, car elles ont des identifiants différents. Néanmoins, l outil autorise l utilisateur à effectuer une action pas très heureuse, qui consiste à créer des associations entre entités de modèles différents. L idéal serait que les modèles soient totalement «étanches» les uns les autres, ce qui n est malheureusement pas le cas. Page

43 Figure 27 : Association réalisée entre entités de modèles différents En partant du postulat que le futur utilisateur maitrisera conceptuellement ce qu il réalise, l emploi des modèles peut tout de même s effectuer dans la mesure où celui-ci disposera des règles à respecter pour assurer le bon fonctionnement du plug-in. Il s agira donc de lui interdire la création de ce genre d associations qui sont, dans notre cas d utilisation, totalement insensées. 9.3 Prise en charge des sous-systèmes La question à se poser ensuite est de savoir si les paquetages peuvent être employés comme répertoires afin d amener la possibilité de séparer les modèles en sous-systèmes au sein de Visual Paradigm. En effectuant le même test que précédemment, mais avec des paquetages en place et lieu des modèles, on se rend compte qu il est tout à fait possible, malheureusement pour nous, de créer deux classes portant le même nom et présents dans deux paquetages différents. Figure 28 : Test des identifiants de deux classes portant le même et se trouvant dans des paquetages différents Les identifiants des deux objets sont différents, ce qui prouve qu il existe bien deux classes «Intervenant» distinctes. Cela n empêche pas de considérer les paquetages comme des répertoires, mais laisse à l utilisateur la possibilité d utiliser l explorateur de modèles de manière incorrecte pour le plug-in. Par contre, à la manière des modèles, il est tout à fait possible de mettre en relation des entités présentes dans des paquetages différents, ce qui est une nécessité ici : Figure 29 : Possibilité d associer des classes se trouvant dans des paquetages différents À condition de mentionner clairement à l utilisateur qu il est interdit de créer des entités représentées par des classes portant le même nom et se trouvant dans un même modèle, l on peut prendre en charge les notions de sous-systèmes au sein du référentiel d un projet Visual Paradigm. Page

44 9.4 Restrictions d utilisation Pour permettre au plug-in de comprendre correctement la structure du projet, il a été décidé que Visual Paradigm devait être utilisé de la manière représentée au moyen du diagramme ci-dessous élaboré par mes soins : Figure 30 : Usage à respecter pour l utilisation du plug-in La prise en charge de plusieurs niveaux de répertoire est assurée. Afin d illustrer la structure définie, la figure ci-dessous présente le référentiel tel qu il pourrait être construit. Figure 31 : Illustration d une structure adéquate du référentiel Page

45 Un projet est constitué de modèles qui sont composés eux-mêmes de répertoires comportant des entités et tables. Dans un répertoire, les éléments des modèles conceptuels et logiques sont réunis. Cela pourrait être évité en créant un niveau de répertoires supplémentaires. 9.5 Comportement du plug-in La transformation du modèle conceptuel donne lieu à la création de tables. Les questions qui se posent sont, en premier lieu, quels sont les objets du MCD qu il faudra transformer et, enfin, où devront se trouver ceux qui ont été transformés, ceci dans le but, bien entendu, de respecter la structure du référentiel défini OBJETS A TRANSFORMER Dans un projet VP conséquent, il est improbable que le concepteur souhaite lancer le processus de transformation sur tous les objets, d autant plus s il dispose de plusieurs modèles. Le point de départ de l algorithme peut se trouver à plusieurs endroits. Chacun d eux a été pris en charge par le plug-in. Dans la barre de menu ou dans la «toolbar» : Dans ce cas, l algorithme s occupe de transformer toutes les entités du projet en tables. Figure 32 : Nouvelle action de menu (à gauche) et nouveau bouton de barre d outils (à droite) Dans le menu contextuel d un modèle : L avantage de disposer de cette option est de pouvoir transformer uniquement le modèle «Réel», ce qui est cohérent, car, généralement, les «Existant» et «Idéal» ne donnent pas lieu à la création d un MLD. L inconvénient majeur réside dans le fait que les actions ne peuvent pas être mises sur les menus contextuels du navigateur de modèles, mais uniquement sur un diagramme. Figure 33 : Menu contextuel depuis le navigateur de modèles Page

46 Par conséquent, il est nécessaire de créer un diagramme de présentation de la structure et d y placer les modèles pour qu ensuite, à l aide d un clic droit sur ceux-ci, l on puisse lancer la transformation de toutes les entités dudit modèle. Cela ne pose pas de problèmes particuliers en soi, et cette solution convient au directeur de travail. Figure 34 : Menu contextuel sur un modèle affiché dans un diagramme Dans le menu contextuel d un répertoire : L idée de n effectuer la génération que sur une partie du modèle, par exemple le domaine «Vente», peut poser des problèmes à l algorithme. En effet, si une entité du répertoire dispose d une nouvelle association vers une autre nouvelle entité, mais que cette dernière n a pas encore été transformée en table, alors la contrainte de clé étrangère ne pourra simplement pas être créée. Néanmoins, pour des raisons diverses, cette solution peut être bien utile si l utilisateur ne souhaite pas disposer de toutes les tables dans son MLD. Par la suite, il conviendra de définir comment gérer les dépendances dans un tel cas. Notons que, ici également, il est nécessaire de poser la représentation d un répertoire (ou d un paquetage, plus spécifiquement) dans un diagramme. Figure 35 : Menu contextuel d un répertoire affiché dans un diagramme Dans le menu contextuel d une entité : Au même titre que pour le répertoire, la génération d une seule entité peut soulever une erreur. Par contre, ici également, l utilisateur pourrait trouver avantage en cette solution. Figure 36 : Menu contextuel d une entité Page

47 Dans le menu contextuel d une zone vide d un diagramme : La dernière solution réalisable propose de placer un bouton qui apparait dans le menu contextuel d une zone de dessin d un diagramme, ce qui a pour effet de sélectionner les propriétés du diagramme. Cela permet de transformer toutes les entités du diagramme, et pourrait être pratique si l utilisateur souhaite personnaliser les objets qu il souhaite déployer sans devoir modifier la structure de son référentiel ; il lui suffirait alors de les définir dans un diagramme. Figure 37 : Menu contextuel d une zone vide d un diagramme Il n y a pas lieu de choisir une solution particulière, mais bien de les combiner. Chacune des solutions citées ayant ses avantages, elles ont toutes été développées et sont fonctionnelles. En réalité, dès que la structure du code a été correctement définie et qu une de ces solutions était faite, il ne restait plus tant d efforts à fournir pour parvenir à l aboutissement des autres. Pour celui qui est intéressé à visualiser la configuration des balises XML nécessaires à la mise en place des éléments graphiques, sachez que qu elles sont décrites dans le fichier plugin.xml fourni en annexes LIEU DE DESTINATION Les différentes actions possibles qui ont été exposées ont permis de déterminer quels étaient les objets qui devaient être transformés. Maintenant, il est nécessaire de déterminer où les objets transformés doivent se placer, tout en sachant que la solution retenue doit respecter les principes de modèles et sous-systèmes décrits dans la partie théorique Solutions envisagées Deux solutions distinctes sont envisageables. La première est de placer chaque table au même endroit que son entité correspondante. L inconvénient est d avoir une structure où les éléments du MCD et du MLD se confondent. La seconde consiste à placer les éléments du modèle logique dans un nouveau répertoire nommé «MLD». Cette solution implique que la structure doit être prévue de manière à séparer les éléments du modèle conceptuel et logique. Pour cette dernière solution, les deux exemples suivants montrent deux structures possibles, l une d elles devant être choisie : Figure 38 : Les répertoires «MCD» et «MLD» sont placés au dernier niveau (solution de gauche) ou avant (solution de droit) Page

48 Le problème d une telle solution est que l utilisateur se voit obligé de respecter les règles qu on lui impose, c est-à-dire soit l arborescence montrée sur la page précédente à gauche, ou soit celle présenté à droite Solution retenue La solution que je retiens est un mix entre les deux variantes : l algorithme va analyser le chemin complet de l objet source et va remplacer chaque répertoire «MCD» trouvé par un nouveau «MLD» pour déterminer le chemin de destination. Les trois exemples ci-après illustrent le comportement du plug-in d après cette solution : Figure 39 : Premier exemple de transformation Figure 40 : Deuxième exemple de transformation Page

49 Figure 41 : Troisième exemple de transformation Comme on peut le voir, cette solution répond à tous les problèmes. En outre, le programme développé gère autant de niveaux de répertoires que nécessaire. Le concepteur ne doit donc en aucun cas restreindre son architecture à cause de l outil. Bien que l implémentation des multiples modèles et sous-système ait pris un certain temps, elle s avérait nécessaire et la réaliser en amont des différents développements de méthodes de transformation apporter un bénéfice indéniable : les objets transformés pouvaient dès lors être placés au bon endroit, ce qui ne requerrait plus d adaptations futures de ces méthodes pour supporter ultérieurement la fonctionnalité. Page

50 10. IMPLÉMENTATION DE LA TRANSFORMATION INCRÉMENTALE L implémentation des règles élémentaires de transformation n est pas spécifiquement décrite dans un chapitre, car aucune particularité n a dû être réalisée pour parvenir au but. En effet, je privilégie les commentaires dans le code même plutôt qu une documentation externe. Par contre, il existe des notions travaillées de manière approfondie pour réussir à mettre en œuvre les éléments théoriques de la transformation incrémentale. Ce chapitre a pour but de les décrire Stockage des propriétés d objets La première spécificité qui a nécessité une analyse particulière est celle qui consistait à trouver une solution permettant d implémenter la solution de liaison des objets du MCD avec ceux du MLD, comme cela a été décrit dans le chapitre «Liaison entre MCD et MLD» de la partie théorique. Ce chapitre a mis en avant le besoin de stocker les identifiants des objets du niveau conceptuel des données. Ainsi, la recherche s axe sur une solution permettant de stocker des propriétés sur des objets tels que des entités ou des attributs. Il est à relever qu une partie de cette recherche a été effectuée durant le travail personnel qui précédait la thèse de Bachelor. En effet, un module d une durée trois semaines avait été réalisé, et servait à prémâcher le projet conséquent qui allait venir, à savoir le présent travail SOLUTIONS ENVISAGEES Utilisation de stéréotypes Un stéréotype permet d'ajouter une information supplémentaire à l'élément sur lequel il s'applique. Il est visible sur le diagramme, et est placé entre guillemets. Ils peuvent s appliquer sur à peu près tous les objets du diagramme, que ce soit les classes, les attributs ou les associations. Les mentions «MCD», «PK» ou «UID» en sont des exemples. Il serait difficilement possible d utiliser cette notion pour stocker les valeurs que nous souhaitons. En effet, ce que nous souhaitons est avant tout une relation «clé-valeur», où la clé serait «tablename» et où la valeur serait «Clients» par exemple. Par ailleurs, nous ne voulons pas forcément que ces valeurs soient visibles sur le diagramme. Par conséquent, il n est pas probant de retenir cette solution Utilisation de valeurs marquées Les valeurs marquées, provenant de la traduction de «Tagged Values», offrent cette possibilité de disposer d associations «clé-valeur». Dans l outil, un onglet permet de définir autant d entrées que nécessaire. Figure 42 : Liste des valeurs marquées d un objet dans Visual Paradigm Page

51 Par ailleurs, ces valeurs ne seront pas visibles sur le diagramme, ce qui répond parfaitement à notre besoin. Cette solution semble donc convaincante. Tester cette possibilité à l aide d Open API m a rapidement permis de vérifier sa faisabilité. Cependant, deux inconvénients sont tout de même à signaler. Le premier est que ces valeurs ne peuvent pas être placées sur tous les objets souhaités. Les contraintes de tables, par exemple, ne les acceptent point. Le second est que l utilisateur pourrait modifier la valeur d un identifiant, ce qui pourrait provoquer des effets de bords néfastes à l intégrité du modèle logique généré. Effectivement, modifier une telle valeur revient à changer la valeur d une clé étrangère, chose que les contraintes d intégrité empêchent dans les bases de données. En considérant que l utilisateur du plug-in maîtrise parfaitement la modélisation des données, cet empêchement n est pas un problème. Par curiosité, j ai tout de même effectué une petite recherche qui aurait pu me permettre de trouver la solution idéale. Celle-ci est décrite au point ci-après Recherche de propriétés d objets cachés Il arrive souvent que, dans diverses situations de programmation, une collection de propriétés permette de personnaliser les données d un objet. Par exemple, l utilisation de la technologie des Servlets en Java, qui s occupe de la création d interfaces web, offre une telle possibilité sur la session d un client 18. Le programmeur peut alors, autant qu il le souhaite, ajouter des couples «clé-valeur» pour personnaliser et conserver des données propres à chaque client HTTP. L on retrouve fréquemment cette manière de procéder dès qu il s agit d utiliser un contexte. Les API de Java JPA 19 et JSF 20 offrent l accès à un contexte qui permet à toute classe de programmation développée d y stocker de l information commune et de la partager, à l aide de couples «clé-valeur» toujours. Ainsi, je me suis demandé si les développeurs d Open API avaient prévu une telle possibilité, ce qui pourrait s avérer tout à fait plausible, car, appliqué aux objets de type IModelElement, cela permettrait à chacun des héritiers d être extensible. Si telle était le cas, les entités, tables, attributs, colonnes et autres types disposeraient de cette collection de propriétés que je recherchais. Cela sort donc clairement du cadre des spécifications UML, mais le problème d un utilisateur qui pourrait modifier la valeur marquée serait alors réglé, car les identifiants ne seraient plus visibles ni accessibles. Malheureusement, après avoir parcouru l ensemble des méthodes appelables sur un objet de cette classe, de même que celles appelables sur une entité, j en conclu que l idée est techniquement irréalisable, aucune ne semblant proposer cette possibilité. Il n existe donc aucun moyen de disposer d un couple «clé-valeur» caché sur les objets de Visual Paradigm, ce qui anéantit l espoir que j avais dans ma courte recherche d une solution alternative. 18 [INT-34] La documentation Java montre que la classe «HttpSession» permet la création et la consultation d attributs, à l aide des méthodes «getattribute(name)» et «setattribute(name, value)». 19 JPA est une API qui standardise la création d un framework de gestion du mapping objet-relationnel. 20 JSF est une API qui standardise la création d un framework de création de pages web. Page

52 Utilisation des commentaires Il existe une autre propriété qui permet le stockage d informations. Il s agit des commentaires. Son net avantage est qu il est employable par, à peu près, tous les types d objets de Visual Paradigm. À l inverse, il a l inconvénient de ne pas pouvoir être recherché en fonction de sa clé. Un parcourt de l ensemble est donc nécessaire si l on en recherche un qui porte un nom particulier. En outre, il ne dispose pas d une simple valeur, mais d un contenu entier pouvant même être au format HTML, ce qui semble un peu trop pour notre utilisation. Cela ne limiterait toutefois pas son usage. Figure 43 : Liste de commentaires sur une contrainte unique Utilisation d un fichier XML En dehors des standards proposés par UML, j ai porté ma réflexion sur l utilisation d un fichier XML. L idée serait de définir une structure pouvant ressembler à ceci : <mapping mcddiagramname="gestionprojetsmcd" mlddiagramname="gestionprojetsmld"> <entity> <name>client</name> <table-name>clients</table-name> <short-name>cli</short-name> </entity> [ ] </mapping> De cette manière, les valeurs ne seraient plus présentes dans l objet lui-même, mais déportées dans un document externe. Trois inconvénients majeurs ressortent ici : en premier lieu, l utilisateur ne peut pas saisir ces données depuis Visual Paradigm, mais doit avoir recours à un éditeur de texte. Ensuite, il est évident qu il doit maitriser XML. Enfin, le principal inconvénient réside dans le fait d avoir les valeurs en dehors du référentiel. Pour contourner ce dernier problème, il serait nécessaire de sauvegarder le document XML au même emplacement que le projet, dans le l espace de travail, dit «workspace». Cela complique le développement et peut, par la suite, rendre la maintenance plus difficile Remarques sur les profils UML définit la possibilité d utiliser des profils. Ils ne permettent pas d étendre davantage le langage, mais, à contrario, de réduire le champ d action et les possibilités offertes à celui qui modélise. À titre d exemple, on peut imaginer que seuls les stéréotypes «PK», «UID» et «MCD» soient autorisés pour la conception d un modèle conceptuel de données, de même qu interdire l emploi des objets inutiles comme les liens d agrégation ou de composition. La notion est ainsi très intéressante, mais n a plus de réel lien avec le présent projet. Page

53 SOLUTION RETENUE La solution la plus probante est l utilisation des valeurs marquées, autant proposée par UML que supportée par Visual Paradigm. Cette solution permet de définir facilement des ensembles «clé-valeur» sans que ce soit visible directement sur le diagramme. L avantage est que les données sont stockées directement au sein du modèle, et sont donc présentes dans le référentiel. Ses seuls inconvénients résident dans la liberté laissée à l utilisateur quant à la modification des valeurs stockées, et à l impossibilité de l utiliser sur certains objets. Pour ce dernier problème, ce sera l utilisation des commentaires que je privilégie. En ce qui concerne le premier problème cité, il ne faut pas perdre de vue que la personne est sensée maîtriser l outil qu elle utilise ; aucune erreur grave ne devrait donc être soulevée par cet inconvénient mineur. Au besoin, des règles strictes d utilisation du plug-in devraient permettre d avertir l utilisateur sur les incidences que cela a de modifier les références d identifiants présents dans les valeurs marquées Gestion du chargement des objets en mémoire Ce sous-chapitre tient lieu d une préanalyse effectuée quant à la gestion du chargement des objets en mémoire. En effet, je me suis retrouvé confronté à une situation où je souhaitais disposer de la table générée à partir d une entité, ce qui n était pas possible en tant que tel, car cette table n était pas encore chargée en mémoire, mais bien présente dans Visual Paradigm. Pour disposer des objets nécessaires en mémoire, il existe, selon moi, deux stratégies : la première consiste à charger tous les objets dès le démarrage, alors que la seconde suggère un chargement des objets dès que l on en a besoin. Cette dernière philosophie est un patron de conception nommé «Lazy Loading» 21. C est elle que j ai utilisée pour la récupération d une table depuis une entité ainsi que d une colonne depuis un attribut. Le principe est d aller rechercher, dans le référentiel, les objets lors de l appel à l accesseur Get(). Ci-dessous se trouve la méthode de récupération d une table générée depuis la classe Entite. public Table getgeneratedtable(){ if(this.generatedtable == null){ String idtable = this.gettaggedvalue(table.tagged_value_id_name); this.generatedtable = Projet.getInstance().getTableById(idTable); //loading } return this.generatedtable; } La méthode permet de s assurer que, lorsque l accesseur retourne la valeur null, mon objet n existe réellement pas, et que ce n est pas uniquement parce qu il n a pas été récupéré depuis le référentiel. Notons toutefois qu un chargement complet des objets en mémoire fonctionnerait tout aussi bien et que, pour gérer les dépendances et les associations, cette considération devra certainement être reconsidérée par la suite. 21 [INT-35] Page

54 10.3 Implémentation de la transformation incrémentale des UIDs Pour en conclure avec les spécialités qui ont été requises pour l implémentation des règles incrémentales, ce point présente, au travers du diagramme d activité ci-dessous, la démarche de la méthode s occupant de transformer les identifiants naturels. Figure 44 : Algorithme de gestion de la transformation incrémentale des UIDs d une entité Le test, présent sur le diagramme, détermine s il existe une contrainte dans la table, qui comporte exactement les mêmes colonnes que celles qui seraient générées à partir des attributs de la nouvelle contrainte qui serait créée. Cette technique qui a pour but de savoir si une contrainte existe déjà a été expliquée dans le rapport théorique. Pour réaliser un tel test, il a été nécessaire d effectuer deux boucles imbriquées : Une première parcourant toutes les contraintes déjà présentes dans la table Une seconde qui vérifie si chaque colonne de la contrainte nouvellement créée existe dans celle qui est en train d être parcourue et qui existe déjà dans la table Un problème rencontré pour mettre en place cet algorithme a été de parvenir à placer un marqueur sur les contraintes, car, malheureusement, il est impossible de leur affecter des valeurs marquées. Ici, je n ai donc eu d autre choix que d opter pour une alternative. D après les possibilités analysées, j avais cité celle qui consistait à placer un commentaire. C est cette possibilité qui m a permis d aboutir à la solution, car les contraintes peuvent en être dotées. En dehors de cette solution, j ai envisagé l utilisation d un stéréotype. En effet, il n y a nul besoin de disposer d un couple «clévaleur» dans ce cas, car seuls les mots-clés «autogenerated» et «required» devraient être spécifiés. Seulement, cette option est également impossible, car Visual Paradigm ne permet pas d apposer un stéréotype sur une contrainte. Page

55 11. RESULTATS OBTENUS Alors que les éléments importants du développement ont été décrits, et avant d exposer les améliorations futures à apporter, ce chapitre présente les résultats obtenus. Au premier point se trouve un résumé des diverses analyses produites. S ensuite une présentation de ce que réalise, en l état, le plug-in. Enfin, une partie essentielle, qui consiste à montrer et motiver la différence entre ce qui était initialement prévu et ce qui a été effectivement réalisé conclue ce chapitre Analyses produites Le fruit du travail ne se résume pas uniquement au plug-in développé. En effet, les analyses font aussi partie des résultats. Étant donné que les rapports théorique et pratique représentent, finalement, ces analyses, elles ne sont pas réexpliquées ici, mais simplement listées. Les points suivants résument donc les éléments analysés : Recensement de risques pouvant empêcher l obtention d un plug-in qui couvre tous les besoins que le mandant souhaite couvrir à terme Définition exhaustive des règles élémentaires de transformation d un MCD et MLD Définition des prérequis pour l implémentation des règles de transformation incrémentales. Ce point sousentendu l analyse du besoin des liens entre objets du MCD et MLD, et la recherche de solutions dans Visual Paradigm. Définition des règles de transformation incrémentales pour l entité, les attributs, les types d attributs, les clés primaires, les colonnes non nulles et les identifiants naturels Comportement de la transformation avec Visual Paradigm, sans plug-in Fonctionnement général d Open API Marche à suivre pour tester une méthode développée, à l aide d un diagramme d activités Façon de gérer efficacement les erreurs, avec notamment la gestion des exceptions, des logs et des sorties d écran pour l utilisateur Prise en charge des multiples modèles et sous-systèmes avec Visual Paradigm 11.2 Fonctionnalités du plug-in livré Il est bien clair que tout n a pas été implémenté, car, comme cela avait été dit dans le contexte général de la partie d introduction, le projet avait pour but d amener de nouvelles fonctionnalités de façon itérative, sans pour autant définir des objectifs à respecter à tout prix. Quelques fonctionnalités du plug-in seront présentées ici, de façon plutôt pratique, à l aide de captures d écran. Il est à noter que de simples exemples ne suffisent pas à exposer entièrement le comportement du plug-in. Le seul moyen de vérifier cela est d effectuer des tests pratiques, en l installant. Pour qui cela intéresse, j ai réalisé un document nommé «Procédure d installation du plug-in», qui se trouve en annexes. En plus de celui-ci, un autre document réalisé est présent. Il est utile à celui qui souhaite importer le code source dans Eclipse, et se nomme «Procédure de chargement du code source dans l EDI». Page

56 Avant de présenter les exemples concrets de transformations avec le plug-in, je tiens à préciser que, du moment qu une analyse a donné lieu à une implémentation, cette dernière a été réalisée entièrement. Par exemple, si la transformation de la multiplicité d un attribut est développée, alors elle respecte et se comporte comme ce qui a été analysé dans le rapport. Les illustrations sont faites au travers de deux exemples. Le premier se concentre sur une seule entité, alors que le second montre plutôt la structure d un référentiel EXEMPLE D UNE ENTITE «ADRESSE» Une entité Adresse est créée selon sa représentation ci-dessous. Bien que cela ne soit pas visible ici, la valeur de la multiplicité de l attribut IsValided a été placée à 1. Enfin, deux valeurs marquées ont été ajoutées à l entité : «tablename», avec la valeur «Adresses», ainsi que «shortname», qui contient «Adr». La transformation donne lieu à la création de la table ci-dessous à droite. Figure 45 : Exemple de la transformation d une entité «Adresse» Si l on consulte les propriétés de la table, l on voit que deux contraintes uniques ont été ajoutées en fonction de «UID-1» et «UID-2», selon les règles de nomenclature définies. Figure 46 : Les contraintes uniques ont été ajoutées Pour réaliser la transformation, j ai configuré les propriétés du fichier plugin.properties de façon à ce que la sortie d affichage des messages soit mise à DETAILS, ce qui a pour effet d afficher les actions réalisées au niveau des attributs, en plus de ceux du niveau de l entité si cette propriété était maintenu à INFO. Ainsi, la console de Visual Paradigm affiche le texte présenté en page suivante lorsque l entité a été transformée. Page

57 Figure 47 : Messages affichés à l utilisateur lorsqu il transforme une entité Pour tester la transformation incrémentale, il convient d effectuer des modifications sur l entité et la table. En premier lieu, un nouvel attribut Etage est créé, avec une multiplicité non spécifiée. L identifiant naturel «UID-2» est retiré de l attribut Localite. Sur la table, les types ont été adaptés, la colonne Npa a été renommée en NumPost et une nouvelle NbHabitant a été ajoutée. Voici l état actuel des deux objets avant la transformation : Figure 48 : Modifications apportées au niveau conceptuel et logique En plus de cela, les deux contraintes uniques ont été renommées, et une nouvelle a été adjointe à la table. Figure 49 : Renommage des deux contraintes et ajout d une nouvelle sur la table Page

58 Un second lancement de la transformation à partir de l entité ne provoque pas la création d une nouvelle table, mais adapte celle qui existe déjà. Le nouvel état de la table après transformation est le suivant : Nouvel état de la table après une transformation incrémentale Comme on le remarque, les spécifications faites précédemment dans la table n ont pas été écrasées. Le nom et le type des colonnes sont maintenus, la colonne ajoutée manuellement n est pas supprimée alors que le nouvel attribut a provoqué la création d une nouvelle colonne qui porte le nom de Etage. Une vérification des contraintes permet de voir que le renommage des contraintes a été maintenu, mais que, la contrainte qui était auparavant portée sur les champs Localite et Rue n existe plus. À la place, une nouvelle a été ajoutée et nommée «UK_Adr_rue». Figure 50 : Le nom des contraintes ainsi que celles ajoutées manuellement sont maintenus Enfin, la console de Visual Paradigm nous fait part des nouvelles transformations faites. L on voit que la nouvelle colonne a été créée, et que l ancienne contrainte supprimée, pour faire place à sa remplaçante. Figure 51 : Messages affichés à l utilisateur lorsqu il effectue une transformation et que des objets du MLD existaient déjà Page

59 EXEMPLE D UN REFERENTIEL Toutes les actions permettant de lancer la transformation à partir du projet entier, d un modèle, d un répertoire, d un diagramme et d une entité ont été implémentées de la façon décrite dans le chapitre Ainsi, cet exemple ne présente pas à nouveau ces différentes possibilités, mais se restreint à effectuer une transformation d un projet complet. L image ci-dessous représente l état du référentiel initial, et son état après transformation. Figure 52 : Exemple de transformation d un référentiel entier Toutes les entités ont été transformées et mises au bon emplacement d après la solution retenue lors de l analyse des possibilités de prises en charge des multiples modèles et sous-systèmes. Comme on le voit, chaque chemin est analysé et la table générée est placée de façon à ce qu elle respecte le même chemin, mais en remplaçant «MCD» par «MLD». Notons que les valeurs «MCD» et «MLD» sont configurables dans le fichier plugin.propertires. Page

60 11.3 Différences par rapport aux résultats souhaités Tout d abord, il paraît important de rappeler que la demande de ratification définissait les objectifs du travail, mais précisait que les fonctionnalités devaient venir de façon itérative et qu il en serait fait autant que possible. Étant donné que les éléments réalisés viennent d être présentés, je me concentre, ici, uniquement sur ceux qui n ont pas été faits. Parmi les analyses ou implémentations qui pouvaient être faites, certaines ont volontairement été omises, de façon à mettre un accent plus fort sur les choses prioritaires. D autres n ont simplement pas pu être réalisées pour cause de manque de temps, ce qui est dû à de nouvelles demandes, tâches ou embûches apparues en cours de projet. Le grand point qui n a pas été réalisé est celui de la transformation des associations et liens de généralisationspécialisation. Ainsi, bien que la structure ait été prévue dans le code source, l algorithme de gestion des dépendances n est pas en place, et le plug-in est incapable, actuellement, de transformer des liens entre tables. L autre point, mais qui était optionnel et, de manière prévisible, non réalisable à temps, était de prendre en charge la transformation incrémentale pour ces associations. Sans que cette première soit implémentée, il est évident que ce second point ne pouvait techniquement pas être réalisé. Voici les diverses raisons de ces empêchements : Le développement du socle de base du plug-in a pris un temps considérable alors que cette tâche n avait simplement pas été prévue lors de la planification. Ce socle incluait, notamment, la définition des règles de nommage, la mise en place d une structure de gestion des exceptions, messages et logs, ainsi que la création des classes métiers, de la fabrique et des autres éléments de programmation nécessaire à l implémentation des règles de transformations. La nécessité, validée par le directeur de travail, de gérer les multiples modèles et sous-systèmes, a rendu indispensable, d une part, une analyse et, d autre part, une implémentation. Le temps nécessaire à déboguer les méthodes du plugiciel était considérable, à cause du processus de tests qui devait être fait pour chaque nouvelle méthode implémentée. Cela a également impliqué la création d un script de déploiement automatique pour faciliter ce processus, ce qui a, finalement, également occupé du temps. L analyse approfondie sur la façon de gérer la transformation incrémentale des identifiants naturels a été plus compliquée que les autres, car il était simplement impossible de placer un marqueur au niveau conceptuel, alors que les contraintes du niveau logiques n acceptaient pas de valeurs marquées. La recherche d une solution et la création d un algorithme n étaient initialement pas prévues. Enfin, l administration du projet a représenté une part très importante du travail, qui s est avérée encore plus grande que prévu. Effectivement, chaque analyse ou développement devait être rédigé, des rapports hebdomadaires de travail devaient être complétés et envoyés en fin de semaine avec, également, les procèsverbaux des séances, de même que tous les nouveaux ajouts rédactionnels, sans compter que la demande de ratification a occupé une longue période durant les premières semaines où l on n avait, finalement, réalisé aucun élément constitutif concret servant au projet en soi. À ces raisons s ajoute également la notion de qualité du code, que je souhaitais assurer à tout prix. En effet, sachant qu il va être consulté et complété, je ne pouvais faire autrement que de me pencher là-dessus. Ainsi, toutes les classes, attributs et méthodes sont commentés, de même que les instructions difficiles à comprendre ou non évidentes. Page

61 12. ANALYSES ET DÉVELOPPEMENTS FUTURS Pour déterminer clairement ce qui n a pas encore été abordé, ce qui a été analysé et ce qui a été implémenté, j ai réalisé le tableau ci-dessous qui décrit clairement quels seront les travaux à réaliser par la suite. Tâches Non analysé Analysé Définir les conventions de nommage. Définir l architecture logicielle et la structure du projet Java. Mettre en place une technique de déploiement automatique, pour augmenter la productivité lors du développement. Prévoir la gestion des exceptions Prévoir la gestion des logs Prévoir la gestion des messages à afficher à l utilisateur. Prendre en charge de multiples modèles dans un projet VP. Prendre en charge les sous-systèmes dans un projet VP. Analysé et implémenté Prendre en charge la transformation d une entité et de ses attributs. Prendre en charge la transformation d associations Prendre en charge la transformation des associations identifiantes de composition. Prendre en charge la transformation d associations de spécialisation-généralisation. Prendre en charge la transformation d associations identifiantes naturelles. Mettre en place un algorithme qui transformation les éléments dans le bon ordre de façon à gérer les dépendances. Permettre la transformation à partir d un projet, d un modèle, d un répertoire, d un diagramme et d une classe. Mettre en place une liaison entre les objets du MCD et du MLD pour permettre la gestion de la transformation itérative et incrémentale. Prendre en charge la transformation itérative et incrémentale des entités et attributs. Prendre en charge les règles de transformation itérative et incrémentale des clés primaires, des identifiants naturels et de la multiplicité des attributs. Prendre en charge tous les cas possibles de la transformation incrémentale des types d attributs (une préanalyse a été réalisée et une première implémentation cohérente est en place). Prendre en considération les cas où des objets du MCD et du MLD sont renommés ou supprimés (une préanalyse a été réalisée). () () () Page

62 Tâches (suite) Non analysées Analysées Analysées et implémentées Définir les tailles maximales des noms de colonnes et contraintes, en tenant compte des conventions de nommage du chapitre 5. Mettre les valeurs marquées que l utilisateur ne devrait pas modifier en lecture seule (la solution est impossible). Prendre en compte le cas où une entité est l enfant de plusieurs pères pour les associations identifiantes naturelles. Vérifier si, avec une version plus récente de Visual Paradigm 8.2, il est possible d effectuer des logs avec OpenAPI. Voir le chapitre Internationaliser le plug-in pour permettre d afficher les messages en français en plus de l anglais. Rédiger un manuel utilisateur qui pose les prérequis et les règles à respecter pour l utilisation du plug-in. De fait, tous les éléments non analysés ou non implémentés font bien entendu l objet de tâches futures. J évite volontairement de parler d «améliorations» futures, car le projet n est pas terminé et s inscrit bien dans la continuité d un grand travail et non d une simple réalisation qui peut aboutir aux termes d un seul travail de Bachelor. Page

63 13. ADMINISTRATION DU PROJET Dans l optique d assurer un suivi efficace, le directeur de travail m a convié à mettre en place les éléments d administration de projet suivant : Une séance de travail, en présence du directeur de travail, de l assistant et de moi-même, est faite en chaque début de semaine. Une séance donne lieu à un procès-verbal qui se focalise uniquement sur les décisions prises. L ensemble des PVs est retrouvable dans la partie administrative. Un rapport hebdomadaire de travail (RHT), qui présente le déroulement de la semaine, la planification de la semaine suivante ainsi que les éventuelles remarques ou questions de l étudiant, est réalisé. Tout comme pour les PVs, les RHTs se situent dans la partie administrative. Enfin, à chaque fin de semaine, les nouveaux PVs, le RHT de même que toutes les nouvelles rédactions faites sont envoyés par courriel au directeur de travail. Pour le candidat, cette gestion apport l avantage indéniable qu il peut être réorienté rapidement s il venait à partir dans une mauvaise direction. D un autre côté, le directeur de travail, qui est également le représentant du mandat dans mon cas, peut s assurer que le produit qu il attend réponde au mieux à ses besoins. Bien entendu, l inconvénient de la mise en place de cette administration réside dans le temps dépensé par les deux parties, autant pour la préparation des documents à envoyer que pour la lecture de ceux-ci. Au final, chacun y trouve son compte. Pour terminer, je souhaite fournir un retour particulier sur quatre outils liés à l administration de mon projet et que j ai eu l occasion d utiliser. Microsoft Project : Ne l ayant jamais utilisé auparavant, mais souhaitant essayer un logiciel de gestion de projet, j ai passé le premier mois de mon Bachelor à gérer mes tâches sous Microsoft Project. Le résultat est sans appel : il ne m a été d aucune utilité et son utilisation m a consommé un temps précieux. La raison de cet échec d utilisation est due au fait que le programme est trop rigoureux dans la gestion des tâches pour ce que je souhaitais en faire. Ce serait, à n en pas douter, un outil fort utile dans le contexte de projets gérés minutieusement et dont plusieurs personnes travaillent dessus, mais pas dans le mien. Todoist : Après avoir abandonné Microsoft Project, j employais de simples feuilles de papier pour gérer ma liste de tâches. Les limites de cette solution se sont vite montrées : impossibilité d ordonner les tâches en fonction des priorités, aucun moyen de mettre en évidence celles qui arrivent à échéance et lisibilité des fiches devenant mauvaises, du fait des tâches biffées. J ai alors consacré quelques minutes pour rechercher un outil simple, qui m a pleinement satisfait : Todoist. C est une application web qui offre une gestion des tâches, tout en permettant de les imbriquer les unes dans les autres, de les prioriser et de leur mettre une date butoir. Simple et gratuite (une version payante existe), elle a su répondre à mes attentes et dispose d applications pour les smartphones tournant sous ios, Android ou BlackBerry OS. Page

64 DropBox : La gestion des sauvegardes ainsi que le partage de documents communs avec M. Sester et M. Veya s est fait à l aide du puissant outil DropBox, qui gère de manière redoutable la synchronisation entre plusieurs utilisateurs. Cela est bon à prendre, la solution historise toutes les versions des documents dans le Cloud, sur son compte en ligne. En l utilisant quotidiennement, je n ai perçu aucun problème particulier, ce qui fait de lui, selon moi, une solution tout à fait stable et utilisable professionnellement. Subversion Edge : Faute d avoir pu disposer d un répertoire sur un serveur de versions de l école, j ai effectué des recherches pour finalement trouver Subversion Edge, un serveur SVN de CollabNet gratuit, pouvant fonctionner sur Windows et qui propose une interface d administration facile à prendre en main. Il a été utilisé pour gérer les versions du plug-in durant le développement et a amené tous les avantages d un gestionnaire de versions 22. Du reste, il gère les sauvegardes automatiques et n a provoqué aucune erreur durant la période d utilisation. Au besoin, la page officielle de l éditeur fournit plus d informations : Notez qu Eclipse, contrairement à NetBeans, ne dispose pas d un client SVN natif. L installation d un plug-in a donc été nécessaire. Subversive, un projet de la communauté Eclipse, a pour but d en fournir un. C est celui-là que j ai utilisé et que je recommande. Il est accessible à l adresse 22 [INT-36] Le fonctionnement d un serveur de versions et les avantages qui en découlent peuvent être consultés sur ce lien. Page

65 14. CONCLUSION PERSONNELLE La modélisation des données est un domaine de grande importance pour le développement de systèmes informatiques et l utilisation d outils tels que des AGL ou des CASE, qui mettent en œuvre les principes MDA et MDE, apportent un réel gain de productivité. Le développement d un plug-in pour Visual Paradigm permet de s approcher d une de ces solutions complètes, sans pour autant arriver à la cheville de ce que proposait Oracle Designer qui n est, malheureusement, plus supporté officiellement. L aboutissement d une fonctionnalité performante de transformation incrémentale et itérative d un modèle conceptuel de données en modèle logique se rapproche et, avec un développement supplémentaire, la filière informatique de la HEG Arc de Neuchâtel disposera d un outil fiable pouvant être utilisé autant pour l enseignement que pour la réalisation de mandats. Alors que Visual Paradigm prendra en compte, à terme, la transformation des différents niveaux de modèles de données, celle des traitements ne semble pas possible aisément. Il est, en effet, impossible de décrire des processus pouvant générer automatiquement des interfaces applicatives. Peut-être les évolutions du logiciel apporteront-elles des solutions, qui permettront, par le biais de l API, de créer de nouveaux diagrammes personnalisés? Cela ne peut être affirmé aujourd hui et j aurais tendance à dire qu il vaut mieux se concentrer sur la gestion des données à l heure actuelle. Malgré cela, l éditeur propose d autres solutions, dans sa suite logicielle, qu il serait intéressant de tester. Il se pourrait qu elles apportent une réelle plus-value à celui ou celle qui souhaite développer une application ou gérer son SII. Agilian, par exemple, est vendu comme étant un outil prenant en charge la description de l architecture de l entreprise et de ses processus, le développement agile ainsi que d autres éléments collaboratifs. A 3 Plateform, quant à lui, se dit gérer le cycle de vie d applications web de même que le processus de développement selon la méthodologie Unified Process. Enfin, l on pourrait sérieusement se poser la question de l avenir des outils «tout-en-un» comme Oracle Designer. D après mon opinion personnelle, le marché a tendance à évoluer vers des solutions de plus en plus spécialisées, au dépit de celles qui sont plutôt généralistes. Oracle, par exemple, dispose aujourd hui d Apex, qui ne se charge «que» de créer des écrans à partir d une base de données existante. Pourquoi est-ce que cela se passe ainsi? Pourquoi voit-on des outils qui prennent en charge le développement piloté par les modèles disparaître? D après moi, le problème est multiple. Il provient, d une part, de l apparition toujours plus rapide des nouvelles technologies qui force les éditeurs à revoir sans cesse leur copie. Se lancer aujourd hui dans une grande solution qui a pour mission de gérer autant les données que les traitements serait un pari risqué. D autre part, j ai la sensation que le marché recherche une orientation plus marketing que conceptuelle ou intellectuelle. Un produit doit être vendu et, si l on ne parle pas de «Cloud», d application pour smartphone ou pour tablette tactile aujourd hui, il semble moins attrayant et pourrait être délaissé rapidement. En dernière hypothèse, j ai l impression que le nombre de développeurs qui connaissent réellement les concepts du MDA et MDE n est pas très important. Ainsi, ce genre d outils a pour cible un segment de marché bien précis, peut-être pas assez grand pour être suffisamment rentable. En conclusion, je souhaite émettre des remerciements aux personnes qui m ont aidé et sans qui la réalisation de mon travail aurait été plus difficile. Tout d abord, c est mon directeur de travail, M. Pierre-André Sunier, envers qui j exprime ma reconnaissance pour le temps qu il a consacré à me suivre et à me conseiller tout au long du projet. Il a toujours su me répondre et, qui plus est, dans les meilleurs délais s il qu il s agissait d un contact par courriel. Ensuite, c est bien entendu l assistant, M. Loïc Jeanneret, que je remercie pour m avoir aidé dans les périodes où je m interrogeais sur mon Page

66 travail. Viennent alors mes deux collègues de travail qui ont aussi réalisé un plug-in pour Visual Paradigm et avec qui j ai eu des discussions intéressantes, à savoir M. Samuel Veya et M. Julien Sester. Je dois également des remerciements à mes autres collègues, qui ont apporté une atmosphère positive et souvent motivante dans notre salle de classe. Pour terminer, je remercie mon entourage familial, notamment mon amie, qui m a soutenu durant cette période importante et parfois ardue, et sans qui je n aurais peut-être pas eu la force d aboutir au résultat que je présente aujourd hui. Page