UML: se uno scambio di messaggi di risposta alle richieste asincroni dovesse essere modellato come due porte / interfacce o uno

Question

UML: se uno scambio di messaggi di risposta alle richieste asincroni dovesse essere modellato come due porte / interfacce o uno

Naviga le tue risposte

#1 da (2 voti)

5

Voglio modellare uno scambio di messaggi di richiesta-risposta asincrono in UML.

La richiesta viene inviata da un client a un server. Il server risponde in modo asincrono.

Questo può essere modellato in un modello di componente in due modi:

Opzione 1

Larichiestaelarispostasonodueinterfaccedifferenticonunmetodociascuno.Ilserverforniscel'interfacciadirichiestamentreilclientforniscel'interfacciadirisposta.Leinterfaccesonorichiesteviceversa.InUMLmodellereiilservereilclientcomecomponenticonunaportaciascuno.Entrambeleporteespongonodueinterfacce:unafornitaeunarichiestachesonocollegatedaclientaserver(richiesta)edaserveraclient(risposta).

Opzione2

Larichiestaelarispostasonoun'interfacciaconunmetodo.Larispostaèsemplicementeilvalorediritornodiquestometodo.Ilserverfornisceeilclientrichiedequestainterfaccia.Loscambiodimessaggièmodellatocomecollegamentodalclientalserver.

Pensochel'opzione(1)siapiùappropriatapergliscambiasincronimentrel'opzione(2)èilmodopreferitoperquellisincroni.Tuttavia,fareunadistinzionedelgenereesporrebbeundettaglionelmodellodelcomponentecheeffettivamenteappartieneaidiagrammicomportamentali.

Esisteunostandardouna"best practice" per modellare uno scambio di messaggi asincroni nei modelli di componenti?
Se l'opzione (2) è il modo "giusto" per farlo: come si dovrebbe specificare che il cliente deve rispettare un contratto di interfaccia per ricevere una risposta?

interfaces asynchronous-programming modeling uml

posta Claude 28.10.2015 - 16:29

fonte

1 risposta

Leggi altre domande sui tag interfaces asynchronous-programming modeling uml

Come implementare efficienti query di dati con microservizi eterogenei? JavaScript esteso vs mixin

score 2 · Accepted Answer

Credo che tu abbia ragione nella valutazione che l'opzione 2 è migliore per i messaggi sincroni e l'opzione 1 per i messaggi asincroni.

Per loro stessa natura, gli schemi di messaggistica asincrona (anche se richiesto) sono più complicati da modellare. L'opzione 1 sarebbe l'opzione migliore per modellare la messaggistica che descrivi.

Apprezzo la tua preoccupazione che l'utilizzo dell'opzione 1 includa un livello di dettaglio equo che potrebbe essere eccessivo per il diagramma in questione.

È possibile modellare una relazione o un'associazione personalizzata (denominata in modo appropriato, ad esempio <<CustomRqRs>> ) e utilizzarla per collegare i componenti. Questo semplifica il diagramma, descrive meglio l'interazione e offre una migliore modellazione del messaggio e della risposta stessa.

Quando si modella è sempre importante ricordare che è principalmente lì a comunicare l'intento; design, utilizzo, possibile implementazione, funzione, ecc. Più semplice è quasi sempre meglio . Modella accuratamente, modella bene, ma mantienilo semplice.