UML: Uma troca de mensagem de solicitação-resposta assíncrona deve ser modelada como duas portas / interfaces ou uma

5

Eu quero modelar uma troca de mensagem de solicitação-resposta assíncrona na UML.

A solicitação é enviada de um cliente para um servidor. As respostas do servidor de forma assíncrona.

Isso pode ser modelado em um modelo de componente de duas maneiras:

Opção 1

Solicitaçãoerespostasãoduasinterfacesdiferentescomummétodocada.Oservidorforneceainterfacedesolicitaçãoenquantooclienteforneceainterfacederesposta.Asinterfacessãonecessáriasevice-versa.NaUMLeumodelariaoservidoreoclientecomocomponentescomumaportacada.Ambasasportasexpõemduasinterfaces:umafornecidaeumanecessária,quesãovinculadasdeclienteparaservidor(solicitação)edeservidorparacliente(resposta).

Opção2

Solicitaçãoerespostaéumainterfacecomummétodo.Arespostaésimplesmenteovalorderetornodessemétodo.Oservidorforneceeoclienterequeressainterface.Atrocademensagensémodeladacomolinkdoclienteparaoservidor.

Euachoqueaopção(1)émaisapropriadaparatrocasassíncronas,enquantoaopção(2)éamaneirapreferidaparaassíncronas.Entretanto,fazertaldistinçãoexporiaumdetalhenomodelodecomponentequerealmentepertenceaosdiagramascomportamentais.

  • Existealgumpadrãoou"melhor prática" para modelar uma troca de mensagens assíncrona em modelos de componentes?
  • Se a opção (2) é a maneira "certa" de fazê-lo: como alguém deve especificar que o cliente deve cumprir um contrato de interface para receber uma resposta?
por Claude 28.10.2015 / 16:29
fonte

1 resposta

2

Acredito que você esteja correto na avaliação de que a opção 2 é melhor para mensagens síncronas e a opção 1 para mensagens assíncronas.

Por sua própria natureza, os esquemas de mensagens assíncronos (mesmo que sejam solicitados) são mais complicados de modelar. A opção 1 seria a melhor opção para modelar as mensagens que você descreve.

Agradeço sua preocupação de que o uso da opção 1 incluiria um nível razoável de detalhes que pode ser demais para o diagrama em questão.

Você pode modelar um relacionamento ou uma associação personalizada (nomeado adequadamente, por exemplo, <<CustomRqRs>> ) e usá-lo para vincular os componentes. Isso simplifica o diagrama, descreve melhor a interação e oferece melhor modelagem da mensagem e da própria resposta.

Ao modelar, é sempre importante ter em mente que está principalmente lá para comunicar a intenção; design, uso, implementação possível, função etc. O mais simples é quase sempre melhor . Modele-o com precisão, modele-o bem, mas mantenha-o simples.

    
por 29.10.2015 / 09:05
fonte