Rubriques

Introduction Haut de la page

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.

Description de l'architecture Haut de la page

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.

Vues d'architecture Haut de la page

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.

Ensemble typique de vues d'architecture Haut de la page

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 :

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.

Foyer d'architecture Haut de la page

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.

Schémas d'architecture Haut de la page

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

Diagramme décrit dans le contenu.

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

Diagramme décrit dans le contenu.

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 :

Diagramme décrit dans le contenu.

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.

Style d'architecture Haut de la page

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.

Plans d'architecture Haut de la page

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

Processus de définition d'architecture Haut de la page

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.



RUP (Rational Unified Process)   2003.06.15