parallelism in sequence diagrams?

[Scott Lindner]

I have a desire to illustrate parallelism in some sequence diagrams.  When I try to do this EA shifts messages of other things around so I cannot get the illustration of parallelism in the diagram.  It also breaks the activation boxes.

Is there a way to illustrate parallelism in a sequence diagram with EA or is it inappropriate for parallelism to be in a sequence diagram?

Thanks for any help on this.

Cheers,
Scott

[Tjerk]

In UML1.x paralel messages were not allowed or at least could not be modelled well. In UML 2.0 you should use a fragment with the keyword "par". Look at the OMG UML specs or use Zicom Mentor for more details.

[Scott Lindner]

I was reading up on that very thing yesterday but I don't understand how to do it in EA.  Are there any examples that you could point me to?

[Tjerk]

You should be able to create a fragment in a sequence diagram (see toolbar), then change the properties of the fragment to a par type and add lanes (conditions) if you want to.

The messages still do not line up at the same height, but the fragment implies that all the messages in the fragment could occur parallel.

I don't have an example, but Zicom Mentor (www.zicom.com.au) explains this type of fragment.

[Martin Fülöp]

Hi,

It's ten years since this thread was started. I didn't find a helpful answer on how to model multi-threaded / parallel processing with EA in sequence diagrams on this forum. Unfortunately, the Zicom Mentor link didn't work for me. But I was lucky enough to collect partial UML know-how on the net. Here are my conclusions (might require verification).

[*]UML sequence diagram models a single-threaded view. It was the first thing I had to realize myself.
[*]Every activation (or execution occurrence) should therefore refer to the activity in the modeled execution thread. Mixing activations of different threads in one diagram looks reasonable only in the "parallel-interaction fragment". Doing it without or outside "par" makes the diagram ambiguous/unreadable.
[*]Every asynchronous message implies existence of some kind of multi-threading. Typically, one thread does the sending only. The execution is in the other thread and thus requires no activity of the sending thread. => At one end of an asynchronous message, there should be only a short activation rectangle (represents the sending).
[*]The "parallel-interaction fragment" ("par") makes it possible to switch the thread context for the messages within its partitions. In every partition, you can model a different thread.
[*]If I would like to have a diagram modeling parallel processing explicitly (not relying on the implied parallelism of an asynchronous message), I would prefer an activity diagram.
[/list]
Here are some examples. All of them try to model the cooperation of 3 threads, a client, a timer server and a processing server. I hope, the use case is clear (a timer guards the processing time).

[*]Sequence_test_parallel_1.png shows my first direct approach. It looks ok according to UML. I didn't like it however. It came to me, that implementing it strictly would require the messages startTimer and startProcessing to be called from different threads.
[*]Sequence_test_parallel_2.png shows how I dealt with the above. It clearly shows, how I failed to let go of my wrong interpretation of activation rectangle. It is definitely mixing threads outside of the "par". It's not ok.
[*]Sequence_test_parallel_3.png shows how I corrected the above. This looks correct, if your implementation will cancel the processing/timer immediately during sending of expiredTimer/doneProcessing. If your implementation only signals to the client thread, the cancellation is done in the client thread and thus its activation does not belong to any partition of "par", the diagram would not fit.
[*]Sequence_test_parallel_4.png shows what I ended-up with, after cleaning the diagram of unnecessary elements. Well, it probably is not, what you would expect to get, when you are modelling parallel processing. I would end-up with three sequence diagrams modelling the activity within client, timer and server threads separately. However, it looks unambiguous, clean and readable to me, which is what I prefer with UML.
[/list]
All of the diagrams have been created with EA10.

Best regards
Martin

[qwerty]

I don't think that SDs itself tell anything about threading. You could simply add partitions for the single threads which act completely independent of each other. Anyway visualization of threading models is simply a nightmare. Description of a single thread is already difficult enough.

What would be the reason for visualizing threading? Do you intend to implement a scheduler?

q.

[Martin Fülöp]

Hi qwerty,

I guess you are right, SD doesn't explicitly tell anything about threading.

My conclusions were meant for us, who are thinking multi-threaded. We tend to misinterpret the lifelines for separate threads. Therefore, I have suggested for those thinking multi-threaded, to think about every SD as a single thread.

Reason for visualizing threading (for me and people asking me for advise with EA):
A common motivation is to describe a cooperation of some objects running in different threads. The multi-threading and scheduling is provided by the framework we deploy to, so we take if for granted and have no need to model the core of multi-threading. The scenario could be: "My Client will start a Timer and ask the Server for processing. Then my Client is free to do other tasks. The Server will inform my Client, when the processing is done. The Timer will inform my Client, when the time is up. My Client will cancel the timeout or the processing, if one or the other is received". As you see, we mostly care about our Client object (which is the subject to be modeled), not the other objects in the other threads.

We think by mistake, that the lifelines are separate threads and that it is useful/nice to show activation rectangle for the parallel processing at the Timer and Server objects. This is mostly based on our past experience with hand-drawn pseudo-UML sequence diagrams. We run into problems with EA and then start complaining about the capabilities of EA, not doing, what we want.

I have learned for my self, that EA is actually doing it right in this scenario as long I'm not mixing multiple threads in one diagram.

Best regards
Martin

[qwerty]

So I see you came to the right conclusion :-)

q.