Objet
  • Définir une architecture potentielle destinée au système sur la base de l'expérience acquise sur des systèmes similaires ou dans des domaines de problèmes similaires.
  • Définir les schémas architecturaux, les principaux mécanismes et les conventions de modélisation pour le système.
Rôle :  Architecte logiciel 
Fréquence :  a lieu de façon facultative au cours de la création. Doit survenir au cours de la première itération. Cette activité peut avoir lieu lors d'itérations ultérieures si des modifications ou des ajouts importants doivent être envisagés dans l'architecture du logiciel.

Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   
Plus d'informations : 

Détails sur l'enchaînement d'activités :   

L'analyse architecturale définit une architecture potentielle et détermine les techniques architecturales à utiliser dans le système. Elle s'appuie sur l'expérience de systèmes ou de domaines de problèmes similaires et s'attache à ne pas gaspiller l'effort dans une architecture déjà définie. Dans les systèmes qui possèdent déjà une architecture bien définie, l'analyse architecturale peut être omise. Cette analyse est particulièrement adaptée au développement de nouveaux systèmes sans précédent.

Développer une présentation générale de l'architecture Haut de la page

Objet  Faciliter la présentation du système en explorant et en évaluant les options architecturales générales. 
Favoriser une compréhension rapide de la structure générale du système de la part du sponsor, des équipes de développement et des 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 au moment de la phase de création. Elle reflète les premières décisions et hypothèses sur la mise en oeuvre de la vision, ainsi que les décisions prises au niveau de l'architecture physique et logique et des exigences non fonctionnelles du système. Elle est élaborée par l'architecte du logiciel, souvent en collaboration avec le sponsor du projet, et prend la forme d'un storyboard informel ou d'un graphique. Sur un plan conceptuel, elle illustre la nature de la solution proposée, présente les idées clés et les thèmes majeurs. La vue d'ensemble de l'architecture est plus ou moins formelle en fonction des projets. Par exemple, dans un projet d'envergure et très formel, il peut être 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 est une ébauche provisoire. Ne prenez pas d'engagements sur la base du diagramme de la vue d'ensemble de l'architecture tant qu'un prototype architectural exécutable n'a pas validé l'architecture (y compris la conception, l'implémentation et le déploiement).

L'architecture doit prendre appui sur une architecture de référence, sur d'autres schémas architecturaux, ou encore sur d'autres ressources architecturales.

Déterminez si vous souhaitez affiner et gérer le diagramme de vue d'ensemble de l'architecture pour qu'il serve de vecteur de communication.

De nombreux systèmes doivent être développés et déployés au sein d'un environnement existant composé d'éléments matériels et logiciels : dans ce cas, l'architecte du logiciel rassemble les informations relatives à l'environnement actuel.

Par exemple, au cours d'un développement sur un système de commerce électronique, les informations suivantes sont pertinentes :

  • conception logique et physique du réseau existant
  • conception de la base de données et des bases de données existantes
  • environnement Web existant (serveurs, pare-feu, etc)
  • environnement serveur existant (configuration, versions de logiciels, mises à niveau planifiées)
  • normes existantes (réseau, affectation de noms, protocoles, etc)

Ces informations peuvent être enregistrées sous forme de texte, ou encore dans un modèle de déploiement.

Décrire les ressources disponibles Haut de la page

Objet  Identifier les ressources susceptibles d'être adaptées au projet.
Analyser les écarts entre les ressources et les exigences du projet.
Déterminer si les zones du système doivent prendre comme base les ressources.
Rechercher et répertorier les ressources potentiellement réutilisables dans le cadre du projet.
Effectuer une évaluation préliminaire pour vérifier que le support requis est potentiellement disponible.

Vous devez bien comprendre les exigences de l'environnement pour lequel les ressources sont décrites, ainsi que l'étendue et les fonctionnalités générales requises. Effectuez une recherche dans les bases de ressources de l'organisation et dans les documentations disponibles pour identifier les ressources ou les projets similaires. Il existe plusieurs types de ressources à prendre en compte, tels que les modèles de l'industrie, les cadres, les classes et l'expérience (cette liste n'est pas exhaustive). Vous devez évaluer si les ressources disponibles contribuent à relever les principaux défis du projet en cours et si elles sont compatibles avec les contraintes du projet.

Vous analyserez sans doute le niveau d'adéquation entre les ressources et les exigences des clients, en examinant si les exigences sont négociables (afin de permettre l'utilisation de la ressource).

Veillez à vérifier si la ressource peut être modifiée ou étendue pour satisfaire les exigences, et à évaluer l'arbitrage entre le coût, le risque et les fonctionnalités.

Enfin, vous déterminerez si vous souhaitez ou non utiliser une ou plusieurs ressources et vous justifierez cette décision.

Définir l'organisation générale des sous-systèmes Haut de la page

Objet Créer une structure initiale pour le modèle de conception.

Lorsque l'objectif consiste à élaborer une synthèse architecturale pendant la phase de création, cette étape est exclue de cette activité.

Normalement, le modèle de conception est organisé en couches (schéma architectural applicable aux systèmes de taille moyenne et élevée). Le nombre de couches n'est pas fixe, mais varie en fonction des situations.

Au cours de l'analyse architecturale, vous tenez généralement compte des deux couches supérieures : les couches d'application et métier. C'est ce que signifie l'organisation des sous-systèmes. Les autres couches de niveau inférieur sont décrites dans l'activité d'incorporation des éléments de conception existants. Si vous utilisez des schémas architecturaux spécifiques, les sous-systèmes sont définis autour du schéma architectural correspondant.

Pour plus d'informations sur les couches, voir Principes et conseils : organisation en couches.

Identifier les abstractions importantes Haut de la page

Objet Se préparer à l'analyse via l'identification des abstractions importantes (représentation des concepts identifiés pendant les activités liées aux exigences) que le système doit gérer.

Lorsque vous effectuez la synthèse architecturale, cette étape est réalisée à hauteur de la sélection de ressources (guidée par l'architecte du logiciel) pour la construction de l'artefact de concept architectural et du support de scénarios d'utilisation représentatifs.

Les activités d'exigences permettent généralement de découvrir des concepts clés que le système doit être capable de gérer ; ces concepts se manifestent comme des abstractions de conception. En raison du travail déjà effectué, il est inutile de répéter l'identification pendant l'activité d'analyse de cas d'utilisation.

Vous pouvez identifier les classes d'analyse d'entités préliminaires qui représenteront ces abstractions clés sur la base d'une connaissance générale du système (en utilisant les Exigences, le Glossaire, et, en particulier, le modèle de domaine, le cas échéant.

Lorsque vous définissez les abstractions clés, définissez également les relations existant entre les classes d'entités. Présentez les abstractions clés sous forme d'un ou de plusieurs diagrammes et créez pour chacun une brève description. En fonction du domaine et de la nouveauté du système, il peut exister des schémas d'analyse chargés d'enregistrer un grand nombre des abstractions clés requises pour la modélisation du système. Utilisez ces patterns (déjà utilisés avec succès dans le domaine) pour faciliter la tâche d'identification des importants concepts à représenter. [FOW97a] présente certains schémas d'analyse utiles pour la modélisation de systèmes métier, et applicables également à d'autres contextes.Un autre exemple est illustré par les groupes de gestion d'objets, qui tentent également de définir des interfaces et des protocoles pour de nombreux domaines, via le travail du comité de technologie des domaines et des équipes associées. Inévitablement, ce travail conduit à identifier d'importantes abstractions dans le domaine.

Les classes d'analyse identifiées ici seront probablement modifiées et évolueront pendant le projet. L'objectif de cette étape n'est pas d'identifier un ensemble de classes qui survivra tout au long de la conception, mais d'identifier les concepts clés que le système doit gérer. Ne passez pas trop de temps à détailler les classes d'entité lors de cette étape initiale, car vous risquez d'identifier des classes et des relations qui ne sont pas réellement requises par les cas d'utilisation. Souvenez-vous que vous trouverez davantage de classes d'entités et de relations lorsque vous examinerez les cas d'utilisation.

Identifier les interactions stéréotypées Haut de la page

Cette étape n'est incluse que si vous effectuez une analyse architecturale (cette activité) comme faisant partie du détail de l'enchaînement d'activités de synthèse architecturale au cours de la phase de 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évelopper une présentation générale de l'architecture Haut de la page

Objet

Fournir une base d'évaluation de la viabilité de l'implémentation du système.
Bien comprendre la répartition géographique et la complexité opérationnelle du système.
Constituer une base pour les efforts de départ et les estimations de coûts.

Développez une présentation générale du logiciel sous l'angle de son déploiement. Par exemple, déterminez si le système doit utiliser l'accès à distance, ou si ses exigences vont dans le sens d'une distribution sur plusieurs noeuds. Voici certaines des sources d'informations à prendre en compte :

  • utilisateurs définis dans les profils utilisateur (dans la Vision) et cas d'utilisation (dans le modèle de cas d'utilisation)
  • exigences de services (dans les spécifications supplémentaires)
  • contraintes (dans les spécifications supplémentaires, telles que les exigences d'interface avec les systèmes hérités)

Si un système distribué complexe est requis, un modèle de déploiement peut être utilisé pour l'enregistrement des relations entre les noeuds. Cela doit inclure l'affectation de composants et de données aux noeuds et l'indication de la méthode d'accès aux composants d'accès aux données. La spécification détaillée des noeuds et des connexions est différée, à l'exception des cas où cela serait important dans le cadre de l'estimation de la viabilité. Vous pouvez utiliser des ressources existantes si elles sont appropriées. Bien qu'il s'agisse du premier modèle de déploiement créé dans le projet, et qu'il soit généré rapidement et à un niveau élevé, il est susceptible d'identifier des produits matériels et logiciels s'ils sont connus, ou s'il est important de prendre ces décisions de sélection à ce stade.

Validez que le modèle de déploiement apporte un support aux utilisateurs (tout particulièrement à ceux qui se trouvent sur des sites distants si cela est nécessaire) via l'élaboration des cas d'utilisation classiques et la satisfaction d'exigences et de contraintes non fonctionnelles. Validez que les noeuds et les connexions sont adaptés aux interactions entre les composants sur différents noeuds, ainsi qu'entre les composants et leurs données stockées.

Identifier les mécanismes d'analyse Haut de la page

Objet Définir les mécanismes et les services d'analyse utilisés par les concepteurs pour donner "vie" à leurs objets.

Lorsque l'objectif consiste à élaborer une synthèse architecturale pendant la phase de création, cette étape est exclue de cette activité.

Les mécanismes d'analyse peuvent être identifiés du haut vers le bas (connaissance a priori) ou du bas vers le haut (découverte au fur et à mesure). Pour le mode du haut vers le bas, l'expérience guide l'architecte du logiciel à savoir que certains problèmes sont présents dans le domaine et nécessitent certains types de solutions. Voici des exemples de problèmes architecturaux courants pouvant être exprimés sous la forme de mécanismes pendant l'analyse : persistance, gestion des transactions, gestion des anomalies, messages et moteurs d'inférence. Ils ont en commun une capacité générale de large classe de systèmes, et chacun d'entre eux offre des fonctionnalités qui interagissent avec les fonctionnalités de base des applications ou qui offrent un support. Les mécanismes d'analyse offrent un support des capacités requises par le système, quelle que soit la plate-forme ou le langage d'implémentation. Ces mécanismes peuvent également être conçus et implémentés selon différentes méthodes. En règle générale, plusieurs mécanismes de conception correspondent à chaque mécanisme d'analyse, et plusieurs méthodes d'implémentation peuvent être utilisées pour chaque mécanisme de conception.

L'approche du bas vers le haut est la source des mécanismes d'analyse (ils sont créés lorsque l'architecte du logiciel voit émerger un thème commun à partir d'un ensemble de solutions à différents problèmes). Il est nécessaire de trouver un moyen de synchroniser les éléments des différentes unités d'exécution et d'harmoniser l'allocation des ressources. Les mécanismes d'analyse, qui simplifient le langage d'analyse, sont issus de ces schémas.

L'identification d'un mécanisme d'analyse signifie que vous identifiez un sous-problème implicite et que vous le nommez. Le nom peut initialement être le nom souhaité : par exemple, l'architecte du logiciel détecte que le système aura besoin d'un mécanisme de persistance. Ce mécanisme sera implémenté via la collaboration d'une société de classes (voir [BOO98]), dont certaines ne fournissent pas directement les fonctionnalités, mais ont pour but d'être un support. Il est très fréquent que ces classes soient situées au milieu ou sur des couches inférieures d'une architecture, ce qui offre un service de support commun à toutes les classes d'applications.

Si le sous-problème identifié est assez courant, un pattern existe peut-être permettant d'instancier le mécanisme via la liaison des classes existantes et l'implémentation de nouvelles classes selon les besoins du pattern. Le mécanisme d'analyse produit de cette façon est abstrait et nécessite d'être retravaillé via la conception et l'implémentation.

Pour plus d'informations, voir les concepts de mécanismes d'analyse.

Revoir les résultats Haut de la page

Objet S'assurer que les résultats de l'analyse architecturale sont complets et cohérents.

A la fin de l'analyse architecturale, revoyez les mécanismes architecturaux, les sous-systèmes, les packages et les classes identifiés pour vous assurer qu'ils sont complets et cohérents. Les résultats de cette activité étant provisoires et relativement informels, les revues doivent également être informelles. Vous pouvez utiliser des scénarios ou des cas d'utilisation pour valider les choix architecturaux effectués à plusieurs niveaux (du niveau métier au niveau des interactions spécifiques).

Pour plus d'informations sur l'évaluation des résultats de cette activité, voir les points de contrôle sur le document d'architecture logicielle et sur l'analyse logicielle.



RUP (Rational Unified Process)   2003.06.15