КОНСТРУИРОВАНИЕ КАНОНИЧЕСКИХ …synthesis.ipi.ac.ru › synthesis ›...

éîæïòíáôéëá é å¿ ðòéíåîåîéñ, 2007. ô. 1. ÷ÙÐ. 2. ó. 15�38

КОНСТРУИРОВАНИЕ КАНОНИЧЕСКИХ ИНФОРМАЦИОННЫХ

МОДЕЛЕЙ ДЛЯ ИНТЕГРИРОВАННЫХ ИНФОРМАЦИОННЫХ

СИСТЕМ∗

В. Н. Захаров1, Л. А. Калиниченко2, И. А. Соколов3, С. А. Ступников4

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

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

1 Введение

Статья посвящена изучению, трансформациии унификации моделей представления информа-ции в процессе проектирования и разработки инте-грированных, интероперабельных информацион-ных систем. Это важная проблема информатикикак науки, изучающей естественные и искусствен-ные информационные процессы. С нарастающейинтенсивностью информатику рассматривают какестественную науку [1] (наряду с другими есте-ственными науками), а не как науку, изучающуюлишь сущности, искусственно созданные челове-ком. Информационные процессы являются частьюприродных явлений: примеры таковых общеизвест-ны в молекулярной биологии, квантовой физике, вэкономике, в социальных процессах и пр. Инфор-матика, таким образом, изучает как естественные,так и искусственные информационные процессы.Понимаемая широко (как computing [2]), инфор-матика включает вычислительную науку (computerscience), компьютерную инженерию и инженериюпрограмм, информационные технологии (ИТ),информационную науку (information science),инженерию информационных систем. Трактовкаинформатики как естественной науки приводит к

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

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

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

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

∗Работа выполнена при финансовой поддержке РФФИ (проект 06-07-08072-офи-а) и программы ОИТВС РАН «Фундаменталь-ные основы информационных технологий и систем» (проект 1-10).

1Институт проблем информатики Российской академии наук, [email protected]Институт проблем информатики Российской академии наук, [email protected]Институт проблем информатики Российской академии наук, [email protected]Институт проблем информатики Российской академии наук, [email protected]

15

В. Н. Захаров, Л. А. Калиниченко, И. А. Соколов, С. А. Ступников

ния информации, представляемой в той илииной информационной модели.

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

Известно (разработано) большое число моделейпредставления информации как природных, так иискусственно созданных. Природные информаци-онные модели для изучения преобразуются в ис-кусственные модели, реализуемые на компьютере.Поэтому в дальнейшем статья будет сосредоточенана искусственных моделях (соответствие естествен-ных моделей искусственным можно проследить напримере биологических моделей [4, 3], астроно-мических моделей [6, 5] и др.; существенно, чтоодной природной модели, как правило, соответ-ствует значительное число искусственных моделей,с той или иной степенью подробности отражающихее семантику). Следует оговориться, что под ин-формационными моделями понимаются языки дляописания структуры информации, ее семантики, атакже операций, определяющих характерные пре-образования информации в такой модели. МодельДНК служит примером подобного языка в молеку-лярной биологии. Он позволяет описывать общиегенетические модели, представления конкретныхструктур (генов) и содержит специальные опера-ции трансформации таких структур. Отображе-ния модели ДНК в разнообразные искусственныекомпьютерные информационные модели активноизучались, например, в [4].

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

подобным процессом создания информационныхмоделей. Это развитие происходит как в рам-ках конкретных инфраструктур (таких как архи-тектуры OMG, в частности архитектура CORBA,архитектуры, движимые моделями представленияинформации (MDA), архитектуры семантическогоВеба, сервис-ориентированные архитектуры, архи-тектуры электронных библиотек, архитектуры ин-формационных грид систем), так и в стандартахконкретных информационных моделей — моделейданных (таких как, например, ODMG 2000, SQL2003, UML, стеки XML и RDF моделей данных),моделей потоков работ (например, Staffware, COSA,InConcert, Eastman, FLOWer, Domino, Meteor, Mo-bile, MQSeries, Forte, Verve, Vis. WF, Changeng, IFlow,SAP/R3), языков процессной композиции сервисов(XPDL, BPEL4WS, BPML, XLANG, WSFL, WSCI),семантических моделей (включая онтологическиемодели и модели метаданных), моделей цифро-вых репозиториев данных и знаний в конкретныхобластях бизнеса, торговли, науки и многих дру-гих. Основу названных моделей составляют раз-нообразные понятия и парадигмы, не совместимыемежду собой. Этот процесс сопровождается дру-гой тенденцией — накоплением использующих по-добные модели информационных ресурсов, числокоторых экспоненциально растет. Такой рост вызы-вает все увеличивающуюся потребность совместно-го использования (интеграции) модельно неодно-родных информационных компонентов и сервисовв различных применениях, а также их повторно-го использования и композиции для реализацииинтероперабельных информационных систем [7].Указанные тенденции противоречивы: чем большеразнообразие применяемых моделей в различныхресурсах, тем более сложными становятся пробле-мы их интеграции и композиции. Эти тенденции неновы, но с течением времени разнообразие моде-лей (величина «Вавилонской башни» моделей) и ихсложность растут вместе с ростом потребности до-стижения интеграции и композиции разномодель-ных компонентов и сервисов при решении задач.Предел возможности интеграции и композиции ре-сурсов близок к достижению: уже сейчас зачастуюпроще создать новый ресурс, чем найти и правиль-но применить существующий.

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

16 ИНФОРМАТИКА И ЕЁ ПРИМЕНЕНИЯ том 1 выпуск 2 2007

Конструирование канонических информационных моделей для интегрированных информационных систем

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

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

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

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

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

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

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

На протяжении длительного периода временив лаборатории композиционных методов проек-тирования информационных систем ИПИ РАНразрабатывались методы синтеза каноническихмоделей для широкого спектра реальных информа-ционных моделей: структурированных, объектных,сервисных, процессных, включая произвольные ихкомбинации [9–20]. При этом рассматриваются

ИНФОРМАТИКА И ЕЁ ПРИМЕНЕНИЯ том 1 выпуск 2 2007 17


полные спецификации моделей (языков), включаясредства описания как информационных струк-тур (типов данных), так и поведения (операций,функций и процессов) [14, 15, 21].

При преобразовании структурированных, сла-боструктурированных и объектных моделей вканоническую разработанные методы сохраняютинформацию и операции в соответствии с прин-ципом уточнения [21]. Отображение процессов присинтезе их канонической модели требует сохране-ния семантики одновременного поведения (con-currency). В 2004 г. авторы, используя недавнообнаруженную возможность интерпретации про-цессных событий в формальных методах специфи-кации [22–25], создали метод конструирования до-казательных уточнений процессных спецификацийи синтезировали расширяемую каноническую про-цессную модель для широкого класса процессныхмоделей (сотни таких моделей используются в миретолько в различных коммерческих системах управ-ления потоками работ), языков процессной ком-позиции веб-сервисов [26]. Этот результат завер-шил многолетние исследования и позволил достичьсовмещения двух практически важных требова-ний — полноты охвата канонической моделью се-мантики разнообразных требующихся на практикемоделей представления информации с доказатель-ностью правильности представления в расширяе-мой канонической модели разнообразных практи-чески используемых моделей. Эти результаты былиопубликованы в [15]. Таким образом, решениемногих актуальных практических задач стало болееобоснованным (например, конструирование вирту-альных организаций, трейдинг процессов или сер-висов).

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

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

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

2 Метод конструированияунифицирующихинформационных моделей

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

информационной метамоделью.Понятие уточнения моделей данных определяет-

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

Схема системы Ss уточняет схему St, если итолько если для каждого типа ts в Ss есть тип tt в St

(и St не содержит других типов) такой, что ts явля-ется уточнением tt. Модель данных Ms уточняет

1Исходная информационная модель Ms эквивалентна целевой информационной модели Mt, если Mt уточняется Ms и Ms

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



модель данных Mt, если и только если для каждойдопустимой схемы Ss в Ms существует допустимаясхема St в Mt такая, что Ss является уточнени-ем St.

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

Принцип расширения информационных моделей дан-

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

Принцип коммутативного отображения информаци-

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

Множество всех схем систем, которые могутбыть выражены на языке определения информа-ции модели Mi, обозначается Si. Множество спе-цификаций абстрактной метамодели, прообра-зами которых при семантическом отображенииявляются схемы из Si, обозначается Bi. ОбозначимMsi : Si → Bi семантическую функцию модели Mi.Отображение f = 〈σ, θ〉 модели Mj в расширениеMij модели Mi коммутативно, если выполняютсяследующие условия:

– диаграмма отображения схем языков определе-ния информации является коммутативной:

-6 6

-

Si × {Ÿij}Msij Bij

σ θ

Sj

MsjBj

– отображение θ является уточнением.

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

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

определения. Это позволяет в данном рассмотре-нии ограничиться только диаграммой отображениясхем.

Принцип синтеза унифицирующей канонической ин-

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

2.1 Абстрактная информационнаяметамодель

В настоящей работе в качестве абстрактной ин-формационной метамодели используется Нотацияабстрактных машин (Abstract Machine Notation,AMN). Язык AMN обеспечивает манипулирова-ние теоретико-множественными спецификация-ми в логике первого порядка и доказательствоуточнения спецификаций [27–29]. Специальныеинструментальные средства (B-технология [27])предоставляют возможность доказательства ком-мутативности диаграмм отображения моделей по-луавтоматическим способом: теоремы, требуемыедля доказательства уточнения моделей, генериру-ются средствами B-технологии автоматически, ноих доказательство может быть интерактивным.

Язык AMN как теоретико-модельная нотацияпозволяет рассматривать состояния и операциисистемы интегрированно как спецификацию про-странства состояний и поведения (определенногооперациями на состояниях) абстрактных машин.Спецификация состояния абстрактной машинывводится переменными состояния вместе с инва-риантами — ограничениями, которые должны все-гда удовлетворяться. Операции определяются наоснове расширения формализма охраняемых ко-манд Дейкстры. Ключевым понятием AMN явля-ется уточнение, позволяющее соотносить специ-фикации систем различных уровней абстракции.Уточняющая спецификация может быть значитель-но более детальной, чем уточняемая специфика-ция. Конструируется уточняющая спецификацияна основе алгоритмического уточнения и уточне-ния данных [28]. Уточнение формализуется в AMNпутем формулировки ряда теорем специального ви-да, так называемых proof obligations. Такие теоремы



формулируются автоматически при помощи ин-струментальных средств поддержки В-технологии(B-Toolkit [30], AntelierB [31]) на основании склеи-

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

2.2 Спецификация операций в AMN

Операции абстрактных машин основаны наобобщенных подстановках. Любая операция вAMN имеет следующий вид

r1, . . . , rn ← op(p1, . . . , pm) = S .

Здесь op — имя операции, r1, . . . , rn — выходныепараметры операции, p1, . . . , pm — входные пара-метры операции, S — подстановка, определяющаядействие операции на пространстве состояний.

Язык обобщенных подстановок (GeneralizedSubstitution Language, GSL) позволяет описыватьпереходы между состояниями системы. Каждаяобобщенная подстановка S определяет преобразо-ватель предиката, связывающий некоторое пост-условие R со своим слабейшим предусловием [S]R,что гарантирует сохранение R после выполненияоперации. В этом случае говорят, что S уста-

навливает R. «Слабейшее» предусловие означает,что предикат «начального состояния», связанный снекоторым предикатом «заключительного состоя-ния», должен разрешать максимально большое чис-ло состояний. В табл. 1 рассматриваются основныевиды обобщенных подстановок и соответствующиеим слабейшие предусловия. Здесь S, T, T1, T2 озна-чают подстановки; x, y, t — переменные; E, F — вы-ражения; G, G1, G2, P — предикаты; P{x→ E} —предикат P , в котором все свободные вхожденияпеременной x заменены нa E.

Таблица 1 Обобщенные подстановки и их семантика

Обобщенная подстановка S [S]P

x := E P{x→ E}

skip P

x := E||y := F [x, y := E, F ]P

S[]T [S]P ∧ [T ]P

SELECT G1 THEN T1 (G1 ⇒ [T1]P )∧WHEN G2 THEN T2 END (G2 ⇒ [T2]P )

PRE G THEN T END G ∧ [T ]P

ANY t WHERE G THEN T END ∀t • (G⇒ [T ]P )

S ;T [S][T ]P

IF G THEN S ELSE T END (G⇒ [S]P )∧(¬G⇒ [T ]P )

2.3 Виды конструкций и структурныемеханизмы AMN

В AMN существует три вида конструкций:

(1) абстрактная машина (abstract machine);

(2) уточнение (refinement);

(3) реализация (implementation).

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

Уточнение выглядит следующим образом.

REFINEMENT r

REFINES m

SEES sm

INCLUDES im

SETS s

CONSTANTS c

PROPERTIES P (s, c)

VARIABLES x

INVARIANT I(x)

INITIALISATION S

OPERATIONS O1; . . . ;On

END

Уточнение с именем r содержит переменные вразделе VARIABLES, которые и определяют состо-яние системы. Начальная инициализация пере-менных определяется подстановкой, определеннойв разделе INITIALISATION. Изменять состояниесистемы могут только операции, определенные вразделе OPERATIONS. Состояние системы должноудовлетворять инварианту после инициализации;операции также должны сохранять инвариант. Раз-дел SETS содержит определение множеств, разделCONSTANTS содержит имена констант, использу-ющихся в уточнении, раздел PROPERTIES содер-жит предикат, описывающий свойства констант.



Имя конструкции, которую уточняет r, содержитсяв разделе REFINES.

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

2.4 Формализация понятия уточненияв AMN

Рассмотрим, каким образом формализуетсяфакт уточнения конструкции M конструкцией N

в AMN. Заметим, что факт уточнения может бытьустановлен только в том случае, если конструкцииM и N (табл. 2) согласованы, т. е. удовлетворяютследующим требованиям.

– раздел REFINES конструкции N должен содер-жать имя M ;

– для каждой операции конструкции M кон-струкция N должна содержать операцию с точ-но такой же сигнатурой;

– инвариант конструкции N должен содержатьтак называемый склеивающий инвариант (ин-вариант уточнения) R, задающий соотношениемежду состояниями уточняемой и уточняющейконструкций.

Таблица 2 Спецификации M и N

REFINEMENT M REFINEMENT N

REFINES K REFINES M

CONSTANTS cM CONSTANTS cN

PROPERTIES PM PROPERTIES PN

VARIABLES v VARIABLES w

INVARIANT IM INVARIANT IN

INITIALISATION InitM INITIALISATION InitN

OPERATIONS OPERATIONSy ← op(x) = y ← op(x) =

PRE Preop,M PRE Preop,N

THEN THENDefop,M Defop,N

END END. . . . . .

END END

Определение 1. N уточняет M , если верны следующие

теоремы (proof obligations):

– Теорема непустоты объединенного состояния.

Существует объединенное состояние M и N ,

удовлетворяющее инвариантам M и N :

PM ∧ PN ⇒ ∃(v, w) • (IM ∧ IN ).

– Теорема уточнения инициализации. Инициализа-

ция N уточняет инициализацию M :

PM ∧ PN ⇒ [InitN ]¬[InitM ]¬IN .

– Теорема уточнения операций. Каждая из опе-

раций N уточняет соответствующую опера-

цию M , т. е. при условии выполнения инварианта

уточнения и предусловия уточняемой операции,

выполняется предусловие уточняющей операции;

и для каждого случая исполнения Defop,N су-

ществует исполнение Defop,M из соответству-

ющего начального состояния (задаваемого инва-

риантом уточнения R), которое устанавливает

точно такие же значения выходных параметров

и сохраняет инвариант уточнения на постсосто-

яниях:

PM ∧ PN ∧ IM ∧ IN ∧ Preop,M ⇒Preop,N ∧[Defop,N{y → y′}]¬[Defop,M ]¬(IN ∧ y′ = y).

В целом, для верификации отображения инфор-мационной модели Mj в расширение Mi требуетсяопределить AMN-семантику Mj и AMN-семантикурасширенной Mi. После этого применяется B-тех-нология, чтобы доказать коммутативность отобра-жения моделей. Это ведет к доказательству то-го, что Mj является уточнением расширения Mi.Важно, что отображение информационных моде-лей, основанное на AMN и на технике уточнения,применимо как к структурированным, объектным,онтологическим, так и сервисным и процессныммоделям.

3 Архитектура средствконструированияунифицирующихинформационных моделей

Целью Унификатора моделей является унифи-кация множества информационных моделей (на-зываемых исходными), совместно использующихсяв некоторой И-системе. Унификация исходной



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

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

– ядро канонической информационной модели;

– формализм, позволяющий описывать синтак-сис информационных моделей и специфици-ровать трансляторы из одной модели в другую;

– формализм, поддерживающий верификациюуточнения.

В качестве ядра канонической информацион-ной модели в настоящей работе рассматриваетсяязык СИНТЕЗ [32], ориентированный на семан-тическую интероперабельность и композиционноепроектирование информационных систем в широ-ком диапазоне существующих неоднородных ин-формационных компонентов.

Для формального описания синтаксиса и транс-ляторов моделей используются языки метаком-пиляции SDF (Syntax Definition Formalism) иASF (Algebraic Specification Formalism), обес-печенные инструментальной поддержкой Meta-Environment [33].

Для формализации семантики информацион-ных моделей и верификации уточнения исполь-зуется язык спецификаций AMN, основанный налогике предикатов первого порядка и теории мно-жеств и поддержанный технологией и инструмен-тальными средствами доказательства уточнения(В-технология [27]).

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

1. Формализация синтаксиса и семантики моде-ли R.

2. Интеграция эталонных схем модели R и кано-нической информационной модели.

3. Создание необходимого расширения E кано-нической модели C.

4. Построение отображения модели R в расши-ренную каноническую модель.

5. Верификация уточнения моделью R расширен-ной канонической модели.

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

Рассмотрим более подробно указанные этапы.

1. Формализация синтаксиса и семантики исходной

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

(a) Определение синтаксиса трансформируетсяэкспертом в язык SDF, и это новое опре-деление считается формальным описаниемсинтаксиса.

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

2. Интеграция эталонных схем исходной и канони-

ческой моделей.

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

Целью интеграции эталонных схем является вы-деление релевантных конструкций исходной иканонической моделей. Входными данными эта-па являются SDF-синтаксис исходной модели иее вербальная семантика.

(a) Автоматически выполняется построение за-готовки эталонной схемы исходной модели



на основе ее формального синтаксиса. Заго-

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

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

(c) На основе вербальных определений автома-тически порождаются векторы дескрипторовэлементов эталонной схемы, с использова-нием векторной модели производится поискэлементов эталонной схемы каноническоймодели, близких к элементам эталонной схе-мы исходной модели (эталонная схема кано-нической модели при этом предполагаетсяпостроенной). Эксперт подтверждает либоотвергает найденные соответствия, а такжедобавляет соответствия, не найденные авто-матически. Результатом интеграции явля-ется список соответствий конструкций ис-ходной и канонической моделей. Однойконструкции канонической модели можетсоответствовать несколько конструкций ис-ходной модели (и наоборот).

3. Создание расширения канонической модели. К не-обходимости создания расширения эксперт при-ходит в процессе интеграции эталонных схемисходной и канонической моделей: обнаружи-вается, что средств ядра (или ядра с уже постро-енными расширениями) канонической моделинедостаточно для выражения некоторых кон-струкций исходной модели. К этому выводуэксперт приходит, если:

– между конструкциями исходной модели иконструкциями канонической модели алго-ритмы интеграции не установили связей;

– на основе анализа документов, описыва-ющих синтаксис и семантику исходной иканонической модели сделано экспертноезаключение о невыразимости конструкцийисходной модели в канонической.

При создании расширения для каноническоймодели предполагаются определенными:

– документы, описывающие синтаксис и се-мантику;

– формальный SDF-синтаксис;

– AMN-семантика (т. е. вербальные правила иинструментальные средства отображения вязык AMN);

– онтологическое описание.

Для исходной модели необходимо обеспечить:

– документы, описывающие синтаксис и се-мантику;

– формальный SDF-синтаксис;

– AMN-семантику;

– эталонную схему модели;

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

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

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

(a) Создание расширения эксперт начинает сопределения названия расширения и расши-ряемой версии канонической модели (т. е.выбирает расширяемую версию из списка).

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

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

(d) Далее уточняется картина интеграции эта-лонных схем исходной модели и расширен-ной канонической модели: устанавливаютсяи фиксируются соответствия между кон-струкциями исходной модели и конструк-циями расширения.



4. Построение отображения исходной модели в рас-

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

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

(b) Автоматически генерируется заготовка ASF-

транслятора исходной модели в расширен-ную каноническую. Заготовка строится наоснове информации, содержащейся в спискесоответствий элементов исходной и канони-ческой моделей и SDF-синтаксисах моделей.

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

5. Верификация уточнения исходной моделью рас-

ширенной канонической модели. Верификацияуточнения осуществляется на наборе образцовспецификаций исходной модели. Желательно,чтобы образец являлся достаточно характернойспецификацией исходной модели (типовой кон-струкцией). Примерами могут служить образцыпотоков работ (workflow patterns) [34], использо-ванные для синтеза канонической процессноймодели [15]. В случае, когда для модели за-труднительно выделить образцы, верификацияможет быть проведена для используемых приконструировании И-системы конкретных схем висходной модели.

Идея верификации уточнения образцом S

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

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

(b) C использованием транслятора исходной мо-дели в AMN, полученного на этапе 1b, авто-матически порождаются AMN-специфика-ции SAMNi образцов.

(c) C использованием полученного на этапе 4cтранслятора исходной модели в канониче-скую автоматически порождаются канони-ческие спецификации CSi образцов.

(d) C использованием транслятора канониче-ской модели в AMN [18], автоматически по-рождаются канонические AMN-специфика-ции CSAMNi образцов.

(e) Экспертом с использованием средств В-тех-нологии автоматически и/или интерактив-но доказывается уточнение спецификаци-ями SAMNi спецификаций CSAMNi . Текстдоказательств фиксируется.

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

Унификатор состоит из следующих крупныхкомпонентов (групп компонентов):

– Meta-Environment (для определения и проверкикорректности синтаксиса моделей и транслято-ров моделей);

– B-Toolkit (поддерживающий язык AMN и сред-ства доказательства уточнения спецификаций);

– репозиторий метаинформации;

– менеджер моделей.

Meta-Environment и B-Toolkit представляют со-бой самостоятельные продукты. Meta-Environmentподдерживает следующие этапы унификации мо-делей: формализация синтаксиса и семантики ис-ходной модели (этап 1), формализация синтакси-са расширения канонической модели (этап 3b),формализация вербальных правил отображенияисходной модели в каноническую и построениетранслятора моделей на основе автоматически сге-нерированной заготовки (этап 4c), проверка образ-цов исходной модели на соответствие формально-му синтаксису (этап 5a). B-Toolkit поддерживаетэтап 5e автоматического и интерактивного доказа-тельства уточнения спецификаций.

Репозиторий метаинформации представляет со-бой объектно-реляционную базу данных и предна-значен для реализации реестра моделей и храненияспецификаций. Реестр моделей (или просто ре-

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



Рис. 1 Архитектура Унификатора моделей

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

– название модели (краткое, полное);

– синтаксис модели:

• название документа, описывающего син-таксис (стандарт, заявка и т. д.);

• дата документа;

• ссылка на документ (URI);

• формальный SDF-синтаксис модели;

– семантика модели:

• название документа, описывающего семан-тику;

• дата документа;

• ссылка на документ (URL);

• вербальные правила отображения модели вAMN (текстовый файл);

• спецификация ASF-транслятора модели вAMN;

– спецификация заготовки эталонной схемы мо-дели;

– спецификация эталонной схемы модели;

– список регистрационных карт примеров мо-дели;

– ссылка на расширение канонической модели, скоторым интегрируется модель;



– соответствие элементов исходной и канониче-ской моделей;

– вербальные правила отображения модели в ка-ноническую;

– спецификация ASF-транслятора модели в ка-ноническую.

Все остальные компоненты Унификатора объ-единены в группу, называемую менеджер моделей.

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

– поиск информационной модели в реестре;

– регистрацию новой модели в реестре;

– просмотр расширений, зарегистрированных вреестре;

– регистрацию нового расширения канониче-ской модели в реестре.

Компонент ModelExplorer предоставляет графи-ческий интерфейс, позволяющий производить по-иск модели в реестре по полному или краткомуназванию модели, названиям или ссылкам на до-кументы, описывающие синтаксис или семантикумодели.

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

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

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

Компонент SDF2RS (SDF to Reference Schema)обеспечивает автоматическое построение заготов-ки эталонной схемы исходной модели (этап 2a) илирасширения (этап 3c) на основе их формальногосинтаксиса.

Компонент RSEditor (Reference Schema Editor)предоставляет графический интерфейс, позволя-ющий превратить заготовку эталонной схемы моде-ли (этап 2b) или расширения (этап 3c) в собственноэталонную схему.

Компонент RSIntegrator (Reference Schema Inte-grator) обеспечивает поддержку интеграции эталон-ных схем исходной модели и канонической модели(этап 2c) или расширения канонической модели(этап 3d).

Компонент SynthesisLoader обеспечивает поме-щение эталонных схем моделей (этапы 2b, 3c) испецификаций образцов моделей в репозиторийметаинформации (этап 5c).

Компонент TranslatorTemplateConstructor обеспе-чивает автоматическую генерацию заготовки ASF-транслятора исходной модели в каноническую(этап 4b).

Компонент Synthesis2B обеспечивает автомати-ческое отображение спецификаций каноническоймодели в язык AMN (этап 5d).

4 Пример отображения исходнойинформационной моделив каноническую

В этом разделе рассматривается пример отобра-жения в каноническую модель фрагмента моделиOWL (Web Ontology Language, [35]) — языка семан-тической разметки для публикации и совместногоиспользования онтологий в Веб.

4.1 Формализация синтаксиса OWL

Синтаксис и семантика OWL описаны в доку-менте [36]. Заметим, что в этом документе описанне XML-синтаксис, а абстрактный синтаксис, неза-висимый от XML представления.

Синтаксис представлен в версии расширеннойформы Бэкуса–Наура, правила которой имеют сле-дующий вид:

axiom ::= ... |’ObjectProperty(’ propertyID[’Deprecated’] { annotation }{’super(’ propertyID ’)’}[’inverseOf(’ propertyID ’)’][’Symmetric’][ ’Functional’ | ’InverseFunctional’ |’Functional’ ’InverseFunctional’ |’Transitive’ ]{ ’domain(’ classID ’)’ }{ ’range(’ classID ’)’ } ’)’

Здесь символ ::= разделяет голову и тело правила,вертикальная черта (|) означает альтернативу, опци-ональные части правила заключаются в квадратныескобки [ ], повторяющиеся части заключаются вфигурные скобки { }.

Первым этапом унификации модели являетсяпреобразование исходного синтаксиса в формаль-ный SDF-синтаксис:



module unifier/owl/OWL-Syntax

sortsAxiom ObjectPropertyAxiom ...

context-free syntaxObjectPropertyAxiom -> Axiom

"ObjectProperty" "(" PropertyID("Deprecated")? Annotation*SuperProperty* InverseOf?("Symmetric")? PropertyKind?ObjectPropertyDomain*ObjectPropertyRange* ")"-> ObjectPropertyAxiom

Как можно видеть, формальный синтаксис OWLобразует SDF-модуль OWL-Syntax, включающийраздел сортов (куда попадают все нетерминальныесимволы синтаксиса) и раздел контекстно-свобод-ного синтаксиса (включающий правила). Раздели-телем в правилах SDF является символ ->, головаправила располагается справа от разделителя, те-ло — слева. Опциональные части правил помеча-ются знаком вопроса ?, повторяющиеся части —знаком *.

При формализации в синтаксисе могут по-явиться новые нетерминальные символы, детали-зирующие синтаксис и помогающие избавитьсяот недетерминизма при программной обработке.Так, аксиома объектного свойства (ObjectProperty)в SDF-синтаксисе OWL была выделена в отдель-ный сорт, и для нее было образовано отдельноеправило.

4.2 Формализация семантики OWLв языке AMN

Формализация семантики заключается в по-строении ASF-транслятора, отображающего спе-цификации OWL в спецификации AMN. В данномразделе будут кратко проиллюстрированы принци-пы отображения OWL в AMN на примере онтологиивин:

Class(Winerestriction(hasColor cardinality(1))restriction(hasFlavor cardinality(1))restriction(hasSugar cardinality(1)))

Class(IceWinerestriction(hasFlavorallValuesFrom(oneOf(Strong Moderate))))

Class(DessertWineWinerestriction(hasSugarallValuesFrom(oneOf(OffDry Sweet))))

EquivalentClasses(IceWine

intersectionOf(DessertWinerestriction(hasColor value(White))))

ObjectProperty(hasColordomain(Wine) range(WineColor))

ObjectProperty(hasFlavordomain(Wine) range(WineFlavor))

ObjectProperty(hasSugardomain(Wine) range(WineSugar))

EnumeratedClass(WineColor White Rose Red)EnumeratedClass(WineFlavorDelicate Moderate Strong)

EnumeratedClass(WineSugarSweet OffDry Dry)

Основной класс онтологии — Wine, подкласса-ми его являются IceWine и DessertWine. Вино ха-рактеризуется цветом (свойство hasColor), вкусом(hasFlavor) и содержанием сахара hasSugar.IceWine — это белое десертное вино с сильным илисредним вкусом.

Образом при отображении данной онтологии вAMN является конструкция Wines:

REFINEMENT Wines

SETS Ind;WineColor = {White, Rose, Red};WineF lavor = {Delicate, Moderate, Strong};WineSugar = {Sweet, OffDry, Dry}

VARIABLESWine, IceWine, DessertWine,

hasColor, hasF lavor, hasSugar

INVARIANTWine ∈ POW (Ind) ∧ IceWine ∈ POW (Ind) ∧DessertWine ∈ POW (Ind) ∧DessertWine ⊆Wine ∧hasColor ∈Wine↔WineColor ∧∀wine.(wine ∈Wine⇒

card (hasColor[{wine}]) = 1) ∧hasF lavor ∈Wine↔WineF lavor ∧∀wine.(wine ∈Wine⇒

card (hasF lavor[{wine}]) = 1) ∧hasSugar ∈Wine↔WineSugar ∧∀wine.(wine ∈Wine⇒

card (hasSugar[{wine}]) = 1) ∧ran (IceWine ⊳ hasF lavor) ={Strong, Moderate} ∧

ran (DessertWine ⊳ hasSugar) ={OffDry, Sweet} ∧

IceWine = DessertWine ∩{x|x ∈ dom (hasColor) ∧ hasColor(x) =White}

OPERATIONSinclude Wine(ind) = . . .

include IceWine(ind) = . . .

include DessertWine(ind) = . . .



Рис. 2 Интеграция эталонных схем OWL и канонической модели

set hasColor(ind, val) = . . .

set hasSugar(ind, val) = . . .

set hasF lavor(ind, val) =PRE

ind ∈Wine ∧ val ∈WineF lavor ∧ind ∈ IceWine⇒ val ∈ {Strong, Moderate}

THENhasF lavor(ind) := val

END

Множество всех индивидуализированныхобъектов (individuals) онтологии представляетсяв AMN множеством Ind, перечислимые классы(например, WineColor) представляются отдель-ными множествами. Классы (например, Wine)представляются одноименными переменными, ти-пизированными в инварианте как подмножестваInd.

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

ного объекта. В примере рассмотрено тело лишьодной операции, соответствующей свойству has-

Flavor. Операция изменяет значение свойства has-

Flavor у индивидуализированного объекта ind назначение val, но только в том случае, когда вы-полняется предусловие операции, гарантирующеевыполнение инварианта после выполнения опе-рации.

4.3 Интеграция эталонных схем OWLи канонической модели

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

На левой стороне рисунка в виде UML-диа-граммы изображены типы, атрибуты и связи эта-лонной схемы модели OWL. Представлены связидвух видов: отношение обобщения — специализа-ции (например, тип Restriction является подтипомDescription) и ассоциации различных кардинально-стей (например, с аксиомой класса ClassAxiom могутбыть связаны описания — Description).

На правой стороне рисунка изображены типыэталонной схемы канонической модели.

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



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

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

Таблица 3 Соответствия конструкций OWL и канониче-ской модели

Конструкция OWLКонструкция

канонической модели

OwlID Synthesis-IdClassAxiom Abstract-TypeClassAxiom.name Abstract-Type.nameClassAxiom.descriptions Abstract-Type.attributesDescription Attribute-SpecificationRestriction Attribute-SpecificationRestriction.onProperty Attribute-Specification.name

4.4 Создание расширения каноническоймодели

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

не соответствуют никакие конструкции канониче-ской модели.

В канонической модели понятию объектногосвойства (ObjectPropertyAxiom) соответствует поня-тие метакласса ассоциаций (Association-Metaclass).Было принято решение о расширении канониче-ской модели новыми метатипами ассоциаций —Transitive, Functional и т. д. В качестве примера рас-смотрим спецификацию метатипа Transitive:

{ Transitive;in: association, metatype;instance_section: {

domain: type;range: type;transitivity: {in: predicate, invariant;{{ all a/this.domain.inst,

b/this.domain.inst,c/this.domain.inst(

b/this.range.inst &in([a,b], this) &in([b,c], this) ->

in([a,c], this)) }}} } }

Транзитивность ассоциаций выражается инва-риантом transitivity и состоит в следующем: еслиa состоит в ассоциации с b и b состоит в ассо-циации с c, то a состоит в ассоциации с c (a, b,c — значения некоторого типа данных). Так жевыражается и вербальная семантика транзитивнойассоциации.

Семантику транзитивной ассоциации в AMNрассмотрим на следующем примере. Пусть тип Re-gion содержит атрибут subRegionOf, принадлежащийметатипу ассоциаций SubRegionOf (который явля-ется подтипом метатипа транзитивных ассоциацийTransitive):

{ Region; in: type;subRegionOf: {set;type_of_element: Region;};

}{ SubRegionOf; in: association, metatype;

superclass: Transitive;instance_section: {domain: Region;range: Region;

}}

Транзитивность ассоциации означает, что еслирегион A является подрегионом B и регион B явля-ется подрегионом C, то A является подрегионом C.При отображении в AMN данная семантика будетвыражаться следующим инвариантом:

∀a, b, c (a ∈ ext Region ∧ b ∈ ext Region ∧c ∈ ext Region ∧ a ∈ subRegionOf(b)∧b ∈ subRegionOf(c)⇒ a ∈ subRegionOf(c))

Здесь subRegionOf — переменная, представляющая вAMN соответствующий атрибут, ext Region — мно-жество, представляющее все допустимые экземпля-ры типа Region.

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

Список соответствий конструкций OWL и ка-нонической модели расширяется следующим соот-ветствием:

Конструкция OWLКонструкция

канонической модели

ObjectPropertyAxiom.kind Association-Metaclass.superclass

Это соответствие означает, что вид объектногосвойства OWL выражается в канонической моделиотношением суперкласса между метатипом ассоци-аций, выражающим объектное свойство (в приме-ре — SubRegionOf), и некоторым встроенным мета-типом ассоциаций (в примере — Transitive).



4.5 Построение отображения OWLв расширенную каноническуюмодель

Структура ASF-транслятора моделей в общемслучае выглядит следующим образом:module <имя модуля><список импортируемых модулей>hiddens

variables

<список переменных>exports

context-free syntax

<список сигнатур функций трансляции>equations

<список правил трансляции>Автоматически генерируются следующие эле-

менты транслятора (тем самым образуя заготовку,подлежащую доработке экспертом):

– имя транслятора —unifier/owl2synthesis/owl-translator;

– список импортируемых (используемых) моду-лей:

imports unifier/owl/OWL-Syntaximports unifier/synthesis/

Synthesis-Syntax

– список переменных:

"ObjectPropertyAxiom"[0-9\’]* ->ObjectPropertyAxiom

"Attribute-Specification"[0-9\’]* ->Attribute-Specification

"Attribute-Specification*"[0-9\’]* ->Attribute-Specification*

Данные определения означают, что в правилахтрансляции могут использоваться перемен-ные соответствующих сортов (например, пе-ременная Attribute-Specification2 сорта Attribute-

Specification).

– список сигнатур функций трансляции:

t-Module-Def(Ontology) -> Module-Deft-Type-Specification-List(Directive*)-> {Type-Specification ","}*t-Class-Declarator-List(Directive*)-> {Class-Declarator ","}*

В данном примере функция t-Module-Def преоб-разует онтологию OWL в модуль каноническоймодели и порождена из соответствия элемен-тов Ontology и Module-Def, функция t-Type-

Specification-List преобразует список директив всписок типов и порождена из соответствия свя-зей Ontology.directives и Module-Def.type, функ-ция t-Class-Declarator-List преобразует список

директив в список классов и порождена из со-ответствия связей Ontology.directives и Module-

Def.class specification.

– список заготовок правил трансляции:

[Module-Def]Synthesis-Id := t-Module-Name(OwlID),Type-Specification* :=t-Type-Specification-List(Directive*),Class-Declarator* :=t-Class-Declarator-List( Directive* )====>t-Module-Def(Ontology(OwlID Directive*))={ Synthesis-Id; in: module;

type: Type-Specification*;class_specification:Class-Declarator*;

}

Приведенное правило описывает действиефункции t-Module-Def и порождено на основеанализа элемента t-Module-Def, его атрибутов иассоциаций (имя модуля соответствует именионтологии OWL, секции типов и секции клас-сов модуля соответствуют директивы). В пра-виле использованы рекурсивные вызовы функ-ций преобразования списка директив в спискитипов и классов.

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

4.6 Верификация уточнения модельюOWL расширенной каноническоймодели

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



OWL и семантика в AMN. Осталось рассмотретьотображение онтологии в каноническую модель,отображение канонической спецификации в AMNи верификацию уточнения AMN-спецификаций.

Каноническая спецификация, полученная при-менением транслятора OWL в каноническую мо-дель (рассмотренного в предыдущем подразделе) квинной онтологии, выглядит следующим образом:

{ Wines; in: module, ontology;type:{ Wine; in: type, owl;

hasColor: WineColor;metaslotin: HasColor;min_card: 1;max_card: 1

end...

},{ DessertWine; in: type, owl;

supertype: Wine;restriction_hasSugar: {

in: predicate, invariant;{{ all w/DessertWine (

in(w.hasSugar,{OffDry, Sweet})) }}

};},{ IceWine; in: type, owl;

restriction_hasFlavor: {in: predicate, invariant;{{ all w/IceWine (

in(w.hasFlavor,{Strong, Moderate})) }}

};},{ HasColor;

in: association, metatype, owl;instance_section: {

domain: Wine;range: WineColor;

} },...{ WineColor;

{ enum; enum_list: {White, Rose, Red} }},...

class_specification:{ wine; in: class, owl;

instance_section: Wine;},{ dessertWine; in: class, owl;

superclass: wine;instance_section: Wine;

},{ iceWine; in: class, owl;

instance_section: {in: type, owl;

supertype: DessertWine;equivalentClasses: {

in: predicate, invariant;{{ iceWine = intersect(dessertWine,

{ w | in(w, wine) &w.hasFlavor = White })

}}};

};}; }

Перечислимые классы OWL (например, Wine-

Color) представляются в канонической модели од-ноименными перечислимыми типами. Классы(например, Wine) представляются одноименнымитипами (Wine) и классами (wine) каноническоймодели. Объектные свойства (например, hasCol-

or) представляются атрибутами типов и метати-пами ассоциаций (HasColor). Ограничения значе-ний свойств представляются инвариантами типов(например, DessertWine.restriction hasSugar). Огра-ничения, выражаемые отдельными аксиомами (на-пример, аксиомы эквивалентности классов), пред-ставляются инвариантами классов каноническоймодели (например, iceWine.equivalentClasses).

Образом при отображении данной онтологии вAMN является конструкция Wines:

REFINEMENT Wines

SETS AV AL,

WineColor = {White, Rose, Red},WineF lavor = {Delicate, Moderate, Strong},WineSugar = {Sweet, OffDry, Dry}

CONSTANTSObj, ext Wine, ext DessertWine, ext IceWine

PROPERTIESObj ∈ POW (AV AL) ∧ext Wine ∈ POW (Obj) ∧ext DessertWine ∈ POW (Obj) ∧ext IceWine ∈ POW (Obj) ∧ext DessertWine ⊆ ext Wine

∧ ext IceWine ⊆ ext DessertWine

VARIABLESwine, iceWine, dessertWine,

hasColor, hasF lavor, hasSugar

INVARIANTwine ∈ POW (ext Wine) ∧iceWine ∈ POW (ext IceWine) ∧dessertWine ∈ POW (ext DessertWine) ∧dessertWine ⊆ wine ∧hasColor ∈ ext Wine→WineColor ∧hasF lavor ∈ ext Wine→WineF lavor ∧hasSugar ∈ ext Wine→WineSugar ∧∀w(w ∈ ext IceWine⇒

hasF lavor(w) ∈ {Strong, Moderate}) ∧∀w(w ∈ ext DessertWine⇒



Таблица 4 Число теорем

ТеоремыЧислотеорем

Число автоматическидоказанных теорем

Теорема непустоты объединенного состояния 1 0Теоремы уточнения операции include Wine 17 5Теоремы уточнения операции include DessertWine 20 5Теоремы уточнения операции include IceWine 21 5Теоремы уточнения операции set hasColor 11 1Теоремы уточнения операции set hasSugar 11 1Теоремы уточнения операции set hasF lavor 11 1Общее число теорем 92 18

hasSugar(w) ∈ {OffDry, Sweet}) ∧iceWine = dessertWine ∩{w|w ∈ wine ∧ hasColor(w) =White}

OPERATIONSinclude Wine(obj) = . . .

include IceWine(obj) = . . .

include DessertWine(obj) = . . .

set hasColor(obj, val) = . . .

set hasSugar(obj, val) = . . .

set hasF lavor(obj, val) =PRE

obj ∈ wine ∧ val ∈WineF lavor ∧obj ∈ iceWine⇒ val ∈ {Strong, Moderate}

THENhasF lavor(obj) := val

END

Множество всех значений абстрактных типовданных представляется в AMN множеством AVAL,множество всех значений объектных типов дан-ных — его подмножеством Obj. Перечислимыетипы (например, WineColor) представляются от-дельными множествами. Типы представляютсямножествами всех своих допустимых значений —экстенсионалами (например, тип Wine представ-ляется экстенсионалом ext Wine). Экстенсио-налы объектных типов типизируются в секцииPROPERTIES как подмножества Obj. Отношениетип–подтип представляется отношением множест-во–подмножество на экстенсионалах.

Классы (например, wine) представляются одно-именными переменными, типизированными в ин-варианте как подмножества экстенсионалов типовсвоих экземпляров. Отношение класс–подкласспредставляется отношением множество–подмно-жество на соответствующих переменных.

Атрибуты типов (например, hasColor) представ-ляются одноименными переменными, типизиро-ванными в инварианте как функции, определенныена экстенсионале типа.

Различные ограничения на классы и свойства(ограничения значений и кардинальности свойств,

аксиомы эквивалентности классов и т. д.) представ-ляются соответствующими частями инварианта.

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

Спецификации AMN, отвечающие онтологиивин OWL и ее образу при отображении в кано-ническую модель, были введены в инструменталь-ное средство автоматизации доказательства уточ-нения AMN (B-Toolkit 5.1.4). Далее автоматическибыли сформулированы 92 теоремы, в совокупно-сти утверждающие факт уточнения спецификаций.Большое количество теорем объясняется тем, чтосложные теоремы автоматически подразделяютсяинструментальным средством на более простые,которые можно доказывать независимо. Напри-мер, теорема уточнения операции set hasFlavor быларазделена на 11 теорем. С использованием авто-матических средств доказательства было доказано18 теорем, остальные были доказаны интерактив-но. В табл. 4 указано общее число теорем и числоавтоматически доказанных теорем.

5 Состояние проблемы

Представляемая работа является новой, она неимеет аналогов в мировой практике. Наиболееблизкие исследования активно ведутся в последниедесять лет Microsoft Research и рядом университетовЕвропы и США с целью создания унифицирован-ных средств манипулирования метаданными, глав-ным образом в базах данных (спецификации интер-фейсов лишь упоминаются). Эти средства сводятсяк отображению схемы баз данных из одной модели



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

Основным оператором отображения схем явля-ется ModelGen [38], параметрами которого служатисходная модель данных M1, целевая модель дан-ных M2, исходная схема базы данных S1, выра-женная в M1. Результатом ModelGen является це-левая схема S2, выраженная в M2. Существенно,что ModelGen должен быть универсальным опера-тором, применимым к любым моделям данных врассматриваемой среде.

Основная идея подхода ModelGen заключается виспользовании метамодели — набора конструкций,используемых для определения моделей данных,являющихся экземплярами метамодели. Средствомопределения конструкций этого набора являютсяунифицированные, не зависящие от моделей дан-ных метаконструкции, классифицированные в [39]Халлом и Кингом в ряд категорий:

– лексем (наборов атомарных значений);

– абстрактов (сущностей, типов и т. д.);

– агрегатов (конструкций, основанных на под-множестве декартова произведения — таблиц,связей и пр.);

– функций (атрибутов, свойств);

– иерархий и пр.

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

Процесс отображения включает следующиешаги:

1. Трансляцию исходной схемы в супермодель.

2. Трансляцию результата в целевую схему, выпол-няемую в рамках супермодели.

3. Трансляцию целевой схемы в целевую модель.

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

(is subsumed) супермоделью. Единственная транс-формация, согласно [38], кодированная авторами,соответствует шагу 2.

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

В дальнейшем планируется введение макроопе-раторов [41–43] для шага 2:

– Match — возвращает отображение одной схемыв другую;

– Merge — для двух схем и отображения однойиз них в другую возвращает интегрированнуюсхему;

– Diff — для схемы и заданного для нее отображе-ния возвращает остаток схемы, не входящий вотображение;

– Compose — возвращает композицию двух отоб-ражений схем.

Инструментарий поддерживает пользователейтрех категорий:

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

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

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

Подход ModelGen использует четырехуровневыйреляционный словарь [44]:

– уровень метасупермодели, определяющийструктуру метаконструкций;



– уровень супермодели, на котором хранятся схе-мы, подлежащие трансляции;

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

– уровень схем, на котором расположены все схе-мы системы.

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

Развитием инструментария ModelGen являетсяинструментарий MIDST [40], который дополни-тельно к отображению схем позволяет реализоватьтрансформацию на уровне данных (если задана ба-за данных D1 в схеме S1, генерируется соответству-ющая база данных D2 в схеме S2).

Отдельно, без связи с инструментарием Model-

Gen или MIDST, рассматривается вопрос транс-ляции схем, который можно отнести к шагам 1и 3 выше. Вопросы трансляции схем из исходноймодели данных (например, объектной, реляцион-ной, XML-ориентированной) в целевую рассмат-риваются в работах [45], где упоминается прото-тип интерактивной генерации реляционных схемиз объектно-ориентированных, который встроен вMicrosoft Visual Studio 2005. В процессе трансля-ции схем используются правила элиминации кон-струкций исходной схемы, которые отсутствуют вцелевой модели данных.

Неопределенными остаются термины соответ-

ствия, специализации, поглощения во фразах типа:

– отображение схемы базы данных из одной мо-дели данных в соответствующую схему базыданных в другой модели данных;

– каждая модель данных является специализаци-

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

– генерируется соответствующая база данных D2в схеме S2;

– каждая модель данных (исходная или целевая)поглощается супермоделью.

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

Одной из попыток формального обоснованиярассматриваемых отображений схем можно считатьработу [46]. В ней используется категорный подход,даны определения, на основе которых можно было

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

Авторы отмечают, что хотя алгебраическая итеоретико-модельная семантика средств отображе-ния схем и рассматривалась в [46, 47], она остаетсяво многом не исследованной областью.

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

Другими словами, образуется биекция междумножеством исходных экземпляров и подмноже-ством целевых экземпляров данных. Это считает-ся общим требованием правильности отображенияисходной модели в целевую (что, конечно же, не-точно, например в случае отображения моделей исхем для интеграции баз данных, поскольку дез-ориентирует пользователя целевой модели — онможет ожидать появления экземпляров, которыеникогда не появятся из-за семантики исходной мо-дели). Утверждается, что универсальная характе-ризация отображения моделей данных (или схембаз данных) является сложным делом: например,при трансляции схем исходная и целевая моделимогут обладать различными выразительными спо-собностями, так что при интуитивной трансляциине удастся образовать ни доминирующей, ни экви-валентной схемы, что может привести к потереинформации, представленной в рамках исходнойсхемы. Как выход из существующего положе-ния предлагается применять реверсивные отобра-жения, которые могут стать критерием правиль-ности [41].

В работе [48] предлагается использовать расши-ряемую модель, а специализация и refinement могутприменяться для расширения модели, в которойметаконструкции организованы в виде иерархиинаследования (решетки) предопределенных поня-тий. Этот подход рассматривается как альтернативаподходу, основанному на метаконструкциях супер-модели.



В работах Бернстайна макрооператоры над схе-мами баз данных (Match, Merge, Diff, Compose) рас-сматриваются чисто синтаксически: схемы и ихотображения трактуются как графовые структуры,семантика схем, определяемая соответствующимиязыками определения данных [41], при этом отбра-сывается. Авторы осознают этот недостаток и вбудущем предполагают провести дополнительныеисследования.

В практическом плане достижением считает-ся разработанная в результате многолетних иссле-дований Алмаден Центра фирмы ИБМ системаCLIO [49], которая позволяет осуществлять отобра-жение схем ресурсных баз данных в целевые схемы,выраженные в ограниченном подмножестве струк-турированных информационных моделей.

Кратко сравнение рассматриваемого в настоя-щей работе подхода (Синтез) и подхода ModelGen,

развивавшихся независимо, заключается в следу-ющем.

Выразительные способности супер- и канонической

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

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

Набор метаконструкций ядра канонической мо-дели (языка Синтез [32]) не ограничивается струк-турированными моделями данных, подобно Model-

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

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

Сохранение информации при отображении моделей.

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

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

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



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

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

Помимо универсальных средств отображениямоделей данных и схем баз данных широко извест-ны попытки разработать общие языки информаци-онных моделей, спецификаций. Достаточно упо-мянуть UML, различные архитектуры разработкиоткрытых систем (например, The Open Applica-tions Group Integration Specification (OAGIS), мо-дели архитектур программного обеспечения, опре-деляющие компоненты программ, их свойства исвязи между ними (Acme, Aesop, SADL)), выявле-ние и описание типовых конструкций разнородныхпроцессных моделей (проект, выполненный недав-но в Голландии группой Ван дер Аальста), архитек-туры открытых систем OMG, движимые моделями(MDA). Недостатком указанных попыток являетсястремление создать общий язык как единое целое,безотносительно к другим языкам спецификацийресурсов.

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

6 Заключение

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

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

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

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

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



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

Литература

1. Denning P. Computing is a Natural Science // Communi-cations of the ACM, 2007. Vol. 50, № 7.

2. Denning P. Great principles of computing // Communi-cations of the ACM, 2003. Vol. 46. № 11.

3. Kroger P. Molecular biology data: Database overview,modelling issues, and perspectives. — Munich: Institutefor Informatics, Munich University. 2001.

4. Bry F., Kroger P. A computational biology database di-gest: Data, data analysis, and data management // J. ofDistributed and Parallel Databases, 2003. Vol. 13. № 1.P. 7–42.

5. Data model for observation, Version 0.23. // IVOA DMWG Internal Draft, 2004.

6. Cambresy L., Derriere S., Padovani P., Mar-

tinez A. P., and Richard A. Ontology of astronom-ical object types, Version 1.0. // IVOA Techni-cal Note http://www.ivoa.net/ Documents/ cover/AstrObjectOntology-20061031.html, 2006.

7. Kalinichenko L. A., Briukhov D. O., Martynov D. O.,

Skvortsov N. A., Stupnikov S. A. Mediation framework forenterprise information system infrastructures // 9th Con-ference (International) on Enterprise Information Sys-tems (ICEIS), 2007.

8. Калиниченко Л. А. Методология организации реше-ния задач над множественными распределенныминеоднородными источниками информации // Меж-дународная конференция «Современные информа-ционные технологии и ИТ-образование». — М.: МГУ,2005. С. 20–37.

9. Kalinichenko L. A. Data model transformation methodbased on axiomatic data model extension // 4th Confer-ence (International) on Very Large Data Bases, 1978.

10. Калиниченко Л. А. Методы и средства интеграции не-однородных баз данных. — М.: Наука, 1983.

11. Kalinichenko L. A. Methods and tools for equivalent datamodel mapping construction // Proc. EDBT’90 Confer-ence. Springer-Verlag, 1990. P. 92–119.

12. Kalinichenko L. A., Skvortsov N. A. Extensible ontolog-ical modeling framework for subject mediation // 4thRussian Scientific Conference “DIGITAL LIBRARIES:Advanced Methods and Technologies, Digital Collec-tions.” — Dubna, 2002.

13. Kalinichenko L. A. Canonical model development tech-niques aimed at semantic interoperability in the heteroge-neous world of information modeling // Knowledge and

model driven information systems engineering for net-worked organizations: Proc. of the CAiSE INTEROPWorkshop. — Riga: Riga Technical University, 2004.P. 101–116.

14. Kalinichenko L. A., Stupnikov S. A., Zemtsov N. A. Exten-sible canonical process model synthesis applying formalinterpretation // East-European Conference ADBIS’05.Springer, 2005.

15. Калиниченко Л. А., Ступников С. А., Земцов Н. А. Син-тез канонических моделей для интеграции неодно-родных источников информации. — М.: ИПИ РАН,2005. 87 с.

16. Калиниченко Л. А. Синтез канонических моделей,предназначенных для достижения семантическойинтероперабельности неоднородных источников ин-формации // Системы и средства информатики:Спец. вып. «Формальные методы и модели в ком-позиционных инфраструктурах распределенных ин-формационных систем». — М.: ИПИ РАН, 2005.

17. Ступников С. А. Формальная семантика ядра кано-нической объектной информационной модели //Системы и средства информатики: Спец. вып. «Фор-мальные методы и модели в композиционных инфра-структурах распределенных информационных сис-тем». — М.: ИПИ РАН, 2005.

18. Ступников С. А. Отображение спецификаций, выра-женных средствами ядра канонической модели, вНотацию Абстрактных Машин // Системы и сред-ства информатики: Спец. вып. «Формальные методыи модели в композиционных инфраструктурах рас-пределенных информационных систем». — М.: ИПИРАН, 2005.

19. Ступников С. А. Автоматизация верификации уточ-нения при композиционном пректировании инфор-мационных систем и посредников // Системы и сред-ства информатики: Спец. вып. «Формальные методыи модели в композиционных инфраструктурах рас-пределенных информационных систем». — М.: ИПИРАН, 2005.

20. Ступников С. А., Брюхов Д. О. Представление UMLи OCL в канонической информационной модели //Системы и средства информатики: Спец. вып. «Фор-мальные методы и модели в композиционных инфра-структурах распределенных информационных сис-тем». — М.: ИПИ РАН, 2005.

21. Kalinichenko L. A. Method for data models integrationin the common paradigm // Advances in Databases andInformation Systems: Proc. of the 1st East-EuropeanConference. — St. Petersburg: Nevsky Dialekt, 1997.P. 275–284.

22. Butler M. csp2B: A practical approach to combining CSPand B // Formal Aspects of Computing, 2000. Vol. 12.

23. Treharne H., Schneider S. How to Drive a B machine //Formal Specification and Development in Z and B: FirstInternational Conference of Z and B Users, 2000.

24. Stupnikov S. A., Kalinichenko L. A., Dong J. S. ApplyingCSP-like workflow process specifications for their refine-ment in AMN by pre-existing workflows // Advances in



Databases and Information Systems: Proc. of the 6th East-European Conference. — Bratislava: Slovak University ofTechnology, 2002. P. 206–215.

25. Abrial J.-R. B#: Toward a synthesis between Z and B //ZB’2003 — Formal Specification and Development in Zand B: International Conference of B and Z Users, 2003.P. 168–177.

26. Stupnikov S. A., Kalinichenko L. A., Bressan S. Interac-tive discovery and composition of complex Web services //East-European Conference on ADBIS’06. Springer, 2006.

27. Abrial J.-R. B-Technology. Technical overview. B-Core(UK) Ltd., 1993.

28. Abrial J.-R. The B-Book: Assigning programs to mean-ings. — Cambridge: Cambridge University Press, 1996.

29. Cansell D., Mery D. Foudations of the B Method // Com-puting and Informatics, 2003. Vol. 22, No. 3–4. P. 221–256.

30. The B-Toolkit. http://www.b-core.com/ONLINEDOC/BToolkit.html.

31. Atelier B: The industrial tool to efficiently deploythe B method. http://www.atelierb.societe.com/indexuk.html.

32. Kalinichenko L. A., Stupnikov S. A., Martynov D. O. SYN-THESIS: A language for canonical information modelingand mediator definition for problem solving in hetero-geneous information resource environments. — M.: IPIRAS, 2007. 171 p.

33. Van den Brand M. G. J., van Deursen A., Heering J., et

al. The ASF + SDF meta-environment: A component-based language development environment // CompilerConstruction 2001 / Ed. by R. Wilhelm. Springer, 2001.P. 365–370.

34. Van der Aalst W. M. P., ter Hofstede A. H. M., Kiepuszews-

ki B., Barros A. P. Workflow patterns // Distributed andParallel Databases, 2003. Vol. 14. № 3. P. 5–51.

35. OWL Web ontology language reference. W3C Recom-mendation. http://www.w3.org/TR/owl-ref/, 2004.

36. Patel-Schneider P. F., Hayes P., Horrocks I. OWL Webontology language semantics and abstract syntax //W3C Recommendation. http://www.w3.org/TR/owl-semantics/, 2004.

37. Atzeni P. Schema and data translation: A personal per-spective // 11th East European Conference ADBIS 2007.Springer, 2007.

38. Atzeni P., Cappellari P., Bernstein P. ModelGen: Mod-el independent schema translation // 21st InternationalConference on Data Engineering, 2005.

39. Hull R., King R. Semantic database modeling: Survey,applications and research issues // ACM Computing Sur-veys, 1987. Vol. 19. № 3.

40. Atzeni P., Cappellari P., Gianforme G. MIDST: Model in-dependent schema and data translation // SIGMOD 2007Conference.

41. Bernstein P. Applying model management to classical metadata problems // 2003 CIDR Conference.

42. Melnik S., Rahm E., Bernstein P. Rondo: A programmingplatform for generic model management // SIGMOD2003 Conference.

43. Melnik S., Bernstein P., Halevy A., Rahm E. Supportingexecutable mappings in model management // SIGMOD2005 Conference.

44. Atzeni P., Cappellari P., Bernstein P. A multilevel dic-tionary for model management // ER 2005 Conference.Springer-Verlag, 2005.

45. Bernstein P., Melnik S., Mork P. Interactive schema trans-lation with instance-level mappings // 31st VLDB Con-ference, 2005.

46. Alagic S., Bernstein P. A model theory for generic schemamanagement // DBPL, 2001.

47. Miller R., Ioannidis Y., Ramakrishnan R. Schema equiv-alence in heterogeneous systems: Bridging theory andpractice // Information Systems, 1994. Vol. 19. № 1.

48. Barsalou T., Gangopadhyay D. M(dm): An open frame-work for interoperation of multimodel multidatabase sys-tems // ICDE 1992. — Los Alamitos: IEEE ComputerSociety Press, 1992.

49. Haas L. M., Hernandez M. A., Ho H., Popa L., and Roth M.

Clio, 2005. Grows up: From research prototype to indus-trial tool // Proc. of the ACM SIGMOD Conference,2005. Baltimore, Maryland, USA.


КОНСТРУИРОВАНИЕ КАНОНИЧЕСКИХ …synthesis.ipi.ac.ru › synthesis ›...

Documents

Transcript of КОНСТРУИРОВАНИЕ КАНОНИЧЕСКИХ …synthesis.ipi.ac.ru › synthesis ›...