Développement de la vue d'ensemble de l'architecture
Objet
|
Mieux se représenter le système en explorant et évaluant les options générales de
l'architecture.
Communiquer une vue d'ensemble de la structure du système prévu dès les premières phases, au sponsor, aux
équipes de développement et aux autres parties prenantes.
|
La vue d'ensemble de l'architecture doit être développée très tôt dans le cycle de vie d'un projet, si possible pendant
la phase de création. Elle reflète les premières décisions et les hypothèses de travail sur l'implémentation de la
vision, ainsi que les décisions concernant l'architecture physique et logique et les exigences non fonctionnelles du
système. Produite par l'architecte du logiciel, souvent en collaboration avec le sponsor du projet, elle prend la forme
d'un graphique d'icônes ou d'un storyboard illustré informel et riche. Conceptuellement, elle illustre la nature
essentielle de la solution proposée, en transmettant les idées directrices et en incluant les principaux blocs de
construction. Le niveau de formalité de la vue d'ensemble de l'architecture dépend du projet. Par exemple, dans un
grand projet très formel, il peut s'avérer nécessaire d'enregistrer la vue d'ensemble de l'architecture dans les
sections appropriées du document d'architecture logicielle, afin qu'elle puisse faire l'objet d'une revue formelle.
A ce stade, la vue d'ensemble de l'architecture reste simplement une ébauche provisoire. Ne fondez pas d'engagement sur
le diagramme de vue d'ensemble de l'architecture tant qu'un prototype d'architecture exécutable n'a pas validé
l'architecture, y compris les aspects relatifs à la conception, à l'implémentation et au déploiement.
Envisagez de fonder votre architecture sur une architecture de référence, ou sur d'autres patterns d'architecture ou actifs architecturaux.
Evaluez la nécessité d'affiner et de maintenir le diagramme de vue d'ensemble de l'architecture, utilisé comme support
de communication.
De nombreux systèmes sont contraints d'être développés et déployés dans un environnement matériel et logiciel existant
; l'architecte du logiciel devra alors réunir les informations concernant l'environnement en cours.
Par exemple, lors du développement d'un système d'e-business, les informations suivantes s'avèrent pertinentes :
-
la conception physique et logique du réseau existant
-
les bases de données et conception des bases existantes
-
l'environnement Web existant (serveurs, pare-feu, etc.)
-
l'environnement de serveur existant (configuration, versions logicielles, mises à niveau planifiées)
-
les normes existantes (réseau, désignation, protocoles, etc.)
Ces informations peuvent être enregistrées sous forme de texte ou dans un Modèle
de déploiement.
|
Evaluation des actifs disponibles
Objet
|
Identifier les actifs potentiellement importantes pour le projet.
Analyser les correspondances et les décalages entre les actifs et les exigences du projet.
Décider de fonder ou non des zones du système sur des actifs.
Localiser et répertorier les actifs potentiellement réutilisables sur le projet.
Effectuer une évaluation préliminaire afin de s'assurer que la prise en charge nécessaire est
potentiellement disponible.
|
Vous devez comprendre les exigences de l'environnement dans lequel vous considérez les actifs, ainsi que la portée du
système et les fonctionnalités générales requises. Recherchez des actifs ou des projets semblables dans les bases
d'actifs de l'organisation et la littérature du secteur d'activité. Il existe plusieurs types d'actifs à considérer,
tels que (mais pas uniquement) des modèles, infrastructures préfabriquées, classes et expériences du secteur
d'activité. Vous devrez évaluer la contribution des actifs existants à la résolution des principaux défis du projet en
cours et leur compatibilité avec les limitations de ce projet.
Vous souhaiterez analyser le degré de correspondance entre les actifs et les exigences du client, en envisageant la
possibilité de négocier certaines de ces exigences (afin d'utiliser l'actif).
Assurez-vous d'évaluer la possibilité de modifier ou d'étendre un actif pour répondre aux exigences, ainsi que les
conséquences de l'adoption de cet actif en termes de coûts, risques et fonctionnalités.
Enfin, vous déciderez, en principe, de l'utilisation d'un ou de plusieurs actifs et fournirez les motivations de cette
décision.
|
Définition de l'organisation de haut niveau des sous-systèmes
Objet
|
Créer une structure initiale pour le modèle de conception.
|
Lorsque votre but est d'effectuer une synthèse architecturale pendant la phase de création, cette étape est exclue de
la tâche.
En principe, le modèle de conception est organisé en couches (un pattern d'architecture courant pour les systèmes de taille modérée à grande). Le
nombre de couches n'est pas fixe ; il varie d'une situation à l'autre.
Lors de l'analyse architecturale, vous vous concentrez habituellement sur deux couches de haut niveau : les couches
application et métier. Il s'agit de l'organisation de haut niveau des sous-systèmes. Les autres
couches de niveau inférieur sont abordées dans la Tâche
: intégration des éléments de conception existants. Si vous utilisez des patterns d'architecture spécifiques, les
sous-systèmes sont définis en fonction du modèle architectural pour ce pattern.
Pour plus d'informations sur l'organisation en couches, voir les Instructions relatives au
produit : organisation en couches.
|
Identification des abstractions clé
Objet
|
Se préparer à l'analyse en identifiant les abstractions clé que le système doit traiter (représentation de
concepts identifiés lors des tâches relatives aux exigences et des tâches de modélisation métier le cas
échéant).
|
Lorsque votre but est d'effectuer une synthèse architecturale, cette étape ne doit être effectuée que dans la mesure où
elle guide l'architecte du logiciel dans le choix des actifs pour l'élaboration du Produit : Bien-fondé de la conception architecturale et où elle prend
en charge les scénarios d'utilisation représentatifs.
Les tâches relatives aux exigences et, le cas échéant, les tâches de modélisation métier, révèlent habituellement les
concepts clé que le système doit pouvoir traiter ; ces concepts se manifestent sous forme d'abstractions de conception
clé. Ce travail d'identification ayant déjà été effectué, il n'est pas nécessaire de le répéter au cours de la Tâche : analyse du cas d'utilisation.
Vous pouvez profiter des connaissances existantes en identifiant les classes d'analyse d'entité préliminaires pour
représenter ces abstractions clé en fonction des connaissances générales du système telles que les exigences, le
glossaire et, en particulier, le modèle de domaine ou le modèle d'analyse métier, si vous en avez
un.
Lorsque vous définissez les abstractions clé, définissez également toutes les relations qui existent entre les classes
entité. Présentez ces abstractions dans un ou plusieurs diagrammes de classes, puis créez une brève description pour
chacun d'entre eux. Selon le domaine et la nouveauté du système, il se peut que certains patterns d'analyse enregistrant de nombreuses abstractions clé nécessaires à
la modélisation du système existent déjà. L'utilisation de tels patterns (dont vous devriez avoir déjà tiré parti dans
votre domaine) allégera considérablement la tâche d'identification des concepts clé à représenter. [FOW97a] présente quelques patterns d'analyse d'utilité immédiate pour la modélisation
des systèmes métier, mais également applicables dans d'autres contextes. Le groupe Object Management Group (OMG) tente
également de définir des interfaces et des protocoles pour de nombreux domaines, par le biais de son comité
technologique du domaine et des groupes de travaux associés. Inévitablement, ce travail conduit à l'identification
d'abstractions importantes dans le domaine.
Il se peut que les classes d'analyse identifiées à ce stade changent et évoluent au cours du projet. Le but de cette
étape n'est pas d'identifier un ensemble de classes qui subsisteront tout au long de la conception, mais des concepts
clé que le système doit traiter. Lors de cette étape initiale, ne passez pas trop de temps à décrire les classes entité
en détail. Vous risquez en effet d'identifier des classes et des relations qui se révéleront inutiles pour les cas
d'utilisation. Souvenez-vous que vous découvrirez plus de classes entité et de relations en abordant les cas
d'utilisation.
|
Identification des interactions stéréotypées
Cette étape est incluse uniquement si vous effectuez cette tâche à la création.
L'objectif de cette étape consiste à identifier les interactions entre les abstractions clés du système qui
caractérisent les principaux types d'activité présents dans le système. Ces interactions sont enregistrées sous forme
de réalisations de cas d'utilisation.
|
Développement de la vue d'ensemble du déploiement
Objet
|
Construire une base pour évaluer la viabilité de l'implémentation du système.
Comprendre la distribution géographique et la complexité du fonctionnement du système.
Construire une base pour les premières évaluations en termes de coût et d'effort.
|
Développez une vue d'ensemble des modalités de déploiement du logiciel. Par exemple, déterminez si le système requiert
un accès à distance ou si ses exigences entraînent une distribution sur plusieurs noeuds. Voici quelques sources
d'information à prendre en compte :
-
les utilisateurs (sur leur lieu de travail), définis dans les Profils utilisateurs (dans la Vision), et les cas
d'utilisation (dans le Modèle de cas d'utilisation)
-
l'organisation des données métier (dans le Modèle d'analyse métier et le Modèle de conception, selon la
disponibilité)
-
les exigences de niveau de service (dans les Spécifications supplémentaires)
-
les limitations (dans les Spécifications supplémentaires, telles que les exigences d'interface avec les systèmes en
vigueur)
Si un système distribué complexe est requis, vous pouvez utiliser un modèle de déploiement pour enregistrer la relation
entre les noeuds. Il s'agira d'attribuer provisoirement des composants et des données à des noeuds, et d'indiquer la
manière dont les utilisateurs accèdent aux composants qui accèdent aux données. La spécification détaillée des noeuds
et des connexions est différée, sauf lorsqu'elle est importante pour l'estimation et l'évaluation de la viabilité. Vous
pouvez utiliser des actifs existants si les actifs adéquats sont disponibles. Bien qu'il s'agisse du premier modèle de
déploiement dans le projet, effectué rapidement et dans les grandes lignes, il peut identifier les produits matériels
et logiciels réels s'ils sont connus, ou s'il est important de prendre ces décisions à ce stade.
Assurez-vous que le modèle de déploiement prend en charge les utilisateurs qui exécutent des cas d'utilisation courants
(en particulier sur des sites distants, le cas échéant), et répond aux exigences et limitations non fonctionnelles.
Validez la prise en charge, par les noeuds et les connexions, des interactions entre les composants sur différents
noeuds, ainsi qu'entre les composants et leurs données stockées.
|
Identification des mécanismes d'analyse
Objet
|
Définir les mécanismes et services d'analyse utilisés par les concepteurs pour donner "vie" à leurs objets.
|
Lorsque votre but est d'effectuer une synthèse architecturale pendant la phase de création, cette étape est exclue de
la tâche.
Les mécanismes d'analyse peuvent être identifiés de manière descendante (connaissance a priori) ou ascendante
(découverte au fur et à mesure). En mode descendant, l'expérience guide l'architecte du logiciel et lui permet de
connaître l'existence, dans le domaine, de certains problèmes qui exigeront certains types de solutions. Ces exemples
de problèmes d'architecture courants sont susceptibles d'être exprimés sous forme de mécanismes lors de l'analyse :
persistance, gestion des transactions, gestion des pannes, messagerie et moteurs d'inférence. Leur point commun est
qu'ils constituent tous une capacité générale d'une large classe de systèmes, et offrent une fonctionnalité qui
interagit avec ou prend en charge la fonctionnalité de base de l'application. Les mécanismes d'analyse prennent en
charge les capacités requises par les exigences fonctionnelles de base du système, indépendamment de la plateforme de
déploiement ou du langage d'implémentation. Ils peuvent également être conçus et implémentés de plusieurs manières
différentes. Généralement, chaque mécanisme d'analyse correspondra à plus d'un mécanisme de conception, voire à plus
d'un mode d'implémentation de chaque mécanisme de conception.
Dans l'approche ascendante, les mécanismes d'analyse apparaissent en dernier - ils sont créés à mesure que l'architecte
du logiciel entrevoit, d'abord légèrement peut-être, un thème commun émerger d'un ensemble de solutions à divers
problèmes. Il est nécessaire d'harmoniser les modes d'allocation des actifs et de permettre aux éléments de différentes
unités d'exécution de synchroniser leurs horloges. Les mécanismes d'analyse, qui simplifient le langage de l'analyse,
émergent de ces patterns.
Identifier un mécanisme d'analyse signifie identifier l'existence d'un sous-problème commun, peut-être implicite
(impliqué par les exigences du système), et le nommer. Initialement, le nom peut être le seul élément existant. Par
exemple, l'architecte du logiciel reconnaît que le système nécessitera un mécanisme de persistance. En
dernier ressort, ce mécanisme sera implémenté par le biais de la collaboration d'une société de classes (voir
[BOO98]), dont certaines n'offrent pas directement une fonctionnalité de
l'application, mais existent dans le seul but de la prendre en charge. Ces "classes support" se trouvent très souvent
dans les couches intermédiaires et inférieures de l'architecture, offrant ainsi un service de support commun à toutes
les classes des niveaux de l'application.
Si le sous-problème identifié est assez général, il existe peut-être un pattern à partir
desquels le mécanisme peut être instancié, en reliant les classes existantes et en en implémentant de nouvelles classes
comme requis par le pattern. Un tel mécanisme d'analyse sera abstrait et devra être affiné tout au long de la
conception et de l'implémentation.
Pour plus d'informations, voir les Instructions :
mécanismes d'analyse.
|
Revue des résultats
Objet
|
S'assurer que les résultats de l'analyse architecturale sont complets et cohérents.
|
Au terme de l'analyse architecturale, révisez les mécanismes d'architecture, les sous-systèmes, les packages et les
classes identifiés afin de vous assurer qu'ils sont complets et cohérents. Les résultats de l'analyse architecturale
étant provisoires et relativement informels, les revues doivent également être informelles. Vous pouvez utiliser les
scénarios ou cas d'utilisation pour valider les choix architecturaux effectués sur plusieurs niveaux, de la perspective
métier aux interactions spécifiques.
Pour plus d'informations sur l'évaluation des résultats de cette tâche, voir la Liste de contrôle : document d'architecture logicielle - considérations relatives à
l'analyse architecturale.
|
|