Ключевые слова:

• отношение
• отношение «является элементом множества»
• отношение «входит в состав»
• схема отношения
• схема состава
• круги Эйлера

Разнообразие отношений

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

Например:

• «Иван - сын Андрея»;
• «Эверест выше Эльбруса»;
• «Винни Пух дружит с Пятачком»;
• «21 кратно 3»;
• «Кострома такой же старинный город, как и Москва»;
• «текстовый процессор входит в состав программного обеспечения компьютера»;
• «один байт равен восьми битам».

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

Отношение - это взаимная связь, в которой находятся какие-либо объекты.

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

Пусть про населённые пункты А, Б, В, Г, Д и Е известно, что некоторые из них соединены железной дорогой: населённый пункт А соединён железной дорогой с населёнными пунктами В, Г и Е, населённый пункт Е - с населёнными пунктами А, В, Г и Д.

Для большей наглядности имеющиеся связи («соединён железной дорогой») можно изобразить линиями на схеме отношений. Объекты на схеме отношений могут быть изображены кругами, овалами, точками, прямоугольниками и т. д. (рис. 4).

Рис. 4

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

Так, на рис. 4 каждая стрелка направлена от отца к его сыну и поэтому отражает отношение «приходится отцом», а не «приходится сыном». Например: «Андрей приходится отцом Ивану».

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

Рис. 5

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

Отношения могут существовать не только между двумя объектами, но и между объектом и множеством объектов, например:

• Гарри Поттер - литературный персонаж;
• «Камчатка - это полуостров (является полуостровом)»;
• «Москва - столичный город».

В каждом из этих предложений описано отношение «является элементом множества».

Отношения между множествами

Отношения могут связывать два множества объектов, например:

• «файлы группируются в папки»;
• «колеса входят в состав автомобилей»;
• «бабочки - это насекомые (являются разновидностью насекомых)».

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

Если множества А и В имеют общие элементы, т. е. элементы, принадлежащие одновременно А и Б, то говорят, что эти множества пересекаются (рис. 6).

Рис. 6

Пример. Пусть А - множество электронных писем, В - множество писем на русском языке. В пересечение этих множеств попадают все электронные письма на русском языке.

Если множества не имеют общих элементов, то говорят, что они не пересекаются (рис. 7).

Рис. 7

Пример. Пусть А - множество компьютерных устройств ввода информации, В - множество устройств вывода информации. Эти множества не имеют общих элементов.

Если каждый элемент множества В является элементом множества А, то говорят, что В - подмножество А (рис. 8).

Рис. 8

Пример. Пусть А - множество учеников, В - множество шестиклассников. Множество шестиклассников является подмножеством множества учеников.

Если каждый элемент множества В является элементом множества А и, наоборот, каждый элемент множества А является элементом множества В, то говорят, что множества А и В равны (рис. 9).

Рис. 9

Пример. Пусть А - множество равносторонних прямоугольников, В - множество квадратов. Эти множества равны.

Отношение «входит в состав»

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

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

Объект может состоять из множества различных объектов. Например, объект «компьютер» состоит из множества не похожих друг на друга объектов (системный блок, монитор, клавиатура и т. д.). При делении объекта «компьютер» на части новые объекты получают разные имена; признаки новых объектов различны.

При описании состава объектов в одних случаях речь идет о составе конкретного объекта, а в других - об общих составных частях множества объектов. В последнем случае описание состава содержит ответ на вопрос «Из чего обычно состоят объекты некоторого множества?». Например:

• «в состав дома входят стены, крыша, двери, окна, ...»;
• «в составе автомобиля есть двигатель, кузов, багажник, ...».

Описывая состав объекта, человек мысленно «разбирает» его на части. При этом, как правило, используют такой приём: сначала называют небольшое число крупных частей, затем каждую из них «разбирают» на части поменьше и т. д. Например, при описании состава дома удобно выделить сначала фундамент, стены и крышу, затем в составе стены выделить окно и дверь, затем сообщить, что окно состоит из рамы и стёкол, и так же поступить, описывая состав двери (рис. 10).

Схема отношений «входит в состав» (схема состава ) отражает не только составные части, но и тот порядок, в котором предмет «разбирался» на части. Таким образом, она отражает строение (структуру) объекта. На схеме состава можно использовать линии без стрелок, если имя объекта-части располагать ниже имени объекта, которому принадлежит эта часть.

Рис. 10

Все имена на рис. 11 - общие (обозначают множества предметов), потому что эта схема отражает состав не одного конкретного дома, а «дома вообще».

Рис. 11

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

Давайте обсудим 1.Приведите примеры отношений между: двумя объектами; объектом и множеством объектов; двумя множествами объектов. 2.В каких отношениях могут быть только объекты некоторых видов? В каких отношениях могут находиться любые объекты? 3.Как можно наглядно изобразить отношения объектов? 4.Приведите примеры пар объектов, имена отношений которых изменяются, когда меняются местами имена объектов. ??

Бабушка прислала Ивану посылку с яблоками и грушами. Некоторые из этих плодов были большими, остальные – маленькими. По цвету плоды тоже различались: часть плодов была жёлтого цвета, остальные – зелёного. Среди плодов не было ни маленьких груш, ни маленьких зелёных яблок. Яблок было 25, а груш – 17. Больших плодов было 32. Жёлтых плодов было 28. Зелёных яблок было на 2 больше, чем зелёных груш. Иван угостил этими плодами своих друзей. Больше всего ребятам понравились большие жёлтые яблоки. Сколько было таких яблок? Давайте обсудим?? Решение

Так как больших плодов было 32, то среди них было 15 больших яблок (32-17). Всего яблок было 25, значит, маленьких яблок 10, причём все они были жёлтого цвета. Фрукты, 42 Яблоки, 25 Большие,15 Жёлтые Зелёные Маленькие, 10 Жёлтые, 10 Груши, 17 Большие, 17 ЖёлтыеЗелёные

Если жёлтых плодов 28, то зелёных – 14. А так зелёных яблок на 2 больше, чем зелёных груш, то из уравнения х+х+2=14 получаем, что зелёных яблок 8, а груш 6. Фрукты, 42 Яблоки, 25 Большие,15 Жёлтые, 7 Зелёные, 8 Маленькие, 10 Жёлтые, 10 Груши, 17 Большие, 17 Жёлтые, 9 Зелёные, 6 Ответ: больших жёлтых яблок было 7.

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

1.Приведите примеры отношений между: двумя объектами; объектом и множеством объектов; двумя множествами объектов. 2.В каких отношениях могут быть только объекты некоторых видов? В каких отношениях могут находиться любые объекты? 3.Как можно наглядно изобразить отношения объектов? 4.Приведите примеры пар объектов, имена отношений которых изменяются, когда меняются местами имена объектов. Давайте обсудим??

5. В детском саду 52 ребёнка. Каждый из них любит конфеты или мороженое. Половина детей любит конфеты, а 20 человек – конфеты и мороженое. Сколько детей любит мороженое? Сколько детей любит только мороженое? Давайте обсудим?? 20, любят К и М 26, любят К?, любят М?, любят только М?, любят только К 52

2.1.4. Зависимости между классами (объектами)

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

Между объектами можно устанавливать зависимости по данным. Эти зависимости выражают связи или отношения между классами указанных объектов. Примеры таких зависимостей изображены на рисунке 2.6 (первые две зависимости - бинарные, третья зависимость - тренарная). Зависимость изображается линией, соединяющей классы над которой надписано имя этой зависимости, или указаны роли объектов (классов) в этой зависимости (указание ролей - наиболее удобный способ идентификации зависимости).

Рис. 2.6. Зависимости между классами

Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость. Так, в первом примере на рисунке 2.6 имя зависимости имеет_столицу предполагает, что зависимость направлена от класса страна к классу город (двусторонность зависимости вроде бы пропала); но следует иметь в виду, что эта зависимость двусторонняя в том смысле, что одновременно с ней существует и обратная зависимость является_столицей. Точно таким же образом, во втором примере на рисунке 2.6 можно рассматривать пару зависимостей владеет-принадлежит. Подобных недоразумений можно избежать, если идентифицировать зависимости не по именам, а по наименованиям ролей классов, составляющих зависимость.

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

Дальнейшие примеры зависимостей между классами приведены на рисунке 2.7. Первый пример показывает зависимость между клиентом банка и его счетами. Клиент банка может иметь одновременно несколько счетов в этом банке, либо вовсе не иметь счета (когда он впервые становится клиентом банка). Таким образом, нужно изобразить зависимость между клиентом и несколькими счетами, что и сделано на рисунке 2.7. Второй пример показывает зависимость между пересекающимися кривыми (в частности, прямыми) линиями. Можно рассматривать 2, 3, и более таких линий, причем они могут иметь несколько точек пересечения. Наконец, третий пример показывает необязательную (optional) зависимость: компьютер может иметь, а может и не иметь мышь.

Зависимостям между классами соответствуют зависимости между объектами этих классов. На рисунке 2.8 показаны зависимости между объектами для первого примера рисунка 2.6; на рисунке 2.9 показаны зависимости между объектами для примеров, изображенных на рисунке 2.7.

Рис. 2.7. Дальнейшие примеры зависимостей. Обозначения

Рис. 2.8. Зависимости между объектами

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

При проектировании системы удобнее оперировать не объектами, а классами.

Рис. 2.9. Более сложные зависимости между объектами

Понятие зависимости перенесено в объектно-ориентированную технологию проектирования программных систем из технологии проектирования (и моделирования) баз данных, где зависимости используются с давних пор. Языки программирования, как правило, не поддерживают явного описания зависимостей. Тем не менее описание зависимостей очень полезно при разработке программных систем. Технология OMT использует зависимости при интерпретации диаграмм, описывающих систему.

Связи

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

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

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

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

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

Рис. 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 TemperatureRamp&); Minute schedule(const TemperatureRamp&) 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 .

Сами по себе объекты не представляют никакого интереса: только в процессе их взаи­модействия реализуется система. Например, самолет – это "совокупность элементов, каждый из которых по своей природе стремится упасть на землю, но за счет совместных непрерывных усилий преодолевающих эту тенденцию". Он летит только бла­годаря согласованным усилиям своих компонентов.

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

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

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

Перечислим следу­ющие четыре способа обеспечить видимость :

– сервер глобален по отношению к клиенту;

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

– сервер является частью клиента;

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

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

Пример. Рассмотрим класс объектов, управляющих температурой в теплице Controller. Пусть он имеет атрибут h класса Heater (нагреватель).

class Controller {

В данном случае Controller – целое, а h – его часть (часть его состояния). Исходя из Controller, можно найти соот­ветствующий нагреватель. Однако по h нельзя найти содержащий его объект (на­зываемый также его контейнером), если только сведения о нем слу­чайно не являются частью состояния h.

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

КЛАССЫ

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

Класс – это множество объектов, имеющих общую структуру и общее поведение. Любой конкретный объект является экземпляром класса.

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

– маргаритка – цветок;

– роза – (другой) цветок;

– красная и желтая розы – розы;

– лепесток является частью обоих видов цветов;

– пчелы опыляют цветы и питаются их нектаром.

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

Известны три основных типа отношений между классами. Во-первых, это отношение "обобщение/специализация" (общее и частное), т.е. иерархия "является". Розы являются цветами, что значит: розы являются специализированным частным случа­ем, подклассом более общего класса "цветы". Во-вторых, это отношение "целое/часть", т.е. иерархия "имеет". Например, лепестки являются частью цветов. В-третьих, это семантические, смысловые отношения, ассоциации. Например, пчелы ассоциируются с цветами.

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

– ассоциация;

– агрегация;

– обобщение;

– зависимость;

– инстанцирование.