5.2. Реализация в Rational Rose
Прежде чем начать построение диаграммы классов, необходимо идентифицировать ключевые абстракции, т.е. определить классы сущностей. Строгой инструкции, которая предписывала бы способы отыскания классов, нет. Источники классов - знание предметной об ласти и требования, предъявляемые к системе. Поскольку процесс проектирования отличается итеративным характером, множество классов системы на протяжении ее жизненного цикла изменяется и пополняется [4].
Исходя из предметной области разрабатываемой системы, сразу можно выделить следующие классы сущностей: «Пользователь», «Преподаватель», «Студент», «Сотрудник деканата», «Дисциплина»
и«Предложение дисциплины».
Всистеме Rational Rose диаграмма классов является основой для генерации кода программы, поэтому названия классов, атрибутов, операций необходимо вводить на английском языке (в противном случае при генерации кода символы кириллицы будут заменены восьмеричным кодом).
Втабл. 5.1 представлены соответствующие английские названия вышеперечисленных классов.
|
Т аблица 5.1 |
Название класса в Rational Rose |
Расшифровка |
SysUser |
Пользователь системы |
Teacher |
Преподаватель |
Student |
Студент |
DeaneryEmployee |
Сотрудник деканата |
Discipline |
Дисциплина |
DisciplineOffer |
Предложение дисциплины |
Создадим классы, представленные в таблице. Для этого в окне браузера выделим элемент «Logical View», вызовем контекстное ме ню и выберем пункт «New», а затем «Class». В результате этого будет создан новый класс. Назовем его «SysUser». Так как этот и все пере численные в таблице классы являются классами сущностей, то сразу укажем соответствующий стереотип для созданного класса, открыв окно спецификации класса и выбрав стереотип «entity» (рис. 5.11).
«getOffers». Вызовем контекстное меню класса «DisciplineOffer»
и выберем пункт «New» > «Operation». Введем название «getOffers» для нового элемента. Двойным щелчком на элементе-операции от кроем окно спецификации и задокументируем данную операцию, введя в поле «Documentation» ее назначение из табл. 5.2. Аналогич ным образом создадим оставшиеся операции из табл. 5.2. В результа те получим класс «DisciplineOffer», представленный на рис. 5.18.
|
Т аблица 5.2 |
|
Название операции |
Назначение операции |
|
в Rational Rose |
||
|
||
getOffers() |
Получить список всех существующих предложений |
|
addTeacher() |
Назначить преподавателя |
|
removeTeacher() |
Снять преподавателя |
|
addStudent() |
Добавить студента |
|
removeStudent() |
Снять студента |
|
getStudentsQuantityO |
Получить список студентов по предложению |
|
save() |
Сохранить предложение |
|
close() |
Закрыть предложение |
|
cancel() |
Отменить предложение |
|
isOpen() |
Проверить, действительно ли еще предложение |
<<entity>>
DisciplineOffer
^>ID Integer ^studentsQuantity Integer ^studyYear Integer l%term Integer
^ d a y s Enum G|?startTime Time ^endT im e Time
^getOffersO
^addTeacherO
^removeTeacherO
^addStudentO *re moveStudentO
*saveO ^closeO
^cancelO
^isOpenO
Рис. 5.18. Класс «DisciplineOffer»
множественности. Для этого в окне диаграммы классов, дважды щелкнув на линии связи, открываем диалоговое окно спецификации «Association Specification». В этом окне переходим на закладку «Role A Detail» (или «Role В Detail»), соответствующую одной из двух ро лей связи (А или В), и в поле «Multiplicity» вводим требуемое значе ние признака множественности. В результате этого получаем диа грамму классов, представленную на рис. 5.20.
До сих пор мы рассматривали только классы сущностей. Теперь рассмотрим граничные классы и классы управления. Граничные классы и классы управления идентифицируются, как правило, при реализации сценариев соответствующих прецедентов.
В качестве примера рассмотрим сценарий «Внесение предложения дисциплины». Согласно этому сценарию преподаватель выбирает предмет, который он желал бы читать в течение семестра. Этот сцена рий является частным потоком событий, представленным в специфи кации прецедента «Выбор дисциплин преподавателем» (см. табл. 4.1). Соответствующая диаграмма представлена на рис. 4.16.
Создадим граничные классы. Напомним, что таковыми являются классы, представляющие собой «посредников» при взаимодействии актера с системой.
С прецедентом «Выбор дисциплин преподавателем» взаимодей ствует только один актер - «Преподаватель». В общем случае препо даватель может не только вносить новые предложения, но и просмат ривать, печатать, редактировать и удалять предложения, внесенные ранее. Система должна содержать некоторые средства, с помощью которых актер мог бы осуществить задуманное. С этой целью созда ем класс «ChoosingDisciplineOption» (опция выбора дисциплины). Рассматриваемый сценарий предполагает наличие одной опции - «внесение предложения дисциплины». Эта опция будет являться под классом класса «ChoosingDisciplineOption», назовем подкласс «AddingOffer».
Для обслуживания потока событий, происходящих в процессе выполнения прецедента «Выбор дисциплин преподавателем», созда дим один класс управления и назовем его «DisciplineOfferControl» (контроль предложения курса).
Создадим вышеперечисленные классы, указав для классов границ стереотип «boundary», а для класса управления стереотип «control». Да лее создаем дополнительную диаграмму классов «AddingOfferDgm», на
