Комментарии 16
Может быть будут интересны примеры генерации схем бизнес-процессов через graphviz:
https://habr.com/ru/articles/810851/
https://bpmbpm.github.io/jsDOTsmartDesign/jsDOTsmartDesign.html (выбор ComboBox EPC\VAD и кнопка "схема")
dreampuf.github.io
Аналогичное можно повторить на PlantUML, и смотреть \ редактировать, например, через https://www.drawio.com/
Сделать диаграмму красивой занимает 90% времени.
Я ожидал в группировке объектов скрытые связи. Но в статье они помещенны в другое место.
Сделать диаграмму красивой занимает 90% времени
90 или нет, сказать трудно, но точно много. И если до этого навёл красоту, то с добавлением новых деталей по мере развития диаграммы всё может "поплыть". Поэтому сперва предпочитаю максимально проработать детали, а уже потом, если результат автоматики не впечатляет, начинаю влиять на расстановку элементов.
Я ожидал в группировке объектов скрытые связи. Но в статье они помещенны в другое место.
Одно другому не противоречит. Все способы можно комбинировать. А то, что конкретно в раздел с группировкой я не поместил скрытые связи, объясняется тем, что я хотел представить материалы по мере усложнения: сначала то, что лежит на поверхности, что можно пробовать, не вникая во "внутрянку", а потом постепенно усложняя детали.
Если интересен пример, где сочетаются скрытые связи, norank и ractangle, могу предложить обратиться к примеру №2 из упомянутой в конце работы (прямая ссылка, самый последний раздел). Когда готовил данную публикацию, решил не включать этот пример, чтобы статья совсем не разрасталась.
Прыгающие элементы которые нельзя прибить к определенному месту - самая большая ложка дегтя в бочку меда планта. Для одной компании делал экспорт в drawio благо оба можно привести к объектам svg. Так как внутренняя структура drawio в XML, то можно не переписывать всю диаграмму, а программно добавлять или обновлять ее элементы. В итоге можно получить лучшее от обоих.
Деды рассказывали, что PlantUML нужен, чтоб быстро накидать схему и её было просто поддерживать. :)
ожидание-реальность.jpg
Не вижу противоречий. Я тоже его использую за быстроту и то, что не надо много времени уделять тому, как эстетично расставить блоки на экране. Но ведь иногда схема становится большой и/или возникает желание переставить элементы так, чтобы лучше донести какую-то мысль, и вот тут надо переходить на следующий уровень.
Могу ответить иначе: можно заставить PlantUML расставить элементы как надо, а вот заставить draw.io или что-то иное расставить автоматически -- не особо:)
Я вам умных мыслей накину. :)
Любая схема из простой может превратиться в сложную.
Если всю жизнь кого-то заставлять что-то делать, то сам ты это никогда не научишься делать.
Расставать элементы как надо в PlantUML - невозможно. Расставить как надо в draw.io - ну, может час от силы. (Следствие из предыдущего пункта.)
Мы уже уходим в область философии и личных предпочтений))
Вообще-то нет. Каждый мой пункт можно доказать. :)
На моей текущей работе минимум половина моих схем стали усложняться со временем. Просто потому, что проект развивается. Остальная половина схем — это схемы для "показать и выкинуть". Т.е. по факту - все схемы превращаются в сложные по мере развития проекта.
Очевидно, по-моему.
У меня нет под рукой схемы, которую я не смог в PlantUML отобразить так, как надо. PlantUML же, в свою очередь, схему постоянно отображал просто страшно. Это было давно и мне тупо не хочется сейча пытаться это воспроизвести. Но факт невозможности был. Да, может уже исправили. Да, может у меня было помутнение, и я что-то делал не так. Но моё помутнение не отменяет факта невозможности: никого просто не было, кто бы смог. А то, что такие люди есть - мне это не помогло. :)
К последнему пункту добавлю отдельно: WYSIWYG не зря придумали. Время разбора и борьбы с синтаксисом PlantUML несоизмеримо больше, чем "просто нарисовать". Поддержка этого синтаксиса - аналогично.
Например, наш архитектор при отрисовки схем в PlantUML использовал макросы (или что там?). В простенькой схеме из 10 элементов - большая часть кода PlantUML состояла из текста этих макросов! Представляю, сколько времени он потратил на написание этого кода (пусть и копипастом). А я перерисовал её в draw.io за несколько минут. :)
Схемы "показать и выкинуть" - ещё один яркий пример. Вы собрались на встрече, на которой кому-то что-то хотите рассказать-объяснить. В процессе встречи решили показать более наглядно с помощью отрисовки схемы в realtime с объяснением каждого элемента. Представлю, как бы это выглядело с помощью PlantUML. :)
P.S. Я был за PlantUML, когда нужно было отрисовать диаграмму последовательности. Но сейчас повспоминал свои последние пару лет и понял, что даже в этом я уже отказался от использования PlantUML.
Я не могу согласиться, что всё плохо, что долго разбираться и что архитектору для 10 элементов обязательно использовать функции препроцессора (видимо, про них речь). Каждой задаче свой инструмент.
Мне реально часто проще использовать именно PlantUML. Понадобится вставить новый элемент на схему, я это сделаю вставкой одной новой строки и модификацией пары-тройки существующих. Все блоки подвинутся, мышкой перетаскивать не нужно будет. Понадобится поменять раскраску группы блоков (например, классов), я это сделаю буквально за пару секунд. И я не ограничиваюсь сиквенсами.
Плюс многие диаграммы не содержат гигантского числа элементов, в таких случаях даже прибегать к продвинутым возможностям не приходится. Я не говорю, что ничего кроме PlantUML не использую, я делюсь опытом и надеюсь, что это будет полезно тем, кто категорично не отрицает этот инструмент и готов им пользоваться.
puml полезен, если, например, нужно автоматически генерить схему. Ну и для SD, да, там как сценарий пишешь, а он схему рисует.
Там, где важнее красота, puml бессилен
За статью спасибо, будучи системным аналитиком, прочитал и освежил в памяти про плантюмл с большим удовольствием.
Емнип, стрелки можно писать не только слева направо, но и в обратном направлении, то есть B <–– A должно быть эквивалентно A ––> B. Правда, не помню, можно ли это использовать в целях позиционирования, но по крайней мере, в статье этот вопрос не покрыт.
Также, по прочтении осталось непонятно, можно ли в одной стрелке совместить опции [hidden] и [norank] (полагаю, что можно).
Соглашусь, эти 2 момента в явном виде не были проговорены и могло получиться не очень прозрачно. Прокомментирую.
Емнип, стрелки можно писать не только слева направо, но и в обратном направлении, то есть B <–– A должно быть эквивалентно A ––> B. Правда, не помню, можно ли это использовать в целях позиционирования, но по крайней мере, в статье этот вопрос не покрыт.
Стрелки можно ставить справа налево, слева направо, делать их двусторонними или вообще без стрелок. Смысл в том, что наконечник — это дополнительный графический символ. Важно само ребро, то есть это дефисы или точки, используемые при задании связи. Что изображено на конце (или обоих концах) ребра — не принципиально. Для позиционирования важно то, что ранг передаётся от левого узла правому (пардон за не очень строгую формулировку). Поэтому запись B<--A сформирует то же отношение между узлами, что и A-->B, но ранг будет выше в первом случае для A, во втором — для B. Ниже привожу модификацию ранее рассмотренного примера.
@startuml
(ВИ 1) <-- "Актор 1"
"Актор 2" --> (ВИ 2)
@enduml
Также, по прочтении осталось непонятно, можно ли в одной стрелке совместить опции [hidden] и [norank] (полагаю, что можно).
Если подходить к вопросу с точки зрения синтаксиса, то можно увидеть, что PlantUML принимает связи вида A - [norank,hidden] - B, но я бы не делал по двум соображениям: такая инструкция выглядит как потенциально рискованная для рендеринга плюс встаёт вопрос семантики. Остановлюсь на втором соображении более подробно.
[hidden] и [norank] совмещать не стоит потому, что эти опции направлены на решение разных задач. Первая опция прячет связь, введённую специально для добавления ранга, т.е. в данном случае ранг связи важен и ради него связь и добавлялась (чтобы искусственно пододвинуть узел на нужное нам место). Вторая опция указывает на то, что ранг от этой связи считать не надо, но семантика этой связи важна и её отображение должно сохраняться.
Если же мы смешиваем эти обе инструкции, то стоит задуматься: а точно ли мне эта связь нужна, зачем я её вообще вводил, ведь мне не нужен ни вес связи, ни её визуальное отображение? Ответ, скорее всего, будет отрицательным.
Управление вёрсткой в PlantUML