Риски задачи регистрации курсов
Группа разработчиков определила, что главный риск системы связан с возможностью эффективно сохранять и получать информацию об учебных планах. С этой целью было создано несколько прототипов, чтобы оценить механизмы хранения и доступа к информации для каждой рассматриваемой системы управления базами данных. Результаты испытания прототипов показали, что риск неэффективной работы базы данных может быть уменьшен. Дополнительные прототипы были использованы для оценки аппаратных ресурсов, необходимых при создании онлайновой системы регистрации.
Постановка задачи регистрации курсов
В начале каждого семестра студенты могут запросить каталог курсов, в который включен список учебных предметов, предлагаемых в данном семестре. Информация о курсах должна содержать фамилию преподавателя, название факультета и краткое описание, помогающее студентам сделать выбор.
Новая система позволит студенту выбрать четыре курса из предложенных в наступающем семестре. Кроме того, каждому студенту нужно дополнительно указать еще два варианта, на случай если курс будет переполнен или отменен. На курс не должно быть записано более десяти или менее трех студентов. Курс, на который запишутся менее трех студентов, будет отменен. По завершении регистрации система регистрации направляет информацию в систему оплаты для выставления счетов студентам.
Преподаватели должны иметь возможность онлайнового доступа к системе для указания курсов, которые они будут читать, и для просмотра списка записавшихся студентов.
В каждом семестре выделяется определенное время, в течение которого студенты могут менять свое расписание и получать доступ к системе для добавления или удаления выбранных курсов.
Резюме
Фаза задумки - это этап открытия. Задача оговаривается и обсуждается в группе разработчиков с привлечением заказчиков. Все высказанные предположения и допущения могут быть утверждены или отклонены после апробации на прототипах. Результаты этой фазы - описание внешних интерфейсов, оценка начальных рисков, определение требований к системе. Заказчики, клиенты, пользователи и другие заинтересованные стороны обсуждают различные идеи и точки зрения и предлагают возможные пути получения необходимых ресурсов и инструментов.
Глава 3. Создание прецедентов
Поведение системы
Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров - actors) и связи между прецедентами и актерами (диаграммы прецедентов - use cases diagrams). Основная задача модели прецедентов - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Разработка модели прецедентов начинается на стадии задумки с выбора актеров и определения общих принципов функционирования системы. Затем на этапе проработки модель дополняется детальной информацией к существующим прецедентам, а при необходимости добавляются новые.
Актеры
Актеры не являются частью системы - они представляют собой кого-то или что-то, что должно взаимодействовать с системой. Актеры могут:
только снабжать информацией систему;
только получать информацию из системы;
снабжать информацией и получать информацию из системы.
Обычно актеры определяются из описания задачи или путем переговоров с заказчиками и экспертами. Для выявления актеров может быть использована следующая группа вопросов:
1. Кто заинтересован в определенном системном требовании?
2. Какую роль система будет выполнять в организации?
3. Кто получит преимущества от использования системы?
4. Кто будет снабжать систему информацией, использовать информацию и получать информацию от системы?
5. Кто будет осуществлять поддержку и обслуживание системы?
6. Использует ли система внешние ресурсы?
7. Выступает ли какой-либо участник системы в нескольких ролях?
8. Выступают ли различные участники в одной роли?
9. Будет ли новая система взаимодействовать со старой?
В языке UML актер изображается в виде фигуры человечка - см. рис. 3.1.
Рис. 3.1. Нотация языка UМL для изображения актера
Определение "хорошего" актера
Необходимо внимательно подходить к вопросу определения актеров для системы. Такое определение обычно происходит итеративным образом - первый из утвержденных списков актеров часто далек от конечного. Например, является ли новый студент актером другого вида нежели студент, вернувшийся из академического отпуска? Допустим, вы сначала ответили утвердительно. Следующий шаг - выяснить, как актер взаимодействует с системой. Если новый студент использует систему не так, как вернувшийся студент, то это разные актеры. Если они используют систему одинаковым образом - это один и тот же актер.
Другой вариант - создание актера для каждой роли, исполняемой участником. Здесь тоже можно получить избыточность. Хороший пример - ассистенты преподавателей в системе регистрации курсов университета. Ассистенты тоже проводят занятия с группами студентов. Средства, требующиеся для выбора курсов, уже заложены в языке для актеров в роли студентов и актеров в роли преподавателей. Таким образом, нет необходимости в актерах, исполняющих роль ассистентов преподавателей.
Отобрав утвержденных актеров и описания их ролей в использовании системы, вы итеративным путем получите нужный набор актеров для системы.
Актеры в системе регистрации курсов университета
Перечислим ответы на ранее поставленные вопросы:
1. Студент хочет зарегистрироваться на курсы.
2. Преподаватель хочет выбрать курсы, которые он будет читать.
3. Регистратор должен создать учебный план и составить каталог на семестр.
4. Регистратор должен хранить информацию о курсах, преподавателях и студентах.
5. Система оплаты должна получать необходимую информацию из системы регистрации.
Основываясь на полученных ответах, можно выделить следующих актеров: студент (Student), преподаватель (Professor), регистратор (Register) и система оплаты (Billing system).
Алгоритм создания актеров в программе Rational Rose:
1. Щелкните правой кнопкой мыши по разделу Use Case View (Представление прецедентов) в окне браузера.
2. В появившемся контекстно-зависимом меню выберите команду New => Actor (Создать => Актер). В список окна браузера будет добавлен новый актер с именем New Class.
3. Выбрав новый пункт списка, введите нужное имя актера.
Окно браузера со списком актеров для системы регистрации курсов показано на рис. 3.2.
Рис. 3.2. Актеры
Описание актеров
В модель желательно включить краткое описание каждого актера, в котором нужно указать роль актера при взаимодействии с системой.
Для системы регистрации курсов описание актеров может быть следующим:
студент - человек, который регистрируется для посещения занятий в университете;
преподаватель - человек, который читает лекции в университете;
регистратор - человек, управляющий системой регистрации курсов;
система оплаты - внешняя система, выполняющая функции расчетов за курсы.
Описание актеров в программе Rational Rose осуществляется при выполнении следующих действий:
1. Если окна описания нет на экране, откройте его, выбрав команду меню View => Documentation (Вид => Описание).
2. Из списка браузера выберите актера, щелкнув по нему мышью.
3. Установите курсор в окне описания и введите текст описания актера.
Пример описания актера студент показан на рис. 3.3.
Рис. 3.3. Описание актера студент
Прецеденты
С помощью прецедентов (use cases) моделируется диалог между актером и системой. Другими словами, они определяют возможности, обеспечиваемые системой для актера. Набор всех прецедентов системы определяет способы ее использования. Можно сказать, что прецедент - это последовательность транзакций, выполняемых системой, которая приводит к значимому результату для определенного актера.
Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:
1. Каковы задачи каждого актера?
2. Будет ли актер создавать, хранить, изменять, удалять или получать информацию из системы?
3. Какой прецедент будет создавать, хранить, изменять, удалять или получать эту информацию?
4. Должен ли актер информировать систему о внезапных изменениях внешней среды?
5. Должен ли актер быть проинформирован об изменениях состояния системы?
6. Какие прецеденты будут поддерживать и обслуживать систему?
7. Могут ли все функциональные требования быть реализованы прецедентами?
В языке UML прецедент изображается в виде овала - см. рис. 3.4.