6

I want to model an asynchronous request-response message exchange in UML.

The request is sent from a client to a server. The server responses asynchronously.

This can be modelled in a component model in two ways:

Option 1

Option 1

Request and response are two different interfaces with one method each. The server provides the request interface while the client provides the reponse interface. The interfaces are required vice versa. In UML I would model the server and the client as components having one port each. Both ports expose two interfaces: a provided one and a required one which are linked from client to server (request) and from server to client (response).

Option 2

Option 2

Request and response is one interface with one method. The response is simply the return value of this method. The server provides and the client requires this interface. The message exchange is modelled as link from the client to the server.

I think option (1) is more appropriated for asynchronous exchanges while option (2) is the preferred way for synchronous ones. However, making such a distinction would expose a detail in the component model which actually belongs to the behavioural diagrams.

  • Is there any standard or "best practice" to model an asynchronous message exchange in component models?
  • If option (2) is the "right" way to do it: how should one specifiy that the client must comply with an interface contract in order to receive a response?
Improve this question
10
  • IMO, unless you are going to jump through all the hoops to attempt to create executable models then your diagram is supposed to help explain how the system works. Thus, it seems obvious to me that initiating commands and their responses are most easily understood when in the same diagram. How you implement that in code is another matter entirely which depends on your architectural design. A single method call with the response as the result means the caller is going to block. This may or may not be desirable in your system.
    – Dunk
    Commented Oct 28, 2015 at 20:12
  • @Dunk I added two UML diagrams to illustrate my question: it is within one diagram
    – Claude
    Commented Oct 29, 2015 at 6:44
  • I don't think this changes the edvice though, unless you are trying to produce an executable model then it only depends on what you want the diagram to show. Consider why are you producing this diagram in the first place? who is it for? what inormation do they want from it?
    – jk.
    Commented Oct 29, 2015 at 8:31
  • I can't say that I've used the component model for these types of diagrams. And in looking at the diagrams, I can say that I never will. Where's the value over sequence diagrams? You are eventually going to create a sequence diagram covering the same information. It seems like double work to me. What am I missing? Anyways, I use option 1 in my sequence diagrams.
    – Dunk
    Commented Oct 29, 2015 at 15:55
  • @Dunk the diagram is a simplified view of course. Usually there are lots of components and the component diagram depicts the structural view of the systems. Sequence diagrams blow up with far less components and depict the behaviour of the system. Both diagrams have a different goal and a right on their own, IMHO.
    – Claude
    Commented Oct 30, 2015 at 12:54

1 Answer 1

Reset to default
3

I believe you are correct in the assessment that option 2 is better for synchronous messages and option 1 for asynchronous messages.

By their very nature asynchronous messaging schemes (even if it is solicited) are more complicated to model. Option 1 would be the better option to model the messaging you describe.

I appreciate your concern that using option 1 would include a fair level of detail that may be too much for the diagram in question.

You could model a custom relationship or association (named appropriately, e.g.: <<CustomRqRs>>) and use that to link the components. This simplifies the diagram, better describes the interaction and offers better modelling of the message and response itself.

When modelling it is always important to bear in mind that it is primarily there to communicate intent; design, usage, possible implementation, function etc. Simpler is almost always better. Model it accurately, model it well, but keep it simple.

Improve this answer
1
  • 1
    Thanks to your answer I resolved this issue by getting rid of the exposed interfaces. Instead of I linked both ports with a bidirectional link.
    – Claude
    Commented Nov 2, 2015 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.