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

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

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

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

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

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

Объединение отражает более «тесное» отношение между объектами, при котором изменение объекта влияет на некоторый другой объект в наборе. Простейший пример такого отношения – изменение формата соседней страницы при добавле­нии текста на предыдущей странице документа.

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

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


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

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

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

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

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

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

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

Связи

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

На рис. 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 .


























Давайте обсудим 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

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

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

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

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

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

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

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

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

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

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

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

class Controller {

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

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

КЛАССЫ

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

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

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

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

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

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

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

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

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

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

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

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

– агрегация;

– обобщение;

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

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

28. Между двумя первыми понятиями существует некоторое отношение. Между третьим и одним из четырёх, приведённых ниже, - такое же (аналогичное) отношение. Укажите нужное понятие:

29. Какую связь отражают каждая схема отношений?

30. Запишите отношения между парами объектов, представленными на рисунках.

31. Приведите 2-3 примера пар объектов, имена отношений которых не изменяются, когда меняются местами имена объектов.

32. Установите соответствие.

33. Приведите примеры.

34. Определите отношения между понятиями и изобразите эти отношения в виде кругов Эйлера по образцу.

35. Составьте пирамиды понятий по образцу.

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

37. Каждый из 35 шестиклассников является читателем по крайней мере одной из двух библиотек: школьной и районной. Из них 25 человек берут книги в школьной библиотеке, 20 – в районной.
Схематически это можно представить так:

38. Каждый ученик в классе изучает по крайней мере один из двух языков: английский или французский. Английский язык изучают 25 человек, французский – 27 человек, оба языка – 18 человек.
Изобразите это схематически и ответьте на вопросы.

39. Решите задачу, используя круги Эйлера или схему состава.
В летнем лагере отдыха 86 семиклассников. 8 из них не любят играть в компьютерные игры. 54 семиклассника предпочитают квесты, 62 – симуляторы. Сколько ребят с одинаковым удовольствием играют и в квесты, и в симуляторы?

40. Постройте схемы состава для следующих объектов.


{reklama}
41. Для каждой из приведённых пар «объект – его часть» запишите действие, которое можно выполнять со всем объектом, и действие, которое можно выполнять с его частью.

42. Для каждой пары объектов укажите связывающее их отношение.

43. Придумайте примеры отношений «является элементом множества», «входит в состав», «предшествует» и представьте их с помощью схем.

44. Решите задачу, используя схему состава.
В салоне небольшого самолёта летят 42 пассажира. Некоторые из них москвичи, остальные иногородние. Среди москвичей 9 мужчин. Некоторые из пассажиров артисты, но ни одна из иногородних женщин не является артисткой. Всего иногородних мужчин 18. Из них 13 – не артисты. Среди пассажиров, не являющихся артистами, 16 мужчин и 11 женщин. 6 москвичей не артисты.
Разберитесь, пожалуйста, с пассажирами: кто есть кто?

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

46. Разгадайте кроссворд «Отношения объектов и их множеств».

47. Состав семьи.
а) По улице идут два сына и два отца. Всего 3 человека. Может ли так быть?
Да. Сын, его отец и его дедушка.

б) В одной многодетной семье у каждого из пяти сыновей было три сестры. Сколько всего детей было в этой семье?
8 (5 братьев и 3 сестры)

в) У трёх маляров был брат Иван, а у Ивана братьев не было. Может ли так быть?
Да. Маляры были сёстрами Ивана.

Что еще почитать