3. 2 Evolution des architectures

VII. 3. 2. 1 Observation des architectures et comparaison des versions

L’étape 1 consiste à collecter des informations concernant l’évolution des architectures. Une première action est de déterminer si les architectures modifiées respectent toujours leur style de référence ou non. Ceci est assuré par le « customizer » ArchWare utilisé par le vérificateur de conformité de l’environnement de développement.

Il est ensuite nécessaire d’obtenir des informations concernant les propriétés structurelles et comportementales des architectures modifiées afin de pouvoir les comparer à celles des précédentes versions des architectures, et d’en déduire les évolutions. Pour cela il a fallu ajouter au vérificateur de conformité une fonctionnalité permettant de collecter et

d’archiver les différentes informations présentes dans les architectures d’IHMs (valeurs des attributs, nombre d’éléments architecturaux de chaque style, …). Ces informations sont stockées dans une table de base de données, et des procédures permettent de les consulter pour retourner les points et les tendances d’évolution.

VII. 3. 2. 2 Analyse des évolutions

Afin de pouvoir analyser efficacement les futures évolutions des architectures, il a été nécessaire de comprendre quelles caractéristiques celles-ci pouvaient avoir. Dans cet objectif il a été intéressant d’analyser les évolutions qu’ont connues les prototypes d’architectures d’IHMs. Ces IHMs avaient pour fonction de superviser les systèmes nécessaires à l’opération d’un accélérateur particulier du CERN, le SPS (Super Proton Synchrotron). Le développement de ces IHMs a pris plusieurs mois, et n’est pas encore tout à fait complet car leurs utilisateurs demandent régulièrement la supervision de systèmes supplémentaires. Le paragraphe suivant présente les principales modifications qui ont été appliquées aux architectures d’IHMs.

VII. 3. 2. 2. 1 Analyse des évolutions des IHMs prototypes

Depuis le début du développement des prototypes d’IHMs, de nombreuses améliorations ont été appliquées. Celles-ci sont notamment le résultat de notifications de dysfonctionnements ou de l’apparition de nouveaux besoins. Toutes ces mises à jour ont été archivées dans un système logiciel de type CVS (Concurrent Version System).

L’étude des différentes versions des IHMs a permis de répertorier plus de cinquante modifications appliquées sur environ vingt IHMs au cours d’une année. Celles-ci ont été classées suivant le type d’élément (IHM globale, IHM spécifique, bloc système, …) sur lequel elles ont été appliquées, ainsi que suivant le nombre d’éléments de ce type concernés. Il a par ailleurs été intéressant de considérer les dates des modifications de façon à être capable de connaître la fréquence d’évolution de chaque élément. Ceci est utile pour déterminer quels sont les éléments matures, et quels sont ceux qui ne le sont pas. Une fois ces modifications classées en fonction du type et du nombre d’éléments concernés, la notion de type d’évolution a été ajoutée (exemples : nouvelle fonctionnalité, modification du traitement des données, correction de défaut, modification des paramètres d’instanciation, amélioration graphique, modification structurelle). Il a de plus été utile de considérer la cause de chaque modification afin de déterminer si celle-ci pourrait se reproduire dans un autre contexte, et comment cela pourrait être évité.

En résumé, les informations pour chacune des modifications sont les suivantes : - libellé de la modification (exemple : ajout du système « air comprimé ») ; - date de la modification ;

- élément(s) concerné(s) par la modification (exemple : toutes les IHMs spécifiques) ;

- classe de modification (exemple : modification structurelle) ;

- cause de la modification (exemple : définition incomplète de l’architecture – la présence de ce système n’était pas requise).

La plupart de ces modifications ont entraîné un raffinement correspondant du style GTPM qui était alors en cours de développement. En effet, parmi les cinquante

modifications d’IHM répertoriées, six d’entre elles concernaient le style GlobalHCI du style GTPM, vingt trois concernaient le style IndividualHCI, et dix huit concernaient le style StatusBloc.

Cette étude indique précisément comment les IHMs initiales ont évolué : plusieurs nouvelles propriétés ont été ajoutées aux IHMs et aux blocs ; la structure de l’IHM globale a évolué ; de nouveaux blocs systèmes ont été ajoutés ; le comportement des blocs ont évolué ; etc. L’analyse de ces modifications a servi de base à la définition de critères pour l’analyse des évolutions des futures architectures d’IHMs, ce qui fait l’objet du paragraphe suivant.

VII. 3. 2. 2. 2 Analyses des évolutions des architectures

Une fois l’étape de l’observation des évolutions achevée, le deuxième point du processus de supervision consiste à les analyser et à déterminer si elles doivent impliquer des modifications au niveau du style. Plusieurs questions apparaissent alors :

- Est-ce que ces améliorations ont un intérêt pour les autres architectures qui respectent le style en question ?

- Ou, est-ce seulement le résultat d’un besoin spécifique à une architecture particulière ?

- Est-ce une modification temporaire qui évoluera probablement de nouveau ? - Des améliorations similaires ont-elles été appliquées à d’autres architectures qui

suivent le même style ?

Les réponses à ces questions peuvent être trouvées à l’aide d’analyses statistiques ainsi que par la considération du facteur temps.

L’analyse statistique permet de déterminer les tendances d’évolution en comparant les évolutions de plusieurs architectures instanciées à partir du style de référence. Si plusieurs architectures qui suivent le même style ont reçu des améliorations similaires, on peut considérer que le style doit être modifié dans ce sens. Au contraire, quand une architecture est modifiée en fonction d’un besoin spécifique, qui ne concerne pas les autres architectures suivant le même style, le style de doit pas être mis à jour, et l’architecture modifiée reste donc découplée du style.

La considération du facteur temps peut être très pertinente pour déterminer si l’évolution d’une architecture doit être prise en compte au niveau du style. En effet, une architecture qui ne satisfait pas les utilisateurs sera rapidement revue pour être améliorée.

Au contraire, une architecture satisfaisante aura vraisemblablement une durée de vie plus longue. Il est donc possible de définir une durée d’utilisation d’une version d’IHM à partir de laquelle celle-ci est supposée satisfaire les utilisateurs, et peut donc être utilisée pour améliorer le style. A l’opposé, il n’y a aucune garantie qu’une version d’IHM venant juste d’être mise en opération ne satisfasse pleinement les utilisateurs, elle devra donc probablement évoluer rapidement (cet aspect a été largement observé dans la série des modifications appliquées aux prototypes d’IHMs). Dans ce cas, les modifications appliquées aux IHMs ne doivent pas être immédiatement prises en compte pour améliorer le style.

A partir de ces considérations il a été possible de définir un jeu de règles permettant de déterminer si une modification appliquée sur une ou plusieurs architectures doit impliquer une modification du style. La classification des modifications d’architectures

présentée dans la section VII.3.2.2.1 a servi de base pour atteindre ce but. Par exemple, une règle stipule que si une modification structurelle a du être apportée à une IHM spécifique, et qu’elle a causé la violation d’une propriété (trop contraignante) du style, et que cette modification a été éprouvée pendant une durée définie, alors la propriété concernée doit être affaiblie au niveau du style « IHM spécifique ».

A ce niveau du processus de supervision il n’est possible que de recommander une modification du style, mais pas encore de déterminer si cette modification est possible.

Ce dernier point, qui constitue l’étape 3 du processus de supervision, fait l’objet de la section suivante.