Содержание к диссертации
Введение
1. Введение 7
2. Инструментальные средства программирования (обзор) 12
2.1. Накопление и использование программистских знаний 12
2.1.1. Идеи, на которых основывается накопление и использование программистских знаний 12
2.1.2. Системы, поддерживающие накопление и использование программистских знаний 16
2.1.3. Практическое применение средств накопления и использования программистских знаний 21
2.1.4. Применение логического аппарата 24
2.1.5. Инструментальные средства широкого спектра 27
2.2. Компонентная объектная модель JavaBeans 29
2.2.1. Введение 29
2.2.2. Коротко о языке Java 30
2.2.3. Основные понятия модели JavaBeans 32
2.2.4. Афиширование и выяснение интерфейсов 35
2.2.5. Сохранение компонентов в долговременной памяти 42
2.2.6. Компоненты и контейнеры 45
2.2.7. Обмен данными 46
2.2.8. Агрегирование интерфейсов 51
2.3. Современные объектно-ориентированные СУБД 53
2.3.1. Введение 53
2.3.2. СУБД P0STGRES 53
2.3.3. Объектно-ориентированные возможности INFORMIX-Universal Server 62
2.3.4. СУБД ObjectStore 65
3. Основные понятия и компоненты системы ЭСКОРТ - з 3.1. Нетекстовое представление программы 70
3.2. Объектно-ориентированная СУБД 72
3.3. Абстрактный структурно-текстовый редактор программ . 74
3.4. Инкрементальный анализ программ 75
4. Язык широкого спектра ЭСКОРТ 78
4.1. Данные 78
4.1.1. Введение 78
4.1.2. Механизм типизации. Контроль типов. Описания объектов 79
4.1.3. Механизм типизации. Генераторы типов 81
4.1.4. Предопределенные типы и генераторы типов 86
4.1.5. Пакеты 98
4.1.6. Бремя жизни объектов 99
4.2. Управляющие структуры 100
4.2.1. Традиционные управляющие структуры 100
4.2.2. Оператор вызова процедуры (сопрограммы) и оператор возврата 100
4.2.3. Цикл ДНЯ 101
4.2.4. Исключительные ситуации 101
4.2.5. Применение механизма исключительных ситуаций: выход из цикла 101
5. Объектно-ориентированная СУБД как компонент инструментальной среды программирования 102
5.1. Объектно-ориентированная система управления базами данных комплекса ЭСКОРТ 102
5.1.1. Введение 102
5.1.2. Модуль как объект нижнего уровня СУБД 102
5.1.3. Проекты, версии и модули в версиях 109
5.1.4. Примеры работы с проектами, версиями и модулями в версиях 117
5.2. О достаточных условиях бесконфликтной синхронизации процессов - клиентов объектно-ориентированной СУБД 121
5.2.1. Введение 121
5.2.2. Принцип неуничтожения информации 123
5.2.3. Синхронизация процессов - компонентов одной программной системы 125
5.2.4. Синхронизация независимых программных систем 126
5.2.5. О реалистичности сформулированных достаточных условий бесконфликтной синхронизации 128
6. Многоплановая объектная модель и ее приложения 131
6.1. Введение 131
6.2. Объектная модель и ее оболочка 131
6.2.1. Основные понятия многоплановой объектной модели и ее оболочки 131
6.2.2. Внутренний слой оболочки 133
6.2.3. Передача сообщений объектам 135
6.2.4. Некоторые обобщения 137
6.2.5. Некоторая конкретизация 138
6.3. Приложения многоплановой объектной модели 139
6.3.1. Настраиваемый структурно-текстовый редактор 139
6.3.2. Гипертекстовая среда 143
6.3.3. Многоплановые электронные бланки 146
6.4. Заключение 149
7. Настройка инструментальной системы ЭСКОРТ на обработку HTML-документов 150
7.1. Введение 150
7.2. Сведения о языке HTML 151
7.3. Средства настройки ЭСКОРТа 155
7.4. Язык настройки 157
7.4.1. Основные понятия языка настройки 157
7.4.2. Лексические элементы языка настройки 162
7.4.3. Обработка синтаксических ошибок 164
7.4.4. Правила видимости символов 164
7.4.5. Структурное редактирование, пользовательский интерфейс
7.5. База Данных ЭСКОРТа 165
7.6. Заключение 167
8. Аппарат схем 169
8.1. Понятие схемы программы 169
8.2. Пример схемы программы 170
8.3. Механизм подстановки схемы 171
8.4. Пример подстановки схемы 172
8.5. Представление схем программ в БД ЭСКОРТа 175
9. О постановке задачи разграничения доступа в распределенной объектной среде 183
9.1. Введение 183
9.2. Недостатки существующих моделей разграничения доступа
с точки зрения объектного подхода 183
9.3. Основные предположения 185
9.4. Формальная постановка задачи 186
9.5. Первый уровень конкретизации 1 9.5.1. Политика безопасности контейнера 187
9.5.2. Ограничения на вызываемый метод 187
9.5.3. Ограничения на вызывающий метод 187
9.5.4. Добровольно налагаемые ограничения 188
9.5.5. Условие допустимости вызова 188
9.5.6. Внутренние и внешние вызовы 189
9.6. Оптимизация вычисления ГГРД 190
9.6.1. Однократное вычисление предикатов 190
9.6.2. Уменьшение числа членов ПРД
9.7. Обработка ПРД 191
9.8. Второй уровень конкретизации - реализация традиционных моделей разграничения доступа 1 9.8.1. Реализация дискреционной модели 192
9.8.2. Реализация мандатной модели 193
9.8.3. Реализация модели песочницы 194
9.9. Заключение 195
10. Заключение 196
11. Литература
- Практическое применение средств накопления и использования программистских знаний 21
- Абстрактный структурно-текстовый редактор программ
- Механизм типизации. Контроль типов. Описания объектов
- Модуль как объект нижнего уровня СУБД
Практическое применение средств накопления и использования программистских знаний 21
Накопление и использование программистских знаний - ключевой вопрос современных информационных технологий. Сейчас не имеет большого значения, насколько удобно в том или ином инструментальном окружении проектировать и реализовывать программы "с нуля" - в любом случае для большой информационной системы это будет сложный, многолетний процесс. Впрочем, как правило, это и не нужно. Очень многие вещи уже написаны (причем по многу раз), так что остается только настроить их должным образом и "проинтегрировать", то есть собрать в единую систему.
Можно считать общепринятым, что основным средством накопления программистских знаний являются схемы, хотя трактовка этого термина в разных работах существенно различается. Б статье [98] используется наиболее общая трактовка, восходящая к работам по искусственному интеллекту и по сути находящаяся на стыке программирования и психологии. Схема определяется как структура знания, состоящая из переменных (слотов), в которых "схвачены" закономерности, имеющие место среди объектов и событий. В слотах могут быть представлены свойства объектов, типичные последовательности объектов или событий, а также любое другое "типичное" знание. Как правило, схемы не являются полностью определенными, в них присутствуют параметры, возможно, снабженные подразумеваемыми значениями. Кроме того, схемы зависят от контекста - той предметной области, к которой они относятся.
Понятие схемы является достаточно общим, чтобы в рамках единого формализма представить два вида знания - процедурное и -декларативное. Процедурные знания можно считать динамическими. Они фиксируют, как взаимодействовать с определенными объектами, какие действия и в какой последовательности совершать. Запись какого-либо алгоритма (то, что в программировании как раз и называют процедурой) - пример процедурного знания. Декларативное знание статично. Оно основывается на фактах и описывает свойства объектов и событий, а также связи между ними.
Процедурные и декларативные знания могут обладать различной степенью общности. Степень общности, в свою очередь, определяется как мощностью механизма параметризации схемы, так и зависимостью последней от контекста. Наиболее общие знания в [98] называются тематическими. Их можно почерпнуть из книг или учебных курсов. Более конкретные знания, полученные на собственном опыте, называются эпизодическими. Например, можно прочитать в книге о методах перехода от формальных спецификаций к объектной модели, а затем на практике попытаться подобный переход осуществить.
Сравнительный анализ механизмов, поддерживающих, соответственно, процедурные и декларативные знания, проведен в работе [87]. Процедурные механизмы в наиболее современном виде представлены классическими объектно-ориентированными системами. Декларативные знания могут быть представлены средствами дескриптивных логик (Description Logics - весьма общий термин, за которым, как отмечается в [87], могут стоять разные теории и практические системы). Б [87] утверждается, что, вообще говоря, декларативные знания отличаются большей гибкостью, способностью воспринимать новые данные, они особенно полезны в условиях неполной информации (при инкрементальном накоплении знаний). Представленные в системе CLASSIC понятия концепции, отношения, роли, фильтра, будучи отображенными на формулы в логике предикатов первого порядка, позволяют задействовать машину логичес - 14 -кого вывода для получения новых знаний, первоначально представленных в неявной форме.
Объектный подход как инструмент представления процедурных знаний необходим для работы с большими системами (в [87] в роли носителя объектного подхода выступает система CL0S). Инкапсуляция, сокрытие за поведенческим интерфейсом деталей реализации, а также наследование позволяют структурировать знания, "подстраивать" знания при их повторном использовании с минимальным анализом существующих объектов и связей между ними.
Таким образом, согласно [87], логический подход хорош для накопления знаний "в малом", то есть знаний, относящихся к ограниченной теме или небольшому множеству объектов. Объектный подход видится как каркас (вернее, как средство создания каркаса) для больших систем. Б этом смысле между двумя подходами нет противоречий; более того, их сочетание представляется естественным и необходимым.
По сути на то же сочетание каркаса и наполняющих его компонентов указывается в работе [92] (см. также [75], [86], [102]). В ней утверждается, что каркас является моделью предметной области, построение которой есть научная задача. В модели фигурируют объекты, операции и отношения, общие для класса проблем или систем. Например, компиляторы включают в себя лексический анализатор, грамматический анализатор, средства управления таблицей символов, а также генератор кода, между которьми существуют соответствующие отношения. Такой каркас является достаточно общим, чтобы в него можно было вложить любой компилятор; это значит, что в нем сосредоточены необходимые элементы знаний о компиляторах. Задача разработки качественных компонентов (например, для грамматического разбора), способных встраиваться в каркас в различном окружении, является инженерной задачей, а граница между научным и инженерным представляется важ - 15 -ной в концептуальном плане.
Для повторного использования (см. [26]) как архитектуры, так и составляющих ее компонентов необходима инкапсуляция знаний, минимизация неявно используемых сведений об окружении, в котором должны использоваться каркасы и компоненты. Это неявное знание концентрируется в интерфейсах с пользователем, операционной средой и другими компонентами. В работе [35] предлагается ввести, наряду с традиционными абстрактными объектами данных, играющими прикладную роль, абстрактные представления данных (Abstract Data View, ADV), обслуживающие интерфейс. Это важное расширение объектно-ориентированного подхода, необходимое для накопления и практического использования программистских знаний в больших системах.
Для представления знаний в [35] используются дескриптивные схемы, описывающие структурные, статические и динамические свойства объектов. Для описания свойств применяется аппарат временной (темпоральной) логики, что позволяет единым образом специфицировать поведение компонентов больших систем, функционирующих асинхронно.
На близкую по сути проблему указывается в работе [53]. Имеется в виду недостаток средств для задания связей между объектами в современных языках программирования (см. также [104]). В результате интерфейсная информация "размазывается" по системе, что затрудняет повторное использование компонентов; кроме того, в реализации теряется существенная архитектурная информация. Для решения этой проблемы в Л 53] развивается понятие коннектора - объекта, в котором сосредоточена информация о связях. Потенциально это открывает возможность повторного использования не только отдельных компонентов, но и их совокупностей, что весьма важно. Кроме того, могут повторно использоваться именно связи с возможной параметризацией по подключаемым компонентам.
В работах [40], [41] путем измерения количественных характеристик программ на языке C++ обосновывается то (очевидное, на наш взгляд) положение, что сам по себе объектный подход и, в частности, механизм наследования, не является адекватным средством накопления и использования программистских знаний (см. также [83], [116]). Необходимы специальные средства, специальные меры (технические и организационные).
Абстрактный структурно-текстовый редактор программ
К числу основных понятий архитектуры JavaBeans относятся компоненты и контейнеры. Контейнеры могут включать в себя множество компонентов, образуя общий контекст взаимодействие о другими компонентами и с окружением. Контейнеры могут выступать в роли компонентов других контейнеров.
Неформально компонент ("кофейное зерно" - Java Bean) можно определить как многократно используемый программный объект, допускающий обработку в графическом инструментальном окружении и сохранение в долговременной памяти. С реализационной точки зрения компонент - это Java-класс и, возможно, набор ассоциированных дополнительных классов.
Каждый компонент предоставляет набор методов, доступных для вызова из других компонентов и/или контейнеров.
Компоненты могут обладать свойствами. Совокупность значений свойств определяет состояние компонента. Свойства могут быть доступны на чтение и/или запись посредством методов выборки и установки.
Компоненты могут порождать события (быть источниками событий), извещая о них другие компоненты, зарегистрировавшиеся в качестве подписчиков. Извещение (называемое также распространением события) заключается в вызове определенного метода объек-товподписчиков.
Типичным примером события является изменение свойств компонента. В общем случае компонент может предоставлять, подписку на получение информации об изменении и на право запрещать изменение .
Методы, свойства и события образуют набор афишируемых характеристик компонента, то есть характеристик, доступных инструментальному окружению и другим компонентам. Этот набор может быть выяснен посредством механизма интроспекции.
Состояние компонентов может быть сохранено в долговременной памяти. Наличие методов для подобного сохранения выделяет компоненты JavaBeans среди произвольных Java-классов.
Компоненты JavaBeans могут упаковываться для более эффективного хранения и передачи по сети. Описание соответствующего формата является частью спецификаций JavaBeans. Жизненный цикл компонентов JavaBeans можно подразделить на три этапа: - разработка и реализация компонента; - сборка приложения из компонентов; - выполнение приложения. Разработка и реализация компонентов JavaBeans по сути не отличается от создания произвольных Java-объектов, хотя и может включать реализацию специфических методов.
Сборка приложений выполняется, как правило, в инструментальном окружении, позволяющем проанализировать афишируемые характеристики компонентов, настроить значения свойств, зарегистрировать подписку на получение событий, организовав тем самым взаимодействие компонентов. Разработчик компонента может реализовать специальные методы для использования исключительно в инструментальном окружении (например, редактор свойств).
Компоненты взаимодействуют между собой и с инструментальным окружением. Взаимодействие осуществляется двумя способами -вызовом методов и распространением событий.
Спецификации JavaBeans описывают только локальное взаимодействие компонентов, осуществляемое в пределах одной виртуальной Java-машины. (Напомним, впрочем, что Java-аплеты рассчитаны на передачу по сети, так что возможно собрать приложение из компонентов, первоначально распределенных по сети.) Удаленные объекты могут связываться по протоколам архитектуры C0RBA
Интроспекция используется прежде всего на этапе разработки, в рамках инструментального окружения, позволяя увидеть афишируемые характеристики и с их помощью настроить компонент и связать его с другими элементами приложения.
Принципиальная возможность интроспекции была изначально заложена в Java-технологии. Файлы классов содержат достаточно информации для выяснения всех необходимых характеристик объектов. Воспользоваться этой информацией можно с помощью класса Class, пакета Java.lang.reflect и некоторых других средств, которые будут рассмотрены далее. Чтобы оценить полноту сведений, предоставляемых Java-средой, целесообразно рассмотреть фрагменты описаний класса Class (листинг 1), а также класса Method из пакета Java.lang.reflect (листинг 2).
Таким образом, разработчики и пользователи компонентов ведут работу исключительно Java-средствами. Более того, в большинстве случаев разработчику, чтобы сделать класс полноценным элементом среды JavaBeans, достаточно придерживаться определенной дисциплины описания методов, не прибегая к явному афишированию характеристик. Например, по умолчанию в число афишируемых попадают все public-методы компонента.
Способность компонента среды JavaBeans по существу без дополнительных усилий со стороны разработчика предоставлять информацию о своем интерфейсе называется рефлексией. Рефлексия базируется на дисциплине определения методов. Эта дисциплина состоит в следовании заданным шаблонам при выборе имен методов, а также типов формальных параметров и результатов. Далее, по ходу изложения, мы будем приводить эти шаблоны.
Среда JavaBeans проектировалась таким образом, чтобы в типичных случаях и действия разработчиков, и внутренняя реализация оставались простыми; дополнительные усилия и утяжеление компонентов должны требоваться только тогда, когда этого желает сам программист. В данном случае, если разработчику не хватает выразительной силы рефлексии, он может реализовать интерфейс Beanlnfo, явным образом описывающий афишируемые характеристики компонента.
Интерфейс Beanlnfo содержит методы, позволяющие получить объекты-описатели характеристик компонента. В число этих методов входят getBeanDescriptor, getMethodDescriptors и т.д. (см. листинги 3 и 4). Поскольку реализация методов может быть сколь угодно изощренной, у разработчика появляется возможность ассоциировать с компонентом ресурсы (например, файлы), содержащие описательную информацию. Класс SimpleBeanlnfo, входящий в пакет Java.beans, является "пустой" реализацией интерфейса Beanlnfo, отрицающей наличие у компонента каких-либо афишируемых методов, свойств и событий. Разработчик может создать производный класс и выборочно переопределить методы класса SimpleBeanlnfo.
Механизм типизации. Контроль типов. Описания объектов
Из типов данных, встроенных в INFORMIX-Universal Server, следует в первую очередь отметить две разновидности больших объектов - простые и интеллектуальные. Интеллектуальные большие объекты (текстовые или бинарные) допускают чтение/запись произвольных фрагментов, они подвергаются журнализации и могут откатываться.
INFORMIX-Universal Server позволяет определять новые типы данных. С точки зрения сервера СУБД эти типы могут быть атомарными или структурными.
Атомарные типы (называемые также типами со скрытой структурой) описываются средствами, внешними по отношению к серверу СУБД, и регистрируются в системном каталоге. Таким внешним средством может быть, например, язык С, на котором описывается представление объектов нового типа, а также функции, применимые к этим объектам (сравнение, отображение и т.п.). Хотя в терминах языка С подобные объекты могут определяться как структуры, сервер СУБД не знает и, следовательно, не интерпретирует их содержимое, то есть считает их атомарными.
К техническим моментам можно отнести средства для определения типов с новым именем, заимствующих у одного из ранее описанных типов внутреннее представление и функциональность. Подобная возможность присутствует, по-видимому, во всех системах с именной эквивалентностью типов; она необходима для частичного изменения поведения объектов со встроенной структурой.
Очень важным является введение в INFORMIX-Universal Server на уровне языка SQL структур данных (конструкторов типов) -множеств, мультимножеств, списков и реляционных строк.
Множество (конструктор SET) - это неупорядоченный набор -однотипных элементов с поддержанием уникальности. Мультимножество (конструктор MULTISET) - это множество, элементы в котором могут повторяться.
Список (конструктор LIST) представляет собой упорядоченный набор элементов. По существу это одномерный массив.
Реляционные строки как структурный тип данных представляют собой совокупность поименованных элементов - полей. В традиционных языках программирования аналогом реляционной строки является запись.
Множества, мультимножества и списки представляют собой однородные структуры, все элементы которых имеют один и тот же тип. Реляционные строки, вообще говоря, состоят из разнотипных элементов. INFORMIX-Universal Server не накладывает ограничений на тип элементов структурных объектов, то есть структуры данных могут быть вложенными.
Если придерживаться объектно-ориентированного подхода, каждый тип данных следует характеризовать двумя группами свойств: - представлением значений данного типа; - подпрограммами (методами), применимыми к значениям данного типа. Обычно типы наследуют свойства у ранее описанных типов, добавляя к ним новые компоненты и методы и/или изменяя поведение существующих методов. INFORMIX-Universal Server поддерживает одиночное наследование. Новые или модифицированные методы реализуются с использованием языка хранимых процедур (Stored Procedures Language - SPL) или какого-либо внешнего языка.
Если объекты нового типа предполагается индексировать, необходимо определить так называемые вторичные методы доступа, отвечающие за работу с индексами. INFORMIX-Universal Server предлагает несколько вторичных методов, применимых к данным различной природы. Например, для обслуживания индексов пространственных данных используются R-деревья, позволяющие эффективно разыскивать объекты по их пространственным координатам.
Новые подпрограммы (процедуры и функции), необходимо не только реализовать, но и зарегистрировать в базе данных. При регистрации можно сообщить информацию, способствующую оптимизации работы сервера. Если функция при заданных значениях параметров возвращает фиксированный результат и не имеет побочных эффектов, ее целесообразно специфицировать как невариантную. В таком случае оптимизатор в состоянии проиндексировать вызовы функций, избегая их многократного выполнения.
Центральное место в INFORMIX-Universal Server занимает концепция DataBlade ("лезвий данных" - по аналогии со сменными лезвиями в многоразовом бритвенном станке). Обычно модуль DataBlade представляет собой совокупность объектов (данных и программ), обеспечивающих законченную функциональность в какой-либо предметной области. Модули DataBlade добавляются к серверу СУБД, расширяя тем самым его возможности. Установленные модули доступны из SQL-запросов, из прикладных программ и из других модулей DataBlade. Возникает иерархия, характерная для объектно ориентированных систем.
Существуют модули DataBlade для организации связи между WebcepBepaMH и серверами СУБД, для работы с пространственными данными, для индексирования текстовых документов и т.п.
В этом разделе будут рассмотрены наиболее интересные черты реализации объектно-ориентированной СУБД ObjectStore [79].
Одна из фундаментальных операций в языке программирования базы данных - разыменование: поиск и использование объекта, на который указывает ссылка. Цель ObjectStore - сделать так, чтобы время выполнения этой операции для временных и постоянных объектов отличалось незначительно.
Если объект уже был извлечем из базы данных, то доступ к нему будет происходить как к временному объекту. Для реализации проверки того, был ли уже извлечен объект из базы данных или нет, используются механизмы поддержки виртуальной памяти. ObjectStore использует аппаратную поддержку механизмов управления виртуальной памятью и интерфейс ОС. Механизмы управления виртуальной памятью позволяют ObjectStore устанавливать защиту любой страницы от доступа, чтения или чтения/записи. Когда прикладная программа обращается к объекту, которого еще нет в оперативной памяти, то происходит аппаратное прерывание. После этого ObjectStore получает нужную страницу от сервера и помещает ее кэше клиента. Затем ОС устанавливает для данной страницы защиту и операция доступа к объекту повторяется. Все последующие операции обращения к объектам, расположенным на данной станице, выполняются как одна команда и не приводят к прерываниям.
Архитектура ObjectStore основана на модели клиент/сервер. Сервер и клиент взаимодействуют через локальную сеть, если они запущены на разных компьютерах, или через разделяемую память и локальные сокеты, если на одном и том же.
В сервере ObjectStore реализована два способа организации хранилища на диске: на основе файловой системы ОС и на основе своей файловой системы. Второй способ обеспечивает более высокую производительность (последовательное расположение данных, нет издержек ОС).
Модуль как объект нижнего уровня СУБД
На момент старта программной системы все множество объектов, хранящихся в базе данных, можно считать разбитым на два подмножества. К первому относятся объекты, чьи последние состояния принадлежат варианту, порожденному предыдущими выполнениями этой же системы. Это подмножество будем называть приватным. Ко второму подмножеству, которое мы будем называть разделяемым, относятся все прочие объекты (последние состояния которых потенциально могут быть общими для нескольких программных систем) .
Дадим еще одно определение. Будем говорить, что подмножество объектов базы данных находится в корректном зафиксированном состоянии, если нормально завершены все транзакции, затрагивающие объекты подмножества, и данное подмножество больше не подвергается изменениям.
Утверждение 2. Механизм вариантов делает ненужными какие-либо действия по синхронизации независимых программных систем в плане доступа к базе данных. Доказательство. По определению понятия варианта базы данных последовательность состояний произвольного объекта о для системы S не зависит от поведения других систем, что и требовалось доказать. Сформулируем достаточное условие реализации механизма вариантов . Утверждение 3. Для поддержания механизма вариантов достаточно, чтобы приватные подмножества каждой программной системы отображались на различные области виртуального пространства, и чтобы на момент старта разделяемое подмножество находилось в корректном зафиксированном состоянии.
Основной посылкой, на которой базируются сформулированные выше достаточные условия бесконфликтной синхронизации процессов - клиентов объектно-ориентированной СУБД, является принцип неу-ничтожения информации. Современный уровень развития устройств долговременной памяти, в первую очередь доступность оптических дисков большой емкости с возможностями однократной записи и многократного считывания, делает следование принципу неуничтожения информации технически вполне возможным. Кроме того, операция фиксации варианта может включать в себя ликвидацию промежуточных состояний объектов в тех случаях, когда экономия долговременной памяти становится по каким-либо причинам актуальной.
С другой стороны, нередко хранение нескольких состояний объектов желательно в силу специфики прикладной программной системы. Например, если речь идет об инструментальной среде программирования, весьма желательно хранить историю разработки, чтобы предоставить возможность возврата к предыдущим состояниям.
Таким образом, следование принципу неуничтожения информации (быть может, в сочетании с операцией фиксации варианта и ликвидацией промежуточных состояний) технически вполне возможно и зачастую желательно. Отметим, что частный случай принципа неуничтожения использован при реализации файловой системы Cedar [62].
Разбиение проблемы синхронизации процессов на два уровня -уровень компонентов одной программной системы и уровень независимых систем - отражает реальную архитектуру многопроцессных комплексов. Выделение процессов-компонентов в соответствии с изменяемым ими множеством объектов не является обременительным и, более того, представляется вполне естественным. Разумеется, процессы-компоненты могут взаимодействовать не только как клиенты СУБД, но подобное взаимодействие, требующее, как правило, их синхронизации, специфично для конкретных прикладных областей и не может быть снято или сокращено универсальными методами.
Современные операционные системы (например, ОС UNIX System V Release 4.2) предоставляют страничную виртуальную память практически неограниченного размера с возможностью отображения на файлы и/или области дискового пространства. Области виртуальной памяти могут быть как внутренними для процесса, так и разделяемыми между произвольным числом процессов. Таким образом, реализация объектно-ориентированной СУБД с помощью технологии виртуальной памяти не только технически возможна, но и ведет к повышению эффективности, а также снимает различия между временньми и постоянными объектами, что делает доступными для прикладных программ многочисленные библиотеки классов, накопленные на языках типа C++ [31], без переделки этих программ.
Предоставление каждому процессу - клиенту СУБД независимого пула ресурсов применительно к виртуальной памяти ведет к уменьшению так называемого рабочего множества - совокупности данных, используемых в близкие моменты времени, что положительно сказывается на поведении всего множества процессов.
Использование механизма вариантов снимает проблему синхронизации независимых программ как клиентов СУБД, но ставит новую проблему - слияния вариантов. Например, если речь идет об инструментальной среде программирования, общая проблема слияния формулируется как учет изменений, независимо сделанных несколькими разработчиками. Отметим в этой связи два обстоятельства. Во-первых, проблема слияния существует независимо от используемых методов доступа к данным. Во-вторых, для ее решения необходим учет специфики конкретной предметной области и, быть может, участие людей, породивших новые варианты. Таким образом, и решаться проблема слияния вариантов должна не на уровне доступа к базам данных.
