Как изобразить поток, ожидающий сигнала на диаграмме последовательности?

Question

Обычной многопоточной реализацией является наличие некоторого класса, в котором Method_A() работает в потоке и блокируется в ожидании некоторой переменной-члена сигнала / события (например, WaitForSingleObject).

Взаимодействующие классы, работающие в другом потоке, затем вызовут Method_B(), который выполняет некоторую работу, устанавливает переменную сигнал / событие, возможно, выполняет еще некоторую работу, а затем возвращает.

Как мне представить это взаимодействие на диаграмме последовательности?

Должны ли я иметь две линии жизни, по одной для каждого потока, даже если они работают в одном экземпляре класса? Мой инструмент моделирования (Enterprise Architect 12) не позволяет одному и тому же классу дважды появляться на диаграмме последовательности, поэтому, кажется, это препятствует этому.

---

Редактировать: Гирт отметил, что на диаграмме последовательности должны использоваться экземпляры, , а не классы, , что является справедливым комментарием. Однако проблема та же: множественные линии жизни подразумевают несколько экземпляров, но в вопросе Method_A() и Method_B() работают на одном и том же экземпляре , только из разных потоков. Как это можно изобразить?

Answer 1

Подход, который я решил использовать, состоит в том, чтобы добавить две линии жизни для одного и того же экземпляра, затем обозначить одну линию жизни стереотипом <<thread>> и добавить нить, в которой он работает, к имени:

Я понимаю, что это, вероятно, не стандартный UML, но, похоже, он четко передает всю информацию, которую я хочу выразить, что является самым важным, верно?

Мартин Фаулер несколько раз упоминал в своей книге, что иногда ненормативная диаграмма на самом деле более ясна. Так что это мое оправдание. :)

Answer 2

( Редактировать Вы можете решить эту проблему, просто используя асинхронные сообщения, как указывает @sim. Это просто поможет. Ответ ниже показывает, что происходит под капотом. Так что если вы этого не сделаете позаботься о деталях, иди с этим ответом.)

Вы спрашиваете больше о дизайне, чем о UML. А именно, как параллельные экземпляры общаются друг с другом. Вы сказали сначала

Method_A () работает в потоке и заблокирован в ожидании

, что просто означает, что он не может ничего принять, поскольку он заблокирован. Теперь, исходя из контекста вашего вопроса, я предполагаю, что вы все еще хотите общаться с этим экземпляром, так как

в другом потоке вызовет Method_B ​​()

Таким образом, чтобы иметь возможность принять сообщение, экземпляр должен находиться в соответствующем состоянии. Есть несколько способов добиться этого. Один простой способ - если соответствующая ОС имеет такую ​​поддержку, вернуться к планировщику и сказать ему, что он ожидает какого-то сообщения.

Теперь, когда вызывается method_b, вы знаете, внутри Object1, что вы находитесь в каком-то неактивном состоянии внутри method_a и делаете соответствующие (возвратные) действия.

Другой способ - опросить планировщик на наличие входящих сообщений и обработать их.

Необходимо помнить, что отправка сообщения обычно не имеет непосредственного отношения к экземпляру, а указывает системному планировщику взаимодействовать с соответствующим экземпляром (по крайней мере, в большинстве ОС).

Я только что вспомнил из компилятора Modula2, который я однажды написал, что у него есть концепция сопрограмм, которая позволяет параллельному потоку выполняться в скомпилированном коде. Но в основном это просто сопоставлено двум независимым потокам, работающим под капотом полу-одиночного, и вы будете изображать это с двумя линиями жизни, когда будете вдаваться в детали.

N.B .: Вместо метода это должна быть операция (поскольку она вызывается сообщением; метод - это то, что реализовано внутри операции). И согласно общему соглашению они должны начинаться со строчной буквы.

А также: НЕ используйте классы на SD. К сожалению, EA все еще позволяет это (почему? Спросите их!) Где-то в их документах спрятано предложение, которое вы должны использовать экземпляры. Иначе модель сломается. SD - это всегда (!) Образец последовательности экземпляров, говорящих друг с другом. Классы не разговаривают, это просто чертежи для экземпляров.

Answer 3

Обозначение, которое вы ищете, является асинхронным сообщением. Вы можете теоретически выразить это, используя единственную линию жизни. Но это не будет читабельным. Таким образом, в вашем классе может быть два экземпляра класса потоков и показано взаимодействие между экземплярами. Но никогда не показывайте классы в диаграмме последовательности. Но почему вы вообще используете диаграмму последовательности? Для такого внутреннего поведения диаграмма деятельности, скорее всего, более подходит. Там вы можете использовать элементы отправки и получения сообщений, чтобы выразить такое поведение для каждого потока. Или, если это будет показано на одной диаграмме, вы можете использовать fork.

Answer 4

Никогда не следует использовать классы в диаграммах последовательности, но вместо этого используйте экземпляры / линии жизни , в которых ваш класс является классификатором.

Если при перетаскивании класса на диаграмму последовательности удерживать элемент управления нажатым, вы можете выбрать его как экземпляр, а не как класс.

Таким образом, вы можете добавить столько, сколько хотите для одного класса.