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.
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.
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.
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 :
-
La vue des cas d'utilisation, qui contient des cas d'utilisation et des
scénarios couvrant le comportement, les classes ou les risques techniques architecturalement significatifs. Cette
vue est un sous-ensemble du Modèle de cas d'utilisation.
-
La vue logique, qui contient les classes de conception les plus importantes et leur organisation
en packages et sous-systèmes, et l'organisation de ces packages et sous-systèmes
en couches. Cette vue contient également certaines réalisations de cas d'utilisation. Cette vue est un sous-ensemble
du modèle de conception.
-
La vue d'implémentation, qui contient une vue d'ensemble du modèle d'implémentation et son organisation en termes de modules
en packages et en couches. L'allocation des packages et des classes (à partir de la vue logique) aux packages et
aux modules de la vue d'implémentation est également décrite. Cette vue est un sous-ensemble du modèle d'implémentation.
-
La vue de processus, qui contient la description des tâches (processus et unités
d'exécution) impliquées, leurs interactions et configurations, et l'allocation des classes et objets de conception
aux tâches. Cette vue ne doit être utilisée que si le système connaît un niveau élevé d'accès concurrent. Dans le processus RUP, cette vue est un sous-ensemble du modèle de conception.
-
La vue de déploiement, qui contient la description des divers noeuds physiques pour
les configurations de plateforme les plus typiques et l'allocation des tâches (à partir de la vue de processus) aux
noeuds physiques. Cette vue ne doit être utilisée que si le système est réparti. Elle constitue un sous-ensemble du
modèle de déploiement.
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.
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.
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
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 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 :
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.
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.
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
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.
|