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

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

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