Instructions: Modèle de conception
Ces instructions expliquent comment obtenir les modèle de conception à partir du modèle d'analyse
Relations
Eléments connexes
Description principale

Identification des éléments de conception depuis les classes d'analyse Début de page

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.

Mappage au modèle d'analyse Début de page

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. 

Diagramme indiquant la dépendance de trace

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.

Mappage au modèle d'implémentation

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.

Caractéristiques d'un bon 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.