Timeline for UML: Should an asynchronous request-response message exchange be modelled as two ports/interfaces or one
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 9, 2016 at 20:21 | history | edited | Tulains Córdova | CC BY-SA 3.0 |
added 6 characters in body
|
| Nov 4, 2015 at 8:14 | comment | added | Claude | @Dunk (Part 4) "Useful" ... in some projects component diagrams are simply required and you have to provide one. This diagram must be consistent with all other diagrams ... and in an asynchronous message exchange the client must provide an interface. However, see the accepted answer for a resolution. Hope this helps. | |
| Nov 4, 2015 at 8:06 | comment | added | Claude |
@Dunk (Part 3) Example code for a synchronous request: interface Server { public int request(int x) }. Example code for an asynchronous request: interface Callback { public void response(int x) }; interface Server { public void request(int x, Callback c) }.
|
|
| Nov 4, 2015 at 8:02 | comment | added | Claude | @Dunk (Part2) A request (actually a behaviour) needs an established structural relation between client (C) and server (S). S must provide an interface which is required by C (s. option 2). In a synchronous request S simply returns the result. As a software component it doesn't need a reference to C. However, if the request is asynchronous (e.g. using an enterprise service bus) S must know (at least temporary) to whom it should send the response (Callback Interface). S requires an interface and C provides it. It's all about structure, not behaviour. The behaviour must be specified separately. | |
| Nov 4, 2015 at 7:53 | comment | added | Claude | @Dunk (Part1) Let me explain why I think the above diagrams might be helpful. A component (CMP) diagram displays the structural relations between CMPs. A CMP might have ports which help too to vizualize realations especially if they are repeated in a composition structure diagram displaying the inner structure of the CMP. A port may provide and/or require interfaces. For an example see http://www.uml-diagrams.org/component-diagrams-reference.html. Especially look for the "ball and socket" notation. TBC | |
| Nov 3, 2015 at 22:50 | comment | added | Dunk | @Claude - I don't want to sound antagonistic because I am not trying to be. I am truly trying to understand your thinking because maybe I will learn something. With that said: I see how the different diagrams could have different goals but with the example, what useful information do you hope to convey with the component diagram that wouldn't be more usefully conveyed in a sequence, collaboration or even activity diagram? By "useful" I am referring to being of benefit to the designer/programmer. (ie. the people that will actually use the diagrams) | |
| Nov 2, 2015 at 15:06 | vote | accept | Claude | ||
| Oct 30, 2015 at 14:52 | history | tweeted | twitter.com/StackProgrammer/status/660107072051236864 | ||
| Oct 30, 2015 at 12:54 | comment | added | Claude | @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. | |
| Oct 29, 2015 at 15:55 | comment | added | Dunk | 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. | |
| Oct 29, 2015 at 8:31 | comment | added | jk. | 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? | |
| Oct 29, 2015 at 8:05 | answer | added | Niall | timeline score: 3 | |
| Oct 29, 2015 at 6:44 | comment | added | Claude | @Dunk I added two UML diagrams to illustrate my question: it is within one diagram | |
| Oct 29, 2015 at 6:41 | history | edited | Claude | CC BY-SA 3.0 |
spelling correction
|
| Oct 28, 2015 at 20:12 | comment | added | Dunk | 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. | |
| Oct 28, 2015 at 15:31 | review | First posts | |||
| Oct 30, 2015 at 17:31 | |||||
| Oct 28, 2015 at 15:29 | history | asked | Claude | CC BY-SA 3.0 |