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