Терри Кватрани - Rational Rose 2000 и UML Визуальное моделирование

После завершения очередной версии риски переоцениваются и план проекта при необходимости обновляется. «Для большинства проектов план определяет пять (плюс-минус два) промежуточных выпусков»[15].

Процесс планирования версий представлен на рис. 12.1.

Рис. 12.1. Процесс планирования версий

План выпуска версий для задачи регистрации учебных курсов

Версия 1:

Сохранение сведений о преподавателе Выбор курсов для преподавания Создание учебного плана Версия 2:

Сохранение сведений о студенте Составление каталога Версия 3:

Регистрация на курсы

Запрос списка учебных классов

Версия 1 содержит риск, связанный с базой данных. Сведения о курсах должны храниться в базе данных, которая доступна для всех. Сценарии Сохранение сведений о преподавателе и Выбор курсов для преподавания включены в данную версию, так как их необходимо завершить до составления каталога. С помощью второй версии добавляется функциональность, необходимая для регистрации студента (сведения о студентах должны быть помещены в базу данных, и каталог должен быть доступен студентам). Версия 3 завершает систему.

На ранних стадиях жизненного цикла проекта для граничных классов системы были созданы пустые классы. Теперь они должны быть доработаны: нужно внести данные о количестве и расположении окон, а также создать обработчики событий, поступающих от пользователей. Для получения сведений о требованиях к пользовательскому интерфейсу применяются диаграммы последовательностей. Интерфейс пользователя позволяет получать все сообщения, поступающие от актера. Кроме того, он должен обеспечивать отправку всех сообщений, адресованных актеру.

Проектирование пользовательского интерфейса для прецедента «Выбор курсов для преподавания»

После изучения сценариев, связанных с прецедентом Выбор курсов для преподавания (Select Courses to Teach), созданы окна для добавления, удаления и просмотра и определены следующие требования:

□ преподаватель должен ввести пароль для входа в систему. Для ввода пароля создано отдельное окно;

□ если пароль верен, на экране появляется окно Параметры курса преподавателя (ProfessorCourseOptions). Оно содержит поле для указания семестра и группу кнопок: Добавить курс (Add Course), Удалить курс (Delete Course), Просмотр расписания (Review Schedule), Печать расписания (Print Schedule).

В этой книге проектирование рассматривается на примере операции Добавить курс (Add Course) для данного сценария. Важно отметить, что проект системы не может основываться только на одном сценарии — он развивается по мере создания новых сценариев. Я выбрала один сценарий для иллюстрации нотаций Rational Unified Process и UML, которые могут быть использованы для представления различных решений при проектировании.

Операция Добавить курс подразумевает добавление преподавателя к учебному курсу в качестве учителя. Этот сценарий требует отдельного окна для ввода преподавателем необходимой информации. Я назвала это окно Добавление (Addition). Оно содержит следующие элементы:

□ поле ввода Название предмета (Course name);

□ поле ввода Номер предмета (Course number);

□ список Учебные курсы (Course offerings);

□ кнопку OK;

□ кнопку Отмена (Cancel);

□ кнопку Выход (Quit).

После того как преподаватель ввел название и номер предмета, система получит и отобразит список учебных курсов. Затем преподаватель может выбрать учебный курс. При щелчке по кнопке ОК объекту предмет направляется сообщение.

Реализация пользовательского интерфейса зависит от выбранной библиотеки классов. Ее рассмотрение выходит за рамки данной книги. В этом разделе говорится о проектировании интерфейса. Как правило, он создается с помощью специальных инструментов для построения графических интерфейсов пользователя. В данном случае, после создания классов ГИП, могут быть использованы средства возвратного проектирования программы Rational Rose для добавления классов к модели.

Классы обычно добавляются в модель, чтобы выяснить, как реализовать что-либо в системе. Например, в системе регистрации курсов определено, что преподаватель должен ввести пароль, который обязательно проверяется. Для реализации этой задачи в систему добавляется класс, проверяющий пароль. По мере добавления классов в систему они отображаются на соответствующих диаграммах.

Обновленная диаграмма классов для задачи регистрации учебных курсов изображена на рис. 12.2. В этой точке жизненного цикла я буду показывать только названия стереотипов, потому что в модель добавляется разная детальная информация.

Рис. 12.2. Класс уровня проектирования

Вам необязательно поступать таким же образом. Чтобы стереотипы по умолчанию отображались только в виде названий, выберите в меню команду Tools => Options (Сервис => Параметры), затем вкладку Diagram (Диаграмма) и установите переключатель Label (Название) в группе переключателей Stereotype display (Отображение стереотипов).

Шаблоны проектирования (design patterns) содержат решения общих проблем при проектировании программ. Шаблоны проектирования используются в системе при решении вопросов «как». Говоря словами Грейди Буча, «шаблоны — это круто»[16]. Они позволяют повторно использовать удачные решения в области проектирования и архитектуры. Благодаря этому можно получить более простые в обслуживании системы и повысить производительность труда. Как и другие классы, создаваемые на этом этапе жизненного цикла, классы, составляющие шаблоны, добавляются в модель и на диаграмму классов. Например, шаблон абстрактный конструктор (Abstract Factory) может использоваться для получения объектов пользователь (RegistrationUser) различного типа. На сегодняшний день издано много книг с описанием шаблонов проектирования. Одна из наиболее популярных — книга Е. Гаммы (Е. Gamma) «Шаблоны проектирования: элементы многократно используемых объектно-ориентированных программ» (Design Patterns: Elements of Reusable Object-Oriented Software), выпущенная издательством Addison-Wesley в 1995 году.

На этапе проектирования отношений должны быть приняты решения относительно следующих вопросов: направленность (navigation), содержание (containment), уточнение (refinement) и реализация мощности (multiplicity implementation).

Направленность

Ассоциации и агрегации являются двунаправленными отношениями. Во время проектирования ассоциативные связи проверяются, чтобы выяснить, действительно ли нужна двунаправленность. По возможности отношения создаются однонаправленными (то есть проходимыми в одну сторону) — их так легче реализовать и поддерживать.

Для указания направленности отношения в программе Rational Rose:

1. Щелкните правой кнопкой мыши по линии ассоциативной или агрегаци-онной связи.

2. В появившемся контекстно-зависимом меню выберите команду Navigation (Направленность), чтобы изменить направленность отношения.

Некоторые однонаправленные ассоциации показаны на рис. 12.3.

Рис. 12.3. Направленность отношений

Содержание

В модели также необходимо определить тип содержания в агрегационном отношении. Содержание может быть реализовано по значению или по ссылке. Первое предполагает эксклюзивное владение для содержащего класса (агрегата) и изображается в виде закрашенного ромба. Второе не предполагает эксклюзивного владения и изображается в виде незакрашенного ромба.

Для указания типа агрегационного содержания в программе Rational Rose:

1. Дважды щелкните по линии агрегационной связи, чтобы открыть диалоговое окно настройки параметров отношения.

2. Выберите вкладку Detail (Детально) для роли, представляющей «целое» в агрегации.

3. Установите нужный тип содержания в группе переключателей Containment (Содержание).

4. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно.

Отношение с содержанием по значению (класс параметры курса преподавателя (ProfessorCourseOptions) содержит класс добавление учебного курса (AddACourseOffering)) и отношение с содержанием по ссылке (отношение класса параметры курса преподавателя (ProfessorCourseOptions) к классу список доступных идентификаторов (ValidlDList)) показаны на рис. 12.4.

Рис. 12.4. Содержание

Уточнение

На данном этапе ассоциативные отношения могут быть преобразованы в отношения зависимости (dependency relationship). Они означают следующее: объект, запросивший услугу (клиент) у другого объекта (поставщика услуги), не имеет представления о расположении объекта-поставщика.