3. 3 Styles architecturaux

concentrent particulièrement sur les motivations de l’utilisation du patron. Tout comme les styles architecturaux, de tels patrons permettent de caractériser des familles d’applications ayant des caractéristiques communes. Toutefois, ces patrons ne sont pas exploitables par les langages de programmation conventionnels. De même, les styles architecturaux ont longtemps été définis et utilisés comme des guides de conception informels, n’ayant pas de langages dédiés à leur exploitation. Les travaux menés depuis lors ont souligné l’intérêt de formaliser les styles [Abowd et al. 1995], et de nombreux langages dédiés à cette tâche ont été développés. Ces langages, appelés ASLs (Architectural Style Langages), sont des ADLs proposant des formalismes et des outils permettant de définir et d’exploiter efficacement les styles architecturaux. Leur utilisation comporte de multiples bénéfices : le fait de permettre de décrire formellement l’architecture de systèmes logiciels rend possible l’utilisation de mécanismes (cf. section III.3.3.4) pour représenter les architectures, leur analyse, leur raffinement, et la génération automatique du code correspondant. L’utilisation de styles architecturaux formalisés dans le contexte de l’outil SEAM est donc plus appropriée que celle de simples patrons, même si, comme le soulignent [Shaw et Clements 1996], il est intéressant de combiner les avantages des deux approches. Il est par exemple bénéfique d’ajouter aux descriptions formelles des styles certaines informations permettant de les organiser en bibliothèque pour les réutiliser plus efficacement en connaissant quels problèmes ils résolvent, dans quels contextes ils doivent être utilisés, etc.

III. 3. 3. 3 Processus de développement

La figure III.4 présente un processus de développement général incluant la définition formelle et l’exploitation de styles architecturaux [Leymonerie 2004]. Ce schéma reprend et étend le processus de développement architectural représenté par la figure III.3.

Figure III. 4 : Processus de développement architectural utilisant les styles

La première étape de ce processus est la formalisation du style architectural ou des styles architecturaux. Au fur et à mesure des définitions de styles une bibliothèque peut être définie. L’architecte d’application instancie alors le ou les styles qui correspondent à ses besoins spécifiques et les utilise comme éléments de construction pour définir une architecture de base. La suite du développement est identique au processus précédemment étudié : le développeur raffine petit à petit l’architecture de base en architectures de plus en plus concrètes jusqu’à l’obtention de l’application finale. Il est toutefois à noter que l’utilisation d’un tel processus de développement permet à l’analyste d’appliquer aux différentes architectures des analyses définies par les styles utilisés. Les analyses disponibles ne sont donc plus uniquement des analyses génériques, applicables à toutes les architectures. Elles peuvent aussi être des analyses spécifiques à un domaine d’application particulier, applicables uniquement aux architectures définies à l’aide des styles correspondant à ce domaine.

III. 3. 3. 4 Bénéfices des styles dans la production d’IHMs

Un processus de développement centré sur la définition et l’exploitation d’un style architectural pour développer une famille d’IHMs de supervision possède donc plusieurs bénéfices. En effet, l’utilisation des styles architecturaux simplifie la construction des systèmes, réduit le coût d’implémentation en promouvant la réutilisation, et par dessus tout, améliore l’intégrité des systèmes au moyen d’analyses et d’outils spécifiques au style utilisé [Monroe et al. 1997]. Le développement architectural permet de réutiliser des concepts déjà validés, comme par exemple les prototypes d’IHMs présentés en II.3, et garantit que les futures applications vont respecter les propriétés précédemment validées [Leymonerie et al. 2001]. De plus, l’utilisation d’un style architectural guide le développement d’une famille de systèmes logiciels (ex : IHMs) en fournissant un vocabulaire architectural commun utilisé pour décrire les structures des systèmes, et en contraignant l’utilisation de ce vocabulaire [Allen 1996]. L’adoption d’une approche utilisant les styles architecturaux apporte donc des solutions pour au moins quatre des cinq besoins listés dans l’introduction de ce chapitre, en effet, un tel processus de développement permet de faciliter l’implémentation des IHMs en :

- contraignant la construction de ces IHMs (par la spécification et la vérification de propriétés comme celles listées dans la section II.4.2) ;

- produisant des IHMs standardisées partageant des propriétés graphiques, structurelles et comportementales communes ;

- capturant le savoir faire du domaine et en réutilisant l’expérience acquise (réutilisation des concepts utilisés pour les prototypes d’IHMs).

D’autres aspects de ces besoins, comme la spécification des IHMs au moyen d’une interface graphique ou encore la génération automatique de code, peuvent être satisfaits par certains ADLs accompagnés de leurs outils. L’étude des principaux ADLs existants et le choix du plus approprié dans le contexte de cette thèse sont exposés dans la section III.3.4.

III. 3. 3. 5 Principaux styles existants

L’intérêt de l’utilisation des styles architecturaux ayant été mis en évidence, il est maintenant nécessaire d’étudier les styles déjà existants afin de déterminer si certains d’entre eux résolvent des problématiques semblables à celle exposée dans cette thèse.

C’est l’objet du prochain paragraphe.

[Garlan et Shaw 1993] ont répertorié plusieurs styles architecturaux parmi ceux qui ont été les plus fréquemment utilisés, avant même que des formalismes efficaces aient été disponibles pour faciliter leur définition et leur utilisation. La liste obtenue comprend les styles suivants :

- Systèmes événementiels, invocation implicite ; - Filtres et tuyaux (pipes and filters) ;

- Systèmes orientés objet ; - Systèmes en couches ; - Processus distribués ;

- Programme principal – sous routines ; - Systèmes de type état/transition.

De même, [Shaw et Clements 1997] ont identifié plusieurs styles génériques très couramment utilisés et les ont classés en deux catégories :

- styles du type « flux de données » : dominés par la notion de transmission de données à travers un système (ex : réseaux de transmission de données, pipelines,

« filtres et tuyaux », etc.) ;

- styles du type « processus interagissants » : dominés par les modèles de communication entre des processus indépendants et/ou concurrents (« processus communicants », « client-serveur », « broadcast », etc.).

Cette classification, ainsi que la plupart des travaux effectués dans ce domaine, se basent sur le fait que la grande majorité des styles est descriptible en termes de composants et de connecteurs. La catégorie des styles de type « flux de données » correspond aux styles ayant des composants de type « convertisseur de données » connecteurs de type « transmission de données ». La catégorie des styles du type

« processus interagissant » correspond quant à elle aux styles ayant des composants de type « processus » et des connecteurs de type « protocole de transmission de message ».

Une telle classification permet de déterminer rapidement quelles sont les caractéristiques de tel ou tel style et facilite donc le choix du style approprié pour résoudre un problème donné.

Les exemples de styles cités jusqu’à maintenant permettent de satisfaire des besoins génériques, ils caractérisent de très grandes familles de logiciels. En conséquence, même s’ils fournissent un guide de développement basique, ils ne sont pas suffisamment précis et contraignants pour pouvoir servir de guide de développement de logiciels spécifiques à un domaine d’application particulier (comme le développement d’IHMs de supervision).

C’est pourquoi de nombreux architectes ont défini des architectures et des styles propres à leur secteur d’activité, adaptés à leurs propres besoins (DSSA : « Domain-Specific Software Architectures »). En outre, certains styles ont été définis dans les domaines particuliers des systèmes de contrôle de processus et des interfaces homme-machine.

Concernant le développement de systèmes de contrôle de processus [Savigni et Tisato 1999] ont défini une architecture de référence, nommée Kaléidoscope, dédiée au développement de systèmes de contrôle et de supervision. Il s’agit d’une architecture en couches basée sur la séparation de la communication, du traitement, et de la stratégie dans le but de favoriser la modularité et la réutilisation [Savigni 2000]. Cette architecture de référence est elle aussi décrite en terme de composants et de connecteurs. Les

« images conceptuelles » sont les composants d’information qui modélisent les concepts du domaine d’application, et sont spécialisés en « images concrètes », comme l’acquisition, le traitement et la représentation des données. L’approche a été expérimentée avec succès dans la construction de deux systèmes importants. Partant du constat que tous les systèmes de contrôle et de supervision présentent un certain nombre de caractéristiques communes, les auteurs considèrent que cette architecture de référence, conçue au départ pour le développement de systèmes de contrôle de trafic routier [Savigni et Tisato 2000], peut être appliquée pour concevoir des systèmes de contrôle et de supervision dans un large panel de domaines d’applications. Toutefois, cette architecture de référence, ou style architectural, est conçue pour permettre le développement de systèmes de supervision complets, alors que la problématique de cette thèse se situe uniquement au niveau de la couche de représentation des données.

Kaléidoscope fournit donc un style de trop haut niveau d’abstraction pour répondre précisément aux besoins de construction des IHMs de supervision d’accélérateur de particules.

En conséquence, il est intéressant de considérer les travaux architecturaux effectués dans le domaine du développement d’IHMs. [Taylor et al.] ont défini un style architectural (Chiron-2 , ou C2) de type « composant et message » dédié à la construction d’interfaces graphiques. Constatant que, dans ce domaine, la réutilisation était souvent limitée à celle d’outils (« toolkits ») existants, ils ont mis en place un style flexible supportant une réutilisation de plus « gros grain ». Ce style supporte la conception d’applications distribuées et concurrentes. Les composants qu’il définit interagissent au moyen de messages asynchrones de requête et de notification. Ce style a été éprouvé dans la construction de plusieurs applications. Il s’agit d’un style très général utilisable dans de nombreux domaines d’application. Toutefois son objectif est différent de celui décrit dans cette thèse. En effet, ce style est dédié à la description d’architectures d’interfaces utilisateurs complexes, comportant de nombreux composants (comme des fenêtres de dialogue) interagissant avec plusieurs utilisateurs et utilisant de multiples medias.

L’objectif du style devant être défini pour prendre en charge la construction des IHMs GTPM est à la fois plus simple et plus ciblé : il s’agit principalement de contraindre la disposition et le comportement des éléments graphiques représentant l’état d’un processus. Le style C2 ne correspond donc pas précisément à la problématique décrite dans le chapitre 2.

Les besoins concernant les IHMs de supervision à générer étant très spécifiques, il est normal qu’aucun des styles développés dans d’autres contextes, pour répondre à d’autres besoins, ne satisfasse entièrement la problématique de cette thèse. Il s’avère donc nécessaire de formaliser un style dédié à la construction des IHMs de supervision des accélérateurs du CERN. Comme cela a déjà été mentionné précédemment, une telle définition se fait au moyen d’un ADL. La section suivante présente les principaux ADLs existants et les évaluent en fonction des besoins exprimés.