Основные элементы моделирования прецедентов

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

При выявлении прецедентов необходимо всегда помнить главный принцип: их следует тесно связывать с будущим руководством пользователя. Связь между каждым прецедентом и разделом руководства должна быть очевидной. Это подкрепляет основную идею, состоящую в том, что проект системы базируется на восприятии ее пользователями. Можно сказать, что «основа на прецедентах» означает: «Сначала напишите руководство пользователя, а потом код». Если вы перерабатываете унаследованную систему, то можете просто отталкиваться от руководства пользователя и вносить необходимые изменения.

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

Некоторые авторы призывают использовать развернутые шаблоны прецедентов. Но наши рекомендации всем ученикам таковы:

1. Создайте шаблон прецедента, в котором есть разделы «Главная последовательность» и «Альтернативные последовательности». Другие разделы не нужны, они будут только отвлекать внимание.

2. Задайте себе вопрос: *Что происходит?», С ответа на него начинается главная последовательность.

3. Спросите себя: А что дальше?*. Продолжайте в том же духе, покавсе детали главной гоеледователъностн не будут записаны на бумаге.

4. Спросите себя: «Л что еще можем происходить?». Будьте упорны. Хоть что-нибудь еще может происходить? Вы уверены? Задавайте себе эти вопросы, пока не появится достаточно обширный набор альтернатив. Поверьте, проблемы на этом этапе - ничто по сравнению с бедами, возникающими, скажем, во время тестирования сопряжений.

Цель состоит не в том, чтобы построить красивую модель прецедентов; важно учесть все, что может сделать пользователь.

Вы еще будете анализировать этот материал при рецензировании требований (глава 4), и еще раз во время рецензирования предварительного проекта (глава 6), и снова при рецензировании окончательного проекта (глава 8). Если вам кажется, что это чересчур, вспомните: чем четче определено поведение системы, тем легче ее построить.

В вашем распоряжении есть несколько механизмов для вычленения фрагментов (к примеру, обработки ошибок), общих для некоторого набора прецедентов. Обычно это разумно, так как разбиение на атомарные блоки упрощает анализ и экономит время при рисовании диаграмм. Будете ли вы применять механизм обобщения прецедентов и отношения включения (include) и расширения (extend), имеющийся в UML, или отношения вызова (invoke) и предшествования (precede) из языка Open . Modeling Language (OML), рекомендуемые нами в книге «Use Case Driven Object Modeling with UML», цель состоит в том, чтобы получить набор небольших, четко очерченных и допускающих повторное использование прецедентов.

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

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

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