Comments 18
Я люблю PlantUML, единственное, что я как-то умудрился нарисовать такую диаграмму, которая после загрузки в конфлюэнс его крешила. Так я и не понял, чем я так ему не угодил :)
Некоторые типы диаграмм при некоторых входных данных получаются хорошие. Но в общем случае очень легко получить совершенно безумную компоновку.
Эта ссылка должна быть в статье: https://www.planttext.com/
Я раньше тоже избегал мышкой рисовать, но после пары реальных попыток использовать PlantUML, понял, что взять и передвинуть мышкой - это всегда одинаково предсказуемо, а учить десятки хитрых параметров PlantUML - просто специальная олимпиада какая-то.
В итоге использую https://www.diagrams.net/ - он позволяет сохранять диаграммы как XML файлы (ну и дальше их конечно же можно в гит).
Инструментов много, суть моего доклада и данной статьи показать, как работает инструмент plantuml. Посмотреть diagrams - посмотрим. А для него есть плагины для confluence и других вики?
У вас очень поверхностная статья и все примеры гладкие. Реальность выглядит например вот так:
(плагины для конфлюенсов конечно есть)
Если вы рисуете uml для людей, а не для галочки, у вас таких примеров не будет. Ограничьте количество элементов, можно настроить длину стрелок и прочее. Диаграмма должна быть понятной - это зависит не от инструмента рисования, а от автора
По-моему вы просто "для людей" натягиваете на технические ограничение инструмента. В зависимости от конкретной ситуации и двух прямоугольничков может быть много и тридцати мало.
Оно не техническое. Оно концептуальное. Если получается то что на картинке — это означает, что диаграмма становится бессмысленной (Начинаем рисовать всякие таблицы и вообще отображать ту же информацию по другому). Можно то же самое разложить в yEd который значительно богаче в смысле инструментов раскладывания диаграммы.
Результат скорее всего получится приблизительно такой же.
Сформулируете концептуальное ограничение? Типа: "показать все реализации интерфейса на одной диаграмме - бессмысленная затея, никто и никогда не должен этого хотеть".
Приблизительно — как только становится невозможным держать всю диаграмму разом в фокусе внимания и памяти — значит, пора менять представление и/или нарезать на кусочки.
С текстом, например, это делается параграфами и главами.
"показать все реализации интерфейса на одной диаграмме" — ну так по мне действительно бессмысленная. Просто написать текстом "All Known Implementing Classes: <дальше список>" или нарисовать табличку с ними же — рассказывает о том же и дополнительно позволяет всяким поисковым движкам искать то, что тебе надо.
А какой смысл этой диаграммы? К сожалению, это как раз пример очень перегруженной диаграммы, смысл которой не ясен совсем. Это тоже самое, что взять продовую базу с 10^5 таблиц и сгенерировать таблицу связей. Хорошие диаграммы - это sequence диаграммы, state диаграммы. Что отображено в статье. Плюс модель с4. Хорошее видео по с4 model: https://www.youtube.com/watch?v=x2-rSnhpw0g
А какой смысл этой диаграммы? К сожалению, это как раз пример очень перегруженной диаграммы, смысл которой не ясен совсем. Это тоже самое, что взять продовую базу с 10^5 таблиц и сгенерировать таблицу связей.
Да ну. Развесистые диаграммы бывают. С ними всё в порядке. Они полезный инструмент для "творческих" задач - когда толком не знаешь где начало, где конец, но хочешь посмотреть, пообсуждать. В таких ситуациях удобны срезы всей системы целиком. Берёшь такую диаграмму, и погнал: зачёркиваешь, исправляешь, добавляешь, и т.д.
И неразвесистые диаграммы тоже бывают. Они полезный инструмент для более конкретных вопросов, типа "а как у нас классы и студенты связаны"? А вот вам картинка из 3 прямоугольничков: классы-энроллменты-студенты. На всю базу нет смысла смотреть.
Потребности "пользователей" определяют какие диаграммы имеют ценность, а какие нет. Уж точно мнение PlantUML по этому вопросу не имеет веса.
Хорошие диаграммы - это sequence диаграммы, state диаграммы. Что отображено в статье.
Sequence диаграммы хорошо идут, потому что там компоновка совершенно предсказуемая. Любой другой тип, где в общем случае дерево/граф - и всё, "3 прямоугольничка должно быть достаточно каждому". Я ж вроде это и написал в первом комментарии?
Ну если необходимо показать наслоения классов то либо так либо круговая. И мне кажется в PlantUML добавить что-то в диаграмму будет проще нежели в графическом интерфейсе.
У меня есть диаграммы размером где-то А1 если печатать, если бы я руками расставлял в них квадратики я бы с ума сошел.
Вот исходник моей демонстрационной диаграммы:
@startuml
title Classes - Class Diagram
interface Service
class ServiceA implements Service
class ServiceB implements Service
class ServiceC implements Service
class ServiceD implements Service
class ServiceE implements Service
class ServiceF implements Service
class ServiceG implements Service
class ServiceH implements Service
class ServiceI implements Service
class ServiceJ implements Service
class ServiceK implements Service
class ServiceL implements Service
class ServiceM implements Service
@endumlПокажете как круглый лэйаут сделать?
С наступлением пандемии, когда все ушли на удаленку, для описания задач и фичей мы использовали notepad, textedit, sublime - все, что попадало под руку, чтоб зафиксировать текст.
А таск менеджер использовать, нет? Он вроде и создан для того что копить и структурировать задачи.
А диаграммы нужны проекту для понимая проекта в целом, а не решения конкретно задачи. Т.е. диаграммы нужны всегда, а не только когда стоит какая-то задача.
А статья хорошая и инструмент полезный и нужный :)
У них ещё фишка есть (про интеграцию)
Попробуйте где-нибудь на гитлабе (не гитхабе, хотя там тоже может сделают), вводить plantuml в соответствующем контейнере
digraph foo {
label="Elevation deadlock"
Th1 -> Shared1 [label=" take 1r"]
Th2 -> Shared2 [label=" take 1r"]
}... и тут вдруг внезапно оказывается, что встроенный plantuml (или всё, что может под ним скрываться, в данном случает dot) - после рендеринга превращается в картинку!
Работает (на гитлабе) везде - заметки, тикеты, комментарии к тикетам, вики.
(на гитхабе пока, к сожалению, просто рендерится код как текст. Но наверняка очень скоро исправится!)
PlantUML — инструмент продуктового разработчика