UML best practice: One Operation => One SD

[Geert Bellekens]

I've written down one of my best practices to model implementations of operations using sequence diagrams.
UML Best Practice: One Operation => One Sequence Diagram
Any and all comments/congratulations/insults are welcome

Geert

[sargasso]

Geert,

I can only agree 99.98% here.  The remaining 2c are based on:

* there used to be a thing called a "found message" or something.  That is where the invocation should come from.  The object / class / object / whatever that is the focal point of the diagram quite simply has no (and should not have any) idea where the message came from.  IIRC it was  a diamond?

* At the other end of the spectrum, so to speak, a class or object ought to have right to send a message to an unknown recipient (aka at the implementation level "raise an event" (which is a concept in itself that OMG seems to have difficulty understanding (along the lines of {oh, bugger, I'm down to three nesting levels}) RAISE.EVENT.NOW(condition=too_much_water, problem=no_air,severity=" " )) etc

Sadly, I recall these were things called "lost messages"  

[Geert Bellekens]

* there used to be a thing called a "found message" or something.  That is where the invocation should come from.  The object / class / object / whatever that is the focal point of the diagram quite simply has no (and should not have any) idea where the message came from.  IIRC it was  a diamond?

* At the other end of the spectrum, so to speak, a class or object ought to have right to send a message to an unknown recipient (aka at the implementation level "raise an event" (which is a concept in itself that OMG seems to have difficulty understanding (along the lines of {oh, bugger, I'm down to three nesting levels}) RAISE.EVENT.NOW(condition=too_much_water, problem=no_air,severity=" " )) etc

Sadly, I recall these were things called "lost messages"  

bruce,

I've never heard about found or lost messages, but Davide suggested on my blog to use a gate i.s.o. the first lifeline "Caller".
I just tested it, and I think this is the concept you are referring to. You can also send a message to a gate, so that could be used for your "lost message" as well.
I'm going to adjust the blogpost to use a gate i.s.o. the lifeline as it is a much more elegant solution.

Geert

[philchudley]

Lost and found messages are indicated by a message ending at or starting from a solid black ball (exactly like an initial connector on an Activity diagram).

As Geert states, Gates can be used to achieve the same thing, I always use Gates on my sequence diagram, since I cannot see any difference between Gates and lost/found messages. I am sure buried away in the OMG UML spec, there is some semantic difference between the two

Cheers

Phil

[Geert Bellekens]

I've added a new feature to the EA Navigator to navigate to the implementation of an operation. It selects the Behavior element in the project browser and opens all diagrams owned by this behavior element.
More details on my blog
or download the EA Navigator 1.2 Windows Installer directly from github.

Geert

[Dave_Bullet]

As Phil noted - I use MessageEndpoints as a "source or sink" for event driven architecture.  Handy to initiate a diagram where you don't care about who calls it (or want to terminate processing or hand off to another event).

The above is different to queue based processing where I model a queue as a type of <<message_store>> where the location of input or output is important to understanding the end to end flow of a realisation.

In the case of message end points - I create these per operation diagram (not a common re-use pair / set) as I don't want to confuse the reader thinking all messages lead to Rome.