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

Введение в UML: история, стандарты и основные элементы нотации

Добро пожаловать на курс «Основы UML: визуальное моделирование систем». Мы начинаем погружение в мир системного анализа и архитектуры с фундаментального инструмента, который стал стандартом де-факто в IT-индустрии — Unified Modeling Language (UML).

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

Что такое UML?

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

Важно понимать главное различие: Методология (например, Agile, Scrum, Waterfall) говорит нам, что* делать и в какой последовательности. UML — это язык*, который дает словарь и грамматику для того, чтобы выразить свои идеи. Он не диктует процесс разработки, он дает инструменты для описания системы.

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

История создания: объединение методов

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

Ключевой поворот произошел, когда трое ведущих специалистов объединили усилия в компании Rational Software. Их называют «Три амиго»:

Грейди Буч (Grady Booch) — силен в проектировании и конструировании.

Джеймс Рамбо (James Rumbaugh) — специализировался на анализе систем.

Ивар Якобсон (Ivar Jacobson) — привнес концепцию вариантов использования (Use Cases).

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

Зачем нам моделирование? Математика сложности

Главная проблема современной разработки — сложность. Человеческий мозг способен удерживать в кратковременной памяти ограниченное количество объектов (знаменитое число Миллера ).

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

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

Пример: Если у вас в системе всего 5 модулей (), то количество связей . Это легко удержать в голове. Но если модулей становится 20 (), то . Удержать в голове 190 связей невозможно.

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

Основные элементы нотации (Building Blocks)

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

1. Сущности (Things)

Это «существительные» языка UML. Основные абстракции, которые мы моделируем.

Структурные сущности: Базовые части модели. Примеры: Класс (описание множества объектов), Интерфейс (набор операций), Компонент* (модульная часть системы). Поведенческие сущности: Динамические части. Примеры: Взаимодействие (обмен сообщениями), Состояние* (статус объекта). Группирующие сущности: Организационные части. Пример: Пакет* (папка для упорядочивания элементов). Аннотирующие сущности: Пояснения. Пример: Примечание* (комментарий к диаграмме).

2. Отношения (Relationships)

Это «глаголы» языка, связывающие сущности между собой.

* Зависимость (Dependency): Изменение одного элемента влияет на другой. Обозначается пунктирной стрелкой. * Ассоциация (Association): Структурная связь, показывающая, что объекты связаны (например, «Учитель» учит «Ученика»). * Обобщение (Generalization): Наследование. Отношение «является частным случаем» (например, «Кот» является «Животным»). * Реализация (Realization): Отношение между интерфейсом и классом, который его исполняет.

3. Диаграммы (Diagrams)

Это графическое представление набора элементов. Согласно neogenda.com, диаграммы позволяют видеть общую картину системы и находить оптимальные решения.

В UML 2.x существует 14 типов диаграмм, которые делятся на две большие группы:

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

#### Поведенческие диаграммы (Behavioral Diagrams) Отображают динамический аспект («как система работает во времени»). * Диаграмма вариантов использования (Use Case): Описывает, что система делает с точки зрения пользователя. * Диаграмма последовательности: Показывает обмен сообщениями между объектами в хронологическом порядке. * Диаграмма деятельности (Activity): Блок-схема алгоритмов и бизнес-процессов. * Диаграмма состояний: Показывает переходы объекта из одного состояния в другое (например, Заказ: Создан -> Оплачен -> Отправлен).

Инструменты для работы

Рисовать UML на бумаге полезно для черновиков, но для документации используют специализированный софт. Согласно guru99.com, выбор инструмента зависит от задач, но среди популярных можно выделить: * Enterprise Architect: Мощный комбайн для корпоративных систем. * Visual Paradigm: Поддерживает полный цикл разработки. * Draw.io / Diagrams.net: Бесплатный веб-инструмент для быстрого создания схем. * PlantUML: Инструмент «UML как код», позволяющий генерировать диаграммы из текстового описания.

Итоги

Мы рассмотрели фундамент, на котором будет строиться весь наш курс. Запомните ключевые моменты:

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

Стандартизация. Благодаря «Трем амиго» и консорциуму OMG, мы имеем единый стандарт, понятный разработчикам во всем мире.

Три элемента нотации. Любая диаграмма состоит из Сущностей (объекты), Отношений (связи) и самих Диаграмм (виды).

Два типа диаграмм. Всегда различайте статику (структурные диаграммы) и динамику (поведенческие диаграммы).

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

Диаграммы вариантов использования (Use Case) для описания требований

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

Именно для этого существуют Диаграммы вариантов использования (Use Case Diagrams). Это самый простой для понимания вид диаграмм, который служит мостом между техническими специалистами и заказчиками.

Что такое Use Case?

Use Case (Вариант использования) — это описание последовательности действий, которые выполняет система в ответ на событие, инициируемое пользователем (или другой системой), для достижения конкретной цели.

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

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

Ключевая концепция: «Черный ящик»

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

Основные элементы диаграммы

Нотация Use Case диаграммы предельно лаконична. Она состоит всего из четырех основных элементов.

1. Актор (Actor)

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

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

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

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

Правила именования: * Имя должно быть глагольным выражением. * Плохо: «Данные», «Отчет», «Настройки». * Хорошо: «Сохранить данные», «Сформировать отчет», «Изменить настройки».

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

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

4. Связи (Relationships)

Линии, соединяющие элементы.

Типы отношений: самая сложная часть

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

Ассоциация (Association)

Сплошная линия между Актором и Вариантом использования. Она просто говорит: «Этот актор участвует в этом сценарии».

Включение (Include)

Обозначается пунктирной стрелкой с меткой <<include>>.

Используется, когда один вариант использования обязательно включает в себя выполнение другого. Это способ избежать дублирования. Если у вас есть сценарии «Заказать пиццу» и «Заказать суши», и в обоих случаях нужно «Проверить адрес доставки», вы выносите проверку адреса в отдельный овал и связываете их отношением <<include>>.

> Use Case похож на инструкции... нажмите на кнопку — получите результат; если результат выглядит иначе, выполните следующие действия. > > practicum.yandex.ru

Расширение (Extend)

Обозначается пунктирной стрелкой с меткой <<extend>>.

Используется, когда один вариант использования может (но не обязан) сработать при выполнении другого при определенных условиях.

Пример: * Базовый сценарий: «Оформить заказ». * Сценарий расширения: «Применить промокод». * Связь: «Применить промокод» --<<extend>>--> «Оформить заказ».

Вы можете оформить заказ без промокода. Но промокод не существует сам по себе без заказа.

Обобщение (Generalization)

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

Сценарий: текст за картинкой

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

Согласно systems.education, полноценное описание включает:

Название и ID.

Акторы.

Предусловия: Что должно быть истиной до начала (например, «Пользователь авторизован»).

Основной поток (Basic Flow): «Счастливый путь», где все идет по плану.

Альтернативные потоки (Alternative Flows): Ошибки, ветвления (например, «Недостаточно средств», «Товар закончился»).

Постусловия: Состояние системы после завершения.

Оценка сложности тестирования

Use Case диаграммы помогают не только разработчикам, но и QA-инженерам (тестировщикам). Глядя на сценарий, можно математически оценить минимальное количество тест-кейсов, необходимых для покрытия функционала.

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

где — общее количество сценариев тестирования (тест-кейсов), — это основной поток (Basic Flow, «счастливый путь»), — количество точек ветвления в сценарии, а — количество альтернативных исходов в -й точке ветвления.

Пример расчета: Представьте сценарий «Снятие наличных в банкомате».

Основной путь (все хорошо) = 1.

Ветвление 1: Ввод ПИН-кода. Альтернатива: Неверный ПИН ().

Ветвление 2: Проверка баланса. Альтернатива: Недостаточно средств ().

Ветвление 3: Наличие купюр в банкомате. Альтернатива: Нет купюр ().

Итого:

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

Практический пример: Библиотека

Рассмотрим пример системы для библиотеки, который упоминается на habr.com.

Акторы: Читатель, Библиотекарь.

Use Cases Читателя:

* «Найти книгу». * «Забронировать книгу».

Use Cases Библиотекаря:

* «Выдать книгу». * «Принять книгу». * «Добавить новую книгу».

Связь <<include>>: Сценарий «Выдать книгу» включает в себя «Проверить читательский билет». Библиотекарь не может выдать книгу, не проверив билет.

Частые ошибки новичков

Слишком много деталей. Не рисуйте «Нажать кнопку ОК» или «Ввести пароль» как отдельные овалы. Это шаги сценария, а не сам сценарий. Овал — это цель (например, «Авторизоваться»).

Стрелки направления данных. В Use Case стрелки показывают инициатора взаимодействия, а не то, куда летят данные. Если Читатель ищет книгу, стрелка идет от Читателя к «Найти книгу», даже если система возвращает ему список книг.

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

Итоги

Мы разобрали инструмент, который позволяет перевести абстрактные «хотелки» бизнеса на язык четких сценариев.

Use Case — это про цели. Диаграмма показывает, зачем пользователи приходят в систему.

Акторы — это роли. Один человек может играть разные роли в разное время.

Различайте связи. Include — это «всегда», Extend — это «иногда».

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

Основа для тестов. Правильно составленные сценарии позволяют математически точно рассчитать объем работ по тестированию.

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