UML-диаграммы многопоточных приложений

Для однопоточных приложений мне нравится использовать диаграммы классов, чтобы получить представление об архитектуре этого приложения. Этот тип диаграммы, однако, не очень помог при попытке понять многопоточные / параллельные приложения, например, потому что разные экземпляры класса «живут» в разных потоках (то есть доступ к экземпляру сохраняется только из одного нить это живет дальше). Следовательно, ассоциации между классами не обязательно означают, что я могу вызывать методы для этих объектов, но вместо этого я должен сделать этот вызов в потоке целевого объекта.

В большей части литературы, которую я выкопал по этой теме, такой как Проектирование параллельных, распределенных приложений и приложений реального времени с использованием UML Хасана Гомаа, было несколько хороших идей, таких как рисование границ потоков в диаграммах объектов, но в целом они казались слишком академичными и многословными для быть действительно полезным.

Я не хочу использовать эти диаграммы в качестве высокоуровневого представления проблемной области, а скорее как подробное описание моих классов / объектов, их взаимодействия и ограничений из-за границ потоков, о которых я упоминал выше.

Поэтому я хотел бы знать:

1. Какие типы диаграмм вы считаете наиболее полезными для понимания многопоточных приложений?
2. Существуют ли какие-либо расширения классического UML, которые учитывают особенности многопоточных приложений, например, посредством аннотаций, иллюстрирующих, что
   • некоторые объекты могут жить в определенном потоке, в то время как другие не имеют привязки к потоку;
   • некоторые поля объекта могут быть прочитаны из любого потока, но записаны только из одного потока;
   • некоторые методы являются синхронными и возвращают результат, в то время как другие асинхронные, которые помещают запросы в очередь и возвращают результаты, например, с помощью обратного вызова в другом потоке.

Наиболее важные сведения о том, как выполняются потоки, можно изобразить с помощью так называемой диаграммы последовательности . Вот пример из Википедии

Эта диаграмма по существу рисует список событий вместе с направлением по вертикальной отдельной линии, часто называемой жизненным путем . В этом случае каждый поток является владельцем собственной линии жизни. Диаграмма позволяет представлять все типы событий, такие как синхронные, асинхронные и т. Д.

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

Существуют и другие типы диаграмм , как диаграммы взаимодействия и диаграммы связи , но я думаю , пытаясь нарисовать диаграмму последовательности и диаграммы состояний поместит максимальную ясность.

Мой ответ дополняет ответ Дипана тем, что он включает диаграммы последовательности UML. Я обнаружил, что стиль, который не на 100% чистый UML, тоже подойдет. Посмотрите на диаграммы, используемые в шаблонах параллелизма . Некоторые из них почти UML-подобные (но этот, безусловно, не стандартный):

Если вы знакомы с ожиданием / уведомлением в синхронизации потоков Java, вы по достоинству оцените следующую диаграмму последовательности из упомянутого мной документа:

Для многопоточных приложений, использующих один и тот же класс, хитростью может быть перетаскивание одного и того же класса в каждую модель, представляющую поток. Вы сможете иметь один и тот же класс с разными представлениями и перемещаться по модели и коду, щелкая по классу, диаграмме или коду. Я знаю, что слияние моделей не является широко известной концепцией, но она очень хорошо работает в Eclipse с Omondo.

Я имею в виду, когда я моделирую большое приложение, которое состоит из нескольких проектов. Я создаю модель для каждого проекта, а затем объединяю их внутри более крупного проекта. Все моделирование выполняется с использованием диаграмм классов, что является моделью, которую я получил, переворачивая полный проект из кода Java в UML. Я имею в виду, что в моем примере я использую существующий код и обращаю его в одну модель UML, а затем объединяю весь этот обратный код, который создал модели UML, в одну большую модель. Вы также можете создавать несколько моделей, а не реверсировать существующий код. Он работает в обоих направлениях - при создании без кода или на стадии обратного проектирования с существующим кодом.

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