Рис. 3.4. Нотация языка UML для прецедента
Основа правильного прецедента
На протяжении многих лет велись дискуссии на тему правильности прецедентов. Одной из проблем, с которой я столкнулась, является уровень их детализации. Насколько мал или велик он должен быть? Здесь нет однозначного ответа. Я обычно использую следующее правило: "Прецедент обычно определяет основной элемент функциональности и совершается от начала до конца. Он должен приносить что-то значимое для актера".
Например: в системе регистрации учебных курсов студент должен выбрать курсы для наступающего семестра; студент должен быть прикреплен к предлагаемым курсам; студенту должен быть выставлен счет. Это три прецедента или только один? Я бы сделала один, потому что функциональность действия определяет происходящее от начала до конца. Что бы получилось, если студента не прикрепили бы к выбранным курсам (или, по крайней мере, не известили об этом)? Или что произошло бы, если студент не получил бы счет (университет наверняка бы разорился, если бы курсы стали бесплатными)?
Другая проблема в том, как объединить функциональность различных действий, которые кажутся едиными. Например, регистратор должен добавлять курсы, удалять и изменять их. Три прецедента или один? Здесь я опять сделала бы один - работа с учебным планом, потому что действия инициируется одним актером (регистратором) и выполняются над одной сущностью системы (расписанием).
Прецеденты в системе регистрации курсов университета
В системе должны обеспечиваться следующие потребности:
актер студент использует систему для регистрации на курсы;
по завершении выбора курсов в систему оплаты должна поступить необходимая информация;
актер преподаватель использует систему для выбора курсов, которые он будет читать в наступающем семестре, и должен получать от системы расписание занятий;
регистратор отвечает за составление каталога курсов на семестр, за управление информацией об учебных курсах, а также о студентах и преподавателях, работающих с системой.
На основании перечисленных потребностей можно выделить следующие прецеденты:
регистрация на курсы;
выбор курсов для преподавания;
запрос расписания курсов;
управление информацией о курсах;
управление информацией о преподавателях;
управление информацией о студентах;
создание каталога курсов.
Для создания прецедентов в программе Rational Rose выполните следующие действия:
1. Щелкните правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в окне браузера.
2. В появившемся контекстно-зависимом меню выберите команду New => Use Case (Создать => Прецедент). В списке браузера появится новый прецедент.
3. Введите для него нужное название.
Окно браузера со списком прецедентов для системы регистрации курсов показано на рис. 3.5.
Рис. 3.5. Прецеденты
Краткое описание прецедентов
В краткое описание прецедентов вносят информацию об их назначении. Такое описание обычно определяется на этапе задумки при выделении прецедентов для системы.
Для прецедента регистрация на курсах оно будет выглядеть так, как на рис. 3.6.
Рис. 3.6. Краткое описание прецедента
Этот прецедент инициируется студентом. Он обеспечивает возможность создавать, изменять, удалять и просматривать расписание студента в определенном семестре.
Для добавления краткого описания прецедента в программе Rational Rose:
1. В списке браузера выберите прецедент, щелкнув по нему мышью.
2. Установите курсор в окне описания и наберите краткое описание прецедента. Если окно невидимо, откройте его с помощью команды меню View => Documentation (Вид => Описание).
Поток событий для прецедента
Поток событий (flow of events) для прецедента - это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах того, "что" система должна делать, а не "как" она должна это делать. То есть он описывается на языке предметной области, а не терминами реализации. Поток событий должен определять:
когда и как прецедент начинается и заканчивается;
как он взаимодействует с актером;
какие данные ему нужны;
нормальную последовательность событий для прецедента;
описание потоков в альтернативных и исключительных ситуациях.
Документация на потоки событий обычно составляется в момент проработки итеративным способом. Сначала дается только краткое описание необходимых шагов для нормального выполнения прецедента. В ходе анализа шаги уточняются. На завершающем этапе в прецедент добавляют потоки для исключительных ситуаций.
В каждом проекте должен использоваться стандартный шаблон для создания документа, описывающего поток событий. Самыми полезными я считаю следующие шаблоны:
X. Поток событий для прецедента <имя>.
X.1. Предусловия.
X.2. Главный поток.
X.3. Под-потоки (если применимы).
X.4. Альтернативные потоки.
Здесь X - число от единицы до количества прецедентов.
Рассмотрим пример полного документа с описанием потока событий для прецедента выбор курсов для преподавания (Select Courses to Teach).
Поток событий для прецедента "выбор курсов для преподавания"
1.1. Предусловия
Под-поток создание учебных курсов (Create Course Offerings) прецедента управление информацией о курсах (Maintain Course Information) должен быть выполнен перед его началом.
1.2. Главный поток
Прецедент начинает выполняться, когда преподаватель подключается к системе регистрации и вводит свой пароль. Система проверяет правильность пароля (Е-1) и просит преподавателя выбрать текущий или будущий семестр (Е-2). Преподаватель вводит нужный семестр. Система предлагает выбрать требуемую операцию: добавить (Add), удалить (Delete), просмотреть (Review), напечатать (Print) или выйти (Quit).
Если выбрана операция добавить (Add), S-1: выполняется поток добавить учебный курс (Add a Course Offering).
Если выбрана операция удалить (Delete), S-2: выполняется поток удалить учебный курс (Delete a Course Offering).
Если выбрана операция просмотреть (Review), S-3: выполняется поток просмотреть расписание (Review Schedule).
Если выбрана операция напечатать (Print), S-4: выполняется поток напечатать расписание (Print Schedule).
Если выбрана операция выйти (Quit): прецедент завершается.
1.3. Под-потоки
S-1: добавить учебный курс (Add a Course Offering)
Система отображает диалоговое окно, содержащее поле для ввода названия и номера предмета. Преподаватель вводит название и номер предмета (Е-3). Система отображает список учебных курсов для указанного предмета (Е-4). Преподаватель выбирает учебный курс. Система закрепляет за преподавателем выбранный учебный курс (Е-5). Затем прецедент начинается сначала.
S-2: удалить учебный курс (Delete a Course Offering)
Система отображает диалоговое окно, содержащее поле для ввода названия и номера учебного курса. Преподаватель выбирает название и номер учебного курса (Е-6). Система удаляет взаимосвязь курса с преподавателем (Е-7). Затем прецедент начинается сначала.
S-3: просмотреть расписание (Review Schedule)
Система получает (Е-8) и отображает следующую информацию для всех учебных курсов, за которыми закреплен данный преподаватель: название предмета, номер предмета, номер учебного курса, день недели, время и место проведения занятий. Когда преподаватель отмечает, что просматривает список, прецедент начинается сначала.
S-4: напечатать расписание (Print Schedule)
Система распечатывает расписание преподавателя (Е-9). Прецедент начинается сначала.
1.4. Альтернативные потоки
Е-1: введен неверный идентификационный номер преподавателя. Пользователь должен повторить ввод идентификационного номера или завершить прецедент.
Е-2: введен неверный семестр. Пользователь должен повторить ввод семестра или завершить прецедент.
Е-3: введено неверное название или номер предмета. Пользователь должен повторить ввод названия и номера предмета или завершить прецедент.
Е-4: список учебных курсов не может быть отображен. Пользователю сообщается, что данная команда в настоящий момент недоступна. Прецедент начинается сначала.
Е-5: преподаватель не может быть прикреплен к выбранному учебному курсу. Информация сохраняется, система осуществит прикрепление позже. Выполнение прецедента продолжается.
Е-6: введено неверное название или номер учебного курса. Пользователь должен повторить ввод названия и номера учебного курса или завершить прецедент.
Е-7: система не может удалить связь курса с преподавателем. Информация сохраняется, система удалит связь позже. Выполнение прецедента продолжается.
Е-8: система не может получить информацию о расписании. Прецедент начинается сначала.
Е-9: расписание не может быть распечатано. Пользователю сообщается, что данная опция в данный момент недоступна. Прецедент начинается сначала.