Что показывает диаграмма Use Case

Что проверяют

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

Как отвечать

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

• актор: роль, а не конкретный человек. Актором бывает внешняя система или таймер, запускающий регламентную задачу;
• вариант использования: цель актора на уровне «оформить заказ», «вернуть товар». Рисуется овалом внутри рамки системы;
• граница системы: прямоугольник, который отделяет то, что вы делаете, от внешнего мира;
• ассоциация: линия между актором и вариантом, показывает, кто в нём участвует;
• include: обязательная часть, вынесенная отдельно, стрелка идёт от базового варианта к включаемому. «Оформить заказ» включает «оплатить»;
• extend: необязательное поведение при условии, стрелка идёт от расширяющего варианта к базовому. «Применить промокод» расширяет «оформить заказ»;
• обобщение: между акторами («администратор» может всё, что может «менеджер») и между вариантами.

Дальше скажите, где диаграмма живёт в процессе. Это обзорная карта функциональности, по ней согласуют объём работ со стейкхолдерами. Сами требования описываются в текстовой спецификации варианта: основной актор, предусловия, основной сценарий, альтернативные ветки, постусловия. Удобный шаблон такой спецификации предложил Алистер Коберн.

Где спотыкаются

Рисуют блок-схему: «ввести логин», «нажать кнопку», «проверить пароль». Это шаги одного сценария, а не цели, и диаграмма превращается в функциональную декомпозицию.

Путают направление стрелок include и extend или ставят extend там, где поведение обязательно.

Считают диаграмму готовыми требованиями. Без спецификаций сценариев она не отвечает ни на один вопрос разработчика или тестировщика о деталях.