Ci sono due domande qui: 1. L'inclinazione della freccia (s) e 2. cosa fare con l'attivazione.
Le frecce dovrebbero essere inclinate se vuoi rappresentare nel tuo diagramma che ci vuole del tempo perché il messaggio passi da A a B o viceversa.
Se vuoi solo indicare che il messaggio viene elaborato a-sincrono, è sufficiente utilizzare una freccia aperta sul messaggio.
Quando un messaggio (inviato da A a B) viene elaborato a-sincrono, l'attivazione di A termina non appena il messaggio è stato inviato e ricomincia quando viene ricevuta la risposta da B.
Questo presuppone che A non blocchi durante l'attesa della risposta, ma potrebbe eseguire qualche altra elaborazione in attesa della risposta.
Ero solito disegnarli come parte del mio lavoro. Avevamo un modo fisso in cui li abbiamo fatti. Non ho intenzione di dirti come, perché ogni negozio di dang ha il proprio modo di farli. Posso provarlo con un ricerca immagini google .
Una cosa che noterai è che quasi nessuno mette un'inclinazione sulle frecce. In questa metafora un'inclinazione non sarebbe asincronica.
L'asse y rappresenta il tempo. Async non si adatta veramente a questo diagramma perché essere asincroni significa che hai il tuo proprio dannato asse y. Quindi tutto ciò che disegni qui è una supposizione. Ma ci proviamo lo stesso.
La tua linea "risposta qui" mi dice che quando B termina ti aspetti che A sia ancora in elaborazione e, poiché lo metti a posto alla fine, termina quando vede B rispondere.
La tua linea "o qui" mi dice che quando B termina ti aspetti che A sia già terminato.
Molto probabilmente non sai nemmeno cosa succederà. In questi casi la rappresentazione più sicura non è affatto una freccia di ritorno. Se hai una chiamata di ritorno a A ha più senso avere una freccia di 'ritorno'. In realtà hai due diversi flussi di controllo che attraversano A in quel punto.
Tradizionalmente i diagrammi di sequenza hanno avuto due lavori. Per rappresentare il flusso di controllo e prevedere la durata dell'oggetto in modo da sapere quando è sicuro eliminarli. Quando è implicata la sincronizzazione asincrona, la modalità di vita dell'oggetto diventa molto complicata.
La cosa più importante è che il tuo negozio abbia un modo standard per farlo in modo che tu possa capirti. Se quello standard esce da qualche versione di un libro UML tanto meglio. Ciò significa che hai un libro da consegnare ai nuovi dipendenti. Ma non siamo nel tuo negozio. Siamo su programmatori.
Il termine async non si applica realmente a questo livello. Async descrive un evento (messaggio o altro) che accade indipendentemente dal flusso principale del programma (qui, A o B). È un aggettivo che descrive i dettagli di implementazione e i tempi degli eventi esterni relativi al design di threading interno di un client o di un server ed evoca strategie per gestire tali eventi poiché il programma principale potrebbe fare qualcos'altro al momento.
Al livello elevato quando si parla di messaggi tra client e server o due server (e non ci stiamo immergendo nei dettagli di implementazione interni di uno dei due) possiamo parlare di messaggi, richieste / comandi in un modo (cioè messaggi liberamente avviati), e risposte Non esiste una cosa come inviare un messaggio asincrono sul web - è solo l'invio di un messaggio sul web, che è una richiesta / comando o una risposta, se lo desideri.
In primo luogo, dovremmo concentrarci sul comportamento (c'è una o più risposte per una data richiesta / comando) e sui tempi (quanto ritardo ci aspettiamo); questo è il takeaway di alto livello dell'interazione tra A & B.
Se vogliamo descrivere il threading interno dell'uno o dell'altro, possiamo illustrare, per esempio, una risposta ricevuta dall'attivazione. Tuttavia, per essere chiari, questa non è una proprietà del messaggio o dell'interazione tra i due, ma piuttosto un dettaglio interno di come A, in questo caso, è implementato, che potrebbe essere fuori tema a seconda di ciò che il diagramma intende rappresentare.
Leggi altre domande sui tag uml sequence-diagram
