3. 2 Architectures logicielles

Comme l’a montré le paragraphe précédent, le développement d’une famille de produits à l’aide d’un guide de développement utilisant l’expertise d’un domaine d’application, implique la considération d’une solution orientée architecture. Les formalismes de description d’architectures logicielles fournissent des moyens de décrire les propriétés fonctionnelles, structurelles et comportementales que les applications doivent satisfaire (caractéristiques des IHMs dans le contexte de cette thèse : cf. section II.4.2).

Les paragraphes suivants présentent les concepts de base du développement architectural ainsi que les bénéfices généraux que leur utilisation apporte.

III. 3. 2. 1 Définition

Un problème critique dans la conception et la construction de tout système logiciel complexe est son architecture, c’est à dire l’organisation des éléments qui composent le système. Une bonne architecture peut aider à garantir que le système va satisfaire les besoins primordiaux dans des domaines tels que la performance, la fiabilité, la portabilité, et l’interopérabilité. Au contraire, une mauvaise architecture peut avoir des conséquences désastreuses sur le système [Garlan 2000]. C’est pourquoi, au cours de la dernière décennie, les architectures logicielles ont fait l’objet d’une attention croissante, elles sont ainsi devenues un important sous domaine de l’ingénierie logicielle.

Plusieurs définitions du terme « architectures logicielles » sont proposées dans la littérature [Boasson 1995][Bass et al. 1997][Garlan et al. 1992][Perry et Wolf 1992], mais il est largement accepté qu’une architecture soit définie par un ensemble de composants (ex : filtres, objets, bases de données, serveurs, etc.) ainsi que par la description des interactions entre ceux-ci (ex : appels de procédures, envoi de messages,

émission d’événements, etc.) [Garlan et Shaw 1993]. Celle-ci permet de spécifier les caractéristiques d’un système en définissant : quels types de modules sont des composants du système ; combien de composants de chaque type peut il y avoir ; comment les composants interagissent [Rapide 1997] ; quelles propriétés structurelles et comportementales doivent être respectées.

La description architecturale d’un système informatique permet en outre de spécifier : - sa structure : éléments de traitement et leurs interactions (pas de détails

d’implémentation) ;

- son comportement : fonctionnalités et protocoles de communication, dynamisme, évolution ;

- ses propriétés globales (exemples : sécurité, vivacité…).

Le paragraphe suivant présente comment sont spécifiés ces différents aspects des architectures logicielles.

III. 3. 2. 2 Formalisme

Les architectures de la plupart des systèmes logiciels ont longtemps été décrites informellement, au moyen de diagrammes représentant les composants logiciels par des

« boîtes » et leurs interactions par des « lignes ». La description informelle d’architectures induit des difficultés au niveau de son interprétation et possède donc un certain nombre de limitations [Abowd et al. 1995]. En effet, pour être exploitable, une architecture doit clairement définir :

- quels traitements les « boîtes » et leurs annotations représentent ; - est-ce que toutes les « boîtes » ont des comportements similaires ;

- quelles relations de contrôle/flux de données sont indiquées par les « lignes » ; - comment le comportement global du système est déterminé par celui de ses

composants.

De simples diagrammes comportant des annotations ne sont pas suffisamment expressifs pour spécifier une architecture en exprimant toutes ces informations. C’est pourquoi les concepteurs de logiciels qui utilisent de tels diagrammes les interprètent en fonction du contexte d’utilisation. Par exemple, pour décrire une architecture de type

« pipe-filter » un diagramme utilisera les « boîtes » pour représenter des « filters » et les

« lignes » pour représenter des « pipes ». Pour un autre système, les « boîtes » pourraient représenter des objets et les « lignes » des appels de méthodes. Toutefois, l’interprétation reste imprécise, il est donc impossible de donner à ces diagrammes des significations non ambiguës. Il est alors difficile de déterminer si l’implémentation du système satisfait sa description architecturale. De même, ce manque de précision empêche l’application d’analyses formelles : il est impossible de raisonner formellement sur les descriptions architecturales des systèmes, ou de faire des comparaisons efficaces entre différentes descriptions architecturales. Ainsi, afin de définir plus précisément et de mieux comprendre l’architecture des systèmes logiciels, de nombreux travaux ont proposé d’utiliser une structure permettant d’associer des sémantiques formelles aux diagrammes architecturaux. C’est dans cet objectif que des ADLs ont été développés. Les caractéristiques des principaux ADLs utilisés actuellement seront exposées dans la section III.3.4. L’approche de conception formalisée rendue possible par l’utilisation de

ADLs a de nombreux avantages par rapport aux méthodes informelles, comme par exemple la précision, la capacité à prouver des propriétés, et la possibilité d’analyser la structure.

III. 3. 2. 3 Bénéfices généraux

Les architectures logicielles jouent un rôle important dans au moins six aspects du développement logiciel [Garlan 2000] :

1. Compréhension : les architectures logicielles rendent plus facile la compréhension du fonctionnement de systèmes complexe en les représentant à un haut niveau d’abstraction ;

2. Réutilisation : les descriptions architecturales supportent la réutilisation à de multiples niveaux. Les travaux actuels dans le domaine de la réutilisation se concentrent généralement sur l’utilisation de bibliothèques de composants. La conception orientée architecture supporte, en plus, la réutilisation de composants complexes et des structures dans lesquelles ces composants peuvent être intégrés.

Ceci est prouvé par de nombreux travaux existants dans les domaines des DSSA (Domain-Specific Software Architectures), des architectures de référence, ou des patrons de conceptions [Mettala et Graham 1992][Buschmann et al. 1996] ;

3. Construction : une description architecturale fournit un plan de développement en indiquant les composants principaux et les dépendances entre eux ;

4. Evolution : l’architecture d’un système peut décrire comment celui-il est censé évoluer. La définition explicite des limites d’évolutions d’un système permet de faciliter sa maintenance et d’estimer plus précisément les coûts des modifications.

De plus, les descriptions architecturales distinguent les aspects fonctionnels des composants de la façon dont ces composants interagissent entre eux. Cette séparation permet de modifier facilement les mécanismes de connexion, ce qui favorise l’évolution en termes d’interopérabilité et de réutilisation ;

5. Analyses : les descriptions architecturales fournissent des moyens d’analyse, tels que la vérification de la consistance d’un système [Allen et Garlan 1994]

[Luckham et al. 1995], la vérification de la conformité aux contraintes imposées par un style architectural [Abowd et al. 1993], la vérification de la conformité à des attributs qualité [Clements et al. 1995], l’analyse de dépendance [Stafford et al. 1998], ainsi que des analyses spécifiques au style à partir les architectures ont été construites [Coglianese et Szymanski 1993][Magee et al. 1995][Garlan et al.

1994] ;

6. Gestion : l’expérience a montré que la définition précise d’une architecture logicielle est un facteur clé dans la réussite d’un processus de développement logiciel. L’évaluation d’une architecture mène a une meilleure compréhension des besoins, des stratégies d’implémentation, et des risques potentiels [Boehm et al.

1994].

De plus, l’utilisation d’une conception orientée architecture comporte des avantages pour toutes les personnes intervenant dans le cycle de vie d’un projet logiciel [Upchurch 1995] (Cf. figure III.2).

Figure III. 2 : Cycle de vie d’une application logicielle

- client : estimation du budget et du temps de développement ; évaluation de la faisabilité et du risque ; traçabilité des besoins ; suivi de progrès.

- utilisateur : satisfaction des besoins ; scénarii d’utilisation ; adaptation possible aux évolutions des besoins ; performance, fiabilité, interopérabilité, etc.

- architecte : traçabilité des besoins ; support des analyses ; complétude ; consistance de l’architecture.

- développeur : suffisamment de détails pour la conception ; référence pour la sélection et l’assemblage des composants ; interopérabilité avec les systèmes existants.

- mainteneur : guide pour les modifications logicielles ; guide pour les évolutions de l’architecture.

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

La figure III.3 représente le processus de développement centré architecture ainsi que les acteurs qui interviennent directement dans celui-ci : l’architecte, le développeur, ainsi qu’éventuellement l’analyste (cette tâche peut être automatisée) [Leymonerie 2004].

Figure III. 3 : Processus de développement architectural

L’architecte a pour rôle de définir l’architecture qui servira de base au développement de l’application. Le développeur raffine cette architecture de façon à s’approcher petit à petit de l’application finale. Pour cela il implémente les composants ainsi que leurs interactions (les connecteurs) en respectant la structure et les propriétés définies par l’architecture de départ^*. A chaque étape de raffinement l’analyste est en mesure de vérifier que l’architecture raffinée est conforme à l’architecture du niveau d’abstraction supérieur. Ce processus permet de garantir que l’application obtenue respecte les propriétés fonctionnelles, structurelles et comportementales définies par l’architecte en accord avec le client et les utilisateurs.

L’étude des techniques de développement architectural menée dans cette section indique que celles-ci ont le potentiel d’améliorer le développement des IHMs de supervision en fournissant le cadre nécessaire pour spécifier leur structure et leurs propriétés, ainsi que celles des éléments qui les composent. Ces techniques permettent en outre de s’assurer que les applications obtenues respectent cette structure et ces propriétés. De même, elles rendent possible la gestion de l’évolution des IHMs développées. Toutefois, pour répondre pleinement aux besoins exprimés dans la section II.4, l’outil SEAM doit permettre la spécification graphique des IHMs, la génération automatique de leur code, ainsi que l’utilisation d’un guide de développement. Afin d’évaluer la solution centrée architecture dans ces domaines, les prochaines sections présentent les techniques de définition et d’exploitation des descriptions architecturales.

Pour commencer, le paragraphe III.3.3 présente un aspect central de la conception architecturale : l’utilisation des styles architecturaux pour construire des familles d’applications possédant des caractéristiques communes. Il s’agit d’un aspect crucial pour atteindre un des principaux objectifs de l’outil SEAM, la génération de familles d’IHMs de supervision.

* Dans les approches formelles, le processus de raffinement peut-être totalement ou partiellement automatisé