· Система управления каналами

· Система управления кэшированием объектов

· Создание основных объектов

· Клонирование объектов

· Переопределение поведений и действий

· Изменение данных в объектах

· Журнализация изменений в объектах

· Выполнение действий (knowhow)

2. Уточнение методов решения задачи

2.1 Наследование

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

Совокупности свойств объекта в объектно-ориентированной базе данных уделя­ет­ся большее внимание, чем во многих объектно-ориентированных языках прог­рам­миро­ва­ния, поскольку они являются также целью запросов. Объект=состояние+поведение. Чаще всего существует только одна иерархия наследования. Этот подход перешел и в C++. Однако, возможно разделение иерархий наследования данных и наследования по­ве­де­ний. Не всегда желательно иметь точно такую же иерархию наследования пове­де­ния, как и иерархию наследования свойств. Разделение этих двух иерархий повышает возможности переиспользования (reuse) поведений.

Значение переиспользования поведений

Предположим, мы имеем класс Студент и хотим создать класс Аспирант. Чтобы стать аспирантом, человек должен сначала получить высшее образование как студент. В общем случае экземпляры этих классов различны. Мы не можем наследовать Аспирант от Студент, т.к. аспирант не является студентом. В противном случае, мы имели бы право рассматривать аспиранта как экземпляр класса Аспирант и, с тем же правом, как экземпляр класса студент. Тем не менее, оба класса обладают общими атрибутами, таки­ми как: имя, адрес, номер_личной_карточки, а также большинством общих пове­де­ний. Это обстоятельство побуждает создать класс Аспирант, унаследовав свойства и по­веде­ния Студента. Однако, хотя экземпляры класса Аспирант будут подмножеством всех экземпляров класса Студент (т.к. все аспиранты были студентами, но не все студенты стали аспирантами), это представление будет некорректно с точки зрения моде­лиро­вания ситуации в реальном мире.

На рисунке представлено дерево наследования:

Рис. 2: Диаграмма наследования

Свойства классов Студент и Аспирант наследуются от класса Учащийся.

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

Эталоны наследования: классы или прототипы?

В системе отсутствуют классы и типы. Роль класса может брать на себя любой объект, называемый объектом-образцом. Такой вид наследования называется насле­до­ванием на основе прототипов.

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

Независимо от модели наследования (классы или прототипы) существует две раз­личные стратегии реализации механизма наследования: делегирование и конкате­нация.

Способ наследования: делегирование или конкатенация?

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

И конкатенация, и делегирование имеют свои достоинства и недостатки. Делеги­рование обеспечивает возможность гибкого распространения изменений: любое измене­ние свойств родителя автоматически отражается на потомках. Подход, использующий конкатенацию, допускает изменение свойств родителей и потомков независимо друг от друга, что также может быть полезно во многих ситуациях. Делегирование обычно тре­бует меньших затрат по памяти, в то время как конкатенация является более эффек­тивной по времени. Simula и C++ являются примерами языков, которые реализуют на­следование на основе классов с использованием делегирования. В Smalltalk реализовано наследование на основе прототипов с использованием делегирования.

Обоснование избранного механизма наследования

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

Система поддерживает множественное наследование. Необходимость множест­венного наследования остается предметом горячих споров. Практика говорит о том, что «множественное наследование играет роль парашюта: в нем нет постоянной необхо­димости, но если он вдруг понадобился, то большое счастье иметь его под рукой»[8].

Определение родства

Остается важный вопрос: как определить, является ли объект потомком другого объекта? Разделение наследований состояния и поведения приводит к тому, что слово «потомок объекта» обретает двойственное значение. С одной стороны, это потомок по данным, с другой стороны, это потомок по поведению.

На самом деле, в чистой объектно-ориентированной системе данные объектов надежно защищены от вмешательства пользователя через механизм инкапсуляции. Доступ к данным производится через методы. Таким образом, родство объектов следует определять исключительно через их интерфейсы. В системе на основе классов обычно строится дерево наследования. В системе на основе прототипов с конкатенацией опре­деление родства достигается за счет операций пересечения интерфейсов. Поведение объекта составляют методы, хранящиеся в объекте-множестве, а значит для опреде­ления родства необходимо выполнить операцию пересечения множеств. Если получив­шийся в результате пересечения интерфейс совпадает с интерфейсом одного из двух сравниваемых объектов, то другой объект – его потомок. Фактически, это алгоритм оп­ределения общего предка двух объектов. Использование множеств для хранения интер­фейсов позволяет взглянуть на операцию наследования конкатенацией как на операцию слияния множеств.

2.2 Инкапсуляция

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

Интерпретация этого принципа для баз данных состоит в том, что объект инкапсулирует и программу и данные.

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

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

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