Tâche: Analyse architecturale
Cette tâche consiste à définir une architecture candidate et à imposer des limitations aux techniques architecturales à utiliser dans le système.
Objet
  • Définir une architecture candidate pour le système, en fonction de l'expérience acquise dans des systèmes ou domaines semblables.
  • Définir les patterns d'architecture, les principaux mécanismes et les conventions de modélisation du système.
Relations
Description principale

L'analyse architecturale consiste à définir une architecture candidate et à imposer des limitations aux techniques architecturales à utiliser dans le système. Elle repose sur le regroupement des expériences acquises dans des systèmes ou domaines semblables concernant la limitation et le ciblage de l'architecture, afin d'épargner les efforts déployés dans la redécouverte architecturale. Dans les systèmes qui comportent déjà une architecture bien définie, l'analyse architecturale peut être omise. Elle est au contraire de première utilité lors du développement de systèmes nouveaux et sans précédent.

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



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations