3. 4 Vérificateur de conformité

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.

Cardinalités des blocs

Géré en partie (structure de la BD)

Géré en partie (génération de code) Redondance des

dépendances Géré (clé primaire) Boucle de

dépendance Géré

Typage des blocs

compatibles Géré

Boucle

d’acquisition Traité par un outil autre que SEAM Traitement de la

plage de valeurs Etat résultant standard

Géré (domaine de valeurs)

Tableau VI. 1 : Implémentation des contraintes du style GTPM

Le chapitre 4 a énoncé des contraintes de cardinalité devant être formalisées par le style. Ces contraintes imposent le nombre minimum et maximum de blocs présents sur une IHM en fonction de leur catégorie (ex : un et un seul bloc de la catégorie

« Electricité »). De même, ce chapitre a énoncé des contraintes de positionnement relatif des blocs et des IHMs, ainsi qu’une concernant l’obligation de traitement de toute la plage des valeurs supervisées par un bloc. Toutefois, l’expérience a montré que de telles contraintes ne peuvent pas être respectées pour toutes les IHMs, et, pour cette raison, les spécialistes de l’opération des accélérateurs n’ont pas pu les énoncer de manière définitive. Il aurait été faisable de coder ces contraintes, au niveau de l’interface d’exploitation de la base de données par exemple, mais cela aurait introduit un manque de flexibilité contre-productif.

La contrainte du style interdisant les boucles dans la chaîne d’acquisition n’a pas non plus été implémentée par SEAM. En effet, un outil propre au système de supervision de la salle de contrôle a été mis en place dans cet objectif : SEAM lui transmet les règles stockées dans sa base et l’outil les analyse pour vérifier qu’il n’existe pas de boucles.

Par ailleurs, les contraintes concernant l’uniformité des dimensions des blocs et des IHMs n’ont pas été entièrement implémentées. En effet, pour un besoin de flexibilité, des valeurs par défaut sont simplement suggérées à l’utilisateur. Là encore, il a été décidé de les vérifier à posteriori, et d’avertir d’utilisateur en cas de violation.

Ainsi, les trois modules que sont la base de données de SEAM, son interface d’exploitation, et le modélisateur GTPM, peuvent garantir que les IHMs produites respectent la majorité des contraintes du style GTPM, mais pas toutes. Il a donc été nécessaire de mettre en place un outil vérifiant la conformité des IHMs par rapport à toutes les contraintes du style. Cet outil fait partie de l’interface utilisateurs de SEAM car il affiche aux développeurs d’IHMs les résultats des analyses qu’il applique. Il comporte deux aspects principaux faisant l’objet des paragraphes suivants : la conversion des IHMs en architectures formalisées en ArchWare-ADL et utilisant le vocabulaire du style GTPM, et la vérification de la conformité de ces architectures par rapport aux contraintes du style.

VI. 3. 4. 1 Conversion des IHMs en ADL et vérification des contraintes

Cette fonctionnalité permet d’obtenir, à partir des données présentes dans la base de données de SEAM, le code formel des IHMs en ArchWare-ADL sous la forme présentée dans la section V.5. Il a donc fallu établir des règles de transformation pour passer de la représentation « base de données » des IHMs à la représentation formelle. Les principales règles concernant la correspondance entre les notions de la base de données et le vocabulaire défini par le style GTPM sont les suivantes :

- à une association bloc-équipement « supervision » présente dans la table GTPBLOCEQUIP correspond un connecteur tel que « supervision is connector in style DataLink with {…} » ;

- à un bloc « bloc » présent dans la table GTPBLOCS correspond un composant tel que « bloc is component in style StatusBloc with {…} » ;

- à un équipement « equip » présent dans la table GTPEQUIP correspond un composant tel que « equip is component in style Equipment with {…} » ;

- à une IHM « ihm » présente dans la table GTPFCTLOCATION correspond un composant tel que « ihm is component in style IndividualHCI with {…} ».

La table d’association bloc-IHM GTPBLOCLOCATION permet de générer le code d’initialisation des blocs associés à une IHM (avec les valeurs de la table GTPBLOCS comme paramètres) dans sa description ADL.

Le code ADL concernant les ports associés aux différents composants et connecteurs est généré en même temps que ceux-ci. Les attributs graphiques des éléments présents dans la base de données et dans le fichier CSS du modélisateur, sont utilisés pour générer la partie du code ADL contenant l’initialisation des attributs des composants.

Ces quelques règles de transformation permettent d’obtenir une représentation formelle des IHMs développées. L’avantage majeur d’une telle représentation est la possibilité de lui appliquer des analyses automatiques. La vérification du respect des contraintes formalisées au niveau du style par les architectures d’IHMs, est ainsi rendue possible par l’utilisation d’un outil ArchWare. Il s’agit du « customizer » qui offre un service de comparaison d’une architecture par rapport au style et qui appelle l’outil nécessaire (« theorem prover » ou « model checker ») pour la vérification de chacune des contraintes.

VI. 4 Conclusion

Ce chapitre a présenté l’implémentation de l’approche proposée par cette thèse.

L’environnement SEAM est maintenant opérationnel et a été déployé dans les principales salles de contrôle du CERN, où il est utilisé depuis plusieurs mois. SEAM comporte actuellement environ 10.000 lignes de code et 22 tables stockant les informations concernant 36 applications de supervision, 42 types de blocs, environ 600 blocs.

Le style GTPM, formalisé à l’aide des langages ArchWare, a été intégré à l’architecture de l’environnement de développement. Cette architecture qui inclut les contraintes du style a été utilisée pour construire SEAM. Ainsi, les différents modules qui le composent ont été conçus de façon à implémenter les contraintes que le style spécifie.

Certaines de ces contraintes ont été intégrées à la structure de la base de données de

SEAM, d’autres ont été codées dans son interface d’exploitation, d’autres encore ont été implémentées par la personnalisation du modélisateur GTPM, et enfin, pour de raisons de flexibilité, certaines n’ont pas été traitées. Toutefois, l’utilisation du vérificateur de conformité permet de vérifier si les contraintes formalisées sont bien toutes respectées par les architectures d’IHMs, et d’avertir l’utilisateur dans le cas contraire. L’environnement de développement SEAM guide ainsi les développeurs d’IHMs dans leur travail et leur garantit que celles-ci vérifient les contraintes du style.

Le chapitre suivant présente une approche permettant de gérer l’évolution de cet environnement de développement et du style, en fonction de l’évolution des besoins relatifs à la supervision des accélérateurs.