1. Ключевые отличия между MOF 2.5.1 и MOF 3
Независимость от UML и новый метамодельный подход. В MOF 2.5.1 языки часто определялись как профили UML (например, SysML v1 расширял UML через стереотипы), что накладывало ограничения UML-метамодели на DSL-язык. В MOF 3 предполагается переход к самостоятельным метамоделям, не зависящим от UML
mbse4u.com
. Новый стандарт позволит определять язык прямо на основе MOF (M3) без «унаследованных» ограничений UML-метамодели. Это означает, что концепции моделирования можно задавать с нуля, а не через адаптацию существующих UML-элементов. Например, команда SysML v2 разработала новую метамодель без привязки к UML, устранив проблемы, вызванные наследованием от UML в SysML v1mbse4u.com.
Интеграция семантики в метамодель. MOF 2.x фокусировался в основном на описании структуры моделей (абстрактного синтаксиса); семантика моделей определялась вне MOF (неформально в тексте спецификаций или через OCL-ограничения). Одно из ключевых улучшений MOF 3 – поддержка явного задания семантики элементов модели на уровне метамодели. Этот шаг эволюции был инициирован стандартом **SMOF (Semantic MOF)**
mbse4u.com
, предлагающим расширения для описания семантических структур. В MOF 3 эти идеи воплощаются: метамодели смогут содержать формальные определения семантики (например, через специальные семантические библиотеки или логические правила). В результате модели на основе MOF 3 будут однозначно трактоваться и поддерживать верификацию и исполнение. Так, для SysML v2 (основанного на новой метамодели) уже заявлена возможность формальной проверки моделей, их симуляции, генерации выполняемых сценариев и пр.nemo.inf.ufes.br – такие возможности становятся достижимы благодаря включению семантики в ядро метаязыка.
Модульная, многослойная архитектура метамоделирования. MOF 2.5.1 представляет метамодель как единый монолитный набор классов (с некоторыми профилями соответствия – EMOF/CMOF). MOF 3 вводит более слоистую архитектуру метамодели, выделяя минимальное ядро и расширяемые модули. Этот подход прослеживается в KerML – новом ядре моделирования, где метамодель разделена на три уровня: Root (синтаксический фундамент: элемент, отношение, аннотация и т.д.), Core (семантический фундамент: базовые понятия типа “Classifier”, “Feature” и пр.) и Kernel (основные оставшиеся элементы: классы, структуры данных, поведения и т.д.)
nemo.inf.ufes.br
nemo.inf.ufes.br. MOF 3, будучи метаязыком более высокого уровня, перенимает идею модульности: ядро MOF 3 содержит только необходимые примитивы, а более сложные конструкции могут быть оформлены как библиотеки модели (model libraries). В отличие от предыдущей версии, где расширение метамодели зачастую требовало внесения изменений в саму спецификацию, MOF 3 делает метамодель более компонентной и переиспользуемойnemo.inf.ufes.br, что упрощает эволюцию стандартов. (Например, UML 3.0 вероятно будет построен как надстройка над таким ядром, аналогично тому как SysML v2 использует ядро KerMLgsaw.org.)
Новые возможности расширения и отказ от устаревших механизмов. MOF 2.x не имел собственного механизма расширения, кроме как через профили UML (стереотипы) или создание новых метамоделей “с нуля”. MOF 3 упрощает задачу расширения языков моделирования за счет библиотек моделей и более гибкого импортирования пакетов. Теперь, вместо определения профиля со стереотипами, можно добавлять новые элементы в язык как библиотеку на основе ядра. Это подход, уже примененный в SysML v2: расширение языка выполняется добавлением элементов из Systems Library и Domain Library поверх ядра KerML
nemo.inf.ufes.br
nemo.inf.ufes.br. Таким образом устраняются ограничения профилей UML – разработчики DSL могут напрямую расширять метамодель, не искажая исходные понятия. Для инструментов и пользователей это выглядит как “подключение” модуля с дополнительными концепциями вместо применения стереотипов. Кроме того, MOF 3 пересматривает ряд устаревших технических решений: например, мэппинги на CORBA IDL и XMI. В новых реалиях CORBA используется редко, поэтому MOF 3 обновит IDL-модель репозитория (известно упоминание о MOF 3 IDL в задачах OMGissues.omg.org) и улучшит поддержку современных форматов обмена (JSON/YAML помимо XMI, поддержка RDF/OWL и т.д.). Эти изменения делают инфраструктуру более актуальной и удобной для разработчиков.
Совместимость и упрощение метамоделирования. MOF 3 учитывает опыт предыдущих версий, поэтому ряд ограничений снят или упрощен. Например, правила EMOF/CMOF унифицированы (не нужно выбирать между “Essential” и “Complete” MOF – одна спецификация охватывает оба уровня). Улучшена обработка ассоциаций и свойств: предполагается более простое задание противоположностей, квалификаторов и множественностей, что ранее вызывало сложности (в MOF 2.5.1 оставались спорные моменты вроде oppositeRoleName и ограничений навигируемости
issues.omg.org
). MOF 3 стремится обеспечить бóльшую совместимость с существующими метамоделями: модели, созданные по MOF 2.5.1, могут быть относительно легко перенесены на новую версию, так как основные понятия (классы, атрибуты, ассоциации, пакеты) сохраняются. Однако разработчикам следует ожидать небольших изменений в синтаксисе XMI и API. В целом, переход на MOF 3 вносит эволюционные (не революционные) правки, направленные на расширение возможностей и устранение выявленных недостатков предыдущей версии.
(В таблице ниже обобщены некоторые отличия между MOF 2.5.1 и MOF 3):
Примечание: MOF 3 находится на стадии финализации стандарта. Вышеописанные отличия основаны на направлениях развития, обозначенных рабочими группами OMG (в частности, опыте SysML 2)
gsaw.org
. Точные детали реализации могут уточняться в финальной спецификации.
2. Влияние на разработку DSL-языков
Новые возможности MOF 3 заметно расширяют свободу разработки домен-специфических языков моделирования (DSL):
Отсутствие «багажа» UML. Разработчики DSL больше не привязаны к структурам UML. В MOF 2.x типичный способ создать DSL – это профиль UML, что заставляло «подгонять» концепции предметной области под существующие классы UML. С MOF 3 метамодель DSL можно строить с нуля, используя только необходимые элементы ядра. Это устраняет многие искусственные ограничения. Например, в SysML v1 элементы вроде Allocate или ElementGroup были реализованы через стереотипы и испытывали проблемы из-за ограничений UML-метамодели
mbse4u.com
. В SysML v2 (DSL для системной инженерии на новой основе) эти проблемы исчезли – язык определён независимо, что стало возможным благодаря эволюции MOF. Для разработчиков DSL это значит, что язык может точно отражать понятия своей предметной области, а не только те, что «умещаются» в UML-класс.
Встроенная семантика = сразу исполняемые DSL. С интеграцией семантики на уровне метамодели появляется возможность создавать исполняемые DSL без дополнительных средств. В МОF 3 DSL-язык может включать формальные ограничения (OCL), определения поведения (например, через действия, правила или ссылки на исполняемую семантику). Это открывает путь к автоматической проверке моделей на корректность, моделированию их исполнения и даже генерации кода напрямую из моделей
nemo.inf.ufes.br
. Ранее, на MOF 2, для подобных возможностей требовались отдельные стандарты (fUML, ALF для исполнения UML-моделей и др.). Теперь же, описав семантику в метамодели DSL, разработчик получает язык, модели на котором могут проверяться и исполняться более однозначно. Для предметно-ориентированных языков (например, языка бизнес-процессов, сетевых архитектур и т.п.) это значительный шаг – можно заложить формальные правила предметной области прямо в DSL и затем автоматически анализировать модели на их основе.
Устранение ограничений и усложнений предыдущего подхода. Разработка DSL на основе UML-профиля нередко требовала обходных решений: например, «наследование» свойств через стереотипы, дублирование понятий, которые отсутствовали в UML. MOF 3 снимает эти ограничения. Появляется поддержка более сложных структур данных, многократного наследования или классификации, сложных ассоциаций (n-арных, ассоциаций-klass и т.п.), что раньше было либо запрещено, либо затруднено. В итоге DSL может быть богаче по конструкции. Также отпадает проблема соответствия между «понятиями профиля» и реальной метамоделью – теперь DSL является полноценной метамоделью. Проще говоря, создавая DSL на MOF 3, мы работаем с теми же первоклассными элементами (классы, отношения, свойства), что и в UML-метамодели, но можем определять свои, специализированные.
Проще расширять и поддерживать DSL. За счёт модульности MOF 3 становится реалистичной картина семейства языков, разделяющих общее ядро. KerML задуман как такой универсальный базовый язык, который может быть расширен для разных доменов
nemo.inf.ufes.br
. Это значит, что при разработке нового DSL можно не проектировать все с чистого листа – достаточно взять ядро (например, тот же KerML или подобный библиотечный пакет) и сконцентрироваться на добавлении специфичных элементов. Появляются библиотеки типовых концепций, которые можно переиспользовать в разных DSL. Например, для всех языков моделирования может быть единая библиотека математических примитивов, единая библиотека измерUnits (единиц измерения) и т.д., вместо того чтобы каждый раз определять их заново. В перспективе это ускорит создание DSL и повысит их совместимость между собой.
Более простая эволюция DSL-языков. Поскольку MOF 3 поощряет модульность, обновлять DSL (добавлять новые фичи, менять семантику) станет легче. Можно выпустить новую версию DSL-языка, введя дополнительную библиотеку моделей или обновив существующие, без ломки базовой структуры. В MOF 2.5.1 изменения нередко требовали пересмотра профиля UML или даже хардкодинга новых элементов, что могло нарушить совместимость. С MOF 3 разработчики DSL имеют более гибкий инструментарий: можно развивать язык итеративно, сохраняя ядро и наращивая функциональность.
В сумме, MOF 3 делает разработку DSL более гибкой и мощной. Новые возможности (исполняемость, формальная верификация, богатые конструкции) идут рука об руку с устранением прежних ограничений. DSL-языки смогут точнее моделировать свои домены, а затраты на их создание и поддержку снизятся благодаря общему метаязыковому фундаменту.
3. Влияние на инструменты моделирования
Изменения в MOF напрямую затрагивают экосистему инструментов, которые реализуют хранение и редактирование моделей (CASE-средства, фреймворки типа Eclipse EMF, средства моделирования вроде MagicDraw, Sparx EA и др.). Разработчикам таких инструментов важно учитывать следующее:
Поддержка новой метамодели (MOF 3). Инструментам придётся эволюционировать вместе со стандартом. Репозитории моделей (например, ECore в Eclipse EMF, основанный на EMOF) должны быть совместимы с новыми концепциями MOF 3. Возможно, придётся расширить метаданные в хранилище: например, поддержать новые типы отношений или семантические элементы. Инструменты, рассчитанные на MOF 2, могут не знать о концепциях вроде многоуровневой классификации или встроенных семантических библиотек. Разработчикам придётся обновить метамодельные API: к примеру, добавить обработку новых свойств метаклассов, поддержать Serialisierung моделей с учётом обновлённого XMI/JSON формата и т.д. Это обратная совместимость: желательно обеспечить чтение старых моделей MOF 2.5.1, но при этом внедрить возможности MOF 3 для новых моделей.
Новые механизмы расширения моделей. Инструменты моделирования должны реализовать работу с библиотеками моделей и модульным расширением языка. Если раньше инструмент поддерживал применение UML-профилей (т.е. мог назначать стереотипы элементам), то теперь нужно поддерживать другой подход. Разработчикам инструментов важно предусмотреть функциональность для подключения/отключения библиотек метамодели: пользователь может добавить в свой проект определённую модель-библиотеку, обогащающую метамодель новыми элементами. Внутри репозитория это должно отражаться как новые метаклассы, связанные с базовыми. Например, SysML v2 реализован как расширение KerML: инструмент, поддерживающий SysML v2, фактически загружает метамодель KerML + библиотеки SysML
nemo.inf.ufes.br
nemo.inf.ufes.br. Аналогично, любой DSL на MOF 3 может состоять из ядра и доп. библиотек. Инструменты должны гибко работать с такими составными метамоделями. Для разработчиков это новый режим — динамическая расширяемость метамодели во время выполнения инструмента.
Поддержка текстовых нотаций и семантики. Тенденция нового поколения языков (SysML v2, вероятно UML 3) – наличие текстового синтаксиса наряду с графическим
nemo.inf.ufes.br
. SysML v2, например, предоставляет текстовый язык выражений и объявлений моделей, полностью эквивалентный диаграммам. Инструменты моделирования, ориентированные только на графический ввод (drag-and-drop диаграммы), рискуют отстать. Разработчикам следует интегрировать текстовые редакторы DSL-языка, синхронизированные с моделью. Это требует парсеров, подсветки синтаксиса, автодополнения – фактически превращает CASE-средство в гибрид IDE для моделей. Кроме того, раз семантика теперь часть модели, инструменты могут предложить новые функции: проверка ОCL-правил на лету, выполнение моделей или их частей (например, запуск статического анализа или симуляции прямо в модельном редакторе). Это повышает ценность инструмента: помимо рисования диаграмм он становится средством отладки моделей. Однако и усложняет его разработку – потребуется встроить движки логического вывода, интерпретаторы действия (Alf) и т.п. (или интегрироваться с ними).
Совместимость с существующими моделями и инструментами. Переход к MOF 3 означает, что существующие инструменты нужно доработать, но важно не потерять наработанные модельные базы. Разработчикам инструментов придётся обеспечить миграцию: например, импортер UML 2/MOF 2 моделей в новый формат. Возможно, на некоторое время придётся поддерживать оба стандарта параллельно (например, инструмент может иметь режим совместимости UML 2/MOF 2.5 и режим UML 3/MOF 3). Это затрагивает хранилища (форматы файлов XMI, базы данных моделей) – они должны уметь хранить новые поля, не «ломая» старые модели. В идеале, OMG предоставит рекомендации по миграции метамоделей, но реализацию её придётся делать каждому вендору.
Производительность и масштабируемость. Добавление семантики и усложнение метамодели могут сказаться на производительности инструментов. Хранить больше информации (например, элементы Semantic Library, экземпляры исполняемых элементов) – значит оперировать более нагруженным графом объектов. Инструментам, особенно рассчитанным на большие модели, нужно оптимизировать ядро: возможно, внедрить отложенную загрузку семантических данных, компиляцию OCL в исполняемый код для быстрого выполнения и т.д. Разработчики должны учесть, что модели станут богаче, и протестировать свои репозитории и рендеринг на новые сценарии.
Новые интеграции и стандарты. MOF 3 тесно увязан с другими стандартами (как KerML, SysML2, будущий UML3). Инструменты, претендующие на полноценную поддержку MBSE (Model-Based Systems Engineering), будут вынуждены реализовать поддержку SysML 2, UAF 2, а они в свою очередь опираются на новые основы. Например, UAF (Unified Architecture Framework) уже планирует миграцию на SysML 2/MOF 3 связку
gsaw.org
. Это означает, что инструментарий архитектурного моделирования, требований и пр. тоже обновится. Разработчики инструментов должны следить за развитием смежных спецификаций: возможно, придётся обновлять не только ядро MOF, но и плагины/модули для конкретных профилей (которые станут библиотеками). Интеграция с внешними системами (например, генерирование кода, обмен данными) тоже меняется: новый XMI или JSON-шема, новая API для доступа к модели (вместо старого JMI). Всё это требует проактивного планирования, обучения команды и, вероятно, участия в OMG FTF (Finalization Task Force) – чтобы понимать тонкости стандарта до его финального выхода.
В целом, инструменты моделирования ждёт значительный апгрейд. Те, кто его успешно реализуют, получат преимущество: смогут поддерживать современные стандарты (SysML 2, UML 3 и др.), предлагая пользователям более мощные функции моделирования. Те же, кто проигнорирует MOF 3, рискуют остаться на обочине с устаревшими технологиями. Поэтому разработчикам CASE-средств важно уже сейчас экспериментировать с бета-версиями новых стандартов, проверять свои метамодельные движки на совместимость и планировать выпуск обновлений синхронно с появлением MOF 3.
4. Связь MOF 3 и KerML
Стандарт KerML (Kernel Modeling Language) и MOF 3 тесно связаны, хотя находятся на разных уровнях архитектуры моделирования:
Разные уровни метамоделирования. MOF – это метаязык самого верхнего уровня (M3 в четырехуровневой модели OMG), на котором определяются метамодели языков. KerML – это ядро языка моделирования (уровень M2), то есть конкретная метамодель, созданная (как и UML или SysML) на основе MOF. Проще говоря, KerML – это «пример» языка, определённого с помощью MOF 2.5.1/3.0. В спецификации явно указано, что абстрактный синтаксис KerML задан UML-моделью, соответствующей CMOF (Meta-Object Facility)
omg.org
. Таким образом, KerML реализует принципы MOF: все его метаклассы – экземпляры метамета-классов MOF.
KerML как предвестник MOF 3. Хотя формально KerML = M2, опыт его разработки повлиял на эволюцию MOF. SysML 2 (язык для системной инженерии) был разработан командой SST на основе KerML, и этот проект продемонстрировал, какие улучшения требуются от инфраструктуры моделирования. В частности, KerML реализовал разделение на слои (Root/Core/Kernel) и включил библиотеку формальной семантики (Semantic Library)
nemo.inf.ufes.br
nemo.inf.ufes.br. Эти решения показали свою эффективность и, фактически, заложили требования для MOF 3. OMG прямо указывает, что SysML 2.0 (в котором KerML – базовая часть) становится драйвером для будущих UML 3.0 и MOF 3.0gsaw.org. Иначе говоря, KerML можно рассматривать как референсную модель, на основе которой формируются новые версии MOF/UML. Многие идеи KerML (например, единое ядро для разных DSL, явное описание семантики, гибкие связи между классификаторами и характеристиками) вероятно найдут отражение в MOF 3 на концептуальном уровне.
KerML зависит от MOF, но не заменяет его. Важно понимать, что KerML – не «новый MOF», а прикладной метамодельный язык, созданный с помощью MOF. KerML предназначен для повторного использования в специализированных языках
nemo.inf.ufes.br
. Например, SysML 2 – это KerML + расширения для системной инженерии, UML 3 может быть KerML + расширения для общего моделирования программного обеспечения. Сам же KerML нуждается в метаязыке (MOF) для своего определения. На данный момент KerML описан с помощью MOF 2.5.1omg.org, но по сути он уже учёл многие возможности, которые MOF 3 стремится стандартизировать. Можно сказать, KerML – это конкретизация принципов MOF 3 в виде универсальной ядровой метамодели. Однако область применения KerML – создание новых языков (семейств языков) на его основе, тогда как MOF 3 – общий фундамент, на котором могут быть построены и KerML, и любые другие метамодели.
Совместное использование. KerML и MOF 3 не конкурируют, а дополняют друг друга. MOF 3 задаёт абстрактные конструкции метамоделирования (как описывать классы, свойства, ассоциации, операции, ограничения и т.д.), а KerML предлагает набор основных понятий моделирования, полезных практически во всех языках (элементы, отношения, типы, атрибуты, действия, конструкции поведения и др.). В связке это даёт мощный результат: разработчики могут воспользоваться KerML как готовым “каркасом” языка, а при необходимости расширить его, оставаясь в рамках MOF. Таким образом, KerML можно рассматривать как стандартную библиотеку для конструирования языков на основе MOF 3. Формально KerML сам станет стандартом OMG (уже выпущен Beta-стандарт KerML 1.0), и его спецификация будет сосуществовать рядом с MOF 3. Их связь аналогична связи UML и MOF: UML — метамодель (M2), MOF — метаязык (M3). Только в случае KerML/UML 3, KerML претендует на роль универсального ядра, от которого будут наследоваться и UML 3, и SysML 2, и другие языки.
Отличия роли KerML от MOF. MOF 3 продолжит обеспечивать совместимость и интеграцию на самом высоком уровне: все модели, созданные по стандартам OMG, будут по-прежнему MOF-совместимы (это своего рода “XML схемы” мира моделей). KerML же обеспечивает совместимость на уровне смысловых элементов моделей. К примеру, если и UML 3, и SysML 2 будут основаны на KerML, то они будут разделять единый понятийный аппарат (понятие Classifier, Property, Relationship и т.п. будет у них общее). Это облегчит трансформацию моделей между языками, объединение моделей разных типов в одной репозитории и т.д. Можно сказать, MOF 3 + KerML вместе создают более цельную экосистему: MOF 3 – техническое единообразие метамоделирования, KerML – семантическое единообразие базовых понятий.
Вывод: KerML является первым практическим воплощением идей, заложенных в будущий MOF 3, и служит мостом между существующей инфраструктурой MOF 2.5.1 и новыми потребностями моделирования. MOF 3 формализует на мета-уровне те принципы, которые KerML демонстрирует на уровне языка. В перспективе KerML станет фундаментом для многих MOF 3-совместимых языков, включая UML 3, позволяя добиться большей унификации и согласованности в мире моделирования. Таким образом, KerML и MOF 3 находятся в отношениях «язык и его основа»: один не заменяет другой, а вместе обеспечивают развитие технологий моделирования на новое качество.
gsaw.org
nemo.inf.ufes.br
