UML для разработчиков

    Интернет полон статей про UML, вы найдете сотни примеров для каждого вида диаграмм, и без проблем создадите свои, нотация не сложная. Но так ли уж необходимо тратить на это время? Наш богатый опыт говорит «Да». Если у вас в команде более 2 человек и проект от 3 месяцев, то уже имеет смысл отрисовать 2-3 вида диаграмм. В одной нашей команде более 30 человек, проект длительностью более 3 лет, и мы используем...2-3 вида диаграмм.

    Нотация UML избыточна. С другой стороны она недостаточна для проектирования распределенных систем, и здесь нам помогает Archimate. В этой статье мы расскажем, что действительно полезно из всего этого многообразия, и рассмотрим на примере полный цикл создания диаграмм для проекта.

    В чем будем рисовать?


    Если ваша цель «быстро и красиво» (например, для презентации или для этой статьи), то Visio подходит более чем: его редактор удобен и прощает любые отступления от нотации.

    Если же вы занимаетесь проектированием, то потребуется полноценная система с поддержкой связей между диаграммами. Мы используем продукт Enterprise Architect, дешево и сердито.
    Сравнение систем проектирования и рассказ о том, как ими правильно пользоваться — тема для отдельной статьи.

    Техническое задание


    Мы будем проектировать гипотетическое мобильное приложение для изучения иностранных языков. Техническое задание обычно готовят аналитики, которые и подготовят первую партию диаграмм. От разработчиков, в данном случае, требуется только правильно их читать.

    Самая простая диаграмма — Use Case (Варианты использования):



    На диаграмме указаны виды пользователей и перечислены функции или группы функций, которые с ними связаны. Синим цветом выделен элемент, которого в UML нет, но его часто не хватает: Requirement — Требование (из нотации Archimate), уточнение функций.

    Вы спросите — и какой в этом смысл? Ведь перечень функций можно указать просто текстом, одним компактным списком! И будете правы, но есть нюансы.

    1. Некоторые функции относятся к нескольким пользователям, текстом это отобразить сложно.
    2. Когда вы отрисовываете все функции и требования в системе проектирования, вы можете их потом выгрузить в ту же Jira, и в дальнейшем связывать их с задачами и багами, что упрощает управление проектом.

    Почему мы смешали на одной диаграмме UML и Archimate? Не нужно строго следовать нотациям, вам с этим не экзамены сдавать в университете, а с командой общаться, для которой вы это все и готовите.

    Почему для связи элементов мы использовали линии, а не стрелки? Потому что никто не помнит, как выглядят стрелки «Обобщение» и «Расширение», и что они вообще такое. Чем проще вы нарисуете, тем больше людей поймет диаграмму без вашего участия.

    Второй вид диаграмм, который вы можете встретить в техническом задании, это Activity diagram:



    Здесь для разработчика все очевидно, кроме одного: почему AI делает вызовы Студента? Не делает. Эту диаграмму рисуют аналитики, а не программисты, они не знают где клиент, а где сервер, и их не интересуют потоки данных. На Activity diagram вы видите последовательность действий и не более того. Как же из этого сделать код? Переходим к этапу проектирования.

    Проектирование архитектуры


    Архитектура мобильного приложения очевидна: клиент, сервер, база данных. Если мы проектируем что-то серьезное, то следует позаботиться о разбиении проекта на Подсистемы, в нашем случае это будут как минимум:

    • Подсистема бронирования уроков
    • Подсистема Web-тренировок
    • Биллинг
    • Подсистема управления записями голосов

    Подсистемы должны быть изолированы друг от друга: собственные базы данных без реляционных связей с другими подсистемами, общение между подсистемами только через API. Подсистема может быть как набором микросервисов, так и монолитом, на ваше усмотрение.

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

    Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate:



    Даже без знания нотации схема, в целом, читаема. Помните, что 90% участников вашей команды не знают ни UML, ни тем более Archimate, и никогда не выучат эти нотации, поэтому делайте упор на надписи. Тем не менее, пара слов о кубиках и стрелочках:



    Полную спецификацию Archimate вы найдете без труда.

    Цвет — на ваш вкус, нотация никак их не регламентирует. Раскрасьте одним цветом текущую подсистему, вторым — смежные подсистемы, третьим — внешние системы, это сильно повышает читаемость схемы.

    На схеме используется всего два вида стрелок: Flow (Поток) и Access (Вызов, Доступ). Поток показывает направление передачи данных, а Вызов — кто к кому обращается. Следует правильно понимать стрелку Поток:



    На схеме не отображен поток от мобильного приложения к серверу, хотя на самом деле он есть (первым идет поток «Запрос данных»). Делается это для того, чтобы схема проще читалась: показываем только самое важное. То, что есть еще и исходный Запрос данных и так очевидно из кубика с надписью API.

    Детализация


    Последние две диаграммы, которые очень полезны (внимательный читатель конечно заметил, что всего видов диаграмм уже не 2-3): Sequence diagram (Диаграмма последовательности) и Class Diagram (Диаграмма классов, но вовсе не для классов).

    Иногда взаимодействие клиента и сервера многоступенчатое, с использованием третьих ресурсов. Например, авторизация с Oauth2: текстовое описание этого процесса весьма затруднительно для понимания. Здесь нам поможет Sequence diagram:



    Данная реализация Oauth2 не эталонная, вариантов может быть много. Самое главное, что нужно понимать на схеме — на этой диаграмме нет потоков данных, только Вызовы и Ответы на вызовы. Хотя это не помешало нам указать потоки текстом на стрелках.

    Когда вы углубитесь в изучение Sequence diagram вы обнаружите, что она позволяет отобразить циклы и ветвления, но не злоупотребляйте ими: не нужно на одной диаграмме рисовать ветки «Если пользователь выбрал локальную авторизацию, то» и «Если выбрал авторизацию FB, то», вместо этого нарисуйте две схемы под каждый вариант. Условия, особенно вложенные, на Sequence diagram очень сильно снижают читаемость схемы.

    Последняя диаграмма (не на сегодня, а вообще) — Диаграмма классов. Название у нее говорящее, предполагалось, что с помощью нее будут проектировать классы. В давние времена текстовых редакторов под DOS это может и было оправдано, но современные среды разработки позволяют проектировать и анализировать классы не покидая их темных и светлых тем.

    Но практическое применение у Class Diagram все же осталось — проектирование баз данных:



    Если вы знаете, что такое Реляционные базы данных, то это более чем наглядно. Полностью атрибуты на схеме не расписываются, указываются только связи, типы данных, иногда ограничения.

    Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.

    На этом все. Из всех диаграмм в UML и Archimate на практике более чем достаточно перечисленных. Сколько диаграмм каждого вида нужно для проекта? Рисовать ли их под каждый процесс и подсистему? Главное правило — диаграмма сопровождает текстовое описание, она нужна только там, где текста недостаточно, т.е. там, где команда вас не понимает.

    Спасибо за внимание, с вами была компания «Программный продукт».
    Программный Продукт
    Создаем решения для государства и бизнеса

    Комментарии 74

      +3

      В добавление: из свободных продуктов удобны Umbrello и Dia.
      Linux — искаропки, Windows и macOS — есть инсталяторы.

        +1
        Спасибо, учтем эти продукты, когда будем делать сравнение систем проектирования
          0
          Ещё Modelio для Eclipse. Весьма функционален, хотя по сравнению с EA с т.зр. юзабилити проигрывает.
          +2
          Наш опыт говорит практически твердое «нет».

          Причина простая, по этой же причине не находят массового распространения многие средства так называемого «визуального программирования» — нет нормального версионирования диаграмм (хочу заметить, что и вы тут о нем не упоминаете вообще, как будто его и не существует в природе — и для меня это звоночек).

          Что значит «нет нормального версионирования диаграмм»? А значит, что если с диаграммой на изменение работает более одного человека, то вы не сможете удобно посмотреть историю изменений, не сможете зачастую сравнить две разные версии, чтобы понять, кто, что и где менял. Может, что и изменилось, но когда мне приходилось с этим работать, такого хорошего инструмента не было.

          Поэтому оно работало до тех пор, пока диаграмму менял один человек, который помнил, что делает. А остальным раздавали результаты генерации из нее в виде кода, например.

          Ну то есть, бывают случаи, когда это работает. Но как только нужно править вдвоем — тут же возникают сложности.
            +1
            Да, с версионностью в системах проектирования очень туго, это одна из причин, по которой создается минимальный набор схем. Обратите внимание, в статье описаны схемы только для документации (как пояснения к тексту), и ни одной схемы для генерации исходного кода. При работе с набором схем в команде мы используем блокировки на редактирование, защищает от случайных правок. Предыдущие версии сохраняются либо вне системы, либо ветками в дереве диаграмм.
              +4
              Существует язык PlantUML, с помощью которого диаграммы представлют в виде кода.
              Встречал проект, в котором было много анализа и диаграммы как код хранились в гите.
                0
                да, наши разработчики однажды пробовали это использовать, не прижилось. Большие диаграммы потом сложно редактировать.
                  +2

                  большие диаграммы легко бьются на части, которые редактировать гораздо проще.
                  основная сложность, имхо — это замотивировать и наладить процесс вести документацию в таком виде.

              +1
              Версионирование поддерживается, например, в Visual Paradigm соответствующей редакции (есть и бесплатные). Часто бывает, что в чужом коде сложно разобраться и пока рисуешь диаграмму приходит понимание. На корпоративном уровне не весь код пишется внутри, есть и сторонние разработки без документации. Благо если есть комментарии.
                +2
                Чтобы разобраться, имеет смысл построить диаграмму из кода. Это несколько другой случай, вполне осмысленный
                  0
                  Спасибо, рассмотрим этот продукт
                  +3

                  поддерживаю!
                  из-за необходимости версионирования начали обучение аналитиков PlantUML (прошло, кстати, без сопротивления с из стороны).
                  Visio и т.п. — это как презентации в PowerPoint: для одноразового применения для красивой подачи, но ни как не для командной работы.

                    0
                    жаль, что архитектурную схему в PlantUML не нарисовать
                      0

                      там и остальные-то рисуются не то, чтобы фонтан (визуально, если с Visio тем же, например, сравнивать).
                      но если рассматривать как компонент подхода к автоматической генерации документации, то вполне себе вариант.
                      ps: ну и можно принять участие в разработке PlantUML
                      pps: архитектурные схемы, если я правильно понял, о чем речь, меняются все-таки очень редко

                        +1
                        Что такое архитектурная схема, и почему ее нельзя нарисовать в PlantUML?

                        У меня в компании это рекомендованый инструмент для создания архитектурных диаграмм. Поднят рендер сервер, разработчики коммитят в git .puml файлы, которые потом в README.md отображаются картинкой.
                          +1
                          Диаграмма компонентов из UML: plantuml.com/ru/component-diagram
                          Поддержка archimate: plantuml.com/ru/archimate-diagram
                        0
                        В EA функционал версионирования есть. Правда, признáюсь честно, не использовал ни разу. Судя по документации, поддерживаются SVN, CVS и ещё какая-то экзотика. Отсутствие Git в 2020 году, конечно, странно, но если очень надо — можно ради них и SVN откопать, наверное.
                          0
                          На обучении по EA рассказывали следующий вариант: проекты сохраняются в файл (не в БД), в расшаренной папке на всю команду. Файл по мере необходимости комитится в репозиторий. На самом деле это не жизнеспособный вариант.
                            0
                            У нас на проекте активно используется связка ЕА+SVN. И вроде оно даже работает (за вычетом некоторых глюков), но реального версиорования недает.
                            ЕА сохраняет содержимое пакета в XML, а оный уже в svn. То есть в случае какой либо проблемы всегда можно откатить, или найти по истории правок «виноватого».
                            Но работать с этим за отсутсвием диффа не очень удобно, потому все равно не видно кто и что конкретно поменял (тем более что все ленятся писать историю в коммиты).
                          0

                          Визио + хранение на Onedrive или Sharepoint. Вполне решает проблему с контролем версий.

                            0
                            В Visio другая проблема, нет связей между диаграммами, в ряде случаев это большая проблема, но об этом мы расскажем в другой статье
                              0
                              Каким образом оно решает проблему сравнения?
                                0
                                Проблемы сравения оно не решает, но позволяет автоматически хранить версии документа
                                  0
                                  Ну, версии документа (даже бинарного) позволяет хранить что угодно. Вопрос не в этом.

                                  Вот у вас есть две версии диаграммы. И нет автора изменений. Как вы будете узнавать, что именно поменялось? Редактор просто стрелочки подвигал, чтобы было красиво, или скажем изменил кардиналити у одной из них?

                                  Проблема коллективной работы с подобными (не текстами) состоит именно в том, что не слишком просто (и это мягко сказано) сравнить две версии семантически.

                                  В итоге у нас, когда я это последний раз применял, это выглядело так — у диаграммы был один автор. Это была диаграмма классов. Из нее генерировались классы для CRUD, и схемы базы данных. В итоге, если автор не напишет всем почтой: «Я поменял вот это и вот это» — черта с два вы просто так узнаете, что в очередной версии изменилось.
                                    0
                                    PlantUML в git решает эту проблему :)
                                    Другое дело, что визуализация, конечно, после визио не впечатляет. Надо самому попробовать, чтобы понять, насколько быстрее и удобнее.
                            0
                            Почему для связи элементов мы использовали линии, а не стрелки? Потому что никто не помнит, как выглядят стрелки «Обобщение» и «Расширение», и что они вообще такое. Чем проще вы нарисуете, тем больше людей поймет диаграмму без вашего участия.

                            Какое отношение эти диаграммы тогда будут иметь отношение к UML диаграммам? Это просто будут "какие-то диаграммы". Изначальная фраза "UML в работе важен и нужен" сводится до банального "картинки в работе нужны и важны".


                            Проблема тут важная.
                            Если рисовать UML то люди поделятся на две категории: кто хоть что-то уловил, общий смысл будет понятен, но также будут и люди, которые увидят более полный и глубокий смысл. Это как с картинами художников: лично я вижу только что-то совершенно явное, искусствовед видит на три смысловых слоя больше.
                            Упрощённый же UML (как пинглиш, как рисунок ПМХ на заборе) понятен якобы всем, но во-первых, в нём вряд ли будет глубина и допонительные смысловые слои — особо вглядываться там некому, во-вторых и понятность достигается за счёт упрощения и загрубления картинки. (Так и нужен вам тогда UML, если вам просто достаточно кружочков и палочек?)
                            И вторая проблема. Что UML действительно перегружен до непрактичности. Тем не менее, я те диаграммы, которые рисую постоянно знаю достаточно хорошо. Т.е. вопрос именно в достаточной практике.

                              +3
                              линии без стрелок в UML есть, это «Ассоциация», т.е. «какая-то связь» между двумя объектами. Формально мы не нарушаем нотацию UML, а подписями к стрелкам даем необходимую детализацию (глубину).
                              +1
                              Если вы знаете, что такое Реляционные базы данных, то это более чем наглядно.… Не пытайтесь рисовать это в Visio,
                              Вот тут я с вами не согласен. Есть у меня проект старенький (2007 года), в нём БД для MS SQL Server. Рисовали, обсуждали, генерировали DDL Script, писали документацию с помощью MS Visio. С версиями тогда не было проблем, т.к. за всё я один отвечал. Пробовал и другие системы, но не прижились они.
                                0
                                из Visio вы в MS SQL Server базу потом не сконвертируете, а из специализированных систем для СУБД — запросто. Причем там будет доступен и реверс-инжиниринг базы.
                                  +1
                                  Не буду утверждать, какой сейчас у Visio функционал, но в 2007-2010 я генерировал DDL и в MS SQL Server выполнял. Запросто. Возможно это была версия Enterprise или Team Suite…
                                  /* 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. */
                                +2
                                Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.

                                Не полностью согласен с этим утверждением в части Enterprise Architect (EA):
                                1. EA вполне себе подходит для ER-диаграмм, сам использовал для проектирования новой БД и для Reverse Engineering из MSSQL и Oracle существующих БД.
                                2. Еще в EA есть возможность генерации документации по ER-диаграмме (схеме) БД с заданным шаблоном: можно генерировать документацию по структуре БД, с описанием таблиц, столбцов и прочего. Шаблоны можно под себя подстраивать и если потратить немного времени, то сразу в получать документацию в требуемом оформлении. Лучше день потерять, потом за час долететь (с) ;)
                                  –2

                                  Мне, извините, плевать на стрелочки с квадратиками. Я не мыслю картинками, я мыслю образами и 20 лет тренировал свою голову, чтобы глядя на текст в ней правильные образы возникали и правильные взаимосвязи строились и все это проходило проверку на достоверность и непротиворечивость.


                                  Выброске свои диаграммы и напишите требования простым и понятным языком. Сразу станут заметны косяки и несостыковки. А на диаграммах любую фигню нарисовать можно и никто не заметит.


                                  У диаграмм есть своё место — описать общую архитектуру, чтобы новичок понял что с чем глобально связано. Ещё наброски UI. Для всего этого хватает квадратика и стрелочки. UML со своей хитрой семантикой нафиг тут не нужен.

                                    +1
                                    к сожалению, не все могут натренировать голову и создавать правильные образы, и не у всех есть опыт работы 20 лет. Требования и процессы должны быть понятны для всей команды, поэтому приходится рисовать схемы. Как вы правильно заметили, UML не подходит для описания архитектуры, в статье как раз описан другой подход
                                      0
                                      Бррр… я пишу
                                      диаграмм есть своё место — описать общую архитектуру

                                      Мне в ответ
                                      Как вы правильно заметили, UML не подходит для описания архитектуры


                                      Я такого не отмечал, я сказал, что диаграммы полезны как оглавление для системы, чтобы новичкам было проще понять, что вообще есть. А еще я сказал, что большое количество диаграм не нужно, нужен структурированный текст, которые описывает, что система должна делать.
                                      +1
                                      По своему скромному опыту могу сказать, что попытки «описать требования простым и понятным языком» между предметными специалистами (в моём случае юристами) и разработчиками всегда заканчивались эпическим фиаско. Потому что понятия о том, какой язык «прост и понятен», у этих двух категорий ну очень уж кардинально различаются.
                                      А упрощённый UML в ряде случаев оказывается вполне себе удобным средством нахождения единого языка.
                                        +1
                                        Выброске свои диаграммы и напишите требования простым и понятным языком. Сразу станут заметны косяки и несостыковки. А на диаграммах любую фигню нарисовать можно и никто не заметит.

                                        Всё в точности наоборот. Текст стерпит любые нестыковки и противоречия. В отличии от визуальной схемы, на которой даже далёкий от программирования человек (читай — менеджер) сходу увидит большинство проблем в той бизнес логике, которую он придумал.

                                          –1

                                          Ага, тоесть нужно ещё гениальную команду вокруг вас обслуживающие образы в вашей голове…

                                            0

                                            А так нужно команду, обслуживающую семантику UML.

                                              0

                                              я не топлю за УМЛ вовсе…
                                              Мой взгляд зацепило: "вы там свою работу сделайте сначала".


                                              Довелось недавно столкнутся с оутсорсом в Белорусии. Сам я на западе социализировался в ИТ.
                                              Мне в 2019 году рассказвают, что для успешного проекта надо 10 ролей (аналитик, тестировщик, писарь и редактор стори, узкотехнологичный программер сеньер., мид, джун… ) и каждый говорит "вы там свою работу сделайте сначала"….
                                              Я пришел когда они каждый в своем бранже застряли и деплоить не могли на продукцию уже несколько месяцев. Причем большинство по отдельности вполне толковые были и знают свое (узкое) дело.

                                                0

                                                Роли смысл имеют, чтобы ответственность разделить и конвейер построить, но кто говорил, что у человека может быть только одна роль?

                                                  0

                                                  Мне то это понятно ;)
                                                  Вообще там где нет коммандности, доверия и работы над общими целями. Там ни процессы ни УМЛ не помогут.

                                                    0

                                                    А зачем выделять роли и ответственность? Чтобы виноватых искать?

                                                      0

                                                      Explicit is better than implicit. Во-первых, понятно, кто чем занимается, чтобы было ясно, к кому обращаться по вопросам конкретной тематики, во-вторых, меньше переключений между задачами. Ну и виноватых искать, да, когда всё общее, ответственность размывается, а когда какой-то кусок "мой" — порядка больше.

                                                0
                                                Ага, тоесть нужно ещё гениальную команду вокруг вас обслуживающие образы в вашей голове…

                                                Если я программист, то образы в моей голове либо правильные и тогда я хороший программист, либо неправильные и тогда я плохой программист. Я очень хороший программист если понимаю, когда у меня в голове образы неправильные. Команда для обслуживания не нужна.


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

                                                  +1
                                                  Ну-ну. Текст, конечно, нужен. Но одна картинка 500 на 500 пикселей может заменить десяток страниц текста описания конечного автомата в плане «напомнить, как же оно работает». Вы, видимо, мало работали в команде, когда одну фичу пилят по очереди несколько сотрудников (для уменьшения фактора автобуса).
                                              +2
                                              Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate
                                              В UML есть диаграмма компонентов, которая подходит для этого.
                                              Сам пользуюсь для диаграмм plantuml.com/ru из-за удобства хранения в гите (и нормальной интеграцией с vs code).

                                              Ну и совсем не упомянута диаграмма состояний, а это очень полезный инструмент. Почему-то у меня он самый часто используемый :)
                                                +1
                                                Я за все время диаграмму состояний встречал только один раз — когда в Jira настраивал процессы. А в документации не приходилось сталкиваться.
                                                  0
                                                  Ну, если работать с чем-то у чего есть статусы, то диаграммы состояний незаменимы. особенно когда статусов много и они должны переходить друг в друга автоматически и вручную. Далее к каждому переходу свои описания и диаграммы.
                                                  Конечные автоматы в ПО достаточно частое явление.
                                                  Вот есть статья про их использование при отображении интерфейсов: frontstuff.io/using-state-machines-in-vuejs-with-xstate?utm_campaign=Vue.js%20News&utm_medium=email&utm_source=Revue%20newsletter
                                                    0
                                                    Да, видимо мы просто в разных областях с вами работаем. Думаю в проектах по документообороту без диаграммы состояний не обойтись.
                                                      +1

                                                      Главное в диаграмах состояния, по-моему, показать какие статусы вообще есть (спиок вполне заменит) и из какого состояния в какое сисетма не может перейти без грубого вмешательства

                                                  +3
                                                  Выскажусь как Аналитик/Руководитель группы с многолетним стажем. Из моего опыта могу сказать, что сам по себе UML откровенно бесполезная штука, лишь увеличивающая объем работы и генерящий ошибки на проекте. Жаль, что многие Аналитики попросту боятся об этом сказать своему руководству прямо.

                                                  Вот сколько раз сталкивался с ситуацией, когда на картинке нарисовано одно, текстом написано другое, а в результате выясняется, что текст поправили, а картинку поправить забыли. Либо даже не забыли, а просто уже задолбались все это перерисовывать.
                                                  Теперь давайте пройдемся по вашим диаграммам:
                                                  1) UseCase. Вы совершенно правильно написали, что перечень функций ГОРАЗДО проще указать текстом. И что стрелки с этими обобщениями и расширениями кого хочешь запутают и лучше использовать линии. Но еще забыли написать, что когда у вас этих функций с полсотни, а акторов с полтора десятка, у вас вся эта диаграмма прекратится в мусор. А если вся эта «красота» должна будет передана Заказчику в бумажном виде? Значит вам придется все это еще подгонять под формат печатной страницы. А если потребуется добавить новые блоки, то все эти блоки надо будет двигать. Выравнивание всего этого безобразия может занять часы, если не дни. И все ради того, чтобы указать акторов, связанного с этими вариантами использования. А в чем проблема указать это текстом? Да нет в этом никакой проблемы, просто напишите текстом в описании самого варианта использования.
                                                  2) Activity diagram. Опять та же самая проблема, что и для UseCase — куча бессмысленной работы по выравниванию/перемещению блоков и стрелок. Я уж не говорю, если требуется написать чуть больше информации, кроме названия действия, например, список передаваемых параметров. И самое-то главное, зачем? Вся эта задача прекрасно решается с помощью записи варианта использования либо в виде структурированного списка, либо путем классической формы оформления записи в две или три колонки.
                                                  3) Архитектура системы. Да, вот это вещь ценная. Но! Какое отношение она имеет к UML? Да никакого, вы и сами это написали.
                                                  4) Sequence diagram. Вот здесь я с вами действительно соглашусь, эта диаграмма может быть полезна.
                                                  5) Диаграмма классов. А вам не кажется, что для проектирования баз данных существуют отдельные, приспособленные для этого нотации, например, Crow’s foot? Зачем тут UML?

                                                  В сухом остатке: 2 диаграммы — зло, одна полезная, еще одна использована не по назначению при доступном лучшем аналоге, и одна вообще к UML не относится.
                                                  Т.е. 1:4 против UML.
                                                    0
                                                    Спасибо за ваше мнение! Мы кстати ведем набор аналитиков с многолетним стажем
                                                      0

                                                      Ваша боль про "двигать стрелочки" и "задолбались перерисовывать" — следствие использования визуальных редакторов. Тут нужен PlantUML.

                                                      +1
                                                      Вот все так набросились на диаграммы классов — а как без них аналитику сущности предметной области визуализировать (DDD и вот это вот всё)? Можно, конечно, для этой задачи вообще строгой нотации не придерживаться и рисовать хоть от руки на бумажке — но если тот же EA уже куплен, то диаграммы классов для этой задачи, IMHO, вполне себе удобны.
                                                        +1

                                                        Абсолютно согласен, у нас на проекте обычно 50 и более бизнес сущностей. И все они как-то группируются и наследуются. Писать это текстом, конечно можно. Но куда проще кинуть взгляд на диаграмму.
                                                        Естественно, не всегда есть смысл делать одну гигантскую диаграмму, лучше разбить на несколько поменьше.

                                                        0
                                                        Диаграмки полезны, но отдельный инструмент держать не удобно в поддержке.

                                                        В проекте нужно было в приложении показывать небольшие диаграмки для разъяснения работы модулей.
                                                        Вставил рисовалку диаграм в приложение. Используется бесплатная Javascript библиотека «mermaid.js»
                                                        image
                                                        Поддерживает несколько базовых типов диаграм.
                                                        Сами диаграммы описываются текстом и хранятся в базе с возможностью сохранения версий.
                                                        Текст интуитивно понятен, а для непонятных решений сделал список сниппетов (список примитивов между текстом и диаграмкой) ссылка на картинку.
                                                          0
                                                          спасибо, рассмотрим этот инструмент
                                                            0

                                                            Попробуйте PlantUML. Всё как вы описали, только это более стандартизированное решение.

                                                              0
                                                              Спасибо за совет. Мыслим одинаково: на базе PlantUML и интегрировал — сначала понравилось решение с PlantUML в Atom, а затем реализовал похожее решение, только интегрированное в нашу среду.
                                                            +3
                                                            Проблема «веселых картинок» в том, что при увеличении количества элементов, когнитивная нагрузка возрастает.
                                                            Хорошо воспринимается «картинка» состоящая из не более 7 элементов.
                                                            Если больше, то что-то начинает ускользать от внимания.
                                                            В той же «Архитектурной схеме» на «картинке» есть несколько слове абстракций, причем, разные блоки, на разных слоях абстракции.

                                                            REST-API, Префильтр, Мобильное приложение, Портал, PostgreSQL, AmazonMQ.

                                                            Причем тут техническая реализация (PostgreSQL, AmazonMQ), со стандартом/протоколом (REST-API), модулями системы (Префильтр) и интеграция с другими системами (Портал, Мобильное приложение)

                                                            А потом удивляются, почему при изменении требований надо переписывать всю систему с нуля. :-)
                                                              0
                                                              на крупных проектах, к сожалению, не удается обойтись 7 элементами. На данный момент работаем на проекте из 20 подсистем в ЦОД, 15 внешних систем, еще и пользовательских устройств 8 видов (с оборудованием). Приходится увеличивать когнитивную нагрузку. Как вы правильно заметили, на Архитектурной схеме разные слои, это и есть особенности Archimate, которые очень помогают в описании проекта.
                                                                0
                                                                По мне, так это лишняя нагрузка.
                                                                Если у вас есть 20 подсистем в ЦОД и 15 внешних.
                                                                То может быть стоит задуматься над «типизацией» подсистем?
                                                                Чтобы можно было в зависимости от типа сразу понимать, какое окружение нежно для той или иной системы.
                                                                Посмотреть, можно ли как то уменьшить связность.
                                                                А то у вас PostgreSQL и AmazonMQ прибита ржавыми гвоздями к арзхитектуре.
                                                                Что уменьшает вам «пространство для маневра».
                                                                  +1
                                                                  Мы как-то оставили разработчику пространство для маневра, а он вместо реляционной базы добавил в проект MongoDB. Архитектурная схема должна быть более чем конкретная.
                                                                    +1
                                                                    Может быть вы за него еще и программу напишите? :-)
                                                                    А так. Должны быть конкретные технические требования к приложению.
                                                                    В рамках данных требований может оказаться, что MongoDB действительно не подходит.
                                                                    Но в рамках данных требований может оказаться, что и PostgreSQL не подходит.
                                                                    А вы решили, что будет PostgreSQL. Почему. Зачем.
                                                                    На «картинке» это не видно.
                                                                    Что будет если заменить PostgreSQL на Oracle или MS SQL?
                                                                    Сильно ли измениться архитектура…
                                                                    И т.д.
                                                                    Так что чем больше я смотрю на картинку вашей архитектуры, тем больше она меня смущает.
                                                                    :-)
                                                                      0

                                                                      Это не проблема диаграммы, это проблема компетенций. Видимо вы дали свободу выбора человеку, который не знает БД (в широком смысле) настолько хорошо, чтобы делать выбор не на основании маркетинга, а на основании задачи.

                                                                +2
                                                                Если уж речь зашла насчет проетирования баз данных, что думаете насчет IDEF1X?
                                                                  +1
                                                                  не приходилось использовать, но у партнеров в документации встречали. Если базу данных проектировать на IDEF, то и остальные схемы лучше делать по методологии IDEF
                                                                  0
                                                                  Используем в разработке диаграммы состояний. Инструмент QM в связке с QP от Quantum Leaps (state-machine.com). Наглядность, простота разработки.
                                                                    0
                                                                    Спасибо, рассмотрим этот инструмент
                                                                    0
                                                                    Если ваша цель «быстро и красиво» (например, для презентации или для этой статьи), то Visio подходит более чем: его редактор удобен и прощает любые отступления от нотации.
                                                                    Если нужно не обзятательно красиво и точно, но чтобы очень быстро, то советую попробовать UMLet. Из плюсов: бесплатный, миниатюрный, можно таскать на флешке. Благодаря быстрому процессу редактирования очень удобно использовать в качестве «листа бумаги».
                                                                      +1

                                                                      я пока остановился на вебовском draw.io, который позволяет и быстро рисовать, и автоматически менять компоновку, сохранять все в текстовый файл для версионирования…
                                                                      Так как пока не особо погружался в этот инструмент, буду рад узнать, есть ли какие-то существенные недостатки у данного редактора, почему о нем тут никто не вспомнил, или просто он малоизвестен?

                                                                        0

                                                                        Тоже пользуюсь draw.io для рисования несложных схем (например набросок машины состояний).
                                                                        У меня сложилось впечатление, что это максимально универсальный сервис (много разных наборов элементов, в т.ч. из UML), но, как следствие, для каждой из более узких задач есть варианты получше.
                                                                        Например, для проектирования БД намного удобнее использовать что-то, что заточено на entity-relationship model и т.д., со всей сопутствующей функциональностью.

                                                                        0
                                                                        неочень понял в чем радикальная разница между диаграммой компонентов в UML и «архитектурная диаграмма» на Archimate приведенная в статье, что на ней такое чего нельзя получить на UML?
                                                                          0

                                                                          А зачем получать на UML?

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                        Самое читаемое