Труды Института системного программирования РАН. Том 15. 2008 г

Предисловие В очередном сборнике Трудов Института системного программирования РАН представлены девять статей сотрудников ИСП РАН, посвященных различным вопросам теории и практике системного программирования. Статья В.В. Рубанова «Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки» посвящена методам описания расширяемых встраиваемых систем и построения соответствующих инструментов кросс-разработки (симулятор, ассемблер, дисассемблер, компоновщик, отладчик и т.п.). Рассматривается общий процесс проектирования встраиваемых систем и описывается роль инструментария кросс-разработки. Обсуждаются языки для описания моделей встраиваемых систем и методы получения инструментария кросс-разработки на основе таких описаний. Проводится сравнительный анализ рассмотренных решений. В статье А.К. Петренко, О.Л. Петренко и В.В. Кулямина «Роль научных организаций в подготовке ИТ-специалистов» рассматривается проблема подготовки специалистов высокой квалификации в области информационных технологий (ИТ). Предлагается использовать для решения проблем современного ИТ-образования подход, основанный на принципах «системы Физтеха», прежде всего — ресурсы научных и научно-производственных учреждений. В рамках такой системы студенты получают возможность участвовать в работе по специальности совместно с ведущими специалистами в соответствующей области. В статье В.В. Липаева «Проблемы экономики производства крупных программных продуктов» обсуждаются особенности экономики современного производства крупных программных продуктов, а также оценка их экономических характеристик путем маркетинговых исследований или по статистике прототипов продукта. Сформулированы проблемы организации, планирования и применения экономически обоснованных методов автоматизации производства сложных комплексов программ, а также обеспечения их качества с учетом затрат ресурсов. И.Б. Бурдонов и А.С. Косачев представили статью «Обобщённые семантики тестового взаимодействия», в которой развиваются результаты, описанные в предыдущих публикациях авторов. Обобщается семантику тестового взаимодействия на основе допущения наблюдения отказов, не обязательно совпадающих с множеством разрешаемых действий (и даже не обязательно вложенных в него). Изложение состоит из двух частей: сначала рассматриваются модели без приоритетов, а потом вводятся приоритеты. В статье Е.В. Корныхина «Генерация тестовых данных для тестирования арифметических операций центральных процессоров» Рассматривается задача генерации тестовых данных для тестирования арифметической подсистемы центральных процессоров. Для ее решения предлагается использовать метод, позволяющий строить тестовые данные систематически на основе 5

формального описания поведения отдельных команд микропроцессора. Предложенный метод апробирован на командах арифметической подсистемы микропроцессоров MIPS64. Статья К.Н. Долговой и А.В. Чернова «О некоторых задачах обратной инженерии» содержит краткое введение в проблематику задачи декомпиляции программ как одной из задач обратной инженерии. Рассматриваются возможности и недостатки существующих инструментальных средств декомпиляции программ. Представлены результаты сравнительного тестирования декомпиляторов для языка Си на разработанном наборе тестовых примеров. В статье П.Н. Яковенко и А.В. Сапожникова «Подход к реализации переносимого TTCN-3 отладчика» приводится краткое описание интерфейса TCI-TL. Рассматриваются подходы к реализации отладчика: времени выполнения и «посмертный». Описываются особенности реализации операций отладки на базе TL-интерфейса. Обсуждается проблема обработки запущенных таймеров при остановке в контрольной точке. Статья Д.А. Лизоркина «Язык модификации данных формата XML функциональными методами» посвящена описанию языка модификации XML-данных, в основу которого были положены функциональные методы программирования и язык функционального программирования Scheme. Функции, являющиеся в языках функционального программирования объектами первого класса, используются в предлагаемом языке модификации XML-данных в роли обработчиков для операций модификации, что позволяет достичь выразительной мощности и расширяемости набора операций модификации при сохранении синтаксической простоты языка. Проводится анализ алгоритмической сложности выполнения операций предлагаемого языка и рассматриваются детали его реализации функциональными методами. Наконец, в статье В.А. Семенова, С.В. Морозова, О.А. Тарлапана и И.В. Энковича «Нечеткое сравнение коллекций: семантический и алгоритмический аспекты» рассматривается задача нечеткого сравнения коллекций в приложениях реконсиляции. Задача возникает при оптимистической репликации структурированных данных и документов и имеет многочисленные приложения в таких актуальных областях, как управление конфигурацией программного обеспечения, управление мобильными базами данных, построение платформ и систем коллективной инженерии. Анализируются стандартные типы коллекций языков объектноориентированного моделирования, для которых описываются и обосновываются способы представления, журнализации, вычисления, принятия и согласования изменений. Для выделенных типов коллекций дается строгая, семантически содержательная интерпретация конфликтов и предлагаются конструктивные методы их идентификации и разрешения. Член-корреспондент РАН 6

В.П. Иванников

Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

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

Прототипирование целевой аппаратуры и исследование проектных альтернатив (design space exploration) – разработка набора типовых тестов (т.е. программ для целевой машины), их запуск и профилирование на различных вариантах аппаратуры позволяет получать оценки эффективности того или иного проектного варианта и принимать решения о выработке новых улучшений, например, оптимизации системы команд ядра, добавлении / удалении тех или иных функциональных блоков, регистров и сопроцессоров.

2.

Раннее создание приложений – программное обеспечение для целевой платформы должно быть создано и предварительно отлажено еще до появления реальной аппаратуры. Это необходимо для сокращения времени выхода на рынок полного решения в виде «аппаратура + программы».

3.

Верификация спецификаций аппаратуры – использование построенного кросс-симулятора позволяет проводить его взаимную верификацию с симуляторами, полученными на основе точной VHDL/Verilog спецификации целевой системы (после того, как такая спецификация будет создана на позднем этапе проектирования). Такая верификация играет важную роль в процессе финального обеспечения качества перед запуском аппаратуры в производство.

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

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

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

8

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

2.

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

3.

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

Применение такого «идеального» метода позволило бы эффективно решать поставленные выше задачи прототипирования расширяемой аппаратуры с потактовой точностью, верификации VHDL/Verilog моделей и собственно разработки реальных приложении как на этапе проектирования, так и на этапе эксплуатации аппаратуры. Статья состоит из введения, трех разделов и заключения. Во втором разделе рассматривается процесс проектирования встраиваемых систем и описывается роль инструментария кросс-разработки. В разделе 3 дается обзор языков для описания моделей встраиваемых систем и соответствующих методов получения инструментария кросс-разработки на основе таких описаний. В четвертом разделе проводится сравнительный анализ рассмотренных решений. В заключении подводятся итоги и предлагаются направления создания новых методов.

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

1.1. Обобщенная систем

схема

проектирования

Рассмотрим известную (см. например [5-6]) проектирования встраиваемой системы (рис. 1).

встраиваемых обобщенную

схему

1. Проектирование встраиваемых систем В СССР первыми встраиваемыми компьютерными системами можно считать специализированные бортовые вычислительные машины для военных и космических отраслей. Первые такие машины начали разрабатывать в конце 1950-х (см. [1]-[3]) на базе появившихся тогда сплавных транзисторов, и в начале 1960-х их уже стали применять на практике. В [1] в качестве одних из первых таких систем упоминаются передвижные компьютеры для нужд ПВО (1960-1962), обеспечивавшие управление зенитно-ракетными комплексами с сопровождением многих десятков целей. В зарубежных источниках [4] первой широко известной встраиваемой системой называют бортовой компьютер космического корабля Apollo (середина 1960-х). Долгое время основной областью применения встраиваемых систем были именно задачи космического и военного назначения. В современном мире 1

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

Рис. 1. Обобщенная схема проектирования встраиваемой системы 10

На первом этапе происходит определение требований к системе. Определяются необходимые функциональные характеристики системы и задаются ограничения. Типовыми ограничениями являются быстродействие, энергопотребление, размер и стоимость изготовления кристаллов в рамках заданного технологического процесса производства микросхем. На следующем этапе выполняется декомпозиция системы на аппаратные и программные компоненты (HW/SW partitioning). Принимаются решения об общей структуре системы (в первую очередь, число и характеристики вычислительных блоков) и выполняется отображение требуемой функциональности на программные и аппаратные части. Далее процесс разделяется на две ветви – для проектирования программных и аппаратных компонентов. Выходом аппаратной ветви являются модели аппаратуры. В этой ветви принимаются решения об архитектуре выделенных в системе аппаратных вычислительных устройств. Для программируемых компонентов определяется состав функциональных блоков (включая внешние модули расширений для специфических вычислений), структура памяти (включая регистры) и система команд. Результатом проектирования программной части являются модели программных компонентов, совместимые с соответствующими аппаратными моделями. Процесс носит итеративный характер, и точность описания моделей на каждой итерации постепенно повышается от высокоуровневых функциональных описаний до синтезируемых спецификаций аппаратуры и машинных кодов программ, соответствующих этой аппаратуре. Каждая итерация заканчивается интеграцией результатов программной и аппаратных ветвей, моделированием полученной системы, проверкой функциональной корректности и сбором соответствующих оценок ключевых параметров для их анализа с целью дальнейшей оптимизации. На основании полученных таким образом оценок принимаются решения о пересмотре декомпозиции между программными и аппаратными компонентами, о конкретных изменениях программ и аппаратуры, например, добавлении/удалении вычислительных блоков или оптимизации системы команд. Цикл повторяется до получения конкретных спецификаций программ и аппаратуры, которые совместно задают встраиваемую систему, удовлетворяющую всем заданным требованиям. Затем проводится верификация спецификаций, и цикл проектирования завершается подготовкой отчуждаемого продукта, пригодного для интеграции в более крупные проекты «систем на чипе» (SoC) или для запуска в отдельное производство. Такой продукт обычно включает в себя:

3) набор инструментов кросс-разработки (среда программирования, см. подраздел 1.2) для создания и отладки новых программ; 4) документацию для программистов (справочники по архитектуре системы, по системе команд, по поставляемому системному программному обеспечению и различным библиотекам, по среде программирования). Существует много различных методов и средств автоматизации проектирования аппаратуры (см., например, обзор [7]). В случае встраиваемых систем огромное внимание уделяется задаче оптимального разбиения системы на аппаратные и программные компоненты (HW/SW partitioning and codesign) – см. [8-13]. Однако в данной статье мы ограничимся только рассмотрением создания и использования (кроме собственно основного назначения для разработки реальных программ) кросс-инструментария как средства получения дополнительных данных для поддержки принятия проектных решений в процессе проектирования аппаратуры (см. следующие разделы). Конкретные методы использования таких данных выходят за рамки данной статьи.

1.2. Разработка программ с помощью кросс-инструментария Целью использования кросс-инструментов является создание на инструментальной машине файла с двоичным образом (firmware) начального содержимого памяти (как машинные команды, так и данные) для целевой аппаратной системы. Такой файл затем используется для загрузки в конкретные целевые устройства. В качестве языков программирования встраиваемых систем выступают обычно C (а также его расширенные подмножества типа Embedded C [14]) и ассемблер. Ассемблер используется как в виде вставок в код на языке С, так и в виде отдельных ассемблерных модулей. В случае встраиваемых систем программирование на ассемблере остается важной составляющей создания программ ввиду, как правило, жестких требований к высокой производительности и малому объему программного кода. На рис. 2 представлена типовая схема разработки программ с помощью кроссинструментария. Обычно процесс взаимодействия программиста с кросс-инструментами происходит через визуальную интегрированную среду разработки (IDE) со встроенным редактором, механизмами поддержки проектов, различными средствами управления и анализа результатов работы отдельных инструментов.

1) синтезируемые RTL (register transfer level) описания аппаратуры (обычно на VHDL/Verilog); 2) исходные (на С/ассемблере) и машинные (firmware) коды базовых системных и прикладных программ для целевой аппаратуры; 11

12

Интегрированная cреда разработки

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

Рис. 2. Разработка программ с помощью кросс-инструментов.

6) различные статистики на уровне операционной системы (в терминах задач и примитивов синхронизации, зарегистрированных в системе).

Реальные программы обычно состоят из нескольких модулей, каждому из которых соответствует файл с исходными текстами программ (на языках высокого уровня или ассемблера). Компилятор транслирует модули на языке высокого уровня в промежуточные ассемблерные модули. Ассемблер отвечает за преобразование ассемблерных модулей (как написанных вручную, так и сгенерированных компилятором) в объектные модули с машинными кодами и данными для целевой аппаратуры. В качестве формата объектных модулей обычно используется ELF [15-16], включающий в себя различные секции (например, секции исполняемого кода, секции данных, секции с информацией о символах и секции с отладочной информацией). Компоновщик выполняет сборку нескольких объектных модулей в один абсолютный модуль с объединением соответствующих секций входных объектных файлов. При этом выполняются перемещения символов по абсолютным адресам памяти (автоматически или в соответствии с заданной программистом картой памяти) 13

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

стадии эксплуатации. Использование настоящей аппаратуры позволяет запускать программы в режиме реального времени, однако программный симулятор предоставляет гораздо больше возможностей для отладки и анализа программ.

1.3. Прототипирование на основе кросс-инструментария Уже на этапе проектирования для прототипирования и верификации целевой системы часто используется инструментарий кросс-разработки (см. например [17-19]). Это позволяет эффективно выполнять тонкую оптимизацию системы (как аппаратуры, так и программ для нее) с использованием системных и прикладных целевых программ, близких к реальным. Благодаря этому, дальнейший переход к выпуску промышленного набора результатов проектирования происходит бесшовно, то есть последняя итерация проектирования и верификации оканчивается результатами, готовыми к производственному применению (спецификацией аппаратуры и программами для нее). Программа Требования и ограничения

1 Дизайнер

нет

Описание аппаратуры

3

Удовлетворение требованиям и ограничениям

моделей аппаратуры и методы построения кросс-

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

синтеза

реальных

3) языки программирования общего назначения.

2.1. Языки синтезируемого описания аппаратуры

4 5

2. Языки описания соответствующие инструментов

2) языки ADL (Architecture Description Languages) для высокоуровневого описания аппаратуры;

Кроссинструментарий

2

инструментов выполняется сборка, отладка, запуск и профилирование целевой программы (3). Получаются (4) значения необходимых характеристик системы, которые используются (5) для оценки удовлетворения требованиям/ограничениям и принятия решения о путях дальнейшей оптимизации системы (изменения программы/системы команд процессора, добавление/удаление аппаратных расширений, регистров и т.п.).

Функциональная корректность и профили производительности и энергопотребления

да Окончание проектирования

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

Рассмотрим три основных языка HDL (Hardware Definition Language) [20], которые используются современными разработчиками для описания моделей аппаратуры, пригодных для дальнейшего автоматического синтеза спецификаций для производства реальных чипов. Это VHDL, Verilog и SystemC. Первые два языка были разработаны в середине 80х и до сих пор являются наиболее популярными классическими HDL-языками; SystemC – относительно современная разработка, находящаяся в стадии развития, но стремительно набирающая популярность. На верхнем уровне эти языки очень схожи – модель аппаратуры описывается в виде взаимодействующих модулей (блоков), для каждого из которых определяется интерфейс и реализация. Интерфейсы модулей описывают входные, выходные и двусторонние порты, с помощью которых модули соединяются друг с другом для обмена данными и управляющими сигналами. Реализация задает элементы внутреннего состояния и порядок вычисления значений выходных интерфейсов на основе этого состояния и значений входных портов, а также правила обновления внутреннего состояния. Вычисление новых значений выходных интерфейсов и внутреннего состояния инициируется событиями в виде изменения уровней входных сигналов. Важную роль в описании аппаратуры с использованием языков HDL играет понятие времени, которое моделируется целочисленной величиной с 16

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

3.1.1. VHDL VHDL [21-24] был разработан в недрах Министерства Обороны США, изначально предназначаясь для облегчения унифицированного описания микросхем, которые включались сторонними поставщиками в различные решения для этого ведомства. Первая официальная версия VHDL появилась в 1987 году в виде стандарта IEEE 1076-1987 [24]. Многие семантические и синтаксические элементы VHDL заимствованы из языка Ada. Подобно Ada, VHDL – это строго типизированный язык, не чувствительный к регистру символов. В дополнение к стандартным базовым возможностям Ada, VHDL включает расширенные логические операции (например, nand и nor), двунаправленную индексацию массивов, а также дополнительные типы, такие как time, bit, bit_vector, character, string. Позже в VHDL ввели понятие 9-значной (U,X,0,1,Z,W,H,L,-) логики (см. IEEE Std 1164 [25]) и понятие знаковых/беззнаковых типов (см. IEEE standard 1076.3 [26]). Принципиальной особенностью VHDL является поддержка конструкций для задания параллелизма, свойственного аппаратуре, а именно модулей и процессов. Интерфейс модуля задается с помощью ключевого слова entity, ключевое слово architecture обозначает описание реализации, которое заключается между begin и end. Внутри такого блока могут задаваться константы (constant), сигналы (signal) и собственно поведение в виде набора операторов, в том числе, сгруппированных в виде параллельно выполняющихся процессов (с помощью ключевого слова process). Внутри процессов могут объявляться переменные (variable). Важным различием переменных и сигналов является то, что значение переменной меняется сразу после выполнения соответствующего оператора (понятие времени не ассоциируется с понятием переменной), а значение сигнала меняется только после окончания текущей итерации выполнения процесса. Пример 1 иллюстрирует реализацию на языке VHDL простого мультиплексора (см. рис. 4).

17

Рис. 4. Простой мультиплексор

entity mux is port (c, d, e, f: in std_logic; s: in std_logic_vector(1 downto 0); mux_out: out std_logic); end mux; architecture mux_impl of mux is begin muxl: process (s, c, d, e, f) begin case s is when “00” => mux_out mux_out mux_out mux_out >> для арифметического сдвига с заполнением знаковым битом). Однако в Verilog не поддерживаются пользовательские типы, структуры, указатели и рекурсивные функции. Типы данных в Verilog имеют явную битовую ширину. В отличие от VHDL, Verilog является слабо типизированным языком, что позволяет смешивать присвоения элементов разного типа за счет неявного преобразования типов. Как и в случае VHDL, принципиальным отличием Verilog от своего языкапрототипа является поддержка конструкций, выполняющихся параллельно. Модули в Verilog определяются с помощью ключевого слова module и могут быть вложенными. Не происходит явного разделения интерфейса и реализации, как в VHDL. В декларативной части модуля определяются входные (input), выходные (output), двунаправленные (inout) порты, внутренние сигналы (wire) и переменные (reg).

module bcircuit (a, b, av, bv, w, wv); input a, b; output w; input [7:0] av, bv; output [7:0] wv; wire d; wire [7:0] dv; reg e; reg [7:0] ev; . . . endmodule

Важным отличием Verilog от VHDL является подверженность недетерминированному поведению (race conditions) модели на основе описания Verilog и отсутствие таких эффектов в VHDL. Более подробный сравнительный обзор VHDL и Verilog можно найти в [34]. Пример 3 иллюстрирует реализацию простого мультиплексора (см. рис. 4) на языке Verilog.

module mux (c, d, e, f, s, mux_out); input c, d, e, f; input [1:0] s; output mux_out; reg mux_out; always @ (c or d or e begin case (s) 2’b00: mux_out = 2’b01: mux_out = 2’b10: mux_out = default: mux_out endcase end endmodule

or f or s) c; d; e; = f;

Пример 3. Простой мультиплексор на Verilog.

3.1.3. SystemC

Пример 2. Описание модуля и его интерфейсов в Verilog В процедурной части модуля определяется его поведение. Для этого могут использоваться конструкции вентильного уровня (определяется структура модуля в виде соединенных между собой вентилей определенных типов), параллельные присвоения (assign) или процедурные блоки (always или initial). Процедурные блоки аналогичны процессам VHDL. Конструкции языка в рамках процедурного блока выполняются последовательно, в то время как все процедурные блоки выполняются параллельно. Интересно отметить наличие оператора неблокирующего присваивания sc_out <sc_logic>

крупный производитель средств автоматизированной разработки аппаратуры (EDA) поддерживает собственные симуляторы для различных HDL-языков. Synopsis предлагает уже ставшую классической среду VCS [35], способную симулировать модели (в том числе смешанные) на всех трех основных языках - VHDL, Verilog и SystemC. Аналогичные смешанные симуляторы предлагаются компаниями Mentor Graphics (ModelSim [36]) и Cadence (NCSim [37], Incisive Verification Platform [38]). Все эти симуляторы поддерживаются интегрированными средами разработки и отладки моделей, в которых одним из основных средств визуализации отладки являются диаграммы изменения сигналов (waveforms). Основной проблемой HDL-симуляторов является низкая скорость работы порядка 10-50 тыс. модельных тактов в секунду на современных рабочих станциях, в то время как типовой цикл моделирования алгоритмов цифровой обработки сигналов требует миллиарды тактов для обработки репрезентативного тестового сигнала. Такая скорость обусловлена высокой точностью моделирования на слишком низком уровне. Таким образом, скорость работы и отсутствие средств поддержки программирования на уровне системы команд делает применение HDL-симуляторов неприемлемым для эффективной разработки прикладных программ. Тем не менее, такие симуляторы играют важную роль в процессе дизайна и верификации самой аппаратуры.

c, d, e, f; s; mux_out;

SC_CTOR (mux) { SC_METHOD (do_mux); sensitive (,

0) { var integer v; } if (a < 0) { var integer v; } }

Оператор log(v) распечатает, разумеется, единицу, однако в рамках TLинтерфейса нельзя сказать, что значение v в этой точке равно единице. Действительно, при выполнении тестового сценария tc сгенерируется ряд событий, из которых нам интересна часть, соответствующая вызову функции f: tliVar(“v”, 1) tliSEnter(“f”) tliVar(“v”, 2) tliSLeave(“f”)

Если же в этом примере заменить v на a, то имя переменной, объявленной в теле условного оператора, будет совпадать с именем формального параметра функции f, и компилятор выдаст ошибку. Несмотря на недопустимость перекрытия имен, отладчик должен уметь отличать объекты уровня модуля от «компонентных» объектов, а эти объекты, в свою очередь, нужно отличать от локальных объектов. Рассмотрим пример, показывающий важность знания области видимости переменной: type component MyComponent { } function f() runs on MyComponent { var integer v; v := 2; //здесь генерируется событие tliVar (v == 2) } testcase tc() runs on MyComponent { var integer v; v := 1; //здесь генерируется событие tliVar (v == 1) f(); log(v); // v == 1 или v == 2? } В этом примере в тестовом сценарии tc объявляется переменная v, ей присваивается единица (при этом генерируется событие tliVar для переменной с именем “v”) и вызывается функция f. В функции f также объявляется переменная v, и ей присваивается двойка (при этом снова генерируется событие tliVar для переменной с именем “v”). После возврата из функции f тестовый сценарий tc выводит на экран значение v. 143

// // // //

v = 1 вызов функции f v = 2 возврат из функции f

Получив такую последовательность событий, мы можем неверно предположить, что оба события tliVar относятся к одной и той же переменной, и v – компонентная переменная. Тогда просмотр значения v на позиции оператора log(v) в отладчике ошибочно покажет двойку, в то время как оператор log(v) выведет на экран единицу. Если же мы будем считать, что v – локальная переменная, и события относятся к двум разным одноименным переменным (как оно и есть в нашем примере), объявленным в тестовом сценария tc и функции f, то просмотр значения v на позиции оператора log(v) в отладчике покажет единицу. Следовательно, в момент получения события tliVar для переменной v необходимо уметь определять, является ли она компонентной или локальной. В общем случае не представляется возможным выделить среди всех событий те из них, которые относятся к компонентным переменным, . Тем не менее, если придерживаться простого соглашения по написанию программ TTCN-3, то в большинстве случаях можно корректно определять характер переменной. Предположим, что переменная v объявлена в компоненте MyComponent, и для нее указано начальное значение, например, следующим образом: type component MyComponent { var integer v := 1; } Тогда система поддержки выполнения программы сгенерирует событие tliVar в момент инициализации переменной. Инициализация происходит во время создания компонента. Для главного тестового компонента это произойдет в интервале между командой на запуск тестового сценария (в этот момент генерируется событие tliTcExecute) и началом выполнения операторов в теле тестового сценария (в этот момент генерируется событие tliTcStarted). Таким образом, все события tliVar, полученные в период между событиями tliTcExecute и tliTcStarted, относятся к инициализации компонентных переменных и констант. Дополнительные параллельные компоненты в языке TTCN-3 должны явно порождаться при помощи оператора create. При этом генерируется событие 144

tliCCreate. Оператор create только создает новый экземпляр компонента заданного типа. Для запуска функции во вновь созданном компоненте необходимо выполнить оператор start, указав имя функции и значения формальных параметров. При этом генерируется событие tliCStart. Такое разделение сделано для того, чтобы иметь возможность должным образом подключить порты нового компонента до начала выполнения в нем функции. Для параллельных компонентов все события tliVar, полученные в период между событиями tliCCreate и tliCStart, относятся к инициализации компонентных переменных и констант. Таким образом, если в TTCN-3 программе все компонентные переменные инициализируются начальными значениями, то, применяя вышеизложенный метод, в большинстве случаев можно отделять события tliVar, относящиеся к компонентным переменным, от всех остальных. Отметим особенность языка TTCN-3, из-за которой изложенный выше алгоритм в ряде случаев будет работать неверно. В TTCN-3 функция или тестовый сценарий, явно объявленные как выполняющиеся в некотором компоненте, могут вызывать обычную функцию (без объявления “runs on”), допускающую вызов из любой точки программы. Рассмотрим следующий пример: type component MyComponent { var integer v := 1;//здесь генерируется событие tliVar (v == 1) } function f() // _НЕ_ объявлена на компоненте { var integer v; v := 2; //здесь генерируется событие tliVar (v == 2) } testcase tc() runs on MyComponent { f(); log(v); // v == 1, но отладчик ошибочно выдаст v == 2 } Отличие этого примера от предыдущего состоит в том, что объявление переменной v перенесено из тестового сценария tc в компонент MyComponent. При этом из декларации функции f удалено объявление “runs on”. В противном случае область видимости локальной переменной v в функции f перекрывалась бы с областью видимости компонентной переменной v в типе MyComponent, что недопустимо в языке TTCN-3. 145

Функция f не связана с каким-либо определенным типом компонента, поэтому переменные, объявленные в компоненте MyComponent, не видны в ней, и объявление локальной переменной v допустимо. При применении предложенного выше алгоритма просмотр значения переменной v на позиции оператора log(v) в отладчике выдаст двойку, что не является корректным. Скорректировать алгоритм в соответствии с этой особенностью не представляется возможным, потому что TL-интерфейс не информирует о том, каким образом объявлена вызываемая функция – с “runs on” или без этой спецификации. Можно предложить следующее универсальное решение задачи распознавания характера переменной, простое в реализации для разработчиков TTCN-3 компилятора, но, тем не менее, требующее внесения изменений в стандарт TTCN-3: в событии tliVar передавать не просто имя переменной, а дополнять его префиксом для объектов уровня модуля и «компонентных» объектов. Объекты уровня модуля дополняются именем модуля, отделенным точкой, компонентные объекты дополняются именем типа компонента, отделенным двоеточием. Именование локальных объектов оставляется без изменений, т.е. без префикса. Например, MyModule.object – объект уровня модуля, MyComponent:object – объект уровня компоненты, object – локальный объект. Такой подход к именованию объектов согласуется с синтаксисом языка TTCN-3. В рамках стандартного интерфейса можно предложить пользователю придерживаться определенного стиля именования объектов. Например, можно начинать все имена объектов уровня модуля с символов g_, компонентные объекты – с символов ct_. Тогда механизм распознавания областей видимости в отладчике может опираться на подобный стиль именования объектов. Тем не менее, такое решение не является стандартным, а, значит, отладчик теряет универсальность. Что касается констант, объявленных на уровне модуля, то событие tliVar для них генерируется до начала выполнения тестового сценария. Поэтому все события tliVar, которые происходят до события tliTcExecute, информирующего о запуске тестового сценария, относятся к инициализации объектов уровня модуля.

4.4.2. Блочные переменные Язык TTCN-3 позволяет объявлять локальные переменные в теле составного оператора. Значение таких переменных становится неопределенным, когда поток управления покидает тело составного оператора. В следующем примере значение переменной v не определено на позиции оператора log(v).

146

if (...) { var integer v := 1; //здесь генерируется событие tliVar (v == 1) } log(v); //ошибка, значение v не определено Запрос у отладчика значения переменной v в точке log(v) должен выдать, что переменная v не определена, однако реализация такой функциональности не представляется возможной, несмотря на то, что при входе и выходе из составного блока генерируются события tliSEnter и tliSLeave соответственно. Дело в том, что в TL-интерфейсе отсутствует событие, информирующее об объявлении переменной. Это значит, что локальная переменная, для которой мы получили событие tliVar, может быть объявлена не только в текущем блоке, но и в любом блоке, который его объемлет, вплоть до блока, представляющего собой тело функции. Решить эту проблему в рамках стандартного TL-интерфейса не представляется возможным. Разработчик отладчика может следовать одной из двух стратегий: либо предполагать, что каждая переменная инициализируется начальным значением, и первое событие tliVar определяет точку определения переменной, либо предполагать, что блочные переменные в TTCN-3 программе отсутствуют. Другими словами, при этом подходе всегда следует предполагать, что локальные переменные объявляются только на уровне тела функции. Последнее ограничение для целей отладки не является существенным, и оно было принято в нашей реализации. Действительно, в TTCN-3 перекрытие имен не разрешается, одноименные переменные не могут быть объявлены в разных блоках, если один из них вложен в другой. Поэтому единственным неудобством для пользователя является, что значение «блочной» переменной будет видно в отладчике после выхода из блока вплоть до момента возврата из функции.

4.4.3. Формальные параметры функций и тестовых сценариев Среди множества объектов, значения которых могут быть запрошены пользователем во время сеанса отладки, выделяются фактические параметры функции и тестового сценария. Значения всех фактических параметров передаются посредством атрибутов события tliSEnter. К сожалению, список значений фактических параметров не содержит имен этих параметров, как они определены в TTCN-3 программе, и получить имена параметров каким-либо другим образом нельзя. В качестве одного из вариантов, отладчик может поддерживать псевдонимы для формальных параметров, например, присваивая им имена вида @. @1 для первого параметра, @2 – для второго и т.д. Разумеется, такое решение является нестандартным. 147

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

5. Обработка таймеров выполнения

в

отладчике

времени

В языке TTCN-3 имеется встроенная поддержка таймеров. Для таймеров определен набор операций, в число которых входят операция запуска и остановки таймера, проверка того, истекло ли время таймера и т.д. Понятие времени в TTCN-3 не является жестко закрепленным и определяется пользователем путем реализации соответствующих операций в интерфейсе времени выполнения TRI. Как правило, понятие времени в тестовом сценарии соответствует понятию реального времени, но, вообще говоря, время может быть ускоренным или замедленным вариантом реального времени, событийным или каким-либо еще. В отладчике времени выполнения остановка тестового сценария в контрольной точке, если к этому моменту активен хотя бы один таймер, может привести к некорректному поведению тестового сценария после возобновления выполнения. Таймеры, активные в момент выхода на контрольную точку, необходимо отключать на время простоя в этой контрольной точке. Действительно, рассмотрим пример: timer T; T.start(3.0); //запустить таймер на 3 секунды P.send(Request); alt { []P.receive {setverdict(pass)} // тест прошел []T.timeout {setverdict(fail)} // тест _НЕ_ прошел } В этом примере таймер T устанавливается на три секунды, и затем через порт P отправляется сообщение Request. После этого тестовый сценарий ожидает прихода одного из двух событий: либо в порт P приходит какой-то ответ, и тогда вердикт теста устанавливается в pass (т.е. «тест прошел»), либо истекает время таймера T, и вердикт устанавливается в fail (т.е. «тест не прошел»). Таймер T предназначен для проверки того, что обмен данными через порт P (запрос-ответ) укладывается в три секунды. Предположим, что посылка и прием сообщения в совокупности занимают две секунды. В этом случае тест пройдет успешно. Если приостановить выполнение тестового сценария на десять секунд после запуска таймера, но перед отправкой сообщения, то в 148

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

6. Заключение В этой статье предложен подход к реализации отладчика для языка TTCN-3 на базе стандартного интерфейса регистрации событий TCI-TL. Показано, что TL-интерфейс позволяет реализовать типовые операции отладки, такие как установка контрольных точек, пошаговая трассировка, просмотр стека вызовов функций и значений объектов (переменных, констант, параметров модуля). Предложенный подход лег в основу реализации отладчика в среде Telelogic Tester. Ряд ограничений TL-интерфейса не позволяет реализовать операции отладки с той семантикой, которую они имеют в таких широко используемых отладчиках, как WinDbg, gdb, dbx и др. Для устранения наиболее критичных ограничений достаточно внести три изменения в интерфейсы времени выполнения языка TTCN-3: • добавить в TL интерфейс операцию tliSChange, которая информирует об изменении текущей позиции (в исходном TTCN-3 файле) потока управления во время выполнения тестового сценария; • в операции tliVar, информирующей об изменении значения переменной, сообщать имя переменной вместе с префиксом, по которому можно определить характер переменной; для переменных и констант, объявленных на компоненте, таким префиксом является имя типа компоненты, для констант, объявленных на уровне модуля, таким префиксом является имя модуля; • добавить в TCI интерфейс две операции, позволяющие запросить имена формальных параметров функции (например, tciGetFunctionParametersNames) и тестового сценария (например, tciGetTestCaseParametersNames) по соответствующему имени. Отметим, что отладчик, реализованный на базе стандартного TL-интерфейса, не зависит от конкретной среды разработки для языка TTCN-3. Более того, для отладчика не существенно, компилируется или интерпретируется TTCN-3 код, в какой целевой язык он компилируется и на какой целевой платформе исполняется. В дальнейшем планируется провести исследование и реализовать в отладчике обработку таймеров в контрольных точках и возможность изменения значений переменных. 149

Литература [1] ETSI. Methods for Testing and Specification (MTS). The Testing and Test Control Notation version 3; Part 1 TTCN-3 Core Language; ETSI ES 201 873-1, V3.2.1, 2007 [2] ETSI. Methods for Testing and Specification (MTS) .The Testing and Test Control Notation version 3; Part 5 TTCN-3 Runtime Interface (TRI); ETSI ES 201 873-5, V3.2.1, 2007 [3] ETSI. Methods for Testing and Specification (MTS) .The Testing and Test Control Notation version 3; Part 6 TTCN-3 Control Interface (TCI); ETSI ES 201 873-6, V3.2.1, 2007 [4] B. Beizer. Software Testing Techniques, 2nd Edition. New York. Van Nostrand Reinhold. 1990 [5] Extensible Markup Language (XML) 1.0, W3C Recommendation, 1998 [6] Message Sequence Chart (MSC), ITU-T Recommendation Z.120, 1999 [7] S. Burton, A. Baresel, I. Schieferdecker. “Automated testing of automotive telematics systems using TTCN-3”. Proceedings of 3rd Workshop on Systems Testing and Validation. Paris, France. 2004 [8] I. Schieferdecker, J. Grossmann. “Testing of Embedded Control Systems with Continuous Signals”. Proceedings of 2nd Workshop on Modeling of Embedded Systems. Dagstuhl. Germany. 2006 [9] M. Li, A. Rennoch, I. Schieferdecker, D. Witaszek, O. Halabi, A. Vouffou, A. Yin, “Experience Report on Conformance Tests for CORBA ORBs”. Proceedings of Second Asia-Pacific Conference on Quality Software. Hong Kong. 2001 [10] I. Schieferdecker, G. Din, D. Apostolidis. “Distributed functional and load tests for Web services”. International Journal on Software Tools for Technology Transfer. Volume 7. Number 4. 2005 [11] I. Schieferdecker, A. Rennoch, E. Höfig. “TTCN-3 – A Test Technology for the Automotive Domain” Proceedings of Simulation und Test in der Funktions und Softwareentwicklung für die Automobilelektronik. Berlin. Germany. 2005 [12] I. Schieferdecker, A. Rennoch. “Industrial use of TTCN-3 – Scope and Limits”, International Conference on Software Tests. Düsseldorf. Germany. 2005 [13] G. Din, J. Zander, S. Pietsch. “Test exectution logging and visualization techniques”. Proceedings of Software and Systems Engineering and their Applications. Paris. France. 2004 [14] S. Schulz, T. Vassiliou-Gioles. “Implementation of TTCN-3 Test Systems using the TRI”, Proceedings of 14th International Conference on Testing Communicating Systems. Berlin. Germany. 2002 [15] I. Schieferdecker, T. Vassiliou-Gioles. “Realizing distributed TTCN-3 test systems with TCI”. Proceedings of 15th International Conference on Testing Communicating Systems. Cannes. France. 2003 [16] C. Willcock, T. Deiß, S. Tobies, S. Schulz, S. Keil, F. Engler. “An Introduction to TTCN-3”. Wiley. 2005 [17] J. Robbins. “Debugging Applications for Microsoft® .NET and Microsoft Windows®”. Microsoft Press. 2003 [18] R. M. Stallman, R. H. Pesch, S. Shebs. “Debugging with GDB“. GNU Press. 2003 [19] B. Tuthill, K.J. Dunlap, "Debugging with dbx". UNIX Programmer's Supplementary Documents, vol. 1. Computer Systems Research Group. Dept. of Electrical Eng. and Computer Science. Univ. of California. Berkeley. 1986

150

[20] M. Hof. “Post Mortem Debugger for Oberon”. Procedings of Joint Modular Languages Conference, Ulm. Germany. 1994 [21] В.А.Крюков, Р.В.Удовиченко. "Отладка DVM- программ". Программирование . 2001. № 3

151

Язык модификации данных формата XML функциональными методами Д.А. Лизоркин [email protected] Аннотация: Задача внесения модификаций в данные формата XML является актуальной по природе слабоструктурированных данных. До настоящего времени не был разработан такой язык модификации XML-данных, который бы выступал в роли общепризнанного мирового стандарта. В данной статье предлагается язык модификации XML-данных, в основу которого были положены функциональные методы программирования и язык функционального программирования Scheme. Функции, являющиеся в языках функционального программирования объектами первого класса, используются в предлагаемом языке модификации XML-данных в роли обработчиков для операций модификации, что позволяет достичь выразительной мощности и расширяемости набора операций модификации при сохранении синтаксической простоты языка. Производится анализ алгоритмической сложности выполнения операций предлагаемого языка и рассматриваются детали его реализации функциональными методами.

1. Введение Популярность языка разметки XML в качестве формата для хранения, передачи и обработки слабоструктурированных данных делает актуальной для практических приложений потребность в языке модификации XMLдокументов. Несмотря на актуальность данной задачи, доминирующее внимание консорциума W3C, которому принадлежит авторство большинства спецификаций платформы XML [1], в предыдущие годы было направлено на язык запросов из XML-документов [2], и работа над языком модификации XML-данных была начата в Консорциуме сравнительно недавно [3] и в настоящий момент находится в черновом статусе. В настоящей статье предлагается язык модификации XML-документов, основанный на подходе к обработке XML-данных функциональными методами, в частности, с помощью языка функционального программирования Scheme. Благодаря близкому соответствию иерархической структурой XML-документа вложенным спискам языка функционального 153

программирования Scheme и свойству функций Scheme быть объектами первого класса обеспечивается выразительная гибкость предлагаемого языка модификаций и минимизируется проблема потери соответствия [4] по сравнению с другими существующими языками модификации XMLдокументов. Подход к обработке XML-данных функциональными методами базируется на формате SXML — представлении XML-документов в виде вложенных списков, текстуально записываемых при помощи S-выражений. Языки SXML и XML могут рассматриваться как два синтаксически различных представления Информационного Пространства XML [5]. Для демонстрации соответствия между вложенными тегами XML и вложенными списками SXML, на рис. 1 приведен пример простого XML-документа и его представления на SXML. Каждая из информационных единиц Информационного Пространства XML представляется в виде S-выражения, первым членом которого является либо имя информационной единицы (для типов элемент и атрибут), либо служебное имя, предусмотренное для информационной единицы данного типа в грамматике SXML [6]. Заметим, что спецификация SXML обеспечивает поддержку пространств имен XML, и существует парсер, позволяющий для заданного XML-документа сконструировать его представление на SXML [7]. <doc> Text node <empty/>

(*TOP* (*PI* xml "version='1.0'") (doc (tag (@ (attr1 "value1") (attr2 "value2")) (nested "Text node") ) (empty) ))

Рис. 1: XML-документ (слева) и его представление в SXMLУниверсальность представления на SXML узлов всех типов обеспечивает простоту обработки документов формата SXML, а функции Scheme, обладающие свойством объектов первого класса, позволяют прозрачным образом интегрировать конструкции предлагаемого в настоящей статье языка модификации с пользовательскими действиями приложения. Необходимо сразу же отметить, что в функциональной парадигме программирования под модификацией данных понимается нечто отличное от модификации в контексте процедурной и объектно-ориентированной парадигм программирования. Чисто функциональный стиль подразумевает отсутствие в программе побочных эффектов, что исключает такие широко принятые в процедурном и объектно-ориентированном подходе операции как присваивание новых значений глобальным переменным или перестановка 154

указателей [9]. Модификация в функциональном стиле является операцией, не разрушающей исходные данные, и модификация исходного документа осуществляется за счет конструирования нового документа. Благодаря отсутствию в программе побочных эффектов, для конструирование модифицированного документа не требуется глубокое копирование исходного документа [8], но, как более подробно обсуждается в разделе 6, неизменные в результате модификации части документа используются в виде единой физической копии для его исходной и результирующей версий [9]. Приложение само решает, каким образом обрабатывать исходный и модифицированный документы. Например, приложение может использовать исходный документ лишь в локальном блоке своего кода, и тогда части, специфичные для исходного документа, будут освобождены автоматическим сборщиком мусора при выходе программы из данного локального блока [10]. Вопрос обеспечения работы нескольких конкурентных приложений над общим документом вкратце затрагивается в разделе будущих исследований, и его детальное исследование находится за пределами данной статьи. Дальнейшее содержание статьи организовано следующим образом. В разделе 2 дается обзор существующих языков модификации XML-данных и обсуждаются преимущества функционального подхода. В разделе 3 предлагается идея использование функций в качестве обработчиков для операций модификации, иллюстрируется выразительность данного подхода и показывается, как с помощью обработчиков могут быть выражены наиболее распространенные операции существующих языков модификации. В разделе 4 идея обработчиков расширяется возможностью согласованной обработки нескольких узлов документа, что позволяет естественно реализовать такие операции модификации, как перемещение поддеревьев. В разделе 5 вводится сокращенный синтаксис для наиболее употребительных конструкций предлагаемого языка модификаций. Раздел 6 посвящен деталям реализации предлагаемого языка модификаций функциональными методами программирования. Вопрос алгоритмической сложности вычисления запросов на модификацию предлагаемого языка рассматривается в разделе 7. Будущие исследования обсуждаются в разделе 8. Раздел 9 завершает статью.

2. Существующие языки модификации XML-данных До настоящего времени какого-либо единого стандарта языка модификации XML-данных не существовало. Так, разработанный консорциумом W3C язык запросов к XML-данным XQuery [2] в своей текущей версии является языком, предназначенным лишь для выборки данных и не предоставляющим никаких средств для внесения модификаций в XML-документы. С другой стороны, ввиду большого распространения технологии XML и естественности задачи внесения модификации в XML-данные для практических приложений, имеется ряд разработанных промышленных и академических языков для модификации XML-данных. 155

При анализе существующих языков модификации XML-данных в первую очередь необходимо отметить работу [11], в которой предлагается детально проработанный язык модификации с описанной формальной семантикой, который является расширением XQuery. По аналогии с понятием запроса в языке XQuery в языке модификаций, предлагаемом в [11], вводится понятие запроса на модификацию (update query). Запрос на модификацию состоит из одной или нескольких операций модификации (update expression), где каждая операция модификации производит некоторое базовое действие над обрабатываемым XML-документом. В работе [11] вводятся следующие виды операций модификации: • • • •

вставка нового узла в дерево документа; удаление узла; замена узла новым узлом; переименование узла.

Для выбора узлов XML-документа, подлежащих изменению данной операцией модификации, в [11] используется язык адресации структурных частей XML-документа XPath [12]. По семантике вычисления запроса на модификацию, операции модификации, входящие в запрос, независимы друг от друга: изменения, производимые в XML-документе одной операцией модификации, не учитываются при выборе узлов, подлежащих изменению другой операцией модификации. Несмотря на то что набор введенных в [11] операций модификации позволяет выразить любое необходимое изменение XML-документа [13], в языке отсутствует возможность расширения функциональности этих операций или добавления пользовательских операций. В настоящей статье семантика операций модификации определяется с помощью обработчика, представляющего собой произвольную функцию с заданной сигнатурой, благодаря чему достигается полная выразительная мощность языка модификаций из [11] и обеспечивается возможность для приложения по определению собственных операций модификации, равноправных с базовыми операциями вставки, удаления, замены и переименования узлов. Необходимо также отметить, что в языке модификаций, предложенном в [11], не предоставляется важной операция перемещения поддеревьев [13] и предлагается реализовывать ее, как комбинацию операций удаления и вставки узлов. Хотя операция перемещения действительно может быть реализована таким образом, в работе [11] не предоставляется никаких средств по обеспечению согласованности операций удаления и вставки при их комбинации с целью получения эффекта перемещения поддерева. В настоящей статье разработывается механизм зависимой обработки совокупности из нескольких узлов, благодаря которому достигается возможность согласованной модификации узлов, расположенных в разных частях документа, и, в частном случае, функциональность операции 156

перемещения поддеревьев. Разработанный сокращенный синтаксис языка модификаций предоставляет приложению возможность записи операции перемещения поддеревьев в виде наглядного выражения. Язык модификации XML-данных, предлагаемый в работе [14], также разработан как расширение к XQuery, и в нем используются богатые возможности XQuery по адресации частей обрабатываемого документа и конструированию новых узлов. Несмотря на всю мощность XQuery как языка запросов, при реализации на его основе языка модификаций авторам работы [14] потребовалось расширить язык XPath, являющийся составной частью XQuery, возможностью явной адресации значения конкретного атрибута. Проблема адресации отдельного значения атрибута с целью его модификации не возникает в SXPath — реализации XPath на языке функционального программирования Scheme, — поскольку SXPath позволяет обрабатывать элементы и атрибуты унифицированным образом ввиду их однородного способа представления на SXML [15]. В работе [14] вводится операция суб-модификации (sub-update), позволяющая производить поиск других узлов относительно целевого узла модификации и осуществлять для них рекурсивный вызов операции модификации. По своему назначению операция суб-модификации схожа с предлагаемым в настоящей работе механизмом зависимой обработки совокупности из нескольких узлов. При этом предлагаемый механизм обладает большей декларативностью по сравнению с операцией суб-модификации. Более декларативным является и предлагаемый в настоящей работе способ задания обрабатываемых узлов, подлежащих модификации. Для сравнения, в языке модификации, разработанном в [14], итерация по обрабатываемым узлам полностью перекладывается на прикладного программиста, что приводит к необходимости использования чрезмерно большого числа итеративных конструкций (for-update) в запросах на модификацию. Необходимо также отметить, что в работе [14] язык модификаций исследовался в контексте хранения XML-документов в реляционной базе данных, ввиду чего у авторов упомянутой работы возникли проблемы реализационного характера по поддержанию корректной контекстной позиции узлов при вставке нового содержимого между существующими данными [14]. В разрабатываемом группой XML:DB языке модификации XML-документов XUpdate [16] вводится набор операций, аналогичный уже рассмотренным, и для записи запросов на модификацию используется язык XML и специальное пространство имен. Язык XUpdate пока развит хуже по сравнению с рассмотренными выше работами [11] и [14], и до настоящего времени находится в черновом статусе разработки.

157

3. Операция модификации как обработчик узла Модификация на предлагаемом в данной статье языке выражается с помощью декларативного запроса, который мы по аналогии с введенной в [11] терминологией будем называть запросом на модификацию (update query). В контексте функциональных методов программирования можно говорить о том, что запрос на модификацию является атомарным в том смысле, что в реализации, детали которой будут обсуждаться в разделе 6, модификация осуществляется за один проход по дереву модифицируемого документа. Запрос на модификацию может состоять из одной или нескольких операций модификации, где операция модификации предназначена для выполнения некоторого базового действия над частью обрабатываемого документа. Каждая операция модификации адресуется к набору некоторых узлов в документе и выполняет модификацию каждого узла данного набора по отдельности. Анализируя семантику предлагаемых в [11] операций модификации, можно заметить, что любая из этих операций может быть в обобщенном виде представлена как пара значений: (выражение_XPath обработчик) ,

(1)

где выражение_XPath служит для выбора в обрабатываемом XMLдокументе набора узлов, подлежащих модификации, а обработчик специфицирует воздействие конкретной операции модификации на каждый из выбранных узлов. Обработчик может рассматриваться, как функция, которая получает на вход узел, подлежащий модификации, и возвращает результат воздействия конкретной операции модификации на данный узел. Предложенное представление операции модификации в виде пары значений получает естественную реализацию в терминах языка функционального программирования Scheme, поскольку в Scheme функции обладают свойством объектов первого класса. Функции как объекты первого класса могут, в частности, передаваться в качестве аргументов другим функциям, что позволяет нам рассматривать обработчик как черный ящик и, таким образом, абстрагироваться от внутренней реализации конкретного обработчика в дизайне языка модификаций. Рассматривая операцию модификации XML-данных в контексте языка функционального программирования Scheme и формата SXML, определим обработчик как функцию, имеющую следующую сигнатуру: (lambda (node) ...) ,

(2)

где node — это узел, подлежащий обработке с помощью данной операции модификации. Поскольку результат операции модификации естественным образом зависит от узла, подлежащего обработке, функция, введенная для представления обработчика, принимает данный узел в качестве аргумента. В 158

соответствии с тем значением, которое вернет обработчик, будет реализовываться та или иная операция модификации. Будем считать допустимыми возвращаемыми значениями обработчика либо единственный узел, либо набор узлов. В том случае, когда обработчик возвращает единственный узел, этот новый узел будет замещать собой в документе обрабатываемый узел (который был фактическим параметром для данного вызова обработчика). Если обработчик возвращает набор узлов, то этот набор узлов предполагается упорядоченным, и на место обрабатываемого узла в документе подставляются все узлы из полученного набора. В частности, если возвращаемый набор узлов пуст, то обрабатываемый узел удаляется из документа, и вместо него ничего не подставляется [17]. В соответствии с предложенным в данном разделе представлением операции модификации в виде пары значений, с помощью выражения_XPath будет выбираться набор узлов исходного документа, которые подлежат обработке в данной операции модификации. Каждый узел из выбранного набора рассматривается как обрабатываемый узел, и с ним, как с фактическим параметром, вызывается обработчик. Возвращаемый результат обработчика формирует новый узел или узлы, которые заменяют собой обрабатываемый узел. В частности, возвращаемый результат может включать в себя и сам обрабатываемый узел, что производит эффект добавления в дереве документа некоторых новых узлов к обрабатываемому узлу. Несмотря на простоту рассмотренной семантики обработчика и сопоставленного с ним выражения_XPath, предложенное представление операции модификации в терминах, приближенных к языку функционального программирования Scheme, обладает достаточно широкими возможностями для выражения разнообразных модификаций документов формата SXML. Далее в данном разделе рассматривается реализация с помощью идеи обработчиков некоторых наиболее употребительных операций модификации, затем обсуждаются возможности обработчиков при выражении более сложных операций модификации.

3.1. Реализация некоторых операций функциональными методами

модификации

В данном пункте показывается, как имеющиеся в работе [11] операции модификации получают естественное и лаконичное воплощение на языке функционального программирования Scheme при обработке документов в формате SXML.

3.1.1. Вставка нового узла в документ В работах [11] и [14] предлагается 3 разновидности операции вставки нового узла в документ: 159

• • •

вставка после (insert following), добавляющая новый узел сразу же после обрабатываемого узла таким образом, что они оба имеют общий родительский узел; вставка перед (insert preceding), добавляющая новый узел сразу же перед обрабатываемым узлом таким образом что они оба имеют общий родительский узел; вставка внутрь (insert into), добавляющая новый узел в качестве дочернего для обрабатываемого узла, последним по порядку документа (document order [12]).

В терминах SXML и функционального программирования эти операции вставки узла представляют собой простую комбинацию примитивов работы над списковыми структурами данных. Так, эффект “вставки перед” и “вставки после” достигается, когда обработчик формирует список, состоящий из добавляемого в документ нового узла и обрабатываемого узла. Соответственно, если в формируемом списке новый узел идет первым, то в дереве документа он будет добавлен перед обрабатываемым узлом (вставка перед), если вторым — то после обрабатываемого (вставка после). С целью параметризации обработчиков новым узлом, подлежащим вставке, обработчики реализуются как возвращаемый результат функции, которая и осуществляет необходимую параметризацию. Данный подход возможен благодаря тому, что функции Scheme являются объектами первого класса. Реализация обработчиков для “вставки перед” (insert preceding) и “вставки после” (insert following) приведена ниже: (define (insert-preceding new-node) (lambda (node) (list new-node node))) (define (insert-following new-node) (lambda (node) (list node new-node))) Заметим, что при параметризации каждой из записанных функций для нескольких разных значений нового узла new-node будет получено несколько разных обработчиков. Рассмотренный дизайн обработчиков по добавлению узлов в виде возвращаемых результатов функций удобен для приложения, поскольку подлежащий вставке новый узел new-node, как правило, известен на этапе формулирования операции модификации, тогда как обрабатываемый узел node становится известным только на этапе обработки дерева документа. При определении семантики операции “вставки внутрь” следует особо выделять случай, когда обрабатываемый узел является текстовым узлом, т.е. по определению не может содержать узлов, вложенных в него. Реакция на 160

подобную ситуацию может различаться в зависимости от нужд конкретного приложения; ниже показывается реализация, которая оставляет обрабатываемый текстовый узел без изменения: (define (insert-into new-node) (lambda (node) (if (not (pair? node)) ; текстовый node ; оставляем без изменения (append node (list new-node))))) В рассматриваемых далее в данном разделе примерах используются выражения модификаций, исходно предложенные в [11], и для них приводятся и обсуждаются аналоги на языке Scheme, записанные в терминах предлагаемой идеи обработчиков. Пример 1 Запрос, содержащий операцию модификации на “вставку перед”, в терминах синтаксиса, разработанного в [11], записывается в виде: UPDATE INSERT <warning>High Blood Pressure! PRECEDING //blood_pressure[systolic>180] В контексте предложенной в данной статье идеи использования обработчиков для выражения операций модификации, рассматриваемый запрос получает естественное эквивалентное воплощение на Scheme для обработки документов в форме SXML: (sxml:modify `("//blood_pressure[systolic>180]" ,(insert-preceding '(warning "High Blood Pressure!"))))

3.1.2. Удаление узла Операция удаления узла удаляет из документа обрабатываемый узел и все узлы, вложенные в него. Если рассматривать документ в виде дерева, то можно говорить о том, что в данной операции происходит удаление целого поддерева, корнем которого служит обрабатываемый узел. Выше в данном разделе при обсуждении семантики различных возвращаемых значений обработчиков было замечено, что эффект удаления узла достигается в том случае, когда обработчик возвращает в качестве результата пустой набор узлов. В терминах SXML пустой набор узлов представляется пустым списком языка Scheme, и поэтому удаление узла обеспечивает такой обработчик, который игнорирует обрабатываемый узел и всегда возвращает пустой список: (define delete (lambda (node) '())) Необходимо отметить, что в отличие от рассмотренных в предыдущем пункте обработчиков по вставке узла, обработчик для удаления узла не требует параметризации. Пример 2 Запрос на удаление узлов на языке модификаций, выработанном в работе [11], записывается следующим образом: UPDATE DELETE //blood_pressure[systolic>180] С использованием обработчика для удаления узла, эквивалентный запрос на модификацию документов формата SXML имеет на Scheme следующий вид:

Функция sxml:modify реализует запрос на модификацию, который может состоять из одной или более операций модификации. Операция модификации получает естественную нотацию в виде списка, состоящего из двух членов: выражения XPath и функции, играющей роль обработчика. Использованные при записи операции модификации выражения квази-цитирования (quasiquote, сокращенно обозначаемое символом "`") и снятия цитирования (unquote, сокращенно обозначаемое символом ",") показывают, что первый член списка представляет собой константное выражение, а второй член должен быть вычислен. Результатом функции sxml:modify является в свою очередь функция, которая и осуществляет обработку документа формата SXML. В полной аналогии с примером 1 реализуются примеры на “вставку после” и “вставку перед”, и единственное отличие заключается в использовании соответствующего обработчика для каждой из этих операций. 161

(sxml:modify `("//blood_pressure[systolic>180]" ,delete)) Заметим, что по сравнению с примером 1 в выражении языка Scheme поменялся только используемый обработчик. Благодаря гибкости предлагаемого подхода замена обработчика позволяет полностью изменить эффект производимой модификации.

3.1.3. Замена узла новым узлом Операция замены узла замещает обрабатываемый узел и всё его содержимое новым узлом, который задается в качестве параметра операции. Если рассматривать документ в виде дерева, то можно говорить о том, что в данной операции происходит замещение новым поддеревом целого поддерева, корнем которого служит обрабатываемый узел. Обработчик для замены узла новым узлом во многом напоминает рассмотренные ранее обработчики для вставки узла с тем упрощением, что 162

теперь обрабатываемый узел node полностью игнорируется, и возвращаемым значением обработчика является новый узел new-node: (define (replace new-node) (lambda (node) new-node)) Пример 3 Запрос на замену узла новым узлом на языке модификаций, разработанном в [11], имеет следующий вид: UPDATE REPLACE //job[.="bit banger"] WITH <profession>Comp. Scientist С помощью предлагаемой в данной статье идеи эквивалентный результат достигается на Scheme так:

обработчиков

(sxml:modify `("//job[.='bit banger']" ,(replace '(profession "Comp. Scientist"))))

3.1.4. Переименование узла Операция переименования узла изменяет имя узла и оставляет неизменным его содержимое. Операция переименования осмысленна для узлов, которые обладают именами, т.е. для элементов и атрибутов. При обработке XML-данных на языке Scheme элементы и атрибуты выражаются в виде S-выражений единообразным образом, и имя всегда является первым членом S-выражения, соответствующего данному элементу или атрибуту. В случае, когда обрабатываемый узел не имеет имени (например, для текстового узла), в зависимости от семантики конкретного приложения может требоваться различная реакция обработчика. Рассмотрим такой вариант обработчика, который оставляет текстовый узел без изменения: (define (rename new-name) (lambda (node) (if (pair? node) ; именованный узел (cons new-name (cdr node)) node))) По аналогии с операциями вставки узла и замены узла новым узлом обработчик для переименования узла реализован как возвращаемый результат функции, которая осуществляет параметризацию обработчика новым именем new-name. Благодаря параметризации можно получить для нескольких разных значений нового имени new-name несколько разных обработчиков, 163

каждый из которых определяет переименование обрабатываемых узлов на соответствующее новое имя. Приведенное тело обработчика может быть легко дополнено функциональностью, позволяющей для узла типа “инструкция обработки” переименовывать ее указание адреса (PI target) [19], что сделает семантику рассматриваемой операции переименования узла полностью совместимой с [11]. Пример 4 Переименование узла в терминах языка модификаций [11] записывается в виде: UPDATE RENAME //job[.='bit banger'] AS "profession" С использованием предлагаемой идеи обработчиков, эквивалентный запрос на модификацию может быть записан на Scheme так: (sxml:modify `("//job[.='bit banger']" ,(rename 'profession))) Здесь 'profession имеет тип данных символ, и этот тип данных используется в SXML для представления имен элементов и атрибутов.

3.2. Возможности языка Scheme по выражению операций модификации Помимо рассмотренных в предыдущем пункте примеров конкретных обработчиков для наиболее употребительных операций модификации, этими операциями далеко не ограничивается возможности, которые предоставляет приложению использование предложенной идеи обработчиков. При определении обработчиков и, тем самым, операций модификации над документами формата SXML приложению становятся доступны выразительная мощность языка программирования общего назначения Scheme и большой набор стандартных функций для работы со списковыми структурами данных. В частности, конструкторы различных типов узлов реализуются на Scheme конструкторами списков. Более того, наличие в языке Scheme выражений квази-цитирования (quasiquote) и снятия цитирования (unquote) позволяет компактным и наглядным образом комбинировать константные выражения и фрагменты вычисляемых выражений [18]. Аналогичные идеи используются в синтаксисе XSLT для комбинирования литеральных элементов результата [1] и исполняемых инструкций. Тело обработчика может включать в себя вызовы библиотеки SXPath — реализации языка XPath на Scheme, — что позволяет приложению 164

адресоваться к структурным частям обрабатываемого SXML-документа в соответствии со взаимоотношением этих частей с обрабатываемым узлом как контекстным узлом XPath. Примитивы map и filter языка Scheme обеспечивают приложение при работе с узлами SXML-документа возможностями итерирования и фильтрации последовательности узлов в терминах языка запросов к XMLдокументам XQuery. Арифметико-логические и условные выражения языка XQuery реализуются на Scheme соответствующими стандартными функциями. Благодаря возможности использования в теле обработчика произвольного выражения языка программирования общего назначения Scheme и интегрированности Scheme с узлами SXML-документа на уровне списковых структур данных, предложенная в данной статье идея обработчиков обеспечивает приложение выразительным и мощным механизмом для определения операций модификации.

4. Зависимая обработка нескольких узлов Хотя предложенные в предыдущем разделе обработчики узлов обеспечивают достаточно богатые возможности по выражению операций модификации документов, операции типа перемещения поддерева из одного места в документе на другое место обработчиками рассмотренного вида не покрываются. Это объясняется тем, что обработчик вида, рассмотренного в предыдущем разделе, является функцией только от одного обрабатываемого узла, тогда как операция перемещения затрагивает сразу два узла: исходное местонахождение поддерева и его желаемое новое положение. В обобщенном случае можно говорить о том, что обработчиками, рассмотренными в предыдущем разделе, не могут быть выражены такие операции модификации, которые включают в себя зависимую обработку сразу нескольких узлов, располагающихся в разнесенных друг от друга местах обрабатываемого дерева документа. Позиционирование операции перемещения поддерева как одной из базовых операций редактирования древовидных структур данных [13] мотивирует дальнейшее расширение предлагаемой в данной статье идеи обработчиков возможностью осуществлять перемещения поддеревьев1. Необходимо отметить, что в работе [11] операция перемещения не обеспечивается, и вместо этого предлагается имитировать ее как независимое последовательное применения операций удаления и вставки, причем никаких средств согласованного использования этих двух операций не предоставляется. 1

Название операции “перемещение поддерева” выбрано в соответствии с терминологией, введенной в работе [13]. В контексте предлагаемой в настоящей статье идеи обработчиков, корень поддерева, подлежащего перемещению, задается обрабатываемым узлом. 165

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

4.1. Базовый узел Базовым узлом для операции модификации назовем такой узел, относительно которого вычисляется выражение_XPath данной операции модификации. Поскольку при помощи выражения XPath в операции модификации выбираются обрабатываемые узлы, можно говорить о том, что базовый узел определяет те узлы, которые выбираются, и, соответственно, обрабатываются в данной операции модификации. Как отмечалось в разделе 1, запрос на модификацию состоит, вообще говоря, из нескольких операций модификации, которые можно считать упорядоченными между собой. Считаем, что базовым узлом для первой по 166

порядку операции модификации в данном запросе на модификацию всегда является корневой узел обрабатываемого документа. Для последующих по порядку операций модификации корневой узел обрабатываемого документа служит базовым узлом в том и только том случае, если выражение_XPath данной операции модификации является абсолютным путем доступа (absolute location path) [12]. Если в операции модификации используется выражение_XPath другого вида, например, относительный путь доступа (relative location path), то в этом случае базовым узлом последовательно считается каждый из обрабатываемых узлов предыдущей операции модификации данного запроса на модификацию. Сформулированное правило сопоставления базового узла с конкретной операцией модификации хорошо согласуется с семантикой вычисления путей доступа в спецификации XPath: абсолютный путь доступа вычисляется относительно корневого узла документа, а относительный путь доступа — относительно контекстного узла контекста вычисления. Использование относительного пути доступа XPath в операции модификации связывает эту операцию с предыдущей, и вычисление набора узлов, подлежащих обработке, осуществляется способом, во многом напоминающем вычисление последовательности шагов доступа в языке XPath: • • •

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

Расширим сигнатуру обработчика (являющегося функцией в подходе, предлагаемом в данной статье) вторым параметром — базовым узлом операции модификации: (lambda (node base-node) ...) . (3) Рассмотренные в разделе 3 обработчики для наиболее употребительных операций модификации могут быть очевидным образом расширены на предмет наличия в сигнатуре обработчика нового аргумента base-node. Ввиду того, что базовый узел не влияет на результаты обработчиков для обсуждавшихся в разделе 3 наиболее употребительных операций модификации, базовый узел добавляется в эти обработчики просто в качестве фиктивного параметра. С другой стороны, из расширенной базовым узлом сигнатуры обработчика легко видеть, что теперь он позволяет осуществлять зависимую обработку сразу двух узлов. Выразительные возможности языка XPath по адресации 167

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

4.2. Перемещение поддерева При наличии введенного понятия базового узла перемещение поддерева может быть реализовано совокупностью двух операций модификации. На основе рассмотренной семантики вычисления нескольких операций модификации узел – корень поддерева, подлежащего перемещению, – может выступать в роли обрабатываемого узла для первой из двух операций модификации и в роли базового узла — для второй операции. Эффект перемещения поддерева достигается тогда, когда первая операция модификации удаляет свой обрабатываемый узел из документа, а вторая операция вставляет в документ свой базовый узел (являющийся обрабатываемым узлом для предыдущей операции модификации). Поскольку обе операции являются компонентами единого запроса на модификацию, влияние этих операций на обрабатываемый документ атомарно и с точки зрения реализации осуществляется за один проход по дереву документа. Введенное правило вычисления базового узла естественным образом подходит для операции перемещения поддерева, потому что в практических задачах модификации новое местоположение перемещаемого поддерева часто задается относительно его исходного местоположения, и как раз при этом условии обрабатываемый узел первой из двух операций модификации, осуществляющих перемещение, становится базовым узлом для второй операции модификации. Поскольку перемещение поддерева включает в себя удаление поддерева в его старом местоположении и вставку поддерева в новое местоположение, при формализации соответствующих действий в виде обработчиков могут быть почти без изменений использованы обработчики, рассмотренные в разделе 3. В зависимости от различных способов вставки перемещаемого поддерева на его новое местоположение разумно различать такие варианты, как “перемещение перед”, “перемещение после” и “перемещение внутрь”, соответствующие аналогичным вариантам операции вставки узла. Пример 5 Предположим, что электронная версия некоторой книги состоит из элементов с именем глава (chapter), и каждая глава содержит элементы с именем параграф (para). Переместим последний параграф главы, имеющей заголовок “Введение” (“Introduction”), в следующую по порядку главу в качестве ее первого параграфа. 168

Запрос на желаемую модификацию реализуется следующей совокупностью из двух операций модификации, связанных друг с другом посредством базового узла: (sxml:modify `("/book/chapter[title='Introduction']/ para[last()]" ,(lambda (node base-node) '())) `("following::chapter[1]/para[1]" ,(lambda (node base-node) (list base-node node)))) Первая операция модификации выбирает параграф, подлежащий перемещению, и удаляет его по месту его исходного положения. Обрабатываемый параграф, удаленный из документа первой операцией модификации, тем не менее, является базовым узлом для второй операции модификации, поскольку во второй операции модификации в качестве выражения XPath используется относительный путь доступа. Вторая операция модификации осуществляет вставку перемещаемого параграфа – базового узла base-node – перед первым по счету параграфом главы, следующей за главой с заголовком “Введение”. Совокупный эффект обоих операций модификации рассматриваемого примера обеспечивает желаемое перемещение узла. Необходимо отметить, что обе операции модификации рассмотренного примера являются составляющими одного запроса на модификацию, и поэтому с точки зрения реализации, детали которой обсуждаются в разделе 6, выполняются за один проход по дереву обрабатываемого документа.

Предлагаемые правила сокращенного синтаксиса для наиболее употребительных операций модификации приведены в табл. 2. Для операций модификации, требующих параметризации обработчиков (например, для вставки или переименования узлов), необходимые дополнительные параметры в сокращенном синтаксисе записываются после ключевого слова, идентифицирующего операцию модификации. Необходимо также заметить, что каждая из операций перемещения поддерева, представленная в табл. 2 одним списком, переписывается в терминах полного синтаксиса в совокупность из двух операций модификации, связанных друг с другом посредством базового узла. При перезаписи из сокращенного синтаксиса в полный синтаксис дополнительный параметр операции перемещения поддерева становится первым членом пары, выражающей вторую из двух операций модификации, в совокупность которых переписывается данная операция перемещения. операция_модификации_в_сокращенном_синтаксисе ::= `( ,выражение_XPath delete ) | `(,выражение_XPath insert-following,добавляемый_узел_на_SXML)| `(,выражение_XPath insert-preceding,добавляемый_узел_на_SXML)| `(,выражение_XPath insert-into ,добавляемый_узел_на_SXML)| `(,выражение_XPath replace ,заменяющий_узел_на_SXML)| `(,выражение_XPath rename ,новое_имя_узла)| `(,выражение_XPath move-following ,выражение_XPath-новое_место_узла)| `(,выражение_XPath move-preceding ,выражение_XPath-новое_место_узла)| `(,выражение_XPath move-into ,выражение_XPathновое_место_узла)Табл. 2: Сокращенный синтаксис для наиболее

употребительных операций модификации

5. Сокращенный синтаксис для описания модификаций Используемое в предыдущих разделах представление операции модификации в виде пары (выражение_XPath обработчик) может рассматриваться как полный синтаксис записи операции модификации. Помимо полного синтаксиса, являющегося универсальным для широкого класса операций модификации, в данной статье также предлагается сокращенный синтаксис для записи некоторых наиболее употребительных операций модификации. Для рассмотренных выше операций вставки, удаления, переименования узла и т.п. предлагается идентифицировать каждую из этих операций своим ключевым словом, которое выражается типом данных “символ” языка Scheme. Благодаря быстроте операции сравнения в Scheme двух символов [20], при перезаписи запроса на модификацию из сокращенной формы записи в полную форму введенные ключевые слова можно быстро заменить сопоставленными им обработчиками. 169

Помимо уменьшения чисто текстуального размера запроса на модификацию, предлагаемый сокращенный синтаксис также обеспечивает большую наглядность благодаря тому, что позволяет избавиться от функций в теле запроса на модификацию, и вместо них используются более привычные строки, символы и списки. По сравнению с полным синтаксисом, сокращенный синтаксис обладает тем важным преимуществом, что может быть без потерь отображен на постоянное хранилище данных типа файла или на канал передачи данных, — тогда как тип данных функция, являющийся неотъемлемой частью полного синтаксиса, может существовать только во время вычисления программы, в оперативной памяти. Данное свойство сокращенного синтаксиса может быть полезно для таких областей применения предлагаемого языка модификации как генерация скрипта редактирования (edit script) в виде запроса на модификацию при определении различий между двумя деревьями [13]. 170

6. Реализация Предложенный в данной статье язык модификации XML-документов был реализован фукнциональными методами программирования на языке функционального программирования Scheme. Необходимо заметить, что функциональный стиль программирования подразумевает определенные правила, накладываемые на сделанную реализацию. А именно, чистый функциональный стиль запрещает использование в программе таких побочных эффектов, как изменение значений, однажды связанных с глобальными идентификаторами. В контексте выполненной реализации языка модификации функциональный стиль программирования означает сохранение в неизменном виде документа, подлежащего модификации, и конструирование нового документа, выражающего собой результат вычисление требуемого запроса на модификацию к исходному документу. В отличие от процедурной и объектно-ориентированной парадигм программирования, в которых модификация обычно реализуется как принудительное изменение исходных данных, функциональная парадигма программирования позволяет гарантировать, что данные, однажды связанные с идентификатором, останутся постоянными на протяжении всего времени, пока к этим данным есть доступ из какой-либо области программы [9]. Это свойство функционального программирования обладает тем важным преимуществом, что конструирование дерева модифицированного документа не требует глубокого копирования дерева исходного документа, и части, являющиеся общими для обоих деревьев, автоматически хранятся в единственной физической копии. Возможность использования физически разделяемого поддерева, общего для нескольких деревьев, иллюстрируется на рис. 2. Предположим, что некоторый запрос на модификацию затрагивает узел, обозначенный на рис. 2 буквой О. Тогда в результате выполнения запроса на модификацию будут переконструированы только те части дерева обрабатываемого документа, которые обозначены на рис. 2 жирными линиями, а остальные части дерева останутся неизменными и, таким образом, будут существовать в разделяемой физической копии для исходного и сконструированного деревьев. Из рис. 2 легко видеть, что модификация в SXML-документе некоторого узла затрагивает изменение этого узла и всех его узлов-предков. Поскольку на практике глубина XML-документов и соответствующих им SXML-документов обычно бывает небольшой, выполнение запроса на модификацию, выбирающего в документе лишь несколько узлов в качестве обрабатываемых, требует переконструирования только небольшой части модифицируемого документа. Узлы, остающиеся неизменными для исходной и модифицированной версий документа, существуют в единственной 171

физической копии, и обе версии документа адресуются к этим узлам по ссылкам.

Рис. 2: Пример дерева SXML-документа, в которым производится модификация узла. Буквой O обозначен обрабатываемый узел, жирными линиями выделены те части дерева, которые изменяются в результате модификации В зависимости от конкретной прикладной задачи, приложение, использующее функциональную реализацию предлагаемого языка запросов, само определяет, каким образом обрабатывать исходную и сконструированную новую версию модифицируемого SXML-документа. Например, приложение может использовать исходную версию документа только в локальном блоке своего кода, и тогда узлы, специфичные для исходной версии документа и не используемые в других местах прикладной программы, будут освобождены автоматическим сборщиком мусора [10]. Соображения по вопросу обеспечения конкурентной обработки общего SXML-документа несколькими приложениями обсуждается в разделе 8. В сделанной реализации вычисление запроса на модификацию SXMLдокумента осуществляется в следующие два этапа: •

172

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

соответствуют разные базовые узлы. Для обработчиков, относящихся к одной операции модификации, очередность их применения принимается совпадающей с очередностью, которую имеют соответствующие обработчикам базовые узлы в порядке документа [12], подлежащего модификации. Введенная очередность применения обработчиков позволяет ввести логичную и интуитивно ясную семантику операции перемещения поддеревьев. А именно, ситуации, когда с одним узлом ассоциировано несколько обработчиков одной и той же операции модификации, соответствует такой запрос на перемещение, при котором несколько разных поддеревьев перемещается на общее новое место. Например, если все сноски в электронном представлении некоторой книги перемещаются в главу “Приложение”, то в соответствии с принятым соглашением об очередности применения обработчиков сноски попадут в эту главу в точности в том порядке, в котором они встречались по тексту, что полностью согласуется с интуитивным представлением об ожидаемом результате перемещения.

вызывать ни одного обработчика при определении базовых узлов для всех операций модификации. •

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

При вычислении выражений XPath, производимом на первом этапе обработки запроса на модификацию, желательно для каждого узла, выбранного выражением XPath, получить также все его узлы-предки, поскольку, как отмечалось выше, предков обрабатываемого узла в новой версии SXMLдокумента необходимо переконструировать. Для получения предков для узлов, адресуемых с помощью выражения XPath, была выбрана реализация XPath функциональными методами, обеспечивающая хранение предков контекстного узла в контексте вычисления и, благодаря этому, оптимизирующая вычисление обратных осей XPath [8]. Упомянутая реализация XPath позволяет получить результат вычисления выражения XPath в форме наборов контекстов, которые содержат всех предков для каждого из выбранных узлов SXML-документа. Наличие известных предков каждого из обрабатываемых узлов позволяет организовать целенаправленный обход дерева SXML-документа на втором этапе обработки запроса на модификацию. А именно, благодаря тому, что корень дерева обрабатываемого документа является предком для каждого из обрабатываемого узлов, и обход дерева осуществляется сверху вниз, для любого поддерева можно сразу же установить, какие из обрабатываемых узлов располагаются внутри данного поддерева. Если в некотором поддереве не содержится ни одного обрабатываемого узла, то обход поддерева вниз может быть прекращен, потому что поддерево остается неизменным в результате выполнения запроса на модификацию. Необходимо отметить, что семантика предлагаемого языка модификаций не противоречит тому, чтобы с одним и тем же узлом документа было ассоциировано сразу несколько обработчиков. Когда имеется несколько обработчиков, ассоциированных с одним узлом, результатом обработки данного узла служит суперпозиция применения обработчиков, и принимается следующая очередность применения обработчиков к узлу: • •

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

Выполненная реализация языка модификаций обеспечивает проверку корректности производимых модификаций в соответствии с условиями правильной сформированности XML-документов (XML well-formedness) [19]. В частности, производится проверка на отсутствие дублирующих атрибутов у данного элемента и атомарность значений атрибутов. По аналогии с языком запросов к XML-документам XQuery [2], сделанная реализация языка модификаций разрешает приложению в результате модификации элемента записывать его атрибуты и прочее содержимое в произвольном порядке. Поскольку в синтаксисе SXML атрибуты данного элемента должны быть вложены в общий список атрибутов, непосредственно следующий за именем элемента, реализация производит объединение списков атрибутов, если в результате модификации у данного элемента их получилось несколько, и переносит список объединенных атрибутов в позицию, непосредственно следующую за именем элемента и предшествующую всему прочего содержимому.

7. Алгоритмическая сложность В отношении алгоритмической сложности вычисления языка модификаций, предлагаемого в данной статье, можно сформулировать следующую теорему. Теорема 1 Введем следующие обозначения для характеристик запроса на модификацию и XML-документа, обрабатываемого с помощью данного запроса: n — количество узлов в обрабатываемом документе; m — количество операций модификации в запросе на модификацию; 174

kmax — максимальный размер выражения_XPath по всем операциям модификации [21]; T(n) — максимальное время работы каждого из обработчиков, присутствующих в запросе на модификацию. Время может зависеть от числа узлов в документе, например, в случае применения обработчика к корневому узлу документа; N(n) — суммарное количество новых узлов, добавляемых в документ в результате выполнения запроса на модификацию. Тогда время вычисления запроса на модификацию может быть оценено сверху следующим выражением: O( m·kmax·n6 ) + + m·n2·T(n+N(n)) + + O( (n+N(n))2·log2(n+N(n)) ) .

3.

Доказательство теоремы заключается в последовательном рассмотрении каждого из обозначенных этапов и получении верхней оценки времени вычисления по каждому этапу. 1.

(4) (5) (6)

Замечание 1 Рассмотренные в разделах 3 и 4 обработчики для наиболее употребительных операций модификации вычисляются за константное время. В справедливости данного замечания легко убедиться простым анализом реализаций рассмотренных обработчиков. Отметим, что те из обработчиков, которые требуют параметризации (например, узлом, добавляемым в документ, или новым именем узла), будучи параметризованы, выполняются за константное время. Сама параметризация относится к фазе статического анализа запроса на модификацию, равно как и разбор участвующих в запросе на модификацию выражений XPath. Замечание 2 Данной теоремой устанавливается гарантированное полиномиальное от размера документа и от количества операций модификации время вычисления произвольного запроса на модификацию, при условии, что T(n) и N(n) полиномиальны от своих аргументов, т.е. время выполнения каждого обработчика полиномиально от размера документа, и суммарное количество новых узлов, добавленных в документ в результате выполнения запроса на модификацию, полиномиально от размера исходного документа.

к этапу сопоставления обработчиков с узлами;

2.

к этапу обхода дерева документа и вызова обработчиков на обрабатываемых узлах; 175

Как обсуждалось в разделе 6, на этапе сопоставления обработчиков с узлами документа производится вычисление выражений_XPath всех операций модификации относительно базовых узлов этих операций. Ключевым моментом на данном этапе обработки является то, что в соответствии с семантикой предлагаемого в настоящей статье языка запросов максимальное количество базовых узлов для произвольной операции модификации не зависит от количества операций модификации в запросе на модификацию. Даже в том случае, когда все операции модификации в некотором запросе на модификацию связаны посредством базовых узлов (т.е. базовыми узлами каждой последующей операции модификации являются обрабатываемые узлы предыдущей операции модификации), максимальное количество базовых узлов для любой операции модификации не может превосходить общее число узлов в обрабатываемом документе, т.е. число n . Для вычисления выражений_XPath используется разработанная автором реализация XPath функциональными методами, которая включает в себя средства оптимизации [21], позволяющие получить гарантированную верхнюю оценку времени вычисления, равную: O( kmax·n5 ) . Выражения XPath вычисляются относительно каждого из базовых узлов каждой из операции модификации. Умножая время вычисления выражения XPath на количество базовых узлов (которых, как показано выше, не больше n для каждой операции модификации) и на количество операций модификации m, получим (4).

2.

Доказательство 1 (теоремы) Присутствующие в утверждении теоремы слагаемые, помеченные как (4), (5) и (6), относятся соответственно к следующим этапам вычисления запроса на модификацию: 1.

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

176

На этапе обхода дерева SXML-документа производится вызов обработчиков на обрабатываемых узлах и формирование нового дерева в соответствии с возвращаемыми результатами обработчиков. Количество обработчиков, которое может быть ассоциировано с одним узлом SXML-документа, не превосходит суммарного количества базовых узлов по всем операциям модификации, т.е. произведения m·n . Поскольку по семантике предлагаемого языка запросов несколько обработчиков, ассоциированных с одним и тем же узлом, вызываются по правилам суперпозиции, на время выполнения одного обработчика влияют узлы, которые могли быть добавлены в результате вызовов

предыдущих по порядку обработчиков, и поэтому это время оценивается сверху выражением T(n+N(n)). Произведение максимального времени работы одного обработчика на максимальное количество ассоциированных с одним узлом обработчиков и на количество узлов в исходном документе и дает (5). 3.

Производимые проверки корректности сделанных модификаций уже не зависят от вида запроса на модификацию или количества операций модификации в нем, но зависят только от сконструированного результирующего SXML-документа. В терминах введенных в условии теоремы обозначений, данное соображение означает, что временная оценка этапа проверки корректности сделанных модификаций зависит только от числа (n+N(n)), т.е. от количества узлов в новом SXMLдокументе. Среди производимых проверок асимптотически доминирует проверка на отсутствие у данного элемента нескольких атрибутов с одинаковыми именами. Проверка на отсутствие совпадающих имен атрибутов у данного элемента производится с помощью известного алгоритма сортировки слиянием по именам атрибутов данного элемента. Время работы алгоритма сортировки слиянием оценивается выражением O( (n+N(n))·log2(n+N(n)) ) .

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

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

данное утверждение справедливо для любого запроса на модификацию, который содержит по крайней мере один обрабатываемый узел 177

функциональными методами, выражается схемой “много читателей, один писатель”. В то время как одна транзакция осуществляет модификацию SXML-документа, остальные транзакции могут продолжать читать те части документа, которые не затрагиваются проводимой модификацией. Изолированность транзакций на уровне отсутствия чтения “грязных данных” [22] может быть реализована с помощью механизма блокировок древовидных структур [23] или мониторов Хоара. Целью текущих исследований является разработка таких методов изоляции транзакций, которые бы гарантировали отсутствие неповторяющихся чтений и проблемы фантомов, и которые бы в минимальной степени влияли на параллелизм транзакций.

9. Заключение Статья посвящена вопросу исследования и разработки языка модификации для XML-данных. Были проанализированы ограничения, присущие существующим языкам модификации XML-данных, и для преодоления этих ограничений были предложены функциональные методы программирования. При определении семантики действий, осуществляемой конкретной операцией модификации, было предложено использовать функции, обладающие в языке функционального программирования Scheme свойством объектов первого класса, в роли обработчиков для операций модификации. Представление XML-данных в виде списков формата SXML позволило — благодаря наличию в языке Scheme большого количества стандартных функций для работы со списками — в простой и лаконичной форме сформулировать обработчики для всех наиболее употребительных операций модификации. Для согласованного обеспечения операций модификации, подобных операции перемещения поддеревьев, была выработана более широкая возможность зависимой обработки сразу нескольких расположенных в разных местах документа узлов. Предложенная концепция зависимой обработки узлов естественным образом расширяет идею обработчиков благодаря введенному понятию базового узла операции модификации. Для возможности написания запросов на модификацию без явной передачи функций в тело запроса, был разработан сокращенный синтаксис для набора наиболее употребительных операций модификации. В отношении предложенного языка модификаций была сформулирована и формально доказана верхняя временная оценка, утверждающая гарантированное полиномиальное от размера документа и от количества операций модификации время вычисления любого запроса на модификацию, при условиях, что каждый обработчик выполняется за полиномиальное время и что суммарное количество новых узлов, добавляемых в документ в результате модификации, полиномиально от размера исходного документа. 178

Практическая применимость предложенных в статье идей была проиллюстрирована сделанной реализацией. Реализация использовалась при тестировании операций модификации в разрабатываемой в Институте системного программирования РАН XML-СУБД Sedna [24]. Список литературы [1] Когаловский М.Р. Глоссарий по стандартам платформы XML. Версия 7 (17-122006). // Электронные библиотеки. – М.: ИРИО, 2006. http://www.elbib.ru/index.phtml?page=elbib/rus/methodology/xmlbase/glossary_XML [2] The World Wide Web Consortium (W3C). XQuery 1.0: An XML Query Language : W3C Recommendation / Boag S. et al. (eds.). – 2007, 23 Jan. http://www.w3.org/TR/2007/REC-xquery-20070123/ [3] The World Wide Web Consortium (W3C). XQuery Update Facility 1.0 : W3C Working Draft / Chamberlin D. et al. (eds.). – 2007, 28 Aug. http://www.w3.org/TR/2007/WD-xquery-update-10-20070828/ [4] Лизоркин Д.А., Лисовский К.Ю. SXML: XML-документ как S-выражение // Электронные библиотеки. – М.: ИРИО, 2003. – Т. 6, вып. 2. – ISSN 1562-5419 = Russian digital libraries journal. http://www.elbib.ru/index.phtml?page=elbib/rus/journal/2003/part2/LK [5] The World Wide Web Consortium (W3C). XML Information Set : W3C recommendation / Cowan J., Tobin R. (eds.). – 2nd edition. – 2004, 4 Feb. http://www.w3.org/TR/xml-infoset/ [6] Kiselyov O. SXML specification / Rev. 3.0. – ACM SIGPLAN Notices. – New York: ACM Press, 2002. – Vol. 37, N 6. – pp. 52-58. – ISSN 0362-1340. http://okmij.org/ftp/Scheme/SXML.html [7] Kiselyov O. A better XML parser through functional programming : Proc. Practical Aspects of Declarative Languages: 4th int. symposium, PADL'2002, Portland, 1920 Jan., 2002 // Lecture Notes in Computer Science / Krishnamurthi S., Ramakrishnan C.R. (eds.). – Springer-Verlag Heidelberg, 2002. – Vol. 2257. – pp. 209-224. – ISSN: 0302-9743. http://www.okmij.org/ftp/papers/XML-parsing.ps.gz [8] Лизоркин Д.А. Оптимизация вычисления обратных осей языка XML Path при его реализации функциональными методами // Сборник трудов Института системного программирования РАН / Под ред. чл.-корр. РАН Иванникова В.П. – М.: ИСП РАН, 2004. – Т. 8, ч. 2. – 214 c. – с. 93-119. – ISBN 5-89823-026-2. http://modis.ispras.ru/Lizorkin/Publications/xpath-context.ps [9] Abelson H., Sussman G.J., Sussman J. Structure and Interpretation of Computer Programs. – 2nd ed. – London; New York: The MIT Press; McGraw Hill, 1996. – 657 pp. – ISBN 0-262-01153-0. http://mitpress.mit.edu/sicp/ [10] Boehm H.-J. Space efficient conservative garbage collection : Proc. conf. on Programming Language Design and Implementation (SIGPLAN'93), Albuquerque, NM, Jun. 1993 // ACM SIGPLAN Notices. – New York: ACM Press, 1993. – Vol. 28(6). – pp. 197-206; New York: ACM Press, 2004. – Vol. 39, issue 4. – pp. 490-501. – ISSN 0362-1340. http://citeseer.ist.psu.edu/259238.html [11] Lehti P. Design and Implementation of a Data Manipulation Processor for a XML Query Language : Ph.D. thesis. – 2001, Aug. www.lehti.de/beruf/diplomarbeit.pdf

179

[12] Консорциум W3C. Язык XML Path (XPath) версия 1.0 = XML Path Language (XPath) Version 1.0 : Рекомендация Консорциума W3C / Под ред. Clark J., DeRose S.; пер. с англ. Усманов Р. – 1999, 16 ноя. http://citforum.ru/internet/xpath/index.shtml [13] S. S. Chawathe, A. Rajaraman, H. Garcia-Molina and J. Widom. Change Detection in Hierarchically Structured Information. Technical report; detailed version of paper appearing in SIGMOD 1996. http://www-db.stanford.edu/c3/papers/html/tdiff3-8/tdiff3-8.html [14] Igor Tatarinov, Zachary G. Ives, Alon Y. Halevy, Daniel S. Weld. Updating XML : Proc. ACM SIGMOD int. conf. on Management of Data (SIGMOD'01), Santa Barbara, California, 21-24 May, 2001 // SIGMOD Conference / Aref W.G. (ed.). – New York: ACM Press, 2001. – pp. 413-424. – ISBN 1-58113-332-4. http://citeseer.comp.nus.edu.sg/603731.html [15] Лизоркин Д.А., Лисовский К.Ю. Язык XML Path (XPath) и его функциональная реализация SXPath // Электронные библиотеки. – М.: ИРИО, 2003. – Т. 6, вып. 4. – ISSN 1562-5419 = Russian digital libraries journal. http://www.elbib.ru/index.phtml?page=elbib/rus/journal/2003/part4/LL [16] A. Laux, L. Martin. XUpdate update language : XML:DB Working Draft. – 14 Sep, 2000. http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html [17] Лизоркин Д.А., Лисовский К.Ю. Реализация XLink – языка ссылок XML – с помощью функциональных методов // Программирование. – М.: Наука, 2005. – N 1. – С. 52-72. – ISSN 0361-7688 = Programming and computer software. [18] Лизоркин Д.А. Язык запросов к совокупности XML-документов, соединенных при помощи ссылок языка XLink // Сборник трудов Института системного программирования РАН / Под ред. чл.-корр. РАН Иванникова В.П. – М.: ИСП РАН, 2004. – Т. 8, ч. 2. – 214 c. – с. 121-153. – ISBN 5-89823-026-2; Программирование. – М.: Наука, 2005. – N 3. – ISSN 0361-7688 = Programming and computer software. [19] The World Wide Web Consortium (W3C). Extensible Markup Language (XML) 1.0 (Fourth Edition) : W3C Recommendation / Bray T. et al. (eds.). – 2006, 16 Aug. http://www.w3.org/TR/2006/REC-xml-20060816 [20] Лизоркин Д.А., Лисовский К.Ю. Пространства имен в XML и SXML // Электронные библиотеки. – М.: ИРИО, 2003. – Т. 6, вып. 3. – ISSN 1562-5419 = Russian digital libraries journal. http://www.elbib.ru/index.phtml?page=elbib/rus/journal/2003/part3/LL [21] Лизоркин Д.А. Функциональные методы обработки XML-данных / Ph.D. thesis = Диссертация на соискание ученой степени кандидата физико-математических наук по специальности 05.13.11. – 2005, 11 ноя. [22] Кузнецов С.Д. Современные технологии баз данных : Годовой курс для студентов 3-го курса. – Центр Информационных Технологий. http://citforum.ru/database/osbd/contents.shtml [23] Гарсиа-Молина Г., Ульман Дж.Д., Уидом Дж. Системы Баз Данных. Полный курс / Пер. с англ. Варакина С.А.; под ред. Слепцова А.В. – М,: Вильямс, 2003. – 1088 с.: ил. – ISBN 5-8459-0384-X (рус.) [24] Гринев М., Кузнецов С.Д, Фомичев А. XML-СУБД Sedna: технические особенности и варианты использования // Открытые системы. – 2004, вып 8. http://www.osp.ru/os/2004/08/185085/

180

Нечеткое сравнение коллекций: семантический и алгоритмический аспекты В.А. Семенов, С.В. Морозов, О.А. Тарлапан, И.В. Энкович1 Аннотация. Рассматривается задача нечеткого сравнения коллекций в приложениях реконсиляции. Задача возникает при оптимистической репликации структурированных данных и документов и имеет многочисленные приложения в таких актуальных областях, как управление конфигурацией программного обеспечения, управление мобильными базами данных, построение платформ и систем коллективной инженерии. В работе анализируются стандартные типы коллекций языков объектноориентированного моделирования, для которых описываются и обосновываются способы представления, журнализации, вычисления, принятия и согласования изменений. Для выделенных типов коллекций дается строгая, семантически содержательная интерпретация конфликтов и предлагаются конструктивные методы их идентификации и разрешения. Примеры иллюстрируют предлагаемые решения, а также служат мотивацией создания универсальной, основанной на модельном представлении оригинальной среды коллективной инженерии с развитыми возможностями семантически корректной и функционально содержательной реконсиляции дивергентных реплик данных.

1. Введение Сравнение коллекций является одной из традиционных задач сопоставления версий и анализа изменений при оптимистической репликации структурированных данных и документов [1]. Программные средства сравнения, предоставляющие подобную функциональность, являются неотъемлемыми компонентами современных систем контроля версий. Подобные системы нашли применение в задачах управления конфигурацией программного обеспечения (software configuration management), управления мобильными базами данных (mobile database management), организации цифровых архивов, документооборота (document management), построения платформ и систем коллективной инженерии (collaboration workspaces, concurrent engineering environments), управления web–контентом (content management). Так, среди наиболее популярных решений коллективной 1

Работа коллектива поддержана РФФИ (грант 07-01-00427) 181

программной инженерии следует отметить системы управления версиями ПО: CVS, Subversion, OpenCM, BitKeeper, Visual SourceSafe, Perforce, Synergy CM и т.п. [2]. Оформленные в виде программных утилит с пользовательским интерфейсом средства сравнения имеют многочисленные самостоятельные приложения. Например, утилиты командной строки cmp, diff, sdiff, diff3 известного проекта GNU [3] позволяют определить первый отличный байт для заданной пары файлов, вычислить минимальное множество отличий между двумя файлами, интерактивно объединить два файла в один общий, а также представить структуру изменений при одновременной модификации одного файла двумя пользователями или программами и сгенерировать файл, являющийся результатом слияния двух версий относительно базовой с предупреждениями о возникших конфликтах. GNU Diffutils работают преимущественно с текстовыми файлами, для бинарных файлов они могут лишь констатировать факт сходства или различия. Пакет JojoDiff включает набор утилит для сравнения бинарных файлов: jdiff — сравнивает два файла, jpatch — реконструирует второй файл из первого на основе списка изменений, сгенерированного jdiff, jsync — синхронизирует файлы или директории между двумя компьютерами. Приложения KDiff, Xxdiff, gtkdiff, tkdiff, Diffstat, ExamDiff предоставляют средства визуального сравнения произвольных текстовых файлов. Известная утилита UN*X dirdiff позволяет сравнивать деревья каталогов и синхронизировать изменения между ними. Развитые графические средства сравнения текстовых файлов, а также синхронизации директорий включает в себя популярный файловый менеджер TotalCommander. Перечисленные программные средства производят сравнение произвольных текстовых или бинарных файлов без учета семантики их содержимого. Ряд программных утилит и приложений позволяет сравнивать документы в различных текстовых или бинарных форматах, HTML, XML, Multimedia данные. В частности, учитывая типизацию отдельных термов в текстовых данных, утилита spiff позволяет адекватно сравнивать числовые данные с плавающей точкой, а также исходные тексты на популярных языках программирования. Набор приложений CSDiff/CS-ExcelDiff/CS-HTMLDiff позволяет установить и отобразить изменения документов, представленных в форматах Microsoft Word, Microsoft Excel, HTML. Программы ExamDiff Pro, Compare Suite, Diff Doc поддерживают сравнение документов в различных форматах популярных офисных приложений, PDF, HTML, в том числе документов, хранящихся в архивах. Интегрированные пакеты Microsoft Office 2003 и 2007 имеют развитые встроенные средства сравнения и слияния версий документов. Наборы средств diffxml, 3dm, XMLComparator обеспечивают сравнение, коррекцию и слияние документов в XML разметке. Программы Image Comparer, ImageDupeless специализируются на сравнении графической, а Similarity — звуковой информации, хранимой в файлах наиболее распространенных форматов. 182

Средства сравнения реляционных данных позволяют определить изменения схем и содержимого популярных баз данных. В частности, программа DataDiff находит отличающиеся записи в альтернативных базах данных под управлением MySQL, утилита mysqldiff — находит отличия в определениях таблиц СУБД MySQL, утилита MDBDiff позволяет выявить структурные изменения в базах данных Microsoft Access, Oracle SchemaDiff — изменения в схемах Oracle, pgdiff — изменения в реляционных таблицах двух баз данных под управлением PostgreSQL с возможной генерацией команд конвертации схемы одной базы данных в другую. Универсальная программа с webинтерфейсом SQLDiff устанавливает и показывает отличия между двумя SQL таблицами для распространенных реляционных СУБД (Oracle, DB2, PostgreSQL). Ряд программных компонентов сравнения обеспечивает работу с объектными моделями. В частности, библиотека difflib, реализованная на Python, позволяет вычислять изменения в объектных данных. Программный модуль UMLDiff [4], функционирующий в среде программной инженерии Eclipse, определяет структурные изменения статических UML моделей. Более подробные сведения о вышеперечисленных утилитах и библиотеках, а также об аналогичных программных средствах сравнения данных и документов можно найти в Интернет-обзорах и каталогах [5–8]. Несмотря на разнообразие приложений, в которых математические методы и программные средства сравнения находят содержательное применение, следует отметить строгую функциональную специализацию и определенную ограниченность перечисленных выше средств. Главной причиной этого является ориентация на конкретные классы приложений с предопределенной семантикой. Безусловно, подобная направленность делает данные средства чрезвычайно полезными при решении конкретных прикладных задач, однако не дает возможность распространить их на нетривиальные масштабные междисциплинарные информационные модели, описываемые сотнями (иногда тысячами) типами данных и ограничений. Более того, часто и в простых случаях результаты сравнения оказываются неадекватными решаемой задаче. Например, сравнение документов в разметке XML позволяет идентифицировать изменения, связанные с появлением, удалением, модификацией элементов, однако не фиксирует изменения положения элементов относительно друг друга. Приложения, для которых порядок следования элементов данных существенен, не могут доверительно использовать результаты сравнения. Например, приложение, фиксирующее изменения в рейтинговом списке ученых, упорядоченном в соответствии с показателем результативности научной деятельности, не может корректно интерпретировать результаты сравнения и нуждается в более адекватном способе представления изменений в соответствии с семантикой модели данных. 183

В обобщенной постановке задача сравнения обычно не рассматривается, хотя все упомянутые выше виды документов, файлов, схем баз данных могли бы быть прозрачно представлены информационными моделями/метамоделями, и их сравнение могло бы быть проведено на более общей методологической и инструментальной основе. Подобная постановка является критично важной для приложений семантической реконсиляции, оперирующих произвольными типами данных при заданной прикладной модели с формально описанными структурой и алгебраическими ограничениями. В подходе, предложенном и развитом в наших работах [9–12], вычисление изменений данных рассматривается в качестве ключевого элемента реконструкции конкурентных транзакций и их семантически согласованной реконсиляции на основе заданной информационной модели. Учет семантики модели позволяет на формальной, математически строгой основе провести сравнительный анализ реплицируемых данных и выработать непротиворечивые (семантически корректные) и содержательные (обеспечивающие полноту итоговой транзакции) политики реконсиляции. В определенном смысле подход следует важному доминирующему направлению информационных технологий, предполагающему активное использование моделей на всех этапах программной инженерии и анализа информации. Деятельность международных сообществ по разработке соответствующих информационных стандартов и многофакторных прикладных моделей, прежде всего, в рамках ISO 10303 STEP [13] и OMG MDA [14] также следует этой тенденции. В настоящей работе обсуждаются проблемы сравнения коллекций — стандартных типов данных, поддерживаемых популярными языками моделирования и программирования, повсеместно используемых в приложениях и представляющих собой наиболее сложные и интересные конструкции для рассматриваемых задач реконсиляции. Главным лейтмотивом статьи является вопрос об адекватности способов представления изменений типам коллекций, а также о выборе эффективных алгоритмов нечеткого сравнения коллекций в соответствии с их семантикой.

2. Задача нечеткого сравнения семантической реконсиляции

в

приложениях

Обсудим особенности постановки задачи нечеткого сравнения коллекций в приложениях семантической реконсиляции. Напомним, что традиционная задача сравнения последовательностей обычно формулируется как задача отыскания минимального скрипта редактирования (последовательности элементарных команд, обеспечивающей преобразование исходной строки в заданную другую строку) [20, 21]. Множество найденных команд при соответствующей интерпретации может служить представлением изменений, внесенных в модифицированную версию коллекции относительно исходной. Отыскание наибольшей подпоследовательности также решает задачу 184

нечеткого сравнения и позволяет представить изменения модифицированной коллекции в виде добавленных и удаленных фрагментов строк, дополняющих найденную общую подпоследовательность до заданных строк. В отличие от традиционных постановок задач сравнения последовательностей, приложения реконсиляции оперируют с произвольными типами коллекций, и для адекватной реконструкции изменений требуется детальный семантический анализ. Другой важной особенностью рассматриваемой постановки является необходимость декомпозиции долгих транзакций на группы операций, которые могли бы быть представлены и применены независимым друг от друга образом. Это означает, что в ходе реконсиляции одна часть выявленных изменений может быть принята в итоговом представлении при отмене другой без каких-либо дополнительных ограничений. Выбранный базис элементарных операций должен удовлетворять данному требованию. Итак, пусть X , X ′, X ′′ ∈ collection < T > — некоторые версии коллекции элементов типа T, причем X — базовая версия, а X ′ , X ′′ — версии, полученные в результате ее одновременной модификации в двух параллельных ветвях. Задача реконсиляции в наиболее распространенной постановке заключается в вычислении соответствующих изменений модифицированных версий относительно базовой Δ ′ = Diff ( X ′, X ) , Δ ′′ = Diff ( X ′′, X ) и в консолидации изменений Δ* = Merge(Δ ′, Δ ′′) таким образом, чтобы сформировать итоговое представление коллекции X * = Apply ( X , Δ* ) как результат применения согласованных изменений к базовой версии. Это, так называемая, классическая “3-way Merge” схема реконсиляции в отличие от схем “2-way Merge” и “4-way Merge”, имеющих более узкое применение [15, 16]. Например, если при одновременной модификации текстового файла в ходе выполнения одной транзакции была вставлена новая строка, а в ходе выполнения другой транзакции одна из строк была удалена, результатом консолидации изменений должен стать итоговый документ с внесенными общими изменениями (см. рис. 1), дополняющий его существующие версии новым согласованным вариантом. Корректная идентификация изменений и реализация функции исполнения предполагают, что соответствующие тождества X ′ = Apply ( X , Δ ′) , X ′′ = Apply ( X , Δ ′′) необходимо удовлетворены.

185

Merged document Line1 New Line1 Line3

Version1 Line1 New Line1 Line2 Line3

Version2 Line1 Line3

Original document Line1 Line2 Line3

Рис. 1. Пример консолидации изменений в итоговом текстовом документе Тривиальными случаями реализации функции реконсиляции являются Merge(Δ ′, Δ ′′) = ∅ , Merge(Δ ′, Δ ′′) = Δ ′ и Merge(Δ ′, Δ ′′) = Δ ′′ , приводящие к уже известным версиям коллекции X , X ′ и X ′′ соответственно. Содержательная реализация функции реконсиляции Merge(Δ ′, Δ ′′) нетривиальна, поскольку Δ ′ , Δ ′′ могут представлять собой иерархически структурированные изменения Δ ′ = {δ 1′ , δ 2′ ,...δ n′′ } , Δ ′′ = {δ 1′′, δ 2′′ ,...δ n′′′′ } , δ i′ = δ i′,1 , δ i′, 2 ,...δ i′,ni′ ,

{

δ i′′ = δ i′′,1 , δ i′′, 2 ,...δ i′′,ni′′

}

{

и т.д. По существу, дельты

Δ′ ,

}

Δ ′′

являются

реконструируемым представлением конкурентных транзакций, примененных к исходным данным X и имеющих результатом X ′ и X ′′ соответственно. В силу указанных причин реализация данной функции должна обеспечивать консолидацию как можно большего числа изменений при условии сохранения частичного порядка операций, индуцируемого семантикой приложений, и их бесконфликтности. В случаях, когда все конфликты разрешаются путем принятия изменений из первой версии, функция реконсиляции строится следующим образом: Merge(Δ ′, Δ ′′) = {δ ′ | δ ′ ∈ Δ ′} ∪ {δ ′′ | δ ′′ ∈ Δ ′′ & ¬isConflict (δ ′′, δ ′), δ ′ ∈ Δ ′} , 186

где логическая функция isConflict (δ ′′, δ ′) истинна в случае конфликта между изменениями δ ′ , δ ′′ . Является открытым вопрос о том, какие ситуации следует считать конфликтными, и каким образом они могут быть разрешены: отменой всех операций, выделением и принятием бесконфликтного подмножества операций, или путем их коррекции. В дальнейшем под конфликтом будем понимать бинарное или множественное отношение между наборами или последовательностями операций в δ i′1 , δ i′2 ,..., δ i′n′ ∈ Δ ′ , конкурентных транзакциях δ ′j′1 , δ ′j′2 ,...δ ′j′n′′ ∈ Δ ′′ ,

Merged document1 Line1 New Line1 New Line2 Line2 Line3

Merged document2 Line1 New Line2 New Line1 Line2 Line3

одновременное принятие которых приводит к некорректной интерпретации операций и неоднозначности результата, или к нарушению семантических ограничений, накладываемых на результирующее представление данных X * = Apply ( X , Δ* ) , где Δ* = δ i′1 , δ i′2 ,..., δ i′n′ , δ ′j′1 , δ ′j′2 ,...δ ′j′n′′ .

Version1 Line1 New Line1 Line2 Line3

Version2 Line1 New Line2 Line2 Line3

{

}

Стандартный способ разрешения конфликта состоит в принятии одной из опций Options = ∅; δ i′1 , δ i′2 ,..., δ i′n′ ; δ ′j′1 , δ ′j′2 ,...δ ′j′n′′ . При условии, что ориги-

{

}

нальные транзакции приводят к корректным версиям X ′ и X ′′ , а принимаемые операции не конфликтуют друг с другом, результирующая транзакция также будет корректна. В случае выявления конфликтов они разрешаются вплоть до достижения корректности итоговой транзакции. Заметим, что решение всегда существует, поскольку в качестве итоговой транзакции могут быть приняты ∅, Δ ′ или Δ ′′ . Однако более содержательным была бы консолидация операций из обеих конкурентных транзакций. Важной особенностью задачи нечеткого сравнения коллекций в приложениях реконсиляции является учет частичного порядка между операциями. Например, если при одновременном редактировании текста в одну и ту же позицию были добавлены отличные строки, то конфликт связан не с нарушением какого-либо ограничения для результирующего документа, а с неоднозначностью исполнения соответствующих операций δ ′ , δ ′′ и с неопределенностью ожидаемого результата X * = Apply ( X , Merge(δ ′, δ ′′)) . Возможным способом разрешения конфликта в данном случае являлась бы одна из опций: Options = {∅; δ ′; δ ′′; δ ′∠δ ′′; δ ′′∠δ ′} , где символ ∠ означает отношение предшествования между исполняемыми операциями. Результатом может стать исходный документ, одна из его модифицированных версий либо документ с двумя возможными вариантами вставки строк (см. рис. 2). Заметим, что совпадение добавленных строк в обеих версиях модифицируемого документа не приводит к конфликту, и вариантами реконсиляции являются тривиальные решения Options = {∅; δ ′; δ ′′} , приводящие к уже существующим версиям документа.

187

Original document Line1 Line2 Line3

Рис. 2. Пример многовариантной реконсиляции с учетом частичного порядка операций редактирования текстового документа Приведем вариант предыдущего примера редактирования текстового документа, иллюстрирующего важность учета семантики модели данных при дополнительном ограничении уникальности элементов коллекции. Предположим, что документ представляет собой персонофицируемый список имен, формируемый путем согласования альтернативных рейтинговых показателей в параллельных версиях (см. рис. 3). В первой модифицируемой версии документа между персонами на первых двух позициях вставляется новое имя, после чего меняется порядок их следования. Дельта представляется следующим образом: Δ ′ = {δ 1′ (insert , " NewPerson" ,2), δ 2′ (transpose,1,3)} , где δ1′ — операция вставки нового элемента в соответствующую позицию коллекции, а δ 2′ — операция транспозиции пары элементов в заданных позициях коллекции. Во второй версии документа то же самое имя вставляется на позицию между последними персонами, а также меняется порядок их следования: Δ ′ = {δ 1′′(insert , " NewPerson" ,3), δ 2′′ (transpose,2,4)} . Заметим, что изменение порядка следования элементов коллекции и вставка новых элементов согласно репродуцируемой семантике множества не должна приводить к дублированию 188

имен в итоговом документе. Поэтому семантически корректными являются результаты Options = {∅; δ 1′∠δ 2′ ; δ 1′′∠δ 2′′ ; δ 1′; δ 2′ ; δ 1′′ ; δ 2′′ ; δ 1′∠δ 2′′ ; δ 2′′∠δ 2′ } , приводящие, соответственно, к оригинальным версиям Original document, Version1, Version2, версиям Version1-1, Version1-2, Version2-1, Version2-2, полученным частичным принятием операций одной из транзакций, и версиям документа Merged document1, Merged document2, полученным возможной консолидацией операций из двух конкурентных транзакций. Version1-1 Person2 Person1 Person3

Version1-2 Person1 New Person Person2 Person3

Version2-1 Person1 Person3 Person2

Merged document1 Person1 New Person Person3 Person2

Merged document2 Person2 Person1 New Person Person3

Version1 Person2 New Person Person1 Person3

Version2 Person1 Person3 New Person Person2

Version2-2 Person1 Person2 New Person Person3

Original document Person 1 Person 2 Person 3

Рис. 3. Пример многовариантной реконсиляции с учетом семантики модели коллекции

3. Классификация коллекций Коллекции — фундаментальный тип данных, поддерживаемый популярными языками моделирования и программирования для спецификации и реализации в приложениях агрегированных структурированных данных. Как иллюстрируют примеры предыдущего раздела, сравнение коллекций должно проходить в строгом соответствии с их семантикой. В противном случае результаты рискуют быть неадекватными исходной проблеме и теряют смысл для целевого приложения и пользователя. 189

Сравнение коллекций может рассматриваться в качестве частной задачи более общей проблемы семантического сопоставления (matching) и сравнения (differencing) расходящихся реплик структурированных данных, например, популяций объектов, заданных некоторой объектно-ориентированной моделью. Несмотря на многообразие частных типов коллекций, встречаемых в приложениях, можно выделить несколько фундаментальных свойств, в соответствии с которыми их анализ может проводиться содержательным образом. К таким свойствам мы относим уникальность элементов коллекции, упорядочение, возможную сортировку элементов коллекции, а также ограниченный размер коллекции. Декларативные языки объектно-ориентированного моделирования, как правило, предоставляют некоторый набор абстрактных или конкретных типов коллекций с априори заданным набором семантических свойств. В производных пользовательских типах, определяемых на основе базовых, семантика коллекций может быть сохранена или уточнена. Однако выделенные фундаментальные свойства остаются принципиальными для содержательного анализа коллекций. Так, декларативный язык ограничений OCL [17] определяет абстрактный интерфейс коллекций Collection и четыре конкретных класса Bag, Set, Sequence и OrderedSet для представления мультимножеств, множеств, последовательностей и упорядоченных множеств соответственно. Все виды коллекций задаются в обобщенном виде с возможностью параметризации типом элементов. Set — коллекция, по семантике соответствующая математическому понятию множества. Она не допускает дупликации элементов. OrderedSet — специализация данного типа для упорядоченных множеств. Ограничение уникальности необходимо поддерживается данным типом коллекции. Bag — мультимножество с возможным повторением элементов. Sequence — упорядоченное мультимножество или последовательность, допускающая повторение элементов. Таким образом, виды коллекций OCL могут быть классифицированы в соответствии с таблицей 1. Язык моделирования EXPRESS [18] предоставляет иной набор типов коллекций, а именно: Aggregate, Bag, Set, Array и List. Абстрактный тип Aggregate определяет базовый набор методов оперирования с элементами коллекций. Bag — специализация данного типа для представления мультимножеств. Set — специализация типа Aggregate для произвольных множеств, исключающая дупликацию элементов и игнорирующая их порядок. Тип данных List применяется для представления последовательностей. Допустимое количество элементов в списках, множествах и мультимножествах задается дополнительными ограничениями. Коллекции имеют строго фиксированный размер в тех случаях, когда нижний и верхний пределы их размера совпадают. Array — специализация типа Aggregate для массивов фиксированной длины. С учетом индексации порядок элементов в 190

массивах имеет существенное значение. Возможна организация разреженных массивов с неустановленными значениями элементов при помощи специального спецификатора. Также возможно определение производных типов массивов и списков с наложенным ограничением уникальности элементов. Базовые типы коллекций, предоставляемые языком моделирования EXPRESS, приведены в таблице 1. UNIQUE

ORDERED

SORTED

FIXED

+ + -

+

-

+ + -

+

+

-

-

-

+

-

+

+

+

-

+

-

+

+

-

+

+

+

-

-

+

+

+

+

+

+

+

Используемые Коллекции Коллекции сокращения OCL EXPRESS BAG BAG BAG SET SET SET FIXED BAG FIXED SET SEQUENCE LIST LIST ORDERED UNIQUE ORDERED SET SET LIST ARRAY ARRAY UNIQUE UNIQUE ARRAY ARRAY SORTED LIST SORTED SET SORTED ARRAY SORTED UNIQUE ARRAY

Таблица 1. Классификация базовых типов коллекций в языках моделирования EXPRESS и OCL Базовые типы могут переопределяться пользователем с учетом семантики приложения путем задания дополнительных ограничений с использованием всего репертуара конструкций декларативных языков OCL и EXPRESS. В частности, может быть уточнено допустимое число элементов коллекции и способ их индексации, задан частичный или полный порядок на множестве элементов коллекции, определены свойства корреляции значений элементов и т.п. Рассмотрим вопросы представления, вычисления изменений и исполнения соответствующих операций над коллекциями, следуя приведенной выше классификации в соответствии с выделенными семантическими свойствами. 191

4. Сравнение множеств Начнем рассмотрение с наиболее простого типа коллекций X ∈ set < T > — множества элементов типа T, предполагающего неявное задание и выполнение единственного семантического ограничения уникальности элементов ∀x, y ∈ X → x ≠ y . Дельта для двух версий множества X , X ′ ∈ set < T > может быть естественным образом представлена в виде неупорядоченного набора операций добавления и удаления соответствующих элементов коллекции: Δset < T > ( X ′, X ) = {ins ( x) | x ∈ ( X ′ \ X )} ∪ {del ( x) | x ∈ ( X \ X ′)} Корректное представление дельты Δ = Δset < T > ( X ′, X ) предполагает, что выполняется условие ∀ins ( x1 ) ∈ Δ ∀del ( x 2 ) ∈ Δ → x1 ≠ x 2 , означающее, что один и тот же элемент не может одновременно участвовать в операции добавления и удаления. Более того, будем исключать повторение операций добавления и удаления с одним и тем же элементом, которое при исполнении операций противоречило бы определению множества: ∀ins1 ( x1 ) ∈ Δ ∀ins 2 ( x 2 ) ∈ Δ → x1 ≠ x 2 и ∀del1 ( x1 ) ∈ Δ ∀del 2 ( x 2 ) ∈ Δ → x1 ≠ x 2 . Применение операций, определяемых дельтой, довольно прозрачно. К заданному исходному множеству добавляются элементы, определяемые операциями ins, и удаляются элементы, определяемые операциями del. Тем самым, гарантируется тождественность условия Apply ( X , Δset < T > ( X ′, X )) = X ′ , в котором функция Apply ( X , Δ ) возвращает модифицированное представление коллекции, полученное в результате применения дельты к заданному представлению коллекции X. Две конкурентные транзакции Δ ′, Δ ′′ могут оказаться конфликтными в случае isConflict (ins ′( x), del ′′( x)) = true , когда в одной транзакции некоторый элемент добавляется в коллекцию, а в другой транзакции тот же самый элемент удаляется. Однако, если обе дельты вычислялись относительно общей версии коллекции в рамках распространенной схемы слияния “3-way Merge”: Δ ′ = Δset < T > ( X ′, X ) , Δ ′′ = Δset < T > ( X ′′, X ) , то подобные конфликты исключены в силу того, что удаляемый элемент обязан принадлежать базовой версии коллекции X и не может быть добавлен в нее повторно вследствие ограничения уникальности элементов множества. В случае иных схем слияния с участием нескольких базовых версий, например, схемы “4-way Merge”, подобные конфликты должны идентифицироваться и корректно разрешаться. Тривиальными способами разрешения являются следующие опции Options = {∅; ins ′( x); del ′′( x)} , предполагающие игнорирование обеих конфликтных операций или принятие одной из них. 192

Сложность вычисления дельты Δset < T > определяется, прежде всего, способом представления исходных множеств (список, массив, сбалансированное дерево), а также алгоритмами поиска добавляемых и удаляемых элементов. Вычислительная сложность наивной реализации, основанной на простом поиске элемента в неупорядоченном списке и не требующей определения на элементах множеств полного порядка может быть оценена как O(| X | ⋅ | X ′ |) . Сложность оптимальной реализации, основанной на предварительной сортировке исходных множеств, например, методом пирамидальной сортировки или методом слияния списков, можно оценить как O(| X | ⋅ ln | X | + | X ′ | ⋅ ln | X ′ |) . А в случае использования для работы с множеством сбалансированного дерева, хранящего элементы в уже отсортированном порядке, сложность операции построения дельты оценивается как O(| X | + | X ′ |) . Понятно, что последняя оценка не может рассматриваться как реальная оценка, поскольку в данном случае основная часть затрат перенесена на стадию формирования исходных множеств. Наиболее корректной оценкой в данном случае является также O(| X | ⋅ ln | X | + | X ′ | ⋅ ln | X ′ |) . Ниже приведен пример сравнения двух версий множества натуральных чисел X , X ′ ∈ set < N > . Пусть X , X ′ — основная и модифицированная версии коллекции, содержащие следующие элементы: X = {1,2,3,6,8} , X ′ = {1,2,4,5,7,9} . Тогда дельта, вычисленная путем сравнения двух версий множества, представляется как Δ ( X ′, X ) = {ins (4), ins (5), ins (7), ins (9), del (3), del (6), del (8)} .

5. Сравнение мультимножеств Перейдем к задаче сравнения мультимножеств X ∈ multiset < T > с функцией cardinality ( x, X ) для подсчета числа вхождений элемента x ∈ T в коллекцию X . При модификации коллекции данного типа дельта представляется как неупорядоченный набор множественного добавления и удаления элементов. Пусть X , X ′ ∈ multiset < T > — две версии мультимножества, тогда дельта может быть сформирована как ⎧ card ( x , n ) | n = cardinalit y ( x , X ′) − ⎫ Δ multiset < T > ( X ′, X ) = ⎨ ⎬ ⎩ cardinalit y ( x , X ), n ∈ Z , n ≠ 0 ⎭ В используемых обозначениях Z — множество целых чисел. Положительное значение параметра n в операции изменения кардинальности card(x,n) указывает на добавление элемента в коллекцию соответствующее число раз, отрицательное значение — на удаление элемента из коллекции. Нулевое значение n не содержательно для представления дельты, поскольку означает, что количество экземпляров элемента в коллекции не изменилось. В 193

корректно сформированном представлении дельты Δ = Δmultiset < T > ( X ′, X ) предполагается, что элемент мультимножества не может одновременно участвовать в нескольких операциях ∀card1 ( x1 , n1 ) ∈ Δ ∀card 2 ( x 2 , n 2 ) ∈ Δ → x1 ≠ x 2 . В противном случае сравнение идентичных версий коллекции могло бы привести к неожиданному результату, отличному от пустого представления дельты, например: card i ( x, ni ) | ni = 0 ≠ ∅ .

{

∑

}

Применение базовой операции дельты card(x,n) состоит в кратном добавлении соответствующего элемента x при положительном значении параметра n и в его кратном удалении при отрицательном значении параметра. Это гарантирует выполнение необходимого тождества Apply ( X , Δmultiset < T > ( X ′, X )) = X ′ . Две операции card ′( x, n ′) ∈ Δ ′, card ′′( x, n ′′) ∈ Δ ′′ конфликтуют друг с другом, если параметры кратности перемещения экземпляров одного и того же элемента в конкурентных транзакциях отличаются друг от друга n′ ≠ n ′′ . Тривиальные способы разрешения конфликта состоят в выборе одной из опций Options = {∅; card ′( x, n ′); card ′′( x, n ′′)} . Вместе с тем, логичным представляется расширение возможных опций путем назначения параметру кратности всего интервала значений, порождающего конфликтную ситуацию: Options = {∅; card ( x, min(n ′, n ′′));...; card ( x, max(n ′, n ′′))} . Это означает, что может быть выбрано любое число кратности для операции перемещения, лежащее в интервале между соответствующими параметрами конфликтных операций. В случаях, когда обе конфликтные операции являются родственными, конфликт целесообразно разрешать, исходя из промежуточных значений. В случаях, когда одна из конфликтных операций — операция добавления, а другая — операция удаления, допустимым является также весь диапазон значений параметра кратности, означая удаление или добавление числа элементов, не превышающего используемое значение соответствующей операции. Сложность построения Δmultiset < T > определяется теми же факторами, что и сложность вычисления дельты обычного множества. Имеет место незначительное увеличение числа операций, однако это не влияет на асимптотическую оценку, которая в среднем выражается как O(| X | ⋅ ln | X | + | X ′ | ⋅ ln | X ′ |) . В качестве примера рассмотрим процедуру сравнения двух версий мультимножества символов. Пусть X , X ′ ∈ multiset < N > — основная и модифицированная версии коллекции, содержащие следующие натуральные X = {g , a, b, c, c, f , b, c} , X ′ = {b, e, a, d , e, e} . Тогда дельта, элементы вычисленная в результате сравнения двух версий коллекции, представляется 194

как Δ( X ′, X ) = {card (b,−1), card (c,−3), card (d ,1), card (e,3), card ( f ,−1), card ( g ,−1)} .

целью. Все значения индексов позиций относительно исходных версий коллекции.

6. Сравнение списков

Корректное представление дельты Δ = Δlist < T > ( X ′, X ) предполагает, что выполняются следующие условия:

Для сравнения списков (или последовательностей) могут быть задействованы классические алгоритмы минимального редакторского расстояния (editdistance (ed)) и алгоритмы нахождения наибольшей общей последовательности (longest-common-subsequence (lcs)), нашедшие применение в самых разных приложениях [20, 21]. Поскольку данные семейства алгоритмов достаточно хорошо проработаны и изучены, мы ограничимся вопросами их использования в общем контексте решения задач сравнения и слияния коллекций на основе семантики модели. Пусть элементы списка X ∈ list < T > предварительно последовательно пронумерованы, начиная с единицы, и каждый элемент x(i ) ∈ X , i = 1.. | X |, x(i ) ∈ T индексируется в соответствии с положением в списке. Далее x(i ) обозначается i-ый элемент коллекции, | X | — число элементов коллекции и x[i, j ] — упорядоченное подмножество элементов коллекции X , начинающееся в позиции i и заканчивающееся в позиции j ≥ i . Тогда дельта, полученная в результате сравнения двух версий коллекции X , X ′ ∈ list < T > , может быть представлена множеством операций вставки новых элементов в соответствующие позиции исходного списка и удаления элементов с соответствующих позиций подобно тому, как это осуществляется в алгоритмах минимального редакторского расстояния: Δlist < T > ( X ′, X ) = {ins (i, x ′[k , l ]) | i = 1.. | X ′ | +1, x'[k , l ] ⊆ X ′} ∪ {del ( x[i, j ]) | x[i, j ] ⊆ X } ∪ {skip( x[i, j ]) | x[i, j ] ⊆ X , x ′[k , l ] ⊆ X ′, x[i, j ] = x ′[k , l ]}

Здесь операция ins (i, x ′[k , l ]) вставляет упорядоченный набор элементов модифицированного списка X ′ с индексами в отрезке [k , l ] в позицию i исходного списка X . Операция del ( x[i, j ]) удаляет элементы исходного списка с индексами, принадлежащими отрезку [i, j ] , и, наконец, операция skip( x[i, j ]) переносит элементы с индексами в отрезке [i, j ] в модифицируемый список без изменений. Последний тип операций избыточен при практической реализации, поскольку подмножество переносимых элементов может быть вычислено путем анализа интервалов индексов для удаляемых элементов. Тем не менее, здесь они используются с методической 195

элементов

рассчитываются

∀ins1 (i1 , x ′[k1 , l1 ]) ∈ Δ ∀ins 2 (i2 , x ′[k 2 , l 2 ]) ∈ Δ → i1 ≠ i 2 ∀ins1∀ins2 ins1(i1, x′[k1, l1]),ins2 (i2 , x′[k2 , l2 ]) ∈ Δlist < T > ( X ′, X ) → [k1, l1] ∩ [k2 , l2 ] = ∅ ∀del1 ( x[i1 , j1 ]) ∈ Δ ∀del 2 ( x[i 2 , j 2 ]) ∈ Δ → [i1 , j1 ] ∩ [i2 , j 2 ] = ∅

означающие, что индексы позиций вставки элементов не повторяются, а интервалы вставляемых и удаляемых элементов не пересекаются в разных операциях. Будем считать также, что аналогичное условие выполняется для операций переноса элементов, индексы которых в исходном списке дополняют индексы удаляемых элементов: ∀skip1 ( x[i1 , j1 ]) ∈ Δ ∀skip 2 ( x[i2 , j 2 ]) ∈ Δ → [i1 , j1 ] ∩ [i2 , j 2 ] = ∅ ∀skip1 ( x[i1 , j1 ]) ∈ Δ ∀del 2 ( x[i 2 , j 2 ]) ∈ Δ → [i1 , j1 ] ∩ [i 2 , j 2 ] = ∅ ∀i ∈ [1, | X |] ∃del ( x[i1 , j1 ]) ∈ Δlist < T > ( X ′, X ) i ∈ [i1 , j1 ] ∧

∃skip( x[i1 , j1 ]) ∈ Δlist < T > ( X ′, X ), i ∈ [i1 , j1 ] Применение дельты предполагает предварительное упорядочение операций по индексам вставки и удаления элементов в исходной коллекции X таким образом, что при совпадении индексов операции вставки предшествуют соответствующим операциям удаления. Сами операции последовательно выполняются со значениями индексов, скорректированными с учетом предшествующих результатов. При подобной интерпретации каждая операция вставки элементов ins (i, x' [k , l ]) может рассматриваться в качестве композиции элементарных операций вставки отдельных элементов ins (i, x' (k ))∠...∠ins (i, x' (m))∠...∠ins (i, x' (l )) с наложенными отношениями предшествования между ними. Используемый символ отношения ins1 (i, x'1 )∠ins 2 (i, x' 2 ) означает, что операции ins1 (i, x'1 ) , ins 2 (i, x' 2 ) должны выполняться таким образом, чтобы в результирующем представлении коллекции элемент x'1 предшествовал элементу x' 2 при условии, что обе операции применяются. Последнее замечание существенно, поскольку одна из операций может быть не включена в результирующую транзакцию. Тем не менее, транзитивные отношения предшествования определяют частичный 196

порядок между операциями транзакции, который должен соблюдаться независимо от того, какие операции применяются, а какие — нет. Таким образом, установленные отношения предшествования гарантируют, что элементы x'[k , l ] будут вставлены в результирующий список, не нарушая исходный порядок. Подобные отношения могут конструктивно использоваться при выполнении операций. Например, если операция реализуется как вставка в указанную позицию списка, то при условии ins1 (i, x'1 )∠ins 2 (i, x' 2 ) операция ins 2 (i, x' 2 ) должна применяться до операции ins1 (i, x'1 ) . Две конкурентные операции с пересекающимися значениями интервалов индексов могут приводить к ситуациям, допускающим неоднозначное решение. Две операции удаления del ′( x[k ′, l ′]) ∈ Δ ′ и del ′′( x[k ′′, l ′′]) ∈ Δ ′′ с пересекающимися интервалами индексов [k ′, l ′] ∩ [k ′′, l ′′] ≠ ∅ допускают консолидированное исполнение в виде del ( x[k ′, l ′] ∪ [k ′′, l ′′]) . Однако полный перечень опций применения определяется как множество всех простых сочетаний (сочетаний без повторений) операций удаления, включая пустое множество: Options = SimpleCombinations{(del ( x(min(k ′, k ′′)),..., del ( x(max(l ′, l ′′))))} . Число возможных сочетаний может быть слишком велико для выбора необходимого варианта в ходе интерактивной сессии. Поэтому более естественным может оказаться представление конкурентных операций в более компактном виде с меньшим числом альтернатив выбора, а именно: ⎧(del ( x[k ′, l ′] ∩ [k ′′, l ′′]), ⎫ ⎪ ⎪ Options = SimpleCombinations ⎨del ( x[k ′, l ′] \ ( x[k ′, l ′] ∩ [k ′′, l ′′])),⎬ . ⎪del ( x[k ′′, l ′′] \ ( x[k ′, l ′] ∩ [k ′′, l ′′]))⎪ ⎩ ⎭

Отметим, что агрегированная операция удаления общих элементов del ( x[k ′, l ′] ∩ [k ′′, l ′′]) может рассматриваться как консолидированное действие, не требующее в большинстве случаев дополнительного согласования. del ( x[k ′, l ′] \ ( x[k ′, l ′] ∩ [k ′′, l ′′])) и Альтернативы удаления del ( x[k ′′, l ′′] \ ( x[k ′, l ′] ∩ [k ′′, l ′′])) дополняют общую операцию до соответствующих действий в каждой транзакции и могут приниматься в произвольном сочетании с двумя другими операциями. Две конкурентные операции вставки и удаления элементов, пересекающиеся по индексам: ins ′(i ′, x ′[k , l ]) ∈ Δ ′ , del ′′( x[i, j ]) ∈ Δ ′′ , где i ′ ∈ [i, j ] , следует считать неконфликтными, поскольку операции удаления могут всегда быть корректно исполнены последовательно или вместе с соответствующими операциями вставки. 197

ins ′(i, x ′[k ′, l ′]) ∈ Δ ′ и Для конфликтных операций вставки ins ′′(i, x ′′[k ′′, l ′′]) ∈ Δ ′′ , добавляющих неэквивалентные списки элементов x ′[k ′, l ′] ≠ x ′′[k ′′, l ′′] в одну и ту же позицию i исходного списка, пользователь должен принять решение относительно способа формирования консолидированного списка вставляемых элементов. Потенциально, любое размещение элементов альтернативных списков может считаться допустимым при выполнении следующих двух условий: оригинальный порядок элементов не изменяется и исключается дублирование эквивалентных элементов из разных версий списка в смежных позициях результирующего списка. Таким образом, возможные варианты консолидации представляются следующим образом: ⎧ins′(i, x′( k ′)),...ins′(i, x′(l ′)), ins′′(i, x′′( k ′′)),...ins′′(i, x′′(l ′′)) ⎫ ⎪ ⎪| ins′(i, x′(k ′))∠...∠ins′(i, x′(l ′)), ⎪ ⎪ Options = Arrangemen ts ⎨ ⎬ ⎪ ⎪| ins′′(i, x′′(k ′′))∠...∠ins′′(i, x′′(l ′′)), ⎪⎭ ⎪⎩| ins′(i, x′(m′)) ins′′(i, x′′(m′′)) → x′( m′) ≠ x′′( m′′)

Первые два условия гарантируют, что исходный порядок элементов при консолидации не будет нарушен. Третье условие, связанное с непосредственным предшествованием операций ins ′(i, x ′(m ′)) ins ′′(i, x ′′(m ′′)) в итоговой транзакции, обеспечивает исключение тождественных элементов при вставке в соседние позиции из разных списков. Возможный способ реализовать подобную стратегию заключается в применении упомянутых выше методов сравнения к консолидируемым последовательностям. Пусть вспомогательные списки Y ′ ∈ list < T > , Y ′′ ∈ list < T > представляют собой соответствующие последовательности вставки элементов Y ′ = x ′[k ′, l ′] и Y ′′ = x ′′[k ′′, l ′′] . Тогда их дельта представима в виде: Δlist < T > (Y ′′, Y ′) = {ins (i, y ′′[k , l ]) | i = 1.. | Y ′ | +1, y ′′[k , l ] ⊆ Y ′′} ∪ {del ( y ′[i, j ]) | y ′[i, j ] ⊆ Y ′} ∪

{skip( y ′[i, j ]) | y ′[i, j ] ⊆ Y ′, y ′′[k , l ] ⊆ Y ′′, y ′[i, j ] = y ′′[k , l ]}

Способы консолидации элементов из альтернативных списков задаются на основе Δ = Δlist < T > (Y ′′, Y ′) следующими размещениями:

⎧ins(i, y′[k , l ]) ⎫ ⎪ ⎪ Options = Arrangements ⎨| ∃skip( y′[k , l ]) ∈ Δ ∧ ∃del( y′[k , l ]) ∈ Δ ∧ ∃ins(i, y′′[k , l ]) ∈ Δ⎬ ⎪| ∀ins (i , y′[k , l ])∠ins (i , y′[k , l ]) → i < i , l < k ⎪ 1 1 1 1 2 2 2 2 1 2 1 2 ⎩ ⎭ Размещения предполагают предшествование операций, определяемое естественным порядком позиций вставки и индексных интервалов в исходных операциях сформированной дельты. Тем самым, оперируя с альтернативными 198

последовательностями вставки и выделяя отличия между ними, удается определить конструктивный способ разрешения данного рода конфликтов. Рассмотрим следующий пример. Пусть X , X ′, X ′′ ∈ list < S > — основная и модифицированные версии некоторого списка символов: X = {a, b, b, c, c, d , e, h, j} , X ′ = {a, b, c, d , e, f , g , h, j} , X ′′ = {a, b, c, d , e, h, j , k , l} . Тогда дельты, вычисленные в результате сравнения соответствующих модифицированных версий с базовой, представляются как Δ ′( X ′, X ) = {skip ′(1,2), del ′(3,4), skip ′(5,7), ins ′(8, [6,7]), skip ′(8,9)} и Δ ′′( X ′′, X ) = {skip ′′(1,2), del ′′(3,4), skip ′′(5,9), ins ′′(10, [8,9])} . В данном случае изменения не содержат конфликтов и могут быть консолидированы, приводя к результирующему представлению списка X * = {a, b, c, d , e, f , g , h, j , k , l} . Оценка вычислительной сложности классического алгоритма минимального редакторского расстояния с использованием метода динамического программирования составляет O (| X | ⋅ | X ′ |) . Этой же оценкой определяется общая сложность формирования дельты для списков. При неоптимальном формировании дельты, например, путем нахождения наибольшей общей последовательности и определения дополняющих операций, оценка вычислительной сложности может быть улучшена до O (| X | ⋅ ln | X | + | X ′ | ⋅ ln | X ′ |) , однако количество элементарных операций в полученном представлении дельты может оказаться высоким. Более детальная систематизация алгоритмов и сравнительный анализ их вычислительной сложности приводятся в [20, 21].

7. Сравнение упорядоченных множеств Упорядоченные множества являются одновременно специализацией и множеств, и списков, поэтому процедуры сравнения, рассмотренные выше, могли бы применяться и для этого случая. Однако в силу сочетания свойств упорядочения и уникальности элементов, видится более содержательный способ представления и расчета изменений для данного типа коллекций не только в виде операций вставки и удаления, но и операций перестановок. Пусть X , X '∈ ordered set < T > — исходная и модифицированная версии упорядоченного множества. Подобно спискам предполагается, что элементы коллекции последовательно перенумерованы, начиная с единицы, и с каждым элементом ассоциирован соответствующий индекс позиции. Тогда дельта может быть представлена как множество операций циклических перестановок, вставок новых элементов и удалений существующих элементов: Δ ordered set < T > ( X ' , X ) = { prm(i1 , i 2 ,...in ) | x(i1 ), x(i2 ),..., x(in ) ∈ ( X ∩ X ' )} ∪ {ins (i, [k , l ]) | x[k , l ] ∈ ( X '\ X ), i = 1.. | X | +1} ∪ {del ([i, j ]) | x[i, j ] ∈ ( X \ X ' )}

199

Операция перестановки prm(i1 , i 2 ,...in ) однократно циклически переставляет элементы исходного множества x(i1 ), x (i 2 ),...x (i n ) , приводя к следующему результату: x(i 2 ), x(i3 ),...x(i1 ) . Операция ins (i, [k , l ]) вставляет упорядоченный набор элементов модифицированного списка X ' с индексами в отрезке [k , l ] в позицию i-ого элемента исходного множества X . Операция del ([i, j ]) удаляет элементы исходного множества X с индексами, принадлежащими отрезку [i, j ] . Определим более точно семантику операций, исходя из требований предшествования группы новых элементов элементу исходного множества, в позицию которого происходит вставка, сохранения порядка вставляемых элементов относительно друг друга в соответствии с их позициями, а также непрерывности их следования в результирующем представлении множества независимо от применения или неприменения всех других операций дельты. Использование перестановок в представлении дельты упорядоченного множества позволяет изменить порядок элементов без их парных удалений и вставок, как это осуществлялось в случае списков. Более содержательный способ структуризации изменений, отражающий семантику данных, является принципиальным с учетом сложности приложений, оперирующих масштабными междисциплинарными информационными моделями. Все значения индексов позиций указываются в представлении дельты относительно исходных версий коллекции. При выполнении дельты индексные параметры всех последующих операций должны корректироваться с учетом ранее примененных. Данная корректировка заключается в увеличении или уменьшении индексов элементов исходного множества на количество выполненных вставок или удалений. При выполнении перестановок корректировка состоит в циклическом распространении индекса для каждого последующего элемента группы перестановки. Любое изменение порядка элементов в упорядоченном множестве может быть представлено композицией циклических перестановок. Причем при отсутствии пересечений по индексам перестановки удовлетворяют требованию коммутативности и могут применяться в произвольном порядке независимым друг от друга образом [19]. Тем самым удовлетворяется требование конструктивной декомпозиции и реконсиляции транзакций, связанное с возможностью независимого применения их отдельных операций. При этом наличие одного и того же индекса в разных группах перестановок дельты Δ = Δ ordered set < T > ( X ' , X ) должно быть запрещено: ∀prm1 (i1 , i 2 ,..in ) ∈ Δ ∀prm 2 ( j1 , j 2 ,.. j m ) ∈ Δ → (i1 , i 2 ,..i n ) ∩ ( j1 , j 2 ,.. j m ) = ∅

Данное условие не является обременительным, поскольку существует четкая методика разложения перестановки произвольного упорядоченного множества на группы циклических перестановок. Данная методика 200

приводится в [19] как доказательство теоремы о единственности специально заданного соединительного произведения перестановки линейно упорядоченного мультимножества. Для корректного применения дельты Δ = Δ ordered set < T > ( X ' , X ) операции могут быть частично упорядочены подобно тому, как это делалось для операций со списками. Предшествование операций циклической перестановки операциям вставки, а тех, в свою очередь, операциям удаления позволяет упростить реализацию применения дельты: ∀prm(i1 , i2 ,...in ) ∈ Δ ∀ins(i, [k , l ]) ∈ Δ ∀del ([i, j ]) ∈ Δ → prm(i1 , i 2 ,...in ) ∠ins (i, [k , l ])∠del ([i, j ])

del ([2,2]) , del ([6,6]) удаляют элементы b и f, приводя к окончательному представлению модифицированной версии коллекции X ′ . Опишем возможный способ формирования дельты двух упорядоченных множеств в соответствии с перечисленными выше условиями: 1. Поиск идентичных подмножеств Y ⊆ X и Y ′ ⊆ X ′ исходных Y , X , Y ′, X ′ ∈ ordered set < T > , сохраняющих множеств, оригинальный порядок следования элементов:

Y = {y (i ) | y (i ) ∈ X ∩ X ' , ∀ y (i ) ∀ y ( j ) y (i ) = x ( k ), y ( j ) = x (l ), i < j → k < l } , Y ′ = {y ′(i ) | y ′(i ) ∈ X ∩ X ' , ∀y ′(i ) ∀y ′( j ) y ′(i ) = x ′(k ), y ′( j ) = x ′(l ), i < j → k < l}

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

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

2.

На наш взгляд, второй способ более предпочтителен, поскольку контроль частичного порядка операций при выполнении не вызывает дополнительных сложностей в реализации в отличие от обобщенных перестановок. Проиллюстрируем вычисление и применение дельты для упорядоченных множеств на следующем примере. Пусть X , X ′ ∈ ordered set < S > — основная и модифицированная версии коллекции символов, представленные X = {a, b, c, d , e, f } , следующими последовательностями элементов: X ' = {e, g , h, k , l , d , c, m, a}. Тогда дельта, вычисленная в соответствии с вышеописанной семантикой операций, представляется как Δ orderedset ( X ' , X ) = {prm(1,5), prm(3,4), ins(4, [2,5]),ins(1, [8,8]), del([2,2]), del([6,6])}

3.

4.

В ходе применения дельты к основной версии X операции prm(1,5), prm(3,4) переставляют элементы a, e и c, d исходного множества, приводя к промежуточным представлениям коллекции {e, b, c, d , a, f } и {e, b, d , c, a, f } соответственно. Операции ins (4, [2,5]), ins (1, [8,8]) добавляют элементы g, h, k, l перед d и элемент m перед a, формируя последовательности {e, b, g , h, k , l , d , c, a, f } и {e, b, g , h, k , l , d , c, m, a, f } . Наконец, операции 201

5.

202

Возможная алгоритмическая реализация данного этапа состоит в предварительной сортировке элементов исходных множеств (при наличии отношения полного порядка) и последовательном просмотре и идентификации элементов как удаленных, вставленных или перенесенных без изменений. Альтернативный способ заключается в непосредственном использовании процедуры поиска для установления факта наличия или отсутствия элементов в исходных множествах и в параллельном формировании структур соответствия индексов элементов. Подобные структуры обеспечивают быстрое преобразование индексов, необходимое для эффективной реализации следующих этапов. Поиск циклической перестановки элементов множества Y , приводящей к последовательности элементов множества Y ' . Наиболее простым способом реализации данного этапа видится предварительная замена алфавита исходного множества Y на последовательность натуральных чисел (1,2,... | Y |) и применение методики, применяемой в доказательстве теоремы о единственности специальной формы соединительного произведения перестановки линейно упорядоченного мультимножества [19]. {ins(...)} , Определение множества операторов вставки упорядоченного по индексам вставки элементов, используя структуры соответствия индексов элементов множеств X ' и Y ' . {del (...)} , Определение множества операторов удаления упорядоченного по индексам удаляемых элементов, используя структуры соответствия индексов элементов множеств X и Y . Формирование единого списка операций дельты в соответствии с принятым порядком исполнения: сначала следуют операции перестановок, затем — операции вставок и в конце — операции удаления.

Сформированная таким образом дельта состоит из множества независимых операций, каждая из которых может быть принята или отклонена в рамках результирующей транзакции независимо от статуса остальных операций. Вычислительная сложность построения дельты определяется в первую очередь сложностью алгоритмов сортировки, применяемых в ходе реализации. Все остальные элементы, включая алгоритм разложения перестановки на множество циклических, имеют асимптотически линейную сложность при условии использования соответствующих структур быстрого преобразования индексов. Например, описанный метод формирования дельты с использованием сортировки на основе слияния списков имеет асимптотическую оценку вычислительной сложности O (| X | ⋅ ln | X | + | X ′ | ⋅ ln | X ′ |) . Перечислим конфликтные ситуации, возникающие при реконсиляции конкурентных операций над упорядоченными множествами, а также возможные способы их разрешения. Основные конфликты сводятся к следующим содержательным случаям (опустим для краткости математическую нотацию, примеры и комментарии подобно тому, как это делалось в предыдущей главе): 1. 2. 3. 4.

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

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

8. Сортированные последовательности Наличие свойств сортировки для последовательностей элементов позволяет существенно ускорить процедуры сравнения коллекций X , X ′ ∈ sorted list < T >⊂ list < T > и применения соответствующих операций дельты Δsorted list < T > ( X ′, X ) . Способ представления дельты в этих случаях повторяет ранее описанный для произвольных списков, однако методы ее вычисления допускают оптимизацию с учетом свойств порядка. Вместо вычислительно сложных алгоритмов минимального редакторского расстояния и наибольшей общей последовательности может эффективно применяться алгоритм линейной сложности O (| X | + | X ′ |) , осуществляющий последовательный просмотр элементов версий коллекции в сортированном порядке и фиксирующий изменения сразу по ходу их просмотра. Аналогичным образом может быть оптимизирована процедура применения операций дельты, допускающая эффективный поиск элементов по индексам.

9. Последовательности фиксированной длины Наличие у последовательности элементов статически фиксированной длины вносит коррективы в способ представления дельты, наиболее адекватно отражающий ее семантику. Коллекции данного типа будем называть статическими массивами. Для подобных случаев X , X ′ ∈ array < T >⊂ list < T > будем использовать следующее представление дельты: Δarray < T > ( X ′, X ) = {alt (i, x ′[i]) | i = 1.. | X |, x ′[i] ∈ X ′} , фиксирующее индексы измененных элементов. Здесь операция alt (i, x ′[i ]) заменяет значение элемента исходного массива X с индексом i значением соответствующего элемента модифицируемого массива X ′ . Корректное представление дельты Δ = Δarray < T > ( X ′, X ) предполагает, что индексы модифицируемых элементов не повторяются в разных операциях: ∀alt1 (i1 , x ′[i1 ]) ∈ Δ ∀alt 2 (i2 , x ′[i2 ]) ∈ Δ → i1 ≠ i 2 Две конкурентные операции alt ′(i ′, x ′[i ′]) ∈ Δ ′ и alt ′′(i ′′, x ′′[i ′′]) ∈ Δ ′′ в Δ ′ = Δarray < T > ( X ′, X ) и соответствующих транзакциях Δ ′′ = Δarray < T > ( X ′′, X ) оказываются конфликтными в тех случаях, когда присваивают разные значения элементу с одним и тем же индексом: i ′ = i ′′ , x ′[i ′] ≠ x ′′[i ′′] , x ′[i ′] ⊆ X ′ , x ′′[i ′′] ⊆ X ′′ , i ′, i ′′ = 1.. | X | . Способ разрешения конфликтов подобного рода тривиален и состоит в игнорировании обеих конкурентных операций или принятии одной из них: Options = {∅; alt ′(i, x ′[i ]); alt ′′(i, x ′′[i ])} . В частном случае x ′[i ] = x ′′[i ] операции эквивалентны и не конфликтуют друг с другом. 204

Рассмотрим следующий пример согласования изменений в массиве. Пусть X , X ′, X ′′ ∈ array < S > — базовая и модифицированные версии массива символов: X = {a, b, b, d , d } , X ′ = {a, b, c, h, i} , X ′′ = {a, b, c, d , e} . Тогда соответствующие дельты представляются как Δ ′( X ′, X ) = {alt ′(3, c), alt ′(4, h), alt ′(5, i )} , Δ ′′( X ′′, X ) = {alt ′′(3, c), alt ′′(5, e)} . В данном случае операции alt ′(3, c) ∈ Δ ′ и alt ′′(3, c) ∈ Δ ′′ эквивалентны и, следовательно, в результат включается одна из них. Операция alt ′(3, c) ∈ Δ ′ переносится без изменений. Операции alt ′(5, i ) ∈ Δ ′ и alt ′′(5, e) ∈ Δ ′′ конфликтны, поэтому лишь одна из них может быть включена в результирующую дельту. В случае принятия операции второй транзакции дельта приобретает вид Δ* = {alt ′(3, c), alt ′(4, h), alt ′′(5, e)} , а итоговый массив — X * = {a, b, c, h, e} .

10. Коллекции с ограниченной мощностью Наконец, особым образом должны реализовываться процедуры применения дельты для коллекций с ограниченной мощностью. В предположении, что исходная и модифицируемая версия коллекции были корректны и удовлетворяли необходимым семантическим ограничениям, частичное применение операций дельты также должно удовлетворять наложенным ограничениям мощности (размера коллекции). Способы представления и вычисления дельты при этом не меняются и определяются иными семантическими свойствами (см. предыдущие разделы), однако применение отдельных операций удаления и добавления элементов должно проводиться в соответствии с дополнительными логическими отношениями, индуцируемыми соответствующими ограничениями. Пусть задано следующее ограничение мощности коллекции: | X |∈ [ p, q] , где p, q ∈ N . Частный случай p = q соответствует коллекции фиксированной мощности. Если Δ ins ⊂ Δ и Δ del ⊂ Δ — соответствующие подмножества операций вставки и удаления исходного представления дельты Δ = Δcollection < T > ( X ′, X ) , то должно выполняться следующее дополнительное условие: p ≤| X | + | Δ ins | − | Δ del |≤ q . Очевидно, что в случае фиксированной мощности p = q количество операций вставки и удаления в транзакции должно совпадать. Для мультимножеств Δmultiset < T > ( X ′, X ) = {card i ( xi , ni )} условие представления дельты приобретает вид p ≤| X | +

∑n

i

≤ q.

205

В случае конкурентных транзакций Δ ′, Δ ′′ приведенные выше условия должны выполняться для консолидированной дельты Δ* = Merge ( Δ ′, Δ ′′) и итогового представления коллекции X * = Apply ( X , Δ* ) . В случае | X * |< p конфликт вызывает преобладание операций удаления над операциями вставки, в случае | X * |> q — преобладание операций вставки. Логичным способом разрешения подобных конфликтов является исключение такого количества преобладающих операций, чтобы мощность итоговой коллекции удовлетворяла наложенному ограничению: | X * |∈ [ p, q ] . Очевидно, что при выборе исключаемых операций следует учитывать и другие ограничения, наложенные на коллекцию. Например, в случае ограничения уникальности операции вставки и удаления элемента с одним и тем же значением должны быть включены или исключены совместно. Рассмотрим следующий пример. Пусть X , X ′, X ′′ ∈ multiset < S > — базовая и модифицированные версии мультимножества символов с ограниченной мощностью | X |∈ [2,6] : X = {a, b, c} , X ′ = {a, b, d , e, e} , X ′′ = {a, b, e, e, e, e} . Тогда дельты, вычисленные путем сравнения модифицированных версий с базовой, представляются как Δ ′( X ′, X ) = {card ′(c,−1), card ′(d ,1), card ′(e,2)} , Δ ′′( X ′′, X ) = {card ′′(c,−1), card ′′(e,4)} . Операции card ′(c,−1) и card ′′(c,−1) эквивалентны, поэтому в результирующую дельту следует включить любую из них. Операция card ′(d ,1) не конфликтует ни с одной другой операцией, поэтому переносится в результат без изменений. Наконец, операции card ′(e,2) и card ′′(e,4) конфликтуют друг с другом. Согласно рассмотренным выше методам согласования изменений для мультимножеств, конфликт можно разрешить выбором кратности вхождения элемента e из интервала [2, 4]. Однако выбор значения кратности, равного 4, приводит к нарушению ограничения мощности результирующего мультимножества, в которое в таком случае войдет 7 элементов. Следовательно, допустимыми значениями кратности вхождения элемента e в итоговую коллекцию являются 2 и 3. В случае принятия второго значения результирующая дельта приобретает вид: Δ* = {card ′(c,−1), card ′(d ,1), card (e,3)} , а итоговое семантически корректное представление мультимножества — X * = {a, b, d , e, e, e} .

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

объектных ссылок и налагает дополнительные семантические ограничения (уникальности или мощности множественной ассоциации) на исходную модель. Пусть C1 и C 2 — объектные типы, X ∈ collection < C 2 > — прямая множественная ассоциация, Y ∈ collection < C1 > — соответствующая ей инверсная. Будем считать, что в качестве прямой ассоциации может быть использована произвольная коллекция, в качестве инверсной — set или multiset. Поскольку модификация прямой ассоциации подразумевает симметричную коррекцию инверсной, операции установления и отмены ассоциативных отношений связаны логической эквивалентностью следующим образом: ins ( x) ~ ins ( y ) , del ( x) ~ del ( y ) , x ∈ X , y ∈ Y . Поэтому данные операции обязаны совместно участвовать в итоговой транзакции. Если инверсная ассоциация представляется множеством, то дополнительно устанавливается ограничение уникальности инверсного отношения. При сочетании в качестве прямой и инверсных ассоциаций различных коллекций более строгое ограничение уникальности в итоге распространится на обе ассоциативные связи. Таким образом, возможны следующие варианты сочетания прямых и инверсных коллекций: «set–set», «multiset–multiset», «list– multiset», «ordered set–set». Нарушение ограничения уникальности прямой ассоциации автоматически приводит к аналогичному нарушению на стороне инверсной. Поэтому наличие инверсного ассоциативного отношения с уникальными элементами не вносит дополнительных корректив в способы представления и формирования дельты, а также в методы разрешения конфликтов, описанные в предыдущих разделах. Более интересным с этой точки зрения представляются ограничения мощности множественной ассоциации | X |∈ [m, n] , | Y |∈ [ p, q ] , m, n, p, q ∈ N . В данном случае корректное представление дельты предполагает выполнение следующих условий:

m ≤| X | + | Δ ins ( x ) | − | Δ del ( x ) |≤ n p ≤| Y | + | Δ ins ( y ) | − | Δ del ( y ) |≤ q В силу отношений логической эквивалентности операций над прямыми и обратными ассоциациями, условия приобретают вид:

max(m− | X |, p − | Y |) ≤| Δ ins ( x ) | − | Δ del ( x ) |≤ min(n− | X |, q − | Y |) В случае конкурентных транзакций

Δ ′, Δ ′′

данные условия должны

выполняться также для консолидированной дельты Δ* = Merge ( Δ ′, Δ ′′) .

207

12. Заключение Таким образом, рассмотрены основные типы коллекций, поддерживаемые популярными языками объектно-ориентированного моделирования. Для них определены способы представления, журнализации, вычисления, принятия и согласования изменений. Для каждого выделенного типа дается строгая, семантически состоятельная интерпретация конфликтов и предлагается конструктивный метод их идентификации и разрешения. Результаты предполагается использовать при создании универсальной, основанной на модельном представлении среды коллективной инженерии с развитыми возможностями семантически корректной и функционально содержательной реконсиляции дивергентных реплик данных. Литература [1] Y. Saito, M. Shapiro. Optimistic Replication // In ACM Computing Surveys, Vol. 37, No. 1, March 2005, pp. 42–81. [2] Better SCM Initiative: Version Control System Comparison, http://betterscm.berlios.de/comparison/comparison.html [3] Diffutils — GNU Project — Free Software Foundation (FSF), http://www.gnu.org/software/diffutils/diffutils.html [4] Z. Xing, E. Stroulia. UMLDiff: an algorithm for object-oriented design differences. // Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering, Long Beach, CA, USA, 2005, pp. 54–65. [5] Open Testware Reviews — Data Comparator Survey, http://tejasconsulting.com/opentestware/feature/data-comparator-survey.html [6] Comprehensive List of File and Folder Comparison and Synchronization Tools, http://www.foldermatch.com/fmcompetitors.htm [7] Сравнение файлов — Soft Софт каталог, http://www.softsoft.ru/search/19709/index.htm [8] Google directory — Computers > Software > File Management > File Comparison, http://www.google.com/Top/Computers/Software/File_Management/File_Comparison [9] Semenov V.A., Karaulov A.A. Semantic-Based Decomposition of Long-Lived Transactions in Advanced Collaborative Environments. // Proceedings of 6 European Conference on product and process modeling, ECPPM 2006, Spain, Valencia, September 11–15, 2006, pp.223–232. [10] Семенов В.А., Ерошкин С.Г., Караулов А.А., Энкович И.В. Семантическая реконсиляция прикладных данных на основе моделей. // Труды Института системного программирования: т. 13, ч. 2. / Под ред. В.П. Иванникова — М.: ИСП РАН, 2007, с. 141–164. [11] Semenov V.A. Collaborative Software Engineering Using Metamodel-Driven Approach. // Proceedings 16th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, WET ICE 2007, IEEE Computer Society Conference Publishing Services, 2007, pp. 178–179. [12] Semenov V.A. Semantics-Based Reconciliation of Divergent Replicas in Advanced Concurrent Engineering Environments. // Complex Systems Concurrent Engineering: Collaboration, Technology Innovation and Sustainability, Springer-Verlag, 2007, pp. 557–564.

208

[13] ISO 10303: 1994, Industrial automation systems and integration — Product data representation and exchange. [14] OMG. Model Driven Architecture: How systems will be built, http://www.omg.org/mda. [15] T. Lindholm. XML three-way merge as a reconciliation engine for mobile data. // Proceedings of the 3d ACM international workshop on data engineering for wireless and mobile access, San Diego, CA, USA, 2003, pp. 93–97. [16] J. Katajainen and J. L. Träff. A Meticulous Analysis of Mergesort Programs. // Lecture Notes In Computer Science, vol. 1203, 1997, pp. 217–228. [17] Object Constraint Language Specification, Version 2.0, http://www.omg.org/technology/documents/formal/ocl.htm [18] ISO 10303-11: 2004, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual. Edition 2. [19] Д. Кнут. Искусство программирования, том 3. Сортировка и поиск, 2-е изд. — М.: Издательский дом «Вильямс», 2000. [20] Д. Гасфилд. Строки, деревья и последовательности в алгоритмах: Информатика и вычислительная биология. — СПб.: Невский Диалект; БХВ-Петербург, 2003. [21] G. Navarro. A Guided Tour to Approximate String Matching. // ACM Computing Surveys, vol. 33, no. 1, March 2001, pp. 31–88.

209