Комментарии 35
К сожалению, PlantUML хорошо работает только на простых вещах. При попытке нарисовать компонентную схему или схему развёртывания мало-мальски сложной системы мы получим нечитаемую спагетти-диаграмму. Это можно решить декомпозицией, но не всегда
И да, сиквенс очень плохо умеет в ветвление, вернее ветвление у него приколочено сбоку, чтобы было. Поэтому опять декомпозиция и использование совместно с activity diagram.
В плюсы запишу то, что это единственное хоть как-то работающее решение architecture as a code.
Существуют библиотеки, в которых по сути единственным кодом для создания FSM (помимо коллбеков переходов) — является PlantUML.
Да, есть такой нюанс со сложными диаграммами, но сложные диаграммы и сложно читаются (и еще больше пугают народ). Поэтому когда PlantUML уже не справляется, лучше в любом случае для простоты чтения ее декомпозировать.
Как у разработчика, всегда возникали вопросы при изучении диаграмм, но еще большо возникало вопросов - как вообще это создается. Статья развеяла иллюзию, что строить диаграммы могут только избранные, что я считаю здорово!
Однако все равно кажется, что очень сложная и большая диаграмма будет затруднительно читаться из кода из-за отсутствия разноцветных ключевых слов, что очень может помочь в чтении кода диаграмм. Думаю, что это было бы очень полезным улучшением.
Очень рада, что помогла развеять этот миф. Надеюсь, что удасться применить данную информацию на практике.
https://www.planttext.com/ , https://plantuml-editor.kkeisuke.com/ - вот ссылочки, где можно описывать диаграмму и ключевые слова подсвечиваются, думаю, что есть и еще ресурсы с такой же возможностью
Еще хочу отметить, что если в диаграмме есть ошибка, то диаграмма не отрисовывается и указывает, в какой строке есть ошибка, что тоже помогает быстро ориентироваться
Если нужна раскраска текста, то тут хорошо поможет VSCode+плагины для работы с PlantUML, например "PlantUML Previewer"(Mebrahtom.plantumlpreviewer) и "PlantUML" (jebbs.plantuml).
Для работы с Plant мы используем именно VSCode, т.к. есть цветовая градация, хорошо уживается с Markdown и схемы рисуются в онлайне, что особенно прекрасно. Плюсом можно настроить импорт/экспорт с кодовой базой для облегчения ведения документации.
А ещё ChatGPT умеет генерировать plantuml диаграммы, если его попросить :)
О, здорово, покажешь пример? :)
Более того, он умеет их ещё и понимать. Можно скормить ему сложную диаграмму и он объяснит, что в ней делается.
А ещё можно попросить объяснить какую-то тему и к ней для наглядности нарисовать диаграмму.
Перешел на альтернативу в виде Mermaid, потому что он работает везде по умолчанию без плагинов.
"везде" - это где?
"везде" громко сказано, я бы сказал кое-где, но нативная поддержка присутствует — github, gitlab, notion. Можно тут посмотреть: https://mermaid.js.org/ecosystem/integrations.html
Использовал пару лет назад для генерации схем прямо из ClickHouse https://github.com/Felixoid/clickhouse-plantuml
Правда, код уже немного заржавел, в CH появилось очень много всего.
Вопрос по диаграмме "сформировать выписку по счету".
else Клиент прошел проверку
report -> pdf++: Отправка данных для \nформирования выписки по счету
pdf -> pdf: Формирование выписки по счету
В случае else откуда report узнает, что выписку выдать можно?
Отличный вопрос! report узнает о том, можно ли выдать справку от системы скоринга check. Поэтому в идеальном варианте должно быть так:
report -> check++: Проверка клиента
check--> report--: Информация о результатах скоринга
alt Клиент не прошел проверку
report--> front: Отказ в выдачи выписки по счету
else Клиент прошел проверку
report -> pdf++: Отправка данных для \nформирования выписки по счету
pdf -> pdf: Формирование выписки по счету
плант умл крутая штука, для оффлайн редактирования еще sciareto можно использовать, у него включены специально все нужные библиотеки вплоть до elk от эклипса что бы работало!pragma layout elk
с ER-диаграммами у него по прежнему туговато, но и их можно если очень хочется...
туговато, но можно накостылить)
у Mermaid вроде получше с этим делом обстоит: https://mermaid.js.org/syntax/entityRelationshipDiagram.html
выглядит ужасно
если бы инструмент умел объединять однотипные связи, чтобы упростить представление - было полезно
а так как будто визуализация для галочки
Отказ в предоставлении выписки по счету? Чего?
Я не очень понимаю смысл держать plantUml в проекте с кодом и каких-то преимуществ от того что программист сможет это прочитать в коде. Визуальная версия сильно более наглядна. А в исходники класть бессмысленно потому что диаграммы будут устаревать и разработчики не будут их перерисовывать так как нет линка на код. И кто должен перерисовать ее? Аналитик и потом сделать коммит с правами разработчика?
Согласен, я рисовал вот эти диаграммы, но потом с кодом всё разъехалось, и обратно уже не съехалось. А ещё проблема с диаграммами классов, что при редактировании автоматом меняется лэйаут, и бывает так, что надо все с нуля воспринимать мозгом.
у нас диаграммы в коде как раз описывают аналитики, если что-то меняется, то меняется и диаграмма, и да потом идет процесс ревью, как у взрослых)
Лично я уже три раза садился на PlantUML рисовать сложные диаграммы (когда декомпозиция не нужна), плевался, бросал это дело и уходил на draw.io, после чего успешно забывал это и ситуация повторялась. :)
Каждый раз несколько часов занимался тем, что заставлял его нормально расположить элементы на схеме, а не рисованием самой схемы. В итоге на draw.io отрисовывал всё минут за 30.
PlantUML - это строго только диаграмма последовательностей. Ну или буквально из 5 "кубиков" какая-нибудь другая схема.
Он бы был нормальный, если бы в нём можно отключить его "киллер-фичу": криво работающую автоматическую расстановку кубиков на схеме. Чтоб можно было простыми командами говорить, где что должно быть расположено. Но тогда он становится сложнее draw.io. Парадокс. :)
Диаграммы без боли и страданий: PlantUML