vvagr, avlasov и algebraic_brain (сразу оговорюсь: тему нотации сетей Петри для представления кодов логической парадигмы я из цитируемого ниже выкосил, это предмет отдельных размышлений).Я написал:
... 24744 аккуратно обходится с "видами чего-то" и "моими чем-то", в этом плане заезжая на территорию онтологических языков. Проблема неизбежности и желательности заезда UML-подобных языков "моделирования" на "онтологическую" территорию обсуждается, например, в http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119 и http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119. Такая аккуратность позволяет схему базы данных и сами данные хранить в одной и той же persictance.
А вот как моделировать это, не теряя вычислимости -- это вопрос интересный.
... [это задает] постановку задачи для полууниверсального моделера: нужно иметь моделер, покрывающий полянку как моделирования с ее удобством записи, так и онтологическую полянку с ее формальностью и выразительностью.
... Полностью же универсальный моделер будет тогда, когда разберемся с мультипарадигмальностью (ОО, логическая, функциональная, императивная/стековая и т.д. парадигмы в одном флаконе).
avlasov ответил:В той постановке задачи что писал Анатолий, на самом деле, смешано несколько разных (конкретных) процессов моделирования, для которых нужны, вообще говоря, разные моделеры. Что и вызывает у меня непонимание.Я в ответ на это:
Т.е. понятно, что Вы хотите работать с 15926.
Также понятно, что Вам нужно закодировать 24744 в нотации совместимой 15926.
Вопрос, что потом с этим закодированным 24744 в 15926 делать?
Т.е. вообще говоря, задача просто кодирования решается с помощью Протеже. Ибо есть отображение 15926:2 в OWL. Следовательно, можно забить 24744 как онтологию OWL, состоящию из концепций (TBox) из 15926:8 и инстансов (ABox) 24744. Другими словами, на выходе будет OWL база знаний, в которой концепты взяты из 15926:8, а индивиндуалы соответствовуют понятиям 24744.
Подобной цели можно достичь и с помощью темплейтов, т.е. например, просто забить текстовые файлы в текстовой нотации 15926:7.
Понятно, однако, что кодировка не есть само-цель, и она нужна для дальнейшей работы.
Также понятно, что кодирование 24744 есть пример, и что вообще говоря предполагается систему использовать для других целей.
Вот эти два пункта уже понятны смутно. Ну из общих соображения ясно, что хочется рисовать картинки, ну и использовать закодированную 24744 как онтологию для инстансов этой метамодели. Т.е. в последнем случае надо совершить метапереход, и инстансы 24744 в вышеупомянтой OWL онтологии, сконверить например в OWL онтологию (точнее TBox), а в этой онтологии забить инстанс метамодели 24744 как ABox.
Хуже того, насколько я понял, инстанс метамодели 24744 сам по себе является моделью какого-то процесса, т.е. у него тоже могут быть инстансы :). Т.е. нужно опять таки инстанс мета-модели 24744 сконвертить из ABox в TBox, а для него уже забивать какие-то конкретные артефакты процесса.
Т.е. если я правильно понял, 15926 выступает как мета-мета-модель для мета-модели 24744, которая задает какие-то модели процессов, у которой опять таки могут быть инстансы :).
Т.е. тут примерно 2 или три процесса моделирования, причем не понятно, какие будут делаться часто, какие редко, кем, как и т.д. и т.п.
ЗЫ Кстати, я именно поэтому утверждаю что для системной инженерии нужно юзать HOL, потому что там все эти мета-мета-мета- отображаются гораздо естественнее, без всеразличных заморочек с перекодированиями, трансформациями и прочими мета-переходами.
Да, там совершенно разные endeavour моделирования -- которые на практике существенно пересекаются друг с другом (при встреченных трудностях в кодировании какой-то модели немедленно идет перескок на метауровень).А теперь добавлю про концепцию мегамоделей, развиваемую Jean Bezivin из INRIA ATLAS team. Еще в декабре 2004г. он замечал (http://jbezivin.blogspot.com/2005/10/every-metamodel-is-treaty.html)
Как я понимаю, выбор ISO 15926 связан в том числе и с тем, что результаты всех этих моделирований представлены в едином репозитории -- ибо это Онтология, в которой есть как знания о классах, так и сведения об эземплярах.
Если получается так много "перекодирований", то все они должны быть "под капотом" -- невидимы, спрятаны за нотациями ...
Еще один вопрос: как научить пользователей (которых на этой этажерке "мета-" будет больше одного) аккуратно работать на этих уровнях и не путаться? Ведь не хочется плодить разные DSL и нотации для каждого из этих метауровней...
There are very narrow relations between DSLs, Metamodels and Ontologies. Many lessons from ontology engineering are of relevance to model-driven engineering. This is why it may be interesting to read a recent paper by Tom Gruber, one of the most influential researcher in ontology engineering. As a matter of fact, Tom Gruber may be considered as one of the founders of modern ontology. He gave the first definition of an ontology that has been quoted since then times and times: "An ontology is a shared formal specification of an abstraction". As we know, this could as well be taken as a concise defintion for a metamodel.В последние годы он сформулировал про все это "мета-" в терминах моделирования-в-большом, отойдя от онтологического описания -- начиная со статьи 2004г. в соавторстве с Frédéric Jouault и Patrick Valduriez "On the Need for Megamodels" -- https://gforge.inria.fr/scm/viewvc.php/*checkout*/Publications/Before2009/bezivin-megamodel.pdf?root=atlantic-zoos
So, after a long time working in the field, Tom Gruber recently delivered again a new strong message: "Every ontology is a treaty".
http://www.sigsemis.org/newsletter/october2004/tom_gruber_interview_sigsemis
Мегамодель (megamodel) -- основной строительный блок для моделирования-в-большом (modeling in the large). Принцип: для каждой сложной системы или процесса в реальном мире может существовать мегамодель, представляющая различные вовлеченные рабочие продукты-модели (тут я начинаю прихватывать терминологию ISO 24744: по факту metamodel отсюда -- это language из ISO 24744, а artefact -- work product) и их отношения указанием относящихся к ним метаданных (типов моделей и отношений между ними, идентификаторов, места хранения и т.д.).
Развитие этих идей можно увидеть вот на страничке Global Model Management -- http://www.emn.fr/z-info/atlanmod/index.php/Global_Model_Management. Почему-то на этой страничке идея megaprogramming относится Boehm и Sherlis 1992, хотя в начальной статье по предыщущей ссылке говорится, что идея была взята из Deremer и Kron "программирования-в-большом", датированной 1976 годом.
Особо замечу, что еще в 2004 году у них при обсуждении платформы-инструментов-сервисов идет прямая отсылка к сервис-ориентированной архитектуре (хотя и в терминологии еще тех лет: CORBA и UDDI, а не какой-нибудь REST, как это было бы сегодня). Ибо работа с мегамоделью нужна не столько для того, чтобы "просто разобраться", сколько для того, чтобы создать инструменты для работы с мегамоделью -- а там, где инструменты, там появляется инструментальная платформа и нужны средства для ее описания, т.е. нужна SOA.
То, что предлагается в ISO 15926 -- это, безусловно, отражение именно этого подхода к мегамодели, хотя и задающееся совсем в другом языке. Характерная черта ISO 15926 -- это "классы классов", работа с экземплярами и классами в одной системе, одновременная поддержка множества связанных OIM. Я думаю, что "онтологический" подход в силу его общности правилен, но туда можно в существенной степени заимствовать терминологию megamodel и прочие концепции (и соответствующие им термины), развиваемые в группе INRIA ATLANMOD (http://www.emn.fr/z-info/atlanmod/index.php/Main_Page) в их проекте Global Model Management (сводящемуся к управлению конфигурацией мегамодели): https://gforge.inria.fr/scm/viewvc.php/*checkout*/Publications/2009/TypingInGMM_preliminary.pdf?root=atlantic-zoos.
Статья по последней ссылке как раз разбирает типизацию моделей в этих мета- и мега-модельных нагромождениях, т.е. пытается внести какую-то определенность в структуру мегамодели. Фишка в том, что типизируются не только сами модели, но и отношения между ними (например, "модель А получена компиляцией/трансформацией модели B компилятором C"). Интересно, что эмуляция системы типов сначала была сделана на System Coq (http://www.lix.polytechnique.fr/coq/ -- formal proof management system, система управления формальными доказательствами. По сути, еще одно "управление": управление доказательствами, proof management).
Итого, у нас есть несколько источников для содержательного и терминологического разбирательства с зоопарком длинных цепочек мета-мета-мета- для моделей и преобразований/порождений (transformation/generation) моделей, использующихся в инженерии:
-- ISO 42010 про архитектурные описания, который просто про то, что есть много моделей, и требует задавать для них методы описания (включающие метамодели, нотации и т.д.)
-- ISO 24744, который поддерживает главным образом разговор о моделеориентированной деятельности, но не позволяет подробно разобраться с самими моделями. Зато там явно говорится еще и о нотациях и документах, а не только о самих моделях.
-- традиционный мир CAD/PLM (крайне непроработанный: терминология "схемы", "индивидуальных АРМ", "репозитория" и путаница между инструментами и поддерживающимися ими моделями ввиду отсутствия стандартизации и полностью закрытой терминологии, используемой разработчиками софта этих мегамодельных платформ)
-- ISO 15926, в котором про OIM пока почти ничего не известно, нотациями там не озабочены, зато представимы метамодельные (онтологические) этажерки классов и экземпляров в форме, достаточной для оперирования и хранения, плюс задается какой-то минимальный набор готовых классов из промышленных стандартов.
-- подход Global Modeling Management с его понятием мегамодели и типизацией моделей и преобразований
-- SOA, подползающая со стороны "платформ", "инструментария" и необходимости указания продуктов работы для входов-выходов сервисов
-- Simantics, который пытается сделать что-то подобное с симуляционными моделями
-- суперкомпиляторщики, которым потребовалось создать собственную терминологию для всевозможных мета-, существующих в их работе
-- люди из vpri.org, которые пытаются сделать лаконичную среду для языкового моделирования (компиляторщики), и прочие люди из мира language workbenches (застрявшие между компиляторщиками и моделировщиками)
-- ... <что-то забыл важное? Подсказывайте!>