Le document d'architecture logicielle fournit une présentation exhaustive de l'architecture du système, à l'aide d'un certain nombre de vues d'architecture décrivant différents aspects du système.  
Rôle :  Architecte logiciel 
Caractère facultatif/Occurrence:  Développé essentiellement lors de la phase d'élaboration.
Canevas et rapports: 
Exemples : 
     
Représentation UML :  Ensemble de vues d'architecture pertinentes : cas d'utilisation, logique, processus, déploiement, implémentation, données.
Informations supplémentaires :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

Le document d'architecture logicielle fournit un aperçu complet de l'architecture du système logiciel. Il sert de moyen de communication entre l'architecte logiciel et d'autres membres de l'équipe de projet concernant les décisions d'architecture significatives prises pour le projet.

Calendrier Haut de la page

La représentation et les objectifs de l'architecture logicielle doivent généralement être définis avant les toutes premières itérations, puis entretenus tout au long du projet. Ces principes de représentation de l'architecture sont documentés dans les versions initiales du document d'architecture logicielle.

Le document d'architecture logicielle est principalement développé lors de la phase d'élaboration, dans la mesure où l'un des objets de cette phase est d'instaurer une fondation architecturale solide .

La vue des cas d'utilisation dans ce document sera probablement examinée en premier lieu dans la mesure où ces cas pilotent le développement et constituent une entrée indispensable à la planification des itérations. Pour les systèmes caractérisés par un degré élevé d'accès concurrent et de distribution, les vues de processus et de déploiement seront sans doute aussi examinées rapidement vu qu'elle peuvent avoir un impact substantiel sur le système tout entier.

Responsabilité Haut de la page

Un architecte logiciel est responsable de la génération du Document d'architecture logicielle, qui récapitule les décisions de conception les plus importantes sous des vues d'architecture multiples.

L'architecte logiciel définit la structure globale de chaque vue d'architecture : la décomposition de la vue, le regroupement des éléments et les interfaces entre ces principaux regroupements. Par conséquent, à la différence des autres rôles, la vue de l'architecte logiciel se présente en largeur et non pas en profondeur.

L'architecte logiciel est également responsable du maintien de l'intégrité architecturale du système tout au long du processus de développement en :

  • Approuvant toutes les modifications des éléments significatifs sur le plan de l'architecture (tels que les interfaces principales) décrits dans le document d'architecture logicielle.
  • Participant aux décisions du "comité de contrôle des changements" sur la résolution des problèmes affectant l'architecture du logiciel.

Personnalisation Haut de la page

Vous devez adapter la structure du document d'architecture logicielle à la nature de votre logiciel :

  • Certaines vues d'architecture peuvent ne pas être pertinentes :
    • La vue Déploiement n'est pas requise pour les systèmes comportant une seule unité centrale.
    • La vue Processus n'est pas requise si le système utilise un seul fil de contrôle.
    • La vue Données n'est requise que si la persistance d'objets constitue un aspect significatif du système et que son mécanisme nécessite un mappage entre objets persistants et non persistants.
  • Certains aspects spécifiques du logiciel peuvent requérir leur propre section (par exemple, ceux concernant la gestion des données ou les questions d'utilisabilité).
  • Vous pourrez avoir besoin d'annexes supplémentaires afin d'expliquer divers aspects, comme la justification de certains choix critiques et de l'élimination de solutions, ou pour définir des acronymes et des abréviations, ou encore pour présenter des principes généraux de la conception.
  • L'ordre des diverses sections peut varier en fonction des parties prenantes du système et de leurs centres de préoccupation et d'intérêt.

Avantages et désavantages de chaque vue d'architecture :

Vue des cas d'utilisation

Cette vue est obligatoire.

Vue logique

Cette vue est obligatoire.

Vue de processus

Cette vue est facultative. Ne l'utilisez que si le système exploite plusieurs fils de contrôle et que les divers fils sont en interaction ou dépendent les uns des autres .

Vue de déploiement

Cette vue est facultative. Ne l'utilisez que si le système est réparti entre plusieurs noeuds. Même dans ce cas, cette vue n'est justifiée que si cette répartition entraîne des implications sur l'architecture. Par exemple, en présence d'un serveur unique avec plusieurs clients, la vue de déploiement n'est requise que pour dépeindre les responsabilités du serveur et des clients en tant que classe de noeuds. Il est superflu de présenter chaque noeud client s'ils ont les mêmes capacités.

Vue d'implémentation

Cette vue est facultative. Ne l'utilisez que dans les cas où l'implémentation ne découle pas directement de la conception, c'est-à-dire lorsque la répartition des responsabilités entre les packages correspondants est différente entre les modèles de conception et d'implémentation. Si leur package est identique, cette vue peut être omise.

Vue de données

Cette vue est facultative. Ne l'utilisez que si la persistance représente un aspect significatif du système et que la conversion du modèle de conception en modèle de données n'est pas effectuée automatiquement par le mécanisme de persistance.



RUP (Rational Unified Process)   2003.06.15