3. 3 Modélisateur GTPM

La procédure de création d’IHM initialise ses dimensions (largeur et hauteur) avec des valeurs standard afin de respecter la contrainte d’uniformité graphique spécifiée par le style GTPM.

VI. 3. 2. 5 Gestion des dépendances

Le paquetage gérant les dépendances entre les blocs ne comporte que quelques procédures (il n’implémente pas de contrainte du style GTPM). Celles-ci permettent à l’utilisateur de :

- rechercher dans la table GTPBLOCLNK les dépendances existantes pour un bloc donné ;

- créer une nouvelle dépendance entre deux blocs ; - supprimer une dépendance existante.

VI. 3. 2. 6 Gestion de la documentation

Le paquetage gérant la documentation des blocs possède de procédures permettant à l’utilisateur de :

- rechercher dans la table GTPBLOCDOC les liens de documentation associés à un bloc donné ;

- créer un nouveau lien de documentation pour un bloc ; - modifier un lien de documentation ;

- supprimer un lien de documentation existant.

- un ensemble d’outils d’édition, comprenant les fonctions copier et coller, des fonctions de sélection, de zoom, d’impression, etc. ;

- le chargement et la sauvegarde de fichiers en format XML.

Le code source Java de cet éditeur étant fourni avec la suite JViews, il a été possible d’en modifier certaines parties pour qu’il réponde plus pleinement aux besoins concernant l’édition des IHMs GTPM. La personnalisation de l’éditeur à comporté trois aspects qui sont présentés dans les sections suivantes : l’ajout de la possibilité d’interaction avec la base de données de SEAM, la modification de l’interface graphique, et la définition d’une feuille de style.

VI. 3. 3. 1 Interactions avec la base de données

Une des fonctionnalités principales du modélisateur GTPM est la possibilité d’interagir avec la base de données de SEAM. En effet, le processus de développement d’IHMs GTPM comporte deux phases : la définition des données, et la modélisation graphique. Ces deux phases peuvent se succéder dans un ordre comme dans l’autre, et peuvent être réitérées si nécessaire. L’utilisateur doit donc pouvoir importer/exporter des données de/vers la base de SEAM.

La méthode d’importation de données ajoutée au modélisateur effectue le traitement suivant :

- initialisation d’une connexion JDBC vers la base de données de SEAM pour permettre les requêtes SQL sur ces tables ;

- sélection des informations concernant une IHM choisie par l’utilisateur ; - création d’un document portant le nom de l’IHM dans le modélisateur ;

- sélection des informations concernant tous les blocs associés à l’IHM dans la base de données (identifiant, nom, salle de contrôle, taille, position, …) ;

- création des objets graphiques correspondants dans le document du modélisateur, et initialisation de leurs attributs avec les valeurs retournées par la requête précédente ;

- sélection des informations concernant tous les liens de dépendances relatifs aux blocs de l’IHM dans la base de données ;

- création des objets graphiques (liens) correspondants dans le document du modélisateur, et initialisation de leurs attributs avec les valeurs retournées par la requête précédente.

La méthode d’exportation des données effectue quant à elle les opérations suivantes : - initialisation de la connexion JDBC ;

- recherche dans la base de données SEAM d’une IHM correspondant au nom du document en cours d’édition dans le modélisateur ;

- création d’une nouvelle IHM dans le base de données si la requête précédente n’aboutit pas ;

- sélection des objets graphiques présents sur le document et de leurs attributs ; - insertion ou mise à jour des blocs et liens de dépendances dans la base de données

de SEAM.

Ces méthodes permettent d’utiliser la base de données SEAM comme stockage commun aux deux interfaces utilisateurs : l’interface propre à la base de données, et le modélisateur graphique GTPM.

VI. 3. 3. 2 Personnalisation de l’interface graphique

Le deuxième aspect de l’adaptation du modélisateur fut la personnalisation de l’interface graphique. Dans ce contexte, il a notamment été nécessaire de modifier les menus et les palettes d’objets graphiques.

Les palettes d’objets graphiques représentant des « tâches » et des « participants » de

« worflow » n’étaient pas adaptées à la problématique GTPM. Trois palettes spécifiques ont donc été crées (figure VI.15 – 4) :

- Types graphiques : cette palette fournit cinq types graphiques de base, deux dédiés à la représentation des blocs affichant uniquement un état (un de forme horizontale, et un de forme verticale), et trois permettant l’affichage d’informations additionnelles (forme horizontale, affichage de l’état ainsi que d’une mesure ou d’un nombre d’alarmes). A chaque type graphique correspond une classe d’objets ajoutée au modélisateur de base. La palette définit en outre les propriétés de chacun des types graphiques (correspondant aux attributs définis dans les classes d’objets). Par exemple, un bloc suivant le type graphique le plus simple doit avoir un identifiant, un nom, une largeur, une hauteur, un nom de responsable, et l’identifiant d’une valeur résultante (correspond au résultat d’une règle : identifiant 90258 dans l’exemple figure VI.14). Ces propriétés correspondent aux informations de la table GTPPALETTE de la base de données (Cf. section VI.3.1.1). La palette des types graphiques est d’ailleurs définie par du code XML obtenu à partir de cette table ;

- Blocs : cette palette permet de rendre disponible à l’utilisateur tous les blocs déjà créés à partir de types graphiques. Contrairement à ces derniers, les blocs ont déjà des valeurs affectées à leurs propriétés ;

- IHMs : cette palette rend disponible à l’utilisateur les IHMs et les ensembles de blocs déjà crées. Celle-ci est notamment utile pour construire les IHMs globales.

Les objets graphiques définis dans les palettes sont utilisés sur le document de travail (figure VI.15 – 3) par « glisser-déposer ». Afin de pouvoir affecter ou modifier des valeurs à leurs propriétés, il a été nécessaire de modifier l’éditeur de propriétés de base (figure VI.15 – 1). Cela a été réalisé par codage et par la définition du fichier CSS (feuille de style – Cascading Style Sheet) paramétrant le modélisateur (Cf. section VI.3.3.3).

Par ailleurs, comme cela a été signalé, les menus du modélisateur ont été adaptés aux besoins concernant le développement d’IHMs GTPM (figure VI.15 – 2). Par exemple, des boutons ont été ajoutés au menu « Fichier » (« File ») pour permettre l’invocation des méthodes d’importation/exportation des IHMs de/vers la base de données de SEAM. Un bouton permettant d’ouvrir la page web de l’interface d’exploitation des données a aussi été ajouté à ce même menu. D’autre part, afin d’assurer que les IHMs développées respecteront le style GTPM, il a été nécessaire de réduire l’espace de développement du modélisateur de base en supprimant certaines de ses possibilités. Par exemple, le menu

« Palette » ne permet plus d’ouvrir des palettes autres que celles citées précédemment. De

même, il n’est plus possible d’appliquer d’algorithmes de routage réorganisant automatiquement les blocs. En effet, dans le contexte du développement d’IHMs GTPM, l’utilisateur doit rester maître du positionnement des éléments.

Figure VI. 15 : Modélisateur GTPM VI. 3. 3. 3 Définition de la feuille de style

L’utilisation d’une feuille de style est un moyen très efficace pour personnaliser les différents éléments du modélisateur. Elle permet notamment de paramétrer :

- le document d’édition des IHMs (figure VI. 15 – 3) : il est possible de définir si l’application d’algorithmes de routage (pour les blocs et/ou les liens graphiques) est autorisée, ou s’il est possible de grouper les éléments, etc. ;

- les algorithmes de routage des blocs et des liens graphiques ;

- les objets graphiques selon leur type (couleurs, polices, tailles de polices, facteurs de zoom d’apparition/de disparition, libellés, alignement…) ;

- les relations entre les propriétés des objets graphiques et les attributs des classes correspondantes ;

- l’éditeur de propriétés.

Cette méthode de personnalisation est simple à mettre en œuvre, et elle permet de modifier facilement l’aspect des IHMs en fonction d’éventuelles évolutions des besoins.

C’est pour cette raison qu’il a été choisi d’implémenter les contraintes graphiques formalisées par le style GTPM au niveau de la feuille de style (fichier CSS). Ainsi, si les contraintes du style évoluent dans le temps, il sera moins coûteux de modifier la feuille de style, que ça le serait de modifier le code source de l’application si les contraintes avaient été codées en dur en Java. Ainsi, le fichier CSS impose l’uniformité des propriétés graphiques des éléments (polices, facteurs de zoom…) tel que cela est formalisé par le style GTPM.

Il est intéressant de noter que cette feuille de style est utilisée par le modélisateur d’IHMs GTPM, mais aussi par l’outil du système de supervision exécutant ces IHMs. Il s’agit d’un outil faisant partie de la suite JViews permettant l’exploitation du code généré par le modélisateur pour afficher l’état en temps réel des processus supervisés. Ceci garantit que les IHMs auront le même aspect à l’exécution qu’à l’édition.