27

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:

  1. What types of diagrams have you found to be most helpful in understanding multi-threaded applications?
  2. 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.
  • 3
    I personally found activity diagrams useful for modeling (pontentially) concurrent use cases / processes, but they aren't really suitable if you want to go down to class / object level. – Péter Török Nov 21 '11 at 11:03
  • Any behavioral UML diagram is in order for a multi-threaded application. Some behavioral diagrams like activity diagrams include notations for concurrency, but in general, I feel there is no need to treat multi-threaded applications as a special case of UML diagrams, they're just like any other application. Your first step should be deciding if you want to model behavioral or structural aspects of your system. – Zimano Dec 17 '19 at 9:58
13

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

enter image description here

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.

| improve this answer | |
  • What's the heck this has nothing to do with multithread. – user310291 Apr 2 at 12:40
6

My answer is complementary to Dipan's in that it involves UML sequence diagrams. I found that a style that's not 100% pure UML is OK, too. Take a look at the diagrams used in Concurrency Patterns. Some are almost UML-like (but this one is definitely not standard):

enter image description here

If you're familiar with wait/notify in Java thread synchronization, you'll appreciate the following sequence diagram from the document I mentioned:

enter image description here

| improve this answer | |
0

For multi-threaded applications using the same class, the trick could be to drag and drop the same class into each model representing a thread. You would be able to have the same class with different views and navigate in the model and code by clicking on the class, the diagram or the code. I know that the model merge is not a well known concept but it works really well within Eclipse with Omondo.

I mean that when I model a large application which is composed by more than one project. I create a model for each project and then merge them inside a larger project. All modeling is done using class diagrams, which is the model I got when reversing the full project from java code to UML. I mean that in my example I use existing code and reverse it into a single UML model and then merge all this reverse code which has created UML models into a single large model. You can also create multiple models rather than reverse existing code. It works both ways—at creation without code or at reverse engineering stage with existing code.

I don't know if it makes sense but you could maybe create one large model, regrouping sub models for each thread like what I do with multi-projects modeling? Hope this help.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.