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

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

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

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

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

Унифицированный процесс
Унифицированный язык моделирования
Шаблоны проектирования

Унифицированный процесс - это процесс разработки ПО, который обеспечивает упорядоченный поход к распределению задач и обязанностей в организации-разработчике. Унифицированный процесс охватывает весь ЖЦ ПО, начиная с определения требований и заканчивая сопровождением, и представляет собой обобщенный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем.
Неотъемлемой частью унифицированного процесса является UML - язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе ООП.
На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования. Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.

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

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

Объектный подход позволяет создавать системы, которые удовлетворяют пяти признакам хорошо структурированных сложных систем.
Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования. Опыт показал, что при использовании таких языков, как Java, Object Pascal, C++ вне объектной модели, их наиболее сильные стороны либо игнорируются, либо применяются неправильно.
Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что в конце концов ведет к созданию среды разработки. Объектно-ориентированные системы часто получаются более компактными, чем их не объектно-ориентированные эквиваленты. А это означает не только уменьшение объема кода программ, но и удешевление проекта за счет использования предыдущих разработок, что дает выигрыш в стоимости и времени.
Использование объектной модели приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений. Это дает системе возможность развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.
Объектная модель уменьшает риск разработки сложных систем, прежде всего потому, что процесс интеграции растягивается на все время разработки, а не превращается в единовременное событие. Объектный подход состоит из ряда хорошо продуманных этапов проектирования, что также уменьшает степень риска и повышает уверенность в правильности принимаемых решений.
Объектная модель ориентирована на человеческое восприятие мира, или, по словам Робсона, "многие люди, не имеющие понятия о том, как работает компьютер, находят вполне естественным объектно-ориентированный подход к системам".

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

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

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

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

1. Абстрагирование выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.
Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных.
Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу ООП. Существует 4 вида абстракций (перечислены по мере уменьшения полезности).
Абстракция сущности. Объект представляет собой полезную модель некой сущности в предметной области.
Абстракция поведения. Объект состоит из обобщенного множества операций.
Абстракция виртуальной машины. Объект группирует операции, которые либо вместе используются более высоким уровнем управления, либо сами используют некоторый набор операций более низкого уровня.
Произвольна абстракция. Объект включает в себя набор операций, не имеющих друг с другом ничего общего.
Очень важным для абстрагирования понятием является понятие контрактной модели.
Контрактная модель: внешнее проявление объекта рассматривается с точки зрения его контракта с другими объектами, в соответствии с этим должно быть выполнено и его внутреннее устройство (часто во взаимодействии с другими объектами). Контракт фиксирует все обязательства, которые объект-сервер имеет перед объектом-клиентом.
Центральной идеей в контрактной модели является понятие инварианта. Инвариант - это некоторое логическое условие, значение которого (истина или ложь) должно сохраняться. Для каждой операции объекта можно задать предусловия (инварианты предполагаемые операцией) и постусловия (инварианты, которым удовлетворяет операция). Изменение инварианта нарушает контракт, связанный с абстракцией.

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

3. Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.
По мнению Майерса "Разделение программы на модули до некоторой степени позволяет уменьшить ее сложность... Однако гораздо важнее тот факт, что внутри модульной программы создаются множества хорошо определенных и документированных интерфейсов. Эти интерфейсы неоценимы для исчерпывающего понимания программы в целом". В некоторых языках программирования, например в Smalltalk, модулей нет, и классы составляют единственную физическую основу декомпозиции. В других языках, включая Object Pascal, C++, Java модуль - это самостоятельная языковая конструкция. В этих языках классы и объекты составляют логическую структуру системы, они помещаются в модули, образующие физическую структуру системы. Это свойство становится особенно полезным, когда система состоит из многих сотен классов.
Модульность, кроме облегчения поиска нужного описания, позволяет значительно ускорить процесс сборки проекта.

4. Иерархия
Абстракция - вещь полезная, но всегда, кроме самых простых ситуаций, число абстракций в системе намного превышает наши умственные возможности. Инкапсуляция позволяет в какой-то степени устранить это препятствие, убрав из поля зрения внутреннее содержание абстракций. Модульность также упрощает задачу, объединяя логически связанные абстракции в группы. Но этого оказывается недостаточно.
Значительное упрощение в понимании сложных задач достигается за счет образования из абстракций иерархической структуры. Иерархия - это упорядочение абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of"). 

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

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

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

Термин объект или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки:
архитектуры компьютеров (IBM System/38, Intel 432)
объектно-ориентированных операционных систем (StarOS, iMax)
объектно-ориентированных языков программирования (Simula, Smalltalk)
теории БД (модели "сущность-связь")
систем искусственного интеллекта (фреймы)
При разработке ПО термин "объект" впервые был введен Оле-Джоаном Далем, Бьорном Мюрхогом и Кристеном Ныгардом из Норвежского вычислительного центра (г. Осло). Они разработали язык Simula 67, созданый на основе языка Algol-60 и предназначенный для моделирования и описания сложных систем. Однако, по-настоящему широкое внедрение этой идеи произошло при разработке языка Smalltalk в 1990 г. Аланом Кейем из исследовательского центра фирмы Xerox (г. Пало-Альто). В SmallTalk использовались только ОО конструкции.
Объект - нечто, чем можно оперировать. Объект имеет состояние, поведение и идентичность. Структура и поведение сходных объектов определены в общем для них классе. Термины "экземпляр" и "объект" взаимозаменяемы.
Класс - множество объектов с общей структурой и поведением.
Всем вам известны такие понятия как тип и переменная. Исходя из этого, можно сказать, что класс это то же самое, что и тип, а объект – то же самое что и переменная. Вы привыкли, что тип int означает целое число, float – число с плавающей запятой и т.д. Теперь попытаемся несколько расширить этот набор. Представим, что существует такой тип как человек. Переменной в этом случае будет любой конкретный человек. Точно так же мы можем ввести класс стол, объектами которого будут, этот стол и тот стол.

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

Отношение типа “связь”. Мы заимствуем понятие связи у Рамбо (Rumbaugh), который определяет его как "физическое или концептуальное соединение между объектами". Объект сотрудничает с другими объектами через связи, соединяющие его с ними. Другими словами, связь - это специфическое сопоставление, через которое клиент запрашивает услугу у объекта-сервера или через которое один объект находит путь к другому.
Отношение типа “агрегация”. В то время, как связи обозначают равноправные или "клиент серверные" отношения между объектами, агрегация описывает отношения целого и части, приводящие к соответствующей иерархии объектов, причем, идя от целого (агрегата), мы можем придти к его частям (атрибутам). В этом смысле агрегация - специализированный частный случай ассоциации. Агрегация может означать физическое вхождение одного объекта в другой, но не обязательно.
Агрегация иногда предпочтительнее, поскольку позволяет скрыть части в целом. Иногда наоборот предпочтительнее связи, поскольку они слабее и менее ограничительны.
Объект, являющийся атрибутом другого объекта (агрегата), имеет связь со своим агрегатом. Через эту связь агрегат может посылать ему сообщения.
Большинство объектных нотаций вводит понятие диаграммы объектов. Диаграмма объектов - часть системы обозначений объектно-ориентированного проектирования; используется, чтобы наглядно показать объекты и отношения между ними в логическом проекте системы. Часто диаграмму объектов называют диаграммой сотрудничества
Существует еще один вид диаграмм объектов – диаграммы последовательностей (sequence diagram). Диаграммы последовательностей служат тем же целям, что и диаграммы сотрудничества.
Отношение типа “агрегация” между объектами не имеет специального обозначение. Дело в том, что отношению «агрегация» между объектами, соответствует отношение «агрегация» между их классами. Для агрегации между классами существует специальное обозначение.

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

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



Всего между классами существует 6 видов отношений: ассоциация, наследование, агрегация, использование (зависимости), инстанцирование и метакласс.

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





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

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






Дочерние классы обычно расширяют структуру и/или поведение родительского класса. Дочерний класс часто называют подклассом, родительский – суперклассом. У класса обычно бывает два вида клиентов: экземпляры и подклассы.

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



Логическая агрегация




Физическая агрегация (композиция)

4. Инстанцирование. Под обобщенным классом будем понимать класс, служащий шаблоном для создания других классов: шаблон параметризуется другими классами, объектами и/или операциями. Обобщенный класс до создания объектов должен быть инстанцирован. Обобщенные классы используются как контейнерные классы. Термины "обобщенный класс" и "параметризованный класс" взаимозаменяемы.
Инстанцирование - подстановка параметров шаблона обобщенного или параметризованного класса; в результате создается конкретный класс, который может иметь экземпляры.
5. Метакласс - это класс, экземпляры которого суть классы. Метаклассы венчают объектную модель в чисто объектно-ориентированных языках.
6. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.