Введение

---

Обзор

UML 2.0 организует диаграммы в две основные категории:

Категория	Назначение
Структурные диаграммы	Фиксируют физическую организацию элементов — как объекты взаимосвязаны между собой
Поведенческие диаграммы	Сфокусированы на том, как элементы взаимодействуют, изменяют состояние и обрабатывают поведение во времени

💡 Ключевой принцип: Модель UML состоит из одной или нескольких диаграмм. Каждая диаграмма представляет определённый взгляд или интерес в моделируемой системе. Отдельные элементы часто появляются на нескольких диаграммах.

---

🔷 Структурные диаграммы

Структурные диаграммы моделируют статическую архитектуру вашей системы — «что», а не «как».

1. Диаграммы классов

Назначение: Классы модели, интерфейсы и их статические отношения.

Ключевые элементы:

• Классы с атрибутами и операциями

• Интерфейсы и отношения реализации

• Ассоциации, агрегации, композиции и обобщения

• Модификаторы видимости (+, -, #, ~)

• Спецификации многозначности (1, 0..*, 1..5)

Пример использования:Когда использовать:

Стереотипы и типы классов

На диаграмме используются стереотипы (обозначены текстом внутри угловых скобок, например <<entity>>) для категоризации роли каждого класса:

• Классы границы (<<граница>>): Они обрабатывают взаимодействие между системой и ее участниками (пользователями или внешними системами).

• Примеры: Окно консоли и Окно диалога.

• Классы управления (<<управление>>): Они управляют координацией, транзакциями и потоком бизнес-логики приложения.

• Примеры: Контекст рисования и Контроллер данных.

• Классы сущностей (<<сущность>>): Они представляют основные данные или постоянную информацию, которую система отслеживает.

• Примеры: Фрейм, Окно, Событие, Фигура, Круг, Прямоугольник, Многоугольник, и Точка.

• Абстрактный класс: Класс Фигура класс представляет абстрактное понятие. Он служит базовым чертежом для конкретных фигур и не может быть напрямую создан сам по себе.

---

Анатомия класса

Стандартный блок класса UML делится на секции. Рассмотрим в качестве примера класс Круг класса:

• Имя класса: Находится в верхней секции (Круг).

• Атрибуты: Находится в средней секции, представляя поля данных.

• -радиус : float (Знак минус - указывает на приватный атрибут).

• -центр : беззнаковый int

• Операции (методы): Находится в нижней секции, представляя поведение или функции.

• +area(в радиусе : float) : double (Знак плюс + указывает на публичный метод).

• +circum(), +setCenter(), и +setRadius().

---

Связи и ссылки

Линии и стрелки, соединяющие классы, определяют, как они взаимодействуют и зависят друг от друга:

Обобщение (наследование)

Обозначается сплошной линией с пустой стрелкой указывающей на родительский класс. Это указывает на связь «является» (is-a), при которой дочерний класс наследует атрибуты и поведение от родительского класса.

• Окно наследуется от Фрейм.

• Консольное окно и Окно диалога наследуются от Окно.

• Круг, Прямоугольник, и Многоугольник наследуют от абстрактного класса Фигуру (например, круг является Фигурой).

Агрегация

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

• Окно агрегирует Фигуру (множественность 1 до *). Окно Окно может содержать несколько (*) фигур, но если окно закрыто, сами фигуры по-прежнему могут существовать в памяти или в другом контексте.

Композиция

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

• Круг состоит из Точки объектов (множественность 1 к *). Окружность не может существовать без своего центра или граничных точек; уничтожение окружности уничтожает эти конкретные ссылки на точки.

Зависимость

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

• Окно зависит от Событие (обозначено штриховой стрелкой, указывающей на Событие). Окно зависит от событийных триггеров для выполнения операций, таких как handleEvent().

Ассоциация

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

• Диалоговое окно ассоциировано с Контроллер данных, что означает, что они обмениваются информацией или координируют поведение.

---

Элементы документации

• Примечание: На диаграмме присутствует блок с заметкой с загнутым углом, соединённый штриховой линией с классом Окно класса. Он предоставляет читаемый человеком контекст: «Основное окно приложения».

• Проектирование архитектуры объектно-ориентированного программного обеспечения

• Документирование моделей домена

• Генерация скелетов кода

---

2. Диаграммы компонентов

Цель: Показать организацию и зависимости единиц реализации.

Ключевые элементы:

• Компоненты (с типом «component»)

• Предоставляемые/требуемые интерфейсы (нотация шар-гнездо)

• Соединители сборки и отношения зависимостей

• Артефакты (скомпилированные выходные данные: JAR, DLL, исполняемые файлы)

Пример использования:Когда использовать:

Компоненты и модульные границы

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

Интерфейсы как контракты

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

• Предоставляемые интерфейсы: Представляются в виде символа «леденец» или круга, они обозначают службы, данные или операции, которые компонент реализует и предоставляет своей среде. Например, внешний компонент Terminal предоставляет внешние предоставляемые интерфейсы, такие какСостояние, Детали, и Объект осмотра, что указывает на то, что внешние клиенты могут запрашивать у него.

• Требуемые интерфейсы: Представляются в виде символа «розетка» или полукруга, они определяют службы или данные, которые компоненту необходимы от другого объекта для корректной работы. Справа на диаграмме компонент Terminal явно показывает требуемые интерфейсы дляСчет и Идентификатор осмотра, что показывает его зависимость от внешних подсистем.

Порты и внутренняя разводка

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

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

• Делегирование и сборка: Внутри Terminal линии соединяют эти интерфейсы, образуя структурную сборку. Предоставляемый интерфейс на внешнем порту делегирует входящие запросы непосредственно предоставляемому интерфейсу внутреннего компонента (как видно на путях Состояние и Детали которые ведут в Безопасный осмотр). Напротив, внутренние компоненты подключают свои требуемые интерфейсы розеток непосредственно к предоставляемым интерфейсам «леденцов» соседних компонентов. Например, компонент Безопасный осмотр зависит от интерфейса Инспектор который предоставляется Персонал, который Сведения об ошибке интерфейс, предоставляемый Ошибка, и Расположение интерфейс, предоставляемый Карта, создавая тесно координированную, но слабо связанную внутреннюю экосистему.

• Планирование модульной архитектуры системы

• Управление зависимостями сборки

• Документирование библиотек повторно используемых компонентов

---

3. Диаграммы композитной структуры(Добавлено в UML 2.0)

Ключевые элементы:

• Части (свойства с отношениями целое-часть)

• Порты (точки взаимодействия с предоставляемыми/требуемыми интерфейсами)

• Соединители (связи во время выполнения между частями)

• Возникновения сотрудничества

Пример использования: Моделирование Автомобиль:

Класс-оболочка (класс)

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

Части (внутренняя структура)

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

• -t : Трансмиссия: Экземпляр, выполняющий роль трансмиссионной системы.

• -e : Двигатель: Экземпляр, выполняющий роль источника энергии двигателя.

• -s : Система рулевого управления: Экземпляр, выполняющий роль механизма рулевого управления.

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

Порты и границы

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

• Внешние порты на границе автомобиля — например,: Колесо, : Дроссельная педаль, и: Руль—показывают, как автомобиль взаимодействует с внешним миром или физической средой, не раскрываякакиевнутренние части отвечают за эти взаимодействия.

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

Соединители и внутренняя проводка

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

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

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

Когда использовать:

• Документирование шаблонов проектирования

• Моделирование сложных внутренних взаимодействий

• Связывание проектирования классов и реализации компонентов

---

4. Диаграммы развертывания

Цель: Сопоставление программных артефактов с аппаратными средами выполнения.

Ключевые элементы:

• Узлы (устройства, среды выполнения)

• Артефакты (развертываемые единицы)

• Каналы связи между узлами

• Спецификации развертывания (детали конфигурации)

Пример использования:Когда использовать:

Узлы и физическая инфраструктура

В отличие от диаграмм логического проектирования, которые моделируют структуру кода или классов, диаграмма развертывания фокусируется на аппаратной топологии. Основными элементами являютсяУзлы, которые визуально представлены в виде трехмерных кубов. Узлы иллюстрируют физические вычислительные ресурсы или среды выполнения, где фактически работают программные элементы:

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

• <<сеть>> Узлы: Вытянутый куб, помеченный какЛокальная сеть представляет путь связи или инфраструктуру маршрутизации, а не отдельный компьютер. Он обозначает физическую основу, позволяющую подключенным процессорам обмениваться потоками данных.

• Узлы устройств: Нестереотипизированные узлы, такие какИнтернет иБанк модемов представляют граничные аппаратные компоненты или внешнюю физическую инфраструктуру, необходимую для маршрутизации внешнего трафика в основную среду системы.

Связи и пути коммуникации

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

• Линия между Интернет и Банка модемовиллюстрирует точку входа внешних публичных данных в аппаратный стек.

• Ассоциация, простирающаяся от Банка модемов вниз до сервера кэшированияотображает физическое направление входящего трафика до слоя кэширования на периферии.

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

Топологическая многоуровневость и избыточность

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

• Слой кэширования на периферии: Расположенные непосредственно под аппаратным обеспечением модема точки входа находятся два различных, параллельных сервера кэшированияузла. Такая конфигурация визуально демонстрирует избыточный слой на периферии, предназначенный для распределения нагрузки входящего трафика и кэширования активов до того, как запросы достигнут глубокой инфраструктуры.

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

Цель: Моделирование внутренней структуры классификаторов и сложных паттернов.

• Планирование инфраструктуры системы

• Документирование распределенных архитектур

• Определение стратегий отказоустойчивости и резервирования

---

5. Диаграммы пакетов

Цель: Организация и управление пространствами имен с помощью логической группировки.

Ключевые элементы:

• Пакеты (прямоугольники с закладками)

• Связи импорта/доступа («import», «access»)

• Связи слияния («merge»)

• Видимость (+ public, - private)

Пример использования:

Границы подсистемы и пакета

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

• Подсистема: Большая внешняя папка, стереотипизированная как <<подсистема>> Заказы представляет собой крупный, инкапсулированный поведенческий элемент физической системы. Он выступает в качестве контейнера высокого уровня, объединяющего связанные компоненты и пакеты, необходимые для выполнения управления заказами.

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

Зависимости и уровневая структура

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

• Внутренние зависимости: Внутри подсистемы заказов видна четкая иерархическая архитектурная структура. Пакет Интерфейс пользователя зависит от Обработки заказов, которая, в свою очередь, зависит от Калькулятор цен и Внешнее хранилище. Это отражает архитектурный поток, при котором элементы верхнего уровня представления зависят от основных бизнес-логических и слоев доступа к данным.

• Зависимость от внешнего пакета: Пакеты также могут зависеть от элементов за пределами их непосредственной границы подсистемы. Например, пакет Интерфейс пользователя пакет зависит от внешнего GUIManager. Аналогично, пакеты Random Storage и Stream Storage пакеты внизу пересекают границу подсистемы, чтобы зависеть от внешних структур данных, что подчеркивает, как подсистема интегрируется в более крупную программную экосистему.

Абстракция и наследование (обобщение)

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

• Абстрактные и конкретные пакеты: Пакеты, содержащие абстрактные элементы или определяющие структуру, подобную интерфейсу, обозначаются курсивом (например, External Storage и StorageManagement). Напротив, пакеты, содержащие реализации операционного кода, такие как Repository и FileStorage, используют обычный шрифт, чтобы показать, что они являются конкретными пакетами.

• Обобщение: Обозначается сплошной линией с открытым, пустым треугольником, указывающим на родительский пакет. Это указывает на отношение наследования или реализации. Внутри подсистемы Random Storage и Stream Storage специализируют или реализуют абстрактный интерфейс External Storage интерфейс. За пределами подсистемы конкретные пакеты Repository и FileStorage пакеты обобщаются до абстрактного уровня УправлениеХранения пакет, показывающий, как полиморфное поведение и структурная классификация могут быть смоделированы на уровне пакета.

  

• Когда использовать:

• Управление большими кодовыми базами

• Определение границ модулей

• Контроль зависимостей компиляции

---

6. Диаграммы объектов

Цель: Показать снимки экземпляров и их связей в определенный момент времени.

Ключевые элементы:

• Объекты (имена с подчеркиванием: myCar:Car)

• Связи между экземплярами объектов

• Значения атрибутов во время выполнения

Пример использования:

Объекты и конкретные экземпляры

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

• Именованные объекты: Они следуют синтаксису instanceName : ClassName. Например, c : Company представляет конкретный экземпляр компании с именем «c», и p : Person представляет конкретный экземпляр отдельного лица с именем «p».

• Анонимные объекты: Когда конкретный идентификатор экземпляра опущен или не имеет значения для сценария, указывается только имя класса, предваряемое двоеточием (например, : ContactInformation). Это означает, что существует конкретный экземпляр контактной информации, привязанный к структуре, но в данном контексте ему не требуется уникальное имя переменной.

Состояние и значения атрибутов

Нижняя часть прямоугольника объекта содержит его конкретное состояние, определяемое явными значениями, присвоенными его атрибутам в данный момент. Вместо простого перечисления типов данных, эти записи используют формат присвоения атрибут = значение присвоения, чтобы отразить реальность:

• Экземпляр отдела d1 хранит значение атрибута name = Sales.

• Другой отдельный экземпляр отдела d2 хранит значение name = R&D.

• Экземпляр человека p хранит полный набор данных состояния, отражающий конкретный профиль: name = Derek, employeeID = D-12821, и title = Manager.

Связи и отношения

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

• Экземпляр компании c активно связан с экземплярами подразделений d1 (Продажи) и d2 (Исследования и разработки).

• На диаграмме также показано иерархическое соединение экземпляров, где d1 : Подразделение (Продажи) связано с подчинённым экземпляром подразделения, также типизированным как Подразделение (name = США Продажи).

• Наконец, экземпляр человека p (Дерек) связан с экземпляром подразделения США Продажи, одновременно поддерживая связь с анонимным : Сведения о контакте экземпляром, содержащим его физический адрес.

Когда использовать:

• Проверка проектов диаграмм классов

• Отладка сложных отношений между объектами

• Демонстрация примеров состояний во время выполнения

---

🔶 Диаграммы поведения

Диаграммы поведения моделируют динамические аспекты — как система ведёт себя во времени.

7. Диаграммы деятельности

Цель: Моделирование рабочих процессов, бизнес-процессов и алгоритмической логики.

Ключевые элементы:

• Действия (округлые прямоугольники)

• Узлы управления: начальный, решение, слияние, разветвление, объединение, конечный

• Узлы объектов и контакты

• Разделы (полосы) для распределения ответственности

• Обработчики исключений и прерываемые области

Пример использования: рабочий процесс обработки заказов

Структурная организация (полосы и разделы)

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

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

• Ответственный за предложение: Управляет основным планированием, операционным анализом и компиляцией формальных структур данных предложения.

• Ответственный за цитату: Фокусируется исключительно на финансовой оценке и подготовке конкретных показателей цитаты.

Управление потоком и состояния действия

Пошаговое процедурное выполнение управляется узлами управления и направленными путями.

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

• Действие: Округлые прямоугольники (например, Инициализировать контакт, Поиск альтернативы, и Собрать дополнительную информацию) представляют собой отдельные, неделимые шаги или задачи в последовательности выполнения.

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

• Узел завершения действия: Символ мишени (сплошной круг внутри пустого кольца) внизу обозначает абсолютную точку завершения выполнения всего процесса.

Маршрутизация и защищённая логика (узлы принятия решений)

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

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

• Условия, определяющие, какой путь выбрать, заключены в квадратные скобки, известные как условные выражения (например,[принято], [отклонено], и[присоединиться к другому поставщику или изменить требования]). Процесс оценивает эти условия во время выполнения, чтобы направить выполнение по соответствующему функциональному пути.

Параллельная обработка (узлы разделения и объединения)

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

• Узел разделения (обозначен как узел потока на указателе диаграммы): Один входящий поток управления входит в полосу и разделяется на несколько независимых, параллельных потоков выполнения. Здесь, после создания плана проекта, процесс разделяется, чтобы позволить владельцу предложения выполнить анализ и планирование доставки, в то время как владелец предложения одновременно занимается подготовкой предложения.

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

Интеграция данных (узлы объектов)

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

• Узлы объектов представляют экземпляры конкретных данных или физических изделий, создаваемых или используемых действиями, с использованиемinstanceName : ClassName соглашение (например, aProposal : Proposal и aPlan : Delivery Project Plan).

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

Когда использовать:

• Документирование бизнес-процессов

• Моделирование реализации случаев использования

• Определение сложных алгоритмов

---

8. Диаграммы машин состояний (Statecharts)

Цель: Моделирование жизненного цикла и поведения объектов, зависящего от состояния.

Ключевые элементы:

• Состояния (округлые прямоугольники с действиями входа/выхода/выполнения)

• Переходы (триггер[условие]/эффект)

• Псевдосостояния: начальное, выбор, расщепление, объединение, история, завершение

• Составные состояния и ортогональные области

Пример использования: настройка телефонии

Состояния и условия системы

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

• Состояния: Округлые прямоугольники представляют состояния (например, Ожидание, Тон, Ввод номера, Соединение, и Соединено). Состояние представляет собой период в жизненном цикле объекта, в течение которого он удовлетворяет некоторому условию, выполняет действие или ожидает события.

• Начальное псевдосостояние: Тёмный круг слева представляет начальную точку машины состояний. Это псевдосостояние, а не настоящее состояние, служащее лишь указателем на начальное активное состояние при создании объекта (Покой).

• Финальное состояние: Символ мишени справа представляет завершение выполнения машины состояний, указывая на то, что объект завершил свой жизненный цикл.

Переходы и маршрутизация, управляемая событиями

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

• Стандартные переходы: Инициируются конкретными событиями, такими как действие пользователя или ответ системы, указанные вдоль линий. Например, переход от Покой к Тон происходит, когда onHook событие активируется, и переход от Тон к Ввод номера происходит, когда цифрой(n) событие получено.

• Самопереходы: Стрелка перехода, которая выходит из состояния и возвращается непосредственно в то же самое состояние (как видно на Выбор номера состоянии с цифрой(n) триггером). Это означает, что событие обрабатывается и обновляет внутреннее состояние (например, записывает только что набранную цифру), не заставляя объект покинуть текущее состояние или изменить общее операционное состояние.

Альтернативные пути и обработка ошибок

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

• Путь успешного выполнения: Центральная горизонтальная магистраль показывает оптимальный путь: Ожидание $rightarrow$ Тон выбора $rightarrow$ Выбор номера $rightarrow$ Соединение $rightarrow$ Звонок $rightarrow$ Соединено $rightarrow$ Отключено.

• Состояния обработки исключений и ошибок: Система учитывает сбои или задержки, ветвясь в специальные состояния обработки. Если номер занят во время соединения, система активирует состояние номерЗанят переход для входа в Занятой тон состояние. Если пользователь слишком долго паузится при наборе, то тайм-аут событие переводит систему в состояние Предупреждение или Тайм-аут состояние. Если обнаружен неверный последовательность, то некорректныйНомер триггер переводит систему в состояние Записанное сообщение состояние, обеспечивая безопасную обработку всех крайних случаев реального мира.

 

Когда использовать:

• Моделирование встроенных систем или реализаций протоколов

• Определение управления состоянием пользовательского интерфейса

• Документирование правил жизненного цикла объектов

---

9. Диаграммы взаимодействия

Четыре типа диаграмм подчеркивают различные аспекты взаимодействия объектов:

a) Диаграммы последовательности(Наиболее распространённый)

Цель: Показывает временные сообщения между жизненными линиями.

Ключевые элементы:

• Жизненные линии (вертикальные штриховые линии)

• Сообщения (сплошные/штриховые стрелки с метками)

• Возникновения выполнения (активационные полосы)

• Совмещённые фрагменты: альт, опт, цикл, пар, прервать

Пример использования:

Жизненные линии и контексты выполнения

Диаграмма читается слева направо для установления участников, а сверху вниз — для обозначения прохождения времени.

• Жизненные линии: Коробки вверху, прикреплённые к пунктирным вертикальным линиям, представляют жизненные линии. Они моделируют отдельных участников взаимодействия, следуя соглашению имяЭкземпляра : ИмяКласса соглашению (например, окно : UI, aChain : HotelChain, и aHotel : Hotel). Пунктирная линия отслеживает существование этого участника на протяжении всей последовательности.

• Блоки активации: Тонкие цветные вертикальные прямоугольники, расположенные на жизненных линиях, указывают на активацию (или возникновение выполнения). Эти полосы показывают точно, когда объект активно выполняет операцию или ожидает возврата вложенного подвызова.

• Остановлено: Большой символ «Х» внизу окно : UI линия жизни указывает на уничтожение или завершение, показывая, что жизненный цикл этого конкретного участника завершён, и его ресурсы освобождены.

Типы сообщений и коммуникация

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

• Синхронные сообщения: Сплошные линии с сплошными стрелками (например, 1: makeReservation и 1.1: makeReservation) указывают на синхронные вызовы. Отправитель блокирует выполнение и ожидает завершения обработки получателем.

• Сообщения самому себе: Цикл сообщения, который начинается и заканчивается на одной и той же полосе активации (например, 1.1.1: available(roomId, date): isRoom выполнено aHotel) представляет собой Сообщение самому себе. Это указывает на внутренний вызов метода, при котором объект вызывает одну из собственных операций.

• Сообщения создания: Штриховая линия с открытой стрелкой, направленной прямо на ящик объекта (например, сообщение 1.1.2: направленное на aReservation : Reservation) представляет создание объекта. Это показывает, что экземпляр aHotel динамически создает объект aReservation в этот точный момент во время выполнения последовательности.

Совмещённые фрагменты и поток управления

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

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

• Альтернативный комбинированный фрагмент (Alt): Внутри цикла находится фрагмент alt (обозначенный как «Если» в указателе диаграммы), который обрабатывает условное ветвление. Он оценивает условие-охрану [isRoom = true]. Если условие выполняется, последовательность выполняет конкретный путь внутри этого блока — создавая экземпляр aReservation и последующее запуск сообщения 2: для создания экземпляра aNotice : Подтверждение. Если условие было бы ложным, был бы выбран альтернативный путь (или никаких действий не предпринималось бы).

  

b) Диаграммы взаимодействия

Цель: Акцент на отношениях между объектами, а не на временных характеристиках сообщений.

Ключевые элементы:

• Объекты как узлы

• Связи с пронумерованными направленными сообщениями

• Акцент на «кто говорит с кем»

c) Диаграммы обзора взаимодействий

Цель: Высокоуровневая последовательность управления с использованием нотации диаграммы деятельности.

Ключевые элементы:

• Возникновения взаимодействий как узлы деятельности

• Решение/слияние для ветвления

• Разделение/объединение для параллелизма

d) Диаграммы временных интервалов

Цель: Моделирование точных временных ограничений (системы реального времени).

Ключевые элементы:

• Хронограммы состояний для каждого жизненного пути

• Масштабы времени и ограничения

• Стрелки сообщений с маркерами продолжительности

Когда использовать взаимодействия:

• Определение реализаций случаев использования

• Отладка сложных потоков сообщений

• Документирование шаблонов использования API

• Моделирование временных характеристик протокола в реальном времени

---

10. Диаграммы случаев использования

Цель: Захват функциональных требований с точки зрения внешнего актора.

Ключевые элементы:

• Случаи использования (овалы или прямоугольники классификаторов)

• Акторы (рисунки фигурок или классификаторы)

• Ассоциации (актор ↔ случай использования)

• Связи: «include», «расширить», обобщение

• рамка границ системы

Пример использования: система банкомата

Когда использовать:

• Сбор требований с заинтересованными сторонами

• Определение границ и масштаба системы

• Планирование сценариев тестирования

---

🎯 Выбор правильной диаграммы: руководство по принятию решений

Цель	Рекомендуемая(ые) диаграмма(ы)
Проектирование структуры классов	Класс, объект, пакет
Моделирование взаимодействий во время выполнения	Последовательность, коммуникация
Документирование бизнес-процессов	Диаграмма активности, диаграмма вариантов использования
Определение жизненного цикла объекта	Машина состояний
Планирование развертывания системы	Развертывание, компонент
Моделирование сложных внутренних паттернов	Составная структура
Фиксация ограничений в реальном времени	Диаграмма временных интервалов
Определение требований	Вариант использования, диаграмма активности

---

🔑 Ключевые принципы моделирования

1. Начните просто: Начните с типа диаграммы, который лучше всего соответствует вашей текущей цели.

2. Итерируйте: Уточняйте модели по мере углубления понимания — ни одна диаграмма не является «окончательной» на первом черновике.

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

4. Объединяйте взгляды: Используйте несколько диаграмм, чтобы рассказать полную историю (например, Сценарий использования → Последовательность → Класс).

5. Расширяйте осознанно: Используйте стереотипы, помеченные значения и профили для специфических потребностей домена, но документируйте принятые соглашения.

6. Держите его читаемым: Опускайте нерелевантные детали; используйте примечания для дополнительного контекста.

📌 Помните: «UML — это язык, а не методология.» Он предоставляет нотацию — не процесс. Выбирайте диаграммы, которые упрощают коммуникацию, а не те, которые просто нужно отметить.

Заключение

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文