Représentation UML : Ensemble de vues d'architecture appropriées : cas d'utilisation, logique, processus, déploiement,
implémentation, données.
Vous devez ajuster la structure du plan du document d'architecture logicielle en fonction de la nature de votre
projet :
-
Certaines vues d'architecture peuvent s'avérer inutiles :
-
La vue de déploiement n'est pas nécessaire pour les systèmes à processeur unique.
-
La vue de processus n'est pas nécessaire si le système n'utilise qu'une seule unité d'exécution de
contrôle.
-
La vue de données n'est pas nécessaire sauf si la persistance des objets est un aspect important du système
et si le mécanisme de persistance nécessite un mappage entre les objets persistants et
non-persistants.
-
Certains aspects spécifiques du logiciel peuvent nécessite une section dédiée, par exemple les aspects liés à la
gestion des données ou aux questions de convivialité.
-
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 certaines solutions, ou pour définir des acronymes et des
abréviations, ou encore pour présenter des principes de conception généraux.
-
L'ordre des différentes sections peut varier en fonction des parties prenantes concernées par le système et de
leurs centres d'intérêt.
Les avantages et inconvénients de chaque vue d'architecture sont présentés ci-dessous :
Vue de cas d'utilisation
Cette vue est obligatoire.
Vue logique
Cette vue est obligatoire.
Vue de processus
Cette vue est facultative. Utilisez cette vue uniquement si le système a plusieurs unités d'exécution de
commande et si celles-ci interagissent ou sont interdépendantes.
Vue de déploiement
Cette vue est facultative. Utilisez cette vue uniquement si le système est réparti sur plusieurs noeuds.
Même dans ce cas, la vue de déploiement se justifie uniquement si cette répartition a des implications sur
l'architecture. Par exemple, si vous avez un seul serveur avec beaucoup de clients, la vue de déploiement se
contentera de décrire les responsabilités du serveur et des clients en tant que classe de noeuds : inutile de
passer en revue chaque noeud client s'ils ont tous les mêmes caractéristiques.
Vue d'implémentation
Cette vue est facultative. Utilisez cette vue uniquement si l'implémentation ne découle pas exactement de la
conception, c'est-à-dire si la répartition des responsabilités des packages n'est pas strictement identique dans le
modèle de conception et dans le modèle d'implémentation. En revanche, si la répartition en packages est identique
dans le modèle de conception et dans le modèle d'implémentation, cette vue peut être omise.
Vue de données
Cette vue est facultative. Utilisez cette vue uniquement si la persistance est un aspect important du
système et si la transposition du modèle de conception vers le modèle de données n'est pas effectuée
automatiquement par le mécanisme de persistance.
|