656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale

 
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
Travail de Bachelor d’informaticien de gestion.

656-1.1 Thèse de Bachelor
Rapport de travail
Transformation Incrémentale
    « Implanter les adaptateurs qui permettent de modifier un
modèle logique de données existant à partir des spécifications
                  d’un modèle conceptuel de données. »

                                                       Réalisé par : Vanessa Vitale
                                                 Mode de réalisation : intra-muros
                                                        Cycle d’études : 2011-2014
                                                               Restitué le : 07/2014
Travail de Bachelor            Page 1 sur 90                      Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
TABLE DES MATIÈRES
     GLOSSAIRE ............................................................................................................................................................. 4

1.       INTRODUCTION................................................................................................................................................... 5

     1.1         CONTEXTE DU TRAVAIL................................................................................................................................. 6
         1.1.1       Projet MVC-CD ................................................................................................................................... 6
             1.1.1.1          Synthèse de l’objectif du projet mvc-cd ................................................................................................... 9
         1.1.2       Positionnement du Sujet de la thèse de bachelor.............................................................................. 9
         1.1.        Travail de la thèse ........................................................................................................................... 13
         3
                     Technologies utilisées ...................................................................................................................... 14
         1.1.4
             1.1.4.1          Visual Paradigm for UML ........................................................................................................................ 14
             1.1.4.2          Eclipse IDE for Java EE Developpers........................................................................................................ 14
             1.1.4.3          Oracle ..................................................................................................................................................... 14

2.       RÉSUMÉ ................................................................................................................................................. 15

3.       PARTIE THÉORIQUE : BASES ET RÉFÉRENCES .......................................................................................... 16

     3.1         INTRODUCTION ........................................................................................................................................ 16
     3.2         PROFILS .................................................................................................................................................. 16
     3.3         SWING ................................................................................................................................................... 17
     3.4         LISTENER................................................................................................................................................. 19
     3.5         OPENAPI ................................................................................................................................................ 19

4.       PARTIE PRATIQUE .................................................................................................................................................... 20

     4.1         INTRODUCTION ........................................................................................................................................ 20
     4.2         DÉVELOPPEMENT LIÉ AU SUJET DE BACHELOR ................................................................................................. 20
         4.2.1       Diagrammes utilisés ........................................................................................................................ 20
         4.2.2       Préférence de transformation ......................................................................................................... 21
         4.2.3       Interface .......................................................................................................................................... 22
             4.2.3.1          Travail demandé ..................................................................................................................................... 22
             4.2.3.2          Analyse générale .................................................................................................................................... 24
             4.2.3.3          Développement ...................................................................................................................................... 28
             4.2.3.4          Représentation finale ............................................................................................................................. 38
         4.2.4       Changements................................................................................................................................... 40
             4.2.4.1          Travail demandé ..................................................................................................................................... 40
             4.2.4.2          Analyse générale .................................................................................................................................... 41
             4.2.4.3          Adaptateurs ............................................................................................................................................ 42
             4.2.4.4          Chargement des préférences ................................................................................................................. 46

Travail de Bachelor                                                           Page 2 sur 90                                                                Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
4.2.4.5         Notion « Possible » et « Problème »....................................................................................................... 47
           4.2.4.6         Changement – Colonne - Taille (Size et Scale) ........................................................................................ 48
           4.2.4.7         Changement – Colonne - Type................................................................................................................ 52
           4.2.4.8         Changement – Colonne - Type et Size simultané .................................................................................... 59
           4.2.4.9         Clé primaire et clé étrangre .................................................................................................................... 62
           4.2.4.10        Changement – Colonne - Nom................................................................................................................ 66
           4.2.4.11        Changement – Table - Nom .................................................................................................................... 70
     4.3       DÉVELOPPEMENT INDIRECT ......................................................................................................................... 73
       4.3.1       Modification MLDDBORACLECOLTYPE ............................................................................................ 73
       4.3.2       Taille maximum pour le type NUMBER ........................................................................................... 73
           4.3.2.1         Tests ....................................................................................................................................................... 74
           4.3.2.2         Tableau récapitulatif ............................................................................................................................... 77
       4.3.3       Onglet « Paramètre d’affichage » ................................................................................................... 78
       4.3.4       Timestamp ....................................................................................................................................... 79
     4.4       TRAVAUX LIÉS À L’INTÉGRATION ................................................................................................................... 80
       4.4.1       Contexte .......................................................................................................................................... 80
       4.4.2       Éléments ajoutés ............................................................................................................................. 80
       4.4.3       Éléments modifiés ........................................................................................................................... 81
       4.4.4       Propriétés ajoutées.......................................................................................................................... 82
     4.5       ÉTAT ACTUEL DU PROJET............................................................................................................................. 83
       4.5.1       Améliorations .................................................................................................................................. 84
           4.5.1.1         Interface ................................................................................................................................................. 84
           4.5.1.2         Changements .......................................................................................................................................... 85
     4.6       CONCLUSION ........................................................................................................................................... 86

5.     BIBLIOGRAPHIE ............................................................................................................................................... 88

Travail de Bachelor                                                         Page 3 sur 90                                                                Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
GLOSSAIRE

Ce glossaire contient les acronymes couramment utilisés dans ce rapport.

                  Acronyme      Signification

                  TB            Thèse de Bachelor / Travail de Bachelor

                  TP            Travail Personnel

                  VP            Visual Paradigm for UML

                  MCD           Modèle Conceptuel de Données

                  MLD           Modèle Logique de Données

                  MPD           Modèle Physique de Données

                  RHT           Rapport Hebdomadaire de Travail

                  MVC           Modèle-Vue-Contrôleur

                  PK            Primary Key (clé primaire)

                  FK            Foreign Key (clé étrangère)

Travail de Bachelor                   Page 4 sur 90                        Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
1. INTRODUCTION

C’est dans le cadre de l’unité d’enseignement « 656-1.1 Thèse de Bachelor » au cours de ma
formation à la Haute École de Gestion Arc (HEG) en tant qu’informaticienne de gestion que
ce travail a été réalisé. Il représente 12 ECTS, soit 336 heures de travail.

Le directeur de travail M.Pierre-André Sunier et l’assistant M. Steve Berberat ont soutenu le
travail réalisé.

Cette thèse de Bachelor est la continuité de l’unité d’enseignement « 646-2.1 Travail
Personnel » (TP). Le Travail Personnel permet de se préparer à la réalisation du TB en
réalisant une première analyse qui présente le problème posé, son contexte ainsi que la
démarche à suivre pour le résoudre. Certains éléments du TB proviennent alors de la phase
d’analyse initiale réalisée lors du TP.

Des RHT (Rapport Hebdomadaire de Travail) ont été fournis de manière hebdomadaire afin
de préciser le travail effectué. Ceux-ci regroupaient le RHT de la semaine (horaire de travail,
justification des absences, tableau synoptique, journal de travail, déroulement de la
semaine, planification de la semaine suivante ainsi que les remarques et questions
éventuelles), les parties du rapport modifiées/complétées durant la semaine et divers
travaux effectués sur demande du directeur de travail.

Une demande de ratification démontrant que le sujet de cette thèse est compris a été
réalisée. Celle-ci a été validée par la direction de filière et par le directeur de travail.

Les RHT ainsi que la demande de ratification se trouvent dans le chapitre 6.Partie
administrative de ce rapport.

De plus, une séance hebdomadaire a été effectuée entre le directeur de travail, l’assistant et
moi-même, sur la base de ces RHT, afin de faire un point sur l’avancement, les questions
éventuelles et la suite du projet.

Ce travail a été réalisé pour la HEG et s’intègre dans le projet nommé « Projet MVC-CD »,
décrit dans ce document.

Dans la suite de ce chapitre, le contexte du travail est décrit.

Travail de Bachelor                        Page 5 sur 90                            Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
1.1 CONTEXTE DU TRAVAIL

Le sujet du travail de Bachelor découle d’une des activités à accomplir afin que le projet
MVC-CD corresponde à son objectif. Dans ce chapitre, se trouve une description du projet
MVC-CD ainsi que le positionnement du sujet de cette thèse dans le projet et pour terminer,
une brève description du travail demandé.

1.1.1 PROJET MVC-CD

Le projet MVC-CD est décrit de manière générale dans le document [MVC-02]. Dans la suite
de ce chapitre, se trouvent les points clés de ce document qui permettront de mieux
comprendre l’objectif du projet.

Objectif stratégique :
      Transformation automatique et incrémentale des règles métiers impactant l’intégrité des
      données en un composant logiciel jouant le rôle de contrôleur spécialisé « données » dans
      l’optique du patron MVC - Modèle-Vue-Contrôleur.

Brève description du projet :
      Face aux besoins de réactivité toujours plus grande des processus de travail des entreprises,
      la capacité à évoluer des logiciels de gestion devient un facteur critique de leurs systèmes
      d'information informatisés (SII) et de fait, le développement desdits logiciels de gestion
      devient de plus en plus un processus itératif relativement permanent.

      La pression sur les coûts et la nécessité d'amélioration de la qualité ont amené les modèles et
      la modélisation au cœur du processus de développement de logiciels de gestion (MDE, MDA,
      MDD…), à l'image de ce que réalisaient avec succès certains ateliers de génie logiciel (AGL)
      du début des années 2000.

      Notre projet vise à favoriser le développement itératif au sein d'une démarche d'ingénierie
      pilotée par les modèles; cette optimisation prendra la forme de guides méthodologiques, de
      règles de formalisation et de transformation de modèles et enfin d'automates pour la
      réalisation des tâches mécanisables que ce soit transformation de modèles ou génération de
      code.

      La structure de données et leurs règles d'intégrité étant les éléments centraux du SII, nous
      focaliserons notre recherche sur cet aspect-là qui nous offre un gros potentiel d’amélioration
      de la qualité et de l’évolutivité des logiciels de gestion.

Travail de Bachelor                           Page 6 sur 90                        Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
Objectif général :
      L’objectif de notre projet est d’explorer la faisabilité d’automatiser les activités mécanistes ou
      relevant de la partie statique du système d’information.

      Naturellement, il ne s’agira pas seulement d’une démarche intellectuelle, mais, nous nous
      efforcerons de fournir des éléments opérationnels de la transformation sous forme de
      prototypes plus ou moins finalisés […]

Schéma général qui représente des objectifs détaillés et cadre d’expérimentation retenu :

 Figure 1 – Schéma général des objectifs détaillés et cadre d’expérimentation retenu

Travail de Bachelor                                 Page 7 sur 90                      Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
L’explication pour la lecture de ce schéma (Figure 1) se trouve dans le chapitre « 2 Objectifs
- Représentation symbolique » du document [MVC-02].

Pour atteindre ces objectifs, un plugin à intégrer dans Visual Pardigm for UML (VP) a été
développé en Java dans l’environnement de développement Eclipse. Ces différentes
technologies sont présentées dans le chapitre « 1.1.4 Technologies utilisées ».

Le diagramme d’activité suivant, repris de [MVC-04], permet d’avoir une première vue du
fonctionnement du plugin :

Figure 2 - Diagramme d'activité du plugin

Fonctionnement du plugin:

Dans un projet au sein de Visual Paradigm (VP), le modélisateur lance la transformation en
sélectionnant l’entrée dans le menu ajouté expressément à cet effet. Le plugin va alors lire
le modèle conceptuel de données (MCD) se trouvant dans le référentiel de VP et le stocker
en mémoire. Par la suite, il vérifie si un modèle logique de données (MLD) existe déjà afin de
le stocker en mémoire. Il génère ensuite le MLD qui est à obtenir en fonction du MCD en

Travail de Bachelor                         Page 8 sur 90                    Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
mémoire. Pour finir, le plugin va créer le delta entre le MLD existant et celui à obtenir afin
d’adapter le MLD dans le référentiel VP.

Ce diagramme d’activité est la première esquisse et ne tient donc pas compte des classes
et méthodes planifiées.

1.1.1.1 SYNTHÈSE DE L’OBJECTIF DU PROJET MVC-CD

Ci-dessous un schéma et le texte correspondant à celui-ci, repris de [MVC-02],

      Il s'agit, dès la deuxième itération, de
      prendre en compte le delta entre le
      modèle        source   de     l'itération
      courante et le modèle cible de
      l'itération     précédente    et     de
      transformer le modèle cible en un
      nouveau modèle cible incluant le dit-
      delta.

Le projet MVC-CD souhaite offrir la possibilité, dans une démarche d’ingénierie pilotée par
les modèles, de pouvoir faire du développement itératif en proposant une démarche et des
automates qui vont favoriser la productivité, l’agilité et la visibilité du processus de
développement

1.1.2 POSITIONNEMENT DU SUJET DE LA THÈSE DE BACHELOR

Premièrement, il est à noter que le projet MVC-CD a déjà débuté depuis 2 ans. Par
conséquent, les bases du projet ainsi qu’une partie du développement du plugin ont déjà été
mis en place.

Dans le schéma général qui représente les objectifs détaillés et le cadre d’expérimentation
(Figure 3) le travail de cette thèse s’effectue au niveau de l’automate (A). Les deux flèches
« i » qui arrivent dans cet automate représentent le modèle conceptuel de données (MCD)
qui sera transformé dans l’automate pour devenir le modèle logique de données (MLD) à
obtenir.

La flèche « i-1 » représente le MLD existant qui est repris par l’automate afin de pouvoir
comparer le MLD à obtenir au MLD existant.

Travail de Bachelor                       Page 9 sur 90                      Vanessa Vitale
656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
Les deux flèches « i » qui sortent de cet automate représentent les modifications à apporter
au MLD et respectivement, au modèle physique de données (MPD).

Figure 3 – Schéma général des objectifs détaillés et cadre d’expérimentation retenu

Travail de Bachelor                                  Page 10 sur 90                   Vanessa Vitale
Afin d’identifier le positionnement du sujet de travail de Bachelor dans le plugin MVC-CD,
  voici le diagramme d’activités principales du plugin repris de [MVC-04].

Figure 4 - Diagramme d'activité principale du plugin MVC-CD

  Ce diagramme d’activités principales présente donc les activités principales qui se
  trouveront dans l’algorithme de transformation de l’automate (A) de la Figure 3.

  Afin d’avoir une meilleure compréhension de celui-ci, voici une description de chaque tâche
  reprise du document de référence :

                Contrôle de conformité du MCD - la logique de l'algorithme peut s'arrêter à cette
                 seule activité si seul le contrôle de conformité est souhaité par l'utilisateur. Si le
                 modèle est conforme, les objets MCDElement sont créés en mémoire.

                Lecture du MLD existant et mise en mémoire - lecture du MLD existant et création
                 des objets MLDExistantElement en mémoire. La lecture du MLD existant est
                 effectuée si la transformation est incrémentale et que le MLD a été créé lors d'une
                 itération précédente.

  Travail de Bachelor                                Page 11 sur 90                  Vanessa Vitale
   Génération du nouvel MLD en mémoire - lecture des objets MCDElement conformes
           existants en mémoire et création des objets MLDACreerElement en mémoire.

          Elaboration du delta entre MLD existant en mémoire et MLD nouveau en mémoire -
           création des objets MLDAdaptateur qui vont      contenir   les   spécifications   de
           correction du delta entre MLD existant et MLD à obtenir. Si la transformation n'est
           pas incrémentale ou qu'il s'agit de la 1ère itération, le delta correspond à la
           réalisation du MLD à obtenir.

          Génération du MLD - Exécution du code de transformation contenu dans les objets
           MLDAdaptateur.

Le travail demandé est principalement à intégrer dans la tâche « Elaboration du delta entre
MLD existant en mémoire et MLD nouveau en mémoire».

Travail de Bachelor                    Page 12 sur 90                        Vanessa Vitale
1.1.3 TRAVAIL DE LA THÈSE

Le document [ANN-02], chapitre « 3. Transformation incrémentale », décrivant le sujet de
cette thèse, se présente comme suit :

      L'objectif de ce travail est d'analyser les problèmes de répercussions de changements
      entre deux incréments, de proposer des solutions de répercussion des changements
      lorsque cela est envisageable avec sureté et d’en développer les modalités.

         Opération        Analyser    et     implanter   l'opération Modifier en    offrant   la
         Modifier         possibilité à l'utilisateur de choisir quels sont les changements
                          qui doivent être apportés dans son modèle ou pas dans la
                          perspective de pouvoir générer un modèle physique de données
                          sans effets de bord sur une implantation physique existante.

                          Naturellement, il faudra fixer une liste de changements que
                          nous prendrons en compte avec ou sans restriction.

                          L'utilisateur devra pouvoir choisir les éventuels changements à
                          reporter de l'itération à l'itération i+ 1. Pour ce faire, vous pouvez
                          vous inspirer de ce qu'offre l'atelier de génie logiciel Oracle
                          Designer […].

En d’autres termes, ce travail se sépare en deux points :

   1. Pour chaque changement identifié, il faudra analyser quel est l’impact entre deux
      incréments, proposer des solutions de traitements de ces impacts et développer la
      meilleure solution.
   2. Développer une interface graphique permettant au modélisateur de choisir quels
      changements il permet entre deux incréments.

Le travail de chaque point est décrit plus en détail dans la partie pratique de ce rapport
(4.Partie Pratique).

Travail de Bachelor                        Page 13 sur 90                       Vanessa Vitale
1.1.4 TECHNOLOGIES UTILISÉES

Les différentes technologies qui ont été retenues par le projet MVC-CD sont les suivantes :

1.1.4.1 VISUAL PARADIGM FOR UML

Pour   la   modélisation,   la   transformation    et le
développement des automates, Visual Paradigm for
UML a été retenu. Ce logiciel est un outil de
modélisation UML permettant de créer des modèles.

Il offre également la possibilité de produire sous forme de plugins des transformateurs ou
automates, comme nécessaire dans le projet, en ciblant comme base de données Oracle.

1.1.4.2 ECLIPSE IDE FOR JAVA EE DEVELOPPERS

Version : JUNO        Edition : 64 bits

L’environnement de développement retenu dans ce projet est
Eclipse. Il a notamment comme avantage d’avoir la possibilité
d’y intégrer l’environnement Visual Paradigm for UML.

1.1.4.3 ORACLE

La base de données retenue pour ce projet est Oracle notamment à
cause qu’elle permet de s’appuyer sur des trigger et des procédures
stockées pour fabriquer automatiquement la couche Contrôleur de
gestion de l’intégrité des données.

Travail de Bachelor                       Page 14 sur 90                    Vanessa Vitale
2. RÉSUMÉ

                                     Transformation itérative

Candidat            Vitale Vanessa

Professeur          Sunier Pierre-André

           Description
   Le travail de cette thèse s’inscrit dans le projet MVC-CD qui souhaite offrir la possibilité,
   dans une démarche           d’ingénierie pilotée par les modèles, de pouvoir faire du
   développement itératif tout en proposant une démarche et des automates qui vont
   favoriser la productivité, l’agilité et la visibilité du processus de développement.

   Les tâches appartenant à cette thèse sont les suivantes :
       1.    Analyser les problèmes de répercussion de changement entre deux incréments,
             proposer des solutions de répercussion de ces changements lorsque cela est
             envisageable avec sureté et développer les modalités.
       2.    Développer une interface graphique qui permettra au modélisateur de choisir les
             changements à reporter entre deux itérations.
           Déroulement
   Pour commencer, la compréhension du contexte de ce travail dans le projet MVC-CD est
   primordiale afin de saisir correctement comment et où il s’intègre à celui-ci. Dans un
   deuxième temps, une analyse sur la répercussion entre deux itérations de chaque
   changement identifié ainsi que l’implémentation des solutions de répercussion a été
   effectuée. En parallèle, l’interface qui permet au modélisateur de paramétrer les
   modifications à reporter a été développée.
           Résultats
   Une partie des changements identifiés a été analysée et implémentée. Les analyses pour
   l’interface graphique ainsi que l’interface elle-même ont été développées.
           Perspectives
   La partie des changements qui n’a pas pu être analysée et implémentée devra l’être.
   Aussi, comme ce travail s’inclut dans le projet MVC-CD, il sera probablement repris et
   amélioré. L’interface, quant à elle, devra être adaptée en fonction des nouvelles analyses
   de changement, mais également complétée avec d’autres informations concernant le
   paramétrage du projet.

Travail de Bachelor                       Page 15 sur 90                        Vanessa Vitale
3. PARTIE THÉORIQUE : BASES ET RÉFÉRENCES

3.1 INTRODUCTION

Ce chapitre représente une synthèse des informations utilisées pour la partie pratique.
Voici, ci-dessous, les sous-chapitres qui composent cette partie :

3.2 PROFILS

La notion de « profil » étant utilisée au sein du projet et impactant le travail lors de la
spécification d’un type de donnée, il est primordial de comprendre ce concept.

Selon le document [MVC-01], la définition d’un « profil » est la suivante :

      Le méta-modèle UML n'étant pas modifiable – et ne doit pas l'être ! –, le mécanisme
      de profil permet d'étendre les éléments du méta-modèle, sans le changer et tout en
      créant de nouveaux concepts de modélisation.

      Les profils UML sont apparus dans la version UML 2. Avant, le concepteur pouvait
      créer librement des stéréotypes et/ou des valeurs taguées pour étendre son
      vocabulaire et formaliser ses spécifications.

      Un profil UML est un package dans lequel des éléments du méta-modèles (les
      métaclasses) vont être étendus. Le concept central du profil est le stéréotype. La
      création d'un nouveau concept de modélisation se fait par le mécanisme de
      stéréotype, qui dans le méta-modèle UML2 est une extension d'une méta-classe du
      méta-modèle UML.

      Les deux autres concepts-clés dans les profils sont les valeurs taguées (directement
      liées aux stéréotypes) et les contraintes.

      Avant UML2, les stéréotypes et les valeurs taguées pouvaient être librement créés sur
      les éléments de modèles. Dès UML2, les stéréotypes ne peuvent être définis que dans
      un profil, et par conséquent, les valeurs taguées également.

Pour plus de détails concernant cette notion, le document de référence est à consulter.

Travail de Bachelor                     Page 16 sur 90                        Vanessa Vitale
3.3 SWING

Dans le cadre de la création de l’interface, l’API Swing a été utilisée. Afin de comprendre
cette notion, voici ci-dessous une définition tirée de [INT-1] :

      Swing est une bibliothèque graphique pour le langage de programmation Java, faisant
      partie du package Java Foundation Classes (JFC), inclus dans J2SE. Swing constitue
      l'une des principales évolutions apportées par Java 2 par rapport aux versions
      antérieures.

      Swing offre la possibilité de créer des interfaces graphiques identiques quel que soit
      le système d'exploitation sous-jacent, au prix de performances moindres qu'en
      utilisant Abstract Window Toolkit (AWT). Il utilise le principe Modèle-Vue-Contrôleur
      (MVC, les composants Swing jouent en fait le rôle du contrôleur au sens du MVC) et
      dispose de plusieurs choix d'apparence (de vue) pour chacun des composants
      standards.

   Le diagramme de la plateforme Java repris de [INT-6] permet de positionner Swing.

Travail de Bachelor                     Page 17 sur 90                     Vanessa Vitale
Ci-dessous se trouvent, les principaux composants swing utilisés dans ce travail ainsi
   que les liens internet qui ont permis d’en comprendre le fonctionnement:

Composant             Description       Lien

JPanel                Conteneur         http://fr.openclassrooms.com/informatique/cours/apprenez-
                                        a-programmer-en-java/notre-premiere-fenetre

JTabbedPane           Onglets           http://docs.oracle.com/javase/tutorial/displayCode.html?code
                                        =http://docs.oracle.com/javase/tutorial/uiswing/examples/co
                                        mponents/TabbedPaneDemoProject/src/components/Tabbed
                                        PaneDemo.java

JCheckBox             Case à cocher     http://www.java2s.com/Tutorial/Java/0240 Swing/CheckBox
                                        List.htm

JRadioButton          Bouton radio      http://www.java2s.com/Tutorial/Java/0240 Swing/0160 JR
                                        adioButton.htm

ButtonGroup           Groupage de       http://stackoverflow.com/questions/6883604/listening-on-
                      bouton radio      buttongroup-for-child-changes-and-print-selected-
                                        jradiobuttons

GridLayout            Positionnement          http://fr.openclassrooms.com/informatique/cours/appre
                                               nez-a-programmer-en-java/positionner-des-boutons
GridBagLayout         Positionnement          http://www.jmdoudoux.fr/java/dej/chap-awt.htm

GridBagConstraints    Positionnement

Travail de Bachelor                    Page 18 sur 90                         Vanessa Vitale
3.4 LISTENER

Voici une définition selon [INT-5], qui permet de comprendre la manière dont les listeners
sont utilisés :

      Dans le contexte d'une interface graphique (Swing, AWT, etc), les listeners permettent
      au programmeur de réagir suite aux actions de l'utilisateur (clic de souris, touche du
      clavier enfoncée, etc).

      Les « listeners » sont des interfaces. Ces interfaces fournissent une ou plusieurs
      méthodes qui peuvent donc être implémentées différemment selon les cas et les
      besoins, pour répondre aux événements.

      Les interfaces « listener » sont présentes principalement dans le package
      java.awt.event, mais également dans le package javax.swing.event.

      Chaque listener dispose d'une classe Event associée. Cette classe étend
      java.awt.event.EventObject et fournit une description de l'évènement capturé. Par
      exemple, la classe ActionEvent décrit les évènements capturés par un ActionListener.

Les listeners sont utilisés dans ce projet lors du développement de l’interface utilisateur.

3.5 OPENAPI

L’OpenAPI est une librairie mise à disposition par Visual Paradigm. Elle se trouve au sein de
VP et nous permet de faire la traduction entre les projets de VP et le plugin MVC-CD.

C’est donc tout au long de la programmation, tant pour les changements que pour
l’interface, que cette API a été utilisée.

La documentation de l’OpenAPI se trouve à [INT-07].

Travail de Bachelor                          Page 19 sur 90                    Vanessa Vitale
4. PARTIE PRATIQUE

4.1 INTRODUCTION

Le chapitre « 4.Partie pratique » présente le travail effectué dans le cadre de cette thèse et
est divisé en cinq sous-chapitres.

Le premier traite des analyses effectuées et des démarches suivies qui sont liées au sujet
de Bachelor. Vient, ensuite, les activités effectuées qui n’ont pas de rapport direct avec le
cœur du sujet de la thèse.

Le code produit pour ce travail devant ensuite être intégré dans celui du projet MVC-CD, un
sous-chapitre qui regroupe tous les éléments du code qui ont été modifiés ou ajoutés est
décrit.

Pour terminer, un sous-chapitre permettant de signifier l’avancement de ce projet et un
autre contenant une conclusion personnelle sont décrits.

4.2 DÉVELOPPEMENT LIÉ AU SUJET DE BACHELOR

Ce sous-chapitre commence par décrire les diagrammes utilisés dans le cadre d’une
transformation au sein de Visual Paradigme puis, la notion de préférence de
transformations est présentée. Par la suite, le travail effectué pour cette thèse est décrit et
séparé en deux parties :

         Interface
         Changements

4.2.1 DIAGRAMMES UTILISÉS

Les diagrammes de Visual Paradigm utilisés pour modéliser les modèles conceptuels de
données (MCD)/modèles logiques de données (MLD) sont les suivants :

                      MCD            Class Diagramm

                      MLD            Entity Relationship Diagram

Travail de Bachelor                      Page 20 sur 90                       Vanessa Vitale
4.2.2 PRÉFÉRENCE DE TRANSFORMATION

Les préférences de transformation permettent de préciser la façon dont le changement doit
s’effectuer entre deux changements. Celles-ci sont les suivantes :

Forced                Le changement est réalisé qu’il altère ou pas les données

Conserved             Le changement est réalisé uniquement s’il n’altère pas les données

Ces paramètres peuvent être définis depuis l’interface (4.2.2 Interface).

Travail de Bachelor                     Page 21 sur 90                        Vanessa Vitale
4.2.3 INTERFACE

Dans ce sous-chapitre se trouve une définition de l’interface, l’analyse effectuée ainsi qu’un
sous-chapitre expliquant comment tous les éléments nécessaires ont été développés afin
que l’interface fonctionne correctement. Pour terminer, un sous-chapitre concernant la
représentation finale montre l’apparence de l’interface ainsi que les améliorations à
apporter.

4.2.3.1 TRAVAIL DEMANDÉ

Selon le document [ANN-1], le travail à effectuer pour l’interface graphique se décrit comme
suit :

         Développer une interface permettant à l'utilisateur/modélisateur de définir le
         paramétrage de transformation en s'inspirant de ce qu’Oracle offrait avec Designer.

         Les paramètres par défaut proviennent du fichier de propriétés plugin.properties; les
         paramètres de l'utilisateur/modélisateur doivent être enregistrés au sein du projet.

Toujours selon ce document, voici, ci-dessous, l’interface qu’Oracle offrait avec Designer :

                                        Figure 5 - Oracle Designer

Travail de Bachelor                       Page 22 sur 90                        Vanessa Vitale
L’interface graphique à développer a donc pour but de permettre au modélisateur de définir
la préférence de transformation (4.2.1.2 Préférence de transformation) de chaque
changement identifié (4.2.3 Changements). Dans le cas où aucune préférence n’est
paramétrée, ce sont les valeurs par défaut qui seront utilisées.

Sur le conseil du directeur de travail, M.Pierre-André Sunier, le développement de l’interface
s’est basé sur le travail de Bachelor d’Oliver Bel [LGL-01] contenant certains éléments
concernant le développement d’interface utilisateur en java. C’est donc en se basant sur ce
travail que l’API Swing (3.4 Swing) a été utilisé.

Travail de Bachelor                     Page 23 sur 90                       Vanessa Vitale
4.2.3.2 ANALYSE GÉNÉRALE

L’analyse générale décrit le raisonnement et les démarches suivis afin de développer
l’interface utilisateur.

4.2.3.2.1      COMPORTEMENT

Selon le document [MVC-5], le comportement de l’interface se présente comme suit :

             Au niveau de l'élément {table, colonne, fk…} par un choix oui/non

             Au niveau de chaque propriété {nom} {size, scale et type pour les types de
              données des colonnes} {…} par un choix oui/non; le Oui est affiné en:

          1. conserved; la modification n'est réalisée que si les éventuelles données
              enregistrées au sein du SGBD qui subira la modification ne sont pas altérées.

          2. forced, la modification est faite qu'elle que soit l'incidence sur les éventuelles
              données.

Les choix oui/non sont représentés par des cases à cocher. Une case à cocher sélectionnée
(oui) signifie que la transformation pour l’élément ou la propriété est acceptée. Si celle-ci
n’est pas sélectionnée (non), cela indique qu’aucune transformation n’est acceptée pour
l’élément ou la propriété en question.

Si la case à cocher d’une propriété est activée, il faudra encore spécifier le type de
modification souhaité (« conserved » ou « forced »). Ce choix est représenté par des
boutons radio.

Le sous-chapitre suivant décrit la maquette et permet d’avoir un support visuel de l’analyse
faite ci-dessus.

Travail de Bachelor                      Page 24 sur 90                       Vanessa Vitale
4.2.3.2.2       MAQUETTE

Une maquette a été réalisée afin d’identifier au mieux les éléments qui devaient peupler
l’interface selon les changements identifiés et quelle représentation ceux-ci devaient avoir.

Elle a également permis d’avoir une vue d’ensemble de ce à quoi l’interface doit ressembler
comme base pour la programmation de celle-ci.

La première version validée qui a servi de base pour le développement de l’interface se
présente comme suit :

         Maquette
         Figure 6 - Maquette

Travail de Bachelor                    Page 25 sur 90                         Vanessa Vitale
4.2.3.2.3         PRINCIPE GÉNÉRAL

Le plugin MVC-CD se trouve au sein de Visual Paradigm. Il contient le fichier
permanent plugin.properties (4.2.2.2.4 plugin.properties) dans lequel sont spécifiées les
préférences de transformation par défaut. Celles-ci sont utilisées pour paramétrer
l’interface dans un premier temps lors de la partie d’initialisation de celle-ci.

Puis, la seconde étape d’initialisation consiste à récupérer, si elles existent, les préférences
de transformations qui sont stockées dans les propriétés du projet. Dès lors, chaque
préférence présente dans les propriétés du projet remplacera dans l’interface celle
paramétrée lors de la première phase d’initialisation.

A ce moment, le modélisateur a à sa disposition l’interface contenant les préférences
propres au projet. Il peut maintenant modifier les préférences de transformation et
enregistrer ces modifications. Celles-ci sont alors stockées dans le projet.

Le schéma ci-dessous permet d’avoir un premier aperçu du fonctionnement de l’interface :

    Visual Paradigm

          Plugin MVC-CD

                                                                            Interface
                        plugin.properties                 1

                                                               2                        2

                                                      3                          3

                Projet1.vpp                                        Projet2.vpp

                            Properties                                       Properties

  Figure 7 - Schéma de fonctionnement général de l'interface

Travail de Bachelor                                Page 26 sur 90                           Vanessa Vitale
Flux :

    1. Chargement des préférences de transformations par défaut
    2. Chargement des préférences de transformations spécifiques à un projet
    3. Sauvegarde des préférences de transformations spécifiques à un projet

4.2.3.2.4     PLUGIN.PROPERTIES

Le fichier « pluging.properties » est un fichier de propriétés qui stocke les informations
concernant le paramétrage du plugin MVC-CD. Le format de celui-ci se présente comme
suit :

cle=valeur

Voici, une vision non complète du « plugin.properties » du projet afin d’avoir une première
idée de son organisation :

                                Figure 8 - Extrait du plugin.properties

Travail de Bachelor                     Page 27 sur 90                     Vanessa Vitale
4.2.3.3 DÉVELOPPEMENT

Ce chapitre décrit les analyses et réflexions faites lors de la partie développement mais
parle également du développement effectué. Le développement a été séparé en quatre
parties : création du visuel, comportement visuel, chargement des paramètres                 et
sauvegarde des paramètres.

4.2.3.3.1        CRÉATION DU VISUEL

Cette partie comprend tout ce qui concerne la partie visuelle de l’interface pour qu’elle
ressemble à la maquette créée (4.2.2.2.2 Maquette).

Comme cité précédemment, l’interface a été développée en utilisant l’API Swing (3.4 Swing).
Passablement de documentations sur internet ainsi que le travail de O.Bel [LGL-01] ont
permis de comprendre rapidement comment utiliser cette API.

Les principaux composants Swing utilisés lors du développement de cette étape sont les
suivants :

      Case à cocher : JCheckBox
      Bouton radio : JRadioButton
      Texte : JLabel
      Onglets : JTabbedPane
      Organisation des éléments sur la fenêtre :
             o   GridBagConstraints
             o   GridBagLayout
             o   GridLayout
      Conteneur d’élément : JPanel

Ces différents composants sont décrits dans le chapitre 3.4 Swing de ce rapport.

La mise en place de tous ces composants s’est déroulée comme suit :

   1. Création de la classe nommée « DialogueHandler » qui implémente IDialogHandler
       (interface de l’OpenAPI (3.5 OpenAPI) qui permet de créer des fenêtres de dialogue
       dans Visual Paradigm) qui requière l’implémentation des méthodes suivantes :
             a. canClosed() : Fermeture de la fenêtre.
             b. getComponent() : Contiens les composants de la fenêtre.
             c. prepare() : Permet de paramétrer les propriétés de la fenêtre.

Travail de Bachelor                      Page 28 sur 90                          Vanessa Vitale
d. shown()

       La dernière méthode n’ayant pas été utilisée, aucune explication ne sera fournie
       dans ce rapport.
       Le code nécessaire pour créer l’interface se trouve principalement dans cette classe.

   2. Implémentation des différentes méthodes. Le tableau ci-dessous indique le
       comportement dans chaque méthode utilisée :

       Méthode                      Comportement

       canClosed()                    Fermeture de la fenêtre.

       getComponent()                 Création des composants de la fenêtre : onglets, boutons
                                          de fenêtre (« Lancer la transformation » et « Renoncer à la
                                          transformation »).
                                      Appel de la méthode makeFirstTab() pour peupler le
                                          premier onglet.
                                      Positionnement des composants dans la fenêtre avec les
                                          éléments Swing GridBadConstraint et GridBadLayout.

       prepare()                      Paramétrage de la fenêtre (titre de la fenêtre)

       makeFirstTab()                 Création et positionnement de tous les éléments contenus
                                          dans l’onglet « Préférence de transformation ».

   3. Appel de l’interface dans la méthode principale utilisée lors d’une transformation1.
       Le lancement de l’interface se positionne au début de cette méthode afin que le
       paramétrage effectué soit pris en compte lors de la transformation en cours. C’est
       donc au lancement d’une transformation, qu’elle soit lancée depuis n’importe quel
       élément (entité, diagramme, fichier, modèle), que l’interface apparaît :

           Figure 9 - Lancement de la transformation depuis VP

       1
           Méthode déjà existante dans le plugin, seul l’appel de la fenêtre de dialogue a été ajouté.

Travail de Bachelor                                Page 29 sur 90                               Vanessa Vitale
4.2.3.3.2     COMPORTEMENT VISUEL

Le comportement visuel comprend plusieurs points. En se basant sur la maquette :

                                                              Préférence de
                        Éléments              Propriétés
                                                              transformation

               Figure 10 - Maquette - comportement visuel

   1. Sélectionner une des cases à cocher d’un élément dégrise (qui signifie ici « rendre
      sélectionnable ») les cases à cocher des propriétés la concernant.
          a. Par exemple : sélectionner la case « Colonne » dégrisera les cases à cocher
              des propriétés « Nom », « Taille » et « Type » de la colonne
   2. Désélectionner une des cases à cocher d’un élément grise celles de ses propriétés
      (ce qui signifie que les propriétés ne seront plus sélectionnables).
   3. Sélectionner une des cases à cocher d’une propriété dégrise les boutons radio pour
      les préférences de transformation qui la concerne.
   4. Désélectionner une des cases à cocher d’une propriété grise les boutons radio pour
      les préférences de transformation qui la concerne.
   5. Uniquement une des deux préférences de transformation peut être sélectionnée
      (« Forced « ou « Conserved »).

Pour répondre à ces attentes, deux éléments ont été utilisés :

      Listener, décrit dans le chapitre 3.4 Listener.
      ButtonGroup, décrit dans le chapitre 3.3 Swing.

Travail de Bachelor                          Page 30 sur 90                    Vanessa Vitale
Pour les points de 1 à 4         du comportement visuel, les listeners ont été utilisés. Quatre
listeners personnalisés (classes) ont été créés et ajoutés sur des cases à cocher :

                                                        Comportements
Case à         Nom du listener                          (S) = Sélection de la case à cocher
cocher                                                  (D) = Désélection de la case à cocher

Table           CheckBoxTableItemListner
                                                        (S) = Dégrisement de la case à cocher de
                                                        l’élément ainsi que celles de ses propriétés
Colonne         CheckBoxColumnItemListner
                                                        (D) = Grisement de la case à cocher de
                                                        l’élément ainsi que celles de ses propriétés
Association    CheckBoxAssociationItemListner

                                                        (S) = Dégrisement des boutons radio qui
                                                        concernent la case à cocher de la propriété où
                                                        le listener est placé.
Propriétés            RadioButtonListener
                                                        (D) = Grisement des boutons radio qui
                                                        concernent la case à cocher de la propriété où
                                                        le listener est placé.

Le listener RadioButtonListener est placé sur toutes les cases à cocher des propriétés vu
que le comportement attendu est exactement le même.

Pour le cinquième point du comportement visuel, le « ButtonGroup » a été utilisé. Les deux
boutons radio pour la préférence de transformation d’une propriété appartiennent à un
ButtonGroup.

                  Figure 11 - Maquette - comportement visuel - ButtonGroup

Travail de Bachelor                          Page 31 sur 90                              Vanessa Vitale
4.2.3.3.3          CHARGEMENT DES PARAMÈTRES

 Lorsque l’interface ressemble à la maquette et que son comportement visuel correspond à
 ce qui est attendu, le chargement des paramètres se trouvant dans le plugin.properties, puis
 ceux se trouvant dans le projet doit être effectué.

 4.2.3.3.3.1       DÉFINITION DU COMPORTEMENT DES BOUTONS

 Afin de comprendre la suite du chapitre, le comportement des différents boutons de
 l’interface doit être défini. La partie de la maquette qui contient les boutons se présente
 comme suit :

Figure 12 - Maquette - Boutons

 Le comportement des trois premiers boutons du tableau est visible dans le schéma de
 l’interface qui se trouve dans le chapitre 4.2.2.2.3 Principe général.

 Bouton                 Comportement                                                  Schéma de
                                                                                      l’interface

 Annuler                Annule les modifications courantes faites dans l’interface    Flux 2
                        (Reprise des propriétés stockées dans le projet).

 Réinitialiser          Reprends les paramètres par défaut et les affecte à           Flux 1
                        l’interface.

 Appliquer              Enregistre dans le projet les paramètres qui sont sur         Flux 3
                        l’interface.

 Renoncer à la          Ferme l’interface sans lancer la transformation.              -
 transformation

 Lancer la              Lance la transformation.                                      -
 transformation

 Travail de Bachelor                         Page 32 sur 90                          Vanessa Vitale
4.2.3.3.3.2         PROPRIÉTÉS DU PLUGIN.PROPERTIES

Une méthode nommée chargePreferenceTransformationInit , appelée également lors de
l’utilisation du bouton « Réinitialiser » de l’interface, permet d’initialiser les préférences de
transformation par défaut. Ces propriétés se trouvent au sein du plugin.properties.

Cette méthode récupère depuis le plugin.propertise la valeur de la préférence de
transformation par défaut (conserved ou forced) et sélectionne toutes les cases à cocher
ainsi que le bouton radio de la préférence de transformation par défaut de chaque propriété.

4.2.3.3.3.3       PROPRIÉTÉS DU PROJET

Les propriétés d’un projet sont atteignables grâce à la méthode getProjectProperties de
l’OpenAPI (3.5 OpenAPI). Celles-ci sont organisées dans un tableau ou chacune possède un
nom et une valeur. Les noms utilisés pour être stocké dans le projet se retrouvent dans le
plugin.properties et se présente comme suit :

Figure 13 - Plugin.properties - Nom des propriétés

Pour ce qui est des valeurs, celles des cases à cocher peuvent être « selected » ou
« unselected » et celles des boutons radio « conserved » ou « forced ». Ces valeurs sont
également contenues dans le plugin.properties.

Figure 14 -Plugin.properties - valeurs des propriétés

Travail de Bachelor                                     Page 33 sur 90         Vanessa Vitale
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler