UML Sequence Diagrams

Hi,

I'm trying to find an answer to the following UML sequence diagram
problem:

C1 C2
--- ---
O |
O---- M1 ---->O
O O
O---- M2 ---->O
| O
| O
O<--- M4 -----O
O |
O |

Here is another view of the same diagram if the previous one did not
line up correctly on your screen:


C1 C2
--- ---
O |
O---- M1 ---->O
O O
O---- M2 ---->O
| O
| O
O<--- M4 -----O
O |
O |


This is the problem:

Thread C1 sends two messages to thread C2, first M1 and then M2.
As soon as thread C2 receives the M1 message it will send the message
M4 back to C1.

M2 will be sent from C1 before it checks it's incoming pipe for new
messages.
C2 will send the message M4 before before checking it's incoming pipe
for new messages after M1 and get the M2 message.

How can I illustrate that M2 is sent before M4 is received in C1 and
at the same time M2 is received after M4 is sent in C2?

Thanks for your help,
Kjell

kjell@cablescan.com escribió:
> Hi,
>
> I'm trying to find an answer to the following UML sequence diagram
> problem:
>
> C1 C2
> --- ---
> O |
> O---- M1 ---->O
> O O
> O---- M2 ---->O
> | O
> | O
> O<--- M4 -----O
> O |
> O |
>
> Here is another view of the same diagram if the previous one did not
> line up correctly on your screen:
>
>
> C1 C2
> --- ---
> O |
> O---- M1 ---->O
> O O
> O---- M2 ---->O
> | O
> | O
> O<--- M4 -----O
> O |
> O |
>
>
> This is the problem:
>
> Thread C1 sends two messages to thread C2, first M1 and then M2.
> As soon as thread C2 receives the M1 message it will send the message
> M4 back to C1.
C2 reacts to M1 only, M2 has no impact on the Sequence you are
describing, right?
>
> M2 will be sent from C1 before it checks it's incoming pipe for new
> messages.
> C2 will send the message M4 before before checking it's incoming pipe
> for new messages after M1 and get the M2 message.
>
> How can I illustrate that M2 is sent before M4 is received in C1 and
> at the same time M2 is received after M4 is sent in C2?
>
> Thanks for your help,
> Kjell
To my mind, M2 is irrelevant in this sequence diagram, if it has no
impact on the outcome. Are you sure a sequence diagram makes sense here?
What you could do is to give the pipes a lifeline of their own, that way
you can present time, objects are "waiting" in the pipe.
I don't know if that is considered best practice in UML, but if it gets
the message across...

saludos
Stefan

Responding to Kjell...

> I'm trying to find an answer to the following UML sequence diagram
> problem:
>
> C1 C2
> --- ---
> O |
> O---- M1 ---->O
> O O
> O---- M2 ---->O
> | O
> | O
> O<--- M4 -----O
> O |
> O |
>

> Thread C1 sends two messages to thread C2, first M1 and then M2.
> As soon as thread C2 receives the M1 message it will send the message
> M4 back to C1.
>
> M2 will be sent from C1 before it checks it's incoming pipe for new
> messages.
> C2 will send the message M4 before before checking it's incoming pipe
> for new messages after M1 and get the M2 message.
>
> How can I illustrate that M2 is sent before M4 is received in C1 and
> at the same time M2 is received after M4 is sent in C2?

Draw the M2 line on a diagonal so that it is initiated above the M4 line
but arrives at C2 below the M4 line.

However, that is really kind of cheating. The problem is that you are
describing asynchronous processing while the Sequence Diagram is
designed for synchronous processing. (A Collaboration Diagram is better
suited to asynchronous processing.) There are inherent delays in the
processing, both for generating M2 and M4 (e.g., the C1 thread might be
paused before M2 is generated, allowing M4 to arrive before M2 is
generated) and in the pipe queues (e.g., C1 may check the incoming pipe
before generating M2). IOW, there are potentially arbitrary delays
between when messages are generated and when they are consumed, which is
the hallmark of asynchronous processing.

[Note that if checking the incoming pipes is done in the threads at a
fixed point relative to when M2 and M4 are generated, then you need more
swimlanes because the pipe queues need to be explicitly defined within
the sequence if you want to represent this synchronously:

C1 C1Pipe C2 C2Pipe
| | M1 | |
|------------------------------------->|
| | | |
| | M2 | |
|------------------------------------->|
| | | |
| | | Poll M1 |
| | |----------->|
| | | |
| | | M1a |
| | |<-----------|
| | M4 | |
| |<-----------| |
| Poll M4 | | Poll M2 |
|----------->| |----------->|
| | | |
| M4a | | M2a |
|<-----------| |<-----------|
| | | |

Note that this essentially serializes the processing around the input
pipes, which becomes queues. (C2 can poll for M2 before or after
generating M4.)]



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On Aug 22, 5:15*pm, Stefan Nolde <stefan.no...@lazos.cl> wrote:
> kj...@cablescan.com escribió:
>
> > Hi,
>
> > I'm trying to find an answer to the following UML sequence diagram
> > problem:
>
> > C1 * * * * * *C2
> > --- * * * * * ---
> > *O * * * * * * |
> > *O---- M1 ---->O
> > *O * * * * * * O
> > *O---- M2 ---->O
> > *| * * * * * * O
> > *| * * * * * * O
> > *O<--- M4 -----O
> > *O * * * * * * |
> > *O * * * * * * |
>
> > Here is another view of the same diagram if the previous one did not
> > line up correctly on your screen:
>
> > C1 * * * * * * *C2
> > *--- * * * * * * * ---
> > *O * * * * * * * * |
> > *O---- M1 ---->O
> > *O * * * * * * * * O
> > *O---- M2 ---->O
> > *| * * * * * * * * * O
> > *| * * * * * * * * * O
> > *O<--- M4 -----O
> > *O * * * * * * * * |
> > *O * * * * * * * * |
>
> > This is the problem:
>
> > Thread C1 sends two messages to thread C2, first M1 and then M2.
> > As soon as thread C2 receives the M1 message it will send the message
> > M4 back to C1.
>
> C2 reacts to M1 only, M2 has no impact on the Sequence you are
> describing, right?
>
> > M2 will be sent from C1 before it checks it's incoming pipe for new
> > messages.
> > C2 will send the message M4 before before checking it's incoming pipe
> > for new messages after M1 and get the M2 message.
>
> > How can I illustrate that M2 is sent before M4 is received in C1 and
> > at the same time M2 is received after M4 is sent in C2?
>
> > Thanks for your help,
> > Kjell
>
> To my mind, M2 is irrelevant in this sequence diagram, if it has no
> impact on the outcome. Are you sure a sequence diagram makes sense here?
> What you could do is to give the pipes a lifeline of their own, that way
> you can present time, objects are "waiting" in the pipe.
> I don't know if that is considered best practice in UML, but if it gets
> the message across...
>
> saludos
> Stefan

Message M1 will trigger C2 to do something, in this case send message
M4, while the message M2 is more of a status message. M2 will trigger
C2 to update a status variable but not to send any messages.

On Aug 23, 8:38*am, "H. S. Lahman" <h...@pathfindermda.com> wrote:
> Responding to Kjell...
>
>
>
> > I'm trying to find an answer to the following UML sequence diagram
> > problem:
>
> > C1 * * * * * *C2
> > --- * * * * * ---
> > *O * * * * * * |
> > *O---- M1 ---->O
> > *O * * * * * * O
> > *O---- M2 ---->O
> > *| * * * * * * O
> > *| * * * * * * O
> > *O<--- M4 -----O
> > *O * * * * * * |
> > *O * * * * * * |
>
> > Thread C1 sends two messages to thread C2, first M1 and then M2.
> > As soon as thread C2 receives the M1 message it will send the message
> > M4 back to C1.
>
> > M2 will be sent from C1 before it checks it's incoming pipe for new
> > messages.
> > C2 will send the message M4 before before checking it's incoming pipe
> > for new messages after M1 and get the M2 message.
>
> > How can I illustrate that M2 is sent before M4 is received in C1 and
> > at the same time M2 is received after M4 is sent in C2?
>
> Draw the M2 line on a diagonal so that it is initiated above the M4 line
> but arrives at C2 below the M4 line.
>
> However, that is really kind of cheating. The problem is that you are
> describing asynchronous processing while the Sequence Diagram is
> designed for synchronous processing. (A Collaboration Diagram is better
> suited to asynchronous processing.) There are inherent delays in the
> processing, both for generating M2 and M4 (e.g., the C1 thread might be
> paused before M2 is generated, allowing M4 to arrive before M2 is
> generated) and in the pipe queues (e.g., C1 may check the incoming pipe
> before generating M2). IOW, there are potentially arbitrary delays
> between when messages are generated and when they are consumed, which is
> the hallmark of asynchronous processing.
>
> [Note that if checking the incoming pipes is done in the threads at a
> fixed point relative to when M2 and M4 are generated, then you need more
> swimlanes because the pipe queues need to be explicitly defined within
> the sequence if you want to represent this synchronously:
>
> C1 * * * * C1Pipe * * * * C2 * * * * C2Pipe
> * | * * * * * *| * *M1 * * *| * * * * **|
> * |------------------------------------->|
> * | * * * * * *| * * * * * *| * * * * * *|
> * | * * * * * *| * *M2 * * *| * * * * **|
> * |------------------------------------->|
> * | * * * * * *| * * * * * *| * * * * * *|
> * | * * * * * *| * * * * * *| *Poll M1 * |
> * | * * * * * *| * * * * * *|----------->|
> * | * * * * * *| * * * * * *| * * * * * *|
> * | * * * * * *| * * * * * *| * M1a * * *|
> * | * * * * * *| * * * * * *|<-----------|
> * | * * * * * *| * *M4 * * *| * * * * **|
> * | * * * * * *|<-----------| * * * * * *|
> * | *Poll M4 * | * * * * * *| *Poll M2 * |
> * |----------->| * * * * * *|----------->|
> * | * * * * * *| * * * * * *| * * * * * *|
> * | * *M4a * * | * * * * * *| * *M2a * * |
> * |<-----------| * * * * * *|<-----------|
> * | * * * * * *| * * * * * *| * * * * * *|
>
> Note that this essentially serializes the processing around the input
> pipes, which becomes queues. (C2 can poll for M2 before or after
> generating M4.)]
>
> --
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> h...@pathfindermda.com
> Pathfinder Solutionshttp://www.pathfindermda.com
> blog:http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". *Email
> i...@pathfindermda.com for your copy.
> Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH

Thanks! Very interesting approach. I suppose that it will make the
diagram a little bit more complicated but it will definitely show the
timing correctly.