Message crossing on sequence diagrams

[ocroquette]

Hi

I am trying to represent message crossing on sequence diagrams.
What I want as a result, is the following:



I have great difficulties with EA, since it always take control of the length of my activation regions, and I just can't achieve it. If I completely deactivate the activations for the diagram, the problem is solved of course.

Is the diagram below actually UML compliant?
Is there a way to achieve this with EA?

Thanks!

[thomaskilian]

Hm. What is the semantic of this? Your left object is passing a message to the right one while it in the same moment accepts another one from the same partner. Now they continue concurrently repeating this step. As you depicted it, it does not make sense to me. You probably have some kind of synchronisation point where the two object interchange information, right? In that case you have two messages. One going from left to right and a 2nd a bit later in the other direction. Or vice versa.

[ocroquette]

It's a system where the 2 classes are desynchronized, ie. they run in parallel and independently. They both handle asynchronous messages, and use for that services from each other.

I have 2 other diagrams showing the simple cases, where only one of them gets something to handle.

This diagram on the other end shall show what happens when they both get a request at the same time.

[thomaskilian]

So when they run single treaded each object can either work on a task of its own OR serve another task. I think you should adorn this with a state diagram. Especially the message interchange seems to be tricky. There must be some scheduler that knows "I currently serve another task but also wait for response from someone I called". You should make this clear. Else your diagram opens more questions than it could clarify.

[Bokkie]

These kind of diagrams/situations are typically found in telecom / protocol situations e.g. TCP/IP, SIP etc... You will have to consider state of the applicable classes/objects.

Sometimes I think the UML guys are too much focussed at business/financial/web applications and forget us, poor telecommies and embedded people...

[ocroquette]

These kind of diagrams/situations are typically found in telecom / protocol situations e.g. TCP/IP, SIP etc...

Exactly

You will have to consider state of the applicable classes/objects.

While I understand that state machines will help the readers to understand how the requests are handled internally, it won't show the crossing of messages in the corner cases I am interested in :-/
Or did I understand both of you wrong?

Sometimes I think the UML guys are too much focussed at business/financial/web applications and forget us, poor telecommies and embedded people...

Yep, it's not as universal as advertised, especially the tools!

By the way, I tested with Rhapsody, and I can get the result I want. It lets more freedom about the position of the elements.

[SF_lt]

quite opposite in fact

by showing not horizontal message passing you state, that this passing takes time and this is important for you

also, I would use communication diagram for asynchronous message exchange

[Eve]

Try setting the 'duration constraint' from the 'timing details' option in the context menu.

This allows for non-horizontal messages.

[Bokkie]

Nice feature! Didn't know that was possible with EA.

In my understanding the purpose of the non-horizontals is to indicate that the transport of the message takes time and cannot be neglected. This imposes special requirements for the statemachines (clientside&serverside) that handle the protocol. E.g. the ability to deal with retransmissions etc... Take a look at the four statemachines defined as in the SIP specs(rfc3261) (if you savvy ascii art ).

[ocroquette]

Try setting the 'duration constraint' from the 'timing details' option in the context menu.

This allows for non-horizontal messages.

Thanks, I can already do that. Where I have problems is in the repeated crossing of messages. EA imposes too much constraints on the activation regions. Try it, you will see better than I can explain

[Eve]

Then I suggest sending an email to sparx support detailing exactly what you believe is wrong.

[ocroquette]

Hi all

I have filled a bug report.
The support confirmed the limitation and recommended to deactivate the actions completely "for now".

I hope we will see some improvements in the next versions.

[ocroquette]

FYI: the support told me this would be improved in the next "update".

[«Midnight»]

Do you mean that you've just heard that recently?

[ocroquette]

Yes.