Principes et conseils : Modèle de conception
Rubriques
Identification des éléments de conception des classes d'analyse
Application au modèle d'analyse
Mappage au modèle d'implémentation
Caractéristiques d'un bon modèle de conception
Les Artefact : 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 ou plusieurs éléments du modèle de conception. De plus, un seul élément de conception peut remplir des rôles multiples. Les observations suivantes décrivent les manières dont les rôles d'analyse peuvent être remplis :
- Une classe d'analyse peut devenir une seule classe de conception du modèle de conception.
- Une classe d'analyse peut devenir une partie d'une classe de conception du modèle de conception.
- Une classe d'analyse peut devenir une classe de conception d'agrégation du modèle de conception.
(signifiant que les parties de l'agrégation peuvent ne pas être modélisées de manière explicite comme les classes d'analyse.)
- Une classe d'analyse peut devenir un groupe de classes de conception, héritant de la même classe du modèle de conception.
- Une classe d'analyse peut devenir un groupe de classes de conception reliées fonctionnellement, appartenant au même modèle de conception.
- Une classe d'analyse peut devenir un sous-système de conception du modèle de conception.
- Une classe d'analyse peut devenir une partie d'un sous-système de conception, par exemple une plusieurs interfaces et l'implémentation leur correspondant.
- Une classe d'analyse peut devenir une relation du modèle de conception.
- Une relation entre les classes d'analyse peut devenir une classe de conception du modèle de conception.
- Les classes d'analyse traitent principalement des conditions fonctionnelles et des objets du modèle issus du domaine "problème" ; les classes de conception traitent des conditions non-fonctionnelles et des objets du modèle issus du domaine "solution".
- Les classes d'analyse peuvent être utilisées pour représenter "les objets que nous voulons que le système supporte," sans prendre de décision concernant la quantité d'objets susceptibles d'être supportés avec du matériel et la quantité supportée avec du logiciel. Ainsi, une partie de la classe d'analyse peut être réalisée par le matériel ; elle n'est pas modélisée dans le modèle de conception.
N'importe quelle combinaison peut être réalisée à partir des éléments cités ci-dessus.
Si un modèle d'analyse séparé est maintenu, assurez-vous de maintenir sa traçabilité à partir de l'élément de conception identifié jusqu'aux classes d'analyse auxquelles il correspond.
Pour plus d'informations, voir Mappage au modèle d'analyse.
Cette section s'applique, si un modèle d'analyse séparé est maintenu.
Durant la conception, des éléments de conception sont identifiés comme supportant un meilleur alignement par rapport à l'architecture et aux technologies sélectionnées. Toutes les classes d'analyse du modèle d'analyse doivent être associées avec au moins une classe de conception du modèle de conception.
Pour modéliser cette traçabilité, il faut définir une dépendance de <<trace>> de l'élément de conception jusqu'à(aux) classe(s) d'analyse qu'il représente, tel que cela est illustré dans le diagramme suivant :

Remarque : les liens de traçabilité sont définis des éléments du modèle de conception vers les éléments du modèle d'analyse, de manière que le modèle de conception soit dépendant du modèle d'analyse et pas l'inverse.
Vous devez décider, avant que la conception ne débute, la manière dont les classes du modèle de conception vont être rattachées aux classes d'implémentation ; cela doit être décrit dans des principes et conseils de conception, spécifiques au projet.
Le modèle de conception peut être plus ou moins proche du modèle d'implémentation, suivant la manière de faire correspondre ses classes, ses packages et ses sous-systèmes avec les classes d'implémentation, fichiers, packages et sous-systèmes du modèle d'implémentation. Durant l'implémentation,
vous serez souvent amené à traiter de petits problèmes tactiques liés à l'environnement d'implémentation, qui ne doivent pas avoir d'impact sur le modèle de conception. Par exemple, vous pouvez ajouter des classes et des sous-systèmes durant l'implémentation, pour traiter le développement réalisé en parallèle ou pour ajuster les dépendances d'importation. Pour plus d'informations, voir Activité :
Structurer le modèle d'implémentation et Concepts :
Mappage de la conception au code.
Le modèle de conception doit être mappé de manière cohérente au modèle d'implémentation. L' Artefact : Principes et conseils spécifiques au projet doit définir ce mappage, et un niveau cohérent d'abstraction doit être appliqué dans tout le modèle de conception.
Un bon modèle de conception présente les caractéristiques suivantes :
- Il répond aux exigences du système.
- Il résiste aux modifications de l'environnement d'implémentation.
- Il est facile à maintenir par rapport aux autres modèles d'objets éventuels et par rapport à l'implémentation du système.
- Son implémentation est facile.
- Il n'inclut pas les informations qui sont mieux documentées dans le code du programme.
- Il s'adapte facilement aux changements d'exigences.
Concernant les caractéristiques spécifiques, voir Points de contrôle :
Modèle de conception.
|