YashinaS
commented
6 years ago Существует два подхода Как составить перечень исполнителей и их задач:
При построении диаграммы прецедентов имена прецедентов можно рассматри вать как задачи системы. Можно сначала составить перечень исполнителей, уточнить его, а затем стро ить диаграмму прецедентов.
Как выделять прецеденты
Шаг 1. Определение рамок системы Шаги 2 и 3. Определение основных исполнителей и задач Шаг 4. Определение прецедентов Как выделить полезные прецеденты
Критерий одобрения руководством. Критерий ЕВР. Критерий размера. Диаграммы прецедентов и их взаимосвязей имеют второстепенное значение при работе над прецедентами. Прецеденты — это текстовые документы. Работать над прецедентами — значит составлять текстовые описания.
Стройте простые диаграммы прецедентов в соответствии со списком исполните¬ лей и их задач.
use-case driven development
Функциональные требования в основном формулируются при описании преце дентов (в модели прецедентов). Остальные требования (если таковые существу ют) являются либо техническими (например, список функций), либо второсте пенными. Прецеденты — важный этап итеративного планирования. На каждой итерации реализуются некоторые сценарии или целые прецеденты. Поэтому описания прецедентов вносят существенный вклад в оценивание результата. Разработка приложения состоит в реализации прецедентов. То есть, группа раз работчиков продумывает способы взаимодействия объектов или архитектуру подсистем для реализации прецедентов. Описание прецедентов зачастую отражается на организации руководства поль зователей. Функциональное и системное тестирование соответствует сценариям прецедентов. Для большинства сценариев важных прецедентов, реализующих типичные за дачи приложения, в интерфейсе пользователя могут создаваться ярлыки или специальные кнопки.
Проиллюстрируйте имена прецедентов, исполнителей и взаимосвязи между ними на диаграмме прецедентов.
Кто запускает и выключает систему? Кто является системным администратором? Кто осуществляет управление пользователями и безопасностью? Относится ли время к числу исполнителей, другими словами, должна ли систе ма выполнять какие-либо действия в ответ на события времени? Существует ли процесс мониторинга, благодаря которому система перезапуска ется в случае сбоя? Кто контролирует деятельность и производительность системы? Как выполняется обновление программного обеспечения? Кто анализирует журналы регистрации? Можно ли обеспечить удаленный до ступ к ним? Могут ли в качестве исполнителей выступать внешние программы или автома тические системы? Кого следует уведомлять при ошибках или сбоях в системе?
Идентифицировать исполнителей:
Основной исполнитель (primary actor) — его задачи выполняются с использо ванием системы. Примером основного исполнителя является кассир. Зачем его идентифицировать? Чтобы определить цели пользователя, на осно ве которых формулируются прецеденты.
Вспомогательный исполнитель (supporting actor) — обслуживает систему (на пример, предоставляет информацию). Примером вспомогательного исполните ля является служба авторизации платежей. Зачем его идентифицировать? Чтобы определить внешние интерфейсы и протоколы.
Закулисный исполнитель (offstage actor) — заинтересован в реализации пре цедента, но не является основным или вспомогательным исполнителем. Примером закулисного исполнителя является налоговая служба. Зачем его идентифицировать? Чтобы удостовериться, что все интересы опреде лены и удовлетворены. Интересы закулисных исполнителей обычно не очевид ны и их легко упустить из виду, если не идентифицировать их в явной форме.