Concepts : Architecture logicielle
Rubriques
L'architecture logicielle est un concept facile à comprendre, et que la
plupart des ingénieurs ressentent intuitivement, spécialement avec peu
d'expérience, mais qu'il est difficile de définir précisément.
En particulier, il est difficile de tirer un trait entre la conception
et l'architecture. L'architecture est un aspect de conception qui se
concentre sur certaines fonctions spécifiques.
Dans une introduction à l'architecture logicielle, David Garlan et
Mary Shaw émettent l'idée que l'architecture logicielle est un niveau de
conception concerné par des problèmes : "Au-delà des algorithmes et des
structures de données de calcul, la conception et la spécification de la
structure système complète émerge un nouveau type de problème.
Les problèmes structurels incluent les éléments suivants : l'organisation brute et la structure
de contrôle globale ; les protocoles de communication, la synchronisation et
l'accès aux données ; l'affectation des fonctionnalités aux éléments de
conception ; l'évolutivité et les performances ; et le choix parmi les
alternatives de conception." [GAR93]
Mais il y a plus dans l'architecture qu'une simple structure. Le groupe de
travail sur l'architecture de l'IEEE la définit comme "le concept le plus
élevé d'un système dans son environnement"
[IEP1471].
Elle englobe également l'"insertion" dans l'intégrité du système,
avec des contraintes économiques, des questions esthétiques et de style.
Elle ne se limite pas à un foyer sur l'intérieur, mais prend en
considération le système dans sa globalité dans son environnement utilisateur
et son environnement de développement : un foyer vers l'extérieur.
Dans le processus RUP, l'architecture d'un système logiciel (à un point
donné) est l'organisation ou la structure des composants importants du système
qui interagissent via des interfaces, avec des composants composés de petits
composants et d'interfaces successivement plus petits.
Pour pouvoir parler de l'architecture logicielle, vous devez d'abord
définir une représentation d'architecture qui permet de décrire les aspects
importants d'une architecture. Dans le processus RUP, cette description est
capturée dans le document d'architecture
logicielle.
Nous avons choisi de représenter l'architecture logicielle en plusieurs
vues d'architecture. Chaque vue d'architecture répond à un ensemble
spécifique de questions, spécifiques aux parties prenantes dans le processus de
développement : utilisateurs finaux, concepteurs, gestionnaires, ingénieurs
système, responsable de maintenance, etc.
Les vues capturent les principales décisions de conception structurelle en
montrant comment l'architecture logicielle se décompose en composants et
comment les composants sont connectés par des connecteurs afin de
produire des formulaires utiles
[PW92].
Ces choix de conception doivent être liés aux
exigences, fonctionnelles et
supplémentaires, et à d'autres contraintes.
Mais ces choix en retour, mettent davantage de contraintes sur les
exigences et sur les décisions de conception futures à 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, nous partons d'un ensemble typique de vues, appelé le
"modèle de vue 4+1" [KRU95].
Il se compose des éléments suivants :
- La vue de cas
d'utilisation qui contient des cas d'utilisation et des scénarios
couvrant le comportement architecturalement significatif, les classes et les
risques techniques. Il s'agit d'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.
Il comporte également des réalisations
de cas d'utilisation. Il s'agit d'un sous-ensemble du
modèle de conception.
- La vue d'implémentation qui
contient une présentation du
modèle d'implémentation et son
organisation en termes de modules en packages et couches.
L'allocation de packages et de classes (à partir de la vue Logique) aux packages et aux
modules de la vue Implémentation est également décrite.
Il s'agit d'un sous-ensemble du
modèle d'implémentation.
- La vue des processus qui contient la
description des tâches (processus et unités d'exécution) impliquées, leurs
interactions et configurations, ainsi que l'allocation des objets de
conception et des classes aux tâches. Cette vue ne doit être utilisée que si
le système présente un degré important de simultanéité. Dans
le processus RUP, il s'agit d'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, ainsi que l'allocation des
tâches (de la vue des processus) aux noeuds physiques. Cette vue ne doit être
utilisée que si le système est distribué. Il s'agit d'un sous-ensemble du
modèle de déploiement.
Les vues d'architecture sont documentées dans le Document d'architecture du logiciel. Vous
pouvez envisager des vues supplémentaires pour exprimer différents problèmes
spécifiques : vue d'interface utilisateur, vue de sécurité, etc.
Pour les systèmes simples, vous pouvez omettre certaines des vues contenues
dans le modèle de vues 4+1.
Bien que les vues ci-dessus puissent représenter la conception
globale d'un système, l'architecture ne se concentre que sur certains aspects
spécifiques :
- La structure du modèle : les patterns organisationnels, par exemple
les couches.
- Les éléments essentiels :
cas d'utilisation sensibles,
classes principales, mécanismes
courants, etc., opposés à tous les éléments présents dans le modèle.
- Quelques scénarios clés montrant les principaux flux de
contrôle à travers le système.
- Les services, pour capturer la modularité, des fonctions
optionnelles, des aspects de ligne produit.
Par essence, les vues d'architecture sont des abstractions, ou
des simplifications, de la conception complète, dans laquelle des
caractéristiques importantes sont rendues plus visibles en mettant de côté les
détails. Ces caractéristiques sont importantes lors du raisonnement sur :
- L'évolution du système jusqu'au cycle de développement suivant.
- La réutilisation de l'architecture, en tout ou partie, dans le contexte
d'une gamme de produits.
- L'évaluation de qualités supplémentaires, telles que les performances,
la disponibilité, la portabilité et la sécurité.
- L'affectation du travail de développement aux équipes ou sous-traitants.
- Les décisions relatives à l'intégration de composants du commerce.
- L'insertion dans un système plus large.
Les schémas
d'architecture sont des formes toutes prêtes qui résolvent les
problèmes d'architecture récurrents.
Un cadre d'architecture ou une infrastructure d'architecture (middleware) est un ensemble
de composants sur lesquels vous pouvez construire un certain type d'architecture. La plupart des principales difficultés architecturales doivent être résolues dans ce cadre ou cette infrastructure, généralement tournée vers un domaine spécifique : commande et contrôle, système d'informations de gestion, système de contrôle, etc.
Exemples de schémas d'architecture
[BUS96] regroupe des schémas
d'architecture en fonction des caractéristiques des systèmes dans lesquels ils
sont le plus applicables, avec une catégorie traitant de questions de
structuration plus générales. Le tableau montre les catégories présentées
dans [BUS96] et les patterns qu'elles
contiennent.
Catégorie |
Pattern |
Structure |
Couches |
Tuyaux et filtres |
Tableau noir (Blackboard) |
Systèmes répartis |
Courtier |
Systèmes interactifs |
Modèle-Vue-Contrôleur |
Présentation-Abstraction-Contrôle |
Systèmes adaptables |
Reflet |
Micro-noyau |
Deux de ces éléments sont détaillés ici, afin d'éclaircir ces idées. Pour
un traitement complet, voir [BUS96]. Des
patterns sont présentés dans la forme largement répandue suivante :
- Nom de pattern
- Contexte
- Problème
- Force la description des différents aspects de problème qui doivent être pris en compte.
- Solution
- Justification
- Contexte résultant
- Exemples
Nom de pattern
Couches
Contexte
Un large système nécessitant une décomposition.
Problème
Un système qui doit traiter les problèmes à différents niveaux
d'abstraction. Par exemple :
problèmes de contrôle matériel, problèmes de services communs et
problèmes spécifiques au domaine. Il serait fortement indésirable d'écrire des
composants verticaux qui traitent des problèmes à tous les niveaux.
Le même problème devrait être traité (probablement de manière incohérente)
plusieurs fois dans différents composants.
Implications
- Les parties du système doivent être remplaçables.
- Les changements dans les composants ne doivent pas se répercuter.
- Les responsabilités similaires doivent être regroupées.
- La taille des composants complexes peut devoir être décomposée.
Solution
Structurez les systèmes en groupes de composants formant des couches les
uns au-dessus des autres. Faites que les couches supérieures utilisent les
services des couches inférieures uniquement (jamais au-dessus).
N'essayez pas d'utiliser des services autres que ceux de la couche
directement inférieure (ne sautez pas de couche, sauf si les couches
intermédiaires n'ajoutent que des composants de passage).
Exemples :
1. Couches génériques

Une architecture en couches stricte indique que les éléments
de conception (classes, packages, sous-systèmes) utilisent uniquement les
services de la couche immédiatement inférieure. Les services peuvent
inclure le traitement des événements, le traitement des erreurs, l'accès
à une base de données, etc. Elle
contient des mécanismes plus palpables, à l'opposé des appels au niveau du
système d'exploitation brut, documentés dans la couche inférieure.
2. Couches système métier

Le diagramme ci-dessus montrer un autre exemple de couches,
dans lequel figurent des couches spécifiques aux applications verticales et des
couches d'infrastructure horizontale. Notez que le but est d'obtenir des
"héritages" métier très courts et d'utiliser la similitude entre les
applications. Sinon, plusieurs personnes
peuvent tenter de résoudre le même problème, de manière potentiellement
différente.
Pour plus de détails
sur ce point, voir Principes et conseils : Couches.
Nom de pattern
Tableau noir
Contexte
Domaine dans lequel aucune approche fermée (algorithme) à
la résolution du problème n'est connue ou faisable. Les systèmes d'intelligence
artificielle (IA), de reconnaissance vocale et de surveillance en sont des exemples.
Problème
Plusieurs agents de résolution des problèmes (agents de gestion
des connaissances) doivent coopérer pour résoudre un problème qui ne peut pas
être résolu par aucun des agents individuels.
Les résultats du travail des agents individuels doivent être accessibles à tous
les autres agents de sorte qu'ils puissent évaluer s'ils peuvent contribuer à
trouver une solution et publier les résultats de leur travail.
Implications
-
La séquence dans laquelle les agents de gestion
des connaissances peuvent contribuer à la résolution du problème n'est pas déterministe et peut
dépendre des stratégies de résolution du problème.
-
Les entrées des différents agents (résultats ou solutions
partielles) peuvent avoir des représentations différentes.
-
Les agents ne connaissent pas directement l'existence des
autres, mais peuvent évaluer les contributions publiées de chacun.
Solution
Un certain nombre d'agents de gestion des connaissances a accès
à un magasin de données partagées, appelé "tableau noir". Celui-ci fournit une
interface permettant d'inspecter et de mettre à jour son contenu.
Le module/objet de contrôle active les agents selon une certaine stratégie.
Lors de l'activation, un agent inspecte ce "tableau noir" pour voir s'il peut
contribuer à résoudre le problème.
Si l'agent détermines qu'il peut apporter une contribution, l'objet de
contrôle peut permettre aux agents de placer leur solution partielle (ou
finale) sur le tableau.
Exemple :

Ceci illustre la vue vue structurelle ou statique modélisée à
l'aide du langage UML. Ceci ferait partie d'une collaboration paramétrée, ensuite liée aux paramètres réels pour instancier le pattern.
Une architecture logicielle, ou seulement une vue d'architecture, peut
comporter un attribut appelé style d'architecture qui réduit l'ensemble
des formes possibles parmi lesquelles choisir 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 connecteurs spécifiques comme blocs de
construction de base. Pour un système donné, une partie du style peut être
capturée comme élément de description architecturale dans un
guide d style d'architecture, . Le style jour un rôle
important pour la compréhension et l'intégrité de l'architecture.
La description graphique d'une vue d'architecture est appelée
plan d'architecture. Pour les diverses vues décrites ci-dessus, les
plans sont composés des diagrammes suivants du langage UML [UML01]:
- Vue logique. Diagrammes de classes,
automates à états et diagrammes d'objets
- Vue de processus. Diagrammes de classes
et diagrammes d'objets (englobant les tâches : processus et 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 décrivant des cas d'utilisation, des acteurs et
des classes de conception ordinaires ; diagrammes de séquence décrivant des
objets de conception et leur collaboration
Dans le processus RUP, l'architecture est principalement issue de
l'enchaînement d'activités Analyse et Conception. Comme
ce projet reproduit cet enchaînement d'activités, itération après itération,
l'architecture évolue pour se peaufiner. Comme chaque itération inclut
une étape d'intégration et de tests, l'architecture est assez robuste lors de
l'aboutissement au produit livré. Cette architecture est l'un des points
cruciaux des itérations de la phase
d'élaboration, au bout de laquelle
l'architecture est normalement fondée.
|