Comments 17
Use-case диаграммы ещё как-то использую, на начальной стадии, чтобы понять, что вообще в рамки системы входит.
Остальные действительно мимо.
а что сейчас актуально вместо UML?
Зависит от того где, в кровавом ынтерпрайзе до сих пор актуально UML местами. А так C4 вполне.
Смотря для чего. Для описания бизнес-процессов, например - BPMN 2.0
Смотря для чего, как тут и пишут. Но смысл статьи не в том, что нужно срочно отказываться от UML. Я тут читаю как раз наоборот - кто не использует, тому, может и не надо, но посмотрите хотя бы на sequence diagram. А если используете и работает - так и не надо отказываться.
Мне почему то попадались одни UML или им подобные сервисы, где какие-то вещи упрощаются или наоборот собираются в юзкейсы специально максимизируя детали. А альтернатива то какая ?)
Диаграммы последовательности — единственная хорошая вещь, которую UML привнес в разработку ПО
Мы используем диаграммы развёртывания (Deployment) - очень удобно для общения с админами.
И диаграммы активности (Activity) как замену BPMN.
Удобно, когда все диаграммы в одной программе рисуются.
И опять же: какие альтернативы UML? Всегда многостраничные лопухи текста писать? Иногда одна диаграмма заменяет несколько страниц текста..
Не, он же не про то пишет, что нужно с UML куда-то уходить. А наоборот - если вы считаете, что он мёртв, так он не мёртв, взять вот хотя бы диаграммы последовательности... Ну и в опросе у меня результаты гораздо более оптимистичные - почти все вполне UML пользуются, нет такого, чтобы совсем выбросили. На первом месте, с большим отрывом, да - диаграммы последовательности, как и пишет Кнут. Но и другими тоже пользуются. Если работает - зачем менять.
Пользуюсь 5+ типами диаграмм в plantuml для разных случаев. В некоторых сильно выручают (pet-проект, к которому я возвращаюсь раз в несколько месяцев), в других помогают быть на одной волне с коллегами.
И даже тот самый изначальный UML иногда пригождается, чтобы лучше разобраться в наследовании и связях всех важных объектов.
ER диаграммы еще разумеется используются при проектировании хранилищ. Но я совсем не уверен, что они не появились еще до UML.
И хотел бы заметить, что даже в проекте, где они у нас активно применялись, и из них генерился код, это не помогло прошлепать баг, когда одна из связей оказалась 1:1, а должна была быть 1:M. Т.е. все эту связь видели, но никто не заметил, что она не той кардинальности, пока в каком-то одном из последних отчетов не всплыло, что у объекта залога оказывается может быть больше одного владельца.
Ну то есть, весь код работы с БД был построен в расчете, что владелец один, и все приложение работало с этим кодом, и все формы и отчеты, кроме одного, были построены исходя из этого.
Поэтому на вопрос, улучшает ли описание в виде UML понимание проекта, ответ неоднозначный. Вроде и улучшает, а вот подиж ты...
Гораздо удобнее BPMN + swimlanes
Это понятно и компактно. А диаграммы последовательностей огромны и нечитабельны. Они нужны только для частных кейсов, навроде обмена секретами при установке защищенного соединения и т.п.
Я про это уже лет 10 говорю.
дракон в 5 раз лучше , и вообще совесткие блоксхемы алгоритма намного более эффективны, почему в ру
скоязычном сообществе вообще ктото использует это убожество?
Диаграммы последовательности — единственная хорошая вещь, которую UML привнес в разработку ПО