# Лекция 2. МОДЕЛИ И ИХ РОЛЬ В СОЗДАНИИ СИСТЕМ. ОБЪЕКТНАЯ МОДЕЛЬ

Одна из основных проблем при создании больших и сложных систем, в том числе ПО, - это проблема сложности. Виды сложности: техническая сложность и сложность управления. Техническая сложность может быть вызвана:

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

Сложность управления порождается следующими причинами:

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

Подход к решению этой проблемы основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО. Принципы декомпозиции:

- количество связей между подсистемами должно быть минимальным («низкая связанность» или «слабое зацепление» - Low Coupling);
- степень взаимодействия внутри каждой подсистемы должна быть максимальной («сильная связность» или «высокая прочность» - High Cohesion).

При разбиении системы на подсистемы необходимо добиться выполнения следующих условий:

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

Следование этим правилам увеличивает понятность и модифицируемость создаваемого ПО.

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

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

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

Архитектура ПО многомерна, поскольку различные специалисты работают с её различными аспектами. Различные представления архитектуры служат различным целям (модель «4+1»):

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

Среди 5-ти представлений особое место занимает представление вариантов использования, поскольку оно используется при управлении разработкой, служит своего рода скелетом проекта. В общем случае говорят о модели «N+1», имея в виду что перечень архитектурных представлений может варьироваться, но представление вариантов использования входит в него обязательно.

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

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

Гради Буч:

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

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

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

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

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

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

В процессе создания ПО используются следующие виды моделей:

- модели деятельности организации (или модели бизнес-процессов):
- модели "AS-IS" ("как есть"), отражающие существующее положение;
- модели "AS-TO-BE" ("как должно быть"), отражающие представление о новых процессах и технологиях работы организации;
- модели проектируемого ПО, которые строятся на основе модели "AS-TO-BE", уточняются и детализируются до необходимого уровня.

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

Для облегчения труда разработчиков и автоматизированного выполнения некоторых рутинных действий используются CASE-средства (Computer Aided Software Engineering). В настоящее время CASE-средства обеспечивают поддержку большинства процессов жизненного цикла ПО, что позволяет говорить о CASE-технологиях разработки ПО. CASE-технология - это совокупность методов проектирования ПО и инструментальных средств для моделирования предметной области, анализа моделей на всех стадиях ЖЦ ПО и разработки ПО.

Объектная модель является концептуальной базой объектно-ориентированного подхода (ООП).

Проблемы, стимулировавшие развитие ООП:

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

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

Краткая история ООП:

- 1967: язык Simula - 1ый среди объектно ориентированных;
- 1970-е: Smalltalk - получил довольно широкое распространение;
- 1980-е: Теоретические основы, C++, Objective-C;
- 1990-е: Методы OOA и OOD (Booch, OMT, ....), появился язык Java;
- 1997: Принят стандарт OMG UML 1.1.

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

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

- абстрагирование;
- инкапсуляция;
- модульность;
- иерархия.

Дополнительные принципы:

- типизация;
- параллелизм;
- устойчивость (persistence).

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

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

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

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

Тип - точная характеристика некоторой совокупности однородных объектов, включающая структуру и поведение.

Типизация - способ защититься от использования объектов одного класса вместо другого, или, по крайней мере, управлять таким использованием.

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

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

Устойчивость - способность объекта сохранять свое существование во времени и/или пространстве (адресном, в частности при перемещении между узлами вычислительной системы). В частности, устойчивость объектов может быть обеспечена за счет их хранения в базе данных.

Переходим к основным понятиям объектно-ориентированного подхода (элементам объектной модели). К ним относятся: объект; класс; атрибут; операция; полиморфизм; наследование; компонент; пакет; подсистема; связь.

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

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

Атрибут - поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный). Мощность (кратность) атрибута показывает, сколько значений хранится в одном экземпляре атрибута. Если кратность больше 1, то атрибут описывает массив, список... Мощность указывается в профиле атрибута, примеры: name: string [1]; phones: string [*]. Описаны атрибуты: имя - строка; телефоны - список строк. По умолчанию кратность - 1.

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

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

Результат операции зависит от текущего состояния объекта. Виды операций:

- Операции реализации (implementor operations) - реализуют требуемую функциональность.
- Операции управления (manager operations) управляют созданием и уничтожением объектов (конструкторы и деструкторы).
- Операции доступа (access operations) - так называемые, get-теры, set-теры - дают доступ к закрытым атрибутам.
- Вспомогательные операции (helper operations) - непубличные операции, служат для реализации операций других видов.

Объект может быть абстракцией некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект).

Сравнение архитектур традиционной и ОО-системы:

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

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

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

Компонент представляет собой физическую реализацию проектной абстракции и может быть: компонентом исходного кода (cpp-шник); компонентом времени выполнения (dll, ActiveX и т. п.); исполняемый компонентом (exe-шник). Компонент обеспечивает физическую реализацию набора интерфейсов. Компонентная разработка (component-based development) представляет собой создание программных систем, состоящих из компонентов (не путать с объектно-ориентированным программированием (ООП).

ООП - способ создания программных компонентов, базирующихся на объектах.

Компонентная разработка - технология, позволяющая объединять объектные компоненты в систему.

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

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

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

Между элементами объектной модели существуют различные виды связей.

Соединение (link) - физическая или концептуальная связь между объектами, позволяющая им взаимодействовать.

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

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

Агрегация- более сильный тип ассоциативной связи между целым и его частями (пример: автомобиль и мотор). Композиция - усиленная агрегация, когда часть не может существовать без целого (пример: университет, факультет, кафедра). Композиция и агрегация транзитивны, в том смысле, что если B является частью A, и C является частью B, то C также является частью A (но на диаграмме связи, возникающие за счет транзитивности, явно не изображаются).

Соединения, являющиеся экземплярами композиций или агрегаций также изображаются с ромбами на полюсах.

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

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

Атрибут класса также может быть отображен на диаграмме составной структуры как прямоугольник содержащийся внутри класса.

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

Мощность Значение

1 Ровно один

0..* или * Ноль или больше

1..* Один или больше

0..1 Ноль или один

2..4 Заданный диапазон

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

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

Обратите внимание, как переместились мощности связей.

В UML 2.0 к объектной модели добавлено понятие N-арной ассоциации (для каждой комбинации объектов не более одной связи):

На рисунке представлена тернарная ассоциация и класс-ассоциация, связывающая проект, программистов, занятых в проекте, и языки, на которых они программируют в проекте. Некоторым аналогом тернарной ассоциации является реляционное отношение над тремя доменами (таблица со столбцами проект, программист, язык). Экземплярами N-арных ассоциаций являются N-арные соединения. Так, программистка Мэри в одном проекте пишет на Коболе, а в другом на Си. Заметим, что мощности на концах тернарной ассоциации не воспрещают Мэри писать в одном и том же проекте на разных языках (хотя на диаграмме объектов такое не показано). Единственное ограничение, наложенное в данном случае, - два разных тернарных соединения не могут связывать одну и ту же тройку объектов - например: Мэри, проект accountingSystem и Кобол.

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

В объектно-ориентированных языках N-арные ассоциации не поддерживаются

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

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

Полюса ассоциаций с мощностью «много» имеют еще две характеристики: упорядоченность связываемых объектов и повторяемость (т. е. образуют ли связываемые объекты множество или мультимножество). Различные сочетания этих характеристик образуют четыре типа полюсов: множества {set} (тип полюса по умолчанию), упорядоченные множества {ordered}, мультимножества {bar} и последовательности {sequence}:

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

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

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

- в сигнатуре операции одного класса есть аргумент - объект другого класса;
- в методе одного класса есть локальный объект другого класса;
- результатом операции одного класса является экземпляр другого класса.

Зависимость между пакетами возникает при импорте описаний элементов одного пакета в другой.

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

Общие атрибуты, операции и/или отношения отображаются на верхнем уровне иерархии. Заметим, что ассоциации класса-предка наследуются классами потомками, т. е. экземпляры потомков могут иметь соединения того же рода, что и экземпляры родительского класса. Действует принцип подстановки Лисковой (Liskov substitution principle - LSP), по которому любое утверждение, справедливое для экземпляров класса, сохраняет справедливость для экземпляров всех его подклассов. Например, из LSPследует, что экземпляр подкласса подкласса (класса «внука») может рассматриваться как экземпляр подкласса или экземпляр исходного класса (своего «деда»).

В объектной модели наследование может быть множественным. На связи наследования могут накладываться ограничения. Например, если необходимо, множественное наследование внутри некоторой иерархии классов может быть запрещено (над связью указывается ключевое слово: {disjoint}). Можно ограничить набор классов-наследников на некотором уровне иерархии наследования указав ограничение {comlpete}.

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

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

### Литература к лекции 2

- Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. 3-е изд. - М.: Вильямс, 2008. - Часть I.
- Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. - М.: Финансы и статистика, 2005. - Глава 2.
- Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. - СПб.: Питер, 2006. - Главы 2-3.
- Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е изд.: Пер. с англ. - М.: Вильямс, 2004. - Глава 1.