656-1.1 Thèse de Bachelor - Rapport de travail Transformation Incrémentale
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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
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
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
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
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
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
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
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
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
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 Vitale1.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 Vitale1.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 Vitale3. 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 Vitale3.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 VitaleCi-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 Vitale3.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 Vitale4. 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 Vitale4.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 VitaleL’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 Vitale4.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 Vitale4.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 VitaleFlux :
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 Vitale4.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 Vitaled. 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 Vitale4.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 VitalePour 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 Vitale4.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 Vitale4.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
