От переводчика:

Я веду телеграмм‑канал, посвященный системному анализу, и провожу тренинги, и в какой‑то момент задался вопросом — а актуален ли сейчас UML? Если посмотреть обсуждения на SO, Reddit'e и в блогах — видно очень много постов в вопросом «Is UML Dead?». Я начал искать публикации на эту тему, и через некоторое время обнаружил этот пост, в котором были ссылки на статьи, которые я уже нашел, и ещё на некоторые, которых я до этого не видел. Мне показалось, это очень хороший сборник мнений, если вас тоже интересует судьба UML.

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

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

Диаграмма последовательности описывает операции внутри системы и показывает, какие сообщения отправляются и когда.

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

Если вы даже не использовали их сами, вы, вероятно, слышали о них в одном из двух контекстов: во-первых, изолированно, как полезный тип диаграмм для рассмотрения при написании документации, или, во-вторых, как артефакт редко используемого сейчас Унифицированного языка моделирования (UML) конца 1990-х годов.

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

Мой интерес исходит из двух причин: я считаю, что диаграммы последовательностей недооценены и недостаточно используются, и я думаю, что диаграммы последовательностей — идеальный вариант использования для MermaidChart, поскольку он позволяет пользователям выбирать неформальную простоту вместо сложности и жесткости, возникающих при использовании старых инструментов, таких как Rational Rose от IBM.

Взлет и падение UML

UML как стандарт появился в 1997 году, и, как писал Мартин Фаулер, его основная цель заключалась в том, чтобы «положить конец хаосу, который охватил графические языки моделирования в мире объектно-ориентированного программирования». Основная проблема, которая повторялась много раз в истории разработки программного обеспечения, заключалась в том, что существовал хаос и путаница, и у людей было реальное желание какого-то единого стандарта, обеспечивающего ясность.

Компания Rational Software начала разработку UML в 1994 году; OMG приняла его в качестве стандарта в 1997 году; Международная организация по стандартизации (ISO) приняла его в качестве признанного международного стандарта в 2005 году (ISO/IEC 19501:2005 , стандарт версии UML 1.4.2. UML2 и последующие стандартизированы как ISO/IEC 19505-1:2012 и ISO/IEC 19505-2:2012 — прим. переводчика).

Взлет UML сопровождался и восторгом, и критикой, даже когда он стал стандартом (по крайней мере, на бумаге). Многим он нравился, но многие другие сталкивались с проблемами либо с самим UML, либо с тем, как люди его использовали. Статья 2004 года от архитектора программного обеспечения компании Boeing под названием «Смерть от лихорадки UML» отражает некоторые из проблем.

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

С тех пор было написано некоторое количество некрологов, включая статью 2018 года от Ивара Якобсона (который был вице-президентом Rational Software, когда UML становился стандартом), статью 2021 года от Хиллела Уэйна (который брал интервью у некоторых важных людей тех времен, таких как Гради Буч и Бертран Мейер), и статью 2022 года от Лоуренса Трэтта (который непосредственно участвовал в стандартизации UML).

Все эти статьи стоит прочитать, но все они приходят к схожему объяснению: UML стал слишком сложным (например, документация UML 2.2 составляла более 1000 страниц), и стал ассоциироваться с обременительной и зачастую бесполезной предварительной работой.

UML: жизнь после смерти

Мы говорим, на минуточку, о методологии почти 30-летнего возраста — методологии, которую и её сторонники и её противники считают окончательно умершей (не совсем точно — Якобсон, например, считает, что все просто неправильно её используют — прим. переводчика).

И вот, исследование 2014 года показывает — к удивлению самих его авторов — что большинство опрошенных разработчиков и архитекторов создают эскизы и диаграммы, которые «содержат хотя бы некоторые элементы UML». Исследователи отмечают, что «большинство таких диаграмм неформальные», но, тем не менее, это удивительно активная жизнь поле смерти!

Иногда тема «смерти UML» всплывает в обсуждениях, и мы можем видеть, как люди относятся к UML в наши дни. В этом обсуждении на HackerNews, например, один из участников спрашивает — имеет ли смысл тратить время на изучение UML, и, хотя большинство ему отвечает, что UML сам по себе бесполезен, многие рекомендуют изучить хотя бы несколько техник UML (диаграмму последовательности в первую очередь).

Один пользователь даже пишет, что «польза от понятной диаграммы последовательности перевешивает боль и скуку изучения всего остального UML в универсистете», а это довольно сильная рекомендация, как по мне. А ещё более сильная рекомендация исходит от Марка Уотсона, который был соавтром целой книги по UML, а сейчас говорит: «Диаграмма последовательности — единственный вид диаграмм, который я теперь использую».

Мы можем проследить причины такой живучести диаграммы последовательности в истории происходения UML. Во времена расцвета UML Мартин Фаулер описал три кейса использования UML: эскизы и наброски; точные чертежи и программирование.

Программирование на UML умерло в зародыше, т.к., согласно Хиллелу Уэйну, «даже большинство сторонников UML признавали, что это ужасная идея». UML как чертеж будущей системы выглядел самым стойким, но также скончался, т.к. был привязан к Rational Software и CASE‑средствам, которые умерли и утащили UML с собой.

Первый вариант использования — создание эскизов — выжил, но, как пишет Уэйн, «распался на множество непонятных друг для друга диалектов». Трэтт соглашается: оглядываясь назад, можно сказать, что UML достиг своего расцвета в 2000 году «как инструмент для создания эскизов и набросков программного обеспечения».

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

Диаграммы последовательности восстают из пепла

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

Потоки сообщений могут быть довольно сложными, но диаграмма последовательности предлагает два элемента, передающих основную суть:

• линии жизни, показывающие объекты и процессы.

• сообщения, показывающие обмен информацией во времени.

Базовые элементы должны быть простыми, поскольку диаграмма показывает систему в работе, то есть представленные элементы будут запущены одновременно, в определенном порядке и в параллель друг с другом. Хорошая диаграмма последовательности показывает поток, сообщения, которыми обмениваются объекты, и функцию, для выполнения которой все объекты объединяются, пока не «умрут».

Основные способы применения для диаграммы последовательности:

• Эскизные наброски и проектирование того, как будет работать система, ещё до её разработки.

• Документирование требований к новой системе.

• Разбор и понимание, как работает существующая система (часто — разбор легаси‑систем).

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

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

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

Проектирование диаграмм последовательности «изнутри наружу»

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

Начните с основного пути и проработайте граничные случаи

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

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

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

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

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

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

Понятность лучше всеобъемлемости

Наиболее распространенная причина провала диаграмм последовательности — чрезмерное усложнение. (Это также причина провала большинства диаграмм, как я писал в статье о блок-схемах).

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

Игнорирование — это сложная часть. Поскольку цель диаграмм — коммуникация, важно выбросить часть информации, чтобы прояснить другую информацию. Фаулер напоминает нам, что «код — лучший источник всеобъемлющей информации», поэтому диаграммы — по своей природе — не должны быть всеобъемлющими (именно для этого и нужен код). Фаулер хорошо это выразил, написав, что «всеобъемлемость — враг понятности». (в оригинале игра слов: “Comprehensiveness is the enemy of comprehensibility.”  — прим. переводчика)

Вы можете хорошо это увидеть на диаграмме последовательности ниже, которую разработчик приложил к PR, попросив команду «рассмотреть возможность вынести менее значимую информацию из диаграммы, чтобы читающий её разработчик мог сосредоточиться на действительно важных идеях».

В своей статье о смерти UML Томас Бейл пишет, что главная причина, по которой UML стал слишком сложным, заключается в том, что создатели пытались «определить единую метамодель», которая могла бы выдать все элементы, необходимые для более чем дюжины типов диаграмм. Бейл утверждает, что «каждый тип диаграммы на самом деле представляет собой определенное пространство концепций, которому нужна своя собственная частная модель».

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

Общая картина лучше деталей

Если предыдущая проблема является результатом попытки быть слишком всеобъемлющим и смотреть слишком широко, то следующая проблема является результатом попытки быть слишком подробным и смотреть чересчур узко.

В статье Алекса Белла о «лихорадке» UML одним из многих «штаммов», которые он описывает, является «лихорадка мушиной брови» (в оригинале: “Gnat’s eyebrow fever”, примерный аналог в современном русском языке — «докопаться до мышей») и это одна из наиболее вероятных проблем, которая поразит ваши диаграммы последовательностей. Он описывает эту лихорадку как «очень сильное желание создавать диаграммы UML, которые будут чрезвычайно подробными» и утверждает, что она следует из убеждения, что отображение гранулированных деталей «увеличивает вероятность того, что итоговый код будет более правильным».

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

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

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

Освоение архитектурного мышления через диаграмму последовательности

Цель этой статьи не в том, чтобы рассматривать диаграммы последовательностей из чистого исторического любопытства. Диаграммы последовательностей — это не только артефакт UML, но и артефакт мышления при проектировании программного обеспечения, которое подчеркивает тщательность проектирования и планирования.

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

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

«Суть», которую подчеркивает Якобсон в своей статье о смерти UML, «заключается в том, чтобы каждый спринт начинался с архитектурного мышления». С помощью диаграмм последовательностей, в частности, вы можете лучше понять текущие процессы, что упрощает создание или улучшение их частей.

Кнут Свейдквист
автор MermaidJS, основатель Mermaid Chart

От переводчика:

Ещё до того, как я нашел статью Кнута, я решил повторить исследование 2014 года, на которе он ссылается. Я перевел вопросы на русский язык, и добавил пару вопросов, уточняющих использование UML. Я был бы вам благодарен, если бы вы нашли 5 минут и прошли короткий опросник: Исследование по использованию UML.

О результатах напишу на Хабре.