Concept: Architecture logicielle
L'architecture logicielle représente la ou les structure(s) du système, constituée(s) des composants logiciels, de leurs propriétés visibles et des relations qui les unissent.
Relations
Description principale

Introduction

L'architecture logicielle est un concept facile à comprendre et que la plupart des ingénieurs ressentent de manière intuitive, particulièrement avec un peu d'expérience, mais qui est difficile à définir avec précision. Il est particulièrement difficile de tracer une frontière nette entre la conception et l'architecture (qui est un aspect de la conception qui se concentre sur certaines caractéristiques précises).

Dans An Introduction to Software Architecture, David Garlan et Mary Shaw suggèrent que l'architecture logicielle est un niveau de conception qui s'intéresse aux problèmes : « Au-delà des algorithmes et des structures de données du calcul informatisé, concevoir et spécifier la structure générale des systèmes émerge comme un nouveau type de problème. Les problèmes structurels comprennent l'organisation brute et la structure de contrôle globale, les protocoles de communication, de synchronisation et d'accès aux données, l'affectation des fonctionnalités aux éléments de conception, la distribution physique, la composition des éléments de conception, la mise à l'échelle et les performances, et la sélection parmi les options de conception ». [GAR93]

Mais l'architecture ne se résume pas à des questions de structure ; le groupe de travail sur l'architecture de l'Institut IEEE la définit comme « le concept de plus haut niveau d'un système dans son environnement » [IEP1471]. Elle comprend également « l'adéquation » avec l'intégrité du système, avec les contraintes économiques, avec les soucis esthétiques et avec le style. Elle ne se limite pas à des préoccupations internes, mais prend en compte le système dans son ensemble, dans son environnement utilisateur comme son environnement de développement (préoccupation externe).

Dans le processus RUP, l'architecture d'un système logiciel (à un stade donné) est l'organisation ou la structure des composants significatifs du système interagissant par le biais d'interfaces, les composants étant constitués de composants et d'interfaces de plus en plus petits.

Description de l'architecture

Pour discuter et raisonner au sujet de l'architecture logicielle, vous devez d'abord définir une représentation architecturale, une manière de décrire les aspects importants d'une architecture. Dans le processus RUP, cette description est consignée dans le Document d'architecture logicielle.

Vues d'architecture

Nous avons choisi de représenter l'architecture logicielle dans plusieurs vues d'architecture. Chacune d'entre elles traite d'un ensemble précis de problèmes, spécifiques aux parties prenantes du processus de développement : utilisateurs, concepteurs, responsables, ingénieurs système, personnes chargées de la maintenance, etc.

Les vues enregistrent les grandes décisions de conception structurelle en montrant comment l'architecture logicielle se décompose en composants et comment ces composants sont reliés par des connecteurs pour produire des formats utiles [PW92]. Ces choix de conception doivent être liés aux Exigences fonctionnelles et complémentaires, ainsi qu'aux autres contraintes. Mais ces choix imposent à leur tour des contraintes supplémentaires sur les exigences et sur les futures décisions de conception prises à un niveau inférieur.

Ensemble de vues d'architecture type

L'architecture est représentée par un certain nombre de vues d'architecture différentes, constituées essentiellement d'extraits illustrant les éléments « architecturalement significatifs » des modèles. Dans le processus RUP, on commence à partir d'un ensemble type de vues, appelé « modèle de vues 4+1 »[KRU95]. Ce modèle est composé des éléments suivants :

Les vues d'architecture sont documentées dans le Document d'architecture logicielle. Vous pouvez imaginer d'autres vues pour exprimer diverses préoccupations particulières : vue d'interface utilisateur, vue de sécurité, vue de données, etc. Dans les systèmes simples, vous pouvez omettre certaines des vues contenues dans le modèle de vues 4+1.

Centres d'intérêt pour l'architecture

Bien que les vues mentionnées ci-dessus puissent représenter la totalité de la conception d'un système, l'architecture ne s'intéresse qu'à certains aspects précis :

  • La structure du modèle (les patterns organisationnels), comme par exemple l'organisation en couches.
  • Les éléments essentiels - cas d'utilisation critiques, principales classes, mécanismes communs, etc., par opposition à tous les éléments présents dans le modèle.
  • Quelques scénarios clés montrant les principaux flux de contrôle parcourant le système.
  • Les services, afin d'enregistrer les aspects liés à la modularité, aux dispositifs en option et à la gamme de produits.

Les vues d'architecture sont, fondamentalement, des abstractions, ou des simplifications, de la conception, dans lesquelles les caractéristiques importantes sont mises en évidence en laissant de côté les détails. Ces caractéristiques sont importantes lorsque l'on réfléchit aux paramètres suivants :

  • Evolution du système vers le cycle de développement suivant.
  • Réutilisation de l'architecture, ou de parties de celle-ci, dans le contexte d'une gamme de produits.
  • Evaluation des qualités complémentaires, telles que les performances, la disponibilité, la portabilité et la sécurité.
  • Affectation du travail de développement aux équipes ou sous-traitants.
  • Décisions relatives à l'ajout de composants du commerce.
  • Incorporation dans un système plus grand.

Patterns d'architecture

Les patterns d'architecture sont des formats prêts à l'emploi permettant de résoudre les problèmes architecturaux récurrents. Une infrastructure architecturale préfabriquée ou une infrastructure architecturale (logiciel intermédiaire) est un ensemble de composants à partir desquels vous pouvez générer un certain type d'architecture. Un grand nombre des principales difficultés architecturales devrait être résolu dans l'infrastructure préfabriquée ou dans l'infrastructure, qui cible généralement un domaine particulier : commande et contrôle, système d'informations de gestion, système de contrôle, etc.

Exemples de patterns d'architecture

[BUS96] classe les patterns d'architecture en fonction des caractéristiques des systèmes dans lesquels ils sont les plus applicables, une catégorie traitant en particulier des problèmes plus généraux de structure. Le tableau ci-dessous montre les catégories présentées dans [BUS96] et les patterns qu'elles contiennent.

Catégorie Pattern
Structure Couches
Canaux et filtres
Tableau noir
Systèmes répartis Courtier
Systèmes interactifs Architecture MVC
Architecture PAC
Systèmes adaptables Reflet
Micronoyau

Deux de ces patterns sont ici présentés de manière plus détaillée, afin de clarifier ces principes ; pour une présentation complète, voir [BUS96]. Les patterns sont présentés au format courant suivant :

  • Nom du pattern
  • Contexte
  • Problème
    • Forces décrivant les différents aspects problématiques à étudier
  • Solution
    • Justification
    • Contexte obtenu
    • Exemples
Nom du pattern

Couches

Contexte

Grand système nécessitant une décomposition.

Problème

Un système qui doit gérer des problèmes à des niveaux différents d'abstraction.  Par exemple : problèmes de contrôle matériel, problèmes liés aux services partageables et problèmes spécifiques au domaine. Il serait extrêmement peu souhaitable d'écrire des composants verticaux qui gèrent les problèmes à tous les niveaux. Un même problème devrait être traité plusieurs fois (et probablement avec un manque de cohérence) dans différents composants.

Forces

  • Les composants du système doivent être remplaçables.
  • Les changements apportés aux composants ne doivent pas avoir de répercussions.
  • Les responsabilités similaires doivent être regroupées.
  • La taille des composants complexes doit être réduite par décomposition.
Solution

Structurez les systèmes en groupes de composants formant des couches empilées. Faites en sorte que les couches supérieures n'utilisent les services que des couches situées en dessous (et jamais ceux des couches situées au-dessus). Essayez de ne pas utiliser d'autres services que ceux de la couche directement en dessous (ne sautez pas de couche, à moins que des couches intermédiaires existent, au risque d'ajouter des composants passe-système).

Exemples :

1. Couches génériques

Le diagramme est détaillé dans le contenu.

Une architecture en couches stricte établit que les éléments de conception (classes, packages, sous-systèmes) n'utilisent que les services de la couche en dessous d'eux.Les services peuvent comprendre le traitement des événements, le traitement d'erreurs, l'accès aux bases de données, etc. Elle contient des mécanismes plus palpables, contrairement aux appels bruts au niveau du système d'exploitation, documentés dans la couche inférieure.

2. Couches du système métier

Le diagramme est détaillé dans le contenu.

Le diagramme ci-dessus montre un autre exemple d'organisation en couche, dans lequel on trouve des couches verticales propres à l'application et des couches horizontales, d'infrastructure. Il est à noter que l'objectif est d'obtenir des structures verticales métier ('stovepipe') très courtes et d'exploiter les éléments communs entre applications.  Dans le cas contraire, plusieurs personnes se retrouveraient à résoudre le même problème, éventuellement de manière différente.

Voir Instructions : Organisation en couches pour plus d'informations sur ce pattern.

Nom du pattern

Tableau noir

Contexte

Un domaine dans lequel aucune approche fermée (algorithmique) de résolution d'un problème n'est connue ou faisable. Citons par exemple les systèmes d'intelligence artificielle, la reconnaissance vocale et les systèmes de surveillance.

Problème

Plusieurs agents de résolution de problème (agents de gestion des connaissances) doivent coopérer pour résoudre un problème ne pouvant être résolu individuellement par aucun des agents. Les résultats du travail des différents agents doivent être accessible à tous les autres agents afin qu'ils puissent évaluer s'ils peuvent aider à trouver une solution et publier les résultats de leur travail.

Forces

  • L'ordre dans lequel les agents de gestion des connaissances peuvent aider à résoudre le problème n'est pas déterministe et peut dépendre des stratégies de résolution de problème.

  • Les contributions des différents agents (solutions partielles ou finales) peuvent avoir différentes représentations.

  • Les agents n'ont pas directement connaissance de l'existence des autres agents mais peuvent évaluer les contributions publiées par les uns et les autres.

Solution

Un certain nombre d'agents de gestion des connaissances ont accès à un magasin de données partagées appelé Tableau noir. Ce dernier fournit une interface permettant d'inspecter et de mettre à jour son contenu. L'objet/module de contrôle active les agents en respectant une certaine stratégie. Une fois activé, un agent contrôle le tableau noir pour voir s'il peut aider à résoudre le problème. Si l'agent établit qu'il peut apporter une aide, l'objet de contrôle peut autoriser les agents à inscrire leur solution partielle (ou finale) au tableau.

Exemple :

Le diagramme est détaillé dans le contenu.

Ce diagramme illustre la vue structurelle ou statique modélisée à l'aide du langage UML. Elle ferait partie d'une collaboration paramétrée, qui est ensuite reliée aux paramètres réels afin d'instancier le pattern.

Style architectural

Une architecture logicielle, ou une vue d'architecture seule, peut comporter un attribut appelé style architectural, qui réduit le choix de formats possibles et impose un certain degré d'uniformité à l'architecture. Le style peut être défini par un ensemble de patterns ou par le choix de composants ou de connecteurs spécifiques comme blocs de génération élémentaires. Pour un système donné, une partie du style peut être enregistrée comme partie de la description architecturale dans un guide de style architectural, fourni via le produit  Instructions spécifiques au projet du processus RUP. Le style joue un rôle majeur dans l'intelligibilité et l'intégrité de l'architecture.

Plans architecturaux

La représentation graphique d'une vue d'architecture est appelée plan architectural. Pour les diverses vues décrites plus haut, les plans sont composés des diagrammes suivants provenant du langage UML [UML01] :

  • Vue logique. Diagrammes de classes, machines d'états et diagrammes d'objets
  • Vue de processus. Diagrammes de classes et diagrammes d'objets (englobant les processus-tâches et les unités d'exécution)
  • Vue d'implémentation. Diagrammes de composants
  • Vue de déploiement. Diagrammes de déploiement
  • Vue de cas d'utilisation. Diagrammes de cas d'utilisation représentant les cas d'utilisation, les acteurs et les classes de conception ordinaires ; diagrammes de séquence représentant les objets de conception et leur collaboration

Le processus de création d'architecture

Dans le processus RUP, l'architecture est principalement le résultat de l'enchaînement d'activités d'analyse & de conception. A mesure que le projet applique encore et encore cet enchaînement d'activités, itération après itération, l'architecture évolue et devient détaillée et mieux finalisée. Etant donné que chaque itération prévoit une intégration et un test, l'architecture est assez robuste au moment de la livraison du produit. Cette architecture est un objectif central des itérations de la phase d'élaboration, à l'issue de laquelle une version de référence de l'architecture est normalement créée.