Есть ли inituitive UML подход для изображения потоков
Пример создания нового потока, взятого из примеров Android (android-8 \ SampleSyncAdapter \ src \ com \ example \ android \ samplesync \ client \ NetworkUtilities.java):
public static Thread performOnBackgroundThread(final Runnable runnable) {
final Thread t = new Thread() {
@Override
public void run() {
try {
runnable.run();
} finally {
}
}
};
t.start();
return t;
}
runnable - это Runnable, который содержит ваши сетевые операции.
6 ответов
Мне удалось создать диаграмму, которая имела для меня смысл во время ее рисования. Основная предпосылка заключается в том, что я наложил серые прямоугольники, представляющие экземпляры классов, с синими прямоугольниками, представляющими время жизни потоков. Главное, что он позволяет мне отслеживать, - это знать, в каком потоке я буду выполнять при вызове определенных методов.
Несомненно, существуют лучшие и более интуитивно понятные способы моделирования потоков и классов. Мерилом успеха для меня является то, дает ли моя собственная диаграмма тот же уровень понимания через 6 месяцев.
Самая сильная сторона UML - изображение статической структуры. Если вы используете недолговечные потоки, я также не вижу простого способа их построения. Может быть, вы сможете найти решение, немного изменив ситуацию: зачем вам нужны потоки? Какую функциональность они предоставляют? Если они взаимодействуют друг с другом и следуют некоторому API (передача сообщений), рисование их как компонентов может иметь смысл.
В диаграммах активности UML есть элементы fork и join, чтобы показать параллельный поток логики.
Я не знаю способа, но использование диаграммы последовательности не кажется полностью неприемлемым, учитывая, что поток на многих языках реализован как Thread (или аналогичный) class.
Вероятно, наиболее совместимым с UML способом было бы добавить какую-либо аннотацию, указывающую, что «объект» представляет поток.
Диаграммы активности, последовательности и состояний - это все правильные способы отображения поведения потока.
1-й: (К комментариям vs) Есть два набора диаграммы или элементы моделирования в UML, статическая структура, как вы выразились, и поведенческая. Любая книга поможет вам понять разделение, как правило, в содержании / оглавлении, кроме того, это можно увидеть на странице 11 книги Мартина Фаулера «Дистиллированный UML», на мой взгляд, почти де-факто стандарт для начала UML. sipwiz's вопрос и комментарий). Диаграммы действий обычно не используются для моделирования бизнес-процессов, однако их можно использовать для этого, и большинство примеров или простых руководств могут подойти к ним с точки зрения бизнеса.
Обсуждение ваших вариантов моделирования потоков:
Диаграммы действий - Позволяют разветвлять и указывать параллелизм с помощью BAR и строк использования. Обратите внимание, что пример внизу не является бизнес-процессом, example . Их могут прочитать большинство людей, бизнес, менеджмент и разработчики, хотя иногда им может не хватать деталей или они могут запутаться.
Диаграммы взаимодействия последовательности - В том же посте, пример , вы увидите последовательность диаграммы позволяют вам определять параллельное поведение в последовательности, помечая параллелизируемое поведение меткой «par», это полезно, чтобы показать читателю, какие методы могут или должны вызываться параллельно, т. е. разными потоками. Это метод, который я бы использовал для подробного разработчика, например, для обсуждения создания объекта.
Диаграмма состояний - Диаграмма состояний точно так же, как и действие, допускает параллелизм с помощью BAR и строк использования.
ПРИМЕЧАНИЕ: Они не будут моделировать конкретный поток и его точный цикл подъема, как это является частью уровня экземпляра / времени выполнения моделирования, если это то, что вы хотите, уточнить свой вопрос, и я отвечу. Я бы просто смоделировал это, используя одно из вышеперечисленных, поскольку никто, кроме эксперта по MDA / UML, не вызовет вас, и вы не создаете работающую систему.
Также: обратите внимание, что дополнительные сведения можно найти в большинстве UML книги. Также используется: http://www.jguru.com/faq/view.jsp?EID=56322
Традиционно многопоточность изображалась схематически с помощью сетей Петри. У Роба Мартина есть статья о многопоточности в UML, которая может оказаться полезной.
Обновление - только что вспомнил, что вы можете представлять потоки с вилками в диаграммах активности - мне удалось найти кое-что, что объясняет это .
Очень трудно найти какие-либо бесплатные руководства по сетям Петри, однако я знаю, что сети Петри хороши для моделирования параллелизма, поэтому я поискал в Google "сети Петри производителя-потребителя" (моя любимая многопоточность) и нашел это .
Я также нашел несколько слайдов, которые показать сети Петри , моделирующие семафор .