Опубликовано вUML

Овладение отношениями между случаями использования UML: Сила и опасность отношений «include» и «extend»

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

 

 

В этой статье представлен комплексный, практический и поддерживаемый экспертами гидпо пониманию, применению и избеганию распространённых ошибок при использовании отношений «include» и «extend». Мы рассмотрим их истинную семантику, сравним их по сравнению, проанализируем, почему они попадают в ту же ловушку, что и ДФП (функциональная декомпозиция), и предложим современные лучшие практикидля команд 2025–2026 годов — особенно для тех, кто работает в агILE, lean или гибридных средах.

🔹 Основная семантика: что означают отношения «include» и «extend» настоящимзначат

✅ «include»: Обязательное повторное использование — «всегда необходимый» подпоток

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

📌 Ключевые характеристики:

  • Всегда выполняется: Включённый вариант использования выполняется каждый раз, когда вызывается базовый вариант использования.

  • Базовый вариант использования неполон без него: Без включённого поведения базовый вариант использования не может выполнить свою цель.

  • Направление зависимости: Стрелка указывает наот базового → включённого.

  • Самостоятельное значение: Включённый вариант использования обычноне имеет смысла самостоятельно—он имеет смысл только как часть более крупного процесса.

  • Аналогия: Каквызов функцииилиподпрограммав программировании — необходим для основной процедуры.

🧠 Классическая мнемоника:

«Чтобы выполнитьВход, вы должныавторизовать пользователя.”
«Чтобы выполнитьСнять наличные, вы должныПроверить PIN.”

Этообязательные шаги. Вы не можете войти в систему без аутентификации. Вы не можете снять наличные без проверки PIN.

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

  • Когдаобщее, сложное, повторно используемое поведениепоявляется вдва или болеесценариях использования.

  • Примеры:

    • Аутентификация пользователя

    • Ведение журнала аудита

    • Отправка уведомления

    • Проверка формата ввода

✅ Правило thumb: Используйте «include» только тогда, когда повторно используемое поведение являетсясущественным, незначительным, и появляется в≥2–3сценариях использования.

✅ «extend»: опциональная вариация – «условное дополнение»

Определение:
Связь «extend» определяетопциональное, условное или вариативноеповедение, котороеподключается кконкретнойточке расширенияосновного варианта использования.

📌 Ключевые характеристики:

  • Условно выполняется: Выполняется только при определенных обстоятельствах.

  • Основной вариант использования завершен сам по себе: Обычный поток работает без расширения.

  • Направление зависимости: Стрелка указываетот расширяющего → основного (назад).

  • Самостоятельное значение: Вариант использования, который расширяетпочти никогда не имеет смысла самостоятельно—он имеет смысл тольков контексте.

  • Аналогия: Каккрючок, плагин, илисоветы AOP (программирование с ориентацией на аспекты)— добавляет поведение в определенной точке.

🧠 Классическая мнемоника:

«Пока выполняется Бронирование рейса, вы можете хочется Выбрать предпочтительное место.”
«Пока выполняется Оплата кредитной картой, вы можете должны Введите код 3D Secure.”

Это дополнительные улучшения— необязательно для основного потока.

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

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

  • Когда сценарий использования имеет различные поведения на основе условий (например, роли пользователей, состояния системы, предпочтения).

  • Примеры:

    • Применить скидку (расширяет Сделать заказ)

    • Запросить возврат (расширяет Обработать оплату)

    • Сгенерировать PDF-чек (расширяет Завершить транзакцию)

✅ Правило thumb: Используйте «расширить» умеренно — только для смысловые вариации с четким точки расширения.

🔍 Былое сравнение: «включить» против «расширить»

Аспект «включить» «расширить»
Выполнение Всегда Иногда / условно
Базовый UC завершается самостоятельно? ❌ Нет — зависит от включенного ✅ Да — завершается без расширений
Направление зависимости Базовый → Включенный Расширение → Базовый
Направление стрелки Указывает на включённый вариант использования Указывает на базовый вариант использования
Основная цель Повторное использование обязательных общих шагов Обработка необязательных/вариативных потоков
Аналогия Вызов функции / подпрограмма Хук / плагин / совет AOP
Имеет ли самостоятельное значение? Редко Почти никогда
Лучше всего подходит для Повторно используемые, сложные, пересекающиеся аспекты Условное, необязательное или альтернативное поведение

⚠️ «Ловушка декомпозиции»: Почему диаграммы вариантов использования выходят из-под контроля

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

📉 Ловушка функциональной декомпозиции DFD (краткий обзор):

  • Команды продолжают разделять процессы на всё более мелкие и мелкие пузыри.

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

  • Тот первоначальная цель—предоставление ценности пользователю—теряется.

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

🧨 Использование случая «болезнь функциональной декомпозиции»:

  • Каждый мелкий шаг становится собственным случаем использования:

    • Введите имя пользователя

    • Введите пароль

    • Нажмите кнопку входа

    • Проверьте формат

    • Показать сообщение об ошибке

  • «включить» применяется щедро для разбиения каждого действия.

  • Результат: глубокая иерархия случаев использования (A → B → C → D…), без четкой цели актора.

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

❌ Красный флаг: Если ваш диаграмма случаев использования содержит более 15–20 случаев использования, или если большинство базовых случаев использования состоят из 2–4 шагов, вы, скорее всего, попали в ловушку.

🛠️ Почему это происходит: Распространённые ошибки и заблуждения

Ошибки Объяснение Как избежать
Чрезмерное использование «include» Рассматривание каждого подшага как повторно используемого случая использования. Используйте «include» только для существенных, повторно используемых, пересекающих поведений (например, аутентификация, логирование).
Неправильное направление стрелок Рисование стрелок «include» в обратную сторону (базовый ← включённый) или стрелок «extend» вперёд. Помните: include = базовый → включённый; extend = расширяющий → базовый.
Использование «extend» для альтернатив Моделирование альтернативных потоков внутри одного случая использования как «extend», вместо использования текстовых альтернатив. Используйте текстовые альтернативные потоки для большинства вариаций. Оставьте «extend» для настоящие необязательные расширения.
Создание цепочек включения A → B → C → D → E… Избегайте глубоких цепочек. Если вам нужно несколько включений, рассмотрите рефакторинг в единственный повторно используемый сценарий.
Неопределённые точки расширения Добавление отношений «extend» без чётких, именованных точек вставки. Определите явные точки расширения (например, «после подтверждения оплаты») в базовом сценарии.
Загромождение диаграмм Слишком много сценариев и отношений → визуальный шум. Держите диаграммы маленькими, фокусированными и ориентированными на участников. Используйте несколько диаграмм на подсистему.
Путаница заинтересованных сторон Нетехнические заинтересованные стороны находят «включение/расширение» трудным для понимания. Используйте текстовые сценарии или карты пользовательских сценариев для ясности.
Моделирование на уровне проектирования Моделирование внутренней архитектуры (например, «вызов базы данных») вместо целей пользователя. Оставайтесь сосредоточенными на значение актора—не реализация.
Бесконечные споры Команды спорят о том, «включить или расширить?», вместо того чтобы писать сценарии. Используйте практические эвристики и приоритизируйте ясность перед формальностью.

✅ Лучшие практики на 2025–2026 годы: современный, гибкий подход

Ландшафт инженерии требований изменился. Команды, работающие по Agile, lean и продукт-ориентированному подходу все чаще отказываются от тяжеловесных диаграмм UML в пользу легковесных, ориентированных на ценность подходов.

🎯 Основной принцип: Фокусируйтесь на значении актора, а не на внутренней структуре

❗ Задавайте этот вопрос перед добавлением любого «включить» или «расширить»:
«Помогает ли это отношение пользователю понять цель, или это просто разбивка системы?»

✅ Рекомендуемые современные практики:

1. Используйте «включить» умеренно — только для основных повторно используемых действий

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

  • Примеры:

    • Аутентификация пользователя

    • Отправка уведомления по электронной почте

    • Запись события безопасности

    • Применение бизнес-правил

❌ Избегайте: Введите имя пользователя, Нажмите кнопку отправки, Проверка формата электронной почты

2. Предпочтение текстовым альтернативным потокам вместо «extend»

  • Вместо:

    «extend»: Выбор предпочтительного места → Бронирование рейса

  • Используйте:

    Сценарий использования: Бронирование рейса
...
Альтернативный поток:
  1. Пользователь выбирает опцию «Предпочтительное место».
  2. Система отображает схему мест.
  3. Пользователь выбирает место.
  4. Система применяет предпочтение по месту.

✅ Почему? Текстовые потоки являются проще для чтения, более гибкими, и менее подвержены неправильному использованию.

3. Оставьте Диаграммы сценариев использованияМаленькие и направленные

  • Одна диаграмма на актерилиподсистема.

  • Ограничить до5–10 вариантов использованияна диаграмму.

  • Используйтедиаграммы пакетовилидиаграммы контекстачтобы показать высокий уровень структуры.

4. Спросите: «Сообщит ли карта пользовательских историй лучше?»

  • Если вы используете 10+ отношений «включить»/«расширить», рассмотрите возможность замены диаграммы на:

    • Акарта пользовательской истории

    • Атаблица, основанная на сценариях

    • Апростая блок-схемас ключевыми путями

🔄 Современная тенденция: многие команды, использующие гибкие методывовсе избегают диаграмм вариантов использованияили используют ихтолько для высокого уровня обнаружения.

5. Используйте «extend» только для значимых вариантов

  • Выделяйте «extend» длянеобязательные, неосновныефункции, которые:

    • Являютсяредко используемые

    • Являютсязависимыми от контекста

    • Являютсянезависимымиот основной цели

✅ Пример:
Обработка оплаты (основной)
Применение аутентификации 3D Secure (расширение) — только при необходимости банка

❌ Избегайте:
Введите номер карты → Проверка карты → Обработка оплаты (все должны быть шагами в одном сценарии использования)

📊 Обобщение: Золотые правила использования «include» и «extend»

Правило Руководство
1. «include» = Обязательно Используйте только дляосновных, повторно используемыхшагов, которые появляются в ≥2 сценариях использования.
2. «extend» = Необязательно Используйте только дляусловных, вариативных или редкихповедений.
3. Основной сценарий должен быть полным «extend»: базовый сценарий работает самостоятельно. «include»: базовый сценарий неполон без него.
4. Держите всё просто Если сценарий содержит менее 4–6 шагов после «include»/«extend», вы переразбили его.
5. Приоритет — читаемость Текстовые сценарии > сложные диаграммы.
6. Избегайте цепочек Нет A → B → C → D. Переработайте в один повторно используемый сценарий.
7. Знайте свою аудиторию Заинтересованные стороны не интересуются стрелками «include»—они заботятся о ценности.
Задавайте вопрос: «Это цель пользователя или внутренний шаг?» Если это не цель для исполнителя, вероятно, оно не должно входить в сценарий.

🎯 Последняя мысль: Инструменты, а не ловушки

«include» и «extend» — этомощные инструменты—а не жесткие правила. Они были созданы для:

  • Снижения дублирования

  • Управления изменчивостью

  • Улучшения поддерживаемости

Но какфункциональное разложение в DFD, они становятсяопасными оружиемпри чрезмерном использовании. Реальная опасность — не сами отношения, а то, чтопотеря удержания цели пользователя.

🔥 Помните:
Сценарий использования не является техническим процессом.
Это история о том, что пользователь хочет достичь—и как система помогает.

Если сомневаетесь, спросите себя:

«Поймет ли пользователь это, не зная UML?»
Если нет, упростите.
Если да, вы на правильном пути.

📚 Дополнительное чтение и ссылки

  • Спецификация UML (OMG): www.omg.org/spec/UML

  • Мартин Фаулер – Моделирование сценариев использования: Паттерны анализа & UML сжато

  • Ивар Якобсон – Преимущества объектов: Основополагающая работа по сценариям использования

  • Агилитное моделирование (AM) Скотт В. Амблер

  • Карта пользовательских историй Джифф Паттон – Современная альтернатива сложным диаграммам

✅ Правило одной фразы

Используйте «include» для обязательного повторного использования, «extend» — для необязательных вариаций, но только тогда, когда это действительно добавляет ценность. В противном случае оставьте всё просто.

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

📌 Примечание автора (2025–2026):
По мере того как команды переходят кориентированности на продукт, ориентированности на ценность, исовместнойразработке роль традиционных диаграмм UML меняется. «include» и «extend» остаются полезными — но только тогда, когда используются сдержанно, ясно и с цельютолько тогда, когда используются сдержанно, ясно и с целью. Пусть они служат пользователю, а не диаграмме.