"Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (fb2) " - читать интересную книгу автора (Буч Гради)

Объектно-ориентированный анализ и проектирование с примерами приложений на С++ Об автореПредисловиеЧАСТЬ ПЕРВАЯ КонцепцииГлава 1 Сложность1.1. Сложность, присущая программному обеспечению 1.2. Структура сложных систем 1.3. Внесение порядка в хаос 1.4. О проектировании сложных систем Выводы Дополнительная литература Глава 2 Объектная модель2.1. Эволюция объектной модели 2.2. Составные части объектного подхода 2.3. Применение объектной модели Выводы Дополнительная литература Глава 3 Классы и объекты3.1. Природа объекта 3.2. Отношения между объектами 3.3. Природа классов 3.4. Отношения между классами 3.5. Взаимосвязь классов и объектов. 3.6. Качество классов и объектов Выводы Дополнительная литература Глава 4 Классификация4.1. Важность правильной классификации 4.2. Идентификация классов и объектов 4.3. Ключевые абстракции и механизмы Выводы Дополнительная литература

ЧАСТЬ ВТОРАЯ Метод

Глава 5 Обозначения5.1. Элементы обозначений 5.2. Диаграммы классов 5.3. Диаграммы состояний и переходов 5.4. Диаграммы объектов   5.5. Диаграммы взаимодействия 5.6. Диаграммы модулей 5.7. Диаграммы процессов. 5.8. Применение системы обозначений Выводы Дополнительная литература Глава 6 Процесс6.1. Основные принципы 6.2. Микропроцесс проектирования 6.3. Макропроцесс проектирования Выводы Дополнительная литература Глава 7 Практические вопросы7.1. Управление и планирование 7.2. Кадры 7.3. Управление релизами 7.4. Повторное использование 7.5. Качество и измерения 7.6. Документация 7.7. Инструменты 7.8. Специальные вопросы 7.9. Выгоды и опасности объектно-ориентированной разработки Выводы Дополнительная литература ЧАСТЬ ТРЕТЬЯ Примеры приложенийГлава 8 Система сбора данных: метеорологическая станция  8.1. Анализ 8.2. Проектирование 8.3. Эволюция 8.4. Сопровождение Дополнительная литература Глава 9 Среда разработки: библиотека базовых классов9.1. Анализ 9.2. Проектирование 9.3. Эволюция 9.4. Сопровождение Дополнительная литература Глава 10 Архитектура клиент-сервер: складской учет10.1. Анализ 10.2. Проектирование 10.3. Эволюция 10.4. Сопровождение Дополнительная литература Глава 11 Искусственный интеллект: криптоанализ11.1. Анализ 11.2. Проектирование 11.3. Эволюция 11.4. Сопровождение Дополнительная литература Глава 12 Управление: контроль за движением поездов12.1. Анализ 12.2. Проектирование 12.3. Эволюция 12.4. Сопровождение Дополнительная литература ПослесловиеПриложение: Объектно-ориентированные языки программированияА.1. Концепции А.2. Smalltalk А.3. Object Pascal А.4. C++ А.5. Common Lisp Object System (CLOS) А.6. Ada A.7. Eiffel А.8. Другие объектно-ориентированные языки программирования Словарь терминовЛитературные ссылки

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

Типы отношений

Сами по себе объекты не представляют никакого интереса: только в процессе взаимодействия объектов реализуется система. По выражению Ингалса: "Вместо процессора, беззастенчиво перемалывающего структуры данных, мы получаем сообщество хорошо воспитанных объектов, которые вежливо просят друг друга об услугах" [13]. Самолет, по определению, "совокупность элементов, каждый из которых по своей природе стремится упасть на землю, но за счет совместных непрерывных усилий преодолевающих эту тенденцию" [14]. Он летит только благодаря согласованным усилиям своих компонентов.

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

• связи;

• агрегация.

Зайдевиц и Старк назвали эти два типа отношений отношениями старшинства и "родитель/потомок" соответственно [15].

Связи

Семантика. Мы заимствуем понятие связи у Румбаха, который определяет его как "физическое или концептуальное соединение между объектами" [16]. Объект сотрудничает с другими объектами через связи, соединяющие его с ними. Другими словами, связь - это специфическое сопоставление, через которое клиент запрашивает услугу у объекта-сервера или через которое один объект находит путь к другому.

На рис. 3-2 показано несколько разных связей. Они отмечены линиями и означают как бы пути прохождения сообщений. Сами сообщения показаны стрелками (соответственно их направлению) и помечены именем операции. На рисунке объект aController связан с двумя объектами класса DisplayItem (объекты a и b). В свою очередь, оба, вероятно, связаны с aView, но нам была интересна только одна из этих связей. Только вдоль связи один объект может послать сообщение другому.

Связь между объектами и передача сообщений обычно односторонняя (как на рисунке; хотя технически она может быть и взаимной). Как мы увидим в главе 5, подобное разделение прав и обязанностей типично для хорошо структурированных объектных систем [На самом деле организация объектов, показанная на рис. 3-2, встречается настолько часто, что ее можно считать типовым проектным решением. В Smalltalk аналогичный механизм известен как MVC, model/view/controller (модель/представление/контроллер). Как мы увидим в следующей главе, хорошо структурированные системы имеют много таких опознаваемых типовых решений]. Заметьте также, что хотя передаваемое сообщение инициализировано клиентом (в данном случае aController), данные передаются в обоих направлениях. Например, когда aController вызывает операцию move для пересылки данных объекту а, данные передаются от клиента серверу, но при выполнении операции isUnder над объектом b, результат передается от сервера клиенту.

Участвуя в связи, объект может выполнять одну из следующих трех ролей:

∙ Актер [Actor - это деятель, исполнитель. А исполнитель ролей, это и есть актер. - Примеч. ред.]. Объект может воздействовать на другие объекты, но сам никогда не подвергается воздействию других объектов; в определенном смысле это соответствует понятию активный объект.  

Рис. 3-2. Связи.

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

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

На рис. 3-2 объект aController выступает как актер, объект a - как агент и объект aView - как сервер.

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

Абстракция нагрева имеет достаточно четкое поведение, что дает нам право на описание такого класса. Сначала определим тип, значение которого задает прошедшее время в минутах.

// Число прошедших минут typedef unsigned int Minute;

Теперь опишем сам класс TemperatureRamp, который по смыслу задает функцию времени от температуры:

class TemperatureRamp { public:

TemperatureRamp(); virtual ~TemperatureRamp(); virtual void clear(); virtual void bind (Temperature, Minute); Temperature TemperatureAt (Minute);

protected: ... };

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

На самом деле в смысле поведения нам надо нечто большее, чем просто зависимость температуры от времени. Пусть, например, известно, что на 60-й минуте должна быть достигнута температура 250╟F, а на 180-й - 150╟F. Спрашивается, какой она должна быть на 120-й минуте? Это требует линейной интерполяции, так что требуемое от абстракции поведение усложняется.

Вместе с тем, управления нагревателем, поддерживающего требуемый профиль, мы от этой абстракции не требуем. Мы предпочитаем разделение понятий, при котором нужное поведение достигается взаимодействием трех объектов: экземпляра TemperatureRamp, нагревателя и контроллера. Класс TemperatureController можно определить так:

class TemperatureController { public:

TemperatureController(Location); ~TemperatureController(); void process(const TemperatureRampamp;); Minute schedule(const TemperatureRampamp;) const;

private: ... };

Тип Location был определен в главе 2. Заметьте, что мы не ожидаем наследования от этого класса и поэтому не объявляем в нем никаких виртуальных функций.

Операция process обеспечивает основное поведение этой абстракции; ее назначение - передать график изменения температуры нагревателю, установленному в конкретном месте. Например, объявим:

TemperatureRamp growingRamp; TemperatureController rampController(7);

Теперь зададим пару точек и загрузим план в контроллер::

growingRamp.bind (250, 60); growingRamp.bind(150, 180); rampController.process(growingRamp);

В этом примере rampController - агент, ответственный за выполнение температурного плана, он использует объект growingRamp как сервер. Эта связь проявляется хотя бы в том, что rampController явно получает growingRamp в качестве параметра одной из своих операций.

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

Видимость. Пусть есть два объекта А и в и связь между ними. Чтобы А мог послать сообщение в, надо, чтобы в был в каком-то смысле видим для А. Мы можем не заботиться об этом на стадии анализа, но когда дело доходит до реализации системы, мы должны обеспечить видимость связанных объектов.

В предыдущем примере объект rampController видит объект growingRamp, поскольку оба они объявлены в одной области видимости и потому, что growingRamp передается объекту rampController в качестве параметра. В принципе есть следующие четыре способа обеспечить видимость.

• Сервер глобален по отношению к клиенту.

• Сервер (или указатель на него) передан клиенту в качестве параметра операции.

• Сервер является частью клиента.

• Сервер локально порождается клиентом в ходе выполнения какой-либо операции.

Какой именно из этих способов выбрать - зависит от тактики проектирования.

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

• Последовательный - семантика пассивного объекта обеспечивается в присутствии только одного активного процесса.

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

• Синхронный - семантика пассивного объекта обеспечивается в присутствии многих потоков управления; взаимное исключение обеспечивает сервер.

Все объекты, описанные в этой главе, были последовательными. В главе 9 мы рассмотрим остальные варианты более подробно.

Агрегация

Семантика. В то время, как связи обозначают равноправные или "клиент-серверные" отношения между объектами, агрегация описывает отношения целого и части, приводящие к соответствующей иерархии объектов, причем, идя от целого (агрегата), мы можем придти к его частям (атрибутам). В этом смысле агрегация - специализированный частный случай ассоциации. На рис. 3-3 объект rampController имеет связь с объектом growingRamp и атрибут h класса Heater (нагреватель). В данном случае rampController - целое, a h - его часть. Другими словами, h - часть состояния rampController. Исходя из rampController, можно найти соответствующий нагреватель. Однако по h нельзя найти содержащий его объект (называемый также его контейнером), если только сведения о нем не являются случайно частью состояния h.  

Рис. 3-3. Агрегация.

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

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

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

Пример. Добавим в спецификацию класса TemperatureController описание нагревателя:

Heater h;

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

TemperatureController::TemperatureController(Location 1) : h(1) {}