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

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

 

Рисунок 3.21. Некорректная диаграмма прецедентов

Как показывает практика, разработчики диаграмм зачастую пытаются подчеркнуть значимость создаваемой информационной системы, перечислив все разновидности ее пользователей. В приведенном примере актеры сформированы на основании их социального и организационно-правового статуса, что не является верным решением. Система “слепа” к явлениям реального мира, непосредственно не затрагивающих вопросы ее функционирования. Иными словами, системе безразлично обращается к ней с запросом глава какого-либо департамента администрации, директор государственного учреждения или студент ВУЗа. Эти пользователи “безлики” для нее и система все равно предоставит им один и тот же сервис, зафиксированный в модели при помощи прецедента “Предоставить информацию из реестра”. Корректная диаграмма для системы, описанной выше, приведена на рис. 3.22.

Рисунок 3.22. Корректная диаграмма прецедентов

Приведенные рассуждения не означают, что в модели не может быть актеров, приведенных на рис. 3.21. Однако необходим критерий, по которому их следовало бы отличать друг от друга. Таким критерием является наличие сервисов, которые система предоставляет одним пользователям и не предоставляет другим. Например, коммерческие структуры могли бы иметь доступ к информации только о базах данных, имеющих коммерческую направленность, а органы власти к описанию баз данных, созданных исключительно за счет средств бюджета территориального образования. В этом случае, введение в модель двух актеров и их размещение на диаграмме - оправдано, однако каждому из них будет адресован свой прецедент, как это показано на рис. 3.23.

           Рисунок 3.23. Различные актеры – различные сервисы

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

Довольно часто можно встретить диаграммы, прецеденты которых слишком “размыты”. В качестве примера рассмотрим сервис, предоставляемый сайтом электронной торговли и зафиксированный посредством прецедента “Разместить заказ” (рис. 3.24).

           Рисунок 3.24. Слишком размытый прецедент.

В приведенном примере разработчик пытается применить алгоритмический подход, указывая порядок размещения заказа в системе. Предполагается, что сначала актер “Заказчик” размещает заказ на сайте системы электронной торговли, после чего система информирует  диспетчера и начинает процесс его обработки. При этом, видимо, в информационной системе фиксируется изменения его статуса (заказ принят в обработку, заказ обработан, заказ отгружен, заказ оплачен и т.д.). Но диаграммы прецедентов не предназначены для указания последовательности выполнения действий. Для этого существуют диаграммы деятельности, состояний и последовательности. Диаграммы прецедентов раскрывают систему с внешней стороны, фиксируя сервисы, адресованные каждому из окружающих систему актеров.

В нашем примере актер “Диспетчер” не размещает заказа в системе - он его обрабатывает, а система предоставляет ему возможность фиксировать информацию о ходе его обработки. Поэтому налицо попытка объединить в рамках одного весьма размытого прецедента “Разместить заказ” два самостоятельных сервиса, адресованных разным актерам. Следовательно, корректная диаграмма могла бы иметь вид, приведенный на рис. 3.25.

           Рисунок 3.25. Корректно сформулированные прецеденты.

Сформулируем рекомендации относительно пропорций актеров и прецедентов на диаграмме прецедентов.

· Количество актеров на одной диаграмме редко превышает количество прецедентов. Как правило, такая ситуация возникает при использовании отношения обобщения между актерами. Однако, для демонстрации отношения “предок-потомок” между актерами лучше приводить отдельные диаграммы прецедентов или классов.

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

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

Прецеденты описывают, что должна будет делать создаваемая система с точки зрения актера, т.е. точки зрения внешней по отношению к объекту моделирования. Строение прецедента определяется в документе, называемом "потоком событий" (flow of events) и являющемся частью его спецификации. Целью создания документа “поток событий” является документирование процесса обработки данных, реализуемого в рамках прецедента. Этот документ подробно описывает действия пользователей и оклики системы.

Обычно поток событий содержит:

· краткое описание;

· предусловия (pre-conditions);

· описание того, каким образом запускается прецедент;

· основной поток событий (типичный ход событий);

· альтернативные потоки событий;

· потоки ошибок;

· описание того, каким образом завершается прецедент;

· постусловия (post-conditions).

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

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

Ниже приведен поток событий прецедента "Снять наличные", в основу которого положен пример, опубликованный в [8]. Рассматривается процесс взаимодействия пользователя и банкомата.

Основной поток событий

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

2. Банкомат выдает приветствие и предлагает пользователю ввести свой персональный идентификационный номер (код пластиковой карточки).

3. Клиент вводит номер.

4. Банкомат проверяет введенный код. Если код не подтверждается, выполняется альтернативный поток событий А1.

5. Банкомат выводит список доступных действий (снять наличные, получить распечатку, проверить остаток и т.д.)

6. Пользователь выбирает пункт "Снять наличные".

7. Банкомат запрашивает, сколько денег нужно снять.

8. Пользователь вводит требуемую сумму.

9. Банкомат определяет, достаточно ли на счету денег. Если денег недостаточно, выполняется альтернативный поток А2. Если во время подтверждения суммы возникают ошибки, выполняется поток ошибок Е1.

10. Банкомат вычитает требуемую сумму из суммы на счету пользователя.

11. Банкомат выдает пользователю требуемую сумму наличными.

12. Банкомат возвращает пользователю его карточку.

13. Прецедент завершается.

Альтернативный поток А1: ввод неправильного кода.

1. Банкомат информирует пользователя, что код введен неправильно.

2. Банкомат возвращает пользователю его карточку.

3. Прецедент завершается.

Альтернативный поток А2: недостаточно денег на счету.

1. Банкомат информирует пользователя, что денег на его счету недостаточно.

2. Банкомат возвращает пользователю его карточку.

3. Прецедент завершается.

Поток ошибок Е1: ошибка при подтверждении суммы.

1. Банкомат сообщает пользователю, что при подтверждении запрашиваемой суммы произошла ошибка.

2. Банкомат заносит сведения об ошибке в журнал ошибок. Каждая запись содержит дату и время ошибки, имя клиента, номер его счета и код ошибки.

3. Банкомат возвращает пользователю его карточку.

4. Прецедент завершается.

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