Rédaction des documents d’analyse avec U.M.L

Date de publication : 12/04/2006

[ Précédent ] [ Sommaire ] [ Suivant ] [ Télécharger ]

9. Conception
9.1. Préambule
9.2. Découpage en package
9.3. Package Carte
9.4. Base de données
9.5. Epilogue

9. Conception

9.1. Préambule

Vous avez au cours des différents cas d’utilisation, recensé l’ensemble des besoins. Il apparaît maintenant nécessaire d’effectuer une synthèse des modèles de classes dessinés à chaque cas d’utilisation. L’objectif est triple :

Obtenir une vision « Entité » qui prépare l’étape de design
Obtenir un schéma de base de donnée
Valider que l’ensemble des scénarios est cohérent.

9.2. Découpage en package

Auparavant, il semble utile de définir comment nous allons découper les objets métiers en packages.

Découpage des pakages

Ce découpage semble relativement naturel. Il n’offre pas de cycles (2) apparents ce qui facilitera le design.

Nous avons néanmoins introduit deux classes « AnnulerCarte » et « RemplacerCarte » qui détiendront les algorithmes de ces actions. Il semblait plus naturel de les mettre dans le package Carte mais :

L’effort principal de programmation va porter sur les mouvements et non sur les cartes (Modifier les numéros de carte dans les mouvements, modifier leur statut ..).
Ceci introduirait un cycle entre le package carte et le package Mouvement.

Nous avons introduit un package de type « FrameWork » qui contient des entités génériques largement réutilisables d’une application à l’autre. Les dépendances par rapport à ce package ne sont pas montrées.

9.3. Package Carte

L’adresse appartient à un autre package. Nous préférons la considérer dans le package carte comme une interface dont l’implémentation sera une classe du package « Framework ».

9.4. Base de données

La transformation des classes en entités de la base de données est assez simple. Il suffit d’introduire des identifiants permettant la liaison entre les tables.
Contrairement aux diagrammes de classes, le modèle des données doit chercher à être exhaustif. Néanmoins, nous ne représenterons ici que la partie concernant les cartes.

9.5. Epilogue

Ce modèle de conception donne une vision d’implémentation. Il structure les développements.
Mais le travail de programmation transformera encore une fois ce diagramme en introduisant contraintes de design et patterns. Au final le diagramme de classes fera apparaître encore d’autres objets ....

[ Précédent ] [ Sommaire ] [ Suivant ] [ Télécharger ]

Ce document est soumis à la licence GNU FDL traduit en français ici.
Permission vous est donnée de distribuer, modifier des copies de cette page tant que cette note apparaît clairement.