Немного о Use сase
Некоторое время назад я выкладывал свой взгляд на «походный набор» аналитика. Пожалуй, имеет смысл расписать поподробнее некоторые пункты приведенного списка. Как раз недавно с коллегами обсуждали ценность Use cases, поэтому с этого пункта и начну.
Некоторое время назад я выкладывал свой взгляд на «походный набор» аналитика. Пожалуй, имеет смысл расписать поподробнее некоторые пункты приведенного списка. Как раз недавно с коллегами обсуждали ценность Use cases, поэтому с этого пункта и начну.
Вариант использования (Use case) — описание действий, которые может осуществлять система, взаимодействуя с внешними актерами (пользователями, процессами, другими системами).
Здесь не хотелось бы подробно останавливаться на том, какое место Use cases занимают в UML, уж слишком обширная это тема. Лучше попробую зайти с другой стороны – описать преимущества, которые порой позволяют существенно снизить риск программных ошибок, начиная от архитектурных, заканчивая мелкими интерфейсными ляпами.
Use case служит своего рода контрактом между пользователем и разработчиком, и, что важно – язык контракта понятен обоим. Пользователь может сказать, устраивает ли его поведение будущей системы, а разработчик – оценить, насколько заданный сценарий реализуем.
Вариант использования одновременно может служить готовым сценарием тестирования, такая разновидность тестирования гарантирует, что функционально система соответствует ожиданиям пользователей.
Разработчик, зная, как именно предполагается использовать систему, имеет возможность сделать интерфейс эргономичнее. Например, вставить ссылки на отчет в компоненты, где чаще всего он нужен; расположить на форме наиболее важные для пользователя поля выше остальных; позаботиться о максимальной скорости загрузки справочника, если известно, что с ним будут активно работать.
Если проектируется новая система или достаточно крупный дополнительный модуль к существующей системе, варианты использования иногда позволяют удержать разработчика от полета среди высоких абстракций там, где он не нужен.
Когда мы формулируем требования к системе, обычно мы отвечаем на вопрос: «что» должна делать система. Дополняя требования вариантами использования мы, по сути, уточняем - «как» именно система должна это делать. Техническое задание, отвечающее на оба этих вопроса, в редком случае может быть сделано в одностороннем порядке заказчиком и гораздо чаще требует совместной работы с исполнителем. Что, в свою очередь, также способствует лучшему пониманию сторонами друг друга.
Комментарии 0