Discussion :

[analyste_en_herbe]

Bonjour
je suis actuellement entrain de définir les différents diagrammes UML d'une application. j'ai terminé l'identification de mon modèle de données (BD) et les diagrammes d'utilisation (Use Case).
maintenant je voudrai définir mon digramme des classes. toutefois, j'avoue que ce concept m'échappe. aussi, est ce que le diagramme des classes est une extension de mon modèle de données sinon est ce qu'il y a une dépendance entre mon diagramme de classe et celui des cas d'utilisation.
merci de votre aide

[Nip]

Salut et bienvenue sur les forums,

il n'y a pas de regles universelles de passage d'un modele de donnees a un un diagramme de classe (la plupart du temps, on passe plutot du diagramme de classe au model de donnees ).
Neanmoins, on retrouve souvent le modele une classe <--> une table.

De plus, le fait que tu aies etabli les UC devrait grandement te faciliter l'identification de tes objets metiers.

[analyste_en_herbe]

merci Nip pour ton commentaire.
j'ai toujours un problème au niveau de la définition de mon diagramme des classes. en fait, j'ai remarqué qu'en suivant BC4J je devais définir une classe pour chaque table de ma BD. toutefois, dans mes UC j'ai défini beaucoup de fonctions et je ne sais pas si je dois toutes les représenter sour forme de classes ou bien je laisserai ça lors de la programmation. il faut noter que mon projet est assez important et que j'ai peur d'avoir un diagramme de classes illisible.
merci de vos conseils

[Nip]

j'ai toujours un problème au niveau de la définition de mon diagramme des classes. en fait, j'ai remarqué qu'en suivant BC4J je devais définir une classe pour chaque table de ma BD.

Je ne connais pas du tout cet outil mais effectivement c'est comme ca que fonctionnent la plupart (tous?) des outils de mapping O/R: une classe --> une table.

toutefois, dans mes UC j'ai défini beaucoup de fonctions et je ne sais pas si je dois toutes les représenter sour forme de classes ou bien je laisserai ça lors de la programmation. il faut noter que mon projet est assez important et que j'ai peur d'avoir un diagramme de classes illisible.

Meme si tu as une projet de taille consequente, beaucoup d'UC signifient, la plupart du temps, trop d'UC et trop decomposes. D'ailleurs tu le dis toi meme, tu as beaucoup de fonctions dans tes UC, or un UC n'est pas une fonction. Fais bien attention de ne pas penser a l'implementation lorsque tu crees les UC, ce n'est pas leur role.
Et c'est peut etre pour ca que tu as du mal a identifie tes classes a partir de ton diagramme de cas d'utilisation .

Bon la c'est que de la theorie puisque je ne sais pas quoi ressemble tes UC .

[Keihilin]

Je ne connais pas du tout cet outil mais effectivement c'est comme ca que fonctionnent la plupart (tous?) des outils de mapping O/R: une classe --> une table.

Dieu merci non...

En fait il est plutôt rare de pouvoir garder un schéma "une classe = une table" dans une application conséquante et avec une base de donnée normalisée.
Heureusement, la plupart des outils de mapping tiennent compte de cette réalité et savent gérer des cas plus complexes.

[analyste_en_herbe]

merci pour les conseils.
mais j'ai un peu du mal à saisir, les UC décrivent les scénarii devant être supporter par l'application. donc pour traiter un scénario il faut une ou plusieurs classes, de plus, pour chaque entité de la bd il faut aussi une classe (d'aprèes ce que j'ai compris d'Hibernate). en tout cas, j'ai défini un premier diagramme de classes en essaynt de mettre en avant toutes les "fonctions" nécessaires de l'application. toutefois, je me dis que le comportement de mon application sera mieux représenté par d'autres diagrammes UML.
qu'en pensez vous ?

[Nip]

Je ne connais pas du tout cet outil mais effectivement c'est comme ca que fonctionnent la plupart (tous?) des outils de mapping O/R: une classe --> une table.

Dieu merci non...

Desole pour la confusion , j'ai ete effectivement un peu rapide la dessus: j'aurais du plutot dire que le comportement basique de ces outils est de creer une table pour une classe, ce qu'on appelle le mapping horizontal et qui est la mise en oeuvre la plus simple.

Mais je suis totalement d'accord sur le fait que la majorite d'entre eux permettent d'utiliser d'autres approches (comme le mapping vertical ou d'union).

les UC décrivent les scénarii devant être supporter par l'application. donc pour traiter un scénario il faut une ou plusieurs classes

Exact

pour chaque entité de la bd il faut aussi une classe (d'aprèes ce que j'ai compris d'Hibernate).

Pas obligatoirement comme l'a souligne Keihilin.

le comportement de mon application sera mieux représenté par d'autres diagrammes UML

Exact le comportement de ton appli ne peut pas etre represente par ton diagramme de classe, les diagrammes de sequences sont adaptes pour la dynamique.