Discussion :

[mik-at]

Bonjour.

Est-ce que vous savez comment faire communiquer 2 objets entre eux ?

Je vous présente mon problème :

Tout d'abord, le diagramme de classe avec une classe Entreprise qui contient N Directeurs et M Employés :


Dans le diagramme de machines à états de la classe Entreprise, je crée les objets :


Dans le diagramme de machines à états de la classe Directeur, j'envoie un message à tous les employés :


Dans le diagramme de machines à états de la classe Employé, je me contente de les recevoir :



Pour simplifier le problème, je ne crée ici que un seul directeur et 5 employés
Quand j'envoie le message 5 fois par le port : il est reçu toujours par le premier employé lors de la simulation.
Ci-dessous, le diagramme de séquences générée lors de la simulation :


Comment faire pour que le directeur envoie un message pour chacun des employés ?

> Je pensais passer par la classe Entreprise, mais je ne trouve pas ça "propre".
Sinon, je suis en train d'essayer en passant les références de ces classes de la classe Entreprise vers la classe Directeur lors de sa création.

Si vous avez une idée, ça m'aiderait grandement.
Merci d'avance.

[mik-at]

Personne n'a la moindre petite idée ?
ou une piste à suivre ?

[bruno_pages]

en passant, sans vouloir faire de la "lutte des classes" le directeur est aussi un employe :-), bref faire une classe Directeur ne me semble pas forcement tres judicieux

pour le reste il y a plusieurs possibilites :

• soit l'operation 'dire_a_tous' definie sur entreprise recevant le message à diffuse a l'ensemble des employes de Entreprise, sauf l'emetteur qui se donne en param
• et/ou l'operation 'dire_a' definie sur Employe recevant un message, le receveur etant l'interlocuteur, la liste des interlocuteurs pouvant etre fournie par Entreprise
• l'operation de classe 'leur_dire' recevant la liste des destinataire et le message pour une diffusion non totale
• etc...

[mik-at]

En fait : j'ai fait un exemple simplifié de mon problème. Il fallait juste que j'ai une classe qui communique avec les autres. Mais ça représente ce que j'essaye de faire.

Bon je suis tes idées. C'est à peu près ce à quoi je pensais.
En utilisant des références sur les autres objets.

Merci.

[Joshua Beharia]

Hello,

je pense kil y a confusion car ce que tu montres n'est pas vraiment UML...
Déjà toutes tes SMachines sont fausses.
Ensuite ton modèle est biaisé car il y a différenciation entre directeur et employé. Le directeur est un rôle joué par un employé.

Ensuite, pour ton prob, il faut modéliser un system de listener avec abonnement avec certaines resposnabilités qui seront réalisé par un comportement préçis.
Ainsi tu auras une méthode "NotifierTousLesEmployers(:Notification)" qui sera réalisé par ton listener d'employés.

Oki ?

Tcho.

[Hephaistos007]

J'arrive une peu tard mais je confirme les propos de Joshua Beharia.
Le principe de communication qui semble te poser problème est en fait le pattern publish/subscribe. Suivant la conception proposé par ce pattern, un objet "directeur" possède une liste d'objets employés qu'il parcours en envoyant un message, c-a-d un appel de methode. En bref, les employés sont à l'écoute (listener) de leur directeur.

Bonne continuation.

[Joshua Beharia]

J'arrive une peu tard mais je confirme les propos de Joshua Beharia.
Le principe de communication qui semble te poser problème est en fait le pattern publish/subscribe. Suivant la conception proposé par ce pattern, un objet "directeur" possède une liste d'objets employés qu'il parcours en envoyant un message, c-a-d un appel de methode. En bref, les employés sont à l'écoute (listener) de leur directeur.

Bonne continuation.

Merçi pour tes remarques.
En tout cas, les classes seraient les suivantes: Entreprise,Entreprise_Listener et Personne.
Ensuite deux associations bidirectionnelles: Entreprise-----{Directeur}Personne
et
Entreprise-----{Salarié}Personne

Pusi une troisième unidirectionnelle:
Entreprise-----Entreprise_Listener

Et pour finir, un héritage:
Personne------|>Entreprise_Listener

C'est un premier point de vue, qui peut surmeent être améliorer mais qui mérite réflexion.

Tcho !