Модуль-1-шпора-ТРПО

Если рассматривать наш
пример с т.з. реализации, то предполагается, что
между связанными классами существуют указатели в
обоих направлениях. ДК показывает нам, что Заказ
содержит поле, представляющее собой совокупность
указателей на Строки Заказа и указатель на Клиента.
Никакой информации относительно интерфейса в данном
случае из ассоциаций извлечь нельзя.
На рисунке 2.3 приведен другой пример
диаграммы классов. Здесь к ассоциациям добавлены
стрелки, показывающие направление навигации.
Для концептуальных диаграмм направление
навигации не важно, оно имеет значение для диаграмм,
построенных с т.з. спецификации и реализации. С т.з.
спецификации на ДК видно, что Заказ обязан ответить на
вопрос, к какому Клиенту он относится, а у Клиента такой
ответственности нет. На диаграмме реализации это
означает, что Заказ содержит указатель на Клиента, но
Клиент не указывает на Заказ. Направление навигации с
т.з. спецификации и реализации м.б. различным.
В языке UML отсутствие стрелок означает,
что направление навигации неизвестно или ассоциация
является двунаправленной.
операции, не изменяющие состояние
класса, они называются запросами.
Их
результат
–некоторое
извлекаемое из класса значение.
2Операции,
изменяющие
наблюдаемое состояние объекта –
модификаторы.
В языке UML существует различие между
операцией и методом. Операции – это услуги, которые
можно запросить у любого объекта класса для изменения
поведения, а метод – это реализация операции.
1-
2.4.5. Ограничения
В процессе построения диаграммы классов на
ней отображаются различные ограничения. Например, в
примере (рис 2.2) показано, что Заказ может быть сделан
одним Клиентом, что Корпоративный Клиент располагает
Кредитным лимитом, а Частный Клиент – нет.
С помощью конструкций ассоциаций,
атрибутов и обобщения можно показать наиболее важные
ограничения, но не все. Остальные ограничения тоже
нужно отобразить. В языке UML нет строгого синтаксиса
описания ограничений, кроме их помещения в фигурные
скобки. Можно записывать ограничения на естественном
языке, чтобы их было проще понимать, или использовать
фрагменты программного кода.
2.4.6. Агрегирование и композиция
Рисунок 2.3. Диаграмма классов с
направлениями навигации
течении которого каждый служащий работает в каждой
Компании. Это можно сделать, дополнив ассоциацию
атрибутом «интервал Времени». Можно было бы включить
этот атрибут Личность, но на самом деле он характеризует не
Личность, а ее связи с Компанией, которая будет меняться при
смене работодателя.
Эту же информацию можно отразить другой
диаграммой, в которой Работа (класс ассоциаций)
представлена как обычный класс (рисунок 2.7). Здесь роль
«работодатель» становится производной.
Простая ассоциация между двумя классами
отражает структурное отношение между равноправными
классами. Но иногда приходится моделировать отношение
типа «часть-целое», в котором один из классов имеет
более высокий ранг (целое) и состоит из нескольких
меньших по рангу (частей). Отношение такого типа
называются агрегацией или агрегированием. Агрегация
является частным случаем ассоциации. Агрегирование это вид ассоциации, описывающий отношения между
целым и частью. Агрегирование – это чисто
концептуальное отношение, оно лишь позволяет отличить
«целое» от «части», но не изменяет смысла навигации по
ассоциации между целым и его частями не накладывает
никаких ограничений на соотношение времени жизни
целого и частей. Существует вариация простого
агрегирования – композиция.
Рисунок 2.7. Преобразование класса ассоциаций в
обычный класс
2.4.8.Интерфейсы и абстрактные классы
Интерфейс – множество операций, составляющее
спецификацию услуг, которые предоставляет класс.
Одно из замечательных свойств ОО - разработки
заключается в том, что можно изменять интерфейсы классов
независимо от их реализации. Интерфейс в чистом виде
представляет собой класс без каких-либо деталей реализации
и поэтому содержит определения только операций, но не тела
методов и поля. Интерфейсы часто определяют с помощью
абстрактных классов. Абстрактный класс – это класс, для
которого нельзя непосредственно создать экземпляры
объектов. Примером такой ситуации является текстовый
редактор, изображенный на рисунке 2.8.
2.4.2. Обобщения
Обобщения - это отношения, которые связывают
обобщенные классы (суперклассы) со
специализированными (подклассами). Подклассы
наследуют структуру и поведение суперкласса. В
отношениях обобщения экземпляры подкласса могут
использоваться вместо экземпляров суперкласса, т.е.
потомок может замещать родителя.
Рисунок 2.8. Окно как абстрактный класс
Чтобы сделать редактор платформо-независимым,
мы определяем платформо-независимый абстрактный класс
Окно. Этот класс не содержит операций, он определяет только
интерфейс для текстового редактора. Платформо-зависимые
классы могут быть использованы по вашему усмотрению. Имя
абстрактного класса в языке UML должно выделяться
курсивом или можно использовать дескриптор {абстрактный}.
Абстрактные классы и интерфейсы подобны, в
частности потому, что ни у тех, ни у других нет
непосредственных экземпляров. И те, и другие позволяют
определить интерфейс и отложить его реализацию на более
позднее время. Но все же между ними имеется достаточно
различий, чтобы считать их отдельными элементами
моделирования. У абстрактного класса могут быть атрибуты, а
у интерфейса – нет. Абстрактные классы позволяют
доопределить реализацию некоторых методов, а интерфейсы
требуют отложить определение всех методов.
В нашем примере обобщенный класс Клиент
(суперкласс) содержит одинаковые характеристики
Частного и Корпоративного клиентов (подклассов). На
концептуальном уровне подкласс является особым
видом суперкласса. Все, что известно о суперклассе,
справедливо и для полкласса.
В модели спецификации смысл обобщения заключается
в том, что интерфейс подкласса должен включать все
элементы интерфейса суперкласса.
С точки зрения реализации обобщение
связано с понятием наследования в языках
программирования. Подкласс наследует все методы
и поля суперкласса и может переопределять
наследуемые методы.
2.4.3. Атрибуты
Атрибут – это именованное свойство класса,
включающее описание множества значений, которые
могут принимать экземпляры этого свойства. Класс может
иметь любое число атрибутов или не иметь их совсем.
Атрибут представляет некоторое свойство, общее для всех
объектов данного класса Атрибут является абстракцией
данных объекта или его состояния.
На концептуальном уровне атрибут Имя
клиента указывает на то, что Клиенты обладают именами.
На уровне спецификаций этот атрибут
указывает на то, что объект Клиент может сообщить свое
имя и обладает некоторым механизмом определения
имени.На уровне реализации класс Клиент содержит поле,
соответствующее его имени.
На диаграммах обозначение атрибута может
включать имя атрибута, тип и значение, присваиваемое по
умолчанию. Синтаксис UML для атрибутов:
<признак видимости> <имя >:<тип> =
<значение по умолчанию>
Признак видимости может принимать одно из
3 значений:
«+» - общий, открытый (public);
«-» - закрытый, секретный (private);
«#» - защищенный.
Видимость определяют для того, чтобы
скрыть детали реализации атрибута и показать только те
его особенности, которые необходимы для выполнения
обязанностей, продекларированных абстракцией. При
использовании видимости нужно применять правила того
языка, на котором будет написана программа, т.к. разные
языки программирования по-разному интерпретируют
понятие «видимость»
2.4.4. Операции
Операцией называется реализация услуги,
которую можно запросить у любого объекта класса. Иначе
говоря, операция – это абстракция того, что позволено
делать с объектом.
Синтаксис UML для операций:
<признак видимости><имя>(<список параметров>):<тип
выражения
возвращающего
значение
>{<строка
свойств>}.
Признак видимости – тот же, что и для
атрибутов,
имя – символьная строка,
список
параметров
–
необязательные
аргументы, синтаксис которых совпадает с синтаксисом
атрибутов,
тип выражения возвращающего значения –
является необязательной спецификацией и зависит от
конкретного языка программирования,
строка свойств – показывает значения
свойств, которые применяются к данной операции.
Пример
операции:
+кредитный
Рейтинг():Строка
В концептуальной модели операции должны
отражать принципиальное назначение класса, а не его
интерфейс.
Операции можно разделить на 2 вида:
Рисунок 2.4 Агрегация
Рисунок
2.5.
обозначение для композиции
и композиция
Альтернативное
Композиция – это форма агрегирования, в
которой целое владеет своими частями, имеющими
одинаковое время жизни. В случае отношения
композиции объект в любой момент времени может быть
частью только одного целого, например, рама
принадлежит только одному окну. При простом
агрегировании
«часть»
может
принадлежать
одновременно нескольким «целым», например, объект
«стена»может принадлежать нескольким объектам
«комната».
Примеры агрегирования и композиции
приведены на рисунках 2.4 и 2.5. Многоугольник состоит
из упорядоченной совокупности Вершин. Эти Вершины
могут изменяться при изменении многоугольника,
поэтому
применяется
агрегация.
Композиция
используется для связи между Многоугольником и
графическим объектом. Графический объект содержит
такие атрибуты, как «Цвет» и «Текстура». Он
рассматривается отдельно от Многоугольника, т.к. такой
набор атрибутов
могут иметь многие графические
объекты Отношения между Многоугольником и
Графическим объектом определены как композиция,
следовательно, Графический объект создаётся и
уничтожается вместе с данным Многоугольником и не
может быть изменен.
Композицию можно обозначать по-другому,
включая символы частей внутрь символа целого (рисунок
2.5). Эта нотация используется, если нужно подчеркнуть
отношения между частями, действительные только в
контексте целого.
2.4.7. Классы ассоциаций
Класс ассоциаций – это элемент модели, обладающий
свойствами как класса, так и ассоциации. Классы
ассоциаций позволяют определять для ассоциаций
атрибуты, операции и другие свойства. Класс
ассоциаций дает возможность определить
дополнительное ограничение, согласно которому двум
участвующим в ассоциации объектам может
соответствовать только 1 экземпляр класса
ассоциаций. Пример класса ассоциаций приведен на
рисунке 2.6.
Рисунок 2.6. Класс ассоциаций
Из диаграммы (рис.2.6.) видно, что Личность
может работать только в одной Компании. При этом
необходимо хранить информацию о периоде времени, в
1