книги / Проектирование автоматизированных информационных систем на основе объектно-ориентированного подхода
..pdf3.ПОСТАНОВКА ЗАДАЧИ ДЛЯ РЕАЛИЗАЦИИ
ВRATIONAL ROSE
Входе изучения методического пособия будет рассматриваться разработка системы учета университетских дисциплин. За основу взят пример, приведенный в работе Т. Кватрани [4].
Студенты старших курсов имеют возможность по желанию вы брать четыре элективные дисциплины.
Перед началом семестра сотрудник деканата составляет каталог элективных дисциплин. Преподаватели посредством системы учета дисциплин распределяют между собой дисциплины из каталога. Один преподаватель не может вести более четырех предметов.
После того как преподаватели распределили между собой дисци плины, студентам сообщается о начале регистрации - приеме заявок от студентов на элективные дисциплины.
Студент посредством системы учета осуществляет выбор четы
рех элективных дисциплин. При этом система учета дисциплин не должна позволить студенту выбрать дисциплину, если на нее уже записалось двадцать человек. В случае если число желающих запи саться на дисциплину по истечении периода регистрации не превы шает пяти человек, то предложение дисциплины аннулируется.
В деканате списки студентов и указанных ими дисциплин уточ няются, утверждаются и становятся доступными для преподавателей.
Ответственность за ведение базы данных со сведениями о препо давателях, дисциплинах и студентах возлагается на деканат.
Система учета дисциплин передает информацию во внешнюю систему учета студентов.
4. ДИАГРАММА ПРЕЦЕДЕНТОВ
4.1. Теоретическая часть
Диаграммы прецедентов (вариантов использования - use case diagram) описывают то, что должна выполнять новая система, или то, как работает существующая, с точки зрения внешнего наблюдателя (пользователя системы), акцентируя внимание на том, что именно система делает, а не на том, как она это делает.
Главная цель прецедентного моделирования - описание функ циональных требований к системе.
Диаграмма прецедентов обеспечивает эффективный механизм взаимодействия разработчиков и конечных пользователей.
Ключевыми элементами диаграммы прецедентов являются ак тер, прецедент, связь.
Актер (actor) представляет собой связное множество ролей, ко торые пользователи исполняют во время взаимодействия с проекти руемой системой. Обычно актер представляет роль, которую в дан ной системе играет человек, аппаратное устройство или даже другая система. Экземпляр актера представляет собой конкретную личность или объект, взаимодействующий с системой. Актер всегда находится вне системы. Актеры используются для моделирования внешних по отношению к проектируемой системе сущностей, которые взаи модействуют с системой и используют ее в качестве отдельных поль зователей.
Принятое графическое изображение актера —это фигурка чело вечка, под которой записывается конкретное имя актера (рис. 4.1).
|
« актер » |
Рис. 4.1. Изображение актера |
Рис. 4.2. Альтернативное |
изображение актера |
В случаях, когда в качестве актера выступает некая система, ак
тер может обозначаться в виде прямоугольника со стереотипом «ак тер» (рис. 4.2).
Нотация UML допускает определять общие типы актеров, напри мер «Работник предприятия», а затем специализировать их, создав разновидности, например «Менеджер», «Аналитик» (рис. 4.3).
Рис. 4.3. Пример обобщенного актера
Рис. 4.4. Изображение прецедента
Прецедент (use case) - это описание множества последователь ностей действий (включая их варианты), которые выполняются сис темой для того, чтобы актер получил результат, имеющий для него определенное значение. Принятое графическое изображение преце дента - эллипс (рис. 4.4).
Любой прецедент должен иметь имя, отличающее его от других прецедентов. Как правило, имя отражает конкретное действие и ука зывается внутри эллипса либо внизу под ним.
Связь (communication). Актеров можно связывать с прецедентами только отношениями ассоциации [1]. Ассоциация между актером и прецедентом показывает, что они общаются друг с другом, воз можно, посылая или принимая сообщения. Ассоциативное отноше ние устанавливает, какую конкретную роль играет актер при взаимо действии с прецедентом. На диаграмме прецедентов, так же, как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и прецедентом (рис. 4.5).
Прецеденты должны находиться внутри системы, которая, в свою очередь, изображается в виде прямоугольника (см. рис. 4.5).
Отношения на диаграмме прецедентов. Отношение расширения
отмечает тот факт, что один из прецедентов может присоединять к своему поведению некоторое дополнительное поведение, опреде ленное для другого прецедента. Отношение расширения изображают в виде зависимости (пунктирная стрелка с закрашенным острием) со стереотипом «extend» (рис. 4.6).
Отношение включения между двумя прецедентами указывает, что некоторое заданное поведение для одного прецедента включается в качестве составного компонента в последовательность поведения другого прецедента. Один прецедент может быть включен в несколь ко других прецедентов, а также может включать в себя другие преце денты. Отношение включения изображают в виде зависимости со стереотипом «include» (рис. 4.7).
Рис. 4.7. Пример отношения расширения и отношения включения
Отношение обобщения означает, что прецедент-потомок насле дует поведение и семантику своего родителя, может замещать его или дополнять его поведение, а кроме того, может быть подставлен всюду, где появляется его родитель (как родитель, так и потомок мо гут иметь конкретные экземпляры). Например, прецедент «Прове рить клиента» может иметь двух специализированных потомков: «Проверить документы» и «Проверить задолженность» (рис. 4.8).
Рис. 4.8. Пример отношения расширения, отношения включения и отношения обобщения
Отношение обобщения отображается на диаграмме в виде сплошной стрелки с незакрашенным острием.
Прецедент-потомок наследует всю функ циональность от своего родителя, в результа те чего отношение обобщения сродни по сво ей природе с отношением включения.
Организация прецедентов. Для организа ции прецедентов и других элементов языка UML их группируют в пакеты [1]. Пакеты позволяют упростить проектирование боль ших систем путем организации элементов
в более крупные блоки. На рис. 4.9 представлено графическое изо бражение пакета в нотации UML.
PNRPU
После того как дисциплины распределены, сотрудник деканата должен убедиться в корректности распределения и сохранить (утвер дить) заявки преподавателей. В том случае, если возникла конфликт ная ситуация, сотрудник деканата вправе сам произвести необходимое перераспределение дисциплин, уведомив об этом преподавателей. На зовем этот прецедент «Сохранение информации о преподавателях».
После того как список предложений дисциплин составлен и у ка ждой дисциплины есть как минимум один преподаватель, сотрудник деканата открывает регистрацию на дисциплины. Это означает, что любой студент старших курсов теперь может посредством системы учета дисциплин оставить свою заявку на дисциплины, которые он желал бы изучить. Назовем этот прецедент «Открытие регистрации». Открытие регистрации включает рассылку списка дисциплин студен там. Рассылка списка дисциплин также является прецедентом, кото рый связан с прецедентом «Открытие регистрации» отношением включения. Информация о каждой дисциплине должна включать полное наименование дисциплины, фамилию преподавателя, содер жание (описание) курса, наименование кафедры и, возможно, требо вания к предварительному уровню подготовки.
Студент посредством системы учета дисциплин просматривает доступные на текущий момент дисциплины. Доступными считаются те, число поданных заявок на которые не превысило двадцати. Из дос тупных дисциплин студент выбирает четыре. Пока длится регистра ция, студент может изменить свой выбор. Работу студента с системой объединим одним прецедентом «Регистрация дисциплин студентом».
По истечении определенного периода сотрудник деканата закры вает регистрацию. С этого момента ни один студент не может вно сить изменения в список выбранных им дисциплин. Этот прецедент назовем соответственно «Закрытие регистрации». После закрытия регистрации сотрудник деканата сохраняет и утверждает заявки сту дентов на выбранные дисциплины. Если на одну из дисциплин запи салось менее пяти человек, то сотрудник деканата удаляет эту дисци плину и согласовывает со студентами, которые подали заявки на эту дисциплину, перевод на другую дисциплину. Эти действия объеди ним в прецеденте «Сохранение информации о студентах».
После закрытия регистрации преподаватель может получить пол ный список студентов, записавшихся на его курс (дисциплину). На зовем этот прецедент «Получение списка студентов по дисциплине».
Прецеденты документируются точно так же, как и актеры. Доку ментация на прецедент «Выбор дисциплин преподавателем» может иметь следующее содержание: «Прецедент инициируется актером «Преподаватель» и предлагает возможности выбора дисциплин».
Для каждого прецедента может быть определен поток событий, происходящий по мере выполнения соответствующих функций сис темы. При описании потока событий мы определяем, что необходимо осуществить, и игнорируем аспекты того, как это делается.
Описание потока событий прецедента является частью его спе цификации и может храниться в отдельном файле, созданном любым текстовым или другим редактором. Рекомендуется в рамках проекта использовать некий стандартный шаблон*, например, такой [4]:
1.0.Наименование прецедента
1.1.Краткое описание
2.0.Потоки событий
2.1.Основной поток
2.2.Альтернативные потоки
2.2. п. <Альтернативный поток п>
3.0. Специальные требования 3. и. Специальное требование п>
4.0. Предусловия
4.и. <Предусловие п>
5.0.Постусловия
5.п. <Постусловие п>
6.0.Дополнительные замечания
6.1.«^Дополнительное замечание х>
Приведем пример спецификации событий для прецедента «Вы бор дисциплин преподавателем» [4]. Забегая вперед, отметим, что на основе этой спецификации в дальнейшем будет построена диаграмма последовательностей для реализации этого прецедента. Специфика ция разработана строго по приведенному выше шаблону (табл. 4.1).
Этот шаблон позаимствован из регламента Rational Unified Process.