«IS-THE»-отношения в семантических моделях данных: основные понятия и разновидности Текст научной статьи по специальности «Компьютерные и информационные науки»

ВЕСТНИК ТОМСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА

2016 Управление, вычислительная техника и информатика № 1 (34)

ИНФОРМАТИКА И ПРОГРАММИРОВАНИЕ

УДК 004.652.8

DOI: 10.17223/19988605/34/8

А.М. Бабанов, Е.С. Квач

«К-ТНЕ»-ОТНОШЕНИЯ В СЕМАНТИЧЕСКИХ МОДЕЛЯХ ДАННЫХ: ОСНОВНЫЕ ПОНЯТИЯ И РАЗНОВИДНОСТИ

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

Ключевые слова: «IS-THE^-отношение; «IS-THE^-кластер; «IS-THE^-категоризация; семантическая модель данных; ERM-модель.

«IS-Aw-отношения (отношения «ЕСТЬ-НЕКОТОРЫЙ») являются важным элементом человеческой умственной деятельности (не только научной). И на бытовом уровне мы часто используем обобщенные и специализированные понятия: «Пушкин А.С. есть некоторый поэт», «Поэт есть некоторый человек».

Что же касается науки, то в ней операции обобщения и специализации являются важными мыслительными инструментами, позволяющими переходить от частных явлений к их абстракциям различных уровней и наоборот. Многочисленные классификации в различных отраслях науки тому подтверждение. Это важное для человека явление давно изучается исследователями, правда, задачи конкретной науки накладывают свой отпечаток на представление об этом предмете [1, 2]. Соответственно, используются и различные термины для обозначения «К-А»-отношений: собственно «К-А»-отношение, «К-Г№>-отношение (семантические сети), отношение наследования (системы представления знаний и системы объектно-ориентированного программирования), отношения принадлежности и включения (теория множеств), операции обобщения и ограничения понятий (логика), отношения «суперкласс-подкласс», «супертип-подтип» и т.п. Интуитивно все эти термины имеют близкие смыслы, но есть и существенные отличия.

В [2, 3] выделяют две группы смысловых значений «К-А»-отношений - класс / объект (англ. generic / individual) и класс / класс (англ. generic / generic). Первую группу составляют трактовки этого отношения, близкие теоретико-множественному отношению принадлежности элемента множеству. Вторую группу составляют трактовки «К-А»-отношения, близкие теоретико-множественному отношению включения одного множества в другое.

В моделировании данных эта естественная для людей форма представления информации была предложена не сразу. В семантических моделях она появилась вместе с расширенной моделью «Сущность-Связь» (Enhanced / Extended Entity-Relationship Model - EERM) в 80-х гг. прошлого века [4, 5]. В этой модели для представления «К-А»-отношений введены такие структурные понятия, как специализация и категоризация.

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

нятие «К-ТНЕ»-отношения (отношения «ЕСТЬ-ЭТОТ»), ориентированного на моделирование данных, и предпринята попытка синтеза логически непротиворечивого понятийного базиса рассматриваемого явления. Далее в работе будут определены разновидности структур данных для представления «К-ТНЕ»-отношений при моделировании данных. Среди них будут и уже традиционные специализация и категоризация.

Приведенные определения положены в основу правил структуризации данных и определения ограничений целостности семантической модели «Сущность-Связь-Отображение» (Entity-Relationship-Mapping Model - ERMM) [6], касающихся представления в ней «К-ТНЕ»-отношений.

1. Базовые понятия «IS-A^-отношений

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

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

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

Деление является правильным, если оно удовлетворяет следующим условиям:

1. Деление должно происходить по одному определенному основанию.

2. Полученные при делении понятия должны быть попарно несовместимы.

3. Члены деления как классы должны исчерпывать объем исходного понятия.

4. Никакой из членов деления не должен быть пустым классом.

5. Деление должно быть непрерывным, т.е. все его члены являются ближайшими видами исходного понятия, выделяемыми по выбранному основанию» [7].

В. А. Бочаров и В.И. Маркин дополняют эту картину рассмотрением возможных вариантов деления понятий.

«С каждым делением связывается основание деления - такая характеристика предметов, входящих в объем делимого понятия, модификация которой и порождает систему членов деления. В зависимости от того, что берется в качестве основания деления, различают два их вида - дихотомическое деление и деление по видоизменению основания. В случае дихотомического деления родового понятия основанием деления является некоторый признак, присущий лишь части предметов, входящих в объем исходного понятия. Деление осуществляется по наличию или отсутствию этого признака у предметов делимого понятия. В случае деления по видоизменению основания в качестве основания деления используются предметно-функциональные характеристики элементов объема делимого понятия. Необходимо только, чтобы предметная функция, берущаяся в качестве основания, была всюду определенной на этом объеме. При таком делении объемы видовых понятий представляют собой собрания тех и только тех предметов a и b, для которых выполняется условие fa) = f(b).

Всякое деление должно осуществляться по одному основанию» [8].

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

По мнению специалистов по моделированию данных, специализация - это:

- «процесс выделения подклассов в суперклассе, который основан на группировке исключительных характеристик и связей подклассов» [9];

- «процесс выявления различий между экземплярами типа сущностей» [10];

- «процесс определения набора подклассов для типа сущностей на основе отличительных характеристик» [11];

- «процедура, в ходе которой вводятся подклассы более общих типов сущностей, чтобы объявить, что определенные роли зарегистрированы только для этих подклассов» [12];

- «процесс концептуального уточнения суперкласса путем выделения подклассов» [13].

Как видим, если логики обращают внимание, прежде всего, на содержание (признак) понятий деления, то специалисты по моделированию данных видят преимущественно структурные и ограничительные особенности классов данных. Главное назначение специализаций в моделировании данных -возможность группирования признаков (атрибутов и типов связей): обобщенные поднимаются на уровень суперкласса, специализированные опускаются до соответствующего подкласса. Т. Халпин, кроме этого, замечает, что специализации позволяют делать опциональные роли суперкласса обязательными для подкласса и за счет этого вводить дополнительные ограничения целостности [12. Р. 238].

И только Дж. Смит и Д. Смит подходят к концепции специализации аналогично логикам.

«Наш метод представления родовой иерархии требует, чтобы непосредственные потомки любого узла были разбиты на группы. Каждая группа должна содержать родовые объекты, классы которых являются взаимно исключающими. На практике такое группирование обычно может быть весьма легко сделано из семантических соображений. Например, потомки класса Транспорт могли бы быть сгруппированы следующим образом: {Транспортные средства, приводимые в движение ветром; Моторизованные транспортные средства; Транспортные средства, приводимые в движение человеком} и {Воздушный транспорт; Водный транспорт; Наземный транспорт}. Первая группа содержит взаимно-исключающие классы, которые соответствуют альтернативным типам "Системы приведения в движение". Вторая группа, в свою очередь, содержит взаимно исключающие классы, которые соответствуют различным типам "Среды передвижения"».

Назовем взаимно исключающие группы родовых объектов, имеющие общие родительские объекты, кластерами. Будем говорить, что кластер относится к его родительскому родовому объекту. Например, мы можем говорить о двух кластерах, относящихся к типу объектов Транспорт. Кластер, относящийся к "Моторизованным транспортным средствам", и кластер, относящийся к "Воздушному транспорту", могут иметь общий элемент - Вертолет» [14].

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

2. Дополнительные понятия «18-А»-отношений

Важными понятиями, сопутствующими рассмотрению «К-А»-отношений, являются понятия, применяемые к элементам этих отношений.

«Если экземпляры типа объектов классифицируются в более специфичный тип, то этот специализированный тип называется подтипом» [12. Р. 260]. «Супертип - это обобщенная форма его подтипов, в таком случае подтип - специализированная форма супертипа» [Там же].

«Суперкласс - тип сущностей, включающий одну или несколько различимых вспомогательных группировок его экземпляров, которые должны быть представлены в модели данных. Подкласс - различимая вспомогательная группировка экземпляров типа сущностей, которая должна быть представлена в модели данных» [4. С. 430]. «Связь между суперклассом и подклассом является связью "один-к-одному" (1 : 1) и называется связью суперкласс / подкласс» [Там же. С. 431].

Одни авторы (Халпин) предпочитают рассматривать иерархии обобщения типов данных, другие, такие как Т. Коннолли и К. Бэгг, строят «К-А»-иерархии на классах данных. Логики же говорят об

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

Действительно, «понятие - это мысль, которая посредством указания на некоторый признак (содержание понятия) выделяет из универсума и собирает в класс (обобщает) все предметы, обладающие этим признаком (объем понятия) [8]». И далее: «Содержание представляет собой интенсиональную характеристику понятия; экстенсиональной характеристикой понятия является его объем» [8]. Таким образом, говоря об иерархии понятий, мы предполагаем и иерархию признаков, и иерархию объемов. Оба эти аспекта исчерпывают вариации других авторов.

В таком случае, рассматривая двухуровневую «К-А»-иерархию, корректнее говорить о родовом (аналог супертипа или суперкласса) и видовых (аналоги подтипов или подклассов) понятиях, точнее, системе видовых понятий. Содержание видового понятия отличает от содержания родового понятия дополнительное условие (видовое отличие), которое истинно для объектов объема этого видового понятия. Таким образом, спуск по «К-А»-иерархии сопровождается усложнением содержания понятий. Что касается объемов понятий, то чем выше уровень понятия в «К-А»-иерархии, тем его объем шире, и, наоборот, опускаясь вниз, мы переходим от объемов родовых понятий к их подмножествам - объемам видовых понятий.

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

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

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

3. Понятие «IS-THE^-отношения

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

Прежде чем говорить о представлении «К-А»-отношений в моделях данных, введем понятие «IS-THE»-отношения.

Два элемента объемов разных понятий связаны «IS-THE»-отношением (отношением «ЕСТЬ-ЭТОТ») тогда и только тогда, когда они представляют один и тот же объект предметной области (ПрО) (отсюда использование определенного артикля «THE»). Например, фраза «Пациент Иванов есть этот врач Иванов» описывает ситуацию с заболевшим врачом. «IS-THE»-отношение - это бинарное 1 : 1-отношение, определяющее пару взаимообратных функциональных «IS-THE»-отображений. В этом отношении и отображениях участвуют непосредственно объекты ПрО (когда речь идет о законе соответствия объектов) или их абстракции - данные (когда речь идет об аналогичном законе соответствия данных, представляющих объекты).

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

разом, один и тот же объект может быть представлен в нескольких различных структурах данных. Именно между этими элементами-абстракциями одного и того же объекта и устанавливается «К-ТНЕ»-отношение в данных. Если известные трактовки «К-А»-отношения связывают класс с объектом или класс с классом, то в «К-ТНЕ»-отношения вступают объекты.

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

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

4. Разновидности «18-ТНЕ»-отношений и дополнительные понятия

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

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

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

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

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

Понятие «18-ТНЕ»-кластера совпадает по смыслу с понятием двухуровневой специализации, подклассы которой образованы в соответствии с одним и тем же основанием. Например, рассмотрим специализацию людей на мужчин и женщин (рис. 1). Видовое отличие мужчин - «Пол = 'мужской'», женщин - «Пол = 'женский'». И в том и в другом случае используется одно и то же отображение (Пол). От-

личаются объекты подклассов только своими образами при этом отображении. С точки зрения логики имеем деление по видоизменению основания.

Рис. 1. «18-ТНЕ»-кластер

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

Многие исследователи семантических моделей и авторы, повествующие о них, используют термин «специализация» и для обозначения процесса порождения подклассов, и для обозначения его результата - двухуровневой иерархии. Так, Т. Халпин определяет специализацию и как «процедуру, в ходе которой вводятся подклассы более общих типов сущностей» [12. Р. 260], и как «граф подтипов, который может возникнуть нисходящим способом, специализируя тип объекта в подтипы» [Там же. Р. 244]. На наш взгляд, корректнее использовать этот термин только для процесса (и тут все авторы солидарны), а результат именовать «18-ТНЕ»-кластером (в случае двух уровней) или графом кластеров (в случае нескольких уровней). Такой подход позволит к тому же непротиворечиво ввести типизацию структур, некоторые элементы которой не имеют ничего общего со специализациями.

Подавляющее большинство «К-ТНЕ»-отношений, представляющих интерес при построении БД, определяется «18-ТНЕ»-кластерами и подразумевает полное наследование родительских признаков (атрибутов и связей) объектами дочерних понятий. То есть эти признаки на видовом уровне не декларируются, а предполагаются.

В ЕЯМ-модели значимые объекты ПрО представляются, так же как и в ЕЯ-модели, сущностями. Каждая сущность является абстракцией объекта, построенной в соответствии с некоторым понятием о предметах. Один и тот же объект ПрО, таким образом, может быть представлен несколькими сущностями разных типов. После введения таких представлений можно утверждать, что каждый «К-ТНЕ»-кластер определяет полное функциональное «18-ТНЕ»-отображение между объединением множеств сущностей видовых понятий и множеством сущностей родового понятия. Это является отличительной особенностью «К-ТНЕ»-отношений с полным наследованием. Также действует полное функциональное «18-ТНЕ»-отображение между каждым из множеств сущностей видовых понятий и множеством сущностей родового понятия.

В том случае, когда множество сущностей является подклассом только в одном «К-ТНЕ»-кластере (соответствующее видовое понятие связано только с одним родовым понятием), говорят, что осуществляется полное единичное наследование. Когда множество сущностей входит подклассом в несколько «18-ТНЕ»-кластеров (соответствующее видовое понятие связано с несколькими родовыми понятиями), говорят, что осуществляется полное множественное наследование. Но и в этом случае сущности подкласса наследуют признаки всех своих родителей. В обоих случаях полного наследования «К-ТНЕ»-отношение представляет собой широко известное отношение наследования. Направление гиперребра «18-ТНЕ»-кластера указывает на родовое понятие, определяющее наследуемые признаки.

В моделировании данных введен особый подвид двухуровневых «К-А»-иерархий - категоризации, определяющие особые «К-ТНЕ»-отношения между объединением множеств сущностей-суперклассов и множеством сущностей-подклассом, в этом случае называемым категорией [4. С. 209]. Чтобы лучше всего понять суть категоризации, надо представить содержание понятия, объем которого представлен множеством сущностей-подклассов. Первая часть его логического выражения - дизъюнкция условий содержаний множеств сущностей-суперклассов, а вторая часть - условие, которому долж-

ны удовлетворять сущности этих множеств, чтобы быть представленными в категории. Такие двухуровневые «К-А»-иерархии будем называть «18-ТНЕ»-категоризациями (или просто категоризациями).

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

По аналогии с «18-ТНЕ»-кластерами можно утверждать, что с каждой «18-ТНЕ»-категоризацией связано полное функциональное отображение между множеством сущностей-категорией и объединением множеств сущностей-суперклассов. А вот между множеством сущностей-категорией и каждым из множеств сущностей-суперклассов имеется частичное функциональное отображение. Что касается обратных отображений, то в зависимости от семантики ПрО они могут быть как полностью определенными, так и нет.

Для представления «18-ТНЕ»-категоризаций также можно использовать ориентированные гиперребра, только в отличие от «18-ТНЕ»-кластеров они соединяют начальную вершину, представляющую подкласс (категорию), и в общем случае несколько конечных вершин, представляющих суперклассы.

Типичным примером «18-ТНЕ»-категоризации являются «К-ТНЕ»-отношения между понятием «субъект права» и понятиями, объекты которых могут выступать в роли владельцев прав, - физическое лицо, юридическое лицо и административно-территориальное образование (рис. 2). Действительно, каждый субъект права - это или гражданин, или организация, или территория, и в зависимости от этого наследуются признаки соответствующего суперкласса.

Рис. 2. «IS-THE^-категоризация

Теперь для «IS-THEw-кластеров и «IS-THEw-категоризаций (и только для них) можно ввести обобщенные понятия «суперкласс» и «подкласс». Суперкласс определяет наследуемые признаки, а элементы подклассов их наследуют. В сторону суперклассов ориентированы гиперребра, представляющие эти структуры.

В зависимости от применяемого при образовании «К-ТНЕ»-кластера принципа и основания деления суперкласса на подклассы выделяют кластеры с динамичным и статичным набором подклассов. Если в ходе эволюции данных возможно появление нового подкласса - кластер динамичен, если нет - статичен. При использовании метода дихотомии всегда образуются два статичных подкласса: для объектов одного признак деления истинен, для объектов другого - ложен. Чаще всего второй подкласс не создается, а его экстенсионал определяется как разность экстенсионала суперкласса и экстенсионала другого подкласса. В случае деления по видоизменению основания статичность и динамичность кластера определяет то, под все возможные образы дискриминирующего отображения созданы подклассы или нет.

Предыдущие типы «К-ТНЕ»-кластеров характеризовали интенсионал данных, т.е. определялись на основании статичности или динамичности схемы данных. Статичность или динамичность самих данных (экстенсионала) приводит к кластерам со стабильными или мигрирующими экземплярами подклассов. Т. Халпин называет эти разновидности кластеров строгими (rigid) и ролевыми (role) соответственно [12. Р. 251].

Во многих моделях данных (в частности, в реляционной модели, модели «Объект-Роль» Халпина, ERMM) в схеме данных выделяются так называемые хранимые и получаемые структуры. Т. Халпин говорит даже о трех состояниях данных - хранимые, получаемые и частично получаемые.

«Получаемый (англ. derived) факт - это факт, который выводится из других фактов математическими вычислениями или логическим выводом. Факт, который нельзя вывести из других фактов, называется хранимым или утверждаемым пользователем (англ. asserted) фактом. Для каждого получаемого факта в схеме данных задается правило его получения» [12. Р. 33]. «Частично получаемый (англ. semi-derived) тип фактов определяется в том случае, когда ряд фактов этого типа можно вывести, а другие факты будут заданы пользователем» [12. Р. 99].

Что касается «IS-THE»-кластеров, то, как уже отмечалось, альтернативной формой представления информации о принадлежности объекта подклассу является наличие соответствующего экземпляра дискриминирующего отображения. Именно между этими формами данных и осуществляет выбор проектировщик схемы, в каждом конкретном случае предпочитая либо хранение экстенсионалов подклассов (хранимый кластер), либо хранение экземпляров отображения (получаемый кластер), либо их смесь (частично получаемый кластер).

Кстати, именно характер дискриминирующего отображения определяет еще одну типизацию «IS-THE»-кластеров, которую упоминают многие авторы [4, 12]. Это деление специализаций на полные и частичные, пересекающиеся и непересекающиеся. Некоторые говорят об этих видах специализаций как об особом типе ограничений целостности на специализации [4. С. 208].

Вот как определяются эти типы «IS-THE»-кластеров в ERM-модели в том случае, когда при делении по видоизменению основания создаются подклассы для всех образов. Если дискриминирующее отображение - полное функциональное, кластер является полным непересекающимся. Если дискриминирующее отображение - частичное функциональное, кластер является частичным непересекающимся. Если дискриминирующее отображение - полное нефункциональное, кластер является полным пересекающимся. Если дискриминирующее отображение - неограниченное, кластер является частичным пересекающимся.

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

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

Для «IS-THE»-категоризаций существует похожее деление на полные и частичные [4. С. 210]. Если каждый объект всех суперклассов присутствует в подклассе-категории, категоризация считается полной, если есть объекты суперклассов, не отображенные в категории, категоризация частичная. Или на языке отображений: если отображение из объединения суперклассов в категорию - полное функциональное, категоризация полная, если оно - частичное функциональное, категоризация частичная.

И, наконец, в ERM-модели можно строить «IS-THE»-графы на классах одного, но любого типа -множествах сущностей, множествах связей или множествах значений. Это имеет практическое значение и хорошо соотносится с логикой: там наряду с понятиями о предметах (сущностях и значениях) рассматривают и понятия об n-ках предметов (связях). Обобщение множеств сущностей и множеств значений (типов данных) стало уже стандартом во многих областях информатики. Потребность в построении «К-А»-иерархий множеств связей встречалась до сих пор только в системах представления знаний. Теперь такое возможно и в системах баз данных.

Заключение

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

ERM предпринята попытка непротиворечивого включения «К-А»-иерархий в правила построения структур и ограничений целостности. Основным принципом является следование безупречным логическим канонам при сохранении той функциональности этих структур, которая сложилась в моделировании данных. Настоящая статья закладывает основы правил использования «IS-THE»-отношений в виде определений базовых понятий и рассмотрения системы типизации структур, предназначенных для представления этих отношений в данных. В последующих статьях авторы постараются полнее раскрыть феномен «IS-THE»-отношений и их использование в моделировании данных.

ЛИТЕРАТУРА

1. Wang P. From Inheritance Relation to Nonaxiomatic Logic // International Journal of Approximate Reasoning. 1994. No. 11. P. 281-

319.

2. Palomaki J., Kangassalo H. That IS-IN Isn't IS-A: A Further Analysis of Taxonomic Links in Conceptual Modelling // Advances in

Knowledge Representation. 2012. P. 3-18.

3. Brachman R.J. What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks // IEEE Computer. 1983. V. 16,

№>. 10. P. 30-36.

4. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 2-е изд. М. : Вильямс,

2000. 1120 с.

5. Teorey T., Yang D., Fry J. A Logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model //

Computing Surveys. 1986. V. 18, No. 2. P. 197-222.

6. Бабанов А.М. Семантическая модель «Сущность - Связь - Отображение» // Вестник Томского государственного универси-

тета. Управление, вычислительная техника и информатика. 2007. № 1. С. 77-91.

7. Войшвилло Е.К., Дегтярев М.Г. Логика как часть теории познания и научной методологии (фундаментальный курс) : в 2 кн.

М. : Наука, 1994.

8. Бачаров В.А., Маркин В.И. Основы логики. М. : Инфра-М, 1998. 297 с.

9. Coronel С., Morris S., Rob P. Database Systems: Design, Implementation, and Management. 10th ed. Course Technology, 2013. 1054

p.

10. Connolly T., Begg C. Database Systems: A Practical Approach to Design, Implementation, and Management. 4th ed. Addison-Wesley, 2010. 1400 p.

11. Elmasri R., Navathe S. Fundamentals of Database Systems. 6th ed. Addison-Wesley, 2010. 1200 p.

12. Halpin T., Morgan T. Information Modeling and Relational Databases. 2nd ed. Morgan Kaufman, 2008. 943 p.

13. Ferraggine V., Doorn J., Rivero L. Handbook of Research on Innovations in Database Technologies and Applications: Current and Future Trends. Information Science Reference, 2009. 1124 p.

14. Smith J., Smith D. Database Abstractions: Aggregation and Generalization // ACM Transactions on Database Systems. 1977. V. 2, No. 2. P. 105-133.

15. Бабанов А. М. Теория семантически значимых отображений // Вестник Томского государственного университета. Сер. Математика. Кибернетика. Информатика. 2003. № 280. С. 239-248.

Бабанов Алексей Михайлович, канд. техн. наук, доцент. E-mail: babanov2000@mail.ru

Томский государственный университет

Квач Елена Сергеевна. E-mail: kvachelena93@gmail.com

Томский государственный университет Поступила в редакцию 1 декабря 2015 г.

Babanov Alexey M., Kvach Elena S. (Tomsk State University, Russian Federation). «IS-THE»-relations in semantic data models: basic notions and variants.

Keywords: «IS-THE»-relation; «IS-THE»-cluster; «IS-THE»-categorization; semantic data model; ERM-model. DOI: 10.17223/19988605/34/8

«IS-A»-relations are important intellectual tools allowing to pass from the individual phenomena to their abstractions of the different levels and on the contrary. Importance of these relations in data modeling is underestimated. In fact, these relations in addition recover the unity of an object scattered in a database as unconnected abstract entities. In semantic model ERM (Entity-Relationship-Mapping) attempt of consistent «IS-A»-relation inclusion to rules of construction of structures and integrity constraints is undertaken. Main principle is maintenance of faultless logic canons with preservation of that functionality of these structures which has developed in data modeling.

There this natural for people form of the information representation has been offered not at once. In semantic models it has appeared together with the Enhanced Entity-Relationship Model in 80th years of the last century. In this model such structural concepts as specialization and categorization are entered for representation of «IS-A»-relations. But even in data modeling there is no common opinion about «IS-A»-structures so it is no wonder that these representations are different from logic bases.

The logician approach to the «IS-A»-relation problem looks more thorough, and it cannot be bypassed at the definition of the concepts describing these relations, but focused on data modeling. The second corner stone of this system of concepts are mappings and the

semantically significant mapping theory. The analysis of the mappings accompanying «IS-A»-relations allows to consider this subject of inquiry more deeply.

Two elements of scopes of the different concepts are connected by «IS-THE»-relation if and only if they represent the same application domain (AD) object. «IS-THE»-relation is the binary 1:1-relation determining pair of inverse functional «IS-THE»-mappings. AD objects or their abstractions (data) participate in these relation and mappings. If the known treatments of «IS-A»-relations connect a class with an object or a class with a class, «IS-THE»-relations connect objects.

«IS-THE»-relation in maximum generalized understanding allows specifying «nearness» of concepts in such sense: concepts are near if there is at least one object falling under both these concepts. «IS-THE»-relation in such variant determines two partial functional mappings.

If two concepts, one of which is generalization of another, are considered, then «IS-THE»-relation becomes a subsumption relation. «IS-THE»-mapping from scope of generic concept (superclass) to scope of specific concept (subclass) is still partial functional. And here, «IS-THE»-mapping from a subclass to a superclass becomes full functional.

«IS-THE»-cluster (or, simply, cluster) is a system of classes constructed for restrictions of the same superclass concept; such, that all subclass concepts use the same mapping in the bases of them subtyping. Such mapping can be named discriminating; in fact it is this characteristic of superclass objects that determines their hits in subclasses. When an entity set is a subclass only in one «IS-THE»-cluster, it is said that full single inheritance takes place. When an entity set enters as a subclass in more than one «IS-THE»-cluster, it is said that full multiple inheritance is carried out. In both cases entities of subclass inherit characteristics of all their parent classes.

In data modeling the special subspecies of two-level «IS-A»-hierarchies are entered. This is a categorization determining special «IS-THE»-relations between the union of superclass entity sets and subclass entity set (in this case named a category). To understand core of categorization it is necessary to present the content of the concept which scope is represented by subclass entity set. The first part of its logic expression is a disjunction of content conditions of superclass entity sets, and the second part is a condition to which should satisfy entities of these sets to be presented in a category. Such two-level «IS-A»-hierarchy we name «IS-THE»- categorization (or, simply, categorization).

In categorization definition it is emphasized that superclasses do not contain entities been abstractions of the same objects and are so various that they are not connected with the common ancestor. In other words, concepts of superclasses are incompatible in pairs. In that case the element of a category always inherits characteristics only one superclass, where the parental element connected to it contains. Therefore it is said that such two-level «IS-A»-hierarchies assume selective inheritance.

The definitions submitted in this article are based ERMM rules of data structurization and integrity constraint definition concerning representation of «IS-THE»- relations.

REFERENCES

1. Wang, P. (1994) From Inheritance Relation to Nonaxiomatic Logic. International Journal of Approximate Reasoning. 11. pp. 281-

319. DOI: 10.1016/0888-613X(94)90021-3

2. Palomaki, J. & Kangassalo, H. (2012) That IS-IN Isn't IS-A: A Further Analysis of Taxonomic Links in Conceptual Modelling. In:

Gutiérrez, C.R. (ed.) Advances in Knowledge Representation. Publisher: InTech. pp. 3-18. DOI: 10.5772/36484

3. Brachman, R.J. (1983) What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks. IEEE Computer. 16(10).

pp. 30-36. DOI: 10.1109/MC.1983.1654194

4. Connolly, T. & Begg, C. (2000) Bazy dannykh. Proektirovanie, realizatsiya i soprovozhdenie. Teoriya i praktika [Database Systems.

A Practical Approach to Design, Implementation, and Management]. Translated from English by R. Imamutdinova, K. Ptitsyn. 2nd ed. Moscow: Williams.

5. Teorey, T., Yang, D. & Fry, J. (1986) A Logical Design Methodology for Relational Databases Using the Extended Entity-Relationship Model. Computing Surveys. 18(2). pp. 197-222. DOI: 10.1145/7474.7475

6. Babanov, A.M. (2007) Semantic model "Entity - Relationship - Mapping". Vestnik Tomskogo gosudarstvennogo universiteta. Uprav-

lenie, vychislitel'naya tekhnika i informatika - Tomsk State University Journal of Control and Computer Science. 1(1). pp. 77-91. (In Russian).

7. Voyshvillo, E.K. & Degtyarev, M.G. (1994) Logika kak chast' teorii poznaniya i nauchnoy metodologii (fundamental'nyy kurs):

v 2 kn. [Logic as a part of the theory of knowledge and scientific methodology]. Moscow: Nauka.

8. Bacharov, VA. & Markin, V.I. (1998) Osnovy logiki [Foundation of logic]. Moscow: Infra-M.

9. Coronel Q, Morris S. & Rob, P. (2013) Database Systems: Design, Implementation, and Management. 10th ed. Course Technology.

10. Connolly, T. & Begg, C. (2010) Database Systems: A Practical Approach to Design, Implementation, and Management. 4th ed. Addison-Wesley.

11. Elmasri, R. & Navathe, S. (2010) Fundamentals of Database Systems. 6th ed. Addison-Wesley.

12. Halpin, T. & Morgan, T. (2008) Information Modeling and Relational Databases. 2nd ed. Morgan Kaufman.

13. Ferraggine, V., Doorn, J. & Rivero, L. (2009) Handbook of Research on Innovations in Database Technologies and Applications: Current and Future Trends. Information Science Reference.

14. Smith, J. & Smith, D. (1977) Database Abstractions: Aggregation and Generalization. ACM Transactions on Database Systems. 2(2). pp. 105-133. DOI: 10.1145/320544.320546

15. Babanov, A.M. (2003) Theory of semantically significant mapping. Vestnik Tomskogo gosudarstvennogo universiteta - Tomsk State University Journal. 280. pp. 239-248. (In Russian).

ВЕСТНИК ТОМСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА

2016 Управление, вычислительная техника и информатика № 1 (34)

УДК 004.021:004.738.2 DOI: 10.17223/19988605/34/9

Е.В. Царева

РАЗРЕШЕНИЕ КОНФЛИКТНЫХ СИТУАЦИЙ ПРИ СИНХРОНИЗАЦИИ МНОГОПОЛЬЗОВАТЕЛЬСКИХ ONLINE-ПРИЛОЖЕНИЙ

Приведено сравнение конфликтных ситуаций для задачи синхронизации многопользовательских online-приложений и других задач синхронизации. Предложены алгоритмы разрешения конфликтов на стороне клиента. Предлагается методика синхронизации приложений на основе указанных алгоритмов, в том числе способ программной реализации. Рассмотрена синхронизация flash-приложения «Мозговой штурм» в системе вебинаров Adobe Connect Meeting 9.

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

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

При организации сетей ЭВМ термин применяется на уровне передачи данных (сверка правильности доставленных данных), при синхронизации времени на узлах в сети ЭВМ. Синхронизацией называется приведение к одному виду большого объема данных, например в мобильных сетях, когда при подключении мобильной платформы в сеть происходит синхронизация измененных данных с удаленным сервером (отправка изображений на сервис хранения личной информации, обновление комментариев к новости и др.) [1]. Синхронизацией называется передача больших объемов данных по технологии Bit-Torrent [2].

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

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

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

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

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

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

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

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

Подобные функции также используются при передаче данных по сети на транспортном уровне (используются, например, протоколы TCP, UDP) [6]. Для исключения взаимной блокировки для чтения и отправки данных в системе выделяются отдельные потоки, которые при наступлении событий вызывают соответствующие функции-обработчики (слушатели) [7].

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

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

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

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

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

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

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

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

Синхронизируемые многопользовательские приложения можно подразделить на задачи совместного редактирования и онлайн-игры. Различия заключаются в том, что при совместном редактировании менее важны временные задержки, нет соперничества (т. е. необходимости справедливо отдать предпочтение одному из игроков в конфликтных ситуациях), пользователи редактируют одни и те же объекты, в то время как в играх обрабатываются их взаимодействия (столкновения, выстрелы и др.). Конфликтной ситуацией в онлайн-играх становится не одновременное использование ресурсов, а разное (в силу временных задержек) развитие сюжета в разных клиентских приложениях. Для разрешения подобных конфликтных ситуаций используется предсказывание движения игроков (например, на основе кубических сплайнов [11]), обман (когда приложение корректирует действия других игроков так, чтобы проигрыш пользователя выглядел реалистично), использование балластных действий на время ожидания отклика из сети, а также общее замедление игры [12]. Правила выбора наиболее правильного варианта могут быть такими же, как и при совместном использовании ресурсов: прав первый, прав последний, прав владелец объекта и, возможно, прав тот, в чьем приложении сложнее подделать реалистичную картину проигрыша.

В рассмотренной литературе концепция синхронизации многопользовательских приложений наиболее подробно рассматривается в публикациях, посвященных онлайн-играм, однако и в них не приводятся конкретные алгоритмические решения. Целью настоящей работы является предложение алгоритмов синхронизации событий многопользовательского приложения, предложение конкретных шагов по синхронизации произвольного онлайн-приложения, т. е. предложение методики синхронизации многопользовательских онлайн-приложений (в том числе формулируется алгоритм обработки поступающих событий в приложении клиента), а также применение методики на примере синхронизации flash-приложения «Мозговой штурм» в системе вебинаров Adobe Connect Meeting 9.

1. Алгоритмы разрешения конфликтов

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

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

Схема обработки сообщений в приложении приведена на рис. 1.

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

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

Если для события выделения объекта важно первое событие, то события блокировки и разблокировки можно не реализовывать, так как функции блокировки будут выполняться событиями выделения и сброса выделения. Если для события выделения важно последнее событие, то, поскольку выделить объект беспрепятственно может другой пользователь, события блокировки и разблокировки объекта на время редактирования объекта (например, движения) обязательны для реализации.

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

Рис. 1. Работа с событиями одного вида в приложении с учетом их очередности: а - важно первое событие; б - важно последнее событие. А - собственное событие клиента; А - аналогичное сообщение другого пользователя

Рис. 2. Обработка событий блокирования и разблокирования ресурса клиентом - сторонним наблюдателем: оЪ] - объект, над которым производится действие; оЪ).шегИ - идентификатор пользователя, который выбрал объект; оЪ^.Ыоск - индикатор блокировки объекта; аиШогИ - идентификатор автора события

Если объект заблокирован (событие блокировки было принято), запрет на его использование также действует внутри приложения.

На рис. 2 приведена последовательность обработки событий блокировки клиентом, который наблюдает происходящие события, на рис. 3 - клиентом, который является автором этих событий. На этих рисунках события блокировки и разблокировки не удалены для случая, когда для события выделения объекта важно первое событие. Наличие стрелки от Client_Interface к Client означает, что событие принимается, т. е. в приложении производятся необходимые изменения, в квадратных скобках указывается условие принятия события к исполнению, отсутствие стрелки означает отказ от выполнения события.

Рис. 3. Обработка событий блокирования и разблокирования ресурса клиентом - автором событий: о^^пШегИ - идентификатор пользователя клиентского приложения. На рисунке опущено возращение эха разблокировки

объекта и добавление собственных событий в эхо-очередь

2. Сообщения синхронизации

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

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

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

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

1) хранение всего состояния (всех параметров) или его части (подмножества параметров) приложения в последнем варианте;

2) хранение очереди всех поступивших изменений;

3) хранение последнего состояния для каждого вида сообщения и для каждого объекта (имя команды получается соединением названия команды и идентификатора объекта);

4) хранение очереди поступивших сообщений с регулярным сохранением состояния приложения в целом или его части.

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

Для примера приведем порядок синхронизации содержимого виртуальных досок в виртуальном мире vAcademia [13]. Все действия (типовые команды) пользователей сохраняются на сервере в виде бинарного массива. Бинарному массиву ставится в соответствие его последняя версия. Клиенты системы регулярно запрашивают номер последней версии, и если она изменилась, то запрашивают массив всех произведенных действий и перерисовывают содержимое виртуальной доски заново.

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

3. Методика синхронизации опИпе-приложений

Предлагаемая методика представляет последовательность шагов по синхронизации онлайн-приложения и предполагает наличие следующих позиций:

- отлаженный исходный код приложения;

- инструменты разработки приложения;

- инструменты разработки клиент-серверной архитектуры;

- работающее приложение сервера.

В функции серверного приложения должны входить следующие возможности:

- получение сообщений;

- отправление их участникам, включая автора сообщения;

- сохранение сообщений под указанным именем;

- отправление сохраненных сообщений вновь подключившимся участникам;

- обеспечение режима сохранения сообщения: очередь изменений либо последнее состояние.

Порядок синхронизации приложения включает следующие пункты:

- определение перечня событий, подлежащих синхронизации;

- для каждого события определяется режим синхронизации: важно первое или последнее сообщение либо блокировка (определяется событие выбора объекта);

- для каждого события разрабатывается состав полезного содержимого сообщения (не считая названия команды, идентификаторов автора и объекта);

- для каждого события определяются режим хранения на сервере (очередь изменений или последнее состояние), потребность в эхо-ответе;

- программная реализация;

- отладка и тестирование.

Синхронизируемые события могут подразделяться на следующие группы:

- создание или загрузка проекта;

- редактирование объектов;

- навигация (например, переход на стартовую страницу);

- организация (например, установка временного интервала синхронизации).

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

4. Программная реализация

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

- класс, отвечающий за связь с сервером (Netlnterface);

- класс-журнал, отвечающий за накопление событий для отправки, обработку конфликтных ситуаций, применение полученных сообщений (Journal);

- главный класс (MainClass) приложения для каждого синхронизируемого события, предоставляющий функцию, которая вызывается из внутренних частей кода приложения и отправляет событие в журнал для регистрации;

- классы синхронизируемых объектов (SyncObject), включающие в себя параметры userld и blocked, вызовы функций регистрации в журнале событий.

Netl interface

delay: integer

recelve(syncEvent) tlmeSendFuncQ

_1__

Journal

eclioCoinmands: array lastValuakileCoinmands:array etc...

cjitEverrtsQueueO: array receiveEvent(syncEvent) addEvent(lnsldeEvent)

Рис. 4. Внедрение разработанных алгоритмов в код приложения

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

1

Ь-

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

Для определения вида события в журнале используются списки названий команд:

- для которых необходимо эхо;

- для которых необходимо сохранение в виде очереди на сервере;

- события создания проекта;

- события, требующие идентичности автора (блокировка, разблокировка, редактирование, сброс выделения объекта);

- события, не связанные с предметной областью (установка интервала синхронизации, переход на стартовую страницу);

- события, для которых важно последнее событие.

Функция обработки полученного из сети события должна реализовывать следующий алгоритм:

1. Если ожидается эхо создания проекта:

1.1) если вернулось эхо любого события, удалить его из эхо-очереди;

1.2) иначе если пришло событие, не связанное с предметной областью, принять согласно пунктам

4 и 5.

2. Иначе если вернулось эхо (определить по идентификатору автора):

2.1) если речь идет о блокировке либо разблокировке и userld объекта равен идентификатору автора (т.е. собственному ownUserld), принять;

2.2) удалить из эхо-очереди.

3. Иначе если пришло событие, требующее идентичности автора:

3.1) если совпал идентификатор, принять.

4. Иначе если пришло событие, для которого важно последнее событие:

4.1) если в эхо-очереди нет подобного события, принять;

4.1.1) если это событие выбора и в эхо-очереди для выбранного объекта ожидается эхо блокировки, отменить редактирование объекта.

5. Иначе если пришло событие, для которого важно первое событие:

5.1) если в эхо-очереди есть подобное событие, отменить его;

5.2) если событие не произошло (было отменено), принять событие.

Пункты следует выполнять в указанном порядке. На первом шаге важно отклонить и не обработать сообщения, которые относятся к предыдущему проекту. На втором шаге важно не обработать собственные сообщения так же, как сообщения других пользователей. Если событие требует идентичности автора, оно не заносится в список событий, для которых важно последнее событие, т. е. на шагах 4 и 5 будет распознано программой как событие, для которого важно первое событие, и должно быть обработано только на 3-м шаге. Последние два пункта можно поменять местами. Другая организация проверки типов событий может привести к росту числа операторов сравнения и усложнить процесс разработки приложения.

В журнале также должны быть определены функции, которые могут менять состояние приложения, т.е. могут «принять» событие, и другие вспомогательные параметры и функции.

5. Синхронизация flash-приложения в Adobe Connect Meeting 9

Система вебинаров Adobe Connect Meeting 9 предназначена для проведения виртуальных совещаний и, в частности, позволяет загрузку синхронизированных flash-приложений для совместного использования. Для синхронизации приложения предоставляется инструмент разработки Collaboration Builder Toolkit SDK, доступный в среде разработки Flash Builder (ранее Flex) при использовании инструмента разработки SDK 3.6. Инструмент Collaboration Builder Toolkit SDK предоставляет разные возможности, в том числе функцию отправки сообщений серверу с параметрами: название команды; содержимое сообщения; параметры, названные «дельта» (следует ли сохранять очередь поступающих сообщений или

сохранять последнее сообщение) и «эхо» (следует ли возвратить эхо сообщения). Роль сервера здесь играет сама система Adobe Connect Meeting.

Приложение также может быть разработано в среде разработки Flash Professional и экспортировано в Flash Builder при помощи инструмента Flex Component Kit, так что в Flash Builder разрабатывается код (flex-оболочка), ответственный за связь с сервером, в то время как основное приложение (далее назовем его flash-частью) должно предоставлять необходимый интерфейс для обмена информацией и включает в себя основной функционал приложения (рис. 5).

Рис. 5. Схема разработки flash-приложения, синхронизированного в системе вебинаров Adobe Connect Meeting, "swc" и "swf" - расширения выходных продуктов (файлов)

Указанная схема была применена для разработки flash-приложения «Мозговой штурм» [14]. Приложение позволяет совместно построить дерево суждений, состоящее из вершин, соединенных прямыми линиями. Каждой вершине можно назначить текст, размер, цвет и толщину обводки вершины, цвет и толщину линии к родительской вершине. Вершины можно произвольно перемещать. Вершина выделяется желтым цветом, если она выбрана самим пользователем, и красным, если она выбрана другим участником виртуального собрания (рис. 6).

Рис. 6. Программа «Мозговой Штурм» в окне вебинара Adobe Connect Meeting 9; на рабочем поле отображены 14 используемых для синхронизации приложения событий

Очередь сообщений накапливается во 1^^части приложения в ходе работы пользователя. Flex-оболочка извлекает эту очередь и отправляет серверу каждый интервал синхронизации. Событие сохра-

нения полной версии проекта (reserve) создается пользователем с наименьшим идентификатором каждые 100 интервалов синхронизации и отправляется серверу вместе с сообщениями об обнулении всех остальных событий.

Во flash-части приложения синхронизируются следующие 13 видов событий: start (переход на стартовую страницу), new (создать проект), load (загрузить проект), delay (установить интервал синхронизации), allow (разрешить участникам редактировать проект), select (выбрать вершину), param (установить параметры вершины), move (движение вершины), add (добавление вершины), delete (удаление вершины), reject (сброс выделения вершины), block (заблокировать вершину), unblock (разблокировать вершину).

События по своим характеристикам распределены следующим образом:

- не ожидающие эха: move, delete, reject;

- не хранящиеся на сервере в виде очереди: start, new, load, delay, allow;

- не относящиеся к предметной области: start, delay, allow;

- события создания проекта: new, load;

- важно последнее событие: select, param, start, delay, allow, new, load;

- важна идентичность автора: block, move, unblock, reject.

Приложение «Мозговой штурм» опубликовано в сети Интернет, с ним можно ознакомиться по адресу [15].

Заключение

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

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

Разработанная методика в итоге была применена для синхронизации flash-приложения «Мозговой штурм» в системе вебинаров (т.е. виртуальных совещаний) Adobe Connect Meeting 9, предназначенного для совместного редактирования логического дерева.

ЛИТЕРАТУРА

1. Демиш В.О., Пищик Б.Н. Синхронизация данных на мобильных платформах // Вестник Новосибирского государственного

университета. Сер. Информационные технологии. 2013. Т. 11, № 4. С. 46-58.

2. Макаревич А. С. Механизм защищенной синхронизации данных на базе протокола BitTorrent в распределенной вычисли-

тельной среде // Электронные средства и системы управления. 2007. № 2. С. 63-65.

3. Баранов Д.Е., Давыденко В.А., Цупранков А.В., Янишевская А.Г., Василевский В.Б., Соседко В.В. Разработка программного

приложения для синхронизации базы данных справочника материалов и сортаментов // Инженерный вестник Дона. 2013.

Т. 25, № 2 (25). С. 55.

4. Allen B. Downey The little book of semaphores. URL: http://greenteapress.com/semaphores/downey08semaphores.pdf (access date:

22.10.15).

5. Gropp W. Tutorial on MPI: The message-passing interface. URL: http://www.mcs.anl.gov/research/projects/ mpi/tutorial/gropp/talk.html (access date: 05.11.15).

6. Сетевое программирование в ОС UNIX. URL: http://www.opennet.ru/docs/RUS/tcpip/netprg0.html (access date: 05.11.15).

7. Семёнов Д.Е. Использование протоколов и их синхронизация для обмена данными в клиент-серверных приложениях // Со-

временные техника и технологии : 13-я Междунар. науч.-практическая конференция студентов, аспирантов и молодых ученых, г. Томск, 26-30 марта 2007 г. : в 3 т. / Томский политехнический университет. Томск, 2007. Т. 2. С. 428-430.

8. Демидов А. А. Топологические методы в проектировании системы синхронизации конкурирующих транзакций распределен-

ной базы данных // Программные системы: теория и приложения. 2011. Т. 2, № 4. С. 139-152.

9. Плутенко А. Д., Ситников А. А. Проблемы имитационного моделирования процесса журнальной репликации данных в рас-

пределенных СУБД // Информатика и системы управления. 2005. № 1. С. 3-15.

10. Демидов А.А. Об особенностях организации СУБД в MPP-системе. URL: http://psta.psiras.ru/read/psta2014_4_195-205.pdf (дата обращения: 22.10.15).

11. Калдвел Н. Устранение эффекта запаздывания с использованием кубических сплайнов. URL: http://www.gamedev.ru/code/articles/?id=4257 (дата обращения: 22.10.15).

12. Карпов А. Как создать онлайн-игру. URL: http://www.ant-karlov.ru/kak-sozdat-mnogopolzovatelskuu-igru-anons.html (дата обращения: 22.10.15).

13. Сморкалов А.Ю. Реализация инструмента графического комментирования на виртуальной доске на графических потоковых процессорах // Образовательные технологии и общество. 2012. Т. 15, № 4. С. 444-456.

14. Царева Е.В. Использование flash-технологий для расширения функциональности LMS Moodle и системы вебинаров Adobe Connect Meeting // Высшее образование сегодня. 2014. № 8. С. 30-33.

15. Мозговой штурм. URL: http://flash_services.lcg.tpu.ru/brain_storm/index.html (дата обращения: 22.10.15).

Царева Елена Владимировна. E-mail: tsareva@tpu.ru Томский политехнический университет

Поступила в редакцию 21 августа 2015 г.

Tsareva Elena V. (Tomsk Polytechnic University, Russian Federation). Resolution of conflicts during synchronization multiplayer online-application.

Keywords: synchronization; multiplayer application; access conflict; locking; collaborative use.

DOI: 10.17223/19988605/34/9

In information technology synchronization problem is quite urgent: the synchronization required when providing multi-tasking operating systems, in parallel and multi-threaded programming, with multi-user database. Besides synchronization process there is also the problem of synchronization of data, i.e. bringing copies of large amounts of data to one version, for example, use of cloud services, update mirroring servers or remote databases. Data synchronization can occur singly or in real time, for example, in the distributed databases and the multi-user online applications.

Task of synchronization of multiplayer online applications is different from other similar tasks. Its features are a critical time delays, reject all but one of the conflicting requests, the execution of their own actions (or cancellation of incoming events) in the application before return of a special response from the server, optionally (but preferably) lock objects on the editing, the possibility of conflict of different user selection rules for related events.

Multi-user applications can be divided into online games and applications of collaborative editing. Multiplayer games differ from collaborative editing systems by the presence of competition, conflicts arise there not only due to simultaneous access, but also different (due to time delays) developments in various client applications of system.

For conflict resolution two selection rules can be used, they based on the time sequence of receipt requests: select the first or the last user. For the authors of events the sequence is determined by the returned from the server echo events: before the return of the echo received events are considered as events occurred before, and after returning of the echo - as events occurred later. Similar conclusions are qualified because used data transfer protocols provides a unified order for receipt of messages to all customers.

For conflict resolution is also used the lock of the editing object. Selecting an object certainly precedes block event (and then edit event), for which there is determined the choice rule (first or last user). Lock, unlock, edit and deselection are only available to the user that has selected an object. Locked element is also not available for the new events of editing.

These rules are implemented in the proposed algorithms. For a system with a client-server architecture, in which events are processed on the client side, messages are sent to the server each time interval, the server provides the storage of messages, and the application implements the events editing objects, there is developed methodology of synchronizing of multi-user online applications. As part of this methodology there are proposed to list all the synchronized events, to define a policy for them for resolving the conflicts, to develop content and order of storage on the server.

For a software implementation in the application code there are proposed to add a class of network interface responsible for connection to the server, the class journal in which application events are recorded, and where network events are

processed. The main class must provide the registration function of the events in the journal. In classes of used objects there are offered to add a variable that stores the user ID, flag of the object lock, function calls of event logging, which is determined in the main class. The paper also presents the algorithm for processing of incoming messages to the client application designed for journal class.

The developed methodology was eventually used to synchronize the flash-application "Brainstorm" in the webinars (i.e., virtual meetings) Adobe Connect Meeting 9. The application allows you to build logic tree together, to determine the color, stroke width, and other parameters of vertices and connecting them lines, specify the text labels to the tops. There are 14 kinds of events that synchronized in application, including removing and adding vertices, changing settings and vertices moving, loading the project, the interval timing, and other events.

REFERENCES

1. Demish, V.O. & Pishchik, B.N. (2013) Data synchronization on mobile platforms. Vestnik Novosibirskogo gosudarstvennogo univer-

siteta. Ser. Informatsionnye tekhnologii - Novosibirsk State University Journal of Information Technologies. 11(4). pp. 46-58. (In Russian).

2. Makarevich, A.S. (2007) Mekhanizm zashchishchennoy sinkhronizatsii dannykh na baze protokola BitTorrent v raspredelennoy

vychislitel'noy srede [A mechanism for protected data synchronization based on BITTORRENT protocol in the distributed computer network]. Elektronnye sredstva i sistemy upravleniya. 2. pp. 63-65.

3. Baranov, D.E., Davydenko, V.A., Tsuprankov, A.V., Yanishevskaya, A.G., Vasilevskiy, V.B. & Sosedko, V.V. (2013) Development

of software applications for database synchronization reference of materials and assortments. Inzhenernyy vestnik Dona - Engineering Journal of Don. 2(25). pp. 55.

4. Downey, A.B. (n.d.) The little book of semaphores. [Online] Available from: http://greenteapress.com/semaphores/ downey08semaphores.pdf. (Accessed: 22nd October 2015).

5. Gropp, W. (n.d.) Tutorial on MPI: The message-passing interface. [Online] Available from: http://www.mcs.anl.gov/research/pro-jects/mpi/tutorial/gropp/talk.html. (Accessed: 5th November 2015).

6. Fedoruk, V.G. (n.d.) Setevoe programmirovanie v OS UNIX [Network Programming in the OS UNIX]. [Online] Available from:

http://www.opennet.ru/docs/RUS/tcpip/netprg0.html. (Accessed: 5th November 2015).

7. Semenov, D.E. (2007) [Using the protocols and timing for exchanging data in a client-server applications]. Sovremennye tekhnika i

tekhnologii [Modern technique and technologies]. The 13th International Scientific Conference of Students, Postgraduates and Young Scientists. Tomks. 26 to 30 March, 2007. Vol. 2. Tomsk: Tomsk Polytechnic University. pp. 428-430.

8. Demidov, A.A. (2011) Topologicheskie metody v proektirovanii sistemy sinkhronizatsii konkuriruyushchikh tranzaktsiy raspredelen-

noy bazy dannykh [Topological methods in the synchronization system design for concurrent transactions in distributed databases]. Programmnye sistemy: teoriya i prilozheniya. 2(4). pp. 139-152.

9. Plutenko, A.D. & Sitnikov, A.A. (2005) Problemy imitatsionnogo modelirovaniya protsessa zhurnal'noy replikatsii dannykh v ras-

predelennykh SUBD [Problems of simulation of magazine data replication in distributed database]. Informatika i sistemy upravleniya. 1. pp. 3-15.

10. Demidov, A.A. (n.d.) Ob osobennostyakh organizatsii SUBD v MPP-sisteme [About the peculiarities of the organization database in the MRP-system]. [Online] Available from: http://psta.psiras.ru/read/psta2014_4_195-205.pdf. (Accessed: 22nd October 2015).

11. Caldwell, N. (2002) Ustranenie effekta zapazdyvaniya s ispol'zovaniem kubicheskikh splaynov [Defeating lag with cubic splines]. [Online] Available from: http://www.gamedev.ru/code/articles/?id=4257. (Accessed: 22nd October 2015).

12. Karpov, A. (n.d.) Kak sozdat' onlayn-igru [How to design an online game]. [Online] Available from: http://www.ant-karlov.ru/kak-sozdat-mnogopolzovatelskuu-igru-anons.html. (Accessed: 22nd October 2015).

13. Smorkalov, A.Yu. (2012) Realizatsiya instrumenta graficheskogo kommentirovaniya na virtual'noy doske na graficheskikh potokovykh protsessorakh [Tool implementation for graphic commenting on the virtual board on graphic stream processor]. Obra-zovatel'nye tekhnologii i obshchestvo. 15(4). pp. 444-456.

14. Tsareva, E.V. (2014) The use of flash-technology for extension of LMS Moodle and webinar system Adobe Connect Meeting. Vysshee obrazovanie segodnya - The Higher Education Today. 8. pp. 30-33. (In Russian).

15. Tomsk Polytechnic University. (n.d.) Mozgovoy shturm [Brain Storm]. [Online] Available from: http://flash_services.lcg.tpu.ru/brain_storm/index.html. (Accessed: 22nd October 2015).