Выбор прецедентов

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

· Какую задачу выполняет каждый из актеров?

· Будет ли кто-то из актеров создавать, сохранять, изменять, удалять информацию из системы?

· Где будет создаваться, сохраняться, изменяться, удаляться информация?

· Потребуется ли актеру уведомлять систему о внешних изменениях?

· Необходимо ли оповещать актеров о наступлении каких-либо событий в системе?

· Могут ли все функциональные требования быть выполнены с помощью прецедентов?

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

Еще одной проблемой является объединение различной функциональности, когда она кажется связанной. Например, в той же системе обучения актер «Секретарь» может добавлять курсы, удалять их и изменять. Опять вопрос: это три прецедента или один? В данном случае есть смысл объединить эти действия в один прецедент, и назвать его, к примеру, «Поддержка учебного плана». Это можно объяснить тем, что описанная функциональность завязана на одного актера и работает он с одной сущностью в системе (учебный план).

Одной из наиболее распространенных ошибок при создании прецедентов является попадание в ловушку функциональной декомпозиции. Чтобы избежать этого рекомендуется при трактовке прецедентов придерживаться следующих рекомендаций:

· Определите, представляет ли прецедент некую законченную функциональность, которую инициирует один актер.

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

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

Наиболее распространенным примером реализации диаграммы прецедентов является моделирование банковского автомата [3]:

Рис. 2.12 Диаграмма прецедентов банкомата