Указатель на Клиента. Никакой информации относительно интерфейса в данном случае из ассоциаций извлечь нельзя

На рисунке 2.3 приведен другой пример диаграммы классов. Здесь к ассоциациям добавлены стрелки, показывающие направление навигации.

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

В языке UML отсутствие стрелок означает, что направление навигации неизвестно или ассоциация является двунаправленной.

Рисунок 2.3. Диаграмма классов с направлениями навигации

С точки зрения реализации обобщение связано с понятием наследования в языках программирования. Подкласс наследует все методы и поля суперкласса и может переопределять наследуемые методы.

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

На концептуальном уровне атрибут Имя клиента указывает на то, что Клиенты обладают именами.

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

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

<признак видимости> <имя >:<тип> = <значение по умолчанию>

Признак видимости может принимать одно из 3 значений:

«+» - общий, открытый (public);

«-» - закрытый, секретный (private);

«#» - защищенный.

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

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

Синтаксис UML для операций:

<признак видимости><имя>(<список параметров>):<тип выражения возвращающего значение >{<строка свойств>}.

Признак видимости – тот же, что и для атрибутов,

имя – символьная строка,

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

тип выражения возвращающего значения – является необязательной спецификацией и зависит от конкретного языка программирования,

строка свойств – показывает значения свойств, которые применяются к данной операции.

Пример операции: +кредитный Рейтинг():Строка

В концептуальной модели операции должны отражать принципиальное назначение класса, а не его интерфейс.

Операции можно разделить на 2 вида:

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

В процессе построения диаграммы классов на ней отображаются различные ограничения. Например, в примере (рис 2.2) показано, что Заказ может быть сделан одним Клиентом, что Корпоративный Клиент располагает Кредитным лимитом, а Частный Клиент – нет.

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

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

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

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

2.4.7. Классы ассоциаций

Класс ассоциаций – это элемент модели, обладающий свойствами как класса, так и ассоциации. Классы ассоциаций позволяют определять для ассоциаций атрибуты, операции и другие свойства. Класс ассоциаций дает возможность определить дополнительное ограничение, согласно которому двум участвующим в ассоциации объектам может соответствовать только 1 экземпляр класса ассоциаций. Пример класса ассоциаций приведен на рисунке 2.6.

Рисунок 2.6. Класс ассоциаций

Эту же информацию можно отразить другой диаграммой, в которой Работа (класс ассоциаций) представлена как обычный класс (рисунок 2.7). Здесь роль «работодатель» становится производной.

Интерфейс – множество операций, составляющее спецификацию услуг, которые предоставляет класс.

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

Рисунок 2.8. Окно как абстрактный класс

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