Кейс-стади: Диаграмма вариантов использования для платформы доставки еды

Моделирование реальных требований с помощью UML — Практическое руководство

---

1. Введение

В современной разработке программного обеспечениядиаграммы вариантов использованияявляются фундаментальным инструментом для фиксации функциональных требований с точки зрения пользователя. В этом кейс-стади представлен подробный анализреалистичной диаграммы вариантов использованиядлядоставки еды, используясинтаксис PlantUMLв качестве языка моделирования. Цель состоит в том, чтобы продемонстрировать не толькочтоэлементы используются на диаграмме, но ипочемуони выбираются — подчеркиваяпрактические решения при моделировании, конвенции, ираспространённые ошибки.

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

---

2. Обзор системы

Платформадоставки еды — это цифровой маркетплейс, соединяющий:

• Покупатели (физические лица, заказывающие еду),

• Рестораны (поставщики еды),

• Водители (персонал доставки),

• Внешние платежные шлюзы (внешние системы, обрабатывающие транзакции).

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

Код PlantUML:

@startuml
skinparam monochrome true
skinparam shadowing false

направление слева направо

‘ Все актеры определены вне прямоугольника
актер Покупатель
актер «Зарегистрированный покупатель» как RegCustomer
актер «Персонал ресторана» как Restaurant
актер Водитель
актер «Платежный процессор» как PaymentGW

прямоугольник «Платформа доставки еды» {

(Просмотр ресторанов)
(Оформить заказ)
(Отслеживание заказа)
(Управление меню)
(Принять / Подготовить заказ)
(Доставить заказ)
(Обработать платеж)
(Выдать возврат)
(Применить промокод)
(Использовать кошелек)
(Оплата картой)
(Оплата цифровым кошельком)

‘ Ассоциации – стрелки пересекают границу
Клиент –> (Просмотр ресторанов)
Зарегистрированный клиент –> (Сделать заказ)
Зарегистрированный клиент –> (Отслеживание заказа)

Ресторан –> (Управление меню)
Ресторан –> (Принять / Подготовить заказ)

Водитель –> (Доставить заказ)

Платежный шлюз –> (Обработка оплаты)
Платежный шлюз –> (Выдача возврата)

‘ включает
(Сделать заказ) ..> (Обработка оплаты) : <<включает>>

‘ расширяет
(Сделать заказ) <.. (Применить промокод) : <<расширяет>>
(Обработка оплаты) <.. (Использовать кошелек) : <<расширяет>>

‘ обобщение
(Обработка оплаты) <|– (Оплата картой)
(Обработка оплаты) <|– (Оплата цифровым кошельком)
}

‘ Обобщение актера (также вне)
Клиент <|– Зарегистрированный клиент

примечание справа от Платежного шлюза
Внешний платежный шлюз
(Stripe, PayPal, Adyen, …)
конец примечания

примечание снизу (Применить промокод)
Необязательно – только при вводе действительного кода
конечная заметка

@enduml

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

---

3. Элементы диаграммы: подробный разбор с практическим смыслом

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

#	Элемент	Обозначение	Значение и цель	Решение при моделировании / Комментарий
1	Граница системы	прямоугольник "Платформа доставки еды"	Определяет область системы, которая моделируется. Все случаи использования внутри являются частью этой системы.	Название краткое, но информативное. В корпоративных контекстах могут использоваться более длинные названия (например, «Система управления заказами клиентов»).
2	Основной человек-актер	актер Клиент, актер Водитель	Представляет внешние роликоторые инициируют или участвуют в использовании случаев.	Имена простые и интуитивно понятные. Избегает ненужных стереотипов, таких как<<человек>>если только это не требуется для крупных моделей.
3	Актер с псевдонимом	актер "Персонал ресторана" как Ресторан	Позволяет сократить длинное, описательное имя актера для ясности в соединениях.	Очень эффективно, когда имена актеров содержат пробелы или являются избыточными. Уменьшает нагромождение и улучшает читаемость.
4	Актер внешней системы	актер "Процессор платежей" как PaymentGW	Моделируетвнешние системыс которыми взаимодействует платформа.	Нет стереотипа«система»используется — допустимо в легких диаграммах. Однако добавление«система»может прояснить намерение в сложных системах.
5	Обобщение актера	`Клиент <	— ЗарегистрированныйКлиент`	Указывает, чтозарегистрированный клиентявляется специализированной версиейгостевого клиента.
6	Обычная ассоциация	Клиент --> (Просмотр ресторанов)	Показывает, что участникинициируетилиучаствует виспользовании случая.	Сплошная линия = коммуникация. Направление подразумевается от участника к случаю использования (стрелка не нужна).
7	Связь «include»	(Сделать заказ) ..> (Обработать оплату) : <<include>>	Обработать оплатуявляетсявсегда требуетсяпри оформлении заказа.	Стрелка указываетот включающего → включённого. Это критически важно:Сделать заказ включает Обработать оплатув качестве обязательного шага.
8	Связь «extend»	(Сделать заказ) <.. (Применить промо-код) : <<extend>>	Применение промо-кода являетсянеобязательными происходит только при определённых условиях.	Стрелка указываетот расширения → базового. Основной случай использования (Сделать заказ) может быть расширен условно.
9	Обобщение случая использования	`(Обработка оплаты) <	— (Оплата картой)<br>(Обработка оплаты) <	— (Оплата цифровым кошельком)`
10	Примечание	примечание справа от PaymentGW примечание снизу (Применить промокод)	Предоставляет контекстное объяснение о реализации или бизнес-правилах.	Примечания недоиспользуются, но чрезвычайно ценные. Они предотвращают неправильное понимание (например, уточняя, что PaymentGW является внешним).
11	Актеры за пределами границы	Все актер объявления предшествуют прямоугольнику	Подчеркивает, что никакой актер не является частью системы — четкое разделение ответственности.	Один из двух стандартных макетов. Предпочтительный при большом количестве актеров или внешних сущностей.
12	Направление диаграммы	направление слева направо	Улучшает компоновку, когда несколько актеров находятся слева.	Улучшает читаемость. Особенно эффективно при 4–8 актерах. Альтернатива: вертикальная компоновка для меньшего количества актеров.

---

4. Ключевые решения при моделировании и обоснования

✅ Почему актеры находятся за пределами границы системы

• Наилучшая практика: Актеры представляют роливнесистемы.

• Почему это важно: Предотвращает путаницу между компонентами системы и внешними сущностями.

• Пример: Водительне является модулем платформы — это роль сторонней организации, взаимодействующая с ней.

📌 Совет эксперта: Если бы все актеры находились внутри границы, это означало бы, что система включает их — что вводит в заблуждение.

---

✅ Почему использоватьКлиент <|-- ЗарегистрированныйКлиентвместо дублирования связей

• Без обобщения вам пришлось бы рисовать:

  Клиент --> (Просмотр ресторанов)
  ЗарегистрированныйКлиент --> (Просмотр ресторанов)
  ЗарегистрированныйКлиент --> (Сделать заказ)
  

• С обобщением вам нужно только:

  Клиент <|-- ЗарегистрированныйКлиент
  Клиент --> (Просмотр ресторанов)
  ЗарегистрированныйКлиент --> (Сделать заказ)
  

• Результат: Чистая, более поддерживаемая диаграмма.

📌 Наилучшая практика: Используйте обобщение актеров каждый раз, когда специализированный актер наследует все поведения более общего.

---

✅ Почему <<включить>> и <<расширить>> используются правильно

Связь	Цель	Направление	Пример
<<включить>>	Обязательный подпоток	От включая → включенный	Сделать заказ должен включить Обработать оплату
<<расширить>>	Опциональное расширение	От расширение → база	Применить промокод расширяет Оформить заказ только если код действителен

❗ Распространенная ошибка: Переворот направления стрелки. Всегда помните:

• включает: База ..> Включено

• расширять: Расширение <.. База

---

✅ Почему Обработка оплаты имеет обобщения

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

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

• Обобщение позволяет общее поведение и будущая расширяемость.

📌 Сценарий использования: добавление нового способа оплаты (например, Apple Pay) будет просто еще одной обобщением Обработка оплаты.

---

5. Реальные толкования и ответы на вопросы

Этот диаграмма — не просто визуальная поддержка — она отвечает на ключевые бизнес- и технические вопросы:

Вопрос	Ответ из диаграммы
Кто основные пользователи?	Покупатели, зарегистрированные клиенты, персонал ресторанов, водители, платежный шлюз
Могут ли незарегистрированные пользователи делать заказы?	❌ Нет — только Зарегистрированный клиент может Сделать заказ. Покупатель может только Просмотр ресторанов.
Оплата всегда обязательна?	✅ Да — Сделать заказ включает Обработка оплаты. Обязательно.
Могут ли клиенты применять промокоды?	✅ Да — но толькопо желаниючерез<<расширить>>. Только если введен действительный код.
Какие методы оплаты поддерживаются?	Карта и цифровой кошелек (через обобщение). Внешняя система обрабатывает фактическую обработку.
Кто обрабатывает оплату?	ВнешнийPaymentGW — не является частью платформы.
Могут ли рестораны управлять своими меню?	✅ Да —Ресторанактер взаимодействует сУправление менюиПринять / Подготовить заказ.

✅ Бизнес-ценность: Диаграмма ясно передаетчто делает система, кто ее использует, икакие поведения являются обязательными или по желанию.

---

6. Показаны общие рекомендации по моделированию

Диаграмма иллюстрирует нескольконаилучшие практикив моделировании случаев использования UML:

Рекомендация	Как применяется
Используйте имена случаев использования, ориентированные на цели	Сделать заказ, Отслеживать заказ, Применить промокод— все начинаются с глагола и описывают цель пользователя.
Сохраняйте читаемость диаграммы	Только10 случаев использованияпоказаны — идеально для большинства бизнес-областей (рекомендуется 5–12).
Внешние системы как участники	PaymentGWмоделируется как участник, а не как случай использования. Правильно разделяет ответственности.
Используйте примечания для устранения неясности	Примечания объясняют, чтоPaymentGWявляется внешним и что промокод необязателен — критически важно для предотвращения неправильного понимания.
Используйте обобщение участников для уменьшения перегруженности	`Пользователь <
Используйтевключитьирасширить правильно	Четкое различие между обязательным и необязательным поведением.

📌 Предупреждение: Многие диаграммы неправильно используют <<extend>> в значении «необязательный» без понимания условного характера расширений. Эта диаграмма избегает этой ошибки.

---

7. Возможные улучшения и критика

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

🔧 1. Добавьте стереотипы для ясности

актер "Платежный процессор" как PaymentGW <<system>>

• Почему: Ясно показывает, что это внешняя система, а не человеческая роль.

• Выгода: Уменьшает неоднозначность, особенно в крупных моделях.

🔧 2. Уточните Применить промо-код условие расширения

Сейчас:

примечание снизу (Применить промо-код)
  Необязательно – только при вводе действительного кода
конец примечания

• Лучше: Используйте обозначение условия или охрана в <<расширить>> стрелка:

(Сделать заказ) <.. (Применить промокод) : <<расширить>> [действительный промокод]

• Почему: Более точный, чем заметка — напрямую связывает расширение с условием.

🔧 3. Рассмотрите возможность добавления Просмотр истории заказов Случай использования

• В настоящее время отсутствует, но, вероятно, важна как для клиентов, так и для ресторанов.

• Может быть добавлено как RegCustomer случай использования.

🔧 4. Группировка связанных случаев использования (по желанию)

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

пакет "Управление заказами" {
    (Сделать заказ)
    (Отслеживание заказа)
    (Применить промокод)
}
пакет "Оплата" {
    (Обработка оплаты)
    (Использование кошелька)
    (Оплата картой)
    (Оплата цифровым кошельком)
}

• Выгода: Улучшает масштабируемость и читаемость.

---

8. Что дальше?

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

🔄 Вариант 1: Вид, ориентированный на ресторан

Моделирование той же области с точки зрения ресторана:

• Сфокусироваться на Управление меню, Принять / Подготовить заказ, Просмотр заказов, Обновить статус.

• Показать Ресторан в качестве основного участника.

• Включить Покупатель в качестве второстепенного участника (например, Покупатель отправляет заказ → Ресторан получает его).

✅ Выгода: Показывает различные цели системы и роли участников.

🔄 Вариант 2: Добавить больше точек расширения

Улучшить Сделать заказ с:

• Применить купон (если промокод недействителен → <<расширить>> с сообщением об ошибке)

• Запросить специальные инструкции (необязательно)

• Запланировать заказ (на будущую доставку)

🔄 Вариант 3: Сравнить включить против расширить с примерами

Сценарий использования	<<включить>>	<<расширить>>
Сделать заказ → Обработать оплату	✅ Обязательно	❌ Не является необязательным
Сделать заказ → Применить промокод	❌ Не является обязательным	✅ Условно
Войти → Проверка личности	✅ Всегда необходимо	❌ Не применимо
Оформить заказ → Применить скидку	✅ Всегда	✅ Только если существует скидка

📌 Правило thumb:

• Использовать <<включить>> когда поведение должно произойти.

• Использовать <<расширить>> когда поведение может произойти при определенных условиях.

🔄 Вариант 4: Преобразовать в диаграммы последовательностей или диаграммы деятельности

Для более глубокого анализа:

• Диаграмма последовательностей: Показать поток Сделать заказ → Обработать оплату → Доставить заказ с сообщениями между участниками и системой.

• Диаграмма деятельности: Моделировать точки принятия решений в Обработать оплату (например, карта отклонена → повторить или перейти к кошельку).

---

9. Заключение

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

• уточняет границы системы,

• фиксирует бизнес-правила,

• направляет разработку,

• предотвращает недопонимание.

Диаграмма Платформа доставки еды является сильным примером:сильного примера такого как:

• правильное использование нотации UML,

• обоснованные решения при моделировании,

• четкое разделение обязанностей,

• эффективное использование примечаний и обобщений.

Следуя принципам, показанным здесь — называние с ориентацией на цели, правильное использование include/расширять, обобщение актеров, и стратегическое использование заметок — вы можете создавать диаграммы вариантов использования, которые одновременно точныеи осуществимые.

---

✅ Основные выводы

Принцип	Применяется здесь?	Почему это важно
Используйте имена вариантов использования, ориентированные на цели	✅ Да	Улучшает ясность и фокус на пользователе
Сохраняйте размер диаграммы в разумных пределах	✅ Да (10 вариантов использования)	Предотвращает когнитивную перегрузку
Внешние системы как актеры	✅ Да	Правильное разделение обязанностей
Используйте заметки для контекста	✅ Да	Предотвращает неправильное толкование
Используйте обобщение для уменьшения избыточности	✅ Да	Делает диаграмму масштабируемой и поддерживаемой
Правильно<<включить>> и <<расширить>> направление	✅ Да	Обеспечивает точное моделирование поведения

---