Discussion :

[Reelo]

Bonjour

j'ai deux questions concernant le diagramme de classe d'un petit projet d'études (boutique en ligne) que je dois réaliser.
La première
Est ce choquant de mettre les multiplicités d'une relation de composition à 1 ... 1 de chaque côtés des
des classes? En fait je voudrais exprimer le fait qu'un client possède un compte, et qu'un compte ne peut être posséder que par un client. Bien entendu si on supprime le client on supprime aussi son compte.

Deuxième question
Mon diagramme de classes est issu de mon MCD. Mes entités ont été transformées en classes d'objets et mes relations en associations. Je ne suis pas super à l'aise avec UML. J'ai donc conçu mon projet, au départ, avec Merise (pour la Bdd) et je dois le programmer en objets.
Je veux donc savoir si on peut passer directement à la programmation et créer de nouvelles classes au fur et à mesure du développement mais qui n'apparaitront pas dans le diagramme (lequel sera moins complet, donc moins explicite ) ou alors, d'abord affiner le diagramme en créant les nouvelles classes et enfin programmer ? comment feriez vous ?
Merci pour votre aide

[kolodz]

Bonjour,

Le diagramme de classe est un outil de réflexion et de travail. Il doit être clair pour ceux qui l'utilise !

Un diagramme n'a pas forcement besoin de tout représenter, mais doit présenter un tout cohérent.

Est ce choquant de mettre les multiplicités d'une relation de composition ?

D'après ce que dit Wikipédia sur le sujet :
Composition_programmation et Diagramme_de_classes : Composition
Cela ne me semble pas nécessaire. Cependant, cela a le mérite d'être explicite.

Note : Si c'est pour être rendu pour un devoir. Demande à la personne référente. Sa réponse sera peut-être différente...

... d'abord affiner le diagramme en créant les nouvelles classes et enfin programmer ? comment feriez vous ?

Fait ce qui te semble le plus logique.

Personnellement, je pense que sur un petit projet, il est plus simple de faire un premier diagramme pour poser les idées. Puis développer et enfin mettre le diagramme à jour pour la documentation (Si besoin).


Cordialement,
Patrick Kolodziejczyk.

Note : Cela reste mon avis personnelle. De plus, je ne connais pas ton contexte...

[Reelo]

Merci, Kolodz pour la réponse

Pour ce qui est du contexte, oui c'est un devoir à rendre.
Je comprend maintenant qu'un diagramme de classe n'est pas figé et qu'il peut être amélioré dès le début.
Le problème est qu'avec un MCD on ne voit pas tout de suite si l'on va avoir des choses à rajouter (même si on peu en avoir une vague idée avec les autres modèles merisien) puisque seuls les attributs et les classes issus du MCD sont représentés dans le diagramme.

D'ailleurs est ce qu'on les voit plus facilement quand on commence avec un diagramme de classes ? Pas sûr, mais d'après ce que j'ai vu et compris d'UML avec mes quelques notions assez basiques (qu'il faut que je complète assez vite ), on a une vision plus globale de ce qu'on veut faire et on peu peut être anticiper plus facilement les fonctionnalités d'un Système. Dites moi SVP si je me trompe ?
Je pense que beaucoup de "débutants" en la matière doivent se poser les mêmes questions que moi à un moment donné quant au passage MCD -> diagramme de classes VS diagramme de classe -> MCD pour faire simple, la deuxième solution n'est elle pas plus rapide ?

Dans mon cas, mon diagramme est pour le moment assez simple (pas de méthodes juste les attributs). Mais au fur et à mesure, je me dis: "tiens là il faudrait que je pense à mettre un attribut pour la connexion à la base", puis, "là il faudrait penser à mettre une nouvelle classe pour tel rôle " . Bref, ça peut durer longtemps . Mais ne semble t il pas plus logique de préciser le plus possible le diagramme de classes pour éviter de le mettre trop souvent à jour ? après reste à trouver le juste milieu pour rester compréhensible.

[bruno_pages]

Bonsoir, je suis globalement d'accord avec ce qui a été dit, mais la phrase disant de mettre à jour le modèle pour la documentation, est trop réductrice. La bonne facon de travailler c'est de générer le code à partir du modèle, pas de mettre a jour le modèle â partir du code. Ensuite UML n'est pas réduit aux seul diagrammes de classe.

[Reelo]

Bonsoir
Loin de moi l'idée de pensée qu'UML ne se résume qu'au diagramme de classes
Mais ayant débuté avec Merise (Diagramme des flux, MCD, MLD, MLT, MOT) je trouvais qu'avec ce diagramme ce serait suffisant pour préciser ce que Merise (surtout le MCD) ne montre pas dans la globalité.
Après j'ai bien compris qu'avec l'une ou l'autre technique que plus un modèle est précis dès le départ moins on a de soucis pour le reste. Ensuite jusqu'où faut il aller dans le détail pour rester simple et complet ? je crois que c'est le plus dur en ce qui me concerne surtout qu'en on n'a pas l'habitude avec UML. Mais ça s’éclaircit peu à peu