Diagrama de seqüência UML - como representar uma resposta assíncrona

Há duas perguntas aqui: 1. A inclinação da (s) seta (s) e 2. o que fazer com a ativação.

1. As setas devem ser inclinadas se você quiser representar em seu diagrama que leva tempo para a mensagem viajar de A para B ou vice-versa.
   Se você quiser apenas indicar que a mensagem é processada de forma síncrona, basta usar uma seta aberta na mensagem.

2. Quando uma mensagem (enviada de A para B) é processada de forma síncrona, a ativação de A termina assim que a mensagem é enviada e recomeça quando a resposta de B é recebida.
   Isso pressupõe que A não bloqueia enquanto aguarda a resposta, mas seria capaz de fazer algum outro processamento enquanto aguardava a resposta.

Eu costumava desenhar isso como parte do meu trabalho. Nós tínhamos um jeito de fazer as coisas. Eu não vou lhe dizer como, porque cada loja tem seu jeito de fazê-las. Eu posso provar isso com um pesquisa de imagens do Google .

Uma coisa que você notará é que quase ninguém coloca uma inclinação nas setas. Nessa metáfora, uma inclinação seria retardar não a assincronia.

O eixo y representa o tempo. Assíncrono realmente não se encaixa neste diagrama porque ser assíncrono significa que você tem seu próprio eixo. Então, qualquer coisa que você desenhe aqui é um palpite. Mas nós tentamos de qualquer maneira.

Sua linha "resposta aqui" me diz que quando B termina você espera que A ainda esteja processando e, porque você a colocou no final, termine quando B for visto responder.

Sua linha "ou aqui" me diz que quando B termina você espera que A já tenha terminado.

O mais provável é que você nem saiba o que vai acontecer. Nesses casos, a representação mais segura não é nenhuma seta de retorno. Se você tiver uma chamada de volta para A, faz mais sentido ter uma seta de 'retorno'. Realmente você tem dois fluxos diferentes de controle marchando por A nesse ponto.

Tradicionalmente, os diagramas de sequência tiveram dois trabalhos. Representar o fluxo de controle e prever o tempo de vida do objeto para que você saiba quando é seguro excluí-los. Quando o assíncrono está envolvido, a previsão do tempo de vida do objeto torna-se muito complicado.

O mais importante é que sua loja tenha uma maneira padrão de fazê-lo, para que você possa entender um ao outro. Se esse padrão sair de alguma versão de um livro UML, tanto melhor. Isso significa que você tem um livro para entregar novos funcionários. Mas não estamos na sua loja. Estamos nos programadores.

O termo assíncrono não se aplica realmente a este nível. Async descreve um evento (mensagem ou não) que acontece independentemente do fluxo principal do programa (aqui, A ou B). É um adjetivo que descreve detalhes de implementação e tempo de eventos externos relativos ao design de threading interno de um cliente ou de um servidor, e evoca estratégias para lidar com tais eventos, pois o programa principal pode estar fazendo alguma outra coisa no momento.

No nível alto, quando falamos de mensagens entre cliente e servidor ou dois servidores (e não estamos mergulhando nos detalhes de implementação interna de nenhum deles), podemos falar de mensagens, solicitações / comandos (ou seja, mensagens livremente iniciadas), e respostas. Não existe algo como enviar uma mensagem assíncrona pela web - é apenas enviar uma mensagem pela web, que é um pedido / comando ou uma resposta, se você quiser.

Primeiro, devemos nos concentrar no comportamento (há uma ou mais respostas para um determinado pedido / comando) e no tempo (quanto atraso esperamos); este é o takeaway de alto nível da interação entre A & B.

Se quisermos descrever o encadeamento interno de um ou de outro, podemos ilustrar, digamos, uma resposta recebida da ativação. No entanto, para ser claro, isso não é uma propriedade da mensagem ou da interação entre os dois, mas detalhes internos de como, neste caso, A é implementado, o que pode estar fora do tópico dependendo do que o diagrama pretende representar.