For single-threaded applications I like to use class diagrams to get an overview of the architecture of that application. This type of diagram, however, hasn’t been very helpful when trying to understand heavily multi-threaded/concurrent applications, for instance because different instances of a class "live" on different threads (meaning accessing an instance is save only from the one thread it lives on). Consequently, associations between classes don’t necessarily mean that I can call methods on those objects, but instead I have to make that call on the target object's thread.
Most literature I have dug up on the topic such as Designing Concurrent, Distributed, and Real-Time Applications with UML by Hassan Gomaa had some nice ideas, such as drawing thread boundaries into object diagrams, but overall seemed a bit too academic and wordy to be really useful.
I don’t want to use these diagrams as a high-level view of the problem domain, but rather as a detailed description of my classes/objects, their interactions and the limitations due to thread-boundaries I mentioned above.
I would therefore like to know:
- What types of diagrams have you found to be most helpful in understanding multi-threaded applications?
- Are there any extensions to classic UML that take into account the peculiarities of multi-threaded applications, e.g. through annotations illustrating that
- some objects might live in a certain thread while others have no thread-affinity;
- some fields of an object may be read from any thread, but written to only from one;
- some methods are synchronous and return a result while others are asynchronous that get requests queued up and return results for instance via a callback on a different thread.
Best Answer
The most important insight about how thread executions happen can be depicted by what is known as sequence diagram. Here is an example from wikipedia
This diagram essentially draws the list of events along with a direction over a vertical single line often called lifeline. In this case, each thread is an owner of it's own life line. The diagram allow representation all types of events such as synchronous, asynchronous etc.
The other most important thing in such systems is the state-charts or state-diagrams. Usually, this applies only if the model is represented as a state machine. However, in most multi threaded systems (where threads are non-trivial) it is best that they are designed to function with isolated algorithms for different states.
There are other diagram types like interaction diagram and communication diagram but i think trying to draw sequence diagram and state diagrams will put maximum clarity.