Главная » UML » Процесс, управляемый прецедентами

0

В данной главе вводятся понятия прецедентов, акторов и сценариев. Здесь показывается, как на протяжении всего цикла разработки прецеденты могут использоваться для направления многих видов деятельности, передачи информации между несколькими моделями и обеспечения согласованности этих моделей.

Определения

Значительная часть Rational Unified Process акцентирована на моделировании. Как объяснялось в главе 5, модели помогают понять и очертить как проблему, которую мы пытаемся решить, так и само ее решение. Выбор моделей и способов их выражения существенно влияет на наше восприятие проблемы и то, как мы пытаемся отыскать ее решение.

Для моделирования проблемы, а также определения требований и ограничений разрабатываемой системы можно применять различные подходы. В то же время следует помнить, что решение придется формулировать в рамках этой же разработанной модели. Если модель проблемы далека от модели решения, то потребуются значительные усилия для преобразования представления проблемы из формы, понятной конечным пользователям, в форму, понятную разработчикам и конструкторам. В этом случае весьма вероятно неверное истолкование проблемы, и довольно часто просто затруднительно обосновать решение по отношению к поставленной проблеме. Более того, в процессе, который должен оставаться непротиворечивым, придется работать с несколькими моделями, что совсем не будет способствовать его согласованности.

В данной главе основное внимание уделяется одному из методов понимания и моделирования проблемы. Этот эффективный метод, рекомендуемый Rational Unified Process, называется технологией моделирования прецедентов. Именно прецеденты позволяют так выразить проблему, чтобы она была понятна значительному числу пользователей, разработчиков и заказчиков .

; Понятие прецедента ввел Айвар Джейкобсон (Ivar Jacobson) в работе Object-Oriented Software Engineering: A Use-Case-Driven Approach. Reading, MA: Addison-Wesley, 1992. См. также более новую книгу: Ivar Jacobson, Grady Booch and James Rumbaugh. The Unified Software Development Process. Reading, MA: Addison-Wesley Longman, 1999.

 

Прецедент и актор

Прежде чем приступить к построению модели прецедентов, нужно разобраться с двумя концепциями: концепцией прецедента и концепцией актора. В Rational Unified Process эти термины определяются следующим образом.

•       Прецедент—    это    последовательность    выполняемых    системой    действий,
которые приводят к видимому, значимому для актора результату.

•       Актор—это некто или нечто вне системы, взаимодействующее с этой системой.

Отметим, что на самом деле рассматривается система; акторы (роли, которые люди или другие системы могут брать на себя) — это то, что взаимодействует с системой, а прецеденты — это то, что определяет эти взаимодействия.

Поясним ключевые термины, используемые в данных выше определениях.

•    Действия

Действие — это вычислительная или алгоритмическая процедура, активизируемая по требованию актора или при получении системой временного сообщения. Действие может предполагать передачу сигналов задействованному актору или другим акторам. Действие является элементарным; это означает, что оно либо выполняется полностью, либо не выполняется вовсе.

•    Последовательность действий

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

•    Последовательность действий, выполняемых системой

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

•    Видимый значимый результат

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

•    Отдельный актор

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

 

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

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

Пример прецедентов и акторов

Рассмотрим следующий пример. Клиент банка может использовать банкомат (automated teller machine — ATM) для снятия денег, их перевода или для проверки состояния счета. Все эти возможности (рис. 6.1) можно представить набором прецедентов.

Каждый прецедент представляет нечто, совершаемое системой, имеющее значение для клиента банка (актора) Клиент. Собранные прецеденты охватывают все возможные способы использования системы, а их названия, как правило, отражают значение, которое они имеют для актора.

Поток событий

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

Пример потока событий

Рассмотрим пример потока событий для одного из описанных выше прецедентов. Исходную схему потока событий прецедента Снятие денег можно записать следующим образом.

1.          Прецедент начинается, когда Клиент вставляет карточку в банкомат. Система
считывает и проверяет информацию с карточки.

2.          Система  запрашивает   персональный   идентификационный   номер   (personal
identification number— PIN) Клиента. Клиент вводит свой PIN-код. Система
проверяет правильность введенной информации.

3.           

3.           Система запрашивает, какую операцию желает произвести Клиент. Клиент вы
бирает "Снятие денег".

4.           Система запрашивает о снимаемой сумме. Клиент вводит сумму.

5.           Система запрашивает о типе счета. Клиент выбирает тип счета (чековый счет,
депозит, кредитный счет).

6.           Система связывается с сетью банкомата для подтверждения номера счета, PIN-
кода и наличия на счете требуемой суммы.

7.           Система "спрашивает" Клиента, требуется ли квитанция. Данный этап выпол
няется только при наличии бумаги для печати квитанции.

8.           Система  указывает   Клиенту  вынуть   карточку.   Клиент  вынимает   карточку.
(Данное требование продиктовано соображениями безопасности и должно га
рантировать, что клиенты не будут оставлять свои карточки в аппарате).

9.           Система выдает запрошенную сумму.

10.  Система печатает квитанцию (если ее заказывали). Прецедент завершен.

Если попытаться описать действия системы с помощью полной последовательности действий, то можно быстро обнаружить, что существует множество направлений действий — различных путей через поток событий прецедента. Имеются альтернативные ветви и различные пути (сценарии), которые также требуют рассмотрения, причем значения или эффекты этих сценариев могут быть различными. Для описания всех этих путей в целом и предназначен поток событий.

Выбранный путь зависит от следующего.

•     Ввода со стороны актора

Актор может выбрать (из предложенных альтернатив),  что делать дальше.   ! Например, банковские клиенты могут в любой момент аннулировать операцию или же они могут отказаться от квитанции.

•     Внутреннего состояния системы

В банкомате, например, может не хватить наличных или бумаги для печати квитанций; может "заесть" устройство выдачи денег или принтер.

•     Блокировки по времени или ошибок

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

Сценарии

Выделять каждый возможный альтернативный поток в отдельный прецедент нежелательно; такие потоки лучше объединять с другими родственными потоками событий прецедента. Результатом такого объединения является класс прецедентов. Экземпляром класса прецедентов является отдельный поток событий или отдельный путь через прецедент. Другим названием экземпляра класса прецедентов является сценарий. Обычно достаточно (и не так громоздко) называть класс прецедентов просто прецедентом, а экземпляр прецедента— сценарием.

 

По теме:

  • Комментарии