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

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

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

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