La conception détaillée et la conception préliminaire

Conception détaillée

La conception détaillée est une activité qui s’inscrit dans l’organisation définie par la conception préliminaire. Le modèle logique y est particulièrement important dans la mesure où c’est en conception détaillée que l’on génère le plus gros volume d’informations. Il est ainsi possible de confier les catégories à des personnes différentes, qui pourront travailler indépendamment les unes des autres. La conception détaillée s’appuie donc sur les catégories de conception organisées à la fois suivant les frameworks techniques et les regroupements propres au métier. Les concepteurs construisent alors les En dernier lieu, il convient de préciser le contenu des sous-systèmes de manière à compléter la configuration logicielle. Le niveau d’abstraction visé par l’étape de conception détaillée est la conception des composants. Il s’agit d’avoir une idée la plus précise possible pour la fabrication et l’assemblage des sous-systèmes de configuration logicielle. La conception détaillée précède la phase de codage. À ce niveau, toutes les questions relatives à l’agencement et aux détails de la solution doivent être modélisées. Ainsi, les interrogations restantes concernent exclusivement la bonne utilisation des langages et des outils de développement. Les classes qui proviennent de l’analyse ne sont pas toujours conformes aux possibilités du langage d’implémentation. Dans certains cas, une analyse orientée objet est réalisée dans un langage non objet. La transformation des classes en codage est alors particulièrement importante pour conserver la trace du passage de l’analyse au code. Java offre bien entendu une transformation beaucoup plus directe. Certaines formes telles que les métaclasses, les états ou les héritages multiples sont cependant tolérées par les analystes mais incon- nues de Java. Concevoir les classes consiste tout d’abord à expliciter comment ces concepts devront être traduits dans le code.

Concevoir les classes, c’est aussi en introduire de nouvelles soit pour prendre en charge des responsabilités purement techniques, soit pour décharger une classe d’analyse de certains de ces aspects techniques. Les liens qui rattachent ces classes entre elles doivent le plus souvent correspondre à des design patterns. On trouvera à terme des classes comme des « fabriques », des « archiveurs », des « traceurs », des « vérificateurs de cohérence », etc. Concevoir les classes, c’est enfin redistribuer les messages et les événements du modèle dynamique sur les différentes couches de conception – nous verrons notamment comment réaliser la conception orientée objet des messages identifiés dans les interfaces EAI. Il est probable en effet que ces concepts vus de manière abstraite par l’analyste ne correspondent plus aux principes de conception. Pour les systèmes 3-tiers, nous pensons plus particulièrement à la redistribution des échanges entre les couches métier et application. Ces échanges s’appuyant sur les capacités d’un réseau physique doivent faire l’objet d’optimisations. Dans cette optique, il convient que les diagrammes d’états soient retravaillés au niveau de la conception.

LE DESIGN PATTERN ÉTAT

Le design pattern État [Gamma 95] est une façon de concevoir le diagramme d’états d’une classe d’analyse. La gestion des états est déléguée de sorte qu’à chaque état corresponde une classe du patron. Une classe gère ainsi les activités et les transitions attachées à l’état qu’elle représente. Le diagramme d’états du suivi de mission sert à illustrer l’application de ce design pattern. Chaque état de la classe correspond à une spécialisation de la classe SuiviMission Etat. Les événements du diagramme d’états deviennent des opérations polymorphes pour les classes États. L’interprétation du diagramme d’états de la figure 11-3 donne ainsi une conception de la classe SuiviMission, accompagnée d’un environnement de gestion de ses états (voir figure 11-4).La classe SuiviMission délègue la gestion de ses états à la classe SuiviMission Etat ; en d’autres termes, elle transmet systématiquement les événements qu’elle reçoit. Les états de la classe sont ensuite chargés de déclencher les opérations et d’assurer les transitions. Le diagramme de communication ci- après vous montre comment un tel mécanisme peut être documenté. Le design pattern État réduit la complexité des méthodes par extraction des instructions d’aiguillage nécessaires à la gestion des transitions. De ce fait, il facilite l’ajout de nouveaux états. La prise en compte d’un super-état se résout tout aussi facilement par l’introduction d’une super-classe état (voir l’étude de cas ci-après).