Книга: Rational Rose 2000 и UML Визуальное моделирование

Проектирование отношений

На этапе проектирования отношений должны быть приняты решения относительно следующих вопросов: направленность (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). Они означают следующее: объект, запросивший услугу (клиент) у другого объекта (поставщика услуги), не имеет представления о расположении объекта-поставщика.

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

Последовательность создания отношений зависимости в программе Rational Rose:

1. Щелкните по кнопке Dependency Relationship (Отношение зависимости) на панели инструментов.

2. Щелкните по классу, выступающему в качестве клиента.

3. Перетащите линию связи к классу-поставщику.

Отношение зависимости между классами учебный курс (CourseOffering) и учебный курс БД (DBCourseOffering) показано на рис. 12.5.

Рис. 12.5. Отношение зависимости

Реализация мощности отношений

Мощность отношения со значением, равным единице, реализуется в виде встроенного объекта, ссылки или указателя. Мощность со значением больше единицы обычно реализуется с использованием класса-контейнера (то есть множества или списка). В этом случае список также может быть либо встроенным объектом, либо указателем на класс-контейнер. Решение об обновлении модели (чтобы показать все используемые классы-контейнеры) зависит от самого проекта.

Я обычно не показываю все контейнеры, чтобы не усложнять диаграмму. Вместо этого я устанавливаю параметры генерации кода в программе Rational Rose для выбора правильного контейнера.

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

Для сценария Добавление курса для преподавания (Add a Course to Teach) должны быть спроектированы следующие отношения:

? отношение классов параметры курса преподавателя (ProfessorCourse Options) и добавление учебного курса (AddACourseOffering);

? отношение классов параметры курса преподавателя и список доступных идентификаторов (ValidlDList);

? отношение классов добавление учебного курса и предмет (Course);

? отношение классов предмет и учебный курс (CourseOffering);

? отношение классов учебный курс и преподаватель (Professor);

? отношение классов учебный курс и учебный курс БД (DBCourseOffering).

Отношение классов «параметры курса преподавателя» и «добавление учебного курса»

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

Отношение классов «параметры курса преподавателя» и «список доступных идентификаторов»

Класс список доступных идентификаторов используется во многих окнах для проверки правильности указанного имени пользователя. Проектировщики решили использовать однонаправленную ассоциацию от класса параметры курса преподавателя к классу список доступных идентификаторов.

Отношение классов добавление «учебного курса» и «предмет»

Это также класс пользовательского интерфейса. Проектировщики решили использовать отношение, направленное от класса добавление учебного курса к классу предмет.

Отношение классов «предмет» и «учебный курс»

Это отношение направлено в одну сторону — от класса предмет к классу учебный курс. Кроме того, это агрегационное отношение с содержанием по значению, так как все взаимодействия с классом учебный курс проходят через класс предмет.

В данном проектном решении предполагается, что классы предмет и учебный курс взаимозависимы. В соответствии со сценарием так и должно быть. Но давайте рассмотрим получение выписки для студента. Если класс выписка

(Transcript) — это всего лишь указатель на учебные курсы, которые прослушал студент, то такая схема не подойдет. Классы предмет и учебный курс в этом случае будут существовать независимо (и агрегация должна быть реализована по ссылке). Таким образом, всегда есть отношения, которые могут видоизменяться при появлении новых сценариев.

Отношение классов «учебный курс» и «преподаватель»

Проектное решение, основанное исключительно на данном сценарии, показывает, что отношение между классами учебный курс и преподаватель должно быть отношением зависимости. Это видно из того, что объект преподаватель является параметром операции добавить преподавателя (addProfessor) класса учебный курс. Однако есть и другой сценарий для этого прецедента — просмотр расписания (Review schedule). Здесь объект преподаватель должен «знать» связанные с ним объекты учебный курс. Следовательно, отношения зависимости не будет. Кроме того, сценарий Создание каталога (Create catalog) требует, чтобы каждый класс учебный курс был проинформирован о назначенном преподавателе. На основе этих сведений можно заключить, что отношение не меняется — это двунаправленная ассоциация.

Отношение классов «учебный курс» и «учебный курс» БД

Это отношение может стать отношением зависимости, потому что объект учебный курс БД передается объекту учебный курс как параметр при вызове операции сохранения.

Обновленные диаграммы классов, выполненные при проектировании решения для отношений, показаны на рис. 12.6 и 12.7. Эти решения, возможно, претерпят изменения при добавлении прецедентов и сценариев.

Рис. 12.6. Обновленная главная диаграмма классов для пакета Интерфейс

Рис. 12.7. Обновленная диаграмма классов

Оглавление книги