Architecture logicielle

2.1.DÉFINITION

L’architecture est l’art de la construction d’édifices selon un ensemble de règles établies [Robert 1992]. L’architecture d’un édifice, c’est aussi sa forme, sa structure. Dans le domaine de l’Interaction Homme-Machine, il s’agit de la façon dont les composants logiciels ou matériels sont organisés et assemblés pour concevoir un système interactif.

Un modèle d’architecture logicielle est utilisé lors de la phase de conception logicielle dans le cycle de vie du logiciel pour concevoir l’architecture du système. Dans un processus de développement, comme le montre la Figure 1 représentant les étapes d’un cycle en V, l’architecture d’un système interactif est le résultat de l’étape de conception globale. Cette étape est une phase critique puisqu’il s’agit d’une étape charnière entre l’espace de conception de l’Interface Homme-Machine (espace IHM) et l’espace de la réalisation logicielle (espace Logiciel). En effet, comme nous l’avons souligné dans le chapitre précédent, c’est au cours de la phase de spécification que l’ensemble des concepts et fonctionnalités est identifié. Cette phase de spécification résulte de l’élaboration de spécifications fonctionnelles et de spécifications externes, c’est-à-dire la spécification de l’interaction. Ainsi, la phase suivante, phase de transition entre les espaces IHM et Logiciel, Figure 1 Cycle de vie en V de développement logiciel Analyse Conception globale Codage Tests unitaires Tests d’intégration Tests utilisateur Conception Conception détaillée des besoins Tests du système Architecture Espace IHM Espace Logiciel logicielle

ARCHITECTURELOGICIELLE

Définition

consiste à traduire ces spécifications sous forme logicielle en appliquant un modèle d’architecture logicielle.

Une architecture logicielle est assimilée à un ensemble organisé de composants dont les interactions sont médiatisées par des entités spécialisées ou connecteurs. Le processus de conception d’une architecture logicielle, comme le montre la Figure 2, recouvre les deux principales activités suivantes [Bass 1998][Coutaz 2001] : définition de la décomposition fonctionnelle du système, choix d’une organisation structurelle (vue statique et dynamique). Le résultat de cette activité constitue la structure modulaire ou architecture conceptuelle:

• Définition d’une décomposition fonctionnelle : cette activité consiste à identifier les fonctionnalités du système regroupées sous forme d’entités logicielles ou de composants. Cette étape est complexe puisqu’il s’agit d’exprimer les requis utilisateurs et les spécifications externes de l’interface en termes logiciels.

• Choix d’une organisation structurelle : il s’agit de choisir ou de définir un schéma d’organisation des différents composants identifiés lors de la décomposition fonctionnelle, ainsi qu’un protocole d’échanges entre ces composants. Ce protocole est défini par l’ensemble des connecteurs et des règles définissant l’interaction entre les composants. L’organisation obtenue reflète une vue statique (agencement des composants) et dynamique (protocole d’échanges et migration fonctionnelle) du système. Les concepteurs peuvent s’inspirer de modèles d’architecture de référence. Ces modèles offrent une description standard d’une organisation de composants et de règles régissant les relations entre ces composants. En général, un modèle d’architecture permet de répondre à une classe de problèmes. Par exemple, le modèle d’architecture du compilateur permet l’identification de ses principaux composants : l’analyseur lexical, l’analyseur syntaxique, l’analyseur sémantique et le générateur de code.

Modèle d’architecture

Figure 2

Etapes de production d’une architecture [Coutaz 2001] Spécifications externes Architecture conceptuelle Architecture d’implémentation

Décomposition fonctionnelle Décomposition modulaire Identification des processus Allocation des processus

Etapes de référence

ARCHITECTURELOGICIELLE

Propriétés

La structure modulaire du logiciel étant établie, il convient de focaliser sur l’association entre entités structurelles et processus d’exécution du système, voire l’allocation des processus aux processeurs. Cette dernière activité prend tout son sens pour un collecticiel, système par définition réparti. La structure physique est alors conçue : elle complète la structure modulaire de l'étape précédente pour constituer ensemble l'architecture implémentationnelle. Cette architecture décrit l’organisation des fonctionnalités selon un ensemble de modules qui représentent les unités logicielles qui seront développées. De plus, cette architecture traduit l’aspect dynamique du logiciel en détaillant la répartition du logiciel selon les différents processus. De plus, comme le montre la Figure 2, le développement d’un collecticiel semble de plus en plus dépendant du choix de la plate-forme cible car les choix techniques ont un impact direct sur son développement (ressources disponibles en matière de réseau ou de capacités calculatoires, etc).

2.2.PROPRIÉTÉS Tout projet de réalisation d’un système interactif est guidé par la nécessité de produire un système de qualité mesurable. Selon l’approche proposée dans [IFIP 1996], la qualité d’un système interactif se mesure en terme de propriétés externes et internes : les propriétés externes sont liées à l’utilisabilité du système, le point de vue est donc celui de l’utilisateur final du système. Les propriétés internes traduisent la qualité du logiciel. [McCall 1977] a identifié onze propriétés internes comme la modifiabilité, l’extensibilité ou la portabilité. Par exemple, la propriété d’extensibilité traduit la capacité d’un système à facilement intégrer de nouvelles fonctionnalités avec un coût de développement réduit. Pour les systèmes interactifs, certaines propriétés du logiciel comme la modifiabilité, sont très importantes. En effet, la réalisation d’un système interactif nécessite une conception itérative de l’interface centrée sur l’utilisateur : chaque itération du cycle permet de corriger des problèmes d’utilisabilité et ainsi d’améliorer la qualité de l’interface. La modifiabilité du code de l’interface est donc essentielle pour faciliter ces itérations avec un coût de développement le plus faible possible.

Une architecture n'est jamais intrinsèquement bonne ou mauvaise, mais sa qualité se juge à la lumière de propriétés identifiées par avance dans le cadre d’un plan d’assurance qualité. Au-delà des propriétés internes usuelles du Génie Logiciel (modifiabilité, extensibilité, portabilité, etc.), les collecticiels sont concernés par des propriétés externes centrées sur l'utilisateur et l’activité de groupe dont le respect peut avoir un impact sur les solutions architecturales. Au cours de ce chapitre, nous étudions les modèles d’architecture logicielle à la lumière de notre grille d’analyse. Ainsi, nous utilisons des propriétés externes incluses dans notre grille comme élément d'évaluation des architectures spécifiques aux collecticiels. On trouvera dans [IFIP 1996] une discussion systématique

MODÈLESD’ARCHITECTUREPOURLESSYSTÈMESINTERACTIFS

Modèle Arch

des relations entre modèles d'architecture et propriétés externes pour la mise en œuvre de systèmes mono-utilisateur. Notre approche étend ces résultats [IFIP 1996] pour la mise en œuvre de collecticiels.

Ayant défini ce qu’est un modèle d’architecture et son rôle, la partie suivante présente trois modèles d’architecture pour la conception de systèmes interactifs auxquels nous faisons référence lors de la présentation des modèles d’architecture dédiés aux collecticiels.

3.Modèles d’architecture pour les systèmes