Видимость связанных объектов

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

В приведенном примере механизма MVC, объект DisplayItem видит объект View, поскольку оба они должны быть объявлены в одной области видимости и потому, что объект View передается объекту DisplayItem в качестве параметра его метода.

Существуют четыре способа обеспечения видимости связанных объектов:

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

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

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

· Сервер локально порождается клиентом в ходе выполнения какой-либо операции (в качестве локального объекта в теле операции клиента).

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

Синхронизация

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

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

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

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

Агрегация

В то время, как связи обеспечивают равноправные или клиент-серверные отношения между объектами, агрегация описывает отношения целого и части, приводящие к иерархии объектов, причем, идя от целого (агрегата), можно придти к его частям (атрибутам агрегата). В этом смысле агрегация – специализированный частный случай ассоциации. На рис. 4.3 объект DisplayItem имеет связь с объектом View и атрибут m класса Image. В этом случае объект DisplayItem – целое, а m – его часть, в виде ссылки на объект класса Image. Другими словами, m – часть состояния DisplayItem. Исходя из DisplayItem, можно найти соответствующее изображение, применяемое для визуализации обработанной информации. Однако по m нельзя найти содержащий его объект (называемый также его контейнером), если только сведения о нем не являются случайно частью состояния m.

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

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

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

До появления языка UML вопрос о различии между агрегацией и композицией у аналитиков не возникал. Многие разработчики считают агрегацию важной. Язык UML включает агрегацию (рис. 4.4), но семантика ее очень расплывчата (целое физически содержит указатель или ссылку на часть).

 

 

: Club

: Person

 

Рис. 4.4. Агрегация

 

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

 

 

 

Рис. 4.5. Композиция

 

 

Рис. 4.6. Агрегация и композиция

 

Согласно приведенной диаграмме, Многоугольник состоит из упорядоченной совокупности Вершин. Эти Вершины могут изменяться при изменении Многоугольника, вследствие чего, применяется агрегация.Композиция применяется для связи между Многоугольником и Графическим объектом. Графический объект содержит атрибуты «цвет» и «текстура». Он рассматривается отдельно от Многоугольника, поскольку многие графические элементы могут использовать такой набор атрибутов. Отношение между Многоугольником и Графическим объектом определяется как композиция, и таким образом, показывается, что данный Графический объект создается и уничтожается вместе с данным Многоугольником и не может быть изменен. Разумеется, можно изменить атрибуты Графического объекта, но невозможно заменить один Графический объект другим.

На рис. 4.7 показано другое обозначение композиции.

 

 

Рис. 4.7. Альтернативное обозначение для композиции

 

В этом случае компонент помещается внутрь целого (объект в объекте - «Целое has-a Компонент»). Имя класса-компонента не выделяется полужирным шрифтом, как все имена классов на диаграммах, и записывается в виде

< имя роли> : < Имя класса> ,

кроме того, кратность указывается в верхнем правом углу.

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

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

Правило: «нет совместного владения» - является ключевым в композиции. Другое допущение состоит в том, что если удаляется объект-многоугольник (Polygon), то автоматически должны удалиться все точки (Points), которыми этот многоугольник владеет.

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

Приведем рекомендации по выбору связи и агрегации:

· Связи обеспечивают низкое сцепление между объектами.

· Агрегация инкапсулирует части, как секреты целого.

 

Классы

Понятия объекта и класса настолько тесно связаны, что невозможно говорить об объекте безотносительно к его классу.

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

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

Класс – это контейнер для кода и данных и способ инкапсуляции пространства имен и управления видимостью переменных и методов.

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

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

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

Атрибуты класса

Атрибут представляет собой пару тип-значение. Класс определяет типы атрибутов. Объекты содержат значения атрибутов.

Полный формат атрибута:

видимость имя: тип [кратность] = значение по умолчанию {характеристика}

Например:

- имя атрибута: string [1] = «Без имени» { readOnly}

Обязательно только имя.

· Метка видимость обозначает, относится ли атрибут к открытому (+) ( public ), или закрытому (-) ( private ), защищенному (#) ( protected ) или к пакетному (~) ( package, internal ) типам видимости.

· имя атрибута – способ ссылки класса на атрибут – приблизительно соответствует имени поля в языке программирования.

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

· кратность определим при рассмотрении ассоциации.

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

· Элемент {характеристика} позволяет указывать дополнительные свойства атрибута. В нашем примере он равен { readOnly}, то есть клиенты не могут изменять значение атрибута. Если этот элемент пропущен, то, как правило, атрибут можно модифицировать.

Отметим ряд других характеристик:

· changeable – нет ограничений на модификацию значения атрибута;

· addOnly – для атрибутов с множественностью большей единицы; дополнительные значения могут быть добавлены, но после создания значение не может удаляться или изменяться;

· frozen – после инициализации объекта значение атрибута не изменяется;

· ordered – ограничение {повторение} подразумевает, что целевые объекты некоторым образом упорядочены, то есть образуют список, причем в этом списке каждый целевой объект может появиться только один раз.

Ассоциации

Другая сторона свойства класса – это ассоциация. Значительная часть информации, которую можно указать в атрибуте, появляется в ассоциации. На рис. 4.8 и 4.9 показаны одни и те же свойства, представленные в различных обозначениях [21].

 

Рис. 4.8. Представление свойств заказа в виде атрибутов

 

 

Рис. 4.9. Представление свойств заказа в виде ассоциаций

 

Два имени на ассоциативной линии ([конкретная] датаЗаказа) и ([конкретная] позицияЗаказа) представляют так называемые ролевые имена, которые ставятся у целевого класса.

Ролевое имя (role name) используется для перемещения к объекту целевого класса из исходного.

В реализованной системе ролевое имя (на противоположном конце ассоциации) становится атрибутом исходного класса, при этом типом этого атрибута является класс, на который указывает ролевое имя.

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

На рис. 4.10 показано отношение двунаправленной ассоциации, с именем ПоставкаЗаказа, между классами Заказ и Поставка. Это отношение дает возможность «отправить» (или связать) объект Заказ более, чем одному объекту Поставка (обозначенному звездочкой *), также как и объект Поставка может осуществить операцию «поставки» (быть связанным с) более, чем одного объекта Заказ.

 

 

Рис. 4.10. Пример двунаправленной ассоциации

 

Двунаправленная ассоциация, также как и обычная, может иметь разные формы маркировки:

· в виде пары свойств, связанных в противоположных направлениях;

· именованием ассоциации, чтобы отношение можно было использовать в предложении;

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

Рекомендуется давать имя ассоциации, только если это улучшает понимание. Слишком часто встречаются такие имена, как « has » (иметь) или « is related to » (связан с) или « is part of » (является частью).

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

Приведем еще один пример двунаправленной ассоциации (рис. 4.11) с кодом реализации на языке С# [21].

 

 

Рис. 4.11. Двунаправленная ассоциация

class Car

{

private Person _owner;

public Person Owner

{ get { return _owner; }

set { if ( _owner! = null ) _owner.friendCars().Remove( this );

_owner = value;

if ( _owner! = null ) _owner.friendCars().Add( this );

}

}

}

class Person

{

public IList Cars

{ get { return ArrayList. ReadOnly( _cars); }}

 

public void AddCar (Car arg)

{ arg.Owner = this; }

private IList _cars = new ArrayList ();

internal IList friendCars()

{ //должен быть использован только Car.Owner

return _cars;

}

…

}

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

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

Кратность свойства

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

· 1 (Заказ может представить только один клиент).

· 0..1 (Корпоративный клиент может иметь, а может не иметь единственного торгового представителя).

· * (Клиент не обязан размещать заказ, а количество заказов не ограничено. Он может разместить ноль или более заказов).

В большинстве случаев, кратности определяются своими нижней и верхней границами, например n..m. Нижняя граница может быть нулем или положительным числом, верхняя – положительное число или * (без ограничения). Кратность 1..1 эквивалентна 1, кратность * является сокращением 0..*.

Если свойство может иметь несколько значений, предпочтительней употреблять множественную форму его имени. По умолчанию элементы с множественной кратностью образуют множество. Если порядок заказов в ассоциации имеет значение, то в конце ассоциации необходимо добавить характеристику { ordered }. Если есть необходимость разрешить повторы, то надо добавить характеристику { nonunique }. Если желательно явным образом показать значение по умолчанию, то можно использовать { unordered} и {unique }. Встречаются также имена для unordered, nonunique, ориентированные на коллекции, такие как { bag} (bag – множество с повторяющимися элементами).

Дискретные кратности, например 2, 4 (означающую 2 или 4 чего-либо) не были широко распространены, и в UML- 2 их уже нет.

Кратность атрибута по умолчанию равна 1, но лучше указывать ее явно, если эта информация важна.

⇐ Предыдущая3456789101112Следующая ⇒

Поделиться: