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

Связи

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

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

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 использует зависимости при интерпретации диаграмм, описывающих систему.

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями или связями в языке UML являются:

Отношение зависимости (dependency relationship)

Отношение ассоциации (association relationship)

Отношение обобщения (generalization relationship)

Отношение реализации (realization relationship)

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

Отношение зависимости

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

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов ("->" или "<-"). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рис. 5.3). На данном рисунке изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А - клиентом этой зависимости.

Рис. 5.3. Графическое изображение отношения зависимости на диаграмме классов

В качестве класса-клиента и класса-источника зависимости могут выступать целые множества элементов модели. В этом случае одна линия со стрелкой, выходящая от источника зависимости, расщепляется в некоторой точке на несколько отдельных линий, каждая из которых имеет отдельную стрелку для класса-клиента. Например, если функционирование Класса_С зависит от особенностей реализации Класса_А и Класса_/>, то данная зависимость может быть изображена следующим образом (рис. 5.4).

Рис. 5.4. Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_Л и Класс_Б)

Стрелка может помечаться необязательным, но стандартным ключевым словом в кавычках и необязательным индивидуальным именем. Для отношения зависимости предопределены ключевые слова, которые обозначают некоторые специальные виды зависимостей. Эти ключевые слова (стереотипы) записываются в кавычках рядом со стрелкой, которая соответствует данной зависимости. Примеры стереотипов для отношения зависимости представлены ниже:

"access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;

"bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;

"derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;

"import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;

"refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

Примечание

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

Отношение ассоциации

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

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

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами - классом "Компания" и классом "Сотрудник" (рис. 5.5). Они связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс "Сотрудник", а вторым - класс "Компания". Отдельным примером или экземпляром данного отношения может являться пара значений (Петров И. И., "Рога&Копыта"). Это означает, что сотрудник Петров И. И. работает в компании "Рога&Копыта".

Рис. 5.5. Графическое изображение отношения бинарной ассоциации между классами

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

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

Порядок классов в N-арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фиксируется. Некоторый класс может быть присоединен к ромбу пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей N-арной ассоциации, а сама N-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация, в свою очередь, является классом с соответствующим обозначением в виде прямоугольника и является самостоятельным элементом языка UML - ассоциацией-классом (Association Class). N-арная ассоциация не может содержать символ агрегации ни для какой из своих ролей.

В качестве примера конкретной тернарной ассоциации рассмотрим отношение между тремя классами: "Футбольная команда", "Год" и "Игра". Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию об играх футбольных команд в национальном чемпионате в течение нескольких последних лет (рис. 5.6).

Как уже упоминалось, отдельный класс ассоциации имеет собственную роль в отношении. Эта роль может быть изображена графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент - конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации является частью ассоциации, но не класса. Каждая ассоциация имеет два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами ассоциации и должны перемешаться вместе с ними.

Рис. 5.6. Графическое изображение тернарной ассоциации между тремя классами

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

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

Так, для рассмотренного ранее примера (см. рис. 5.5) кратность "1" для класса "Компания" означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса "Сотрудник" означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Заметим, что вместо кратности "1..*" записать только символ "*" нельзя, поскольку последний означает кратность "0..*". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Но такая кратность вполне приемлема в других ситуациях, как это видно из рассмотренного выше примера (рис. 5.6).

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

Частным случаем отношения ассоциации является так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на тот факт, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается строка-ограничение "{хог}".

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

Рис. 5.7. Графическое изображение исключающей ассоциации между тремя классами

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

Отношение агрегации

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

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

Примечание

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

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

В качестве примера отношения агрегации рассмотрим взаимосвязь типа "часть-целое", которая имеет место между сущностью "Грузовой автомобиль" и такими компонентами, как "Двигатель", "Шасси", "Кабина", "Кузов". Не претендуя на точное соответствие терминологии данной предметной области, нетрудно представить себе, что грузовой автомобиль состоит из двигателя, шасси, кабины и кузова. Именно это отношение между классом "Грузовой_автомобиль" и классами "Двигатель", "Шасси", "Кабина", "Кузов" описывает отношение агрегации.

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой "целое". Остальные классы являются его "частями" (рис. 5.8).

Рис. 5.8. Графическое изображение отношения агрегации в языке UML

Еще одним примером отношения агрегации может служить известное каждому из читателей деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Используя обозначения языка UML, компонентный состав ПК можно представить в виде соответствующей диаграммы классов (рис. 5.9), которая в данном случае иллюстрирует отношение агрегации.

Рис. 5.9. Диаграмма классов для иллюстрации отношения агрегации на примере ПК

Отношение композиции

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

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

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или "целое". Остальные классы являются его "частями" (рис. 5.10).

Рис. 5.10. Графическое изображение отношения композиции в языке UML

В качестве дополнительных обозначений для отношений композиции и агрегации могут использоваться дополнительные обозначения, применяемые для отношения ассоциации. А именно, указание кратности класса ассоциации и имени данной ассоциации, которые не являются обязательными. Применительно к описанному выше примеру класса "Окно_программы" его диаграмма классов может иметь следующий вид (рис. 5.11).

Рис. 5.11. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы

Данный пример может иллюстрировать и другие особенности разрабатываемой компьютерной программы, которые не указывались в явном виде при описании этого примера Так, в частности, указание кратности 1 рядом с классом "Рабочая_область" характерно для однодокументных приложений.

Отношение обобщения

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

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

Рис. 5.12. Графическое изображение отношения обобщения в языке UML

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

Рис. 5.13. Пример графического изображения отношения обобщения классов

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

Рис. 5.14. Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

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

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

В качестве ограничений могут быть использованы следующие ключевые слова языка UML:

{complete} - означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может. Пример - класс Клиент_банка является предком для двух классов: Физическое_лицо и Компания, и других классов-потомков он не имеет. На соответствующей диаграмме классов это можно указать явно, записав рядом с линией обобщения данную строку-ограничение;

{disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов. В приведенном выше примере это условие также выполняется, поскольку предполагается, что никакое конкретное физическое лицо не может являться одновременно и конкретной компанией. В этом случае рядом с линией обобщения можно записать данную строку-ограничение;

{incomplete} - означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно восполнить их перечень не изменяя уже построенную диаграмму. Пример - диаграмма класса "Автомобиль", для которой указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего каталога. С другой стороны, для отдельной задачи, такой как разработка системы продажи автомобилей конкретных моделей, в этом нет необходимости. Но указать неполноту структуры классов-потомков все же следует;

{overlapping} - означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам. Пример - класс "Многоугольник" является классом-предком для класса "Прямоугольник" и класса "Ромб". Однако существует отдельный класс "Квадрат", экземпляры которого одновременно являются объектами первых двух классов. Вполне естественно такую ситуацию указать явно с помощью данной строки-ограничения.

С учетом возможности использования строк-ограничений диаграмма классов (рис. 5.14) может быть изображена без многоточий и без потери информации (рис. 5.15).

Рис. 5.15. Вариант графического изображения отношения обобщения классов с использованием строки-ограничения

Чтобы проиллюстрировать особенности использования отношения обобщения, преобразуем один из рассмотренных ранее примеров изображения классов в графическую нотацию языка UML. В качестве такого примера рассмотрим иерархию вложенности классов для абстрактного класса "Автомобиль" (см. рис. 1,2, 2.7). Как нетрудно заметить, отношение между отдельными классами на этих рисунках есть именно отношение обобщения, которое в языке UML имеет специальное графическое обозначение. С учетом этой графической нотации, фрагмент семантической сети для представления иерархии класса "Автомобиль" (см. рис. 2.7) может быть представлен в виде следующей диаграммы классов (рис. 5.16).

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

Рис. 5.16. Фрагмент диаграммы классов с отношением обобщения для представления иерархии классов "Автомобиль" из рассмотренного ранее примера (см. рис. 2.7)

Примечание

В качестве упражнения для закрепления рассмотренного материала можно попытаться построить диаграммы классов или хотя бы их фрагменты для библиотек стандартных классов MFC (Microsoft) и VCL (Borland/Inprise) с использованием графической нотации языка UML. Можно предположить, что в недалеком будущем справочные руководства по соответствующим средам программирования будут содержать именно такие диаграммы классов, а возможно, и некоторые другие.