Messages synchrones/asynchrones

bonjour

voila, après avoir fait les cas d'utilisation, je vais commencer les diagrammes de séquences ! bien que je les ai fait sur papier, j'ai du mal a discerner les messages synchrones des messages asynchrones.

si par exemple, je veux faire le diagramme pour la suppression d'un article d'un site par un responsable
les étapes sont les suivantes :
le responsable demande la suppression d'un article
le système demande le numéro de l'article
le responsable donne le numéro de l'article
le système affiche l'article
le responsable supprime l'article
le responsable valide
le système enregistre la modification

les messages dans ce cas sont synchrones ou asynchrones ?
et la réponse du système au responsable doit être une flèche en trait pointillé ?

merci pour vos réponses.

un message est synchrone si on attend la réponse (fin d'exécution) avant de passer à la suite

à part cela tes échanges ne sont pas très optimisés car il y a beaucoup d'échanges

par exemple :

• le responsable demande la suppression d'un article
• le système demande le numéro de l'article
• le responsable donne le numéro de l'article

pourquoi ne pas donner le numero de l'article lors de la demande de suppression et eviter cet aller-retour ?

non mais c'est juste histoire de détailler les étapes
le responsable va bien à un moment cliquer sur "supprimer" un article , donc c'est une demande de suppression, et suite à ça s'affichera un champs de saisie pour qu'il mette le numéro de l'article, donc c'est bien une demande du numéro de l'article.

mais bon, je peux bien sur ne pas rentrer dans les détails? est ce préférable dans ce cas ?
et sinon, synchrones ou asynchrones ? :mrgreen:

Citation:

---

le responsable va bien à un moment cliquer sur "supprimer" un article , donc c'est une demande de suppression, et suite à ça s'affichera un champs de saisie pour qu'il mette le numéro de l'article, donc c'est bien une demande du numéro de l'article.

---

C'est bien ce que bruno dit : le champs de saisie sera mieux à coté du bouton. C'est bien pour cela qu'il faut modéliser sans penser à l'implémentation. :P

Citation:

---

et sinon, synchrones ou asynchrones ?

---

A toi de décider... Typiquement le lancement d'une impression est asynchrone, la demande d'authentification d'une CB est synchrone...

dois je remplacer tout ça par :
le responsable demande à supprimer un article en fournissant le numéro de ce dernier.

Citation:

---

A toi de décider... Typiquement le lancement d'une impression est asynchrone, la demande d'authentification d'une CB est synchrone...

---

oui mais dans mon exemple, je vois pas trop, vu que y'a quand même une attente d'une réponse (l'affichage de l'article en question par exemple)
cela dit, j'ai du mal a savoir comment modéliser les messages, a quel endroit les insérer sur la bandes rectangulaires placées sur la ligne de vie de l'objet.

(ci-joint un exemple pour me faire comprendre )

Voila ce que je proposerais, en haut notre modélisation, en bas ta façon de voir, modélisée comme je la comprend.

L'acteur ne peut pas appeler de méthode sur lui même, c'est assez étrange de le modéliser (tu devrais aussi modéliser toutes ses réflexions !?)

laquelle est bonne? celle du haut ou celle du bas ?
pour l'appel de la méthode sur lui même , je me suis inspiré d'un bouquin, dans lequel sur une étude de cas, quand un superviseur faisait des modifications, ils le modélisaient de cette façon !!!

Citation:

---

laquelle est bonne? celle du haut ou celle du bas ?

---

Tout dépend ce que tu veux faire.

Celle du haut minimise les actions, mais suppose que 'lacteur connait à l'avance le n° d'article.

La seconde permet d'insérer un écran entre les deux, en ajoutant un échange système.

L'environement technique peut aussi jouer (client lourd/léger, webservices ou tout en local....)

ok
et sinon, sur la modélisation, une seule bande pour un "cas" donné ?
et si je comprend bien, la réponse du système avec une flèche pointillée ?

Citation:

---

et sinon, sur la modélisation, une seule bande pour un "cas" donné ?

---

Une meme bande <=> une même "activité"

Citation:

---

et si je comprend bien, la réponse du système avec une flèche pointillée ?

---

Les retours sont effectivement en pointillés.

si je puis me permettre, Hervé il y a quand même une erreur dans ton second diagramme, la bande de gauche est bien unique mais la bande de droite doit être découpée en deux, avec une séparation en le retour et la réception de suppr(number)

Effectivement, erreur de ma part désolé :aie: Je pensais avoir séparé les deux.

Citation:

---

Envoyé par bruno_pages

si je puis me permettre, Hervé il y a quand même une erreur dans ton second diagramme, la bande de gauche est bien unique mais la bande de droite doit être découpée en deux, avec une séparation en le retour et la réception de suppr(number)

---

doit être séparée parce qu'il y'a 2 activités? lesquelles ?

1/ L'action de réagir à la demande suppr(), soit renvoyer la liste des articles.

2/ L'action de réagir à la demande suppr(num) et d'effectivement retirer l'article de la base.

Les deux sont indépendantes potentiellement.

penses en terme d'exécution, une barre d'activité correspond au contexte d'exécution d'une fonction/opération dans une pile.