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

Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение. Управляющие классы можно представить как классы, «исполняющие» прецедент и определяющие его динамику. Они обычно зависят от приложения.

На ранней стадии проработки управляющие классы добавляются для каждой пары актер/прецедент. Такие классы определяют поток событий в прецедентах.

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

Кто должен знать, как прикрепить студента, — управляющий класс или класс, представляющий курс занятий? Правильный ответ — класс, представляющий курс занятий. Управляющий класс знает лишь, когда студент должен быть прикреплен. «Плохой» управляющий класс знает не только когда, но и как прикрепить студента.

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

Этапы создания стереотипов для классов в программе Rational Rose:

1. Щелкните правой кнопкой мыши по имени класса в списке браузера.

2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Открыть параметры).

3. Щелкните по вкладке General (Общие).

4. В открывающемся списке Stereotype (Стереотип) выберите нужный стереотип. Чтобы создать новый стереотип, введите его имя в поле открывающегося списка Stereotype.

5. Щелкните по кнопке OK, чтобы закрыть диалоговое окно настройки параметров класса.

Параметры для класса студент показаны на рис. 4.5. Если язык, выбранный в модели по умолчанию, отличается от языка анализа (вкладка Notation (Нотация) диалогового окна Options (Настройки)), то в диалоговом окне параметров класса появится еще одна вкладка для языка.

Рис. 4.5. Установка стереотипа класса

Документирование классов

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

Информация, необходимая для регистрации студента и оплаты обучения. Студент — это человек, обучающийся в университете.

А вот пример неправильного описания:

Имя, адрес и телефон студента.

Оно раскрывает только структуру класса, которую можно увидеть, посмотрев на список атрибутов, и не поясняет, для чего нужен данный класс.

Трудности при выборе имени и описании класса могут свидетельствовать о том, что это недостаточно хорошая абстракция. В следующем списке перечислены возможнее варианты:

  можно определить имя и дать краткое, четкое описание — хороший класс-кандидат;

  можно определить имя и выбрать описание, похожее на описание другого класса, — объединить классы;

  можно определить имя, но потребуется целая книга, чтобы описать назначение класса, — разделить класс;

  нельзя определить имя и дать описание — требуется дополнительный анализ для выделения правильных абстракций.

Чтобы описать классы в программе Rational Rose:

1. Выберите класс в списке браузера.

2. Установите курсор в окне описания и введите описание класса. Описание класса представлено на рис. 4.6.

Рис. 4.6. Описание класса

Пакеты

Если в системе существует немного классов, управлять ими достаточно легко. Многие системы состоят из большого количества классов, поэтому необходим механизм, позволяющий разбить их на группы и облегчающий управление и повторное использование. Здесь оказывается полезной концепция пакетов.

Пакет (package) в логическом представлении модели — это набор классов и других связанных пакетов. Путем объединения классов в пакеты мы можем получить представление модели на более высоком уровне. Изучая содержимое пакета, мы, наоборот, получаем более детальное представление.

Каждый пакет содержит интерфейс, реализуемый набором его общедоступных классов (public classes), то есть тех, с которыми могут общаться классы из других пакетов. Остальные классы пакета — это классы реализации (implementation classes), которые не взаимодействуют с классами в других пакетах.

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