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

Рис. 6.11. Отношения между пакетами в системе регистрации учебных курсов

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

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

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

Несколько объектов, принадлежащих одному классу, могут взаимодействовать друг с другом. Такое взаимодействие изображается на диаграмме классов как возвратная ассоциация или агрегация.

Для выявления отношений между двумя классами изучают сценарии.

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

Класс реализует ряд обязанностей, от которых зависит поведение его объектов. Обязанности исполняются с помощью определенных для класса операций. Необходимо, чтобы операция выполняла только одну задачу и выполняла ее хорошо. Например, класс учебный курс (CourseOffering) должен добавлять и исключать студента. Для этой цели используются две операции: одна добавляет студента, другая — исключает. За всеми экземплярами класса закреплены соответствующие операции.

Структура (structure) объекта описывается атрибутами класса. Каждый атрибут — это поле данных, содержащееся в объекте класса. Объект, созданный на основе класса, наделен значениями всех атрибутов класса. Например, класс предмет (course) имеет следующие атрибуты: название (name), описание (definition) и количество учебных часов (credit hours). Следовательно, каждый объект предмет будет содержать значения перечисленных атрибутов. Они могут повторяться, так как в университете существуют учебные предметы с одинаковым количеством академических часов.

При формировании имен атрибутов и операций используется определенный стиль, благодаря которому достигается единообразие в описании классов и становится удобно работать с моделью и кодом.

Если какой-либо объект класса не наделен атрибутами или операциями, проверьте определение класса. Это может означать отсутствие целостности класса и необходимость его разделения. Предположим, что класс учебный курс (CourseOffering) имеет следующие атрибуты: номер курса (offerNumber), место занятий (location), время занятий (timeOfDay), факультет (department), количество курсов на факультете (numberOfferinglnDepartment). Он может быть осведомлен о своем факультете, но информация о количестве других курсов на факультете ему не нужна.

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

Сообщения на диаграммах взаимодействий обычно отображаются на соответствующие операции в классах-получателях. Однако в особых случаях сообщения не становятся операциями. Если класс-получатель является граничным классом, представляющим графический интерфейс пользователя (GUI), сообщения отражают требования к интерфейсу. Такие сообщения реализуются обычно в виде элементов управления (кнопок и т. п.) и не отражаются на операции, так как требуемое поведение уже заложено в стандартных элементах управления. Например, актер преподаватель должен ввести пароль, чтобы запустить сценарий добавление учебного курса (Add a Course Offering). Это представлено в виде сообщения, направляемого граничному классу параметры курса преподавателя (ProfessorCourseOptions). Оно никогда не станет операцией в интерфейсном классе, а, скорее, будет реализовано в виде поля ввода в окне программы. Сообщения, поступающие актерам и от актеров, также требуют отдельного рассмотрения. Если актер является человеком, сообщение отражает действия человека, следовательно, должно быть реализовано в виде фрагмента руководства пользователя, а не в виде операции. В сценарии добавление учебного курса актер преподаватель имеет определенный пароль для доступа к системе — это обязательное требование, которое должно быть отражено в руководстве. Когда актер является внешней системой, создается отдельный класс, реализующий протокол взаимодействия с внешней системой. В этом случае сообщения отображаются на операции данного класса.