Artefact :
|
![]() |
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 : | ||
|
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.
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.
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 :
Vous devez adapter la structure du document d'architecture logicielle à la nature de votre logiciel :
Avantages et désavantages de chaque vue d'architecture :
Cette vue est obligatoire.
Cette vue est obligatoire.
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 .
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.
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.
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)
|