UML Use Case диаграмма на собеседовании системного аналитика

Зачем спрашивают на собесе SA

Use Case — базовая нотация для описания функциональных требований. На собесе SA обязательно: «нарисуй use case для онлайн-банкинга», «в чём разница между include и extend», «когда generalization, а когда extend».

Главная боль без понимания — SA рисует диаграмму с 30 use case'ами и 10 актёрами, в которой не видно главных сценариев — не помогает разработке.

Элементы Use Case диаграммы

Системные границы (system boundary) — прямоугольник, обозначающий рамки разрабатываемой системы. Снаружи — актёры, внутри — use cases.

Use case (прецедент) — овал. Сценарий взаимодействия, дающий значимый результат для актёра.

Актёр (actor) — человечек, обозначает роль (пользователь, внешнюю систему, расписание).

Связи — линии и стрелки между актёрами и use cases.

      [Actor]                       [System]
         |                ┌───────────────────────────┐
         |───────────────▶│         (Login)           │
       Customer           │            ▲              │
                          │            | <<extend>>   │
                          │      (Recover password)   │
                          │                           │
                          │         (Buy product)     │
                          │            ▲              │
                          │            | <<include>>  │
                          │     (Verify payment)──────┼─▶ [Payment system]
                          └───────────────────────────┘

Актёры

Актёр — роль, не конкретный человек. Один человек может играть несколько ролей.

Типы актёров:

• Primary — инициирует use case, получает ценность (Customer, Manager).
• Secondary — система помогает основному актёру (банк, провайдер email, расписание).
• Внешние системы — отрисовываются как актёры, обычно на правой стороне диаграммы.
• Расписание / триггер — для ночных задач, регулярных отчётов («Cron», «Schedule»).

Признаки правильного актёра:

• Это роль, а не должность («Покупатель», не «Иван Петров»).
• Внешний по отношению к системе.
• Имеет понятную цель — иначе это не actor.

Use cases

Use case описывает значимый результат для актёра, не действие.

Хорошо:

• «Оформить заказ»
• «Получить выписку»
• «Восстановить пароль»

Плохо:

• «Нажать кнопку OK» (это шаг, не сценарий)
• «Войти в систему и просмотреть профиль» (два use case'а)
• «CRUD пользователя» (это четыре сценария)

Уровень use case:

• User goal — основной уровень собеса, цель пользователя в одном «сеансе» взаимодействия.
• Subfunction — подфункция (валидация, отправка email).
• Summary — высокоуровневый business process.

На собесе обычно требуется User-goal level.

Связи: include, extend, generalization

<<include>> — обязательное включение. Use case A включает B. B всегда выполняется, когда выполняется A.

(Buy product) ──<<include>>──▶ (Verify payment)

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

<<extend>> — необязательное расширение. Use case B расширяет A в определённых условиях.

(Login) ◀──<<extend>>── (Recover password)

Стрелка от расширяющего к базовому. У расширения есть extension points — точки в базовом use case, где может произойти расширение.

Generalization (наследование). Один use case — специализация другого.

       (Pay)
        ▲ ▲
        │ │
(Pay by card)  (Pay by cash)

Применяется реже — обычно use cases слишком разные, чтобы наследоваться.

Между актёрами тоже бывает generalization. «Регистрированный пользователь» — наследник «Гостя».

[Гость] ◀── [Зарегистрированный пользователь]

Уровень детализации

На собес. Покажи 5-8 ключевых use cases на одной диаграмме. Не все 30 — это нечитаемо.

Группировка. Если use cases много — разбивай на пакеты (package). По модулям системы или по фазам (регистрация, основная работа, администрирование).

Что не показывают на use case диаграмме:

• Последовательность действий внутри use case (это sequence/activity).
• Структуру данных (это class / ER).
• Бизнес-процессы пересекающие систему (BPMN).

Use case диаграмма — «что делает система с точки зрения пользователя», не «как».

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

На собесе спросят описать use case текстом. Стандартная структура (Cockburn):

ID: UC-12
Название: Оформить заказ
Актёр: Покупатель
Предусловия: Покупатель авторизован, корзина не пуста
Постусловия (успех): Заказ создан со статусом «Ожидает оплаты»

Основной сценарий:
1. Покупатель открывает корзину
2. Система отображает товары и итоговую сумму
3. Покупатель нажимает «Оформить»
4. Система запрашивает адрес доставки
5. Покупатель выбирает адрес
6. Система запрашивает способ оплаты
7. Покупатель выбирает способ
8. Система создаёт заказ и показывает подтверждение

Альтернативные сценарии:
3a. Корзина пуста: система показывает сообщение, переход к каталогу
5a. Адресов нет: переход к UC-15 «Добавить адрес»
8a. Ошибка БД: система показывает «Попробуйте позже», заказ не создаётся

Исключения:
*. Сессия истекла: переход к UC-01 «Войти в систему»

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

Частые ошибки

Use case = действие. «Нажать кнопку» — не use case. Use case — цель пользователя.

Слишком детально. Не нужно отрисовывать все 50 экранов как use cases. Для деталей — sequence или текстовое описание.

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

Стрелка extend в неправильную сторону. extend идёт от расширяющего use case к расширяемому. include — наоборот.

Use case без актёра. Каждый use case инициирован каким-то актёром. «Cron генерирует отчёт» — Schedule тоже актёр.

Слишком много актёров. Если 15 актёров — скорее всего, дублируются роли. Подумай, можно ли объединить.

Generalization где не нужно. Часто extend / include проще и понятнее наследования.

Смешивать с BPMN. Use case — снапшот функций, BPMN — последовательность действий с участием системы. Это разные диаграммы.

Связанные темы

• UML и BPMN на собесе SA
• UML sequence на собесе SA
• User stories и acceptance criteria
• ERD и связи на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Сколько use cases должно быть на одной диаграмме?

На собесе — 5-10. Если больше — группировать в пакеты, делать несколько диаграмм по модулям.

Можно ли use case включать сам себя?

Технически — нет, это создаёт цикл. На практике повторяющееся действие моделируется на sequence diagram, а не на use case.

Чем use case отличается от user story?

Use case — формальное описание сценария взаимодействия (UML-нотация). User story — короткая формулировка ценности с т.з. пользователя («Как X, я хочу Y, чтобы Z»). User story — продуктовый артефакт, use case — аналитический.

Нужно ли указывать UI-детали в use case?

Нет. Use case описывает поведение системы, не UI. UI — отдельная задача, обычно через wireframes / прототипы.

Где границы между use case и sequence diagram?

Use case — что система делает. Sequence — как именно (объекты, сообщения). Текстовое описание use case детализирует «что» через шаги, sequence — формализует «как» через объектные взаимодействия.

Это официальная информация?

Нет. Статья основана на спецификации UML 2.5 (OMG) и работах Cockburn «Writing Effective Use Cases».

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.