Comments 76
В добавление: из свободных продуктов удобны Umbrello и Dia.
Linux — искаропки, Windows и macOS — есть инсталяторы.
Причина простая, по этой же причине не находят массового распространения многие средства так называемого «визуального программирования» — нет нормального версионирования диаграмм (хочу заметить, что и вы тут о нем не упоминаете вообще, как будто его и не существует в природе — и для меня это звоночек).
Что значит «нет нормального версионирования диаграмм»? А значит, что если с диаграммой на изменение работает более одного человека, то вы не сможете удобно посмотреть историю изменений, не сможете зачастую сравнить две разные версии, чтобы понять, кто, что и где менял. Может, что и изменилось, но когда мне приходилось с этим работать, такого хорошего инструмента не было.
Поэтому оно работало до тех пор, пока диаграмму менял один человек, который помнил, что делает. А остальным раздавали результаты генерации из нее в виде кода, например.
Ну то есть, бывают случаи, когда это работает. Но как только нужно править вдвоем — тут же возникают сложности.
поддерживаю!
из-за необходимости версионирования начали обучение аналитиков PlantUML (прошло, кстати, без сопротивления с из стороны).
Visio и т.п. — это как презентации в PowerPoint: для одноразового применения для красивой подачи, но ни как не для командной работы.
там и остальные-то рисуются не то, чтобы фонтан (визуально, если с Visio тем же, например, сравнивать).
но если рассматривать как компонент подхода к автоматической генерации документации, то вполне себе вариант.
ps: ну и можно принять участие в разработке PlantUML
pps: архитектурные схемы, если я правильно понял, о чем речь, меняются все-таки очень редко
У меня в компании это рекомендованый инструмент для создания архитектурных диаграмм. Поднят рендер сервер, разработчики коммитят в git .puml файлы, которые потом в README.md отображаются картинкой.
Поддержка archimate: plantuml.com/ru/archimate-diagram
ЕА сохраняет содержимое пакета в XML, а оный уже в svn. То есть в случае какой либо проблемы всегда можно откатить, или найти по истории правок «виноватого».
Но работать с этим за отсутсвием диффа не очень удобно, потому все равно не видно кто и что конкретно поменял (тем более что все ленятся писать историю в коммиты).
Визио + хранение на Onedrive или Sharepoint. Вполне решает проблему с контролем версий.
Вот у вас есть две версии диаграммы. И нет автора изменений. Как вы будете узнавать, что именно поменялось? Редактор просто стрелочки подвигал, чтобы было красиво, или скажем изменил кардиналити у одной из них?
Проблема коллективной работы с подобными (не текстами) состоит именно в том, что не слишком просто (и это мягко сказано) сравнить две версии семантически.
В итоге у нас, когда я это последний раз применял, это выглядело так — у диаграммы был один автор. Это была диаграмма классов. Из нее генерировались классы для CRUD, и схемы базы данных. В итоге, если автор не напишет всем почтой: «Я поменял вот это и вот это» — черта с два вы просто так узнаете, что в очередной версии изменилось.
Почему для связи элементов мы использовали линии, а не стрелки? Потому что никто не помнит, как выглядят стрелки «Обобщение» и «Расширение», и что они вообще такое. Чем проще вы нарисуете, тем больше людей поймет диаграмму без вашего участия.
Какое отношение эти диаграммы тогда будут иметь отношение к UML диаграммам? Это просто будут "какие-то диаграммы". Изначальная фраза "UML в работе важен и нужен" сводится до банального "картинки в работе нужны и важны".
Проблема тут важная.
Если рисовать UML то люди поделятся на две категории: кто хоть что-то уловил, общий смысл будет понятен, но также будут и люди, которые увидят более полный и глубокий смысл. Это как с картинами художников: лично я вижу только что-то совершенно явное, искусствовед видит на три смысловых слоя больше.
Упрощённый же UML (как пинглиш, как рисунок ПМХ на заборе) понятен якобы всем, но во-первых, в нём вряд ли будет глубина и допонительные смысловые слои — особо вглядываться там некому, во-вторых и понятность достигается за счёт упрощения и загрубления картинки. (Так и нужен вам тогда UML, если вам просто достаточно кружочков и палочек?)
И вторая проблема. Что UML действительно перегружен до непрактичности. Тем не менее, я те диаграммы, которые рисую постоянно знаю достаточно хорошо. Т.е. вопрос именно в достаточной практике.
Если вы знаете, что такое Реляционные базы данных, то это более чем наглядно.… Не пытайтесь рисовать это в Visio,Вот тут я с вами не согласен. Есть у меня проект старенький (2007 года), в нём БД для MS SQL Server. Рисовали, обсуждали, генерировали DDL Script, писали документацию с помощью MS Visio. С версиями тогда не было проблем, т.к. за всё я один отвечал. Пробовал и другие системы, но не прижились они.
/* This SQL DDL script was generated by Microsoft Visual Studio (Release Date: LOCAL BUILD). */
/* Driver Used: Microsoft Visual Studio — Microsoft SQL Server Driver. */
/* Document: D:\MyProjects\nda\ModelDB.vsd. */
/* Time Created: ** July 2010 **:**. */
/* Operation: From Visio Generate Wizard. */
Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.
Не полностью согласен с этим утверждением в части Enterprise Architect (EA):
1. EA вполне себе подходит для ER-диаграмм, сам использовал для проектирования новой БД и для Reverse Engineering из MSSQL и Oracle существующих БД.
2. Еще в EA есть возможность генерации документации по ER-диаграмме (схеме) БД с заданным шаблоном: можно генерировать документацию по структуре БД, с описанием таблиц, столбцов и прочего. Шаблоны можно под себя подстраивать и если потратить немного времени, то сразу в получать документацию в требуемом оформлении. Лучше день потерять, потом за час долететь (с) ;)
Мне, извините, плевать на стрелочки с квадратиками. Я не мыслю картинками, я мыслю образами и 20 лет тренировал свою голову, чтобы глядя на текст в ней правильные образы возникали и правильные взаимосвязи строились и все это проходило проверку на достоверность и непротиворечивость.
Выброске свои диаграммы и напишите требования простым и понятным языком. Сразу станут заметны косяки и несостыковки. А на диаграммах любую фигню нарисовать можно и никто не заметит.
У диаграмм есть своё место — описать общую архитектуру, чтобы новичок понял что с чем глобально связано. Ещё наброски UI. Для всего этого хватает квадратика и стрелочки. UML со своей хитрой семантикой нафиг тут не нужен.
диаграмм есть своё место — описать общую архитектуру
Мне в ответ
Как вы правильно заметили, UML не подходит для описания архитектуры
Я такого не отмечал, я сказал, что диаграммы полезны как оглавление для системы, чтобы новичкам было проще понять, что вообще есть. А еще я сказал, что большое количество диаграм не нужно, нужен структурированный текст, которые описывает, что система должна делать.
А упрощённый UML в ряде случаев оказывается вполне себе удобным средством нахождения единого языка.
Выброске свои диаграммы и напишите требования простым и понятным языком. Сразу станут заметны косяки и несостыковки. А на диаграммах любую фигню нарисовать можно и никто не заметит.
Всё в точности наоборот. Текст стерпит любые нестыковки и противоречия. В отличии от визуальной схемы, на которой даже далёкий от программирования человек (читай — менеджер) сходу увидит большинство проблем в той бизнес логике, которую он придумал.
Ага, тоесть нужно ещё гениальную команду вокруг вас обслуживающие образы в вашей голове…
А так нужно команду, обслуживающую семантику UML.
я не топлю за УМЛ вовсе…
Мой взгляд зацепило: "вы там свою работу сделайте сначала".
Довелось недавно столкнутся с оутсорсом в Белорусии. Сам я на западе социализировался в ИТ.
Мне в 2019 году рассказвают, что для успешного проекта надо 10 ролей (аналитик, тестировщик, писарь и редактор стори, узкотехнологичный программер сеньер., мид, джун… ) и каждый говорит "вы там свою работу сделайте сначала"….
Я пришел когда они каждый в своем бранже застряли и деплоить не могли на продукцию уже несколько месяцев. Причем большинство по отдельности вполне толковые были и знают свое (узкое) дело.
Роли смысл имеют, чтобы ответственность разделить и конвейер построить, но кто говорил, что у человека может быть только одна роль?
Мне то это понятно ;)
Вообще там где нет коммандности, доверия и работы над общими целями. Там ни процессы ни УМЛ не помогут.
А зачем выделять роли и ответственность? Чтобы виноватых искать?
Explicit is better than implicit. Во-первых, понятно, кто чем занимается, чтобы было ясно, к кому обращаться по вопросам конкретной тематики, во-вторых, меньше переключений между задачами. Ну и виноватых искать, да, когда всё общее, ответственность размывается, а когда какой-то кусок "мой" — порядка больше.
Ага, тоесть нужно ещё гениальную команду вокруг вас обслуживающие образы в вашей голове…
Если я программист, то образы в моей голове либо правильные и тогда я хороший программист, либо неправильные и тогда я плохой программист. Я очень хороший программист если понимаю, когда у меня в голове образы неправильные. Команда для обслуживания не нужна.
Нужно чтобы порядок у аналитика в голове был. Диаграммы со стрелочками этому порядку способствуют меньше, чем хорошо структурированные текст. Диаграммы что-то показывают на самом высоком уровне, их много быть не может, они не могут быть также нагружены семантикой, скорее они работают как оглавление. Если мы с этим согласимся, то следствие — UML не нужен, хватит квадратиков и стрелочек.
Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на ArchimateВ UML есть диаграмма компонентов, которая подходит для этого.
Сам пользуюсь для диаграмм plantuml.com/ru из-за удобства хранения в гите (и нормальной интеграцией с vs code).
Ну и совсем не упомянута диаграмма состояний, а это очень полезный инструмент. Почему-то у меня он самый часто используемый :)
Конечные автоматы в ПО достаточно частое явление.
Вот есть статья про их использование при отображении интерфейсов: frontstuff.io/using-state-machines-in-vuejs-with-xstate?utm_campaign=Vue.js%20News&utm_medium=email&utm_source=Revue%20newsletter
Главное в диаграмах состояния, по-моему, показать какие статусы вообще есть (спиок вполне заменит) и из какого состояния в какое сисетма не может перейти без грубого вмешательства
Вот сколько раз сталкивался с ситуацией, когда на картинке нарисовано одно, текстом написано другое, а в результате выясняется, что текст поправили, а картинку поправить забыли. Либо даже не забыли, а просто уже задолбались все это перерисовывать.
Теперь давайте пройдемся по вашим диаграммам:
1) UseCase. Вы совершенно правильно написали, что перечень функций ГОРАЗДО проще указать текстом. И что стрелки с этими обобщениями и расширениями кого хочешь запутают и лучше использовать линии. Но еще забыли написать, что когда у вас этих функций с полсотни, а акторов с полтора десятка, у вас вся эта диаграмма прекратится в мусор. А если вся эта «красота» должна будет передана Заказчику в бумажном виде? Значит вам придется все это еще подгонять под формат печатной страницы. А если потребуется добавить новые блоки, то все эти блоки надо будет двигать. Выравнивание всего этого безобразия может занять часы, если не дни. И все ради того, чтобы указать акторов, связанного с этими вариантами использования. А в чем проблема указать это текстом? Да нет в этом никакой проблемы, просто напишите текстом в описании самого варианта использования.
2) Activity diagram. Опять та же самая проблема, что и для UseCase — куча бессмысленной работы по выравниванию/перемещению блоков и стрелок. Я уж не говорю, если требуется написать чуть больше информации, кроме названия действия, например, список передаваемых параметров. И самое-то главное, зачем? Вся эта задача прекрасно решается с помощью записи варианта использования либо в виде структурированного списка, либо путем классической формы оформления записи в две или три колонки.
3) Архитектура системы. Да, вот это вещь ценная. Но! Какое отношение она имеет к UML? Да никакого, вы и сами это написали.
4) Sequence diagram. Вот здесь я с вами действительно соглашусь, эта диаграмма может быть полезна.
5) Диаграмма классов. А вам не кажется, что для проектирования баз данных существуют отдельные, приспособленные для этого нотации, например, Crow’s foot? Зачем тут UML?
В сухом остатке: 2 диаграммы — зло, одна полезная, еще одна использована не по назначению при доступном лучшем аналоге, и одна вообще к UML не относится.
Т.е. 1:4 против UML.
В проекте нужно было в приложении показывать небольшие диаграмки для разъяснения работы модулей.
Вставил рисовалку диаграм в приложение. Используется бесплатная Javascript библиотека «mermaid.js»
Поддерживает несколько базовых типов диаграм.
Сами диаграммы описываются текстом и хранятся в базе с возможностью сохранения версий.
Текст интуитивно понятен, а для непонятных решений сделал список сниппетов (список примитивов между текстом и диаграмкой) ссылка на картинку.
Хорошо воспринимается «картинка» состоящая из не более 7 элементов.
Если больше, то что-то начинает ускользать от внимания.
В той же «Архитектурной схеме» на «картинке» есть несколько слове абстракций, причем, разные блоки, на разных слоях абстракции.
REST-API, Префильтр, Мобильное приложение, Портал, PostgreSQL, AmazonMQ.
Причем тут техническая реализация (PostgreSQL, AmazonMQ), со стандартом/протоколом (REST-API), модулями системы (Префильтр) и интеграция с другими системами (Портал, Мобильное приложение)
А потом удивляются, почему при изменении требований надо переписывать всю систему с нуля. :-)
Если у вас есть 20 подсистем в ЦОД и 15 внешних.
То может быть стоит задуматься над «типизацией» подсистем?
Чтобы можно было в зависимости от типа сразу понимать, какое окружение нежно для той или иной системы.
Посмотреть, можно ли как то уменьшить связность.
А то у вас PostgreSQL и AmazonMQ прибита ржавыми гвоздями к арзхитектуре.
Что уменьшает вам «пространство для маневра».
А так. Должны быть конкретные технические требования к приложению.
В рамках данных требований может оказаться, что MongoDB действительно не подходит.
Но в рамках данных требований может оказаться, что и PostgreSQL не подходит.
А вы решили, что будет PostgreSQL. Почему. Зачем.
На «картинке» это не видно.
Что будет если заменить PostgreSQL на Oracle или MS SQL?
Сильно ли измениться архитектура…
И т.д.
Так что чем больше я смотрю на картинку вашей архитектуры, тем больше она меня смущает.
:-)
Это не проблема диаграммы, это проблема компетенций. Видимо вы дали свободу выбора человеку, который не знает БД (в широком смысле) настолько хорошо, чтобы делать выбор не на основании маркетинга, а на основании задачи.
Если ваша цель «быстро и красиво» (например, для презентации или для этой статьи), то Visio подходит более чем: его редактор удобен и прощает любые отступления от нотации.Если нужно не обзятательно красиво и точно, но чтобы очень быстро, то советую попробовать UMLet. Из плюсов: бесплатный, миниатюрный, можно таскать на флешке. Благодаря быстрому процессу редактирования очень удобно использовать в качестве «листа бумаги».
я пока остановился на вебовском draw.io, который позволяет и быстро рисовать, и автоматически менять компоновку, сохранять все в текстовый файл для версионирования…
Так как пока не особо погружался в этот инструмент, буду рад узнать, есть ли какие-то существенные недостатки у данного редактора, почему о нем тут никто не вспомнил, или просто он малоизвестен?
Тоже пользуюсь draw.io для рисования несложных схем (например набросок машины состояний).
У меня сложилось впечатление, что это максимально универсальный сервис (много разных наборов элементов, в т.ч. из UML), но, как следствие, для каждой из более узких задач есть варианты получше.
Например, для проектирования БД намного удобнее использовать что-то, что заточено на entity-relationship model и т.д., со всей сопутствующей функциональностью.
Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.
При использовании специализированных инструментов нет возможности использовать трассировочные связи с другими видами диаграмм. Ну и не очень понятен смысл специализации скажем в реляционных СУБД. Что в них такого специфического? Типы данных? Это вопрос поддержки инструмента в актуальном состоянии.
При этом универсальные инструменты в том же Sparx EA позволяют достаточно удобные вещи: например автоматическую генерацию DDL не только на создание БД, но и на изменение. Это очень удобно при переносе изменений между средами.
Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate:
Почему приведенный пример архитектурной схемы не отрисовывается на UML ? Archimate по сути это такой упрощенный вариант UML, такой архитекторский "суржик" :)
Например компонентная диаграмма:
https://www.uml-diagrams.org/component-diagrams.html
При этом помимо перечисленных ОСНОВНЫХ компонентов при необходимости можно использовать и другие элементы. Например я часто использую на компонентных диаграммах information flow (хотя если нужно, то в EA можно использовать старый добрый DFD), могу отразить отношения композиции (помимо визуальной вложенности компонентов). UML ничем не ограничивает использование дополнительных элементов при условии, что мы обеспечиваем адекватную интерпретацию этой диаграммы
UML для разработчиков