Bonjour à tous.
 
Je suis un petit peu bloqué sur mon projet, j'en suis à l'analyse et plus particulièrement au diagramme des classes. Mais j'arrive pas à comprendre certaine chose. Les relations entre table (de la BDD) vont forécement être différente des relations (héritage) entre les classes du programme ?
 
Je m'explique et pour cela je vous joint une image du MPD fait sous Mysql Workbench
 

 
Même si peu y avoir des erreurs la version est pas encore vraiment finalisé mais je prépare quand même le terrain. J'ai pour but donc de faire un classe par table en quelque sorte.
L'une des classes mère sera DOSSIER qui comme on peut le voir est un peu le pilier de l'application.
 
Je vais prendre donc 2 exemples concret sur lesquels je me pose des questions.  
 
1°) J'ai une table T_TYP_CONTENTIEUX cette table servira a stocker des valeurs dans le but d'avoir une liste déroulante dans l'application. j'ai donc une relation avec la table T_DOSSIER pour y stocker l'id du type de contentieux. Cependant j'ai également un champs dans la table T_DOSSIER qui se nomme RID_CMPLT_TYPE_CONT qui est un complément d'informations sur le type de contentieux (en gros le pourquoi du comment en longText). Dans la logique dès choses je verrais cela pour la partie classe de faire un objet TypeContentieux qui reprend les informations de la table mais également en lui l'attribut ComplementInfo en plus. Ou alors je me trompe dans mon analyse et que ce complément d'info est belle et bien dans l'objet Dossier tel qu'il figure dans les champs de la table Msql T_DOSSIER ???
 
2°) Exemple qui reste similaire avec la table T_PARTIES qui est une table stokant un certain nombre d'informations fixe mais dont on pourra en rajouter, ce sera des informations de type SOCIETE, SERVICE, PERSONNE  afin de justement avec une liaison avec T_DOSSIER toujours en liste déroulante en faite et ou l'on à un complément d'info via le champs RID_LIB_REQUERANT et RID_LIB_DEFENSEUR. Dans la programmation j'aurais appeler l'objet PARTIE en créant un objet globale avec toutes les informations cependant étant donné que les informations se stockent sur 2 bases différentes je suis un peu perdu.
 
 
Pour les table JUGEMENT SUITE JUGEMENT et EVENEMENT pas de soucis je pense un objet pour chaque  
JUGEMENT classe fille de DOSSIER
SUITE JUGEMENT classe fille de JUGEMENT
EVENEMENT classe fille de DOSSIER
Etc...
 
En gros jusqu’à maintenant j'ai jamais eu de soucis car je faisait de l'objet correspondant a une table avec une classe qui était une classe fille d'une classe objet qui était une classe fille d'une classe Mysql  
j'ai toujours bosser comme ça. Mais la c'est pas vraiment dans le même fonctionnement donc je pose pas mal de question
 
Donc si quelqu'un ou plusieurs pourrait éclairer ma lanterne sur comment organisé mes classes cela m'aiderai beaucoup car je bloque vraiment pas mal sur ca.
 
Vous en remerciant par avance

Bonjour,
mettre ComplementInfo dans la classe Type Contentieux n'aurait pas de sens à mon avis. Si tu veux le séparer du dossier il faudrait plutot créer une classe Contentieux qui aurait comme attribut un TypeContentieux.
 
tu aurais donc un Dossier qui a un Contentieux qui est d'un TypeContentieux.
 
Mais je pense que l'intêret est limité et à ta place je laisserais l'attribut ComplementInfo dans la classe Dossier. Pareil pour T_PARTIES
 
Au final ces compléments d'info concerne bel et bien le dossier.
 
Voilà pour ce qui est de mon point de vue

Je te remercie pour ton point de vue. Je commençais à m'arracher les cheveux (que j'ai pas) sur cette analyse.
Donc en gros  je reste tel qu'une classe par table en BDD et une classe mysql (qui n'est pas sur le schéma) sous forme de pattern singleton  
 
Mais autre question donc
les relation entre table, n'est pas obligé de correspondre à une relation (héritage) entre classe.
Genre la relation entre T_TYP_CONTENTIEUX et T_DOSSIER pour la BDD ne va pas forcement donner lieu à une classe mere pour dossier et une classe enfant pour TypeContentieux. C'est bien deux choses différente n'est ce pas ?
Sachant que TypeContentieux est vraiment des informations unique.
 
Contrairement a jugement  et suite jugement ainsi qu'a Evenement
 
D'ou ma quatrieme question
 
est ce qu'un attribut d'une classe peut etre un objet ? qu'elle type en UML donnée si c'est le cas ?
 
car dans ce cas dans la classe Dossier j'aurais des attribut du genre
Jugement (objet de la classe jugement)
Evenement (objet de la classe événement).
 
mais il peut y avoir plusieurs jugement et plusieurs événement bien entendu donc plusieurs objet fille pour une instanciation de la classe mère dossier.
je ne sais pas si je suis claire dans mes propos :s

Attention à ne pas voir de l'héritage là ou il n'y en a pas alors !
Si un dossier a plusieurs évènements c'est qu'Evenement n'est en aucun cas une classe fille de Dossier.
 
Exemple : une classe Vehicule ayant un attribut couleur, et un attribut immatriculation. Alors une classe Voiture pourrait hériterait de la classe Véhicule. Mais un Véhicule n'a pas de voiture. Une voiture EST un véhicule.
 
Si un Véhicule a un seul Fournisseur alors la classe véhicule a un attribut fournisseur de type Fournisseur.
 
Si un Vehicule a plusieurs chauffeurs alors la classe Vehicule a un attribut array() de Chauffeur.

Et bien je te remercie pour ces réponses pertinentes j'ai donc tous ce qu'il faut pour me remettre à bosser comme il faut en effet je faisait pas la différence entre relation table et héritage classe (grosse erreur con).
 
En gros je pourrait découper ma table dossier par exemple en plusieurs classe 1 classe mère dossier et des classe fille du genre comme tu disais contentieux qui regrouperais le type de contentieux et l'information complémentaire par exemple ou encore une autre classe fille pour les indemnisation ainsi qu'une classe requérant et une classe défenseur toutes également enfant de dossier (ce n'est qu'un exemple faut que je voie tout cela).
 
Cependant j'ai également ma réponse un attribut d'une classe peut contenir un objet d'une autre classe sans pour autant être en relation d'héritage de ce fait ma classe dossier aura un attribut Jugement, qui sera un tableau d'objet de la classe jugement et dont le type sera array.
 
Encore un grand merci pour avoir éclairer ma lanterne

De rien, bon courage