Concepts : Architecture logicielle
Rubriques
L'architecture logicielle est un concept facile à comprendre, intuitivement saisi par la plupart des ingénieurs (en particulier s'ils sont un peu expérimentés), qui reste toutefois difficile à définir de façon précise. En particulier, il n'est pas évident de faire clairement la distinction entre conception et architecture, dans la mesure où l'architecture est elle-même un aspect de la conception centré sur des fonctions spécifiques.
Dans An Introduction to Software Architecture, David Garlan et
Mary Shaw considèrent l'architecture logicielle comme un niveau de conception lié à la résolution de problèmes : "Au-delà des algorithmes et des structures de données de la représentation informatique, la conception et la spécification de la structure globale du système apparaît comme un nouveau problème. Les questions structurelles incluent notamment l'organisation et la structure de contrôle globales, les protocoles de communication, la synchronisation et l'accès aux données, l'affectation des fonctionnalités aux éléments de conception, la répartition physique, la composition des éléments de conception, l'échelonnement et la performance ainsi que la sélection d'alternatives de conception." [GAR93].
Mais l'architecture ne se limite pas à la structure ; le groupe de travail sur l'architecture de l'IEEE la définit d'ailleurs comme "le concept de niveau le plus élevé d'un système dans son environnement" [IEP1471].
L'architecture implique également une "adéquation" avec l'intégrité du système, les contraintes économiques, l'esthétique et le style. L'architecture n'est pas uniquement orientée vers l'intérieur, mais envisage l'ensemble du système dans son environnement utilisateur et dans son environnement de développement. Elle est donc également tournée vers l'extérieur.
Dans RUP, l'architecture logicielle (à un certain stade) renvoie à l'organisation ou à la structure des composants clés du système qui interagissent, par le biais des interfaces, avec des composants constitués d'interfaces et de composants de taille toujours plus réduite.
Pour pouvoir parler d'architecture logicielle et réfléchir sur le sujet, il est nécessaire de définir en premier lieu une représentation d'architecture, c'est-à-dire d'établir une description des aspects importants d'une architecture. Dans RUP, cette description est disponible dans le document d'architecture logicielle.
Nous avons choisi de représenter l'architecture logicielle par le biais de plusieurs vues d'architecture
. Chacune d'elles aborde une série d'aspects spécifiques à chaque partie prenantedu processus de développement : utilisateurs, concepteurs, gestionnaires, ingénieurs système, équipe de maintenance, etc.
Ces vues mettent en évidence les décisions clés en matière de conception de structure et décrivent comment l'architecture logicielle s'articule autour des différents composants. Elles détaillent également la façon dont ces composants sont reliés à des connecteurs et produisent ainsi des canevas très pratiques [PW92].
Les décisions relatives à la conception doivent être prises en fonction des exigences,
fonctionnelles et complémentaires, et des contraintes. Il convient de souligner toutefois que ces choix imposent à leur tour des contraintes vis à vis des exigences et des décisions de conception qui interviendront par la suite à un niveau inférieur.
L'architecture est représentée via différentes vues d'architecture. Celles-ci sont, par essence, des extraits permettant d'illustrer les éléments de modèles les plus "significatifs
du point de vue de l'architecture". Dans RUP, une série de vues caractéristiques, le"modèle de vue 4+1" [KRU95] est disponible par défaut.
Celle-ci inclut :
- La vue Cas d'utilisation,
qui comprend les cas d'utilisation et les scénarios incluant les comportements significatifs du point de vue de l'architecture, les classes, ou 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 décrit leur organisation en packages et sous-systèmes, eux-mêmes agencés en couches.
Cette vue comprend également des réalisations de cas d'utilisation. Il s'agit d'un sous-ensemble du modèle de conception.
- La vue Implémentation,
propose un vue d'ensemble du modèle d'implémentation
et en décrit l'organisation en modules divisés en packages et en 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étaillée. Il s'agit d'un sous-ensemble du modèle d'implémentation.
- La vue Processus, qui comprend la description des tâches (processus et unités d'exécution) impliquées, les interactions et les configurations, ainsi que l'attribution d'objets de conception et de classes aux tâches. Cette vue ne doit être employée que si le système présente un niveau d'accès concurrent suffisant. Dans RUP, il s'agit d'un sous-ensemble du modèle de conception.
- La vue Déploiement, qui inclut la description de plusieurs noeuds physiques pour les configurations de plateforme les plus courantes, et l'attribution de tâches (à partir de la vue Processus) à ces noeuds physiques. Cette vue ne doit être employée que si le système est réparti. 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 logicielle. Vous pouvez également imaginer d'autres vues en fonction des questions spécifiques que vous voulez aborder : vue Interface utilisateur, vue Sécurité, vue Données, etc. Dans les systèmes simples, vous pouvez ignorer certaines vues proposées dans le modèle de vue 4+1.
Bien que les vues citées précédemment représentent parfois la conception globale du système, l'architecture proprement dite ne concerne que certains aspects spécifiques :
- La structure du modèle : les patterns organisationnels, notamment l'agencement en couches.
- Les éléments essentiels : les cas d'utilisation, classes principales, et autres mécanismes communs indispensables (par opposition à tous les autres éléments inclus dans le modèle).
- Quelques scénarios clés décrivant les principaux flots de contrôle à travers le système.
- Les services, permettant d'identifier la modularité, les fonctionnalités en option, les aspects relatifs à la gamme de produits.
Par essence, les vues d'architecture sont des abstractions, ou des simplifications
de conception, dans lesquelles les caractéristiques essentielles sont mises en évidence et les détails ignorés. Ces caractéristiques sont d'une grande importance lorsqu'il s'agit de réfléchir sur :
- l'évolution du système dans le cadre du prochain cycle de développement ;
- la réutilisation totale ou partielle de l'architecture, dans le contexte d'une gamme de produits ;
- l'évaluation de qualités complémentaires, telles que la performance, la disponibilité,
la portabilité, et la sécurité ;
- la délégation de la phase de développement à des équipes de travail ou à des sous-traitants ;
- les décisions relatives à l'inclusion de composants disponibles dans le commerce ;
- l'insertion d'un système de plus grande envergure.
Les patterns d'architecture sont des canevas prêts à l'emploi permettant de résoudre les problèmes architecturaux récurrents. Un cadre d'architecture ou infrastructure d'architecture (middleware) est un ensemble de composants à partir duquel 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 les schémas d'architecture en fonction des caractéristiques des systèmes dans lesquels ils sont le plus susceptibles d'être appliqués, et inclut une catégorie plus particulièrement chargée de traiter les problèmes structurels d'ordre général. Le tableau ci-après décrit les catégories
proposées par [BUS96]
et les patterns qu'elles contiennent.
Catégorie |
Pattern |
Structure |
Couches |
Tuyaux et filtres |
Tableau noir |
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 patterns sont détaillés ci-après, afin d'en clarifier le concept. Pour plus d'informations, voir [BUS96]. Les patterns se présentent généralement comme suit :
- Nom du pattern
- Contexte
- Problème
- Contraintes décrivant divers aspects du problème à prendre en considération.
- Solution
- Justification
- Contexte résultant
- Exemples
Nom du pattern
Couches
Contexte
Un système étendu qui doit être décomposé.
Problème
Le système doit gérer des problèmes de niveaux d'abstraction différents, par exemple, les problèmes liés au contrôle du matériel, les difficultés courantes relatives aux services et les questions inhérentes au domaine. Il est fortement déconseillé d'écrire des composants verticaux permettant de traiter les problèmes indépendamment de leur niveau. Le cas échéant, une même difficulté serait prise en charge plusieurs fois par divers composants (et probablement de façon incohérente).
Contraintes
- Les différentes parties du système doivent pouvoir être remplacées.
- Les modifications opérées au niveau des composants ne doivent pas entraîner de perturbations.
- Les responsabilités de même nature doivent être regroupées.
- La taille des composants : les composants complexes doivent être dissociés.
Solution
Structurer les systèmes en groupes de composants de façon à obtenir une superposition de couches. Faire en sorte que les couches fassent appel aux services des couches inférieures (jamais aux services des couches situées au-dessus).
Veiller à ne pas utiliser les services autres que ceux proposés par la couche immédiatement inférieure (ne pas ignorer de couche car, si tel était le cas, les couches intermédiaires n'ajouteraient
que des composants passerelles).
Exemples :
1. Couches génériques

Une architecture strictement organisée en couches suppose que les éléments de conception (classes,
packages, sous-systèmes) fassent uniquement appel aux services de la couche qui leur est immédiatement inférieure. Ces services peuvent inclure le traitement des événements, le traitement de erreurs, l'accès aux bases de données, etc. Ils comprennent des mécanismes plus concrets que les invocations de base du système d'exploitation documentées dans la première couche en partant du bas.
2. Couches du système d'application

Le diagramme ci-dessus illustre un nouvel exemple d'organisation en couches dans lequel on distingue des applications verticales (couches spécifiques) et des couches d'infrastructure horizontales.
Il convient de souligner que l'objectif est d'obtenir des " tuyaux de poêle " métier les plus courts possible et d'exploiter les points communs entre les applications. Si tel n'est pas le cas, plusieurs personnes peuvent être amenées à résoudre le même problème et éventuellement de façon différente.
Voir Principes et conseils : Création de couches
pour plus d'informations sur ce type de pattern.
Nom du pattern
Tableau noir
Contexte
Un domaine pour lequel il n'existe aucune approche fermée (algorithmique) connue ou réalisable permettant la résolution de problèmes. Il peut s'agir, par exemple, d'un système d'intelligence artificielle, de reconnaissance vocale ou de surveillance.
Problème
Plusieurs agents de résolution de problèmes (agents de connaissance) doivent coopérer dans le but de traiter les problèmes auxquels les agents individuels ne peuvent trouver de solution. Les agents doivent pouvoir accéder aux résultats obtenus par les agents individuels afin de déterminer dans quelle mesure ils peuvent contribuer à la solution, et de transmettre le résultat de leur travail.
Contraintes
-
L'ordre dans lequel les agents de connaissance interviennent dans la résolution d'un problème donné n'est pas déterministe et dépend des stratégies de résolution mises en place.
-
Les données entrées par les agents (résultats ou solutions partielles) peuvent avoir des représentations différentes.
-
Les agents ne se connaissent pas directement mais ils ont la possibilité d'évaluer mutuellement leurs contributions.
Solution
Plusieurs agents de connaissance ont accès à un magasin de données partagées nommé Tableau noir. Celui-ci comporte une interface permettant de vérifier et de mettre à jour son contenu. Le module/objet de contrôle active les agents de façon stratégique.
Lorsqu'il est activé, l'agent examine le tableau noir afin de déterminer s'il peut contribuer à la résolution du problème. Le cas échéant, l'objet de contrôle peut autoriser l'agent à "inscrire" une solution (partielle ou finale) sur le tableau.
Exemple :

Ce diagramme présente la vue structurelle ou statique modélisée en langage UML.
Celle-ci s'inscrit dans le cadre d'une collaboration paramétrée, qui doit donc instancier le pattern en fonction des paramètres effectifs.
Il est possible qu'une architecture logicielle, ou simplement une vue d'architecture, comprenne un attribut
style d'architecture. Cet attribut réduit le choix de formes possible et impose un certain degré d'uniformité dans l'architecture. Le style est défini par un ensemble de patterns, ou bien par la sélection de composants spécifiques ou de connecteurs comme blocs constitutifs. Pour un système donné, certains éléments de style peuvent figurer, en tant qu'éléments de description de l'architecture, dans un guide de style d'architecture
. Le style joue un rôle essentiel en termes d'intelligibilité et d'intégrité de l'architecture.
L'architecture orientée service (SOA), en pleine expansion, est un exemple remarquable de style d'architecture : la SOA est une étape évolutive qui repose sur l'orientation objet et sur un développement basé sur les composants, en vue de fournir, par le biais d'une couche de services, des services analogues aux fonctions métier qui exécutent totalement ou partiellement les processus métier enregistrés, notamment les cas d'utilisation métier. Alors que ces services peuvent être proposés par des composants, ils se distinguent par leur caractère compositionnel dans la mesure où ils gèrent la collaboration d'un ensemble de composants (mappage avec des entités de gestion de niveau inférieur) afin d'offrir une fonction métier à plus gros grain et de plus grande valeur. Ces notions sont encore en pleine évolution, et il n'existe pas encore d'accord universel sur la terminologie ou la précision des caractéristiques élémentaires d'une SOA, toutefois les points énumérés ci-après semblent généralement admis :
- Les services doivent autoriser un couplage lâche entre l'utilisateur et le fournisseur ; l'utilisateur doit pouvoir découvrir les services de façon dynamique (par exemple, par le biais d'un registre ou d'un courtier) et il est, en outre, tenu de respecter le contrat d'interface du service pendant toute la durée de l'invocation du service.
- Les interactions se mettent en place (avec les applications et les autres services), souvent de façon asynchrone, sur un modèle de communication fondé sur les messages.
- Les services, généralement sans état, gèrent des groupes de ressources en transmettant les objets de valeur aux demandeurs.
Pour plus d'informations sur les SOA, voir le document technique Rational (logiciel IBM) "Using Service-Oriented Architecture and Component-Based
Development to Build Web Service Applications".
La description graphique d'une vue d'architecture est appelée plan d'architecture. Les plans des vues décrites précédemment se composent des diagrammes UML [UML01] suivants :
- Vue Logique - Diagrammes de classes, automates à états et diagrammes d'objets.
- Vue Processus - Diagrammes de classes et diagrammes d'objets (incluant les processus de tâches et les unités d'exécution).
- Vue Implémentation -
Diagrammes de composants
- Vue Déploiement - Diagrammes de déploiement
- Vue Cas d'utilisation -
Diagrammes de cas d'utilisation décrivant les cas d'utilisation, les parties prenantes et les classes de conception ordinaires ; diagrammes de séquence décrivant les objets de conception et leur collaboration.
Dans RUP, l'architecture résulte essentiellement de l'enchaînement des activités d'Analyse et de conception. Comme le projet reproduit cet enchaînement, au fur et à mesure des itérations, l'architecture évolue : elle est dégrossie et affinée. Chacune de ces itérations impliquant une phase d'intégration et de test, l'architecture est suffisamment solide au moment de la livraison du produit. La définition de l'architecture constitue l'un des objectifs principaux des itérations associées à la phase d'élaboration,
à l'issue de laquelle l'architecture de base est normalement déterminée.
| |
|