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.
|