Существует ли подход, основанный на использовании UML для отображения потоков

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

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

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

Ответ 1

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

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

Ответ 2

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

1st: (To vs comments) В UML есть два набора диаграмм или элементов моделирования, статическая структура, как вы выразились, и поведенческие. Любая книга поможет вам понять раскол, как правило, в содержании /TOC, дополнительно это можно увидеть на стр. 11 Martin Fowler UML. По моему мнению, для начала UML дистиллирован близкий стандарт defacto.

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

Самый UML-совместимый способ, вероятно, должен был добавить аннотацию какого-то типа, указывающую, что "объект" представляет поток.

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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