Существует ли подход, основанный на использовании 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-интерфейсам передачи сообщений, их использование в качестве компонентов может иметь смысл.