Discussion :

[nicocsgamer]

Bonjour à tous,

Je souhaiterais que vous me donniez votre avis sur mon diagramme de classe.

http://img179.imageshack.us/img179/1...smodle1ss0.jpg

Règles de gestion :

Un seul itinéraire est définit pour chaque chantier.
Un chantier est composé de lot, et chaque lot est unique (correspond à un seul chantier).
Un historique du statut doit être réalisé ainsi que celui des réunions et coordonateur.
Un lot est réalisé par une entreprise, et une entreprise peut avoir plusieurs sous-traitants, et elle-même sous-traités.
Une entreprise, assistantMaitreOuvrage, maitreOuvrageDelegue … sont des types de structure.
Contact, coordonnateur … sont des types de personne.
Un contact peut se trouver dans un certains service dans une structure. Il peut y avoir plusieurs contacts pour une structure.
Une personne à un titre : Mr, Mme….
Un chantier à une et une seule adresse ainsi qu’une structure.
Un chargé de chantier d’une entreprise, est chargé d’un chantier.

Merci.

[Nip]

Revois l'utilisation de l'heritage dans ton diagramme; l'heritage apporte bien souvent plus de problemes qu'il n'en resoud, utilise de preference l'agregation ou la composition; de plus dans les cas presentes la seule difference entre les classes filles et mere se resume a un attribut:
-Pour les structures, cree plutot une classe "type d'entreprise" dans laquelle tu ranges tes types que des sous classes.

-Pour les personnes, la c'est plus discutable mais sachant que les differences entre les personnes ne se font que par leur type, cree plutot une autre classe "profession" (par exemple) avec une relation d'agregation; a toi apres d'etablir des regles strictes sur les associations "personne"/Autre classe (comme chantier), tu peux pour ca utiliser OCL ainsi qu'en faisant bien attention aux multiplicites.

Dans ce cas l'heritage n'a aucune raison d'etre tout simplement parce que la classe fille n'apporte aucune info supplementaire (a part la profession de la personne, qui est donnee dans mon cas par la classe agregee); je ne sais pas si c'est un exercice, mais si c'etait une de mes appli je n'utiliserai pas l'heritage; par contre si c'est un exo, c'est une autre histoire puisque la soit tu expliques correctement ton point de vue, soit tu vas dans le sens du prof et de l'enonce et tu utilises l'heritage (mais pour la classe personne seulement), et si c'est un enonce ...c'est un peu bancal.

-Adresse: je ne comprends pas l'interet de la multiplicite pour le complement d'adresse, je passerai tout sous la classe adresse.
Si tu crees une classe codePostal alors il faut creer une classe Ville et une classe pays, ou alors tu passes le CodePostal directement dans la classe adresse.
La classe rue n'a pas d'interet: passe les attributs directement dans la classe adresse et supprime cette classe

-multiplicite chantier -> lot: est ce que un chantier est compose de au minimum 1 ou 2 lots? (la difference n'est pas fondamentale)

-Utilise l'agregation entre adresse et chantier et adresse et structure.

Le reste me parait correct.

[nicocsgamer]

Merci bcp pour ta réponse.

Comment supprimer l'héritage alors qu'un seul type de structure, par exemple entreprise soustraite mais pas maitrise d'oeuvre. En fait les classe filles n'apporte pas d'attibuts mais des relations. Donc comment supprimer l'héritage.

Ensuite pourquoi mettre rue comme attribut de adresse, alors q'une adresse n'a pas forcement une rue. Pareil pour la boite postale. Si je fais comme tu le suggére j'aurais des champs vides dans ma base.

Enfin pourquoi utiliser une agrégation entre adresse-structure et chantier-adresse ?

Ce n'est pas un exercice

Merci encore.

Ps : Ocl ?

[Nip]

Desole pour le temps de reponse

Comment supprimer l'héritage alors qu'un seul type de structure, par exemple entreprise soustraite mais pas maitrise d'oeuvre. En fait les classe filles n'apporte pas d'attibuts mais des relations. Donc comment supprimer l'héritage.

Je comprends ce que tu veux dire et je vais developper mon point de vue un peu plus tard la dessus (par manque de temps mais comme je ne veux pas te laisser sans reponse, je meuble ). Quoiqu'il en soit ce ne sont que des suggestions et tout est discutable .
En attendant je t'invite a lire ce PDF de Martin Fowler sur la modelisation des roles en UML (ce qui correspond parfaitement a ton sujet): http://www.martinfowler.com/apsupp/roles.pdf

Ensuite pourquoi mettre rue comme attribut de adresse, alors q'une adresse n'a pas forcement une rue. Pareil pour la boite postale. Si je fais comme tu le suggére j'aurais des champs vides dans ma base.

Oui tu auras des champs vides dans ta base, mais je ne vois pas ou est le probleme, ce n'est pas mal d'avoir des champs vides ou a null; par contre avoir un modele objet qui part dans tous les sens ca l'est plus . La par contre, je suis sur qu'il vaut mieux tout passer dans une meme classe, en tout cas pour les rues et complement d'adresse; pour le CP, ville et Pays, c'est a discuter et ca depend de tes besoins, tu peux les passer dasn une classe a part.

Enfin pourquoi utiliser une agrégation entre adresse-structure et chantier-adresse ?

Juste parce que tu as une notion d'appartenance entre une adresse et une structure/personne; si tu detruit une personne/structure l'adresse n'a plus de raison d'etre, donc elle doit disparaitre; d'ailleurs, je rectifie, ce n'est pas une agregation mais une composition

Ps : Ocl ?

OCL c'est pour Object Constraint Language et ca te permet de preciser tes relations dans un modele UML.