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

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

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

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

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

Шаблоны проектирования (design patterns) содержат решения общих проблем при проектировании программ. Шаблоны проектирования используются в системе при решении вопросов «как». Говоря словами Грейди Буча, «шаблоны — это круто» [16] Booch, Grady. Best of Booch, SIGS Reference Library. New York, NY, 1996, p. 167. . Они позволяют повторно использовать удачные решения в области проектирования и архитектуры. Благодаря этому можно получить более простые в обслуживании системы и повысить производительность труда. Как и другие классы, создаваемые на этом этапе жизненного цикла, классы, составляющие шаблоны, добавляются в модель и на диаграмму классов. Например, шаблон абстрактный конструктор (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). Они означают следующее: объект, запросивший услугу (клиент) у другого объекта (поставщика услуги), не имеет представления о расположении объекта-поставщика.

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

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

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

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

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

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

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

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

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

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

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