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

Чтобы ответить на эти вопросы, нам придётся отмотать время назад — в начало девяностых. Тогда объектно-ориентированное программирование набирало обороты, и каждая крупная компания рисовала диаграммы по-своему. Представьте: десять команд в одной корпорации, и у каждой — свой способ изобразить класс. Один рисует прямоугольник с тремя секциями, другой — овал с подписями, третий — вообще облачко с пунктиром. Вы приходите на совещание, смотрите на чужую схему и не понимаете ровным счётом ничего. Хаос.

К середине девяностых существовало больше пятидесяти различных методологий объектно-ориентированного моделирования. Книги по одной методологии были бесполезны для пользователей другой. Инструменты одного вендора не читали файлы другого. Индустрии отчаянно нужен был единый язык. И тут на сцену выходят три человека, которых индустрия прозвала «Три Амиго» (The Three Amigos). Нет, это не шутка — так их действительно называли на конференциях и в статьях.

Первый — Грейди Буч (Grady Booch). Он создал метод Буча (Booch Method) — одну из первых серьёзных методологий объектно-ориентированного проектирования. Его диаграммы были мощными, но визуально перегруженными: облачка для классов, пунктирные линии, стрелки во все стороны. Зато метод отлично описывал архитектуру крупных систем.

Второй — Джеймс Рамбо (James Rumbaugh). Он разработал OMT — Object Modeling Technique. Этот метод славился отличной работой с данными и отношениями между объектами. Если Буч был силён в проектировании архитектуры, то Рамбо — в анализе предметной области.

Третий — Ивар Якобсон (Ivar Jacobson). Он подарил миру понятие Use Case (вариант использования) — способ описывать систему глазами пользователя. Его методология OOSE (Object-Oriented Software Engineering) сделала акцент на том, что система делает для людей, а не на том, как она устроена внутри.

Каждый из троих был звездой в своей области, написал книги-бестселлеры и понимал, что война нотаций никому не помогает.

В 1994–1995 годах все трое оказались в компании Rational Software. Буч и Рамбо начали объединять свои методы — результат назвали «Unified Method 0.8». Потом присоединился Якобсон, и вместе они взялись за создание единого стандарта. Три подхода, три характера, одна цель — покончить с хаосом нотаций.

В январе 1997 года вышла спецификация **UML 1.0**. Её представили в организацию OMG — Object Management Group. Это консорциум, который занимается разработкой открытых стандартов для IT-индустрии. Не одна компания, а сотни компаний вместе: IBM, Microsoft, Oracle, Hewlett-Packard и десятки других. OMG приняла UML как стандарт, и с этого момента началось его официальное развитие.

Дальше UML развивался итерациями. Версия 1.1 вышла в том же 1997-м — с уточнениями и исправлениями. Потом были 1.2, 1.3, 1.4, 1.5 — каждая добавляла уточнения, закрывала пробелы, но принципиально структура не менялась. Это был период «полировки»: язык уже существовал, его просто доводили до ума.

Настоящая революция случилась в 2005 году с выходом UML 2.0. Это был не косметический апдейт, а полная переработка. Количество типов диаграмм выросло до четырнадцати. Появились диаграммы композитных структур, временные диаграммы, диаграммы обзора взаимодействий. Семантика стала более формальной — теперь можно было точнее описывать параллелизм, состояния, потоки управления. UML 2.0 превратился из «удобного инструмента для эскизов» в полноценный язык моделирования, на котором можно было строить исполняемые модели.

Текущая версия — UML 2.5.1, выпущенная в декабре 2017 года. Она не добавила новых диаграмм, а упростила и реструктурировала спецификацию. Документ стал читаемее — что немаловажно, когда речь идёт о стандарте на семьсот с лишним страниц. Зачем знать историю версий? Потому что в реальной работе вы столкнётесь с диаграммами из разных эпох. Откроете книгу 2002 года — и увидите нотацию UML 1.x, которая отличается от современной. Загрузите проект в старый инструмент — и он не поймёт конструкции из UML 2.x. Коллега покажет диаграмму «как учили в университете» — и вы поймёте, почему она выглядит непривычно.

Кроме того, UML — это международный стандарт ISO. Версия 1.4.2 стала стандартом ISO/IEC 19501, а версия 2.x — ISO/IEC 19505. Это значит, что в крупных проектах (особенно в государственных и оборонных) контракты могут прямо ссылаться на конкретную версию UML. «Документация должна быть оформлена в соответствии с UML 2.5» — это реальная строчка из технического задания.

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

SysML (Systems Modeling Language) — расширение UML для системной инженерии. Когда вы проектируете не просто софт, а целую систему — с железом, датчиками, механикой — UML не хватает. SysML добавляет диаграммы требований, параметрические диаграммы и другие инструменты для инженеров, которые мыслят шире, чем «классы и объекты».

ArchiMate — язык для описания корпоративной архитектуры. Если UML говорит про код и компоненты, то ArchiMate описывает бизнес-процессы, приложения и инфраструктуру на уровне всей организации.

BPMN (Business Process Model and Notation) — нотация для бизнес-процессов. Когда нужно нарисовать «клиент оставляет заявку → менеджер проверяет → бухгалтерия выставляет счёт», BPMN подходит лучше, чем UML.

C4 model — подход Саймона Брауна с четырьмя уровнями: контекст, контейнеры, компоненты, код. C4 не конкурирует с UML напрямую — скорее, предлагает упрощённый вход в мир архитектурных диаграмм.

Ни один из этих инструментов не заменяет UML полностью. SysML — для инженеров, ArchiMate — для архитекторов предприятия, BPMN — для аналитиков, C4 — для быстрых архитектурных набросков. А UML остаётся универсальным языком моделирования программных систем.

В следующем уроке мы перейдём от истории к практике и разберём типы диаграмм UML: чем структурные отличаются от поведенческих и когда какие использовать.