Отношения между объектами

Типы классов объектов.

Тема 3.2. Проектирование ПО при объектном подходе

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

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

Большинство классов можно отнести к определенному типу, который рйменительно к данному подходу называют стереотипом, например:

• классы-сущности (классы предметной области);

• граничные (интерфейсные) классы;

• управляющие классы;

• исключения и т. д. (рис. 7.1).

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

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

Управляющие классы служат для моделирования последовательного по­ведения, заложенного в один или несколько вариантов использования.

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

Диаграмма пакетов показывает, из каких частей состоит проектируемая программная система, и как эти части связаны друг с другом.

Связь между пакетами фиксируют, если изменения в одном пакете могут повлечь за собой изменения в другом. Она определяется внешними связями классов и других ресурсов, объединенных в пакет. Возможны различные ви­ды зависимости классов, например:

• объекты одного класса посылают сообщения объектам другого класса;

• объекты одного класса обращаются к компонентам объектов другого;

• объекты одного класса используют объекты другого в списке параметров методов и т.п.

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

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

На рис. 7.2 приведены обозначения нотации UML, которые допустимо использовать на диаграммах пакетов. Кроме указанных обозначений на диа­граммах пакетов допустимо показывать обобщения (рис, 7.3), что, как правило, подразумевает наличие единого интерфейса нескольких пакетов. В этом случае фиксируется связь от пакета-подтипа к пакету-супертипу.

Пример 7.1. Разработать диаграмму пакетов системы решения комбина­торно-оптимизационных задач.

Анализ концептуальной модели (см. рис. 6.9) и вариантов использова­ния (см, рис. 6.4) позволяют выделить следующие группы классов или паке­ты:

• Пользовательский интерфейс — классы, реализующие объекты интерфейса с пользователем;

• Библиотека интерфейсных компонентов - классы, реализующие интерфейсные компоненты: окна, кнопки, метки и т. п.;

• Объекты управления - классы, реализующие сценарии вари­антов использования;

• Объекты задачи - классы, реализующие объекты предметной области системы;

• Интерфейс базы данных - классы, реализующие интерфейс с базой данных;

• База данных;

• Базовые структуры данных - классы, реализующие внутренние структуры данных, такие, как деревья, n-связные списки и т. п.;

Обработка ошибок - классы исключений, реализующие обработку не­
штатных ситуаций.

Последние два пакета объявим глобальными, так как их элементы могут
использовать классы всех пакетов.

Процесс проектирования классов начинают с уточнения отношении между ними. На этапе проектирования помимо ассоциации и обобщения различают еще два типа отношения между классами: агрегацию и композицию

Агрегацией называют ассоциацию между целым и его частью или частями. Агрегацию вместо ассоциации указывают, если отношение «целое-часть» в конкретном случае существенно. Например, если колесо нас интересует только как часть автомобиля, то между соответствующими классами целесообразно указать отношение агрегации, а если колесо - товар, также как и автомобиль, то связь целое-часть не существенна.

Композиция - более сильная разновидность агрегации, которая подразумевает, что объект-часть может принадлежать только единственному целому.
Объект-часть при этом создается и уничтожается только вместе со своим целым.

Уточненные отношения между классами фиксируют на диаграмме клас­сов. Для этого используют специальные уловные обозначения (рис. 7.11).

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

.

Специальное обозначение на диаграмме классов этапа проектирования используют для указания абстрактных классов и методов: на диаграмме классов их имена выделяют курсивом, либо перед именем класса указывают стереотип «abstract».

UML также включает специальную нотацию для обозначения парамет­ризованных классов или шаблонов (рис. 7.1 2, а). Получение из такого класса класса с конкретными типами элементов называют связыванием. Связывание можно обозначить двумя способами: явно указав тип параметра (рис. 7.12, б) и используя условное обозначение уточнения (рис. 7.12, в).

Диаграммы классов позволяют также отобразить ограничения, которые невозможно показать, используя только понятия, рассмотренные выше (ассо­циации, обобщения, атрибуты} операции). Например, показать, что средний

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

Особое место в процессе проектирования классов занимает проектирование интерфейсов.

Дата добавления: 2014-01-07