S UPERVISION DE L ’ EVOLUTION DES ARCHITECTURES DEFINIES A PARTIR DU STYLE

Chapitre VII : Evolution des IHMs et de l’outil logiciel

VII. 1 Introduction

Les chapitres précédents ont proposé un processus de développement d’IHMs^* utilisant les styles architecturaux, et ont présenté l’implémentation d’un environnement prenant en charge ce processus. L’environnement, construit à partir de son architecture formelle, guide les utilisateurs dans le développement d’IHMs respectant les contraintes définies par un style. Cet environnement de développement garantit la satisfaction des besoins exprimés par les utilisateurs de IHMs et formalisés par le style. Toutefois, les besoins exprimés dans les premières phases d’un projet peuvent évoluer avec le temps, et ceci pour deux raisons principales :

- l’évolution du processus supervisé : dans le contexte du projet GTPM, les accélérateurs de particules sont sujets à une évolution permanente au cours de leur longue durée de vie ; il est nécessaire de mettre à jour les IHMs en fonction de ces évolutions ;

- le besoin de nouvelles fonctionnalités/informations : l’utilisation des IHMs en salle de contrôle peut mettre évidence certaines limitations ; les utilisateurs peuvent alors proposer de nouvelles solutions, de nouvelles fonctionnalités, ou requérir l’affichage de nouvelles formes d’informations.

Les questions qui se posent alors sont les suivantes : - Comment faire évoluer les IHMs ?

- Quels sont exactement les types de besoins pouvant évoluer ? - Comment mesurer l’évolution des IHMs ?

- Est-ce possible de mettre à jour le style en fonction de cette évolution ? Comment ?

- Est-ce possible de mettre à jour l’environnement de développement ? Comment ? Ce chapitre a pour objectif de répondre à ces questions. Dans un premier temps la section VII.2 explique comment les IHMs peuvent être mises à jour en fonction de l’évolution des besoins. Ensuite, la section VII.3 présente une approche permettant de superviser l’évolution des IHMs. Enfin, les sections VII.4 et VII.5 proposent une solution pour exploiter le résultat de cette supervision en mettant à jour le style et l’environnement de développement associé.

* Dans ce chapitre encore, le terme « IHM » désigne des logiciels de supervision à forte composante graphique.

VII. 2 Evolution des IHMs

Les besoins évoluant, il est nécessaire que les IHMs puissent être mises à jour en fonction. Cette section expose comment les prototypes d’IHMs ont été régulièrement mis à jour, comment, dans une approche architecturale classique les IHMs pourraient évoluer, et comment cela est possible dans un environnement de développement dédié.

VII. 2. 1 Evolution des prototypes d’IHMs

Comme cela a été présenté dans le chapitre 4 (figure IV.3), les prototypes d’IHMs n’ont pas été développés à partir du style GTPM, mais à l’aide d’un outil de développement d’IHMs traditionnel (PVSS). Ces prototypes ont servi de base à la définition du style GTPM, mais ont aussi été largement utilisés en salle de contrôle. Ainsi de nouveaux besoins sont apparus lors de leur phase d’exploitation et de nombreuses modifications leur ont été appliquées (des détails concernant ces modifications sont présentés dans le paragraphe VII.3.2.2.1).

Les modifications des prototypes d’IHMs ont été apportées à l’aide de l’outil PVSS.

Il est à noter que cet outil n’étant pas contraint par un style propre au domaine de la supervision du redémarrage des accélérateurs, il était possible d’appliquer un large éventail de modifications. Cette flexibilité était intéressante au début du projet, mais non acceptable par la suite, car elle risquait d’impliquer une perte de contrôle de l’orientation des développements itératifs. Par ailleurs, certaines des modifications avaient uniquement un caractère graphique, et étaient donc applicables par des développeurs non informaticiens, mais la plupart impliquaient des changements au niveau du code, et ont donc dû être prises en charge par l’équipe de programmeurs, ce qui constituait un inconvénient majeur.

Les modifications successives des prototypes d’IHMs ont été considérées pour le raffinement du style GTPM qui était en cours de développement.

VII. 2. 2 Evolution des IHMs dans une approche architecturale

Dans un environnement de développement entièrement architectural, comme celui présenté figure VI.1, l’évolution des IHMs passe par l’évolution de leurs architectures.

Des outils architecturaux, tel que le modélisateur ArchWare, permettent de mettre à jour les architectures, et donc les IHMs, d’une manière graphique. Toutefois, lorsque l’environnement est contrôlé par un style, les utilisateurs ne sont pas libres d’appliquer n’importe quelle modification : les architectures doivent utiliser le vocabulaire, et respecter les contraintes définis par le style. En effet, c’est l’objectif du style de garantir que les IHMs respectent les besoins « prédéfinis ». Cependant, comme les besoins peuvent évoluer, ceux « prédéfinis » peuvent devenir obsolètes, et il devient nécessaire de pouvoir s’affranchir des contraintes de développement définies par le style.

Un outil tel que le modélisateur ArchWare n’est pas nécessairement paramétré par un style particulier. En cas de besoin, il est donc tout à fait possible à un utilisateur de définir des nouvelles versions d’architectures, utilisant des éléments architecturaux non définis dans le vocabulaire du style, et violant ses contraintes, en utilisant le modélisateur sans le

paramétrer avec un style. Toutefois, si cette opération peut être nécessaire, elle a l’inconvénient de découpler les architectures du style, ce qui empêchera de contrôler leur évolution future. Ceci amène à considérer le fait que si les architectures doivent évoluer hors des limites fixées par le style, c’est que le style ne satisfait plus les besoins du domaine, et qu’il est donc nécessaire qu’il évolue lui même. Ce point est traité dans la section VII.4.

VII. 2. 3 Evolution des IHMs avec dans un environnement de développement spécifique

La solution choisie dans le contexte de cette thèse a été de concevoir l’environnement de développement spécifique à partir de contraintes exprimées par un style formel. Le chapitre 6 a expliqué que le style a été intégré dans une architecture comprenant une base de données, son interface d’exploitation, et un modélisateur graphique. Comme ces trois modules comportent la majeure partie des contraintes du style, les utilisateurs ne peuvent pas appliquer n’importe qu’elle modification aux IHMs par son intermédiaire. Toutefois, certaines contraintes du style n’ont volontairement pas été « codées » de façon à donner une flexibilité d’évolution. Ainsi, lorsque de nouveaux besoins apparaissent, leur implémentation peut se faire des manières suivantes (Cf. figure VII.1) :

- utilisation de l’interface base de données et du modélisateur graphique de l’environnement (1) : soit les modifications requises ne violent pas le style et sont donc implémentables, soit elles violent le style mais restent implémentables (les violations de contraintes seront indiquées lors de la vérification de conformité architecture/style) ;

- modification du code des IHMs (2) : les modifications requises violent le style et ne sont pas implémentables via l’interface et le modélisateur, mais peuvent l’être par modification directe du code des IHMs. Par exemple, dans le cadre de l’outil SEAM, la base de données et son interface empêchent l’utilisateur d’associer à un bloc une salle de contrôle différente de TCR/MCR/PCR/QCR, mais c’est tout à fait possible de le faire en éditant directement le code XML des IHMs ;

- modification de l’environnement de développement (3) : les modifications requises violent le style et ne sont ni implémentables via l’interface et le modélisateur, ni par modification du code des IHMs. Il s’agit de l’alternative la moins souhaitable car elle requière la redéfinition partielle de l’architecture de l’environnement de développement et son implémentation. Il peut être nécessaire de modifier la structure de la base de données, et/ou son interface d’exploitation, et/ou le modélisateur graphique.

L’évolution des IHMs peut donc conduire à des violations du style de référence.

Toutefois, il est nécessaire de mesurer l’impact de ces violations et que celles-ci soient faites en connaissance de cause. De plus, celles-ci indiquent dans certains cas que le style est partiellement obsolète et qu’il est nécessaire de le mettre à jour. Ainsi, comme le représente la figure VII.1, une analyse des modifications appliquées sur les IHMs permet de déterminer si le style doit être lui-même modifié. Dans l’affirmative, le style, mais aussi l’environnement de développement, seront mis à jour.

Figure VII. 1 : Processus de modification des IHMs, du style, et de SEAM La section suivante présente une approche permettant de superviser et d’analyser l’évolution des IHMs, ce qui constitue une étape indispensable pour la maintenance du style.

VII. 3 Supervision de l’évolution des architectures définies à partir du style

Le but de cette section est de définir un processus de supervision de l’évolution des architectures. L’approche proposée concerne le cas d’un processus de développement architectural classique (Cf. paragraphe VII.2.2) : les architectures dont l’évolution est supervisée ont été directement instanciées à partir d’un style architectural, et non via un environnement de développement tel que SEAM. La section VII.5 présentera quant à elle l’adaptation de cette approche dans le contexte d’un environnement de développement spécifique.