Partie théorique

Transcription

Partie théorique

HEG Arc - Haute école Arc – Gestion
Travail de Bachelor d'informaticien de gestion
Gestion visuelle
d’enchaînements de
pages APEX avec VP
Partie théorique
Nom :
Bel
Prénom :
Olivier
Classe :
4IGTP
Cycle d'études :
2009-2012
École :
HEG-ARC
E-mail :
[email protected]
Date de création : 02.10.2012
Dernière
modification :
14.01.2013
Mode de
réalisation :
Extra-muros
Version :
1.0
Adressé à :
P.-A. Sunier
Restitué :
21.01.2013
C Partie théorique.odt
Table des matières
1 Introduction....................................................................................................................................1
1.1 Le principe de base..................................................................................................................1
1.1.1 Le fichier pivot..................................................................................................................3
2 A propos de ce travail....................................................................................................................4
3 Les risques......................................................................................................................................5
4 Description des principaux logiciels.............................................................................................7
4.1 APEX, description...................................................................................................................7
4.2 Visual Paradigm, description.................................................................................................10
5 Étude d'APEX..............................................................................................................................12
5.1 Avant de commencer.............................................................................................................12
5.2 Structure des métadonnées d'APEX......................................................................................12
5.2.1 Package ApexGen............................................................................................................13
5.2.2 Fichier d'exportation d'application APEX.......................................................................14
5.3 Structure d'une application APEX.........................................................................................15
6 Étude de VP for UML..................................................................................................................17
7 Quel diagramme choisir ?...........................................................................................................20
7.1 Les contraintes.......................................................................................................................20
7.1.1 Les 13 diagrammes UML................................................................................................21
7.1.2 Exemple de diagrammes..................................................................................................21
7.1.3 Remarques.......................................................................................................................24
7.1.4 Les outsiders....................................................................................................................24
7.1.5 Les favoris.......................................................................................................................25
7.1.6 Notre choix......................................................................................................................27
7.2 Les autres diagrammes non UML.........................................................................................28
8 Étude du diagramme retenu.......................................................................................................29
8.1 Le choix du Dependency.......................................................................................................31
8.2 Étude des boutons et branchements......................................................................................31
8.2.1 Les choix..........................................................................................................................32
8.3 Les groupes de pages.............................................................................................................33
9 La modélisation de nos objets Java............................................................................................36
10 Nouveau diagramme ou diagramme existant ?.........................................................................37
Gestion visuelle de pages APEX avec VP
Partie théorique
Auteur
Bel Olivier
1 Introduction
1.1 Le principe de base
Ce travail de Bachelor consiste en l'écriture d'un plugin pour Visual Paradigm for UML (abrégé VP
pour la suite).
Ce plugin1 sera en mesure de lire les métadonnées de APEX pour une application donnée afin de
représenter les pages de celle-ci et leur enchaînement les unes avec les autres dans un diagramme
UML. Les enchaînements, au niveau d'APEX sont provoqués par des action sur des éléments de
page tels que des boutons, branchements, hyperliens, etc.
A terme, ce plugin sera aussi capable de travailler dans l'autre sens à savoir, lire les données du
référentiel VP et créer les pages et les éléments ainsi représentés dans APEX.
Le projet étant tout de même assez complexe, nous avons prévu de décomposer dans un premier
temps le projet en deux parties bien distinctes.
La première partie est une application qui nous permet de lire les métadonnées d'une application
APEX et de représenter cette structure dans un fichier pivot (expliqué plus bas) au format XML.
Elle sera aussi en mesure de faire l'opération inverse à savoir, lire le fichier pivot et modifier les
métadonnées APEX.
La seconde partie est le plugin qui relira les données à partir du fichier pivot afin de représenter la
structure dans le référentiel VP. Le plugin sera aussi en mesure de lire le référentiel VP et de créer le
fichier pivot.
Dans un premier temps, nous nous intéresserons au sens APEX à Pivot à VP afin de représenter
graphiquement les pages d'une application APEX existante et leurs enchaînements les unes avec les
autres.
Idéalement nous devrions pouvoir représenter n'importe quelle application aussi complexe soit-elle.
Initialement nous avions prévu qu'un, voire deux plugins, seraient nécessaires pour la
synchronisation entre VP et APEX dans les deux sens, sans fichier pivot selon le schéma cidessous :
1
[INT 01]
1 / 37
Partie théorique
Auteur
Bel Olivier
Puis après réflexion, nous avons décidé, mon directeur de travail et moi qu'il serait bien de
décomposer le travail de développement en deux parties et d'utiliser un fichier pivot intermédiaire
selon le schéma ci-dessous :
Cette solution offre l'avantage de pouvoir développer, dans un premier temps, deux projets
séparément. Un projet pour ce qui est de la synchronisation entre APEX et le fichier pivot XML et
un autre projet, le plugin, qui se charge de synchroniser le référentiel VP et le fichier pivot XML.
Les deux schémas ci-dessus sont ceux que j'ai repris du document de demande de ratification.
Actuellement il ne m'est pas encore possible de prévoir s'il faudra 1 ou 2 plugins. Si on choisit un
seul plugin, il faudra qu'il soit interactif et nous propose de faire des choix quant au sens de
synchronisation.
Une première phase du développement correspondra au schéma ci-dessous où certains termes ont
été revus et le sens lecture APEX vers représentation VP a été privilégié :
2 / 37
Partie théorique
Auteur
Bel Olivier
Nous avons donc une application Java qui est capable de lire les métadonnées d'une application
APEX et d'écrire cette structure dans un fichier pivot au format XML.
Le plugin quant lui sera capable de relire le fichier pivot et de représenter la structure de celui-ci
dans VP.
A terme, le plugin et l'application Java ne feront qu'un, à savoir un plugin interactif nous demandant
par exemple si l'on veut lire à partir du fichier pivot ou à partir du référentiel APEX.
1.1.1 Le fichier pivot
Comme dit plus haut le fichier pivot nous permet de décomposer le projet en deux parties distinctes
qui sont la lecture des métadonnées APEX puis l’écriture dans le référentiel VP. Il s'agit donc là
d'une sorte de fichier temporaire,
A terme il n'y aura plus qu'un (voire deux) plugin.
Dans le cas d'un seul plugin du moins, il semble que le fichier pivot ne soit alors plus nécessaire
puisqu'il suffit de lire les métadonnées et ensuite de directement écrire dans le référentiel APEX.
Cependant, dans une vision à plus long terme, nous pouvons tout à fait imaginer que le plugin ne
lirais plus les données dans les métadonnées APEX mais seulement à partir du fichier pivot, lequel
serait alimenté par une autre application externe qui, elle, irait relire les données APEX.
Dans cette optique nous choisirons alors de conserver le fichier pivot même après fusion en un seul
ou plusieurs plugins.
3 / 37
Partie théorique
Auteur
Bel Olivier
2 A propos de ce travail
Le travail de Bachelor que l'on m'a proposé se veut être une expérimentation ou une recherche de
faisabilité plus qu'un produit fini et exploitable. A terme, il pourra être modifié et amélioré afin
d'être utilisable par les étudiants de HEG-ARC.
Les objectifs ne sont pas clairement définis mais seront dictés par l'avancement des travaux et les
résultats. Les objectifs sont revus séance après séance par le directeur de travail (PSU) et par moimême.
Ce projet n'est pas un projet tel que l'on en rencontre dans l'industrie, les coûts ne sont pas fixés
pour autant qu'il y en ait. Les temps est fixé idéalement 360 périodes soit 270 heures que je
répartirai sur 15 semaines de 17 heures environ en moyenne.
Il est bon de noter que le développement se fera de manière itérative-incrémentale pour un tel
projet.
4 / 37
Partie théorique
Auteur
Bel Olivier
3 Les risques
Bien que ce travail de Bachelor se veuille être plus une étude de faisabilité que l'attente d'un produit
final fonctionnel, il me parait intéressant de faire une petite analyse quant aux risque de ce projet.
Le développement de plugin ayant déjà été fait avec succès par certains étudiants, cette partie ne
doit pas poser de problèmes particuliers. Pour ce qui est de la relecture des métadonnées APEX il en
va certainement autrement puisque c'est, à ma connaissance, une première dans notre école.
Les risques potentiels devraient normalement uniquement changer le cours du projet, nous obliger à
faire certains choix ou changements mais la finalité sera toujours de faire une analyse de faisabilité
en ayant a disposition un plugin le plus avancé possible.
Voici la liste des risques retenus :
1. Impossibilité de relire le référentiel VP avec l'Open API : Les méthodes à disposition ne
fonctionnent pas comme on le désire ou la maîtrise de cette Open API est trop difficile. Cette
possibilité n'est à vrai dire pas envisageable puisque certains travaux ont été réalisé avec succès
quant à la relecture du référentiel VP. Cependant, si le risque se présentait, le présent travail pourrait
continuer à se faire puisque l'on privilégie d'abord le sens APEX (lecture) vers VP (écriture).
2. Impossibilité d'écrire dans le référentiel VP avec l'Open API : Les méthodes à disposition ne
fonctionnent pas comme on le désire ou la maîtrise de cette Open API est trop difficile. Cette
possibilité n'est à vrai dire pas envisageable puisque certains travaux ont été réalisés avec succès
quant à l'écriture dans le référentiel VP. Cependant, si le risque se présentait, le présent travail
n'aurait plus de sens ou il faudrait envisager d'utiliser un autre outil que VP pour représenter
graphiquement nos pages APEX.
3. Impossibilité de relire les métadonnées APEX : Il n'y a pas d'accès possible aux métadonnées
APEX, ni par des fonctions PL/SQL ni par une accès direct aux tables ou vues ou alors c'est trop
compliqué. Si ce risque ce produisait le projet en soi n'aurait plus de sens car la relecture des
métadonnées d'APEX, c'est le cœur du sujet. On pourrait cependant utiliser notre plugin à partir du
fichier pivot que serait généré « à la main » et non pas à partir d'une relecture des métadonnées
d'APEX.
4. Impossibilité d'écrire dans les métadonnées APEX : Il n'y a pas d'accès possible en écriture
aux métadonnées d'APEX, ni par des fonctions PL/SQL ni par une accès direct aux tables ou vues
ou alors c'est trop compliqué. Si ce risque ce produisait le projet en soi aurait tout de même un sens
puisque l'on privilégie, dans un premier temps, le sens APEX (lecture) vers VP (écriture).
5. Changement de l'Open API dans les futures releases: Si l'Open API venait à être trop
fortement modifiée suite à une mise à jour de VP. Dans ce cas, notre plugin pourrait ne plus
fonctionner du tout. Cependant il est assez inconcevable que l'éditeur de ce logiciel, même en
remaniant complètement son Open API ne se soucie pas de la compatibilité avec les versions
précédentes.
6. Suppression de l'Open API dans les futures releases: Si la possibilité d'écrire des plugin pour
VP venait à disparaître. Cette idée n'est pas envisageable de la part de l'éditeur d'un tel logiciel.
Cependant si cela se produisait, il suffirait de rester avec une ancienne version du logiciel mais avec
les problèmes d'obsolescence que cela engendrerait.
7. Lenteur exagérée du processus : Les risque est que le processus de lecture des métadonnées, de
5 / 37
Partie théorique
Auteur
Bel Olivier
l'écriture du fichier pivot puis de la représentation de la structure avec VP soit trop lent. Ce risque
n'est pas à écarter mais il faudrait que ce processus dure plus d'une minute pour que cela devienne
vraiment problématique. Il faudrait alors se concentrer sur les performances et l'optimisation du
code au détriment de la clarté et de la maintenabilité de celui-ci.
Classement des risques
Certain
7. Lenteur exagérée du
processus
Probabilité à
Très
probable
4. Impossibilité d'écrire
dans les métadonnées
APEX
plausible
1. Impossibilité de relire
le référentiel VP avec
l'Open API
Peu
probable
3. Impossibilité de relire
les métadonnées APEX
2. Impossibilité d'écrire
dans le référentiel VP
avec l'Open API
5. Changement de
l'Open API dans les
futures releases
6. Suppression de l'Open
API dans les futures
releases
impossible
nul
Très limité
sensible
Très
important
Catastrophique
Impact à
Selon le tableau ci-dessus, les éléments à risque les plus importants, dans la partie rouge, concernent
l'impossibilité d'écriture dans le référentiel VP qui s'avère de fait impossible puisque des travaux ont
été menés à bien dans d'autres projets. Quant à la suppression de l'Open API dans des versions
futures elle n'est même pas envisageable.
6 / 37
Partie théorique
Auteur
Bel Olivier
4 Description des principaux logiciels
4.1 APEX, description
Pour rappel ou pour ceux qui l'ignorent APEX2 est un acronyme qui signifie Application Express.
C'est un moyen rapide de créer des applications (RAD3) basées sur une base de données Oracle.
APEX est fourni gratuitement par Oracle lors de l'achat de licences pour leur base de données mais
aussi lors de l'installation de la version gratuite appelé Oracle Express ou Oracle XE.
APEX est une application web pour créer des applications web et qui ne nécessite donc qu'un
browser et un accès à la base de données Oracle.
APEX est en fait aussi une application APEX et est installé automatiquement lors de l'installation de
la base de données.
D'un point de vue pratique, APEX s'utilise presque uniquement avec la souris, le clavier est
uniquement utile pour saisir quelque valeurs, noms de variable ou parties de code.
Il est bien sûr possible d'améliorer les applications par de petits fragments de code en PL/SQL,
JavaScript ou encore du HTML ou des styles CSS.
APEX s'appuie sur les assistants pour guider l'utilisateur lors de la conception de ses applications.
De par la rapidité de développement, APEX est souvent utilisé pour le prototypage d'applications.
La version utilisée pour ce travail est le version Oracle XE 11g2.
La définition d'une application APEX est en fait représentée dans ce que l'on appelle les
métadonnées. Les métadonnées sont des données présentent dans la base Oracle mais elles
représentent la structure de l'application.
Nous avons donc, dans le schéma APEX, des tables pour y stocker des pages, des éléments de page
(boutons, navettes, hyperliens, menus, etc.).
De plus, des packages et des fonctions PL/SQL spécifiques sont à disposition du développeur pour
créer des applications APEX.
Ces fonctions sont bien entendu utilisées par APEX mais elles sont aussi disponibles par tout un
chacun. Malheureusement ces fonctions sont pas ou peu documentées.
Voici un écran APEX représentant les applications présentes dans un espace de travail (workspace)
donné :
2
3
[INT 02]
[INT 03]
7 / 37
Partie théorique
Auteur
Bel Olivier
Et voici, depuis SQL-Developer, la vue Oracle contenant la définition de ces applications :
Voici à quoi ressemble la partie conception d'une page APEX :
8 / 37
Partie théorique
Voici un autre exemple de vue nous renseignant sur les pages d'une application :
9 / 37
Auteur
Bel Olivier
Partie théorique
Auteur
Bel Olivier
4.2 Visual Paradigm, description
Visual Paradigm et plus précisément Visual Paradigm for UML4 que nous abrégerons par la suite
par VP est un outil permettant la conception de diagrammes UML. Les 13 diagrammes de la norme
sont supportés mais il est possible de créer encore d'autres diagrammes non UML.
La société éditrice de ce produit se nomme tout simplement Visual Paradigm International.
Cet outil est bien plus qu'un simple outil de conception de diagrammes. En effet, il est par exemple
possible de générer du code à partir de diagrammes ou éléments de diagrammes. Plusieurs langages
sont bien entendu supportés tels que Java, C#, C++, etc.
Il est aussi possible, à partir de code source de générer les diagrammes UML, notamment des
diagrammes de classe.
Lorsque nous travaillons dans VP, nous travaillons donc sur un projet VP. Ce projet est composé
d'éléments de modèle que nous appellerons aussi le référentiel VP. Ces éléments de modèle
(paquetages, classes, attributs, acteurs, etc.) peuvent être représentés graphiquement sur un
diagramme approprié.
Voici une capture d'écran sur laquelle on peut voir un diagramme de classe à droite et le navigateur
de diagrammes à gauche :
Voici une vue de l'explorateur de modèles et les éléments du modèle pour un projet donné :
4
[INT 04]
10 / 37
Partie théorique
Auteur
Bel Olivier
Il est important de comprendre que l'on peut créer des éléments dans le modèle sans forcément les
représenter graphiquement. A l'inverse lorsque nous créons des éléments graphiques dans la zone
d'un diagramme, l'élément du modèle est forcément créé dans le modèle.
Enfin VP nous offre la possibilité de créer ou lire des éléments du modèle et graphiques à partir de
plugins écrits en java. Ces plugins utilisent alors une Open API offerte par VP présente dans le
dossier lib du répertoire d'installation de l'application.
Pour notre projet nous devrons choisir le type de diagramme qui sera le plus approprié pour
représenter les pages, régions, liaisons et autres éléments de page composant une application APEX.
Le diagramme de communication semble être bien adapté à cette représentation mais une étude plus
approfondie devra tout de même être faite à ce sujet.
Nous n'allons pas détailler ici l'utilisation de VP mais exposer les points importants pour le présent
projet.
VP est un programme écrit en Java ce qui fait que les plugins doivent aussi être écrit dans ce
langage qui est justement celui utilisé tout au long de ma formation.
Sur le site de l'éditeur du logiciel nous pouvons trouver quelques tutoriels pour la mise en œuvre
d'un tel plugin.
Le détail de l’implémentation sera vu dans la partie pratique du rapport.
11 / 37
Partie théorique
Auteur
Bel Olivier
5 Étude d'APEX
Nous allons maintenant étudier APEX au niveau des éléments qui nous intéressent, à savoir les
métadonnées. Nous allons aussi voir comment y accéder et rechercher les informations qui nous
intéressent dans le cadre de notre projet.
Nous allons aussi étudier les packages et les fonctions disposition et voir où cela se trouve et
comment y accéder.
Nous allons aussi voir comment nous pouvons trouver l'information grâce aux exemples à notre
disposition.
5.1 Avant de commencer
Avant de commencer à pouvoir utiliser APEX dans le cadre de ce projet, il faut bien entendu
télécharger la version gratuite d'Oracle. Cette version sera la version 11g2.
Une fois cette version installée, nous avons tout naturellement accès à APEX qui est installé par
défaut.
Pour pouvoir créer une application APEX, il faut disposer d'un espace de travail, d'un nom
d'utilisateur et du mot de passe.
L'administrateur de la base de données peut créer et donner les accès en question.
Chaque utilisateur connecté peut alors créer ses propres applications.
5.2 Structure des métadonnées d'APEX
La structure d'une application APEX est en fait stockée dans plusieurs tables de la base de données
Oracle. Nous appellerons cette structure les métadonnées d'APEX.
Ces métadonnées sont donc des tables et des vues non modifiables sur ces tables et qui peuvent être
consultées sans problèmes par n'importe que utilisateur.
Pour ce projet, j'ai donc utilisé SQL-Developper pour parcourir et étudier ces métadonnées. En plus
de ces métadonnées, nous pouvons aussi voir les packages et fonctions utilisables pour lire,
modifier et créer des applications ou éléments d'applications APEX.
Ces métadonnées sont la propriété d'un utilisateur particulier appelé APEX_040000 (le nom peut
différer selon la version) mais tout utilisateur connecté peut y accéder en lecture écriture et en
utilisation pour ce qui est des fonctions PL/SQL.
12 / 37
Partie théorique
Auteur
Bel Olivier
Oracle ne propose pas de documentation quant à ces métadonnées et il nous incombe donc de tenter
de comprendre comment est structurée une telle application.
Les pistes principales que j'ai retenues sont au nombre de trois :
•
Recherche Google.
•
Étudier le package ApexGen5.
•
Étudier les fichiers d’exportation d’applications.
5.2.1 Package ApexGen
ApexGen, « A utility to generate Oracle Application Express pages based on a PL/SQL API » selon
la description de l'auteur.
Ce paquetage open-source est en fait un utilitaire permettant de créer des pages dans une
application APEX sans être dans APEX, un peu à la manière de notre futur plugin. En étudiant ce
paquetage, nous remarquons que l'auteur s'est fortement inspiré des fichiers d'exportation
d’application ou de page APEX. Il semble que le projet soit arrêté depuis le 16-07-2009.
Plus précisément ApexGen est un utilitaire composé de fonctions PL/SQL qui permet de générer du
code PL/SQL. Ce code généré nous permettant de créer des pages pour une application APEX.
Autrement dit c'est un générateur de fichier d'importation de pages d'application APEX.
Voici la liste des fonctions d'ApexGen :
apexgen_pkg
•
•
•
•
•
•
init
set_option
add_report_page
add_form_page
add_child_region
generate
A y regarder de plus près, et après avoir lu la documentation contenue dans le fichier zip téléchargé
sur le site de l'éditeur, il s'avère que les quelque fonction proposées par ApexGen nous permettent
de créer deux type de pages : Les pages de rapport et les pages de formulaire. On peut aussi ajouter
une région sur les pages. Le code est très similaire au code contenu dans les fichiers d'exportation
5
[INT 05]
13 / 37
Partie théorique
Auteur
Bel Olivier
d'application que nous verrons juste plus loin.
Nous remarquons les commandes print permettant d'écrire le code généré dans un fichier. Le
fichier pourra ensuite être exécuté et les pages de l'application seront alors importées dans APEX.
ApexGen est un package PL/SQL qui possède des fonctions pour générer du code PL/SQL pour
créer des pages ou éléments de pages dans une application.
De façon un peu similaire, nous devrons, en Java, créer des méthodes qui créeront des pages ou des
éléments de pages dans une application APEX.
L'étude de ce package peut donc s'avérer très utile pour notre projet de plugin.
Voici un extrait d'un fichier généré par ApexGen :
5.2.2 Fichier d'exportation d'application APEX
Le résultat d'une exportation d'application APEX est en fait un très volumineux fichier de
commande PL/SQL nécessaire pour recréer l'application APEX. L'étude d'un tel fichier nous donne
une idée des fonctions à utiliser et des paramètres à leur passer.
14 / 37
Partie théorique
Auteur
Bel Olivier
Voici un extrait du contenu d'un fichier d'exportation d'application APEX :
Dans cet exemple nous voyons le nom du package : wwv_flow_api et le nom de la fonction
invoquée : create_flow ainsi que tous les paramètres renseignés et leurs valeurs.
Un tel fichier d'export ne fait qu'écrire des données et ne fait en aucun cas de la lecture de données.
Pour notre projet, le plus important dans un premier temps c'est de pouvoir lire et comprendre les
métadonnées.
Pour ce faire, il faut donc plutôt se tourner vers les vues et les tables que nous pourrons interroger.
Cette partie sera vue dans la partie pratique de ce rapport.
5.3 Structure d'une application APEX
Afin de pouvoir représenter au mieux notre application APEX dans VP et avant d'étudier cette
représentation dans VP, il est important de comprendre comment est structurée une application
APEX.
Une application APEX est en fait composée de plusieurs pages. Un page est composée de zéro ou
plusieurs régions. Une région contient zéro ou plusieurs éléments déclencheurs d'une action de
redirection (bouton, branchements, hyperlien, etc.) .
Par cette description nous comprenons qu'une page est un conteneur de régions et qu'une région est
un conteneur d’éléments déclencheurs d'actions.
Pour cette analyse nous nous arrêterons aux seuls boutons en tant qu'éléments déclencheurs d'une
action de redirection quand bien même il y a d'autres éléments APEX susceptibles de provoquer des
redirections.
Au niveau de la structure des métadonnées, cette relation conteneur-contenu est en fait représenté
par des éléments ayant des id et des éléments ayant des références vers ces id.
Une pages possède un id mais ne connais pas les éléments qui la compose. Par contre une région
possède aussi un id mais aussi une référence vers la page sur laquelle elle est placée.
Voici une représentation des relations entre ces divers éléments APEX :
15 / 37
Partie théorique
Auteur
Bel Olivier
Les attributs ne sont bien entendu pas tous représentés mais les principaux qui nous permettent de
comprendre comment sont faites les relations entre nos divers éléments.
Nous voyons qu'une région possède un attribut PAGE_ID qui contient l'id de la page dans laquelle
elle est placée.
Pour ce qui est du bouton, il possède aussi un attribut nous permettant de savoir sur quelle page il se
trouve mais aussi dans quelle région il se situe.
Il y a là une petite redondance d'information au niveau du bouton. En effet il semble inutile de
connaître sur quelle page il se situe puisque l’information quant à la région est en soi suffisante.
Voici une autre représentation de la structure d'une application APEX :
16 / 37
Partie théorique
Auteur
Bel Olivier
6 Étude de VP for UML
Bien avant de commencer à écrire un plugin ou même de tester quelque plugin que ce soit, il est
nécessaire de se pencher sur l'outil qu'est VP.
VP c'est, entre autre, un outil permettant de créer des diagrammes UML qui sont au nombre de 13.
Les éléments (Acteurs, ligne de vie, packages, classes, etc.) crées dans VP sont en fait stockés dans
ce que l'on appelle le référentiel VP et que l'éditeur appelle le modèle.
Ces éléments sont bien entendu affichables dans des diagrammes pour le côté visuel.
VP offre la possibilité de générer du code dans divers langages à partir de ces schémas UML ou
inversement il permet de recréer des schémas à partir de codes sources.
Il est intéressant de comprendre comment sont représentés les éléments UML dans le référentiel ou
le modèle :
Ci-contre nous avons une vue du modèle, la
représentation en mémoire du référentiel.
Notre projet, la racine du modèle
Un objet Frame
Un objet Lifeline
Un objet Actor
Les relation entre les divers objets ne sont pas représentées dans le modèle mais sont en fait
mémorisés sous forme de propriétés de ces objets comme le montre la capture ci-dessous.
17 / 37
Partie théorique
Auteur
Bel Olivier
Donc, pour l'écriture de notre plugin, nous devrons être en mesure de créer les divers éléments dans
le modèle.
Les éléments crées peuvent bien entendu être visualisées sous forme de diagrammes comme dans la
représentation ci-dessous :
Lorsque l'on crée des éléments dans le modèle, ils ne sont pas représentés graphiquement alors que
lorsque l'on crée les éléments de manière graphique (à la souris et non pas par code), ils sont
forcément présents aussi dans le modèle.
18 / 37
Partie théorique
Auteur
Bel Olivier
Pour notre plugin, nous devrons bien entendu aussi représenter nos éléments de manière graphique.
Nous devrons donc, lorsque nous dessinerons le diagramme représentant notre application APEX,
créer les éléments du modèle mais aussi les formes représentant ceux-ci sur le diagramme en
question.
19 / 37
Partie théorique
Auteur
Bel Olivier
7 Quel diagramme choisir ?
Nous allons maintenant tenter d'étudier les divers types de diagrammes à disposition et tenter de
trouver celui qui nous permet de représenter au mieux les pages de notre application APEX et leur
enchaînement.
Nous étions partis, lors du choix de ce travail de Bachelor, sur le diagramme de communication qui
semble à priori bien adapté pour une telle représentation mais il me semble tout de même
indispensable, dans le cadre d'un tel projet, de faire une étude plus approfondie afin d'être certain
d'avoir choisi le bon diagramme.
En effet, il serait difficilement envisageable de changer de type de diagramme une fois notre plugin
écrit et fonctionnel.
Il faut noter qu'il ne s'agit pas ici d'expliquer en détail les finesses et particularités de chaque
diagramme car il ne s'agit pas d'un cours UML mais nous allons tenter d'en trouver un qui satisfasse
à nos besoins en respectant si possible le standard UML.
Il est bon de rappeler qu'UML offre un standard de modélisation pour représenter une architecture
logicielle et que son utilisation est laissée à l'appréciation de chacun.
Donc, nous pouvons dire que l’utilisation d'UML dans le cadre de ce projet consistant à représenter
graphiquement l’enchaînement de pages d'une application APEX n'est pas du tout une utilisation
abusive de ce standard.
7.1 Les contraintes
Avant de choisir quel serait le ou les diagrammes potentiellement utilisables, nous devons définir
quels sont les critères de choix pour cette décision.
Voici une liste de contraintes :
•
Notre diagramme doit nous permettre de définir des liens entre l'élément déclencheur d'une
redirection (bouton, branchement, etc.) et la page de destination.
•
Nous devons pouvoir représenter une page d'une manière évidente.
•
L'élément choisi pour représenter une page doit être un conteneur.
•
Nous devons pouvoir représenter une région de manière évidente.
•
L'élément choisi pour représenter une région doit être un conteneur.
•
Nous devons pouvoir représenter des boutons et autres éléments déclencheurs d'une
redirection de manière évidente.
La notion de conteneur-contenu est très importante car il faut, lorsque l'on déplace une page de
notre diagramme, que les éléments la composant se déplacent aussi avec celle-ci.
A priori nous choisirons un diagramme UML parmi les 13 à disposition. Cependant, rien ne nous
empêche à en choisir un autre puisque VP for UML nous propose une dizaine d'autres diagrammes
divers.
20 / 37
Partie théorique
Auteur
Bel Olivier
7.1.1 Les 13 diagrammes UML
Voici la liste des 13 diagrammes UML à notre disposition pour ce projet :
1. Use Case Diagram,
2. Class Diagram,
3. Sequence Diagram,
4. Communication Diagram,
5. State Machine Diagram,
6. Activity Diagram,
7. Component Diagram,
8. Deployment Diagram,
9. Package Diagram,
10. Object Diagram,
11. Composite Structure Diagram,
12. Timing Diagram,
13. Interaction Overview Diagram.
7.1.2 Exemple de diagrammes
Voici un aperçu des 13 différents diagrammes UML avec leur nom en français. Ces diagrammes ont
été élaborés selon mes connaissances et/ou selon les exemples donnés sur le site de l'éditeur6:
Use Case Diagram (Diagramme de cas d'utilisation) :
6
[INT 14]
21 / 37
Partie théorique
Class Diagram (Diagramme de classes) :
Sequence Diagram (Diagramme de séquence) :
Communication Diagram (Diagramme de communication) :
State Machine Diagram (Diagramme d'automate fini) :
Activity Diagram (Diagramme d'activités) :
22 / 37
Auteur
Bel Olivier
Partie théorique
Component Diagram (Diagramme de composants) :
Deployment Diagram (Diagramme de déploiement) :
Package Diagram (Diagramme de package) :
Object Diagram (Diagramme d'objets) :
23 / 37
Auteur
Bel Olivier
Partie théorique
Auteur
Bel Olivier
Composite Structure Diagram (Diagramme de structure composite) :
Timing Diagram (Chronogramme) :
Interaction Overview Diagram (Diagramme d’interactions) :
Ce diagramme est en fait un méta-diagramme regroupant plusieurs diagrammes de séquence ou
d'activité. C'est un moyen d'avoir une vue d'ensemble de plusieurs diagrammes détaillés et les
enchaînements entre ceux-ci. Cet enchaînement pourrait nous être utile selon comment nous
voudrions représenter l'enchaînement de nos pages APEX.
7.1.3 Remarques
Certains éléments de diagrammes se retrouvent dans plusieurs diagrammes tels que :
•
Actor (acteur)
•
Class (classe)
•
Lifeline (ligne de vie)
•
Package (Paquetage)
•
etc.
Les package sont même disponibles pour tous les diagrammes UML. Ils sont très intéressants pour
notre projet puisque ce sont des conteneurs et qu'un package peut contenir un autre package.
Certains diagrammes sont des spécialisations d'autres diagrammes selon Wikipedia7.
Certains diagrammes appartiennent donc à la même famille que d'autres diagrammes et ne diffèrent
que peu. Par exemple le diagramme de classe et le diagramme d'objet sont assez proches.
7.1.4 Les outsiders
Suite à cet aperçu des différents diagrammes nous pouvons d'emblée en éliminer certains qui ne
7
[INT 14]
24 / 37
Partie théorique
Auteur
Bel Olivier
satisfont évidemment pas à nos besoins.
En voici la liste et les raisons :
Diagramme
Raisons
Use Case Diagram.
Les cas d'utilisations, sont de forme ovale et ne
sont pas des conteneurs.
Ils pourraient éventuellement représenter les
boutons mais ils ne peuvent être reliés à des
system ou package autrement que par des
generic connector.
Sequence Diagram.
Les lifeline et les éléments à disposition ne sont
de toute évidence pas adaptés à notre
représentation.
State Machine Diagram.
Diagramme trop limité, pas possible d'avoir des
éléments conteneurs.
Component Diagram.
Stéréotype <<component>> impossible à
supprimer, et symbole
toujours présent.
Cela alourdi inutilement le diagramme.
Deployment Diagram.
Utilise aussi des composants. Donc même
remarque que ci-dessus.
Timing diagram.
Totalement inadapté.
7.1.5 Les favoris
Parmi les diagrammes qui semblent être de bons candidats nous pouvons citer :
1. Class Diagram,
2. Communication Diagram,
3. Activity Diagram,
4. Package Diagram,
5. Object Diagram,
6. Composite Structure Diagram,
7. Interaction Overview Diagram.
Nous allons donc tenter de déterminer quel est le diagramme le plus approprié grâce à ce tableau et
notre liste de critères :
Diagramme
Class Diagram
8
Représentation
d'une
L'élément pour
page de manière la page est un
évidente ?
conteneur.
Représentation
d'une région de
manière
évidente.
Oui, class ou
package.
Oui, class ou
package
Oui, package.
Selon les éléments utilisés pour les pages et les boutons.
25 / 37
L'élément pour
la région est un
conteneur.
Représentation
d'un bouton et
autres
déclencheurs
d'action de
manière
évidente.
Liens entre
boutons et pages
possibles8
Oui, package
Oui, class
Oui, plusieurs
Partie théorique
Auteur
Bel Olivier
L'élément pour
la région est un
conteneur.
Représentation
d'un bouton et
autres
déclencheurs
d'action de
manière
évidente.
Liens entre
boutons et pages
possibles
Diagramme
Représentation
d'une
L'élément pour
page de manière la page est un
évidente ?
conteneur.
Représentation
d'une région de
manière
évidente.
Communication
Diagram
Oui lifeline ou
package.
Oui, package.
Oui, lifeline ou
package.
Oui, package.
Oui, lifeline.
Oui, plusieurs.
Oui, activity ,
object node ,
action ou
package.
Oui, package ou
activity.
Oui, activity ,
object node ,
action ou
package.
Oui, package ou
activity.
Oui action ou
object node.
Oui control flow.
Activity Diagram
Package Diagram
Oui, class ou
package.
Oui, package.
Oui, class ou
package.
Oui, package.
Oui, class .
Oui, dependency.
Object Diagram
Oui, class,
instance ou
package.
Oui, package.
Oui, class,
instance ou
package.
Oui, package.
Oui, class ou
instance.
Oui, dependency.
Composite Structure
Diagram
Oui, class,
attribute ou
package.
Oui, package ou
class.
Oui, class,
attribute ou
package.
Oui, package ou
class.
Oui, class ou
attribute.
Oui, dependency.
Interaction Overview
Diagram
Oui, activity ,
object node ,
action ou
package.
Oui, package ou
activity.
Oui, activity ,
object node ,
action ou
package.
Oui, package ou
activity.
Oui, action ou
object node.
Oui, control flow.
A propos de ce tableau, il est intéressant de remarquer que les 7 diagrammes ci-dessus pourraient
faire l'affaire et que dans tous les cas ils répondent à tous nos critères.
Au niveau des représentations des liens entre les pages, c'est aussi toujours possible mais notons
que dans tous les cas il y a le connecteur générique qui connecte tout avec tout si besoin est.
Puisque les 7 diagrammes peuvent à priori faire l'affaire, nous allons tenter d'établir d'autres critères
pour affiner notre sélection. A priori il s'agira de critères esthétiques et ceux concernant les liaisons.
En effet l'utilisation d'un élément de type Dependency (dépendance) n'est pas forcément logique
puisque nous ne pouvons pas parler de dépendance entre un bouton et une page appelée mais plutôt
de liaison (Link) ou de message envoyé.
Parmi les diagrammes comportant plusieurs possibilités quant aux liaisons, nous pouvons retenir les
diagrammes les plus connus que sont le diagramme de classe et le diagramme de communication.
Le diagramme d'objet peut être d'emblée écarté puisqu'il est très proche du diagramme de classe
mais en plus limité quant aux relations offertes entre les éléments.
Voici la liste de ces critères pour les 6 diagrammes restant :
Élément de modèle pour représenter...
Nouveaux critères :
Diagramme
Page
Région
Bouton
Esthétisme
Lien logique.
Lien pratique.
Class Diagram
package
package
class
Bon
Aucun
Usage ou
Dependency.
Communication
Diagram
package
package
lifeline
Bon
Aucun9
Dependency
package
activity
object node ou
action.
Bon
Aucun
Seulement
Generic
connector.
Activity Diagram
9
Un lien Link + Message a pu être fait par programmation mais pas par l'interface VP.
26 / 37
Partie théorique
Auteur
Bel Olivier
Élément de modèle pour représenter...
Nouveaux critères :
Page
Région
Bouton
Esthétisme
Lien logique.
Lien pratique.
package
package
class
Bon
Aucun
Seulement
Generic
connector
Composite Structure
Diagram
package
package ou
class.
class, attribute
Bon
Aucun
Dependency
Interaction Overview
Diagram
package.
activity
object node ou
action
Bon
Aucun
Generic
connector
Diagramme
Package Diagram
Au terme de cette analyse nous ne sommes toujours pas en mesure de sélectionner le bon
diagramme. Au niveau esthétique, ils se valent, à savoir que l'on prendra forcément un package
pour représenter une page APEX. La région peut, selon le diagramme choisi, être représentée par un
package, une class ou une activity.
Pour ce qui est des liens entre les pages, nous ne pouvons malheureusement pas choisir de lien en
rapport avec la logique d’enchaînement. Nous ne disposons que de Dependency ou Generic
connector. Nous aurions bien voulu pouvoir choisir soit un link avec Message ou un control flow
mais impossible vers un package, quel que soit le diagramme.
7.1.6 Notre choix
Les premiers tests de programmation ayant été fait sur la base d'un diagramme de communication, il
serait tentant de conserver celui-ci.
Cependant le diagramme d'activité peut s'avérer aussi très intéressant de par le fait que l'on peut
utiliser un autre élément que la package pour représenter une région à savoir l'activity. Les liens
seront alors à faire avec des generic connector.
Voici ce que donne une représentation d'une application APEX avec les deux digrammes potentiels :
Diagramme de communication
Composé ainsi:
Page:
package
Région: package
Bouton: lifeline
Liens: dependency
Diagramme d'activité
Composé ainsi:
Page:
package
Région: activity
Bouton: action
Liens: generic connector
Au terme de cette étude nous allons donc en rester au diagramme de communication puisque rien
27 / 37
Partie théorique
Auteur
Bel Olivier
ne va à l'encontre de cette idée et que nos premiers tests ont été faits avec ce diagramme.
7.2 Les autres diagrammes non UML
Parmi les autre diagrammes proposés par VP for UML, il y a aussi quelque diagrammes non-UML
tels que :
1. Diagramme de critères (Exigences),
2. Diagramme de base,
3. Diagramme entité-relation,
4. Diagramme ORM,
5. Diagramme de définition de bloc,
6. Brainstorm.
Après avoir eu un bref aperçu de ces diagrammes, il ne semble pas utile de les détailler puisqu'ils ne
correspondent pas à nos attentes et ne sont parfois que des variantes spécifiques des principaux
diagrammes UML.
28 / 37
Partie théorique
Auteur
Bel Olivier
8 Étude du diagramme retenu
Le diagramme que nous avons donc retenu au terme de cette étude est donc le diagramme de
communication.
Les éléments que nous allons retenir pour notre représentation comporterons des stéréotypes 10 afin
d'identifier clairement leur utilité au niveau du diagramme et ainsi en améliorer la compréhension.
Lorsque plus tard nous seront en mesure de générer une application ou partie d'application à partir
de notre plugin, les stéréotypes nous permettrons d’identifier de manière plus stricte nos divers
éléments du diagramme.
Les stéréotypes retenus sont donc les suivants :
Stéréotype
Usage
<<Page APEX>>
Page
<<Bouton APEX>>
Région
<<Région APEX>>
Bouton
<<Branchement APEX>>
Branchement
<<Liste APEX>>
Liste
<<Breadcrumb APEX>>
Breadcrumb
<<Bar nav APEX>>
Barre de navigation
Les éléments retenus pour représenter nos pages, avec leur stéréotype, éléments de pages et liaisons
sont les suivants :
10 [INT 15]
29 / 37
Partie théorique
Élément VP
Correspondance APEX
Package (Ensemble)
Page
Package (Ensemble)
Région
Lifeline (Ligne de vie)
Lifeline
Lifeline
Lifeline
Lifeline
Dependency
Auteur
Bel Olivier
Bouton
Branchement
Liste
Breadcrumb
Barre de navigation
Redirection vers une page
Generic connector ou
Dependency
Déclenchement d'un branchement par un bouton
Notons que, en plus des stéréotypes pour nous aider à comprendre le diagramme et la structure de
notre application, nous pourrons, par la suite, ajouter des couleurs de remplissage ou de contour
pour nos divers éléments selon l'exemple ci-dessous :
30 / 37
Partie théorique
Auteur
Bel Olivier
8.1 Le choix du Dependency
Plus en avant dans notre étude nous avions affirmé que le dependency, autrement dit la dépendance
n’était pas franchement appropriée pour représenter nos enchaînements de pages.
Nous aurions préféré utiliser le lien avec message ou le control de flux qui paraissaient être plus en
rapport avec nos enchaînements.
En effet il semblait absurde d'affirmer qu'un bouton et une page dépendent l'un de l'autre.
Cependant, après plus mure réflexion il n'est pas faux d'affirmer que l’existence d'un bouton sur une
page donnée dépend de l’existence d'une page vers laquelle il nous redirigera. En ce sens nous
sommes en accord avec le paradigme UML.
Nous nous contenterons certainement aussi de la dépendance pour relier un bouton et un
branchement comme sur l'Illustration 1 de la page suivante.
8.2 Étude des boutons et branchements
Maintenant que nous sommes en mesure de créer nos diagrammes, posons-nous quelques questions
au sujet des boutons et des branchements.
Il faut savoir que tous les boutons ne possèdent pas forcément une adresse de redirection vers une
autre page.
La question se posera alors de savoir si l'on affiche tous les boutons ou seulement ceux qui ont une
adresse de redirection.
Concernant les branchements, il en sera de même. Cependant il est bon de noter que le
31 / 37
Partie théorique
Auteur
Bel Olivier
déclenchement d'un branchement se fait souvent à partir d'un bouton.
La question qui nous vient immédiatement à l'esprit est de savoir si l'on doit alors faire ressortir
cette dépendance entre ces éléments.
Si oui, il faut alors représenter les boutons en question et aussi un lien entre celui-ci et le
branchement.
Le diagramme suivant illustre cette idée :
Le bouton CANCEL redirige directement vers
une autre page.
Le bouton SAVE par contre déclenche un
branchement qui, lui, redirige vers une autre
page.
Illustration 1
Il est aussi possible de choisir autre chose qu'un dependency pour cette liaison. On pourrait utiliser
soit une link + message soit un generic connector.
8.2.1 Les choix
Nous avons maintenant plusieurs choix à faire parmi lesquels :
•
Présence de tous les boutons ou les seulement ceux qui redirigent directement ?
•
Présence des boutons qui déclenchent un branchement ?
•
Affichage du lien entre bouton et branchement ?
•
Si oui, type de lien ?
Voici un petit tableau qui va nous permettre de faire nos choix :
Affichage
Pour
contre
Tous les boutons
• Tout est là.
• Surcharge le diagramme.
• Plus lent à générer le
diagramme.
Bouton vers branchement
• Clarté, on comprend mieux
le fonctionnement, sur
quelle
action
le
branchement se fait.
• Complexité.
32 / 37
Partie théorique
Affichage
Pour
Auteur
Bel Olivier
contre
Lien type Dependency vers
branchement.
• Standard UML, on peut
affirmer
aussi
que
l’existence du branchement
dépend du bouton qui le
déclenche.
• Confusion entre les liens
entre les pages et celui
entre le bouton et le
branchement.
(Vite remplaçable par un
lien de type generic
connector.)
Lien type link + message vers
branchement.
• Différenciation du type de
lien par rapport aux liens
vers les pages.
• Pas facile à mettre en
œuvre selon les tests faits
avec Open API.
• Bugs constatés au niveau
de VP aussi.
Lien type generic connector
vers branchement.
• Différenciation du type de
lien par rapport aux liens
vers les pages.
• Ce connecteur n'est pas
très UML de par le côté
générique.
(Vite remplaçable par un
lien de type dependency)
Selon le tableau ci-dessus, les choix que nous allons faire sont les suivants :
•
Nous allons donner le choix de d'afficher ou non les boutons qui ne redirigent pas ou ne
déclenchent pas branchement.
•
Même si c'est plus complexe à mettre en œuvre nous représenterons des boutons qui
déclenchent un branchement.
•
Nous allons si possible utiliser le generic connector puisqu'il se distingue des dependency
utilisés, eux, pour les pages. De plus ils seront vite remplaçables par des dependency. De
plus, de par le fonctionnement erratique des link avec message nous oublierons cette
solution.
8.3 Les groupes de pages
Lorsque nous travaillons avec APEX sur une application comportant un grand nombre de pages, il
nous est possible de créer des groupes et d'y placer les pages désirées en fonction de nos critères.
Ceci peut être très utile lorsque plusieurs personnes travaillent sur une même application, chacun
s'occupant de sa partie et ne s'occupant que des pages du ou des groupes le concernant.
Cette représentation serait intéressante à conserver au niveau de VP. En effet, puisque les
développeurs APEX choisissent de créer des groupes de pages, il semble logique de reprendre cette
logique et de représenter un diagramme par groupe de pages.
Voici au niveau du modèle VP ce que donne la structure si l'on a deux diagrammes composés d'une
page chacun :
33 / 37
Partie théorique
Auteur
Bel Olivier
Selon la structure du modèle ci-contre, chaque
diagramme est un élément de type Frame.
Les éléments composant nos pages ne sont pas
imbriqués dans le Frame et il n'est pas possible de forcer
cela.
Cependant, nous pouvons alors créer des éléments
Model pour représenter nos groupes et y placer nos
pages correspondantes comme le montre la structure du
modèle ci-contre.
Par élément Model il faut comprendre qu'il s'agit en fait
d'un élément de sous-modèle.
Les éléments Model nous permettent seulement de
regrouper nos pages au niveau du modèle.
Les affichages des pages des divers groupes se feront
dans les diagrammes respectifs et pourront même être
représentées toutes à la fois dans un autre diagramme
plus général.
Voici les captures d'écran des 3 diagrammes :
34 / 37
Partie théorique
Auteur
Bel Olivier
Puisque nous devons représenter les enchaînements de nos pages, il va falloir aussi le faire même si
une page d'un groupe peut nous ramener à une page d'un autre groupe.
Dans ce cas, la représentation de la page en question apparaîtra dans deux, voire plusieurs groupes.
Il faudra voir la faisabilité de cette gestion de groupes et des diagrammes y relatifs dans la partie
pratique.
Si nous voulons permettre la représentation de nos groupes de pages dans des diagrammes
différents, il va bien entendu falloir rechercher cette information au niveau de APEX.
Cette recherche d'information se fera dans tous les cas même si elle ne sera peut-être pas prise en
compte dans VP de par sa complexité.
A noter que si des pages ne font partie d'aucun groupe, nous créerons de toute manière un groupe
par défaut pour celles-ci.
35 / 37
Partie théorique
Auteur
Bel Olivier
9 La modélisation de nos objets Java
Nous savons maintenant que, au niveau de VP, nos pages contiennent ou sont composées de
régions, que ces mêmes régions contiennent des boutons. Nos pages contiennent aussi des
branchements qui ne sont, elles, pas dans des régions.
Nous savons aussi que nos pages seront parfois dans des groupes de pages, parfois pas.
Reste maintenant à modéliser cette structure.
Comme un projet est composés de groupes de pages, il semble logique que la classe Project soit
composés d'objets de class Group. Cette composition se fera sous la forme d'une collection d'objets
Group.
Nous parlons ici plutôt de composition et non pas d'agrégation puisque si un projet est supprimé, les
objets englobés le seront aussi. En effet, l'existence d'une page par exemple n'a pas de sens si
l'application n'existe plus.
Une page sera aussi composée de branchements (Branch) et de régions (Region).
Une Region sera composée de Button.
Selon ce modèle, il sera aisé de parcourir tous nos objets en partant de la classe racine Project.
Voici une illustration de ce modèle :
Dans le modèle ci-dessus, les éléments actifs sont donc les boutons et les branchements. Cependant,
par la suite, il faudra faire avec d'autres composants pour représenter tous les cas possibles. Mais
par souci de de clarté nous nous sommes arrêtés à ces deux seuls éléments.
Par souci de simplification, les pages ne faisant pas partie d'un groupe seront tout de même
représentées comme faisant partie d'un groupe mais que nous appellerons NOGROUP par exemple.
Ainsi notre structure en mémoire sera comparable à la figure ci-dessous :
36 / 37
Partie théorique
Auteur
Bel Olivier
10 Nouveau diagramme ou diagramme existant ?
Maintenant que le type de notre diagramme est déterminé, que les éléments de diagrammes sont
définis par rapport aux éléments correspondant dans une application APEX et que les types de
relations sont eux aussi déterminés, il nous reste encore à déterminer le principe de fonctionnement
de notre plugin.
A savoir si l'on partira d'un diagramme existant ou si le diagramme sera créé.
Si l'on part du postulat que notre plugin permet seulement de lire les données d'une application
APEX et de les représenter dans VP, rien ne nous empêche de créer les diagrammes au moment de
l'exécution. Rien ne nous empêche non plus de partir d'un diagramme vide.
Par contre si notre plugin devait être en mesure de faire une synchronisation entre APEX et VP,
dans les deux sens, alors il serait nécessaire de partir d'un diagramme existant s'il en était un ou de
le créer si besoin.
Pour ce projet, nous nous contentons principalement de lire des métadonnées APEX et de les
représenter sous forme de diagramme VP. Donc nous avons le choix.
Cependant, comme nous avons prévu de gérer les groupes de pages et de ne représente qu'un groupe
de pages par diagramme, il semble logique de laisser au plugin le soin de la création des
diagrammes selon leur nombre qui est défini par l'application APEX à représenter.
37 / 37

Partie théorique

Transcription

Documents pareils

L ` essentiel pour venir

Contacts

MEMBERSHIP APPLICATION / RENEWAL FORMULAIRE D

Télécharger la fiche de poste

Les dix raisons pour lesquelles vous devriez joindre l`APEX

2.7 Release Notes

Activation de Apex

Apex - Stage d`été - Transparence

Télécharger la fiche APEX

CP-AE-Investissement-Italie-09092014