How do I model a message interface between two c++ classes (in difference threads) in UML?

Question

What I have is:

• Two different classes that are in different threads (say classA and classB).

• They do not know anything about each other (no includes / forward decls).

• When classA has finished something it posts a message (the routing is handled elsewhere), and classB receives it.

That's all really. In my class diagram, I want to show that classA and classB have messages passing between them (i.e. can communicate) and that they are in different threads.

Is this possible in UML class diagram? - is there a "communicates" relationship syntax? If UML does not do this then I will just make up my own method to show this, but if there is a standard I may as well use it!

Answer 1

To depict threads you can use Activity diagrams, Sequence Interaction diagrams and/or State diagram

• Activity diagrams - Allows for forking and specifying concurrency/synchronization by using a BAR and usage lines.

• Sequence Interaction diagrams - allow you to specify parallel behavior within a sequence by boxing parallelizable behavior with a label "par"

• State diagram - The state chart just like the activity allows for concurrency by using a BAR and usage lines.

The image illustrates consumer/producer pattern in UML activity diagram:

Modeling_Java_Threads_in_UML

Answer 2

Is this possible in UML class diagram? - is there a "communicates" relationship syntax?

Just put notes or a (stereotyped) dependency. It's not possible to express this in an UML class diagram. Class diagrams are inherently not for showing the behavioral aspects, but the structure and static relationships of class types.

Good diagram types to represent concurrent behavior in your system are Activity or State diagrams.

UPDATE
Though one reasonable UML standard compliant way to mark classes as running in separate threads, is to declare them as 'Active Class':

An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control.") The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.

UML Superstructure Specification, v2.1.1, p. 438

It's rendered like this:

Anyway the possible path's of communications between such class elements can be expressed via the mentioned stereotyped dependency relationships.

For Activity / State Diagrams you can think about such asynchronous message interactions in terms of Signal and Event elements.