Discussion :

[wafiwafi]

Bonjour,
J’aimerais avoir votre avis sur cette question :

Pourrait on raisonner sur les communications entre objets (appel de méthodes) pour constituer le diagramme de classe ? Sachant que les relations dans le diagramme de classe se passent entre collections d’objets !
Prenons un exemple :

Problème (gestion bibliothèque) : Trouver les relations entre trois classes : Personnel, Adhérent et Livre.
Mon raisonnement objet :

Manipulation de la fiche d’un adhérent :

Un objet d’une classe Personnel communique directement avec un objet d’une classe Adhérent pour manipulation des données.
Relation : association unidirectionnelle de la classe Personnel vers la classe Adhérent.


Réalisation des opérations liées au prêt d’un livre par un adhérent :

Un objet de la classe Personnel communique avec un objet d’une classe Livre pour changer son état. Ce dernier va à son tour communiquer avec un objet de la classe Adhérent pour indiquer l’opération sur son compte.

Relation : association unidirectionnelle de la classe Personnel vers la classe Livre qui à son tour est associée à la classe Adhérent.

ECT........

[montesq]

Non!

Il faut revoir la définition du diagramme de classe...
En particulier, la deuxième ligne:

il fait abstraction des aspects temporels et dynamiques

[wafiwafi]

OUI, je suis entièrement d'accord avec toi. Je connais bien la définition et, pour moi, elle est respectée puisqu'en lisant un diagramme de classe, on ne peut se rendre compte de l'interactivité, de l'aspect dynamique du problème.
Néanmoins, et c'est mon interrogation !, quand on se fixe les classes mises en jeu et que l'on souhaite établir les relations, personnellement, je ne peux m'empêcher à imaginer ce qui est susceptible de se passer comme échanges en terme de message entre objets. En quelques sorte j'utilise sans me rendre compte un diagramme de séquence avec pleins de boites noirs pour imaginer la manière avec laquelle le diagramme de classe pourrait être exploité. Attention, je n'ai pas dis que le diagramme de classe indique cet aspect dynamique qui en fait m'aide à mettre les relations entre les classes ET C'EST TOUT!
En fait, cela permet de trouver les bonnes relations et écarter l'inutile.
Je ne sais pas si je suis clair.
Merci

[chaplin]

En quelques sorte j'utilise sans me rendre compte un diagramme de séquence avec pleins de boites noirs pour imaginer la manière avec laquelle le diagramme de classe pourrait être exploité.

Faire de la programmation objet, c'est pas de la magie et cela ne vient pas de l'intuition, on utilise le type de diagramme par rapport au besoin. En l'occurence, on choisi entre le diagramme de séquence ou de collaboration pour voir l'aspect dynamique.

[wafiwafi]

Tout d'abord, Merci pour ta réponse.

Faire de la programmation objet, c'est pas de la magie et cela ne vient pas de l'intuition,

Je n'ai pas dis que c'est de l'intuition et je ne me prétends pas magicien; j'aimerais seulement qu'on m'explique comment établir les relations entre classes sans se projeter vers la façon avec laquelle le diagramme serait exploité.
J'ai dis simplement qu'on le fait de façon naturelle et non par magie.
Je ne dis pas non plus que j'ai raison, mais j'aimerais savoir comment vous faites?
Je ne vais tout de même pas mettre des relations à la volé!!

Faire de la programmation objet, c'est pas de la magie et cela ne vient pas de l'intuition, on utilise le type de diagramme par rapport au besoin.

Comment procèdes tu pour trouver les relations?

l'occurence, on choisi entre le diagramme de séquence ou de collaboration pour voir l'aspect dynamique.

Le problème n'est pas là puisqu'on parle du COMMENT établir les relations entre les classes TOUT EN ÉCARTANT L'INUTILE.

[chaplin]

Prenez l'exemple d'une boîte au lettre dans un village ou dans une quartier d'une ville. Faites l'analyse UML de l'envoi d'un courrier, cherchez les acteurs, décrivez les concepts, cherchez les liens(actions) entre chacun.

J'aurais pu prendre l'exemple trivial du distributeur automatique de billet d'une banque, globalement, il s'agit d'observer puis de décrire pour concevoir, voilà le but d'UML.

Commencez d'abord par analyser un cas simple.

[wafiwafi]

Jusqu'au là, je faisais comme tout le monde en suivant le cycle habituel. J'ai réalisé, pour le plaisir et pour mieux apprendre, trois modélisations (justement le distributeur, station service et plateforme de formation). L'utilisation des concepts UML ne me pose aucun problème. C'est en lisant un article suivi de débats sur l'établissement des relations entre classes qui m'a mis la puce à l'orteil. J'établissais les relations en question, à partir de mon analyse et notamment les UC. En me posant LA QUESTION, je me suis rendu compte que les relations entre les classes , dans mon cas, ne font pas vraiment l'objet d'une étude qui leur ai destinée. Je ne peux pas dire que j'ai écarté l'inutile dans mes trois projets.

Je ne veux être non plus lourd, peut être qu'il ne faut se poser ce genre de question et faire ce que fait tout le monde; ce que je faisais d'ailleurs.
Merci pour tes remarques pertinentes.

[montesq]

Ton raisonnement est je pense doublement faux, car comme je te l'ai indiqué le diagramme de classes est une représentation statique de ton système donc ne peut être déduit de la partie dynamique... (ce serait comme si à partir de la communication entre 2 PCs tu pouvais déduire quels sont les composants de chaque PC )
D'autre part, si on applique les bonnes pratiques d'architecture en couche les objets métiers ne communiquent pas entre eux comme tu le suggére, au contraire c'est la couche métier/logique située "au-dessus" qui réalise les traitements et manipule les objets.

[wafiwafi]

EXCELLENTE réponse!
Je ne peux que me plier.
C'est clair!!
Merci beaucoup

[montesq]

EXCELLENTE réponse!
Je ne peux que me plier.
C'est clair!!
Merci beaucoup

J'espère que ce n'est pas ironique...
Sinon, pour en revenir à la vraie discussion de fond (à savoir trouver les relations entre les classes), je t'accorde qu'il n'y a pas vraiment de méthode, et même si ce n'est pas de la magie, il est clair que l'expérience joue beaucoup.
Pour moi, la meilleur moyen de concevoir un diagramme des classes est encore d'écrire un bon (=synthétique) texte descriptif de ton système. Par la suite quand tu auras l'habitude, tu feras directement le diagramme sans formaliser par écrit la description de ton système, mais dans un premier temps...

Par exemple, si je te demande de modéliser une écurie de course automobile et si ensuite je te donne la description suivante:
une écurie est composée d'un directeur, de techniciens et d'un pilote. Le pilote conduit une voiture de course. La voiture de course est composée d'un moteur, d'une carrosserie, de 4 roues...

Avec un texte descriptif tel que celui-là, je pense que tu es facilement en mesure d'isoler les différentes classes et de trouver les relations qui existent entre elles, non?

[wafiwafi]

J'espère que ce n'est pas ironique...

Je ne suis vraiment pas comme ça. A travers ton exemple, j'ai pu me rendre compte qu'une bonne description textuelle pourrait faire l'affaire et j'ai apprécié la manière avec laquelle cela a été expliqué. Ne vois surtout pas de réaction négative dans mon intervention.

Je m'amuserai à faire le modèle que tu m'as fourni.
Bien à toi

[chaplin]

Ce qui sème la zizanie dans UML, ce sont les interfaces, elles sont omniprésentes, omnipotentes.

[wafiwafi]

OHHH OUI, j'en sais quelque chose.
J'irais jusqu'à dire que pour les adeptes de java, et vu la ressemblance avec les interfaces java au niveau principe j'entends, facilite énormément la compréhension de ces dernières.
Les interfaces dans uml (aucune information sur l'implémentation) sont certainement là, à mon avis, pour éviter la répétition du code, faire de l'héritage multiple sans risque du problème du losange (les méthodes sont vides et pas d'attributs sauf les constantes) du coup du polymorphisme, et enfin soulager la sollicitation d'une classe dans les appels des méthodes. Néanmoins, pour le dernier point, je reste sceptique dans le mesure où une classe doit implémenter la méthode, et du coup, cette même classe sera sollicitée (déshabiller Pierre pour habiller Paul).
Qu'en pensez vous?

[chaplin]

Je ne l'avais pas vu sous cet aspect, soit, mais c'est effectivement un point de vu. Par interface je faisais allusion aux IHM par exemple.

Dans l'exemple de la boite aux lettres, l'interface est la façade de la boîte aux lettres, c'est pas un écran d'ordinateur, mais ça reste une interface. Le courrier deviendra une classe, mais on dépose une lettre, on vide la boîte aux lettres, bref ce ne sont que des manipulations d'objets. Les courriers ne s'envoient pas d'eux mêmes, ils sont déplacés d'objet à objet. En revanche, ils ont des états, ils sont fermés, ouverts, en routage, etc ...

[wafiwafi]

Excuse moi, je n'avais compris cela.
Je n'ai pas eu encore l'occasion de réaliser une vraie IHM, si ce n'est qu'à travers des petits TPs. Tu m'arrêtes si je me trompe, il faudrait séparer les deux aspects d'une problématique : le système et son interface graphique (IHM) s'il en a un.
Il y a donc deux modélisations à mener avec des inter-connexions entre dernières (par une gestion des événements par exemple....).

[chaplin]

Il n'y a qu'une modélisation à faire, mais il faut tenir compte à la fois de l'interaction entre les acteurs et le système d'information, et ce qui se passe à l'intérieur de ce dernier.

Pourrait on raisonner sur les communications entre objets (appel de méthodes) pour constituer le diagramme de classe ? Sachant que les relations dans le diagramme de classe se passent entre collections d’objets !

Un petit coup de "De UML à SQL Conception de base de Données" de Christian Soutou, à lire tous les matins et soir avant de se coucher.

[wafiwafi]

Même la partie graphique.....??

[hegros]

En fait ta première description pour identifier les classes n'est pas bonne. Une conception oo c'est une modélisation informatique du monde réel.

Par exemple

Un objet de la classe Personnel communique avec un objet d’une classe Livre pour changer son état. Ce dernier va à son tour communiquer avec un objet de la classe Adhérent pour indiquer l’opération sur son compte.

Non un livre ne communique pas avec un adhérent. Il y a un mélange des genres. Il faut donc avoir une description (modélisation) du monde réel

il y a aussi un malentendu dans comment adopter une démarche méthodique avec UML notamment en ce qui concerne le phasage.

Synthétiquement et pour résumer une approche dans le temps voici une courte description de comment se forment des associations entre classes.

En étude des besoins tu vas effectivement t'attacher à décrire le monde réel et à identifier des classes dites du domaine (de l'étude) et dites aussi candidates pour l'implémentation (c'est la technologie qui va déterminer le degré de rapprochement entre ces classes et l'implémentation)

Après cette phase tu étendre l'analyse et conception(avec un peu de /programmation/tests) et soit

-tu ne vas pas utiliser certaines classes identifier pendant l'étude des besoins. On peut dire que ces classes passent du statut candidate à classe du domaine. Elles restent utilisable dans un contexte d'analyse et de conception du domaine modélisé soit pour l'enrichir et le faire évoluer(dans le monde réel cela bouge assez vite)

et

-tu vas réutiliser certaines classes de ce modèle(par exemple un moteur et une voiture) et les enrichir soit d'attributs soit de méthodes issu d'un affinement de l'analyse.

et

-tu vas créer de nouvelles classes pour faire les interfaces avec les IHM ou pour implémenter des patterns

Au final là tu as au minimum 2 diagrammes de classes de niveaux différents : 1 du domaine et 1 de conception exécutable informatique. Un troisième peut être encore fait par rétro-ingénierie de code. Ce qui donne 3 niveaux de modélisation différents avec un diagramme de classe

Ce qu'il ne faut pas oublier c'est qu'effectivement là c'est la partie statique tandis que la partie dynamique, architecturale ou d'usage peut effectivement avoir un impact sur ces modèle statiques (celui de conception informatique et celui du domaine) s'ils vienne à évoluer ou à apporter des informations jusqu'ici ignoré

J'espère que cela réponds à tes questions "comment trouver les associations" : il y a celles qui sont déduites du monde réel (une voiture à des roues) et celles qui sont déduites de la conception informatique(pattern par exemple, interface avec des ihm)

[wafiwafi]

Je vois que j'ai beaucoup à apprendre dans ce domaine!
J'ai très bien compris ton point de vue. Que penses tu de ce diagramme que je reverrai certainement en tenant compte de ta pertinente intervention.

[wafiwafi]

Non un livre ne communique pas avec un adhérent. Il y a un mélange des genres. Il faut donc avoir une description (modélisation) du monde réel

Du point de vue informatique c'est possible, mail il est vrai qu'un livre ne communique pas. Dans ce cas, la fiche_adhérent et livre ne peuvent jamais être connectées puisque, réellement ni l'un ni l'autre ne peut communiquer.
Prenons l'exemple d'une station service. Dans ce cas gâchette et pompe ne peuvent être connectées; ce qui me gène.
J'ai compris ce que tu veux dire, j'ai du mal à voir ce que voudrait dire réellement

Il y a un mélange des genres

Peut être que tu fais allusion à des associations qui ne sortent pas de la normale. Un adhérent navigue vers livre mais pas le contraire.
Il y a certainement un truc qui m'échappe.