Всем привет! Меня зовут Александр Нилов, я архитектор департамента Логистика КОРУС Консалтинг. В этой статье расскажу, почему мы в команде используем UML для общения вокруг разработки, чем этот язык хорош и зачем вообще нужны какие-то дополнительные инструменты, кроме текстовой аналитики.

Я работаю в ИТ с окончания института – уже 20 лет. За это время успел попробовать себя в разных ролях и зонах ответственности. Начинал когда-то с системного администрирования, потом меня заинтересовало программирование, и я пошел развиваться этим путем. Впоследствии переключился на архитектуру. Сейчас мне кажется, что архитектура идет параллельно с теми областями, которые я пробовал ранее, отчасти их покрывает, но подразумевает более глобальный взгляд на разработку.

В КОРУСе я сталкиваюсь с крупными проектами. Не только у нас, но и в целом в отрасли масштабная разработка, всегда командная. Поэтому когда ты начинаешь погружаться в такой проект, возникает необходимость обмена информацией.

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

Что такое UML

UML (Unified Modeling Language) — это стандартизированный язык моделирования, предназначенный для создания схем и документации в процессе разработки программного обеспечения.

Основное преимущество этого языка в том, что UML нагляден. Он помогает закрыть недопонимания между командами или частями одной команды. Я работал в разных компаниях в ИТ и из своей практики заметил, что в организациях, где есть устоявшаяся практика использования диаграмм, гораздо реже возникают проблемы с коммуникациями. Грубо говоря, если у тебя есть только документация, систему без ошибок реализовать вполне возможно. Но без диаграмм гораздо чаще возникают истории, когда реализация что-то ломает в соседнем компоненте. Например, в базе данных, допустим, взяли и слили несколько таблиц в одну, хотя этого никто не ожидал. Вроде бы это не ошибка, но для соседней команды это может быть месяц работы. Чтобы избежать такой ситуации можно было бы даже подробно ничего не описывать–- просто показать диаграмму, на которой отражено, в какую части системы вносятся изменения.

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

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

В разработке участвует много ролей, и для каждой из них в UML найдется свой собственный набор диаграмм.

Мир архитектуры

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

Одно дело, если я приду к разработчику и скажу: «Создай мне компонент, который делает то-то и то-то». Но совсем другое, если я нарисую схему. У коллег появляется возможность не только быстрее понять, но может в чем-то и покритиковать идею, подкорректировать реализацию.

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

В мире архитектуры есть свои нотации, например, на моем проекте используется С4, существует также ArchiMate и другие. Вплоть до того, что есть еще нотации по ГОСТу, которые были приняты в СССР и России для описания процессов. Некоторые из этих нотаций построены на основе UML, но в целом они более абстрактные (более «архитектурные»). Они хорошо помогают показать системы, компоненты и потоки данных.

Однако архитекторам приходится договариваться с другими ролями, например, о внедрении. Как правило, в этих процессах задействовано несколько систем (и несколько команд) - шины данных, БД и т.п. Одна система генерирует заявку, другая ее обрабатывает, третья обогащает данными. И чтобы описать прохождение этих заявок между системами UML подходит гораздо лучше, чем специализированные архитектурные нотации.

По сути использование UML отвечает архитектурному принципу прозрачности.

Мир инфраструктуры 

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

Мир разработки

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

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

Как правило, на этом уровне используются диаграммы последовательностей (сиквенс-диаграммы), которые  показывают последовательность взаимодействия компонентов программного обеспечения. Подобные диаграммы четко прописывают, как именно работает система. Они позволяют избежать ситуации, когда реализация есть, и даже вроде бы по ТЗ, но работает не так, как планировалось.

Для описания алгоритмов используют диаграммы активностей (активити диаграммы) и диаграммы перехода состояний.

Мир аналитики и бизнеса

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

На этом уровне как правило используют диаграммы вариантов использования (диаграммы use case).

К этому же миру можно отнести взаимодействие с заказчиком.

Все миры связаны

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

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

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

Здесь я упомянул лишь несколько типов диаграмм. На самом деле их гораздо больше.

Про изучение UML

Хотя UML достаточно простой, все-таки это язык, который стоит изучить. Как правило, знания UML не требуют при найме разработчиков. Возможно, для архитекторов он почти обязателен, но многие разработчики даже уровня сениор прекрасно живут без него. Но я рекомендую потратить время на его изучение. Это прекрасное средство общения именно в контексте разработки. Причем, сначала нужно научиться его читать, а потом и писать. В этом смысле диаграммы не отличаются от других инструментов коммуникации – ими надо уметь пользоваться.

UML – еще и огромное конкурентное преимущество вашего резюме.

Подборка советов/материалов для тех, кто не работал с UML:

Онлайн-курсы

IBS и другие платформы предлагают курсы по UML различного уровня сложности.

Книги

«UML Distilled», Мартин Фаулер – отличный вводный ресурс для новичков.

«Applying UML and Patterns», Крейг Ларман – подходит для тех, кто хочет углубиться в процесс разработки программного обеспечения с использованием UML.

«The Unified Modeling Language User Guide» от Гради Буча, Ивара Якобсона и Джеймса Рамбо – полное руководство по всем аспектам UML.

Веб-сайты и документация

Веб-сайт EA

Официальный сайт UML предоставляет спецификации и информацию по UML.

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