Use cases и UML

Use cases (Ivar Jacobson, 1986) представляют собой метод описания взаимодействий актёров с системой для достижения определённых целей. Их можно зафиксировать на трёх уровнях детальности: краткий (один абзац), касуал (ключевые потоки), и полностью детализированный (включая предусловия, основной поток, альтернативные потоки, постусловия, исключения). Use cases особенно полезны там, где у системы множество различных сценариев, таких как административные функции, функции конечного пользователя, и интеграции с API. В то же время, пользовательские истории (user stories) лучше подходят для описания чисто пользовательских функций.

Как это работает

Каждый fully-dressed use case состоит из семи-восьми разделов: имя и уникальный идентификатор, актёры, предусловия, постусловия, основной успешный поток (шаги, нумерованные), альтернативные потоки (вариации успеха), исключительные потоки (обработка отказов), и специальные требования (производительность, безопасность). Каждый шаг в use case описывается в форме глагола и существительного ('Пользователь выбирает способ оплаты'). Важно отметить, что книга Алистера Кокбёрна 'Writing Effective Use Cases' является классическим руководством по написанию эффективных use cases.

Когда применять

Use cases особенно полезны в ситуациях, где у системы множество актёров с разными целями (администратор, техническая поддержка, клиент, API-клиент). Они также являются оптимальным выбором, когда failure modes критически важны (например, в медицине, финансах, безопасности). В таких случаях use cases помогают обеспечить полную документацию и понимание всех возможных сценариев. В то же время, пользовательские истории (user stories) лучше подходят для тесно связанных команд, где подробности могут быть легко обсуждены и заполнены.

Типичные ошибки

(1) Перегрузка инженерии — написание fully-dressed use cases для простых и тривиальных функций может привести к ненужному усложнению. Это не только тратит время разработчиков, но и создаёт документацию, которую никто не читает. Важно сопоставлять глубину детализации с реальной сложностью проблемы. (2) Перегрузка use cases — создание единого 'mega use case', который пытается охватить множество целей, может привести к непонятной и запутанной структуре. Вместо этого, каждый use case должен быть сфокусирован на одной конкретной цели. (3) Use cases без альтернативных потоков — описывание только 'happy path' (успешного пути) может привести к недостаточному покрытию всех возможных сценариев. Это снижает ценность use cases, так как они теряют возможность описывать и обрабатывать исключения и альтернативные пути.

Связанные понятия

• Actors & Goals
• Main & Alternate Flows
• UML Diagrams