Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:
1. Каковы задачи каждого актера?
2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы?
3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?
4. Должен ли актер информировать систему о внезапных изменениях внешней среды?
5. Должен ли актер быть проинформирован об изменениях состояния системы?
6. Какие прецеденты будут поддерживать и обслуживать систему?
7. Могут ли все функциональные требования быть реализованы прецедентами?
В языке UML прецедент изображается в виде овала — см. рис. 3.4.
Рис. 3.4. Нотация языка UML для прецедента
Основа правильного прецедента
На протяжении многих лет велись дискуссии на тему правильности прецедентов. Одной из проблем, с которой я столкнулась, является уровень их детализации. Насколько мал или велик он должен быть? Здесь нет однозначного ответа. Я обычно использую следующее правило: «Прецедент обычно определяет основной элемент функциональности и совершается от начала до конца. Он должен приносить что-то значимое для актера».
Например: в системе регистрации учебных курсов студент должен выбрать курсы для наступающего семестра; студент должен быть прикреплен к предлагаемым курсам; студенту должен быть выставлен счет. Это три прецедента или только один? Я бы сделала один, потому что функциональность действия определяет происходящее от начала до конца. Что бы получилось, если студента не прикрепили бы к выбранным курсам (или, по крайней мере, не известили об этом)? Или что произошло бы, если студент не получил бы счет (университет наверняка бы разорился, если бы курсы стали бесплатными)?
Другая проблема в том, как объединить функциональность различных действий, которые кажутся едиными. Например, регистратор должен добавлять курсы, удалять и изменять их. Три прецедента или один? Здесь я опять сделала бы один — работа с учебным планом, потому что действия инициируется одним актером (регистратором) и выполняются над одной сущностью системы (расписанием).
Прецеденты в системе регистрации курсов университета
В системе должны обеспечиваться следующие потребности:
□ актер студент использует систему для регистрации на курсы;
□ по завершении выбора курсов в систему оплаты должна поступить необходимая информация;
□ актер преподаватель использует систему для выбора курсов, которые он будет читать в наступающем семестре, и должен получать от системы расписание занятий;
□ регистратор отвечает за составление каталога курсов на семестр, за управление информацией об учебных курсах, а также о студентах и преподавателях, работающих с системой.
На основании перечисленных потребностей можно выделить следующие прецеденты:
□ регистрация на курсы;
□ выбор курсов для преподавания;
□ запрос расписания курсов;
□ управление информацией о курсах;
□ управление информацией о преподавателях;
□ управление информацией о студентах;
□ создание каталога курсов.
Для создания прецедентов в программе Rational Rose выполните следующие действия:
1. Щелкните правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в окне браузера.
2. В появившемся контекстно-зависимом меню выберите команду New => Use Case (Создать => Прецедент). В списке браузера появится новый прецедент.
3. Введите для него нужное название.
Окно браузера со списком прецедентов для системы регистрации курсов показано на рис. 3.5.
Рис. 3.5. Прецеденты
Краткое описание прецедентов
В краткое описание прецедентов вносят информацию об их назначении. Такое описание обычно определяется на этапе задумки при выделении прецедентов для системы.
Для прецедента регистрация на курсах оно будет выглядеть так, как на рис. 3.6.
Рис. 3.6. Краткое описание прецедента
Этот прецедент инициируется студентом. Он обеспечивает возможность создавать, изменять, удалять и просматривать расписание студента в определенном семестре.