Produit : les classes d'analyse représentent les rôles joués par les
instances des éléments de conception ; ces rôles peuvent être remplis par un élément de conception ou plus. De plus, un
seul élément de conception peut remplir plusieurs rôles. Les observations suivantes portent sur les différentes façons
dont les rôles d'analyse peuvent être remplis :
-
Une classe d'analyse peut devenir une seule classe de conception dans le modèle de conception.
-
Une classe d'analyse peut devenir une partie d'une classe de conception dans le modèle de conception.
-
Une classe d'analyse peut devenir une classe de conception agrégée dans le modèle de conception. (Cela signifie que
les parties de cet agrégat ne seront pas forcément modélisées comme des classes d'analyse.)
-
Une classe d'analyse peut devenir un groupe de classes de conception qui hérite de la même classe dans le modèle de
conception.
-
Une classe d'analyse peut devenir un groupe de classes de conception ayant des fonctionnements liés dans le modèle
de conception.
-
Une classe d'analyse peut devenir un sous-système de conception dans le modèle de conception.
-
Une classe d'analyse peut faire partie d'un sous-système de conception, comme une interface ou plus et leur
implémentation correspondante.
-
Une classe d'analyse peut devenir une relation dans le modèle de conception.
-
Une relation entre des classes d'analyse peut devenir une classe de conception dans le modèle de conception.
-
Les classes d'analyse traitent principalement les exigences fonctionnelles et les objets de modèle du domaine
"problématique". Les classes de conception traitent les exigences non fonctionnelles et les objets de modèle du
domaine "de solution".
-
Les classes d'analyse peuvent être utilisées pour représenter "les objets que le système doit prendre en charge,"
sans décider quelle partie doit être pris en charge par le matériel et par le logiciel. Une partie de la classe
d'analyse peut être réalisée par le matériel et ne pas du tout être modélisée dans le modèle de conception.
Toutes les combinaisons ci-dessus sont alors possibles.
Si vous conservez un modèle d'analyse séparé, assurez-vous de maintenir la traçabilité entre l'élément de conception
identifié et les classes d'analyse auxquelles il correspond. Pour plus d'informations, voir Mappage au modèle d'analyse.
Cette section ne concerne que les cas où un modèle d'analyse séparé est conservé.
Pendant la conception, les éléments de conception sont identifiés ce qui permet une meilleure adéquation avec
l'architecture et les technologies choisies. Chaque classe d'analyse du modèle d'analyse doit être associée avec
au moins une des classes de conception du modèle de conception.
Pour modéliser cette traçabilité, une dépendance de <<trace>> doit être créée entre le modèle de conception
et la ou les classes d'analyse qu'il représente, comme l'indique le digramme suivant.
Remarque : les liens de traçabilité vont des éléments du modèle de conception aux éléments du modèle
d'analyse. De cette manière, c'est le modèle de conception qui dépend du modèle d'analyse et pas l'inverse.
Vous devez décider, avant le début de la conception, la façon dont les classes du modèle de conception seront liées aux
classes d'implémentation. Cela doit figurer dans les instructions de conception propres au projet.
Le modèle de conception peut être plus ou moins proche du modèle d'implémentation. Cela dépend de la façon dont vous
mappez ses classes, packages et sous-systèmes aux classes d'implémentation, fichiers, packages et sous-systèmes dans le
modèle d'implémentation. Pendant l'implémentation, vous rencontrerez souvent de légers problèmes liés à l'environnement
d'implémentation qui ne devraient pas avoir de conséquence sur le modèle de conception. Par exemple, on peut ajouter
des classes et des sous-systèmes pendant l'implémentation pour traiter un développement parallèle ou pour modifier la
dépendance à l'importation. Pour obtenir plus d'informations, référez-vous à Tâche : Construire le modèle d'implémentation et Technique : Mappage de la conception au code.
Le mappage du modèle de conception au modèle d'implémentation doit être cohérent. Les instructions Produit : Instructions relatives au projet doit définir ce mappage et
un niveau d'abstraction cohérent doit être appliqué au modèle de conception.
Un bon modèle
de conception a les caractéristiques suivantes :
-
Il répond aux exigences du système.
-
Il résiste aux changements de l'environnement d'implémentation.
-
Il est facile à entretenir vis à vis d'autres modèles d'objet éventuels et de l'implémentation du système.
-
Il est facile à implémenter.
-
Il ne contient pas d'informations mieux documentées dans le code du programme.
-
Il est facile à modifier en fonction des changements d'exigences.
Pour des caractéristiques spécifiques, voir Liste de contrôle
: modèle de conception.
|