Setvers - версионироание наборов объектов

SETVERS - ВЕРСИОНИРОАНИЕ НАБОРОВ ОБЪЕКТОВ SETVERS - VERSIONING SETS OF OBJECTS

В. Федотов, С. Рихтер, Ф. Энге V. Fedotov, S. Richter, F. Enge

Техничекий университет Берлина, ФРГ

Эта статья описывает концепцию версионирования и её программную реализацию, которая была разработана в ходе работы над проектом "proITbau"1. Библиотека, которая получила название Setvers, была разработана на основании данной концепции, и в настоящее время применяется в этом проекте. Концепция версионирования была создана для применения в области проектирования строительных процессов. Данная концепция является довольно общей, что позволяет применять её для версионирования объектной модели, описывающей любую предметную область, и её внутренних взаимосвязей.

This paper describes a versioning concept and its implementation, which has been developed in the context of the project "proITbau"1. Currently, the library, which was called Setvers, developed on the basis of this concept is applied in this project. The versioning approach has been developed preliminary for planning of construction processes. The approach however is general, allowing to version individual objects of an object-oriented domain as well as their interdependencies.

1 Введение

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

1 IT-gestützte Methoden für die Gestaltung von Planung und Ausführung; http://www.proitbau.tu-berlin.de/

6/2011 мвВЕСТНИК

называемые изменяемые данные доступны только для чтения, это необходимо чтобы предотвратить их конкурентное изменение, которое может привести к состоянию несогласованности. Данная парадигма так же известна как, блокирование-модификация-разблокирование [3].

Концепция версионирования подразделяется на следующие две категории: децентрализованное управление версиями (ДУВ) или распределённое управление версиями и централизованное управление версиями (ЦУВ). ДУВ использует одноранговый подход, в отличие от клиент-серверного используемого в ЦУВ. Каждый участник в одноранговой архитектуре имеет полную версию данных и их синхронизация, производится путём обмена специальными патчами от одного участника к другому. Центральный сервер, в системе использующей ЦУВ, хранит текущую, актуальную версию данных и историю их изменений. Клиентам необходимо подключится к серверу для получения полной копии данных. Далее клиенты продолжают работу над локальной копией данных, периодически синхронизируя состояние своих данных с сервером.

Концепцию версионирования также подразделяется на следующие два подхода: основывающийся на состоянии и основывающийся на операции. Основывающийся на состоянии подход сохраняет только определённое состояние данных. Различия между двумя различными состояниями определяются путём их сравнения. Подход, основывающийся на операции, записывает информацию о том, какие данные были изменены и вид произведённых изменений. Детальное сравнение этих подходов было рассмотрено [4].

Для версионирования исходного кода программ, было разработано большое количество систем управления версиями (СУВ). Стандартные СУВ для версионирования исходного кода обычно работают на уровне файлов и выявляют различия и конфликты, производя сравнение файлов при помощи строко-ориентированных алгоритмов. Не смотря на то, что СУВ широко применяются в области версионирования данных хранящихся в файлах или документах, всё же стоит отметить, что их применение затруднено, а порой и вообще невозможно в областях использующих графа-подобные структуры данных. Среди прочего, графа-подобные структуры данных встречаются в объектной или объектно-ориентированной среде, в области конфигурационного управления (КУ), а также, при использовании - разработки, управляемой моделями (РУМ) [5]. В области КУ был разработан единый подход версионирования на основе так называемых Версионных Групп Модели. [6] в своей статье представляют информационную систему для распределённой сетевой архитектуры в области гражданского и промышленного проектирования, которая предоставляет интерфейс для сохранения версионных объектов модели. Версионирование объектов основано на графе версий и графе связей. Объекты сохраняются в виде файлов при помощи БУЫ, которая выступает в качестве СУВ [7].

[8] описывают подход версионирования, который отслеживает развитие модели в программе на уровне объектов. Различные версии каждого объекта данной модели сохраняются, создавая в конечном итоге граф версий. Ссылки между объектами рассматриваются в качестве связей, которые формируют граф связей. Граф связей необходим для поддержания модели в согласованном состоянии. Основываясь на этой концепции, [9] разработали подход на основе наборов, основная идея которого состоит в том, что объекты не рассматриваются индивидуально, а объединяются в специальные наборы на основе типов объектов. Данный подход призван уменьшить сложность при выборе согласованной модели.

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

2 Описание

2.1 Объект

Объект является представлением какой-либо сущности. Для определения уникальности сущности используется уникальный идентификатор. Данный идентификатор сохраняется вместе с объектом, так как он является его частью, это означает, что объект возможно однозначно идентифицировать между запусками приложения. Идентификатор присваивается объекту единожды при его создании, и в дальнейшем, в течение жизненного цикла объекта, идентификатор не может быть изменён. Объект может ссылаться на другие объекты. Если объект а ссылается на объект Ь, это означает, что объект Ь связан с а, а также, что объект а указывает на Ь. Это отношение связанности на уровне объектов представляет собой направленный ацикличный граф. Объекты различных классов, являющиеся частью модели, представляют собой определённый домен. В модели может быть представлена только одна версия конкретного объекта, также должно соблюдаться следующее условие: если объект а является частью модели, модель должна содержать все объекты, которые связаны с объектом а. Ссылки одних объектов на другие или, говоря иначе, зависимости одних объектов от других и формируют граф связей объектов. Любая комбинация объектов может считаться моделью, если выполняются следующие условия:

• Только одна версия объекта может быть частью модели. Очевидно, что из этого условия следует невозможность существования различных версий объекта в одной модели;

• Если какой-либо объект связан с другими объектами и данный объект является частью модели, связанные объекты также должны быть частью этой модели.

2.2 Версионный набор

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

Если объект содержащийся в версионном наборе А ссылается на объект в версионном наборе В, то это отношение также называется связью и обозначает, что версионный набор В связан с А, а также, что А указывает на В. Как понятно из контекста, данная связь находится на уровне наборов. Ситуация, когда версионный набор B связан с А, но при этом не все объекты а, в версионном наборе А ссылаются на объекты Ь, в версионном наборе В, является вполне допустимой. Необходимо отметить и то, что если хотя бы один объект версионного набора А ссылается на любой из объектов вер-

6/2011

ВЕСТНИК МГСУ

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

Как следует из выше сказанного, любая комбинация версионных наборов является моделью если соблюдены следующие условия:

• Только один версионный набор с определённым типом класса может быть частью модели;

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

• Если с определённым версионным набором связанны другие наборы, они также должны быть включены в модель.

Пример версионных наборов, сохранённых в определённый момент времени, изображён на рисунке 1. Данный пример содержит три графа версий на уровне наборов: один для объектов типа А, один для В и один для типа С. Также на рисунке изображены связи между различными типами версионных наборов, которые формируют четыре различных графа связей. Наборы, соединённые версионным отношением, содержат объекты одного типа. Связи между различными версионными наборами определяются ссылками между объектами. Для примера, если выбрать набор типа В с идентификатором равным 4, то набор типа А с идентификатором равным 1 и набор типа С с идентификатором равным 8 будут также выбраны, так как этого требует отношение связанности между этими наборами, все эти наборы вместе формируют модель. В данном примере также возможно существование и других моделей.

//////// -Начальный набор

-Модель

ид -Уникальный идентификатор

Рис. 1 Граф версий и граф связей на уровне наборов

2.3 Версионирование объектов и версионных наборов

В отличие от версионирования объектов, где один объект имеет различные состояния, версионирование наборов реализовано иначе. Два набора, содержащие объекты одного типа, фактически являются различными представлениями одного набора в различных состояниях. Версионные отношения сохраняются явно в каждом версион-ном наборе. Для примера: версионный набор А с идентификатором равным 3, пред-

ставленный на рисунке 1, ссылается на набор того же типа с идентификатором равным 2, который представляет предыдущее состояние этого версионного набора. Данный способ организации различных версий версионных наборов, является необходимым, так как механизм версионирования доступный для объектов не подходит для работы с наборами (как упоминалось ранее механизм аудирования объектов обеспечивается сторонней библиотекой Envers). Все изменения, производимые над объектами, сохраняются последовательно из чего следует, что граф версий объектов не может содержать разветвлений и объединений. Данные возможности, позволяющие в определённый момент времени создавать разветвления и объединения, реализованы на уровне наборов.

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

3 Последовательность действий при работе с версионными наборами

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

Рассматриваемый подход версионирования, основанный на версионных наборах, имеет стандартную последовательность действий, которая основана на следующих трёх базовых шагах:

• Выбор версионного набора;

• Процесс моделирования;

• Применение изменений.

Рисунок 2 служит иллюстрацией данных шагов.

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

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

6/2011

ВЕСТНИК _МГСУ

всрьиаптио пааора

О

О—*0—»0—0-0

Сравнение старых и новых версисимъи наборов

с

И II II II II

о

с>-»о—о*

р—кр—о—

Г > Подключение к глобальной БД

Глобал. БД О

Окончательная структура ^ графа версий и связей

................ ..........................................прт^и№ив~иУмён*нйи1~

Рис. 2 Стандартная последовательность действий при работе с версионными наборами

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

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

Загруженные на первом шаге версионные наборы устанавливаются в качестве предшественника для вновь созданных наборов. Если локальная модель или её часть была создана впервые, предшественник будет нулевым. Только новые наборы загружаются в глобальную базу данных. Те версионные наборы, которые не подверглись изменениям, игнорируются. Помимо самих версионных наборов, объекты которые в них содержатся, также будут загружены в глобальную базу данных, при условии, что они были созданы или изменены в процессе моделирования.

4 Реализация

4.1 Hibernate и Envers

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

Не смотря на обширный функционал, предлагаемый фреймворком Hibernate, он способен хранить только актуальное состояние объекта в базе данных, информация об истории изменений объекта не сохраняется. Данную функциональность обеспечивает библиотека Envers, которая производит аудит объекта, сохраняя в специальных таблицах тип изменения и новое состояние атрибута, для каждого объекта, отмеченного специальной аннотацией. Каждый раз при изменении какого-либо атрибута, какого-либо объекта, создаётся новая ревизия, номер которой хранится в одной общей таблице. Актуальное состояние объекта по прежнему хранится в соответствующей этому объекту таблице. История изменений представлена в таблице базы данных в следующем формате: уникальный идентификатор объекта, номер ревизии, тип модификации (0 - создание, 1 - изменение, 2 - удаление) и столбцы с актуальным на момент ревизии атрибутами объекта. Название таблицы, в которой хранится история изменений, имеет следующий вид: имя_объекта_аис1. К сожалению, данной функциональности также недостаточно, так как данный поход аудирования не позволяет создавать разветвления на несколько параллельных веток историй изменений, которые, к примеру, могут возникнуть при одновременной модификации одного объекта одним или несколькими пользователями. Также отсутствует возможность произвести объединение различных версий объекта. Разработанная библиотека Setvers реализует данный функционал, добавляя также и друге дополнительные возможности для хранения различных версий объектов в базе данных. Базовые методы упомянутой библиотеки для аудита объектов частично использует функциональность реализованную в библиотеке Envers.

4.2 Версиоиироваиие объектов при помощи версионных наборов

Для обеспечения версионирования объектов при помощи версионных наборов, необходима дополнительная функциональность, которая не доступна при использовании фреймворка Hibernate и библиотеки Envers. Для добавления необходимого функционала, отвечающего поставленным требованиям и была разработана библиотека Setvers. Данная библиотека определяет специальную аннотацию - @VersionedEntity,

6/2011 ВЕСТНИК

которая указывает библиотеке Setvers на то, что данный объект должен являться частью версионного набора. Эта аннотация требует наличия также аннотации @Audited, являющейся частью библиотеки Envers, которая в свою очередь требует указания аннотации @Entity - основной аннотации фреймворка Hibernate. На Рисунке 3 приведена выдержка из кода, описывающего класс, написанного на языке программирования Java, со всеми необходимыми аннотациями.

1 gVersionedEntity 4 public class SomeCiass{

Рис. 3. Пример Java класса со всеми необходимыми для версионирования

аннотациями

4.3 Сравнение версионных наборов

Механизм сравнения применяется для определения идентичности состояния версионного набора на момент его загрузки из глобальной базы данных с его актуальным состоянием. Алгоритм сравнения выполняется по следующим последовательным шагам: сначала производится сравнение количества объектов содержащихся в сравниваемых наборах, данная процедура выполняется первой, так как это наиболее простой и быстрый способ выявления того, что загруженный набор был изменён. Если количество объектов в наборах одинаково, алгоритм сравнения переходит непосредственно к сравнению объектов, содержащихся в наборах. Первоначально производится сравнение уникальных идентификаторов объектов, если оба набора содержат объекты с одним и тем же идентификатором, то алгоритм приступает к сравнению значений всех атрибутов этих объектов. Объект считается изменённым, если хотя бы значение одного его атрибута было изменено, в противном случае объект рассматривается как неизменённый. Алгоритм сравнения подразделяет сравниваемые атрибуты на: примитивные типы Java, встроенные типы Java, имеющие аннотацию @VersionedEntity, и все остальные. Примитивные типы Java сравниваются по значению (при помощи оператора "=="), типы имеющие аннотацию @VersionedEntity сравниваются по идентификатору, встроенные типы и все прочие сравниваются стандартным механизмом, предлагаемым языком программирования Java (методом equals()). Описанный выше алгоритм сравнения, реализует класс Comparator, являющийся одним из основных классов библиотеки Setvers.

4.4 Взаимодействие с библиотекой Setvers

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

Для преобразования объектов локальной модели в версионные наборы, используется класс Convertor, также предоставляемый библиотекой Setvers. Ещё одним важным элементом библиотеки является интерфейс Versionable. Необходимо, чтобы один из классов локальной модели реализовывал данный интерфейс. Данный интерфейс определяет один метод - getModel(), основное предназначение которого, объединить все объекты локальной модели в одну коллекцию. Метод convert() класс Convertor принимает эту коллекцию в качестве параметра и преобразует её в версионные наборы. Метод convert() также определяет и устанавливает все необходимые связи между верси-онными наборами на основе объектных ссылок. Таким образом, пользователь получает новое состояние локальной модели в виде версионных наборов.

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

5 Заключение

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

6 Благодарности

Результаты исследований, представленные в данной статье, были разработаны в ходе работы над проектом "IT-based Methods for the Design of Planning and Construction Processes". Проект осуществляется при поддержки TSB Technologiestiftung Berlin и финансируется совместно с Europäischer Fonds für Regionale Entwicklung.

References

1. King, G, Bauer, C, Andersen, MA, Bernard, E, Ebersole, S & Ferentschik, H - Red Hat, Inc. 2011, Hibernate - Relational Persistence for Idiomatic Java, viewed 08 July 2011, <http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html_single/>.

2. Warski, A - Red Hat, Inc. 2011, Hibernate Envers - Easy Entity Auditing, viewed 08 July 2011, <http://docs.jboss.org/hibernate/envers/3.6/reference/en-US/html_single/>.

3. Al-Khudair, A, Gray, W & Miles, J 2001, 'Object-oriented versioning in a concurrent engineering design environment. Advances in Databases', BNCOD 18 Proceedings of the 18th British National Conference on Databases: Advances in Databases, Springer-Verlag London, UK, pp. 105-125.

4. Collins-Sussman, B, Fitzpatrick, BW & Pilato, CM 2008, Version Control with Subversion, viewed 08 July 2011, <http://svnbook.red-bean.com/en/1.0/ch02s02.html>.

5. Koegel, M, Herrmannsdoerfer, M, Helming, J & Li, Y 2009, 'State-Based vs. Operation-based Change Tracking', ModSE-MCCM '09: Proc. of the Joint ModSE-MCCM Workshop on Models and Evolution, pp. 1-9, viewed 08 July 2011.

6/2Q11 мвВЕСТНИК

6. Bézivin, J 2003, 'On the Unification Power of Models', paper is based on a guest talk presentation given at the UML '2003 conference in San Francisco and entitled: MDA: From Hype to Hope, and Reality', Springer, pp. 171-188.

7. Beer, DG, Firmenich, B & Beuck, KE 2006, 'A system architecture for net-distributed applications in civil engineering', Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada.

8. Firmenich, B, Koch, C, Richter, T & Beer, DG 2005, 'Versioning structured object sets using text based Version Control Systems', 22nd CIB W78 Conference on Information Technology in Construction, Dresden.

9. Pahl, P & Beucke, K 2000, 'Neuere Konzepte des CAD im Bauwesen; Stand und Entwicklungen processes', Internationalen Kolloquiums über Anwendungen der Informatik und Mathematik in Architektur und Bauwesen (IKM), Weimar, Bauhaus-Universität.

10. Beer, DG & Firmenich, B 2000, 'Freigabebestände von strukturierten Objektversionsmengen in Bauprojekten', IKM, Weimar, Bauhaus-Universität.

11. Huhnt, W & Richter, S 2008, 'Modification management for planning processes' paper presented to the Workshop Intelligent Computing in Engineering, Plymouth.

Ключевые слова: версионирование, проектирование строительных процессов, программная библиотека, Setvers, Hibernate, Envers, база данных, объектно-реляционное проецирование.

Key words: versioning, planning of construction processes, software library, Setvers, Hibernate, Envers, database, object-relational mapping.

e-mail автора: vladislav.fedotov@tu-berlin.de Статья представлена Редакционным советом «Вестника МГСУ»