Décrire l'architecture logicielle en se basant sur plusieurs vues d'un point de vue de différentes parties prenantes (par exemple utilisateur, développeur, chef de projet, ...)
Une vue est une description complète et simplifiée du système d'un point de vue bien défini
Intérêt
Compatible avec la notation UML
Démarche favorable à l'utilisation de diagrammes
Pragmatique : ne documenter que ce qui est utile
Assez facile à comprendre pour des "non techniques"
Vue logique
La vue la plus connue de l'architecture (Souvent réalisée hors du 4+1 vues)
Contenu
Une vue « désincarnée », abstraite de l'architecture
Peut suivre une découpe fonctionnelle
Peut suivre une découpe orientée objets
Format suggéré
Diagramme global
Diagrammes de classes
Diagramme de communication
Diagramme d'objets
Vue de processus
Exprimer la dynamicité du système
Contenu :
Décrire les interactions entre processus/threads/tâches
Expliciter les relations entre tâches (attentes, synchronisations), les allocations / dé-allocations, les exigences non fonctionnelles (concurrence, performance, ...)
Formats suggérés (tout diagramme susceptible d'exprimer la communication et les changements d'état) :
Diagrammes de communication / collaboration
Diagrammes états - transitions
Diagrammes d'activité
Vue d'implémentation
Organisation des modules logiciels sous forme de composants
Composants réutilisés ou à réaliser
Expression des relations entre ces composants (hiérarchie, contraintes, héritage, ...)
Contenu :
Vue logique « instanciée » (noms des composants ajoutés)
Informations de configuration (versions retenues, auteurs/sources, ...)
Formats suggérés :
Diagramme de composants
Diagramme de paquetages
Vue de déploiement
Exprimer comment est déployé le système (Contribue mais ne suffit pas à décrire l'installation)
Contenu :
Décrire la répartition spatiale
Enumérer les contraintes (Pare-feu, bande passante, ...)
Décrire la scalabilité et la tolérance aux pannes
Formats suggérés :
Diagrammes de déploiement
Diagrammes de composants (complétés avec la répartition spatiale et les contraintes)
Vue de cas d'utilisation
Cas normal : comment tout s'enchaine
Sélection d'un sous ensemble des cas d'utilisations définis dans les spécifications pour :
Décrire les interactions entre éléments du système (objets / composants / processus)
Illustrer et valider le design d'architecture
Attention de ne pas réécrire les spécifications du système
Cas « start-up avec cahier des charges sur la nappe »
L'architecture est le seul document qui sera écrit ... autant y ajouter les cas d'utilisations vitaux pour la réalisation
Formats suggérés :
Diagrammes de séquence
Diagramme de cas d'utilisation (et diagrammes attenants)
Aéropole de Charleroi-Gosselies
Avenue Jean Mermoz 28
B-6041 Charleroi - Belgique