Discussion :

[riddickk]

1)Quelle la différence entre un signal et un appel de méthode asynchrone sachant que ce sont tout deux des messages qui peuvent déclencher l’exécution d’activités associées à un objet? Cela peut être par exemple l’exécution d’une machine à états pour un signal, une méthode pour un appel.

2) quelle est la différence entre le déroulement d'une machine à états pour un objet donné et l'exécution d'une méthode pour un même objet ?
De plus dans un diagramme à état, une transition peut être modélisée par un signal ou une opération.

3)Un signal est défini comme un message asynchrone et peut contenir des attributs (BroadcastSignalAction p 241, SendSignalAction p 282; Reception, Signal p 448 à 451et BehavioredClassifier p 434 de la doc officielle de l'omg sur UML version 2.2). Un appel de méthode est défini comme un message pouvant être asynchrone ou synchrone déclenchant une suite d'opération contenu dans une méthode de l'objet (CallOperationAction p 245 ,CallEvent p436 de la doc officielle de l'omg sur UML version 2.2) .

D'après ce que j'ai compris on peut imposer des contraintes temps réels à tous les messages (signal ou appel de méthode).Pour être reçu par l'objet cible, un signal doit être déclaré dans son interface. Le signal étant de nature asynchrone il est stocké dans une file, l'exécution d'une suite d'opérations peut se faire de manière immédiate ou différée suivant l'état de la file qui dépend du contexte du système.A la réception du signal, une suite d'action est effectué mais la transition entre ces actions peut nécessiter la réception de nouveaux messages.

Un appel de méthode nécessite que l'objet cible possède cette méthode, c'est à dire l'aptitude d'exécuter une suite d'opérations définies. La transition entre ces opérations ne nécessite pas la réception de messages mais peut être l'appel de méthode de ce même objet ou d'objets différents. Un appel de méthode peut être synchrone ou asynchrone. Synchrone signifie que l'objet appelant est bloqué tant que l'objet cible n'a pas terminé l'exécution de cette méthode associé à un résultat retourné à l'objet appelant.
Asynchrone signifie que l'objet appelant n' a pas besoin d'attendre la fin de l'exécution de la méthode de l'objet cible pour continuer ses activités. Comment se fait la prise en compte différée d'une méthode quel est le mécanisme associé, est le même que celui des messages?

En conclusion, qu'est ce qui différencie fondamentalement, l'envoi d'un message qui provoque une suite d'actions de l'appel asynchrone d'une méthode?

[bruno_pages]

Bonjour,

Déjà il faut bien comprendre qu'UML ne spécifie pas comment les différents services sont implémentés, donc rien n'est dit par exemple sur la façon d'implémenter un appel d'opération asynchrone, ni même synchrone d'ailleurs.

l'appel d'une opération est l'émission d'un signal sont deux choses très différentes mettant en jeu deux mécanismes très différents d'exécution

• dans le premier cas on spécifie à la fois le comportement à exécuter (l'opération) et le 'récepteur'.
• dans le second cas on émet juste un signal donné, on ne sait ni ce qui ce passera ensuite (peut être rien d'ailleurs), ni qui sont les 'récepteurs' (un ou plusieurs).

[riddickk]

Je vous remercie pour votre réponse.
Comment peut se faire la modélisation de la communication entre 2 objets lorsque la spécification ne précise pas explicitement l'appel de méthode ou l'émission d'un signal, elle précise seulement que les 2 objets doivent communiquer entre eux?
A mon avis, elle peut se faire par l'émission d'un signal et d'une machine à état qui indique comment doit se comporter l'objet suite à la réception du signal ou par l'appel d'une méthode qui indique les instructions à exécuter pour le traitement de la communication. Je voudrais savoir:
1) quel est le bénéfice d'utiliser un appel de méthode, plutôt qu' un message ou l'inverse?
Que l'on connaisse ou pas le récepteur du signal, lorsque l'objet cible reçoit le message et qu'il se reconnait comme récepteur grâce à un attribut du message,il doit se comporter d'une certaine manière. Lorsque l'on connaît le récepteur et que la méthode que l'on désire appelée est implémentée, alors on s'adresse directement à l'objet cible pour effectuer une opération. en fin de compte, est ce que le résultat n'est pas le même?
Je ne vois pas le bénéfice d'utiliser un message, si ce n'est de gagner du temps lors de la communication entre 2 objets.
2) Quelle est la différence entre une machine à états qui s'exécute à la réception d'un signal et la suite d'instructions effectuées par l'appel d'une méthode.Est ce la complexité des instructions (complexité plus grande pour l'appel de méthode? Ou me tromperai je sur toute la ligne?
3) Quelle est la différence entre l'appel d'une méthode synchrone et l'appel d'une méthode asynchrone par un objet sur lui même?

[bruno_pages]

Comment peut se faire la modélisation de la communication entre 2 objets lorsque la spécification ne précise pas explicitement l'appel de méthode ou l'émission d'un signal, elle précise seulement que les 2 objets doivent communiquer entre eux?

attention a ne pas trop caricaturer ma réponse ... qui n'a peut être pas été assez claire ?

ne pas dire comment implémenter quelque chose ne signifie pas ne rien dire

A mon avis, elle peut se faire par l'émission d'un signal et d'une machine à état ...

par exemple, mais pas forcément, recevoir un signal ne veut pas impérativement dire que le récepteur change d'état (ou même qu'il ai des états)

1) quel est le bénéfice d'utiliser un appel de méthode, plutôt qu' un message ou l'inverse?

le 'message' représente le cas général, l'appel d'une opération est un sous cas

Que l'on connaisse ou pas le récepteur du signal, lorsque l'objet cible reçoit le message et qu'il se reconnait comme récepteur grâce à un attribut du message,il doit se comporter d'une certaine manière. Lorsque l'on connaît le récepteur et que la méthode que l'on désire appelée est implémentée, alors on s'adresse directement à l'objet cible pour effectuer une opération. en fin de compte, est ce que le résultat n'est pas le même?

ce sont quand même deux modes de fonctionnement très très différents, c'est un peu comme si vous disiez qu'utiliser des machines à états ou programmer 'classiquement' revient au même, ou que programmer en C++ ou en Prolog revient au même, etc

Je ne vois pas le bénéfice d'utiliser un message, si ce n'est de gagner du temps lors de la communication entre 2 objets.

ce n'est pas cela, une implémentation de la réception synchrone d'un message spécifiant un appel d'opération est bien évidemment l'appel de cette opération; par contre dans le cas d'un message asynchrone ce n'est pas aussi direct

2) Quelle est la différence entre une machine à états qui s'exécute à la réception d'un signal et la suite d'instructions effectuées par l'appel d'une méthode.Est ce la complexité des instructions (complexité plus grande pour l'appel de méthode? Ou me tromperai je sur toute la ligne?

à la fin on exécute toujours quelque chose, mais ce sont donc deux modes de fonctionnement très différents

3) Quelle est la différence entre l'appel d'une méthode synchrone et l'appel d'une méthode asynchrone par un objet sur lui même?

le fait que le récepteur et l'émetteur soient ou non égaux ne change pas grand chose à l'affaire, mais le mieux pour comprendre la différence est sans doute que vous tentiez d'implémenter un appel asynchrone

[riddickk]

Bonjour, en ce moment je n'ai pas trop le temps de me connecter au forum mais je voulais vous remercier d'avoir pris le temps de répondre à mes questions et d'avoir détaillé les réponses.