Comments 20
> В общем случае, может быть произвольное количество уровней моделирования, однако обычно достаточно 2-3.
Да ну? Перечитайте спецификацию MOF, оно же сворачивается в точку на третьей итерации.
Да ну? Перечитайте спецификацию MOF, оно же сворачивается в точку на третьей итерации.
Спасибо за внимание к статье! Я думал, что это слишком специфическая тема, и никто не будет читать.
В MOF 1.4 действительно говорят о 4-х уровнях (M0-M3). Но начиная с версии 2.0 в спецификацию добавили уточнение. Вот, цитата из последней версии 2.5, раздел 7.3:
В MOF 1.4 действительно говорят о 4-х уровнях (M0-M3). Но начиная с версии 2.0 в спецификацию добавили уточнение. Вот, цитата из последней версии 2.5, раздел 7.3:
One of the sources of confusion in the OMG suite of standards is the perceived rigidness of a ‘Four layered metamodel architecture’ that is referred to in various OMG specifications. Note that key modeling concepts are Classifier and Instance or Class and Object, and the ability to navigate from an instance to its metaobject (its classifier). This fundamental concept can be used to handle any number of layers (sometimes referred to as metalevels). The MOF 2 Reflection interfaces allow traversal across any number of metalayers recursively. Note that most systems use a small number of levels (usually less than or equal to four). Example numbers of layers include 2 (generic reflective systems — Class/Object), 3 (relational database systems — SysTable/Table/Row), and 4 (UML 2 Infrastructure, UML 1.4, and MOF 1.4 specification — MOF/UML/User Model/User Object). MOF 1 and MOF 2 allow any number of layers greater than or equal to 2. (The minimum number of layers is two so we can represent and navigate from a class to its instance and vice versa). Suffice it to say MOF 2 with its reflection model can be used with as few as 2 levels and as many levels as users define.
Комитет и так особой ясности в вопрос не вносил, а тут вообще, кажется, перехитрили сами себя. Четвертый и следующие слои просто не имеют смысла. В рамках MOF моделей — уже M4 это 1 сущность, определяющая _всё_.
Согласен, я не смог найти ни одного примера М4. Не могу представить где это могло бы потребоваться.
Сам MOF написан на MOF :) Выше MOF точно ничего нет, но нижних уровней может быть больше. Представьте UML-диаграмму, на которой изображены такие классы: сущность, связь, атрибут. У сущности и атрибута есть свойство «имя». У связи есть две ассоциации с сущностью: «исходный_объект» и «целевой_объект». И ещё у связи есть два свойства: «множественность_для_исходного_объекта» и «множественность_для_целевого_объекта». Есть ассоциация один-ко-многим между сущностью и атрибутом. Нарисовав такую диаграмму классов мы фактически создали метамодель для ER-моделей.
Посчитаем уровни:
M4 — MOF
M3 — UML
M2 — описанная выше UML-модель с классами сущность, связь, атрибут
M1 — некоторая ER-модель
M0 — сведения, структурированные в соответствии с этой ER-моделью
Конечно, в реальности таких иерархий не бывает. Модель на уровне M2 нет никакого смысла описывать на UML, её можно сразу описывать на MOF. Т.е. UML тут лишний промежуточный слой. Но, вообще, такая иерархия не запрещена. UML вполне может использоваться для описания других языков моделирования.
Кроме MOF есть и другие метаметамодели (т.е. языки для описания языков). Самая известная — это EBNF. Вообще, язык для описания других языков сам является языком, поэтому может быть описан сам на себе :) MOF описан на MOF. EBNF можно описать на EBNF. Поэтому потребности в М4 просто нет. Если метаметамодель не может быть описана сама на себе, значит, наверное, это не очень хорошая метаметамодель. Эта тема очень хорошо описана в этой статье.
Точно так же как и компилятор языка программирования часто пишется на этом же языке.
Но с другой стороны. Вот, есть 2 метаметамодели: MOF и EBNF. Наверное можно придумать какой-то M4-язык, на котором можно описать оба этих M3-языка. А может и нельзя, потому что они в разных пространствах моделирования. MOF описывает концептуальные вещи, а EBNF — синтаксические. А может и можно. Ну, короче это вынос мозга :)
Сам MOF написан на MOF :) Выше MOF точно ничего нет, но нижних уровней может быть больше. Представьте UML-диаграмму, на которой изображены такие классы: сущность, связь, атрибут. У сущности и атрибута есть свойство «имя». У связи есть две ассоциации с сущностью: «исходный_объект» и «целевой_объект». И ещё у связи есть два свойства: «множественность_для_исходного_объекта» и «множественность_для_целевого_объекта». Есть ассоциация один-ко-многим между сущностью и атрибутом. Нарисовав такую диаграмму классов мы фактически создали метамодель для ER-моделей.
Посчитаем уровни:
M4 — MOF
M3 — UML
M2 — описанная выше UML-модель с классами сущность, связь, атрибут
M1 — некоторая ER-модель
M0 — сведения, структурированные в соответствии с этой ER-моделью
Конечно, в реальности таких иерархий не бывает. Модель на уровне M2 нет никакого смысла описывать на UML, её можно сразу описывать на MOF. Т.е. UML тут лишний промежуточный слой. Но, вообще, такая иерархия не запрещена. UML вполне может использоваться для описания других языков моделирования.
Кроме MOF есть и другие метаметамодели (т.е. языки для описания языков). Самая известная — это EBNF. Вообще, язык для описания других языков сам является языком, поэтому может быть описан сам на себе :) MOF описан на MOF. EBNF можно описать на EBNF. Поэтому потребности в М4 просто нет. Если метаметамодель не может быть описана сама на себе, значит, наверное, это не очень хорошая метаметамодель. Эта тема очень хорошо описана в этой статье.
Точно так же как и компилятор языка программирования часто пишется на этом же языке.
Но с другой стороны. Вот, есть 2 метаметамодели: MOF и EBNF. Наверное можно придумать какой-то M4-язык, на котором можно описать оба этих M3-языка. А может и нельзя, потому что они в разных пространствах моделирования. MOF описывает концептуальные вещи, а EBNF — синтаксические. А может и можно. Ну, короче это вынос мозга :)
Все проще, вы лишнего начитались :)
И MOF и EBNF можно описать и на MOF и на EBNF. Они изоморфны. Метамодель третьего уровня может описать любую модель, включая метамодели третьего уровня, по определению. Иначе она не имеет права называться М3.
Теперь про ваш пример: модель М2 из него не «нет никакого смысла описывать на UML», а нельзя описывать на UML. Вас запутало то, что у MOF и UML одинаковый синтаксис. Объект «class MyClass» в любом языке программирования с рефлексией — играет как бы сразу двух персонажей, это и инстанс и класс. Так вот создавая объект UML вы получаете модель, а не метамодель. В вашем примере М2 на самом деле инстанс М4. то есть непосредственно MOF.
И MOF и EBNF можно описать и на MOF и на EBNF. Они изоморфны. Метамодель третьего уровня может описать любую модель, включая метамодели третьего уровня, по определению. Иначе она не имеет права называться М3.
Теперь про ваш пример: модель М2 из него не «нет никакого смысла описывать на UML», а нельзя описывать на UML. Вас запутало то, что у MOF и UML одинаковый синтаксис. Объект «class MyClass» в любом языке программирования с рефлексией — играет как бы сразу двух персонажей, это и инстанс и класс. Так вот создавая объект UML вы получаете модель, а не метамодель. В вашем примере М2 на самом деле инстанс М4. то есть непосредственно MOF.
Возможно я перемудрил с примером. Пусть будет другой. Мы можем на EBNF описать BNF. А на BNF описать, например, Java. Получаем:
M4 — EBNF
M3 — BNF
M2 — Java
M1 — программа на Java (с классами «Сотрудник», «Задача», ...)
M0 — объекты реального мира
Практического смысла использовать разные языки на М3 и М4 нет, но всё-таки это возможно.
Описать EBNF с помощью MOF можно. Хотя, есть сомнения. Потому что EBNF описывает синтаксические конструкции, последовательности символов. А MOF описывает сугубо концептуальные вещи (некие абстрактные классы, понятия) и не описывает их представление в виде последовательности символов или квадратиков, стрелочек. Ну, допустим, у нас будут классы «Терминальный символ», «Нетерминальный символ», «Правило», «Конкантенация», «Выбор»,…
Но описать MOF на EBNF точно не получится. На EBNF можно описать одно из текстовых представлений MOF. Например, в виде XMI-файла. Т.е. EBNF в принципе описывает только строки, а не понятия.
M4 — EBNF
M3 — BNF
M2 — Java
M1 — программа на Java (с классами «Сотрудник», «Задача», ...)
M0 — объекты реального мира
Практического смысла использовать разные языки на М3 и М4 нет, но всё-таки это возможно.
Описать EBNF с помощью MOF можно. Хотя, есть сомнения. Потому что EBNF описывает синтаксические конструкции, последовательности символов. А MOF описывает сугубо концептуальные вещи (некие абстрактные классы, понятия) и не описывает их представление в виде последовательности символов или квадратиков, стрелочек. Ну, допустим, у нас будут классы «Терминальный символ», «Нетерминальный символ», «Правило», «Конкантенация», «Выбор»,…
Но описать MOF на EBNF точно не получится. На EBNF можно описать одно из текстовых представлений MOF. Например, в виде XMI-файла. Т.е. EBNF в принципе описывает только строки, а не понятия.
А чем это описание в виде XMI вам не угодило? Оно совершенно изоморфно MOF M3.
Тут скорее эпиморфизм (из множества XMI-файлов в множество MOF-моделей), чем изоморфизм. Одна и та же MOF-модель может быть представлена в виде различных XMI-файлов с разными пробелами, разными идентификаторами (xmi:id), разным порядком XML-элементов, XML-атрибутов.
MOF и XMI соотносятся так же как понятие и символ в семантическом треугольнике. Например, есть некий реальный объект — допустим, автомобиль. Мы можем обозначить этот автомобиль с помощью слова «автомобиль», слова «car», картинки со схематичным изображением автомобиля, жестами или как-то ещё. Но независимо от способа обозначения у человека в сознании будет одно и тоже понятие «автомобиль».
MOF позволяет описывать понятия независимо от формы их представления. А XMI позволяет упаковать эти абстрактные понятия в последовательность символов. Т.е. для MOF объект моделирования (М0) это объекты реального мира, а на уровне М1 понятия об этих объектах. А для XMI — объект моделирования (М0) это не объекты реального мира, а понятия об этих объектах, а на уровне М1 будут последовательности символов, описывающие понятия.
Кстати, как-раз картинка на эту тему:
Другая форма представления MOF-моделей — это диаграммы. Или, например, в Eclipse MOF-модели можно представить в виде дерева. Нельзя сказать, что диаграмма или XMI-файл тождественны самой модели. Точно так же как нельзя сказать, что понятие «автомобиль» в сознании человека тождественно слову «автомобиль» или рисунку с автомобилем.
MOF и XMI соотносятся так же как понятие и символ в семантическом треугольнике. Например, есть некий реальный объект — допустим, автомобиль. Мы можем обозначить этот автомобиль с помощью слова «автомобиль», слова «car», картинки со схематичным изображением автомобиля, жестами или как-то ещё. Но независимо от способа обозначения у человека в сознании будет одно и тоже понятие «автомобиль».
MOF позволяет описывать понятия независимо от формы их представления. А XMI позволяет упаковать эти абстрактные понятия в последовательность символов. Т.е. для MOF объект моделирования (М0) это объекты реального мира, а на уровне М1 понятия об этих объектах. А для XMI — объект моделирования (М0) это не объекты реального мира, а понятия об этих объектах, а на уровне М1 будут последовательности символов, описывающие понятия.
Кстати, как-раз картинка на эту тему:
Другая форма представления MOF-моделей — это диаграммы. Или, например, в Eclipse MOF-модели можно представить в виде дерева. Нельзя сказать, что диаграмма или XMI-файл тождественны самой модели. Точно так же как нельзя сказать, что понятие «автомобиль» в сознании человека тождественно слову «автомобиль» или рисунку с автомобилем.
Я кажется сам понял почему MOF и EBNF (или XMI) не изоморфны. М3-модели позволяют описывать М2-модели, которые позволяют описывать М1-модели, которые позволяют описывать объекты реального мира (М0).
У MOF и EBNF это множество объектов реального мира разное. И способ описания разный, описываются разные аспекты этих объектов.
Для MOF объектом может быть любой реальный или воображаемый объект. При этом с помощью семейства MOF-моделей мы можем описывать свойства этого объекта, область значений свойств, отношения между объектами. Можем в модели указать, что одно множество объектов включает в себя другое множество объектов с помощью отношения обобщения.
Для EBNF объектом могут быть только понятия, а не любые объекты. И с помощью EBNF мы не можем описывать свойства объектов, их отношения, не можем описать отношение обобщения. Зато можем описать как это понятие можно представить в виде последовательности символов.
Конечно в EBNF мы можем описать подобный язык:
А можем сделать такой язык:
или ещё какой-то.
Все эти языки будут описывать не объекты сами по себе, а только понятия об объектах, представленные в виде определенной последовательности символов. Когда мы создаём подобный язык на EBNF, то неявно подразумевается, что уже существует MOF, в котором определены такие понятия как «класс», «свойство», «отношение» и т.п. И в EBNF мы только указываем как описать эти понятия из MOF в виде последовательности символов. Но в самом EBNF при этом нет никаких классов, свойств и отношений. В нём есть только терминальные и нетерминальные символы, правила, конкантенация, выбор и т.д.
У MOF и EBNF это множество объектов реального мира разное. И способ описания разный, описываются разные аспекты этих объектов.
Для MOF объектом может быть любой реальный или воображаемый объект. При этом с помощью семейства MOF-моделей мы можем описывать свойства этого объекта, область значений свойств, отношения между объектами. Можем в модели указать, что одно множество объектов включает в себя другое множество объектов с помощью отношения обобщения.
Для EBNF объектом могут быть только понятия, а не любые объекты. И с помощью EBNF мы не можем описывать свойства объектов, их отношения, не можем описать отношение обобщения. Зато можем описать как это понятие можно представить в виде последовательности символов.
Конечно в EBNF мы можем описать подобный язык:
Класс Сотрудник
Свойство ФИО [1]
Свойство Дата_рождения [1]
А можем сделать такой язык:
class Сотрудник {
int ФИО [1]
date Дата_рождения [1]
}
или ещё какой-то.
Все эти языки будут описывать не объекты сами по себе, а только понятия об объектах, представленные в виде определенной последовательности символов. Когда мы создаём подобный язык на EBNF, то неявно подразумевается, что уже существует MOF, в котором определены такие понятия как «класс», «свойство», «отношение» и т.п. И в EBNF мы только указываем как описать эти понятия из MOF в виде последовательности символов. Но в самом EBNF при этом нет никаких классов, свойств и отношений. В нём есть только терминальные и нетерминальные символы, правила, конкантенация, выбор и т.д.
Спасибо. Всегда интересовали возможности моделирования с помощью Eclipse Modelling Tools. К сожалению, существует очень мало информации на этот счет.
Насколько я могу судить, последнее поколение тулзов отошло от OMG в сторону генерации собственных описательных языков (Epsilon).
Если Вы специалист в EMFT, будет очень интересно увидеть статьи, освещающие использование полного стека технологий на примере от создания модели и до работающего приложения, включающего persistence и xml-mapping.
Насколько я могу судить, последнее поколение тулзов отошло от OMG в сторону генерации собственных описательных языков (Epsilon).
Если Вы специалист в EMFT, будет очень интересно увидеть статьи, освещающие использование полного стека технологий на примере от создания модели и до работающего приложения, включающего persistence и xml-mapping.
Мне самому очень интересна эта тема. Я уже начал писать следующую статью :) От стандартов OMG они не уходят. По крайней мере, их реализации UML, OCL, QVTo основаны на последних версиях стандартов и вполне поддерживаются. Разработчики на форуме оперативно отвечают на вопросы, исправляют ошибки. Уже есть какая-то реализация QVTd.
Немного в стороне Acceleo (который основан на MOF M2T). Сам Accelo вроде активно используется, но стандарт MOF M2T с 2008-го года не обновлялся.
И вы правы, действительно, появляются альтернативные технологии типа Epsilon. Но идейно они не очень сильно ушли от стандартов OMG. Тот же Epsilon Object Language в значительной степени основан на OCL. Я думаю, что просто растет популярность MDA и поэтому появляются новые альтернативные технологии. Чем больше их будет, тем лучше — больше выбор.
Немного в стороне Acceleo (который основан на MOF M2T). Сам Accelo вроде активно используется, но стандарт MOF M2T с 2008-го года не обновлялся.
И вы правы, действительно, появляются альтернативные технологии типа Epsilon. Но идейно они не очень сильно ушли от стандартов OMG. Тот же Epsilon Object Language в значительной степени основан на OCL. Я думаю, что просто растет популярность MDA и поэтому появляются новые альтернативные технологии. Чем больше их будет, тем лучше — больше выбор.
Статья и в самом деле насколько специфична, настолько и полезна. Спасибо автору! Правда, я не сторонник использования ООПешных терминов для моделирования предметных областей, например, когда используется странный на мой взгляд термин экземпляр сотрудника вместо просто сотрудник. Но пока мы только начинаем изучать моделирование и любая информация на эту тему на вес золота! Спасибо!
Да, хотя в тексте много UML, классов, объектов, всё это относится не только к ООП, но к моделированию в целом. Тот же BPMN — это тоже стандарт OMG, основанный на MOF. Или ещё у них есть метамодель для онтологий.
Даже «Войну и мир» можно разложить по уровням моделирования :) M0 — реальные или выдуманные события, люди, объекты. М1 — текст, написанный Толстым, М2 — русский язык. Аналогично можно выделить уровни и для музыкальных или художественных произведений. Они отличаются от привычных языков моделирования и метамоделирования только меньшей формализованностью.
Если посмотреть на это совсем глобально, с точки зрения теологии или философии, то весь наш мир можно рассматривать как уровень М1. При этом Бог — это уровень М2. Абсолютно каждый объект на уровне М1 создан по образу и подобию (является экземпляром) некоторого метакласса на уровне М2.
Я пишу это не ради каких-то религиозных споров и т.п., а чтобы показать, что разработка, управляемая моделями — это качественно новый подход к разработке ПО, который даёт целостный взгляд на моделирование, DSL, рефлексию в языках программирования, сам процесс разработки и т.п.
Например, в статье сотрудники, задачи и проекты описаны в виде UML-классов. Но с тем же успехом их можно описать в виде Java-классов. При этом в качестве метамодели вместо UML используется Java, а в качестве метаметамодели вместо MOF используется EBNF. Практически любой артефакт, создаваемый при разработке ПО можно разложить по уровням моделирования.
Кстати, в сторону ISO 15926, 4D-онтологий мы тоже смотрим…
Даже «Войну и мир» можно разложить по уровням моделирования :) M0 — реальные или выдуманные события, люди, объекты. М1 — текст, написанный Толстым, М2 — русский язык. Аналогично можно выделить уровни и для музыкальных или художественных произведений. Они отличаются от привычных языков моделирования и метамоделирования только меньшей формализованностью.
Если посмотреть на это совсем глобально, с точки зрения теологии или философии, то весь наш мир можно рассматривать как уровень М1. При этом Бог — это уровень М2. Абсолютно каждый объект на уровне М1 создан по образу и подобию (является экземпляром) некоторого метакласса на уровне М2.
Я пишу это не ради каких-то религиозных споров и т.п., а чтобы показать, что разработка, управляемая моделями — это качественно новый подход к разработке ПО, который даёт целостный взгляд на моделирование, DSL, рефлексию в языках программирования, сам процесс разработки и т.п.
Например, в статье сотрудники, задачи и проекты описаны в виде UML-классов. Но с тем же успехом их можно описать в виде Java-классов. При этом в качестве метамодели вместо UML используется Java, а в качестве метаметамодели вместо MOF используется EBNF. Практически любой артефакт, создаваемый при разработке ПО можно разложить по уровням моделирования.
Кстати, в сторону ISO 15926, 4D-онтологий мы тоже смотрим…
Ну да. Чтобы представить себе принципиально иную метамодель — надо уйти от MOF-UML. В RDF-OWL мире вообще можно не заботиться о границе между уровнями мета.
Но писать ограничения для OWL, да ещё транслируемые в какой-то код на языках программирования, пока не так удобно, как строить OCL в Эклипсе.
Но писать ограничения для OWL, да ещё транслируемые в какой-то код на языках программирования, пока не так удобно, как строить OCL в Эклипсе.
OWL — это действительно немного другой мир. Я думаю, что он более выразительный, чем MOF. И многие вещи, которые в MOF приходится описывать с помощью OCL, в RDF/OWL описываются без дополнительных языков. Кстати в Ontology Definition Metamodel пишут, что OCL для онтологий не очень подходит, потому что он слишком неформальный (раздел 8.5):
Но при всех плюсах OWL его сложно представлять в виде диаграмм. И на нём сложно описывать конкретные, строго определенные структуры данных. Т.е. он хорош для концептуального моделирования, когда нужно описать какие сущности, свойства, отношения могут быть в принципе. Но если нужно описать, например, структуру конкретного сообщения, то MOF/UML использовать удобней.
Кстати OCL можно использовать не только для описания ограничений, но и для описания преобразований моделей. QVT, MOF M2T, ATL и другие используют OCL для работы с элементами модели. При этом неважно из какого пространства моделирования эти модели (MOF, RDF, EBNF). Например, можно описать преобразование OWL в UML по каким-то правилам. И OCL тут очень полезен, именно как язык для навигации по модели. OCL можно сравнить XPath или SQL. Все эти языки могут использоваться не только для описания ограничений, но и для манипуляции данными.
8.5 Why Common Logic over OCL?
Common Logic (CL) is qualitatively different from some of the other metamodels in that it represents a dialect of traditional first order logic, rather than a modeling language. UML already supports a constraint (rule) language, which includes similar logic features, OCL [OCL], so why not use it?
The short answer to that question is that the ODM does include OCL in the same way it includes UML. Unfortunately, just as UML lacks a formal model theoretic semantics, OCL also has neither a formal model theory nor a formal proof theory, and thus cannot be used for automated reasoning (today). Common Logic, on the other hand, has both, and therefore can be used either as an expression language for ontology definition or as an ontology development language in its own right.
Но при всех плюсах OWL его сложно представлять в виде диаграмм. И на нём сложно описывать конкретные, строго определенные структуры данных. Т.е. он хорош для концептуального моделирования, когда нужно описать какие сущности, свойства, отношения могут быть в принципе. Но если нужно описать, например, структуру конкретного сообщения, то MOF/UML использовать удобней.
Кстати OCL можно использовать не только для описания ограничений, но и для описания преобразований моделей. QVT, MOF M2T, ATL и другие используют OCL для работы с элементами модели. При этом неважно из какого пространства моделирования эти модели (MOF, RDF, EBNF). Например, можно описать преобразование OWL в UML по каким-то правилам. И OCL тут очень полезен, именно как язык для навигации по модели. OCL можно сравнить XPath или SQL. Все эти языки могут использоваться не только для описания ограничений, но и для манипуляции данными.
Ну, с диаграммами не сильно сложнее, для большой модели что на OWL, что в UML- проблем грамотно распределить по листам, и красиво развести стрелочки.
Под «сложно описывать структуры данных» Вы имеете в виду переход к реальным структурам таблиц СУБД и исполняемых правил для них? Да, для этого нужен ещё один уровень мэппинга, выбор таблиц, колонок, и это работа для модельера логического и физического уровней.
Однако зачем таблицы, если есть triple stores и reasoning? C triple stores вообще всё уже почти хорошо в смысле быстродействия по сравнению с СУБД. C reasoning пока не так хорошо, но сделать проверку фиксированного (без вывода новых) набора правил над триплетами не сложнее, чем проверку фиксированного набора правил OCL.
Как использовать OCL для описания мэппинга из OWL — я что-то не понимаю. Для описания мэппинга нужны два языка поиска по структурам двух исходных языков. Для RDF это SPARQL, который сейчас слегка расширяют в рамках проекта www.w3.org/2014/data-shapes/wiki/Main_Page. Вот на связке SPARQL и SQL можно описывать преобразование сразу в таблицы.
Под «сложно описывать структуры данных» Вы имеете в виду переход к реальным структурам таблиц СУБД и исполняемых правил для них? Да, для этого нужен ещё один уровень мэппинга, выбор таблиц, колонок, и это работа для модельера логического и физического уровней.
Однако зачем таблицы, если есть triple stores и reasoning? C triple stores вообще всё уже почти хорошо в смысле быстродействия по сравнению с СУБД. C reasoning пока не так хорошо, но сделать проверку фиксированного (без вывода новых) набора правил над триплетами не сложнее, чем проверку фиксированного набора правил OCL.
Как использовать OCL для описания мэппинга из OWL — я что-то не понимаю. Для описания мэппинга нужны два языка поиска по структурам двух исходных языков. Для RDF это SPARQL, который сейчас слегка расширяют в рамках проекта www.w3.org/2014/data-shapes/wiki/Main_Page. Вот на связке SPARQL и SQL можно описывать преобразование сразу в таблицы.
Вообще, да, онтологию всегда можно нарисовать в виде графа. Но там будет много вспомогательных узлов. Чтобы диаграмма была понятна не специалистам, приходится придумывать упрощенную, более наглядную нотацию. Например, классы обозначаем кружками, объекты прямоугольниками со скругленными углами, значения просто прямоугольниками. Приходится придумывать нотацию для объединения или пересечения классов. Или как, например, показать на диаграмме, что между некоторыми сущностями НЕ должно быть отношения? Можно обозначить, например, перечеркнутой линией. Сложно показывать отношения между отношениями. Ограничения на множественность в rdf выглядят сложнее, чем в UML.
Есть разные попытки придумать визуальную нотацию для онтологий: VOWL, EXPRESS-G или что-то такое. Но все эти языки гораздо сложнее, чем диаграммы классов, к которым все более-менее уже привыкли.
Отображение моделей в MDA обычно выглядит так. Если исходная или целевая модель не MOFовская, то сначала её нужно сделать такой. Например, на входе RDF-файл.
Создаем MOF-метамодель, в которой описываем все сущности в виде MOF-классов, которые есть в спецификации RDF. Описываем триплеты, графы, ресурсы и т.д. в виде такой диаграммы классов (раздел 10):
Таким образом мы получили объектную модель для RDF. Аналогичная объектная модель уже есть для UML.
И всё, теперь мы можем использовать OCL для работы с RDF. Аналогично с реляционными моделями, описываем их в виде объектной MOF-метамодели. В итоге нам не важно онтологии это или реляционные модели, мы сначала делаем их объектными и манипулируем ими с помощью единого языка — OCL. Это сложно описать в комментарии, я планирую серию статей на эту тему.
Есть разные попытки придумать визуальную нотацию для онтологий: VOWL, EXPRESS-G или что-то такое. Но все эти языки гораздо сложнее, чем диаграммы классов, к которым все более-менее уже привыкли.
Отображение моделей в MDA обычно выглядит так. Если исходная или целевая модель не MOFовская, то сначала её нужно сделать такой. Например, на входе RDF-файл.
Создаем MOF-метамодель, в которой описываем все сущности в виде MOF-классов, которые есть в спецификации RDF. Описываем триплеты, графы, ресурсы и т.д. в виде такой диаграммы классов (раздел 10):
Таким образом мы получили объектную модель для RDF. Аналогичная объектная модель уже есть для UML.
И всё, теперь мы можем использовать OCL для работы с RDF. Аналогично с реляционными моделями, описываем их в виде объектной MOF-метамодели. В итоге нам не важно онтологии это или реляционные модели, мы сначала делаем их объектными и манипулируем ими с помощью единого языка — OCL. Это сложно описать в комментарии, я планирую серию статей на эту тему.
Насчет triple store… Могут быть организационные или технические причины, по которым, например, для хранения должны использоваться реляционные базы, а для обмена — XML или ещё что-то. Причём, XML с «простой и понятной» XML-схемой, а не RDF/XML :)
Я не думаю, что RDF будет универсальным языком моделирования, который заменит все остальные. Наверное всегда будут существовать разные языки моделирования. При этом всегда будет потребность в преобразовании одних моделей в другие. OMG описывает эти идеи в Model-driven architecture.
Я не думаю, что RDF будет универсальным языком моделирования, который заменит все остальные. Наверное всегда будут существовать разные языки моделирования. При этом всегда будет потребность в преобразовании одних моделей в другие. OMG описывает эти идеи в Model-driven architecture.
>Спасибо за внимание к статье! Я думал, что это слишком специфическая тема, и никто не будет читать.
Скорее не тема специфична, а подача материала. Обе статьи начинаются не с объяснения причин возникновения и представления проблемы.
Отсылки на первичные источники отсутствуют. Реляционная алгебра не упоминается и ее плюсы и минусы опускаются.
Любопытно, что автор не вникает в семантику нормализации. Хорошо было бы напомнить определения и требования к нормальным формам.
Скорее не тема специфична, а подача материала. Обе статьи начинаются не с объяснения причин возникновения и представления проблемы.
Отсылки на первичные источники отсутствуют. Реляционная алгебра не упоминается и ее плюсы и минусы опускаются.
Любопытно, что автор не вникает в семантику нормализации. Хорошо было бы напомнить определения и требования к нормальным формам.
Согласен, но это не научная статья :) Поэтому я не уделял особого внимания источникам, проблематике.
Реляционная алгебра и вообще моделирование данных имеют очень опосредованное отношение к основной теме статей (разработка, управляемая моделями). Поэтому я их затронул ровно на столько, чтобы было вообще понятно что такое Anchor и зачем он может быть нужен. Я ориентировался на человека, который возможно никогда не занимался моделированием данных. Плюсы и минусы реляционной алгебры для него явно лишние. Тем более, я не утверждаю, что какие-то подходы лучше или хуже. Просто говорю, что есть разные подходы к моделированию. И есть инструмент, который позволяет реализовывать эти языки моделирования.
Но замечание конечно принимается. Если затрагиваешь какую-то тему, то будь добр, раскрыть её нормально.
Реляционная алгебра и вообще моделирование данных имеют очень опосредованное отношение к основной теме статей (разработка, управляемая моделями). Поэтому я их затронул ровно на столько, чтобы было вообще понятно что такое Anchor и зачем он может быть нужен. Я ориентировался на человека, который возможно никогда не занимался моделированием данных. Плюсы и минусы реляционной алгебры для него явно лишние. Тем более, я не утверждаю, что какие-то подходы лучше или хуже. Просто говорю, что есть разные подходы к моделированию. И есть инструмент, который позволяет реализовывать эти языки моделирования.
Но замечание конечно принимается. Если затрагиваешь какую-то тему, то будь добр, раскрыть её нормально.
Sign up to leave a comment.
Объектный язык ограничений (и немного про метамодели)