В молчаливой пустоте сформировалось таинственное Нечто, и это было рождением. С тех пор Оно постоянно изменяется, находясь в одиночестве и неподвижности. Это исток всех программ. Мне неведомо Его имя, поэтому буду называть Его Дао Программирования.

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

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

Но прежде чем приступить к теории или практике нужно ответить на другой архиважный вопрос: — «Для чего нужен UML?». Он сродни другим подобным вопросам, один из которых звучит как: — «Для чего нужна математика?». Конечно, легко ответить в стиле, — «Раз ты не знаешь зачем тебе математика, значит она тебе не нужна», и в принципе это верно.

К сожалению, когда-нибудь она может понадобиться, и учиться ей будет уже поздно. Потому предусмотрительные взрослые издеваются над детьми всё их детство, заставляя учиться, вместо того, чтобы позволить гулять или играть в какие-нибудь игры.

UML это аналитический инструмент. M — значит моделирование. Моделировать можно до, назовём это премоделированием, и после — постмоделирование. Между ними находится фаза кодирования. Нужно ли пытаться создать алгоритм до кодирования, и стоит ли его описывать после него.

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

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



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

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

Большой прямоугольник с закруглёнными концами и пунктирной линией означает группировку. Если бы диаграмма деятельности была больше, то это помогло бы проанализировать её быстрее. Так же стоит понимать, что операция «условие?» или операция «действие», всего лишь некие стереотипы моего, а может быть и вашего, мышления.



Осталось лишь разобрать параллельное исполнение. Для этого служит чёрная жирная линия. Опять же у Мартина Фаулера при разъединении она называется ветвление, и объединение при соединении. Правило отрисовки тоже довольно логично, с одной стороны должен входить один и только один переход по центру, в другой сколько угодно, но по бокам.

Пример, был взят из википедии flowchart, то есть блок-схем и переделан из однопоточной обработки в многопоточную. Причём никто не мешает по существующей диаграмме деятельности создать однопоточную версию программы. Фишка диаграмм деятельности в том, что они позволяют учитывать параллельность алгоритмов ещё на этапе моделирования. А в наше время многопроцессорных систем (CPU, GPU) это порой бывает очень важно.



Что же касается программы, в которой сделаны мои диаграммы, то это Dia. В линуксе простой экспорт в прозрачный png всех файлов в папке делается следующим образом.

dia -t cairo-alpha-png ./*.dia

И здесь стоит отметить, что Ubuntu нынешней последней версии в определённых случаях генерирует диаграмму неправильно, тогда как Debian делает это правильно. А ещё Dia в бубунте любит иногда вылетать.

Экспорт из командной строки привёл главным образом потому, что диаграммы можно сохранять в репозиториях (git) в папке с документацией (doxygen), отправлять изменения на сервер (debian), а там система непрерывной интеграции (jenkins) может сгенерировать диаграммы и собрать документацию, и сразу же отобразить изменения во встроенной документации трекера (chiliproject).

Но это так к слову, просто в книгах по UML и RUP часто идут обсуждения, что диаграммы надо поддерживать в актуальном состоянии. К счастью для этого требуется не так много телодвижений.

AutoDia — автоматическое создание UML-схем из программного кода
Dia2Code — автоматическое преобразование UML-схем в программный код

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