Hi friends,
Is it possible to use a UML sequence diagram to modelling multiple threads? Well, I did draw a diagram for this purpose, and I think the drawing is easy to understand, but some of my friends said that sequence diagrams are only for modelling classes and objects. They said that my way of modelling is not correct because threads are not objects or classes.
So is it true that we can't use sequence diagrams for modelling threads?
Thank you for reading my question.
Regards,
Riscilla.
UML doesn't have any thread-specific modeling features. A sequence diagram is inherently not an appropriate representation of thread logic, because threads by there very nature do not execute in a sequence with each other. Instead they synchronize at specific points. Most of the UML designs I have seen were thread-agnostic, and could have been implemented in a threaded or non-threaded model at will. In other words, threading is a detail which is below the level of most UML models.
In a flow representation, thread synchronization can be represented as a special kind of block where multiple flows of control join each other. I am NOT a UML expert.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Thread is indeed notoriously difficult to represent well in UML but what we have done is represent each thread *type* (based on function) as a sequence diagram and stored the info that way. On the rare occasion where it was necessary to show thread interaction we would capture these sequence diagrams as a JPG or PNG and assemble them into a single document. FWIW: We also used this as a litmus test to check for a certain class of design flaws: If there was no way to show your overall operation w/o showing all thread interaction, there was a good chance that your threading model was too interdependent and was a recipe for the dreaded race condition or deadlocks. At this point it was often proper to call for a group design review.
What Brewbuck said was correct though: the UML was hideously bad for demonstrating anything other than a single-thread model. At the end of the day you have to ask yourself: it the point of the exercise to show off or use the UML for the sake of using it or is it to clearly express how your application threading model works?
UML can only reliably and clearly model the execution and flow of a single thread. I would approach each thread as it's own UML diagram and use notes in areas where the execution and logic is unclear.
Note that you can model the class structure of threads with UML.
