L’essentiel à retenir
- Un système a un ou plusieurs stakeholders, porteurs de concerns.
- Concern ≠ requirement : le concern se décompose en requirements.
- Viewpoint = gabarit ; view = instance construite à partir de modèles.
- On choisit les viewpoints avant de construire les views.
- Vision, ADD et Communications Plan s’appuient tous sur les concerns.
Une chaîne en cinq maillons
Un système a un ou plusieurs stakeholders : individus, équipes, organisations ou classes de ceux-ci, qui ont un intérêt dans le système. Chacun porte des concerns, c’est-à-dire des domaines d’intérêt : performance, fiabilité, sécurité, distribution, évolutivité… Les concerns peuvent conditionner l’acceptabilité du système.
Un concern n’est pas un requirement. C’est la racine d’une décomposition : on le traduit ensuite en requirements, qui le représentent dans l’architecture. Un architecte sécurité s’intéresse par exemple à l’authentification, à l’autorisation, à l’audit ou à la protection des actifs ; ces concerns deviendront des exigences vérifiables.
Le viewpoint définit la perspective : comment construire et utiliser une view, quelles informations, quelles techniques de modélisation, et pourquoi (finalité, public). La view est la représentation obtenue : elle sélectionne des parties d’un ou plusieurs modèles pour montrer aux stakeholders que leurs concerns sont traités.
- Stakeholder → porte des concerns
- Concern → décomposé en requirements
- Viewpoint → gabarit (template) pour un ensemble de concerns
- View → instance du gabarit, faite de parties de modèles
- Architecture Description → ensemble de views et de modèles
La méthode de travail
L’ordre compte : l’architecte choisit d’abord les viewpoints, puis construit les views correspondantes. Comme un architecte du bâtiment produit plans d’étage, élévations et schémas électriques pour des publics différents, l’architecte d’entreprise produit des views business, systèmes d’information et technologie pour ceux que ces aspects concernent.
Le système vit dans un environnement qui détermine les influences qu’il subit : techniques, métier, opérationnelles, organisationnelles, politiques, économiques, légales, réglementaires, écologiques, sociales. Un Model Kind fixe les conventions d’un type de modélisation.
Où cela apparaît dans les livrables
Les livrables clés intègrent cette chaîne. L’Architecture Vision décrit le problème à partir des stakeholders et de leurs concerns. Le Architecture Definition Document comporte, pour chaque domaine, des views correspondant aux viewpoints retenus et répondant aux concerns clés. Le Communications Plan regroupe les stakeholders selon leurs besoins d’information. Lorsqu’un public trouve un livrable inadapté, la bonne réponse est de produire une view issue d’un viewpoint adapté à ses concerns, pas de modifier l’architecture. Le même modèle peut ainsi nourrir plusieurs views, chacune ciblant un public différent.
LES MOTS À CONNAÎTRE
Le vocabulaire, avec du sens.
- Concern
- Domaine d’intérêt d’un ou plusieurs stakeholders envers un système, racine des requirements.
- Architecture viewpoint
- Perspective qui fixe comment construire et utiliser une view, avec quelles techniques et pourquoi.
- Architecture view
- Représentation d’un système selon un ensemble de concerns, faite de parties de modèles.
- Environnement
- Contexte qui détermine l’ensemble des influences s’exerçant sur un système.
- Model Kind
- Ensemble de conventions propres à un type de modélisation.