Concepts : Mappage de la conception au code
Rubriques
La conception doit définir suffisamment d'aspects du système pour permettre de l'implémenter sans ambiguïté.
L'ampleur suffisante variera d'un projet à l'autre et d'une entreprise à l'autre.
Dans certains cas, la conception ressemble à un esquisse élaborée juste ce qu'il faut pour permettre à l'implémenteur de progresser (approche "esquisse et code").
Le niveau de spécification varie selon l'expertise de l'implémenteur, la complexité et le risque d'interprétation erronée de la conception.
Dans d'autres cas, la conception peut être élaborée au point de permettre sa transformation automatique en code. Ceci implique généralement des extensions au langage UML standard afin de représenter la sémantique spécifique au langage ou à l'environnement.
Cette conception peut aussi être hiérarchique, comme la suivante :
- Un modèle de conception de haut niveau qui brosse un tableau du système global.
- Un modèle de spécification de sous-système qui stipule avec précision les interfaces requises et le comportement des principaux sous-systèmes du système.
- Un modèle de conception détaillé pour les parties internes des sous-systèmes.
Le cas de développement doit définir comment est réalisé le modèle de conception dans le processus spécifique au projet et ses rapports éventuels avec d'autres modèles et avec l'implémentation. Ces informations doivent être recensées dans les Principes et conseils spécifiques au projet.
Les sections ci-dessous exposent différentes options pour rattacher la conception et l'implémentation et traitent des avantages et inconvénients de ces approches.
Une approche fréquente de la conception consiste à l'esquisser à un niveau relativement abstrait, puis à passer directement au code. La maintenance du modèle de conception est manuelle.
Sous cette approche, il est permis à une classe de conception de représenter une abstraction de plusieurs classes au niveau du code. Il est recommandé de mapper chaque classe de conception avec une classe "principale" qui, à son tour, puisse utiliser plusieurs classes "auxiliaires" afin de concrétiser son comportement. Vous pouvez employer des classes "auxiliaires" afin d'implémenter un attribut complexe ou de construire une structure de données requise pour l'implémentation d'une opération.
Dans la conception, vous n'avez pas à modéliser les classes "auxiliaires" mais seulement les attributs, relations et opérations clés définis par la classe principale.
Le but d'un tel modèle est de faire abstraction des détails pouvant être complétés par l'implémenteur.
Cette approche est élargie pour s'appliquer aux autres éléments du modèle de conception. Vous pouvez ainsi disposer d'interfaces de conception plus abstraites que celles au niveau du code, et ainsi de suite.
Dans les environnements d'ingénierie aller-retour, le niveau de détail du modèle de conception évolue jusqu'à devenir une représentation visuelle du code. Ce code et sa représentation sont synchronisés (à l'aide d'outils).
Ci-dessous figurent quelques options pour représenter un modèle de conception dans un contexte d'ingénierie aller-retour :
Modèle de conception de haut niveau et modèle de conception détaillé 
Sous cette approche, deux niveaux de modèle de conception sont maintenus. Chaque élément de conception de haut niveau constitue une abstraction d'un ou de plusieurs éléments plus détaillés du modèle aller-retour. Une classe de conception, par exemple, peut être mappée à une classe "principale" et à plusieurs classes "auxiliaires", tout comme dans l'approche "esquisse et code" décrite auparavant. La traçabilité des éléments du modèle de conception de haut niveau vers ceux du modèle aller-retour peut contribuer au maintien de la cohérence entre les deux modèles.
Bien que ceci puisse permettre de s'affranchir des détails moins importants, cet avantage doit être comparé à l'effort requis pour préserver la cohérence entre les modèles.
Modèle de conception unique évolutif
Sous cette approche, il existe un seul modèle de conception. Les esquisses initiales des éléments de conception évoluent jusqu'au point où elles peuvent être synchronisées avec le code. Des diagrammes (tels que ceux utilisés pour décrire les réalisations de cas d'utilisation de conception) référencent initialement les classes de conception esquissées, puis en fin de compte les classes spécifiques au langage.
Des descriptions de haut niveau de la conception sont maintenues comme requis, par exemple :
- Diagrammes de la structure logique du système.
- Spécifications de sous-système/composant.
- Patterns/mécanismes de conception.
La cohérence d'un modèle de ce genre avec l'implémentation est plus facile à préserver.
Une approche apparentée consiste à définir la conception en termes de spécifications pour les principaux sous-systèmes, détaillées au point de permettre la compilation des implémentations clients.
La conception détaillée de la réalisation du sous-système peut être modélisée et maintenue séparément de ce modèle de spécification.
Voir Principes et conseils : Sous-système de conception pour les directives relatives aux spécifications et réalisations de sous-systèmes, et sur leur utilisation.
|