Что представляет собой процесс в объектно ориентированном подходе
29.Сущность объектно-ориентированного подхода к проектированию ИС
Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира.
По определению признанного авторитета в области объектно-ориентированных методов разработки программ Гради Буча «объектно-ориентированное программирование (ООП) — это методология программирования, которая основана на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса (типа особого вида), а классы образуют иерархию на принципах наследуемости».
Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются
Абстрагирование — это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования.
Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (или, иначе, ограничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта.
Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.
Иерархия — это ранжированная или упорядоченная система абстракций, располагающая их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов — агрегация.
Объектно-ориентированный подход
В объектно-ориентированном подходе основное внимание уделяется захвату структуры и поведения информационных систем в небольшие модули, объединяющие как данные, так и процессы. Основная цель объектно-ориентированного проектирования (OOD) – повысить качество и производительность системного анализа и проектирования, сделав его более удобным для использования.
На этапе анализа ОО-модели используются для заполнения разрыва между проблемой и решением. Он хорошо работает в ситуации, когда системы постоянно проектируются, адаптируются и обслуживаются. Он идентифицирует объекты в проблемной области, классифицируя их с точки зрения данных и поведения.
Модель ОО выгодна следующими способами –
- Это облегчает изменения в системе при низких затратах.
- Это способствует повторному использованию компонентов.
- Это упрощает проблему интеграции компонентов для настройки большой системы.
- Это упрощает проектирование распределенных систем.
Это облегчает изменения в системе при низких затратах.
Это способствует повторному использованию компонентов.
Это упрощает проблему интеграции компонентов для настройки большой системы.
Это упрощает проектирование распределенных систем.
Элементы объектно-ориентированной системы
Давайте рассмотрим характеристики OO System –
- Объекты – объект – это то, что существует в проблемной области и может быть идентифицировано по данным (атрибуту) или поведению. Все материальные объекты (студент, пациент) и некоторые нематериальные объекты (банковский счет) моделируются как объекты.
- Атрибуты – они описывают информацию об объекте.
- Поведение – определяет, что может делать объект. Он определяет операцию, выполняемую над объектами.
- Класс – класс инкапсулирует данные и их поведение. Объекты с похожим значением и целью сгруппированы вместе как класс.
- Методы – Методы определяют поведение класса. Они – не что иное как действие, которое может выполнить объект.
- Сообщение – сообщение – это вызов функции или процедуры от одного объекта к другому. Это информация, отправляемая объектам для запуска методов. По сути, сообщение – это вызов функции или процедуры от одного объекта к другому.
Объекты – объект – это то, что существует в проблемной области и может быть идентифицировано по данным (атрибуту) или поведению. Все материальные объекты (студент, пациент) и некоторые нематериальные объекты (банковский счет) моделируются как объекты.
Атрибуты – они описывают информацию об объекте.
Поведение – определяет, что может делать объект. Он определяет операцию, выполняемую над объектами.
Класс – класс инкапсулирует данные и их поведение. Объекты с похожим значением и целью сгруппированы вместе как класс.
Методы – Методы определяют поведение класса. Они – не что иное как действие, которое может выполнить объект.
Сообщение – сообщение – это вызов функции или процедуры от одного объекта к другому. Это информация, отправляемая объектам для запуска методов. По сути, сообщение – это вызов функции или процедуры от одного объекта к другому.
Особенности объектно-ориентированной системы
Объектно-ориентированная система имеет несколько замечательных функций, которые обсуждаются ниже.
Инкапсуляция
Инкапсуляция – это процесс сокрытия информации. Это просто сочетание процесса и данных в единый объект. Данные объекта скрыты от остальной системы и доступны только через сервисы класса. Это позволяет улучшить или модифицировать методы, используемые объектами, не затрагивая другие части системы.
абстракция
Это процесс выбора или выбора необходимого метода и атрибутов для указания объекта. Основное внимание уделяется существенным характеристикам объекта относительно точки зрения пользователя.
Отношения
Все классы в системе связаны друг с другом. Объекты не существуют изолированно, они существуют во взаимосвязи с другими объектами.
Есть три типа объектных отношений –
- Агрегация – указывает на связь между целым и его частями.
- Ассоциация – при этом два класса связаны или связаны каким-либо образом, например, один класс работает с другим для выполнения задачи или один класс воздействует на другой класс.
- Обобщение – дочерний класс основан на родительском классе. Это указывает на то, что два класса похожи, но имеют некоторые различия.
Агрегация – указывает на связь между целым и его частями.
Ассоциация – при этом два класса связаны или связаны каким-либо образом, например, один класс работает с другим для выполнения задачи или один класс воздействует на другой класс.
Обобщение – дочерний класс основан на родительском классе. Это указывает на то, что два класса похожи, но имеют некоторые различия.
наследование
Наследование – это отличная функция, которая позволяет создавать подклассы из существующего класса, наследуя атрибуты и / или операции существующих классов.
Полиморфизм и динамическое связывание
Полиморфизм – это способность принимать различные формы. Это относится как к объектам, так и к операциям. Полиморфный объект – это тот, кто истинный тип скрывает в супер или родительском классе.
В полиморфной операции операция может выполняться по-разному для разных классов объектов. Это позволяет нам манипулировать объектами разных классов, зная только их общие свойства.
Структурный подход против Объектно-ориентированный подход
Следующая таблица объясняет, как объектно-ориентированный подход отличается от традиционного структурированного подхода –
Структурированный подход | Объектно-ориентированный подход |
---|---|
Работает с нисходящим подходом. | Это работает с восходящим подходом. |
Программа делится на количество подмодулей или функций. | Программа организована по количеству классов и предметов. |
Вызов функции используется. | Передача сообщений используется. |
Повторное использование программного обеспечения невозможно. | Возможность многократного использования. |
Структурное проектирование программирования обычно оставляют до конца фазы. | Объектно-ориентированное проектирование программируется одновременно с другими фазами. |
Структурированный дизайн больше подходит для офшоринга. | Подходит для внутреннего развития. |
Это показывает четкий переход от проектирования к реализации. | Не очень понятен переход от дизайна к реализации. |
Он подходит для систем реального времени, встроенных систем и проектов, где объекты не являются наиболее полезным уровнем абстракции. | Он подходит для большинства бизнес-приложений, проектов разработки игр, которые, как ожидается, будут настраиваться или расширяться. |
Диаграмма DFD & ER моделирует данные. | Диаграмма классов, диаграмма последовательности, диаграмма состояний и варианты использования – все это вносит свой вклад. |
В этом случае проекты могут легко управляться благодаря четко идентифицируемым фазам. | При таком подходе управление проектами может быть затруднено из-за неопределенных переходов между этапами. |
Унифицированный язык моделирования (UML)
UML – это визуальный язык, который позволяет моделировать процессы, программное обеспечение и системы, чтобы выразить дизайн архитектуры системы. Это стандартный язык для проектирования и документирования системы объектно-ориентированным способом, который позволяет техническим архитекторам общаться с разработчиком.
Он определяется как набор спецификаций, созданных и распространяемых Группой управления объектами. UML расширяемый и масштабируемый.
Цель UML – предоставить общий словарь объектно-ориентированных терминов и методов построения диаграмм, который достаточно богат, чтобы моделировать любой проект разработки систем от анализа до реализации.
- Диаграммы – это графическое представление процесса, системы или какой-то ее части.
- Обозначения – это состоит из элементов, которые работают вместе в диаграмме, таких как соединители, символы, заметки и т. Д.
Диаграммы – это графическое представление процесса, системы или какой-то ее части.
Обозначения – это состоит из элементов, которые работают вместе в диаграмме, таких как соединители, символы, заметки и т. Д.
Пример нотации UML для класса
Диаграмма экземпляра – нотация UML
Операции над объектами
Следующие операции выполняются на объектах –
- Конструктор / Деструктор – создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.
- Запрос – Доступ к состоянию без изменения значения, не имеет побочных эффектов. Например, найти адрес конкретного сотрудника.
- Обновление – изменяет значение одного или нескольких атрибутов и влияет на состояние объекта. Например, изменение адреса сотрудника.
Конструктор / Деструктор – создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.
Запрос – Доступ к состоянию без изменения значения, не имеет побочных эффектов. Например, найти адрес конкретного сотрудника.
Обновление – изменяет значение одного или нескольких атрибутов и влияет на состояние объекта. Например, изменение адреса сотрудника.
Использование UML
UML весьма полезен для следующих целей –
- Моделирование бизнес-процесса
- Описание архитектуры системы
- Отображение структуры приложения
- Захват поведения системы
- Моделирование структуры данных
- Построение подробных спецификаций системы
- Зарисовка идей
- Генерация программного кода
Статические Модели
Статические модели показывают структурные характеристики системы, описывают ее системную структуру и делают акцент на тех частях, которые составляют систему.
- Они используются для определения имен классов, атрибутов, методов, подписи и пакетов.
- Диаграммы UML, которые представляют статическую модель, включают диаграмму классов, диаграмму объектов и диаграмму прецедентов.
Они используются для определения имен классов, атрибутов, методов, подписи и пакетов.
Диаграммы UML, которые представляют статическую модель, включают диаграмму классов, диаграмму объектов и диаграмму прецедентов.
Динамические Модели
Динамические модели показывают поведенческие характеристики системы, то есть то, как система ведет себя в ответ на внешние события.
- Динамические модели определяют необходимый объект и то, как они работают вместе с помощью методов и сообщений.
- Они используются для разработки логики и поведения системы.
- Диаграммы UML представляют динамическую модель, включают диаграмму последовательности, диаграмму связи, диаграмму состояний, диаграмму активности.
Динамические модели определяют необходимый объект и то, как они работают вместе с помощью методов и сообщений.
Они используются для разработки логики и поведения системы.
Диаграммы UML представляют динамическую модель, включают диаграмму последовательности, диаграмму связи, диаграмму состояний, диаграмму активности.
Жизненный цикл разработки объектно-ориентированной системы
Он состоит из трех макропроцессов –
- Объектно-ориентированный анализ (ООА)
- Объектно-ориентированный дизайн (OOD)
- Объектно-ориентированная реализация (OOI)
Деятельность по разработке объектно-ориентированных систем
Разработка объектно-ориентированных систем включает в себя следующие этапы –
- Объектно-ориентированный анализ
- Объектно-ориентированный дизайн
- макетирования
- Реализация
- Инкрементальное тестирование
Объектно-ориентированный анализ
Этот этап касается определения системных требований и понимания системных требований для построения модели сценария использования . Вариант использования – это сценарий, описывающий взаимодействие пользователя и компьютерной системы. Эта модель представляет пользовательские потребности или пользовательское представление системы.
Это также включает в себя определение классов и их отношений с другими классами в проблемной области, которые составляют приложение.
Объектно-ориентированный дизайн
Целью этого этапа является разработка и уточнение классов, атрибутов, методов и структур, которые идентифицируются на этапе анализа, пользовательского интерфейса и доступа к данным. На этом этапе также определяются и определяются дополнительные классы или объекты, которые поддерживают реализацию требования.
макетирования
Прототипирование позволяет полностью понять, насколько легко или сложно будет реализовать некоторые функции системы.
Это также может дать пользователям возможность прокомментировать удобство использования и полезность дизайна. Это может дополнительно определить сценарий использования и значительно упростить моделирование сценария использования.
Реализация
Он использует либо компонентную разработку (CBD), либо быструю разработку приложений (RAD).
Компонентно-ориентированная разработка (CBD)
CODD – это промышленный подход к процессу разработки программного обеспечения с использованием различных технологий, таких как инструменты CASE. Разработка приложений переходит от индивидуальной разработки к сборке предварительно созданных, предварительно протестированных, повторно используемых программных компонентов, которые работают друг с другом. Разработчик CBD может собрать компоненты для создания полной программной системы.
Быстрая разработка приложений (RAD)
RAD – это набор инструментов и методов, которые можно использовать для создания приложения быстрее, чем это обычно возможно с помощью традиционных методов. Он не заменяет SDLC, а дополняет его, так как он больше ориентирован на описание процесса и может идеально сочетаться с объектно-ориентированным подходом.
Его задача состоит в том, чтобы быстро и постепенно реализовать приложение, чтобы реализовать дизайн требований пользователя с помощью таких инструментов, как Visual Basic, Power Builder и т. Д.
Инкрементальное тестирование
Разработка программного обеспечения и все его действия, включая тестирование, являются итеративным процессом. Следовательно, это может быть дорогостоящим делом, если мы будем ждать тестирования продукта только после его полной разработки. Здесь появляется инкрементное тестирование, при котором продукт тестируется на разных этапах его разработки.
Все о Process Mining от ProcessMi
Все о технологии Process Mining — кейсы, термины, решения и аналитика. Российский и зарубежный опыт от группы экспертов ProcessMi
Что такое объектно-ориентированный анализ процессов?
Объектно-ориентированный анализ процессов (OCPM) – это новый подход к анализу процессов и управлению их выполнением, который преодолевает рамки традиционных методов и позволяет компаниям лучше визуализировать и анализировать сложность и взаимосвязанность современных бизнес-операций.
Согласно профессору Вил ван дер Аалсту, которого называют «крёстным отцом» процессной аналитики, OCPM представляет собой шаг вперед в области process mining, позволяющий перейти от статического двухмерного представления процессов к динамическому трехмерному.
Чтобы полностью понять значительное улучшение, которое обеспечивает OCPM по сравнению с традиционным интеллектуальным анализом процессов, стоит обсудить интеллектуальный анализ процессов и его ограничения.
Что такое Process Mining?
Process mining, или процессная аналитика – это технология, которая позволяет моделировать, анализировать и в дальнейшем оптимизировать бизнес-процессы в компаниях, государственных учреждениях или других организациях.
Классический подход к исследованию процессов начинается с извлечения данных о событиях из информационных систем, например, ERP, CRM, SCM. Эти системы часто содержат разные части, поставляются разными вендорами и хранят данные в сотнях или даже тысячах таблиц.
Каждый экземпляр процесса называется случаем и может состоять из нескольких событий. Каждый случай можно рассматривать как последовательность событий. Журнал событий можно рассматривать как набор случаев, а случай – как последовательность событий.
Событие может быть определено несколькими атрибутами, но для интеллектуального анализа процессов требуется минимум три:
- идентификатор случая;
- действие;
- отметка времени, когда произошло событие
Другая информация может быть включена, но не обязательна. Если взять в качестве примера процесс заказа на продажу, дополнительно могут указываться название продукта, цена, количество и т.д.
Имея под рукой журналы событий, можно применять к данным инструменты процессной аналитики и обнаруживать пути, по которым реализуются процессы. Так называемый «идеальный вариант выполнения процесса» (happy path) включает в себя наиболее частые начальные и завершающие действия, а также другие промежуточные шаги в бизнес-процессе.
Если посмотреть на сценарии, которые встречаются реже, становится очевидными различные варианты и циклы внутри процесса, что доказывает: в действительности большинство бизнес-процессов намного сложнее, чем идеализированное – эталонное – представление о них.
Рамки традиционной процессной аналитики
Хотя инструменты классического process mining весьма мощные, по словам профессора ван дер Аалста, они несколько ограничены Это связано с тем, как работают современные бизнес-процессы и как хранятся связанные с ними данные.
Классическая модель процесса предполагает понятие одного случая и считается, что один случай (или экземпляр процесса) происходит изолированно. Однако в реальности чаще иначе.
Например, отдел продаж может отслеживать свои процессы. Когда применяются традиционные инструменты process mining к заказу, рассматривается только один объект. Изучается, как он проходит через отдел, а с помощью этой информации можно определить области для улучшения процесса и внести изменения, чтобы закрыть пробелы.
Однако продажи не работают в вакууме. События влияют на другие отделы/службы/департаменты, такие как закупки, производство, склад, распределение, финансов и так далее. Кроме того, разные структурные единицы используют разные объекты. Финансы могут использовать счета-фактуры, закупки могут использовать заказы на покупку и так далее. Все эти объекты связаны.
Именно это провоцирует три ограничения традиционной процессной аналитики:
- Извлечение и преобразование данных чаще всего болезненны и должны повторяться.
Классический анализ процессов требует извлечения данных из многотабличных реляционных баз данных исходной ИС в простой журнал событий, где каждое событие относится к случаю, действию и метке времени. Например, в примере с продажами каждый случай – конкретный заказ, и можно было бы получить ответ на вопрос «Наиболее распространенная причина блокировки заказа?» Однако, если требуется понять какие клиенты своевременно оплачивают счета, необходим другой журнал – со счетами-фактурами. Таким образом, необходимо будет вернуться к данным и сделать новое извлечение, что может быть трудоемко, сложно и болезненно.
- Взаимодействия между объектами не фиксируются.
При извлечении данных из реляционной БД и объединении их в журнал событий, где каждое – отдельный случай, теряются взаимодействия между объектами. Аналогичным образом, любые модели процессов, которые создаются на основе сведенных данных, описывают жизненный цикл бизнес-процесса только изолированно. Чтобы добиться полной прозрачности, важно понимать взаимосвязь между всеми объектами и типами задействованных объектов.
- 3D-реальность «втискивается» в 2D-журналы событий и модели.
При традиционном анализе процессов журнал событий создается для каждого типа объекта и анализируется отдельно. Например, для счетов клиентов – чтобы оценить дебиторскую задолженность, для счетов поставщиков – чтобы проанализировать кредиторскую задолженность, для заказов на покупку для анализа процесса закупок.
Даже если эти 2D-журналы событий связаны, трехмерные объектно-ориентированные данные и модели все равно «сжимаются» в двумерные. Такое «выравнивание» данных приводит к непреднамеренному дублированию или ошибочным трактованиям полученной информации.
Что такое объектно-ориентированный анализ процессов (OCPM)?
В 2021 году профессор ван дер Аалст писал, что «технология интеллектуального анализа процессов должна приблизиться к истинной структуре процессов и систем». Объектно-ориентированный анализ процессов предназначен для дальнейшего преобразования путем создания моделей процессов, которые более точно отражают объектно-ориентированный характер сквозных бизнес-процессов.
Объектно-ориентированный анализ процессов устраняет ограничения традиционного анализа процессов, а также проблемы конвергенции и дивергенции, не определяя события как связанные с одним случаем. OCPM использует объектно-ориентированный журнал событий (OCEL), который позволяет связать событие с несколькими объектами (например, с заказами на продажу, производственными заказами и т.п.). Вместо использования данных о событиях, ориентированных на прецеденты, как в традиционном анализе процессов, OCPM использует данные о событиях, ориентированные на объекты.
Простой способ описать OCEL – использовать две таблицы: одну для событий, а другую для объектов. В таблице событий каждое событие имеет идентификатор, действие, отметку времени, связанные объекты и, возможно, другие атрибуты события. В таблице объектов каждая строка определяет объект и содержит идентификатор, тип, возможно, другие описательные атрибуты (например, размер, вес, адрес и т.п.).
В отличие от традиционного журнала событий, ориентированный на объекты фиксирует отношения между несколькими из них. Объектно-ориентированный же анализ БП позволяет рассматривать процесс под любым углом.
Преимущества объектно-ориентированного интеллектуального анализа процессов
OCPM устраняет ограничения и предлагает множество преимуществ по сравнению с традиционным подходом:
- Извлечение данных выполняется только один раз, что позволяет выбрать представление, объекты и действия для анализа.
- Взаимодействия между объектами регистрируются в журналах событий, ориентированных на объекты.
- Создание трехмерных журналов событий и моделей процессов, которые лучше отражают реальность современных бизнес-операций и позволяют лучше понять бизнес-процессы.
Сущность объектно-ориентированного подхода и его составляющие. Объектная модель. Объекты и классы
Тема: «Сущность объектно-ориентированного подхода и его составляющие
Тема: «Сущность объектно-ориентированного подхода и его составляющие. Объектная модель. Объекты и классы»
Объектно-ориентированный подход — это подход при котором требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области
Объектно-ориентированный подход — это подход при котором требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.
С ООП тесно связано объектно-ориентированное проектирование или моделирование. Если программирование направленно на правильное и эффективное использование контекстных языков, то проектирование направленно на правильное и эффективное структурирование сложных систем. Наиболее популярными методологиями, поддерживающими данный подход, в настоящий момент являются:
Унифицированный процесс
Экстремальное программирование
Гибкое моделирование
Базовым средством фиксации (документирования) результатов проектирования является
Базовым средством фиксации (документирования) результатов проектирования является Унифицированный язык моделирования (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
Термин объект или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки:
архитектуры компьютеров (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. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.
Отношения между классами