Есть ли оригинальный UML-подход к изображению потоков?

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

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

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

1-й: (К комментариям vs) В UML есть два набора диаграмм или элементов моделирования: статическая структура, как вы ее выразили, и поведенческая. Любая книга поможет вам понять разделение, как правило, в содержании / оглавлении, кроме того, его можно увидеть на странице 11 книги Мартина Фаулера UML Distilled, на мой взгляд, почти фактического стандарта для начала UML.

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

Обсуждение ваших вариантов моделирования потоков:

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

Диаграммы взаимодействия последовательности - в том же сообщении example, вы увидите, что диаграммы последовательности позволяют указать параллельное поведение внутри последовательности, помечая параллелизируемое поведение меткой" par ". Это полезно, чтобы показать читателю, какие методы могут или должны вызываться параллельно. , т.е. разными потоками. Это метод, который я бы использовал для подробных разработчиков, например, для обсуждения создания объекта.

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

ПРИМЕЧАНИЕ.. Они не будут моделировать конкретный поток, а его точный цикл подъема, поскольку это часть уровня экземпляра / времени выполнения моделирования, если это то, что вы хотите уточнить. на ваш вопрос и я отвечу. Я бы просто смоделировал это, используя одно из вышеперечисленных, поскольку никто, кроме эксперта по MDA / UML, не вызовет вас, а вы не создаете работающую систему.

Также: обратите внимание, что дополнительные сведения можно найти в большинстве книг по UML. Также используется: http://www.jguru.com/faq/view.jsp?EID=56322

Традиционно многопоточность изображалась схематически с помощью сетей Петри. У Роба Мартина есть статья о многопоточности в UML, которая может оказаться вам полезной.

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

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

Я также нашел несколько слайдов, на которых показано моделирование семафора в сетях Петри..

В диаграммах активности UML есть элементы fork и join, чтобы показать параллельный поток логики.

Я не знаю способа, но использование диаграммы последовательности не кажется совершенно неуместным, учитывая, что поток на многих языках реализован как класс Thread (или аналогичный).

Вероятно, наиболее совместимым с UML способом было бы добавить какую-либо аннотацию, указывающую, что «объект» представляет поток.

UML определяется надстройкой UML, вы можете найти его здесь http://www.omg.org/spec/UML. Если вы прочитаете спецификацию, вы обнаружите, что класс UML может быть активным. Активный класс - это класс с метаатрибутом isActive, установленным в значение true. Он тоже изображен по-разному. Экземпляры объекта активного класса автоматически выполняют «поведение классификатора». Что касается любого поведения, вы можете определить его с помощью действия, в котором вы ждете асинхронных сигналов (AcceptEventActions) и вызывает методы (CallOperationAction) или другие варианты поведения (CallBehaviorActions). Так в UML моделируются активные объекты. Вам просто нужно прочитать спецификацию UML.

Диаграммы действий будут моделировать внутреннюю работу вашего программного обеспечения с ветвями и объединениями для представления потоков. Чтобы узнать, точно, как это правильно смоделировать, см. Серию превосходных статей Конрада Бока. Здесь находится статья, посвященная вилкам и соединениям, но вы должны вернуться по ссылкам на первая статья в серии, чтобы научиться правильно моделировать с помощью «Цветных сетей Петри». Это не то, как вы думаете (а это довольно просто)!

В OMG есть новый, внутрипроцессный стандарт для языка под названием Alf, который обеспечивает более удобную поверхностную нотацию для диаграмм действий и предназначен для представления кода. Из спецификации:

Основная цель языка действий - действовать как поверхностная нотация для определения исполняемого поведения в более широкой модели, которая в основном представлена ​​с использованием обычных графических нотаций UML. Например, это могут быть методы для операций классов или поведения эффектов перехода на конечных автоматах.

Для программиста вы, вероятно, не сможете стать более интуитивным, чем Альф. И он отлично конвертируется в диаграммы активности UML.

Самая сильная сторона UML - это статическая структура. Если вы используете недолговечные потоки, я также не вижу простого способа их построения. Может быть, вы сможете найти решение, немного изменив ситуацию: зачем вам нужны потоки? Какую функциональность они предоставляют? Если они взаимодействуют друг с другом и следуют некоторому API (передача сообщений), рисование их как компонентов может иметь смысл.