Concept: Architecture système
Une architecture système est une représentation d'un système dans laquelle il existe un mappage des fonctionnalités aux composants matériels et logiciels, un mappage de l'architecture logicielle à l'architecture matérielle et une interaction humaine avec ces composants.
Relations
Description principale

Introduction

Le terme architecture est aujourd'hui couramment utilisé dans un autre sens que son sens traditionnel de construction et il existe de nombreuses définitions de l'« architecture » (dans le contexte des systèmes) et de « l'architecture système (ou systèmes) », comme par exemple :

« Architecture systèmes : structure fondamentale et unificatrice du système, définie en termes d'éléments systèmes, d'interfaces, de processus, de contraintes et de comportements » 
[définition de référence approuvée par le groupe de travail sur l'architecture système d'INCOSE lors de la conférence INCOSE '96, qui s'est tenue à Boston (Etats-Unis) le 8 juillet 1996]

« L'architecture système comprend les grandes propriétés physiques, le style, la structure, les interactions et la finalité d'un système ».
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

« Architecture : ensemble des concepts et règles qui définissent la structure, le comportement sémantique et les relations entre les parties d'un système ; plan d'une chose qui doit être construite. L'architecture inclut les éléments qui composent cette chose, les relations qui unissent ces éléments, les contraintes ayant une incidence sur ces relations, une mise en évidence des parties de cette chose et sur la chose dans son ensemble ».
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, qui référence comme source la norme ISO/IEC 10746-2 : Technologies de l'information - Traitement réparti ouvert - Modèle de référence : Fondements]

« Architecture : structure des composants d'un programme/système, leurs interrelations et les principes et instructions qui régissent leur conception et leur évolution dans le temps ».
[DoD 5000.59-P, "Modeling and Simulation Master Plan," octobre 1995]

L'architecture est « la structure des composants, leurs relations et les principes et instructions qui régissent leur conception et leur évolution dans le temps ».
[norme 610.12 de l'institut IEEE, légèrement étendue par le Integrated Architectures Panel (IAP) de la C4ISR Integration Task Force (ITF) dans DoD Architecture Framework, Version 1.0]

Différents termes et constructions sont utilisés et toutes les définitions ne couvrent pas exactement les mêmes aspects, mais les recoupements sont significatifs. Ces définitions montrent que l'architecture système touche aux aspects suivants :

  • la structure du système en termes d'éléments, de composants et de parties
  • les relations entre ces éléments
  • les contraintes ayant une incidence sur les éléments et leurs relations
  • le comportement du système et les interactions qui surviennent entre les éléments pour produire ce comportement
  • les principes, les règles et la logique qui ont fait du système ce qu'il est (et qui régissent son évolution)
  • les caractéristiques et propriétés physiques et logiques du système
  • la finalité du système

Englober véritablement tous ces aspects requiert donc un ensemble d'informations riche et potentiellement complexe, mais il convient de garder à l'esprit que toutes les parties prenantes n'ont pas besoin de voir ou de comprendre simultanément tous ces aspects. La notion de points de vue permet de séparer ces différentes préoccupations et de ne présenter à une catégorie de partie prenante que les éléments dont elle a besoin pour participer de manière efficace. En adoptant un point de vue particulier, on peut également visualiser le système à des « résolutions » différentes, d'une faible résolution, qui correspond à un niveau d'abstraction élevé, à une haute résolution, qui correspond à une spécification concrète (de parties, etc) pour l'implémentation.

Les points de vue

Un point de vue (sur un système) est « une forme d'abstraction obtenue à l'aide d'une sélection de concepts architecturaux et de règles de structuration, afin de mettre en évidence des préoccupations particulières au sein d'un système » [norme ISO/IEC 10746-2 : Technologies de l'information - Traitement réparti ouvert - Modèle de référence : Fondements]. Le tableau ci-dessous répertorie une partie des points de vue retenus pour enregistrer les diverses préoccupations. Ces points de vue sont alignés sur ceux qui figurent dans la norme ISO/IEC 10746-1 : Technologies de l'information - Traitement réparti ouvert - Modèle de référence : Aperçu général.

Point de vue Préoccupation Incidence
Travailleur Préoccupé par les rôles et responsabilités des travailleurs de l'organisation et du système (ainsi que par les règles qui les touchent). Activités des travailleurs, interaction homme/système. Spécification des performances humaines et facteurs humains.
Informations Types d'informations gérés par le système et contraintes d'utilisation et d'interprétation de ces informations. Intégrité des informations, limitations de capacité.
Accessibilité des informations, rapidité.
Logique La décomposition du système en un ensemble de sous-systèmes qui interagissent au niveau des interfaces et collaborent pour la fourniture des services système. Le comportement du système correspond au comportement souhaité.
Le système est extensible, adaptable et maintenable.
Les actifs sont réutilisables.
Distribution/Physique L'infrastructure obligatoire pour la prise en charge de la distribution et des fonctionnalités système. Adéquation des caractéristiques physiques du système afin d'héberger des fonctionnalités et de répondre aux exigences non fonctionnelles.
Processus Accès concurrent, évolutivité, performances, rendement, fiabilité. Adéquation de la réactivité, du rendement et de la tolérance aux pannes du système.

Points de vue communs du système.

Ces points de vue figurent parmi les plus répandus pour les systèmes exigeant beaucoup de logiciels. De nombreuses architectures logicielles requièrent également des points de vue complémentaires, spécifiques au domaine. Citons à titre d'exemple les points de vue de la sécurité et le point de vue de la mécanique. Les points de vue représentent différents domaines de préoccupation qui doivent être traités dans l'architecture et la conception du système. Si les préoccupations de certaines parties prenantes au système ou de certains experts ont une importance dans l'architecture globale, il est probablement nécessaire de créer un ensemble de produits de points de vue pour enregistrer leurs décisions de conception. 

Il est important de mettre sur pied une équipe dédiée à l'architecture système dont le personnel ait les compétences permettant de veiller aux différents points de vue. Cette équipe peut être composée d'analystes métier et d'utilisateurs qui assument la responsabilité principale pour le point de vue du travailleur, d'architectes logiciel qui s'occupent du point de vue logique, d'ingénieurs qui s'intéressent au point de vue physique, ainsi que d'experts qui travaillent sur les points de vue spécifiques au domaine.

Niveaux d'abstraction

Outre des points de vue, une architecture système requiert des niveaux de spécification. A mesure que l'architecture est développée, elle évolue d'une spécification générale et abstraite à une spécification plus détaillée et spécifique. Le processus RUP identifie quatre niveaux architecturaux, comme le montre le tableau ci-dessous.

Niveau du modèle Exprime
Contexte Le système et ses acteurs.
Analyse Partitionnement initial du système permettant de mettre en place l'approche conceptuelle.
Conception Réalisation du modèle d'analyse vers le matériel, les logiciels et les personnes.
Implémentation Réalisation du modèle de conception en configurations spécifiques.

Niveaux architecturaux du processus RUP

Au travers de ces niveaux, la conception passe d'un état abstrait à physique. Le modèle de contexte enregistre toutes les entités externes (acteurs) qui interagissent avec le système. Ces acteurs peuvent être extérieurs à l'entreprise qui déploie le système ou appartenir à cette dernière. Dans les deux cas, les acteurs peuvent être des travailleurs humains ou d'autres systèmes. Au niveau de l'analyse, les partitions ne reflètent pas les choix en matière de matériels, de logiciels ou de personnes. Elles reflètent au contraire les approches de conception pour la division des opérations qui incombent au système et la manière dont l'effort doit être réparti. Au niveau de la conception, les décisions portent sur les types de composants matériels et logiciels et les rôles de travailleurs nécessaires. Au niveau de l'implémentation, des choix précis de matériels et de technologie logicielle sont effectués pour implémenter la conception. A titre d'exemple, au niveau de la conception, un serveur de données peut être spécifié. Au niveau de l'implémentation, la décision est prise d'utiliser une plateforme spécifique exécutant une application de base de données spécifique.

Modèles et diagrammes

Un modèle est une représentation d'un système, qui traite généralement d'un domaine de préoccupation précis. Un système, dès lors, est généralement représenté par un ensemble de modèles, car les préoccupations relatives à son développement ou à son utilisation sont multiples. Chaque modèle peut être construit avec des niveaux variables d'abstraction, du plus général, qui masque ou encapsule les détails, au plus spécifique, qui révèle plus de détails et décisions de conception explicites.

Un point de vue, comme son nom l'indique, est une « position » théorique depuis laquelle peuvent être observés certains aspects ou préoccupations relatifs au système, ce qui implique l'application d'un ensemble de concepts et de règles permettant de constituer un filtre conceptuel. Examiner simplement le vrai système n'est généralement pas suffisant (pour comprendre) — des modèles auront été (ou devront être) construits pour représenter et décrire les préoccupations.

Les vues sont des projections de modèles qui affichent les entités qui sont pertinentes depuis un point de vue donné. Ces projections sont généralement représentées par des diagrammes divers.

L'intersection du point de vue et du niveau d'abstraction ou de spécificité du modèle contient (ou du moins identifie) des vues d'un ou plusieurs modèles pertinents pour ce point de vue ou cette préoccupation, à ce niveau donné d'abstraction.

L'architecture système est ensuite enregistrée dans un ensemble de modèles (et de diagrammes qui les visualisent) qui expriment l'architecture depuis différents points de vue et niveaux. Comme on peut le constater dans le tableau de structure des modèles ci-dessous, il n'existe pas un modèle/diagramme pour chaque combinaison point de vue-niveau. Au niveau de l'implémentation, un unique modèle enregistre la réalisation des composants matériels et logiciels pour chaque configuration système.

Niveau du modèle Points de vue
Travailleur Logique Informations Distribution/Physique Processus
Contexte Vue organisation UML Diagramme de contexte système Vue de données d'entreprise Vue de localisation d'entreprise Vue processus métier
Analyse Vue travailleur système généralisée Vue sous-système Vue données système Vue localisation système Vue processus système
Conception Vue travailleur système Vues de classes de sous-système

Vues de composants de logiciel

Schéma de données de système Vue noeud de descripteur Vue de processus détaillée
Implémentation Spécifications et instructions relatives au rôle du travailleur Configurations : diagrammes de déploiement dotés de composants système matériels et logiciels.

Un grand nombre des vues spécifiées dans le tableau sont dérivées des modèles standards UML. Par exemple, dans le niveau Analyse du point de vue Logique, le système est décomposé en sous-systèmes qui collaborent afin de satisfaire les exigences de l'utilisateur. Les sous-systèmes sont utilisés avec la même sémantique que dans le standard UML. Ces sous-systèmes sont à leur tour décomposés en sous-systèmes ou (finalement) en classes. Le niveau Conception du point de vue Logique correspond à la vue du modèle de classe détaillé. Le modèle de processus est également un modèle de classe UML standard, la mise en évidence portant sur les classes actives du système. Les points de vue spécifiques au domaine doivent également disposer de vues des produits pour un ou plusieurs niveau(x). L'ensemble de produits de projet, au sein de cette infrastructure préfabriquée, doit faire partie du plan de développement du projet.