Основы моделирования и проектирования систем на языке UML

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

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

Разработка сложного программного обеспечения напоминает строительство небоскрёба. Нельзя просто привезти кирпичи и начать кладку — необходим чертёж. В мире IT таким «чертежом» является UML (Unified Modeling Language). Это не язык программирования, а международный стандарт визуального моделирования, который позволяет разработчикам, аналитикам и архитекторам говорить на одном языке.

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

Что такое UML и зачем он нужен

UML (Унифицированный язык моделирования) — это графический язык для визуализации, спецификации, конструирования и документирования артефактов программных систем. Он позволяет создать абстрактную модель системы (blueprint) до написания первой строчки кода.

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

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

Пример: Если в команде 5 человек, то каналов связи . Если команда вырастает до 20 человек, количество каналов становится . Без единой документации (UML) согласовать действия 20 человек через устное общение невозможно. UML снижает эту нагрузку, предоставляя единый источник истины.

Согласно practicum.yandex.ru, UML — это набор правил, по которым нужно рисовать схемы, позволяющий визуализировать явление или процесс так, чтобы схема была понятна всем специалистам.

История создания: от «войны методов» к стандарту

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

Метод Гради Буча (Grady Booch) — отлично подходил для проектирования и строительства объектов.

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

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

Эти три инженера, работавшие в компании Rational Software, объединили усилия. Их стали называть «Три амиго». В 1996 году они выпустили спецификацию UML, объединившую лучшие черты их методов.

> UML был признан стандартом Object Management Group (OMG) в 1997 году. Object Management Group отвечает за управление UML с момента его принятия в качестве стандарта. > > guru99.com

С 2005 года UML также является стандартом ISO. Текущая актуальная версия спецификации — UML 2.5.1, выпущенная в декабре 2017 года.

Классификация диаграмм UML

В UML 2.5 существует 14 типов диаграмм. Чтобы не запутаться, их делят на две большие группы: структурные (статические) и поведенческие (динамические).

1. Структурные диаграммы (Structural Diagrams)

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

* Диаграмма классов (Class Diagram): Самая популярная диаграмма. Показывает классы, их атрибуты, методы и связи между ними. * Диаграмма компонентов (Component Diagram): Описывает организацию физических компонентов ПО (библиотек, файлов, модулей) и связи между ними. * Диаграмма развёртывания (Deployment Diagram): Показывает аппаратную часть системы (серверы, устройства) и то, какое ПО на них выполняется. * Диаграмма объектов (Object Diagram): Снимок системы в конкретный момент времени (экземпляры классов). * Диаграмма пакетов (Package Diagram): Группирует элементы в пакеты для упрощения структуры. * Диаграмма композитной структуры (Composite Structure Diagram): Детализирует внутреннюю структуру класса. * Диаграмма профилей (Profile Diagram): Используется для расширения самого языка UML под конкретную предметную область.

2. Поведенческие диаграммы (Behavioral Diagrams)

Эти диаграммы показывают, что происходит в системе. Они описывают процессы, алгоритмы и взаимодействие элементов во времени.

Диаграмма вариантов использования (Use Case Diagram): Описывает функциональные требования. Показывает, кто (Actor) и что* (Use Case) может делать в системе. * Диаграмма деятельности (Activity Diagram): Блок-схема алгоритмов и бизнес-процессов. Показывает поток управления от одной деятельности к другой. * Диаграмма состояний (State Machine Diagram): Показывает, как объект меняет своё состояние в ответ на события (например, заказ: «Создан» «Оплачен» «Доставлен»).

Диаграммы взаимодействия (Interaction Diagrams) — это подгруппа поведенческих диаграмм:

* Диаграмма последовательности (Sequence Diagram): Показывает обмен сообщениями между объектами в хронологическом порядке. * Диаграмма коммуникации (Communication Diagram): Аналог диаграммы последовательности, но с акцентом на связи между объектами, а не на время. * Диаграмма обзора взаимодействия (Interaction Overview Diagram): Гибрид диаграммы деятельности и последовательности. * Диаграмма синхронизации (Timing Diagram): Фокусируется на временных ограничениях при изменении состояний.

По данным blog.visual-paradigm.com, модели помогают работать на более высоком уровне абстракции, скрывая детали и фокусируясь на общей картине.

Базовые нотации и элементы

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

Сущности (Things)

Это основные элементы модели.

Класс (Class): Изображается как прямоугольник, разделённый на три части:

* Верхняя часть: Имя класса (например, User). * Средняя часть: Атрибуты (свойства, например, email: String). * Нижняя часть: Операции (методы, например, register()).

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

Актёр (Actor): Схематичный человечек. Обозначает роль пользователя или внешней системы, взаимодействующей с вашим продуктом.

Вариант использования (Use Case): Овал с текстом внутри. Обозначает конкретную функцию системы (например, «Оформить заказ»).

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

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

Примечания (Adornments)

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

Почему UML актуален сегодня?

Существует миф, что UML — это устаревшая бюрократия. Однако на практике он трансформировался. Редко кто рисует полные модели всех классов системы. Сегодня UML используют прагматично:

Sketching (Наброски): Быстрое обсуждение архитектуры у маркерной доски.

Documentation (Документация): Фиксация ключевых узлов системы (например, API или схемы базы данных) для новых сотрудников.

Communication (Общение): Язык понятен разработчикам на Java, Python, C# одинаково, так как он агностичен к языку программирования.

Как отмечает neogenda.com, UML применим для объектно-ориентированного подхода и идеально подходит для моделирования систем, позволяя структурировать объекты и их взаимодействия.

Итоги

* UML — это стандарт, а не просто набор картинок. Он позволяет однозначно передавать информацию о структуре и поведении системы. * Две главные категории диаграмм: структурные (что есть в системе) и поведенческие (как система работает). * Базовые элементы: классы (прямоугольники), актёры (человечки), варианты использования (овалы) и связи (стрелки разного типа). * Цель использования: снижение сложности коммуникации и выявление ошибок проектирования до начала написания кода.

2. Анализ требований: построение диаграмм вариантов использования (Use Case)

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

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

Прежде чем проектировать классы или базы данных, необходимо ответить на вопрос: «Что именно должна делать система?». Для этого в UML существует диаграмма вариантов использования (Use Case Diagram).

Что такое Use Case и зачем он нужен

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

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

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

Ключевые задачи диаграммы:

Определение границ: Что делает система, а что делает внешний мир.

Выявление акторов: Кто взаимодействует с системой.

Сбор требований: Функциональный список возможностей.

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

Нотация Use Case диаграммы намеренно сделана простой. В ней всего три главных графических примитива.

1. Актор (Actor)

Обозначается стилизованной фигуркой человечка.

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

Акторы бывают: * Люди: Клиент, Менеджер, Администратор. * Внешние системы: Банковский API, Система отправки SMS, Google Maps. * Время: Таймер (если процесс запускается автоматически по расписанию).

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

Обозначается овалом (эллипсом) с названием внутри.

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

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

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

Типы отношений (Связи)

Самая сложная часть для новичков — правильно соединить элементы. В Use Case диаграммах используется 4 основных типа связей.

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

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

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

Сплошная линия с пустым треугольником на конце (стрелка наследования). Работает так же, как в ООП.

* Между Акторами: Если у вас есть актор «Пользователь» и актор «Администратор», и Администратор умеет всё то же, что и Пользователь, плюс свои функции, то стрелка идет от Администратора к Пользователю. * Между Вариантами использования: Используется редко, когда один кейс является частным случаем другого (например, «Поиск товара» -> «Поиск по артикулу»).

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

Пунктирная стрелка с ключевым словом <<include>>.

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

Пример: У нас есть кейсы «Перевести деньги» и «Оплатить ЖКХ». В обоих случаях нужно проверить баланс. Мы создаем отдельный кейс «Проверить баланс» и направляем на него стрелки <<include>> от обоих процессов.

> «Перевести деньги» --- <<include>> --> «Проверить баланс»

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

Пунктирная стрелка с ключевым словом <<extend>>.

Это отношение опциональности. Расширяющий вариант использования срабатывает только при выполнении определённых условий. Стрелка идет ОТ расширения К базовому кейсу (в обратную сторону по сравнению с include).

Пример: Базовый кейс: «Оформить заказ». Если пользователь хочет подарочную упаковку, срабатывает расширение «Добавить упаковку».

> «Добавить упаковку» --- <<extend>> --> «Оформить заказ»

Текстовое описание сценариев

Сама по себе картинка (диаграмма) — это лишь оглавление книги. Основная суть требований скрыта в текстовом описании сценариев. По данным practicum.yandex.ru, use case похож на инструкцию: нажмите кнопку — получите результат.

Каждый овал на диаграмме должен иметь спецификацию, включающую:

Название: (например, «Снять наличные»).

Основной поток (Main Success Scenario): Идеальный путь, когда всё идет без ошибок.

Альтернативные потоки (Alternative Flows): Ошибки, отмены, ветвления.

Оценка сложности через сценарии

Понимание количества сценариев помогает оценить объем работы тестировщиков. Общее количество тест-кейсов () для одного варианта использования можно грубо оценить по формуле:

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

Пример: Рассмотрим кейс «Авторизация».

Основной путь: Ввод верного логина/пароля -> Успех ().

Ветвление 1 (Проверка логина): Логин не найден ().

Ветвление 2 (Проверка пароля): Пароль неверный ().

Ветвление 3 (Статус аккаунта): Аккаунт заблокирован ().

Итого: сценария, которые нужно покрыть тестами.

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

Давайте спроектируем систему банкомата.

Акторы:

Клиент* (хочет снять деньги). Техник* (обслуживает банкомат). Банковская система* (внешний сервер, подтверждающий транзакции).

Варианты использования:

* «Ввести PIN-код». * «Снять наличные». * «Запросить баланс». * «Заблокировать карту» (расширение при 3 неверных попытках). * «Загрузить кассеты с деньгами» (только для Техника).

Связи: * «Снять наличные» <<include>> «Ввести PIN-код» (нельзя снять деньги без ввода пина). * «Запросить баланс» <<include>> «Ввести PIN-код». * «Распечатать чек» <<extend>> «Снять наличные» (пользователь может отказаться от чека).

Как отмечается в статье на habr.com, вариант использования не зависит от реализации и технологии. На диаграмме мы не пишем «Считать магнитную полосу» или «Отправить JSON-запрос», мы пишем бизнес-действие: «Идентифицировать клиента».

Распространенные ошибки

Функциональная декомпозиция: Превращение Use Case диаграммы в блок-схему алгоритма. Не нужно рисовать овалы «Нажать кнопку», «Подключиться к БД», «Показать окно».

Слишком много деталей: Если на диаграмме больше 10-15 овалов, её невозможно читать. Разбивайте систему на пакеты или подсистемы.

Путаница стрелок: Помните, что <<include>> указывает на включаемый (общий) кусок, а <<extend>> указывает на базовый (расширяемый) кусок.

Итоги

* Use Case диаграмма — это инструмент для фиксации функциональных требований и коммуникации с заказчиком. * Основные элементы: Актор (роль), Вариант использования (цель), Граница системы. * Отношения: <<include>> (обязательно часть процесса) и <<extend>> (опциональное дополнение). * Сценарии: Диаграмма — это только карта. Главная работа аналитика — написать текстовые сценарии (основной и альтернативные) для каждого овала. Простота: Избегайте технических деталей реализации на этой диаграмме. Описывайте что делает система, а не как*.