Pull to refresh

Comments 14

Поддержу автора. Больше всего отталкивает от использования диаграмм попытки каждого разработчика и участника проекта изобрести свою нотацию, непредсказуемый уровень детализации, направления (разработчик мне как то нарисовал ракушку/спираль со стартом в правом нижнем углу, не сразу догадался как смотреть на его запутанную диаграмму). Не так сложно познакомиться со стандартом и соблюдать его.

Во-первых draw.io больше нет.

Во-вторых автор умудрился рассмотреть 3 типа UML-диаграмм, не упоминая что их вообще сильно больше, и выглядят они совсем по-разному, и предназначены для разных целей. Из текста новичку (ну, тому, кто каким-то образом пропустил соответствующий курс в профильном универе) вообще никак не очевидно, что это не одна диаграмма.

В третьих есть мнение, что он таки морально устарел. По крайней мере дизайнеры часто плюются, и говорят что могут нарисовать лучше

Во-первых draw.io больше нет.

Живет под app.diagrams.net/ и активно используется многими.

В третьих есть мнение, что он таки морально устарел. По крайней мере дизайнеры часто плюются, и говорят что могут нарисовать лучше

Давайте отделять одно от другого. Устарел в чем? Какие задачи не выполняет? Какой инструмент их выполняет лучше?

Дизайнеры всегда плюются в сторону программистов, а программисты - всегда на дизайнеров ) Но зачем дизайнерам UML? Они скорее смотрят CJM и прочие красивости.

и активно используется многими

В том числе и мной, но давайте его этим именем и называть. Лет через 10 человек найдет статью, а редиректа со старого имени уже не будет (много раз на хабре с этим сталкивался)

В третьих есть мнение, что он таки морально устарел. По крайней мере
дизайнеры часто плюются, и говорят что могут нарисовать лучше

На самом деле многие делают похожие редакторы, которые есть в open source, но почти у всех есть проблемы, нарисованы они красиво, но работают не очень, обычно проблемы возникают с прикреплением стрелочек к объектам и если начать двигать объектами со стрелками, то начинаются большие проблемы. Поэтому на самом деле задача довольно сложная и вариантов не так много для рисования диаграмм, можно использовать drawio или visio, есть еще несколько продуктов, но по качеству они не дотягивают, но возможно в комментах посоветуют что-то получше или на уровне этих продуктов.

Диаграммы (как для КА, так и тайминг-диаграммы) удобны для общения, особенно в верхней левой и правой верхней части V, поскольку помогают договориться исполнителю и специалисту-пользователю. PlantUML хорошее соглашение, единственный неудобный момент — диаграммы Харела в этой нотации неудобно на доске рисовать для первичного согласования. А дизайнеры всегда плюются и говорят, что могут нарисовать лучше :)

странно, что никто не пришел и не показал mermaid-js. Eго умеет рендерить сам github, и тем самым дизайн документ сервисов оформлять и ложить под гит.

На мой взгляд, основная проблема UML, как и любого другого языка, - на нём должны сносно разговаривать все участники процесса. Если вы знаете, что обозначают разные виды стреловек, а ваш визави нет, то коммуникация не состоится.

Может мне так "везло" с проектами, но последний человек, который нормально владел UML, это был мой препод в ВУЗе.

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

Поддерживаю. Правда в том, что никто не знает UML. Все только "припоминают" что-то о UML, но не более.

В связи с этим простым фактом, для большинства UML будет выглядеть ничем не лучше самостоятельного поделия на чём угодно, от draw.io до фотографии листочка бумаги.

Я вот 99% всех диаграмм рисовал в Gliffy, но с тех пор как убили Chrome Apps, пришлось искатб альтернативы, но пока что ничего лучше так и не нашёл. Gliffy по ощущениям был как ручка с бумагой. Ничего лишнего, все кнопки под рукой, всё было супер интуитивно.

UML is the worst modeling language except for all the others
Bran Selic 

В большинстве реальных случаев сойдёт UML-like сиюминутный костыль из головы)

Sign up to leave a comment.