Диаграммы использования

Цели и задачи

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

На общей диаграмме использования покажите на верхнем уровне функциональность рассматриваемой системы. Эта диаграмма предполагает, что на ней не нужно (и даже может быть вредно) раскрывать детально возможности системы. Например, вариант использования “Оплатить покупку” не должен распадаться на “Открыть страницу оплаты”, “Ввести платёжные данные” и “Подтвердить покупку”. При этом на диаграмме не должно быть варианта использования “Управлять покупками”, это некорректно, поскольку не является конкретной функцией системы (этот вариант использования распадётся на “Оплатить покупку”, “Совершить возврат” и пр.). На этой диаграмме должны быть отражены все действующие лица и все внешние системы (которые находятся и во внутреннем контуре, и во внешнем).

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

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

Если вдруг появится желание добавить новые варианты использования, никто не будет против. Только не забудьте указать обновлённые требования в отчёте.

Оценивание

В отчёте обязательно укажите ФИО, группу и номер лабораторной работы.

Максимум за эту лабораторную работу — 7 баллов. За что снимаются баллы:

Отсутствие диаграмм;
Несоблюдение нотации и методических рекомендаций;
Неудачная вёрстка диаграммы, затрудняющая чтение;
Некорректное оформление отчёта (например, картинки без подписи, водяной знак, закрывающий часть диаграммы или всю диаграмму);
Использование неподходящего ПО;
Сдача после дедлайна.

Методические рекомендации

Разделяйте между собой функциональные и нефункциональные требования. Если что-то не касается конкретной функции системы для конкретного действующего лица, это с вероятностью 95% нефункциональное требование (оставшиеся 5% включают в себя неправильную формулировку требования).
Варианты использования для удобства анализа (и рисования) показывают внутри границы системы. При этом действующие лица расставляются так, что с одной стороны от границы (обычно слева) находятся непосредственно действующие лица, а с другой стороны (справа) — внешние системы.
Не забудьте про правила именования вариантов использования: это глагол с кратким пояснением, в идеале из одного слова, то есть не нужно копипастить предложения из функциональных требований как есть, иначе теряется наглядность. Если есть ощущение, что сократить текст не получится, может, в одном требовании скрывается несколько вариантов использования сразу, в таком случае на диаграмме их нужно показать отдельно.

Два примера

Так точно не надо, это может привести к снижению баллов

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

При необходимости используйте обобщение, оно помогает уменьшить количество ассоциаций (но без фанатизма). Частный случай 1: в системе одна роль является суммой нескольких других ролей, например, если есть два типа менеджеров и администратор, который умеет всё. В таком случае администратор может просто обобщить менеджеров, и в таком случае можно не проводить лишние ассоциации с участием администратора.

Два примера

Вот так не надо

Вот так надо

Частный случай 2: в системе часть ролей пересекается между собой по возможностям, например, когда два типа менеджеров могут смотреть список клиентов и ещё что-то своё сверху. В таком случае (особенно если есть несколько общий вариантов использования) полезно выделить абстрактного менеджера, который умеет только смотреть список клиентов, и остальных менеджеров обобщить от него.

Два примера

Можно оставить и так

Можно переделать так, особенно если общих вариантов использования несколько

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

Два примера

Если варианты использования связаны с одним действующим лицом, то можно оставить так

Если логически есть возможность сгенерировать отчёт, но отчёт генерируется только за конкретный период, то лучше сделать вот так

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

Три примера

Вот так точно не надо

Уже лучше, но всё ещё недостаточно

Превосходно

Самый корректный вариант

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