Основы UML: Визуальное моделирование программных систем

1. Введение в UML: история, стандарты и обзор основных типов диаграмм

Введение в UML: история, стандарты и обзор основных типов диаграмм

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

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

Что такое UML?

UML (Unified Modeling Language) — это унифицированный язык моделирования. Это не язык программирования, как Java или Python. Вы не пишете на нем код, который исполняется компьютером (хотя современные инструменты позволяют генерировать код из схем). UML — это графическая нотация для визуализации, спецификации, конструирования и документирования артефактов программных систем.

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

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

Немного истории: Война методов и «Три амиго»

В начале 1990-х годов объектно-ориентированное программирование (ООП) начало набирать популярность. Вместе с ним возникла потребность в методах проектирования таких систем. Это привело к периоду, который в истории IT называют «войной методов».

Существовало множество конкурирующих нотаций, но лидерами были трое:

Гради Буч (Grady Booch) с его методом Booch, который отлично подходил для проектирования и конструирования.

Джеймс Рамбо (James Rumbaugh) с методом OMT (Object Modeling Technique), сильным в системном анализе.

Ивар Якобсон (Ivar Jacobson) с методом OOSE (Object-Oriented Software Engineering), который ввел понятие Use Cases (варианты использования).

К счастью для индустрии, эти трое решили не воевать, а объединить усилия. Они стали известны как «Три амиго». Работая в компании Rational Software, они начали унификацию своих методов.

!Временная шкала объединения методов Буча, Рамбо и Якобсона в единый стандарт UML.

В 1997 году консорциум OMG (Object Management Group) принял UML версии 1.1 в качестве стандарта. С тех пор OMG занимается развитием и поддержкой спецификации языка. Текущей актуальной веткой является версия UML 2.5.x, которая значительно расширила возможности моделирования по сравнению с первой версией.

Зачем нужен UML сегодня?

Многие новички спрашивают: «Зачем мне рисовать диаграммы, если я могу сразу писать код?». Вот несколько причин:

* Борьба со сложностью. Современные системы слишком сложны, чтобы держать всю их структуру в голове. Визуализация помогает увидеть «лес за деревьями». * Коммуникация. Диаграмма понятна и менеджеру, и программисту. Это универсальный язык эсперанто в IT. * Проектирование перед реализацией. Дешевле исправить ошибку на бумаге (или в редакторе диаграмм), чем переписывать тысячи строк кода. * Документация. Новые сотрудники быстрее войдут в курс дела, изучив диаграммы классов и последовательностей, чем копаясь в исходниках.

Структура UML: Классификация диаграмм

UML 2.5 предлагает 14 типов диаграмм. Это может показаться пугающим, но на практике активно используются 5–6 из них. Все диаграммы делятся на две большие группы:

Структурные диаграммы (Structural Diagrams) — описывают статическую структуру системы. Они показывают, из каких элементов состоит система и как они связаны, но не говорят о том, что происходит во времени.

Поведенческие диаграммы (Behavioral Diagrams) — описывают динамическое поведение системы. Они показывают, как система взаимодействует с пользователями, как меняются данные и какие процессы протекают во времени.

!Классификация основных типов диаграмм UML на структурные и поведенческие.

Основные структурные диаграммы

Рассмотрим самые важные диаграммы, которые отвечают на вопрос «Что это такое?».

#### Диаграмма классов (Class Diagram) Это «король» UML. Самая популярная диаграмма. Она показывает классы системы, их атрибуты, методы и взаимосвязи (наследование, агрегация, композиция). Это основа для генерации кода и проектирования баз данных.

#### Диаграмма компонентов (Component Diagram) Показывает, как система разбита на крупные модули (компоненты) и какие зависимости существуют между ними. Это вид с высоты птичьего полета на физическую структуру кода (библиотеки, пакеты, файлы).

#### Диаграмма развертывания (Deployment Diagram) Описывает аппаратную часть: серверы, рабочие станции, маршрутизаторы и то, какое программное обеспечение (артефакты) на них запущено. Необходима для DevOps-инженеров и системных администраторов.

Основные поведенческие диаграммы

Эти диаграммы отвечают на вопрос «Как это работает?».

#### Диаграмма вариантов использования (Use Case Diagram) Самая простая для понимания. Она показывает действующих лиц (акторов) и то, что они могут делать в системе. Например: «Пользователь» может «Оформить заказ». Часто используется для сбора требований и общения с заказчиком.

#### Диаграмма последовательности (Sequence Diagram) Показывает взаимодействие объектов во времени. Кто кому отправляет сообщение? В каком порядке? Это идеальный инструмент для проектирования сложных алгоритмов взаимодействия между сервисами или объектами.

#### Диаграмма деятельности (Activity Diagram) Очень похожа на классические блок-схемы. Показывает поток управления от одной деятельности к другой. Отлично подходит для описания бизнес-процессов и алгоритмов с ветвлениями и циклами.

#### Диаграмма состояний (State Machine Diagram) Описывает жизненный цикл одного объекта: в каких состояниях он может находиться и какие события переводят его из одного состояния в другое. Например, жизненный цикл «Заказа»: Создан -> Оплачен -> Отправлен -> Доставлен.

Стандарты и совместимость

Важно понимать, что UML — это стандарт. Это значит, что стрелка наследования (сплошная линия с пустым треугольником на конце) означает одно и то же в любом инструменте, будь то Enterprise Architect, Visual Paradigm или бесплатный Draw.io.

Спецификация UML описывает: * Синтаксис: Как выглядят элементы (прямоугольники, линии, ромбы). * Семантику: Что эти элементы означают.

Благодаря стандартизации OMG, мы имеем возможность использовать формат XMI (XML Metadata Interchange) для переноса моделей между разными инструментами, хотя на практике полная совместимость не всегда достигается идеально.

Заключение

UML — это мощный инструмент в арсенале инженера-программиста. Он позволяет абстрагироваться от кода и увидеть архитектуру системы. Вам не обязательно знать все 14 типов диаграмм наизусть. В 80% случаев вам будет достаточно знать диаграммы классов, последовательности и вариантов использования.

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

Полезные ссылки

* Официальная страница UML на сайте OMG * Спецификация UML 2.5.1

2. Структурные диаграммы: углубленное изучение диаграммы классов и диаграммы компонентов

Структурные диаграммы: углубленное изучение диаграммы классов и диаграммы компонентов

В предыдущей статье мы рассмотрели UML с высоты птичьего полета, узнали его историю и разделили диаграммы на две большие семьи: структурные и поведенческие. Сегодня мы спустимся с небес на землю и займемся фундаментом любой объектно-ориентированной системы.

Мы детально разберем Диаграмму классов (Class Diagram) и Диаграмму компонентов (Component Diagram). Если первая помогает спроектировать «кирпичики» вашего приложения, то вторая показывает, как эти кирпичики собираются в целые стены и этажи.

Диаграмма классов: Анатомия системы

Диаграмма классов — это сердце UML. По статистике, более 70% всех создаваемых в мире диаграмм — это именно диаграммы классов. Она описывает типы объектов в системе и статические отношения между ними.

Строение класса

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

Имя класса (верхняя часть). Пишется жирным шрифтом, с большой буквы, по центру. Если класс абстрактный, его имя пишется курсивом.

Атрибуты (средняя часть). Это поля класса, его данные.

Операции (нижняя часть). Это методы класса, его поведение.

!Структура класса в UML: имя, атрибуты и методы.

Видимость (Visibility)

В объектно-ориентированном программировании (ООП) инкапсуляция играет ключевую роль. UML предоставляет специальные символы (маркеры видимости), которые ставятся перед именем атрибута или метода:

Пример описания атрибута: visibility name : type [multiplicity] = default

Например: - balance : Decimal [1] = 0.0

Отношения между классами

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

!Основные типы отношений в UML и их графическое обозначение.

#### 1. Зависимость (Dependency) Как выглядит: Пунктирная линия с открытой стрелкой. Смысл: «Класс А использует Класс Б». Это самая слабая связь. Если изменится класс Б, это может повлиять на класс А. Пример: Метод класса ReportGenerator принимает в качестве аргумента объект Date. Генератор отчетов зависит от даты, но не владеет ею.

#### 2. Ассоциация (Association) Как выглядит: Сплошная линия (иногда со стрелкой на конце для указания навигации). Смысл: «Класс А знает о Классе Б и имеет ссылку на него». Пример: Учитель и Ученик. Учитель знает своих учеников, ученики знают учителя. Это длительная связь.

#### 3. Агрегация (Aggregation) Как выглядит: Сплошная линия с пустым ромбом на стороне «целого». Смысл: Отношение «Часть — Целое». Но это нежесткая связь. Часть может существовать отдельно от целого. Пример: Библиотека и Книга. Если библиотеку закроют и снесут, книги не уничтожаются, их можно перенести в другую библиотеку. Книга является частью библиотеки, но живет своей жизнью.

#### 4. Композиция (Composition) Как выглядит: Сплошная линия с закрашенным ромбом на стороне «целого». Смысл: Отношение «Часть — Целое» с жесткой зависимостью жизненного цикла. Часть не может существовать без целого. Пример: Дом и Комната. Если снести дом, комнаты исчезнут вместе с ним. Вы не можете вытащить комнату и перенести её в другой дом (в контексте архитектуры ПО).

> Запомните простое правило: если при удалении главного объекта удаляются и зависимые — это Композиция (закрашенный ромб). Если зависимые остаются жить — это Агрегация (пустой ромб).

#### 5. Обобщение (Generalization) Как выглядит: Сплошная линия с пустым треугольником на конце. Смысл: Наследование. «Класс Б является разновидностью Класса А». Пример: Кошка (наследник) -> Животное (родитель).

#### 6. Реализация (Realization) Как выглядит: Пунктирная линия с пустым треугольником на конце. Смысл: Реализация интерфейса. Класс обязуется реализовать методы, описанные в интерфейсе.

Кратность (Multiplicity)

Часто важно указать, сколько объектов участвует в связи. Для этого используются цифры на концах линий:

* 1 — ровно один. * 0..1 — ноль или один (опционально). или 0..* — от нуля до бесконечности. 1.. — от одного до бесконечности.

Диаграмма компонентов: Архитектура с высоты

Если диаграмма классов показывает логическое устройство кода, то диаграмма компонентов показывает физическую или логическую разбивку системы на модули. Это уровень архитектора системы.

Что такое компонент?

Компонент — это модульная часть системы, которая скрывает свою реализацию за набором внешних интерфейсов. В мире программирования компонентом может быть: * DLL-библиотека или JAR-файл. * Микросервис. * Отдельный модуль в монолите (например, BillingModule).

На диаграмме компонент изображается как прямоугольник с иконкой компонента в правом верхнем углу (или стереотипом «component»).

Интерфейсы: «Леденцы» и «Гнезда»

Самое важное в компонентах — это то, как они общаются. Для этого используется нотация «Ball and Socket» (Шар и Гнездо).

Предоставляемый интерфейс (Provided Interface) — изображается как полный круг («леденец») на ножке. Это то, что компонент предлагает внешнему миру. «Я умею делать это».

Требуемый интерфейс (Required Interface) — изображается как полукруг («гнездо») на ножке. Это то, что компоненту нужно для работы. «Мне нужно, чтобы кто-то умел делать это».

!Взаимодействие компонентов через интерфейсы: OrderService требует функционал оплаты, который предоставляет PaymentGateway.

Зачем использовать диаграммы компонентов?

Управление зависимостями. Вы сразу видите, если ваш модуль UI напрямую лезет в базу данных, минуя Logic, что является архитектурной ошибкой.

Замена реализации. Если два компонента соединены через интерфейс, вы можете легко заменить один компонент на другой (например, заменить Oracle на PostgreSQL), не переписывая всю систему, при условии, что интерфейс останется прежним.

Связь диаграмм классов и компонентов

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

Представьте матрешку: * Система состоит из Компонентов. * Компонент состоит из Классов. * Класс состоит из Атрибутов и Методов.

Заключение

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

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

3. Моделирование требований и процессов: диаграммы прецедентов (Use Case) и деятельности (Activity)

Моделирование требований и процессов: диаграммы прецедентов (Use Case) и деятельности (Activity)

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

В этой статье мы переходим от статики к динамике и требованиям. Мы изучим два типа диаграмм, которые являются мостом между заказчиком (бизнесом) и разработчиком: Диаграмму вариантов использования (Use Case Diagram) и Диаграмму деятельности (Activity Diagram).

Диаграмма вариантов использования (Use Case Diagram)

Представьте, что вы приходите в ресторан. Вам не интересно, как устроена плита на кухне или как организована иерархия поваров (это структурные диаграммы). Вам важно знать, что вы можете сделать: заказать еду, оплатить счет, позвать официанта. Это и есть варианты использования.

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

Основные элементы

Актор (Actor)

Это действующее лицо. На диаграмме изображается в виде человечка (stickman). Важно понимать: актор — это не конкретный человек (Иван Иванович), а роль. Один человек может играть разные роли (Администратор и Пользователь), и одну роль могут играть разные люди. Примечание: Актором может быть не только человек, но и внешняя система (например, «Банковский API», который подтверждает платеж).

Вариант использования (Use Case)

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

Границы системы (System Boundary)

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

!Пример диаграммы Use Case для системы банкомата.

Отношения на диаграмме Use Case

Самое интересное начинается, когда мы связываем элементы. Кроме простой ассоциации (сплошная линия), существуют специфические отношения между вариантами использования:

#### 1. Включение (Include) Обозначается пунктирной стрелкой со стереотипом <<include>>. Это отношение означает, что один вариант использования обязательно включает в себя выполнение другого.

Пример: У нас есть варианты «Снять наличные» и «Проверить баланс». Для обоих действий необходима аутентификация. Мы выносим «Ввести ПИН-код» в отдельный овал. И теперь «Снять наличные» --<<include>>--> «Ввести ПИН-код». Без ввода пин-кода снятие невозможно.

#### 2. Расширение (Extend) Обозначается пунктирной стрелкой со стереотипом <<extend>>. Это отношение означает, что один вариант использования может (опционально) дополнить поведение другого при определенных условиях.

Пример: Есть вариант «Оформить заказ». Если пользователь хочет подарочную упаковку, срабатывает расширение. «Добавить подарочную упаковку» --<<extend>>--> «Оформить заказ». Это происходит не всегда, а только по желанию пользователя.

> Как запомнить разницу? > Include — это «Я не могу без тебя» (обязательно). > Extend — это «Я могу добавить вишенку на торт» (опционально).

#### 3. Обобщение (Generalization) Работает так же, как наследование в классах. Актор «Администратор» может наследовать все права актора «Пользователь», плюс иметь свои дополнительные возможности.

Диаграмма деятельности (Activity Diagram)

Если Use Case говорит нам «Что сделать», то Activity Diagram объясняет «Как именно происходит процесс». Это, по сути, продвинутая блок-схема. Она идеально подходит для моделирования бизнес-процессов, алгоритмов и потоков работ.

Основные элементы

* Начальный узел (Initial Node): Черный закрашенный круг. Точка входа в процесс. * Действие (Action/Activity): Прямоугольник с закругленными углами. Шаг процесса (например, «Проверить наличие товара»). * Поток управления (Control Flow): Стрелка, показывающая переход от одного действия к другому. * Конечный узел (Final Node): Черный круг в белой окантовке (бычий глаз). Конец процесса.

Управление потоком

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

#### Решение (Decision) и Слияние (Merge) Изображается в виде ромба. * Решение: Один вход, несколько выходов. Каждый выход подписывается условием (например, [Оплата прошла] и [Оплата отклонена]). * Слияние: Несколько входов, один выход. Используется, чтобы объединить альтернативные пути обратно в единый поток.

#### Разделение (Fork) и Объединение (Join) Изображается в виде жирной черной линии (горизонтальной или вертикальной). Разделение (Fork): Один поток входит, несколько выходят. Это означает параллельное выполнение. Например, после оформления заказа можно одновременно* отправить письмо клиенту и отправить уведомление на склад. * Объединение (Join): Несколько потоков входят, один выходит. Процесс пойдет дальше только тогда, когда завершатся все входящие потоки.

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

Дорожки (Swimlanes)

Иногда важно показать не только что делается, но и кто это делает. Для этого диаграмму делят на вертикальные или горизонтальные зоны — дорожки. Каждая дорожка подписывается именем ответственного (например, «Клиент», «Менеджер», «Склад»).

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

Когда и какую диаграмму использовать?

Советы по моделированию

Не усложняйте Use Case. Диаграмма вариантов использования должна быть простой. Если у вас сотни стрелок include и extend, скорее всего, вы пытаетесь нарисовать алгоритм вместо требований. Для алгоритмов используйте Activity Diagram.

Следите за уровнями абстракции. Не смешивайте на одной диаграмме Activity действия «Нажать кнопку ОК» (интерфейс) и «Сохранить транзакцию в БД» (бэкенд), если это не оправдано целью схемы.

Именуйте правильно. Use Case — это всегда глагол + существительное («Создать отчет»). Activity — это действие или состояние процесса.

Заключение

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

В следующей статье мы погрузимся в мир взаимодействия объектов и разберем Диаграмму последовательности (Sequence Diagram), которая покажет, как именно объекты общаются друг с другом во времени для реализации сценариев, которые мы сегодня описали.

Полезные ссылки

* Спецификация UML 2.5.1 (раздел Use Cases) * Руководство по Activity Diagrams от Agile Modeling

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

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

Мы продолжаем наше путешествие по миру UML. В предыдущих статьях мы научились проектировать «скелет» системы с помощью диаграмм классов и компонентов, а также описали требования и бизнес-процессы через Use Case и Activity диаграммы.

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

В этой статье мы разберем два ключевых типа диаграмм взаимодействия: Диаграмму последовательности (Sequence Diagram) и Диаграмму коммуникации (Communication Diagram).

Диаграмма последовательности (Sequence Diagram)

Это, пожалуй, самая популярная диаграмма после диаграммы классов. Если вы хотите понять, как именно реализуется тот или иной вариант использования (Use Case) на уровне кода и объектов, вам нужна именно она.

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

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

Основные элементы

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

* Имя объекта: Обычно пишется в формате имяОбъекта : ИмяКласса. Если имя объекта неважно, пишут просто : ИмяКласса (анонимный объект). * Актор: Изображается знакомым нам человечком (stickman).

#### 2. Фокус управления (Activation Bar) На пунктирной линии жизни вы часто увидите узкие вытянутые прямоугольники. Это фокус управления (или активация). Он показывает период времени, когда объект реально выполняет какое-то действие (процессор занят выполнением его метода) или ждет ответа от другого объекта.

#### 3. Сообщения (Messages) Объекты общаются, посылая друг другу сообщения. В коде это обычно соответствует вызову метода. Стрелки рисуются горизонтально.

* Синхронное сообщение: Сплошная линия с закрашенной треугольной стрелкой. Отправитель ждет, пока получатель закончит обработку, прежде чем продолжить. Это стандартный вызов функции. * Асинхронное сообщение: Сплошная линия с открытой стрелкой (галочкой). Отправитель отправляет сигнал и сразу продолжает работу, не дожидаясь ответа. Часто используется в многопоточных системах или очередях сообщений. * Ответное сообщение (Return): Пунктирная линия с открытой стрелкой, направленная назад (слева направо). Показывает возврат данных из вызванного метода (например, return true). Часто опускается, если возврат очевиден, чтобы не загромождать схему.

Управляющие структуры (Fragments)

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

Самые важные операторы:

alt (Alternative): Аналог конструкции if... else. Рамка делится пунктирной линией на части. Если условие верно — выполняется верхняя часть, иначе — нижняя.

opt (Option): Аналог простого if без else. Выполняется только если условие истинно.

loop (Loop): Аналог циклов for или while. Действия внутри рамки повторяются указанное количество раз или пока верно условие.

par (Parallel): Показывает, что действия в разных секциях рамки выполняются параллельно (одновременно).

Пример чтения диаграммы

Представьте процесс покупки в интернет-магазине:

Пользователь отправляет сообщение нажатьКнопкуКупить() объекту Корзина.

На линии жизни Корзины появляется фокус управления.

Корзина шлет синхронное сообщение проверитьНаличие() объекту Склад.

Используется фрагмент alt:

Если товар есть:* Склад возвращает true, Корзина создает Заказ. Если товара нет:* Склад возвращает false, Корзина показывает ошибку.

Диаграмма коммуникации (Communication Diagram)

Ранее (в UML 1.x) она называлась Collaboration Diagram (диаграмма кооперации). Это «сестра» диаграммы последовательности. Они семантически эквивалентны: одну можно автоматически превратить в другую без потери информации.

Главное отличие: Диаграмма коммуникации не имеет оси времени.

Она фокусируется на связях между объектами. Это вид «с высоты птичьего полета» на то, кто с кем разговаривает, и как объекты расположены в пространстве (архитектурно).

!Пример диаграммы коммуникации, где акцент сделан на связях между объектами, а порядок вызовов задается нумерацией.

Как читать порядок действий?

Поскольку времени здесь нет, последовательность вызовов определяется нумерацией:

* Сообщение 1: Зайти в систему — первое действие. * Сообщение 1.1: Проверить пароль — это действие, вызванное внутри действия 1. * Сообщение 1.1.1: Запрос к БД — вложенный вызов. * Сообщение 2: Открыть главную страницу — второе действие верхнего уровня.

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

Сравнение: Когда и что использовать?

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

> Совет: В 90% случаев для описания алгоритма вам понадобится Диаграмма последовательности. Используйте Диаграмму коммуникации только тогда, когда вам нужно показать сложную паутину связей между компонентами, и порядок вызовов вторичен.

Практические советы по построению

Не пытайтесь нарисовать всю систему на одной диаграмме. Диаграмма последовательности должна описывать один конкретный сценарий (один Use Case или даже его часть). Если вы попытаетесь уместить все ветвления if/else на одной картинке, она станет нечитаемой.

Соблюдайте уровень абстракции. Если вы рисуете бизнес-процесс, объектами могут быть «Отдел продаж» и «Склад». Если вы проектируете код, объектами будут OrderController и ProductRepository. Не смешивайте эти уровни.

Используйте понятные имена сообщений. Вместо msg1() пишите validateUser(login, password). Это документация, ее будут читать люди.

Не забывайте про возврат. Хотя пунктирные стрелки возврата (return) можно опускать, в сложных вычислениях лучше явно показать, что именно вернулось в ответ.

Заключение

Диаграммы взаимодействия оживляют нашу модель. Диаграмма последовательности — это мощнейший инструмент для проектирования логики методов и протоколов обмена данными. Она позволяет разработчику увидеть «фильм» про работу программы еще до начала съемок (кодинга).

Теперь, когда мы знаем, как устроена система (классы) и как она ведет себя в конкретных сценариях (последовательности), нам осталось изучить, как моделировать жизненный цикл сложных объектов, которые меняют свое поведение в зависимости от состояния. Об этом мы поговорим в следующей статье, посвященной Диаграммам состояний (State Machine Diagram).

Полезные ссылки

* Спецификация UML 2.5.1 (раздел Interactions) * Руководство по Sequence Diagrams от Visual Paradigm

5. Жизненный цикл объектов и архитектура: диаграммы состояний (State Machine) и развертывания (Deployment)

Жизненный цикл объектов и архитектура: диаграммы состояний (State Machine) и развертывания (Deployment)

Мы подходим к финалу нашего курса по основам UML. В предыдущих статьях мы проделали огромный путь: от сбора требований через Use Case диаграммы до проектирования структуры классов и детального описания взаимодействия объектов на диаграммах последовательности.

Казалось бы, у нас есть всё необходимое для написания кода. Но остались два важных вопроса, без ответов на которые картина будет неполной:

Как ведет себя сложный объект, который меняет свою реакцию на события в зависимости от того, что с ним происходило раньше? (Например, банкомат: кнопка «Выдать деньги» работает только после ввода ПИН-кода).

Где физически будет работать наш код? На каких серверах, в каких контейнерах и как эти узлы связаны между собой?

Сегодня мы ответим на эти вопросы, изучив Диаграмму состояний (State Machine Diagram) и Диаграмму развертывания (Deployment Diagram).

Диаграмма состояний (State Machine Diagram)

Многие новички путают диаграмму состояний с диаграммой деятельности (Activity Diagram), которую мы изучали ранее. Различие фундаментально:

* Activity Diagram показывает поток работ (алгоритм), где действия выполняются одно за другим. * State Machine Diagram показывает жизненный цикл одного конкретного объекта. Она описывает, в каких состояниях может находиться объект и какие события заставляют его переходить из одного состояния в другое.

Эта диаграмма незаменима при проектировании объектов со сложной логикой: заказов, документов, сетевых соединений, игровых персонажей.

!Диаграмма состояний, описывающая жизненный цикл заказа в интернет-магазине.

Основные элементы

#### 1. Состояние (State) Изображается прямоугольником с закругленными углами. Внутри пишется имя состояния (например, Idle, Running, Waiting). Состояние — это период времени, в течение которого объект ожидает какого-то события или выполняет длительную деятельность.

Внутри состояния можно указать внутренние действия: * entry / действие — выполняется сразу при входе в состояние. * do / деятельность — выполняется, пока объект находится в состоянии. * exit / действие — выполняется перед выходом из состояния.

#### 2. Переход (Transition) Стрелка, соединяющая два состояния. Она показывает, что объект меняет свое состояние. У перехода есть три необязательных параметра, которые записываются в формате:

Событие [Условие] / Действие

* Событие (Trigger): То, что инициирует переход (например, нажатие кнопки, получение сообщения, истечение таймера). * Условие (Guard): Логическое выражение в квадратных скобках. Переход сработает, только если условие истинно. Например: [баланс > 0]. * Действие (Effect): Короткая операция, которая выполняется во время перехода. Например: / обновитьСчетчик().

#### 3. Псевдосостояния * Начальное состояние (Initial State): Черный закрашенный круг. Точка рождения объекта. * Конечное состояние (Final State): Круг с точкой внутри (бычий глаз). Означает, что объект прекратил существование или завершил работу.

Пример: Турникет в метро

Рассмотрим простую модель турникета. У него есть два основных состояния: Заблокирован (Locked) и Разблокирован (Unlocked).

Начало: Турникет находится в состоянии Заблокирован.

Событие: Пассажир прикладывает карту (Coin).

Переход: Турникет переходит в состояние Разблокирован.

Действие при переходе:* Загорается зеленая лампа.

Событие: Пассажир проходит (Pass).

Переход: Турникет возвращается в состояние Заблокирован.

Если пассажир попытается пройти (Pass) в состоянии Заблокирован, перехода не случится (турникет останется заблокированным).

Суперсостояния (Composite States)

Иногда диаграмма становится слишком громоздкой. Например, у банкомата в состоянии «Работает» может быть много подсостояний: «Ожидание карты», «Проверка ПИН», «Выбор операции». Чтобы не рисовать паутину, используют составное состояние.

Мы рисуем большой прямоугольник «Работает», а внутри него — свою маленькую диаграмму состояний. Это позволяет использовать абстракцию и скрывать детали.

Диаграмма развертывания (Deployment Diagram)

Если все предыдущие диаграммы относились к миру идей и логики (Logical View), то диаграмма развертывания возвращает нас в суровую физическую реальность (Physical View). Она отвечает на вопрос: «На каком железе это будет крутиться?».

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

!Пример диаграммы развертывания для веб-приложения с базой данных.

Основные элементы

#### 1. Узел (Node) Изображается в виде трехмерного куба (параллелепипеда). Узел — это вычислительный ресурс. Узлы бывают двух типов:

* Устройство (Device): Физическое железо. Сервер, ноутбук, смартфон, IoT-датчик, сканер штрих-кодов. * Среда выполнения (Execution Environment): Программная среда, внутри которой исполняются компоненты. Операционная система (Linux), контейнер (Docker), сервер приложений (Tomcat, IIS), СУБД (PostgreSQL).

Обычно среду выполнения рисуют как узел, вложенный внутрь физического устройства, или просто используют стереотипы, например «device» Server или «execution environment» Docker Container.

#### 2. Артефакт (Artifact) Изображается как прямоугольник с ключевым словом «artifact» или иконкой листа бумаги с загнутым углом. Артефакт — это конкретный физический файл, который является результатом сборки программного обеспечения.

Примеры артефактов: * Исполняемые файлы (app.exe, service.jar) * Библиотеки (math.dll, utils.so) * Скрипты (script.py, index.html) * Конфигурационные файлы (config.xml)

Артефакты размещаются внутри узлов. Это показывает, что данный файл физически лежит на этом сервере.

#### 3. Путь коммуникации (Communication Path) Сплошная линия, соединяющая узлы. Она показывает, что узлы могут обмениваться информацией. Часто над линией пишут протокол взаимодействия: «TCP/IP», «HTTPS», «JDBC», «USB».

Зачем использовать диаграмму развертывания?

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

Планирование установки. Инженеры знают, какие именно jar или dll файлы нужно скопировать на конкретную машину.

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

Связь с диаграммой компонентов

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

На диаграмме развертывания часто показывают зависимость: Артефакт UserService.jar <<manifest>> Компонент UserService. Это означает, что компонент живет внутри этого файла.

Заключение курса

Поздравляем! Вы прошли краткий курс «Основы UML». Мы разобрали «Великолепную пятерку» диаграмм, которые покрывают 90% потребностей современного разработчика:

Use Case — для требований.

Class — для структуры кода.

Activity — для бизнес-процессов.

Sequence — для взаимодействия объектов.

State Machine — для сложной логики состояний.

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

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

Полезные ссылки

* Спецификация UML 2.5.1 (раздел State Machines) * Спецификация UML 2.5.1 (раздел Deployments)