La conception doit fournir une définition suffisante du système pour qu'il n'y ait pas d'ambiguïté lors de son
implémentation. Cela varie d'un projet à l'autre et d'une société à l'autre.
Dans certains cas, la conception ressemble à une esquisse élaborée juste pour permettre à l'implémenteur de travailler
(approche "esquisse et code"). Le degré de spécification varie selon la compétence de l'implémenteur, la complexité de
la conception et le risque que la conception puisse être mal interprétée.
Dans les autres cas, elle est élaborée de façon à ce qu'elle puisse être automatiquement transformée en code. Cela
implique généralement de rajouter des extensions au langage UML pour représenter la sémantique propre au langage et/ou
à l'environnement.
La conception peut aussi être hiérarchique, comme indiqué ci-dessous :
-
un modèle de conception de haut niveau qui représente une esquisse d'une vue d'ensemble de tout le système
-
un modèle de spécification de sous-système qui précise exactement les interfaces requises et le comportement des
principaux sous-systèmes à l'intérieur du système
-
un modèle de conception détaillé des structures internes des sous-systèmes
Le plan de développement doit définir comment le modèle de conception
est réalisé dans le processus propre au projet et comment/si ce modèle est rattaché aux autres modèles et à
l'implémentation. Les détails s'y rapportant doivent être dans les Instructions relatives au projet.
Les sections suivantes décrivent quelques options différentes pour relier conception et implémentation, et présente les
avantages et inconvénients de ces approches.
Une approche courante consiste à esquisser la conception à un niveau assez abstrait, puis de passer directement au
code. La maintenance du modèle de conception se fait manuellement.
Dans cette approche, une classe de conception peut être une abstraction de plusieurs classes au niveau du code. Nous
vous recommandons de mapper chaque classe de conception à une classe "principale" qui, à son tour, peut utiliser
plusieurs classes d'"assistant" pour remplir sa fonction. Vous pouvez utiliser ces classes d'"assistant" pour
implémenter un attribut complexe ou construire une structure de données dont vous avez besoin pour procéder à
l'implémentation d'une opération. Dans la conception, vous ne modélisez pas ces classes, vous modélisez seulement les
attributs clés, les relations et les opérations définis par la classe principale. L'objectif d'un tel modèle est de
représenter de manière abstraite les détails dont l'implémenteur pourra se charger.
Cette approche est étendue aux autres éléments du modèle de conception. Vous pouvez avoir des interfaces de conception
qui sont plus abstraites que les interfaces au niveau du code, et ainsi de suite.
Dans les environnements d'ingénierie aller-retour, le modèle de conception se développe jusqu'à un niveau de détail où
il devient une représentation visuelle du code. Le code et sa représentation visuelle sont synchronisés (avec un
support d'outil).
Les options suivantes représentent quelques unes des options possibles 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é
Dans cette approche, deux niveaux de modèle de conception sont maintenus. Chaque élément de conception de haut niveau
est une abstraction d'un ou plusieurs éléments détaillés du modèle aller-retour. Une classe de conception peut, par
exemple, être mappée à une classe "principale" et à plusieurs classes d'"assistant", comme dans l'approche "esquisse et
code" décrite précédemment. La traçabilité entre les éléments du modèle de conception de haut niveau et les éléments du
modèle aller-retour peut aider à maintenir une cohérence entre les deux modèles.
Bien que cela puisse aider à représenter de manière abstraite les détails les moins importants, cet avantage doit être
étudié par rapport à l'effort requis pour maintenir la cohérence entre les modèles.
Modèle de conception évolutif unique
Dans cette approche, il existe un modèle unique de conception. Les esquisses initiales des éléments de conception
évoluent jusqu'à ce qu'elles puissent être synchronisées avec le code. Les diagrammes, tels que ceux utilisés pour
décrire les réalisations de cas d'utilisation de conception, font initialement référence aux classes de conception
esquissées mais font par la suite référence aux classes propres au langage. Les descriptions de haut niveau de la
conception sont maintenues selon les besoins en tant que :
-
diagrammes de la structure logique du système,
-
spécifications du sous-système/composant,
-
mécanismes/patterns de conception.
Il est plus facile de maintenir un tel modèle en cohérence avec l'implémentation.
Une approche similaire consiste à définir la conception en termes de spécifications des principaux sous-systèmes qui
sont détaillées de telle manière que le client peut implémenter en se basant dessus.
La conception détaillée de la réalisation du sous-système peut se modéliser et être maintenue séparément de ce modèle
de spécification.
Voir Instructions relatives au produit : Sous-système de conception pour les instructions
relatives aux spécifications et aux réalisations du sous-système et pour savoir quand les utiliser.
|