Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.
share|improve this question
2  
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

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer

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

share|improve this answer

For multi-threaded applications using the same class, the trick could be to drag and drop the same class into each model representing a tread. 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 and not to 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 may be create one large model regrouping sub models for each tread like what I do with multi-projects modeling ? Hope this help.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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