Моделирование: "типовые описания", аналитическое и имитационное, порождающее
Виктор Батоврин в своей презентации в Светлогорске указал на такой тренд, как по мере перехода к рассмотрению сверхсложных систем "ограниченное применение традиционных методов аналитического и имитационного моделирования с одновременным повышением роли эталонных моделей". Я хотел бы с этим поспорить.
Аналитическое моделирование -- это от "математического анализа", совокупности разделов математики, посвященных исследованию функций и их обобщению методами дифференциального и интегрального исчислений, включая теорию рядов (функциональных, степенных и Фурье рядов), и исследование векторных (отображение одного вектороного пространства в другое) и скалярных (функции на векторном пространстве) полей.
Имитационное моделирование -- это emulation и simulation, которые имеют чуть разные смыслы. Emulation -- это "копирование", "имитирование" поведения одной системы другой системой (компьютерный икс "притворяется" реальным игреком, пытаясь повторить его полностью и аутентично http://en.wikipedia.org/wiki/Emulator), а вот simulation -- это попытка изобразить абстрактную модель, как реальную вещь (то есть компьютерный икс пытается отобразить одно или несколько избранных свойств возможно даже несуществующего игрека). Можно сказать так, что simulation -- это аппарат "априорной" науки, когда из какой-то теории пытаются вывести поведение какой-то системы.
Я не согласен с тем, что аналитическое и имитационное моделирование уменьшают сегодня свою роль. Мне кажется, что прогресс в методах аналитического и имитационного моделирования стремительно расширяют границы применимости этих имитационных и даже эмуляционных моделей (см., например, Roadmap по моделированию мозга: http://www.fhi.ox.ac.uk/Reports/2008-3.pdf). Основные проблемы тут не в том, что "методы моделирования неприменимы", а в совсем других вопросах:
-- для каких целей используются модели (например, Анри Ги утверждает, что в Shell методы моделирования никак не повышали качества принимаемых решений, но втрое повышали скорость их принятия за счет того, что менеджеры быстрее начинали понимать, о чем вообще нужно думать. Я писал о таком моделировании, как о "скороварке" -- вкус, цвет и питательность продукта не меняется, выигрыш только в скорости, проигрыш в "освоении технологии".
-- использование продвинутой символьной математики в компьютерах. Средства символьного моделирования из дорогой научной экзотики становятся относительно дешевым "ширпотребом" (взять хотя бы wolfram Alfa), и это явно способствует, а не ограничивает распространение этих методов. Можно указать также на наметившийся тренд в соединении символьных и аналитических моделей: это произошло для практически всех лидеров рынка. Проблема тут в том, что массовый уровень математической подготовки людей не так высок, чтобы задействовать открывающиеся возможности, но это можно сказать про практически любую отрасль знаний: высшие достижения в любой отрасли знаний сначала очень трудно повторить, и только существенно позже находятся способы быстрого обучения.
-- спецязыки аналитического моделирования (типа Modelica, http://www.modelica.org/) и связанная с ними стандартизация моделей. Стандартизация моделей приводит к тому, что стандартные модели легче вставлять в САПР и другие приложения (http://www.modelica.org/tools). Стандартизация приведет не к уменьшению использования аналитических моделей, а наоборот: к применению их даже там, где их применять избыточно.
-- огромная проблема в комплексировании разных типов моделей (см., например, http://ailev.livejournal.com/673824.html и http://ailev.livejournal.com/675208.html). Эта онтологическая проблема совмещения знаний, основанных на разных картинах мира, является сейчас ключевой.
Так что никакого "заката" аналитического и имитационного моделирования не наблюдается, наоборот -- сплошной восход, причем очень стремительный. То, что социальные системы перестали считать похожими на физические и моделировать их дифурами, я не считаю "ограничением" -- выправления этого коленвала давно ждали. Просто для моделирования социальных систем применяются другие методы, нежели статистические (например, модель рабочего процесса, записанная на BPMN 2-- это именно модель, но она явно не относится к "традиционным" или "эталонным". Или модели DEMO, в которых явно предусматривается "выход в дискурс" по поводу вида модели процесса и распределения в нем ролей -- это не имитационные модели, и не "эталонные модели", это другие модели, о которых речь чуть позже).
Конечно, моделировать сверхсложные системы человечество еще не умеет. Любые виды моделей для сверхсложных систем носят ограниченный характер. Но единственный способ, которым вчерашние сложные системы сегодня становятся простыми, а сверхсложные просто сложными -- это как раз моделирование, роль которого во всех его многочисленных ипостасях только "неуклонно возрастает", невзирая на все оговорки про ограниченность их применения только осмысленными случаями.
Развиваются сейчас все виды моделирования, слово "модель" при этом стремительно омонимизируется, границы применимости буквально всех видов моделирования растут, границы между разными видами моделирования размываются, и говорить о "повышении роли" можно только как о "более стремительном повышении" по отношению к "стремительнейшему повышению".
Тезис о "повышении роли эталонных моделей" хотелось бы откорректировать прежде всего с терминологической точки зрения. Как я понимаю, речь идет о неформальных описаниях типа process reference model (каковым описанием является, например, набор практик жизненного цикла ISO 15288). Я рекомендую переводить такие reference model как "типовые описания". Да, таких "типовых описаний" становится много -- но я бы остерегся говорить о них именно как о "моделях". Кресты металлические, кресты католические -- нельзя путать. Гена Лебедев как-то ходил по коридору гостиницы в г.Находка и приставал ко всем: "Дайте мне любой договор -- хотя бы договор на продажу кошки, и я из него сделаю договор на продажу опциона!". Ага, "типовой договор" -- это именно что reference model. "Рыба", или в Украине -- "коза" документа. Типовое описание того или сего: можно назвать это "эталонной моделью", но зачем?! Да, онтологию и архитектуру можно задать неформальным "типовым текстом", но я бы не назвал это "повышением роли эталонных моделей".
Структурированные сборники "лучших практик" или даже "хороших практик" (какие же они "лучшие", ежели их применяют все, кому не лень! "лучшие" -- это которые уже лучше, чем эти застандартизированные "хорошие") типа ITIL, или PMBoK или CMMI, или даже ISO15288, а также всевозможные метамодели для enterprize achitecture типа ORM-ODP, захмановщины или FEA -- это нормальные неформальные описания, и говорить о них, как о "моделях" (подразумевающих все-таки "исполнение", "приведение в действие для получения ответа на вопросы") мне представляется неправильным. Ну, или слово "модель" для этого используется совсем в другом смысле слова -- "автомобиль модели Ford T", "обувь модельного ряда 2009г.", "фотомодель". Структурированное изложение чего-то "типового" является, конечно, "моделированием" в самом широком смысле этого слова, но я бы все-таки сравнил это с использованием слова "проект" в музыкальной промышленности: "проект продюсера Пупкина "Запевайки" добился успеха таким своим проектом, как альбом "Отпевайка", и проект "Выпевайка" турне "Запеваек" с "Отпевайкой" по ближнему подмосковью вчера был представлен Пупкиным поклонникам его проекта". Ничего специального и особенного в reference models я не усматриваю. Не будем же мы назвать модным словом reference model "ассортиментный минимум товаров" или "ассортиментный минимум услуг", хотя по смыслу это ровно то самое?
Если речь идет не о неформальных описаниях, а формальном языке моделирования, "модели модели", то тут чаще говорят не о reference model, а о metamodel. Так, SPEM -- это не reference model для инжиниринга практик и жизненных циклов, а именно что metamodel.
Но об "опережающем повышении роли" каких моделей я бы говорил и выпячивал как (уже даже несвежий) тренд, так это о формально-языковых "порождающих" (generative) моделях. Я бы их так же назвал эээ... архитектурными, или эээ... абстрактносинтаксическими, хотя их использование не сводится к выражению архитектуры или "абстрактного синтаксиса" выражаемых эээ... явлений. В этих моделях речь идет прежде всего о самоценности возможности формального многостороннего описания системы, каковое описание породит затем детальное описание, достаточное для верификации, валидации и (главное!) реализации системы.
Важно иметь возможность формальной записи архитектурного описания. Важно иметь возможность формальной записи требований к системе. А потом запустить аппарат "порождения" (трансформации, интерпретации, компиляции, "вычислений" в общем виде -- не сводящимся к математическим символьным или численным). Это и имеется ввиду, когда говорят о "моделецентричном" подходе в отличие от "безмодельного" подхода, где порождение делается не из явной формальной модели, а прямо "из идеи в голове" -- безо всякой выписанной архитектуры или письменных требований прямо из головы в код, из головы в чертеж.
Эти языковые модели представляют собой некоторый текст (часто с несколькими альтернативными текстовыми и графическими нотациями), который затем рассматривается как текст на "языке программирования", т.е. "исполняется" ("интерпретируется", "трансформируется") некоторым специальным заранее определенным образом. Сюда в полной мере относится использование SysML для моделирования систем: нельзя утверждать, что тексты на SysML являются "эталонными моделями" или представляют собой эмулятор системы, или они имитационно моделируют систему (хотя желание, чтобы это было так, ярко выражено). Тексты на SysML представляют собой "требования" (включая логическую и физическую архитектуру, тоже относимые к "требованиям").
Первый шаг для таких моделей -- это сама возможность многостороннего "логически-архитектурного" описания системы на формальных языках, структурированного описания требований к системе. На этом первом шаге ни о каком "порождении" более детальных описания (например, кода для софта, или рабочих чертежей для железа, или инструкций оператора для людей) речи еще не идет. На этом шаге главная задача -- выбор ряда подходящих рабочих онтологий для многостороннего описания, а также выразительных нотаций, облегчающей составление и чтение таких описаний многочисленными заинтересованными сторонами. "Модели для понимания и коммуникации", на знамени которых стоит самый успешный пример UML-моделирования. Ключевым для успеха UML было озарение: "одного типа диаграмм не хватает". В результате использование UML для архитектурной деятельности (arhitecting) стало обыденным.
Второй шаг -- это возможность "порождения" (интерпретации, "вычисления", или как говорят компиляторщики "выполнения в особом смысле записи на языке программирования" -- получение из высокоуровневого кода низкоуровневого кода/чертежей, и передача их на "реализацию" путем "исполнения", "показа", или даже "изготовления в железе"). Для этого часто вносятся изменения в "универсальные языки моделирования", используемые на первом шаге (например, так из UML появлялись "исполняемый" xUML и "трансформируемый" UMLX). В этом плане "порождающее моделирование" практически сливается с "программированием" и "проектированием".
Третий шаг -- это озарение: "заранее предписанных видов диаграмм не хватает". Отсюда расширяемость UML (вниз-вбок через MOF, и вверх-в-стороны через "стереотипы"), а также гениальная догадка, что UML со стереотипами не похож на удобный для непрограммистов язык моделирования. Для непрограммистов удобным языком моделирования является их привычный DSL, а если хочется сделать несколько тематических узкопрофессиональных групп описаний (view) с использованием разных методов описания (viewpoint), то разные потребные DSL можно заставить "ожить" (т.е. иметь возможность их "исполнить", или на их основе "породить" низкоуровневые описания) путем использования общей "основы" (как MOF для разных диграмм UML) и специального входящего в состав языка IDE (тоже не новая идея: Smalltalk определялся неразрывно с IDE, а не просто как "текст с синтаксисом"). Martin Fowler назвал такие мультиDSL-IDE "language workbenches" (http://martinfowler.com/articles/languageWorkbench.html), а я -- "языковыми капищами", http://ailev.livejournal.com/683311.html).
В наиболее современном виде этот класс "порождающих" моделей развивается сейчас в таких инициативах, как OMG MDA (http://www.omg.org/mda/) и различных инициативах language workbenches (Intentional Software, JetBrains MPS, MetaEdit etc. -- http://martinfowler.com/bliki/IntentionalSoftware.html), а также в онтологических САПР (где множество различных представлений одного и того же объекта объединяются в единую модель на базе "схемы" -- линейки разных специализированных САПР, поддерживающих ISO15926 в качестве основы для общего репозитория модели, см., например, http://www.bentley.com/en-US/Products/OpenPlant+PowerPID/).
Эти "порождающие модели" нельзя назвать "эталонными" ни в каком смысле (разве что вспомнив одно из определений архитектуры -- "описание, удовлетворяющее целому классу применений, целому классу реализаций, а не одному экземпляру системы"), но эти модели не являются и классическими "математическими моделями" в том плане, что по ним не проводится численного анализа. К математическим моделям "символического анализа" я бы тоже эти модели не относил (хотя за уши принятуть, конечно, можно: математика ведь настолько обща, что под ее крышу можно затянуть все что угодно).
"Порождающее моделирование" является сейчас лидером, именно о нем говорится в "моделецентричной" системной инженерии (а не об имитационном моделировании: хотя "запуск на исполнение" порожденного по модели кода может привести в том числе и к имитационному расчету, не вопрос). Моделецентрическая системная инженерия -- это сегодня использование специализированных САПР (САПР -- это же, что софтовое IDE, только для "некомпьютерного железа"), поддерживающих именно что множество DSL для разных специальных инженерий (например, диаграммы P&ID), но в общей интерактивной среде разработки (interactive development environment, IDE) над объединенной общей для всех "специальностей" датацентричной моделью, хранящейся в репозитории.
Системная инженерия ждала 10 лет, когда "многодиаграммное универсальное описание" в UML перешло из программной инженерии в системную инженерию в варианте SysML. Не нужно ждать 10 лет, чтобы сообразить сделать то же самое для тренда, обобщающего "многодиаграммный принцип" до ситуации multiDSL в рамках language workbenches или "много САПР вокруг одного репозитория". Можно думать о том, как сделать "универсальную систему автоматизации проектирования" на базе моделецентричности так же, как десять лет назад думали об "универсальной системе моделирования" для софта -- и породили высоко кастомизируемые Rational Rose, Objecteering, Artisan Studio и т.д.
Аналитическое моделирование -- это от "математического анализа", совокупности разделов математики, посвященных исследованию функций и их обобщению методами дифференциального и интегрального исчислений, включая теорию рядов (функциональных, степенных и Фурье рядов), и исследование векторных (отображение одного вектороного пространства в другое) и скалярных (функции на векторном пространстве) полей.
Имитационное моделирование -- это emulation и simulation, которые имеют чуть разные смыслы. Emulation -- это "копирование", "имитирование" поведения одной системы другой системой (компьютерный икс "притворяется" реальным игреком, пытаясь повторить его полностью и аутентично http://en.wikipedia.org/wiki/Emulator), а вот simulation -- это попытка изобразить абстрактную модель, как реальную вещь (то есть компьютерный икс пытается отобразить одно или несколько избранных свойств возможно даже несуществующего игрека). Можно сказать так, что simulation -- это аппарат "априорной" науки, когда из какой-то теории пытаются вывести поведение какой-то системы.
Я не согласен с тем, что аналитическое и имитационное моделирование уменьшают сегодня свою роль. Мне кажется, что прогресс в методах аналитического и имитационного моделирования стремительно расширяют границы применимости этих имитационных и даже эмуляционных моделей (см., например, Roadmap по моделированию мозга: http://www.fhi.ox.ac.uk/Reports/2008-3.pdf). Основные проблемы тут не в том, что "методы моделирования неприменимы", а в совсем других вопросах:
-- для каких целей используются модели (например, Анри Ги утверждает, что в Shell методы моделирования никак не повышали качества принимаемых решений, но втрое повышали скорость их принятия за счет того, что менеджеры быстрее начинали понимать, о чем вообще нужно думать. Я писал о таком моделировании, как о "скороварке" -- вкус, цвет и питательность продукта не меняется, выигрыш только в скорости, проигрыш в "освоении технологии".
-- использование продвинутой символьной математики в компьютерах. Средства символьного моделирования из дорогой научной экзотики становятся относительно дешевым "ширпотребом" (взять хотя бы wolfram Alfa), и это явно способствует, а не ограничивает распространение этих методов. Можно указать также на наметившийся тренд в соединении символьных и аналитических моделей: это произошло для практически всех лидеров рынка. Проблема тут в том, что массовый уровень математической подготовки людей не так высок, чтобы задействовать открывающиеся возможности, но это можно сказать про практически любую отрасль знаний: высшие достижения в любой отрасли знаний сначала очень трудно повторить, и только существенно позже находятся способы быстрого обучения.
-- спецязыки аналитического моделирования (типа Modelica, http://www.modelica.org/) и связанная с ними стандартизация моделей. Стандартизация моделей приводит к тому, что стандартные модели легче вставлять в САПР и другие приложения (http://www.modelica.org/tools). Стандартизация приведет не к уменьшению использования аналитических моделей, а наоборот: к применению их даже там, где их применять избыточно.
-- огромная проблема в комплексировании разных типов моделей (см., например, http://ailev.livejournal.com/673824.html и http://ailev.livejournal.com/675208.html). Эта онтологическая проблема совмещения знаний, основанных на разных картинах мира, является сейчас ключевой.
Так что никакого "заката" аналитического и имитационного моделирования не наблюдается, наоборот -- сплошной восход, причем очень стремительный. То, что социальные системы перестали считать похожими на физические и моделировать их дифурами, я не считаю "ограничением" -- выправления этого коленвала давно ждали. Просто для моделирования социальных систем применяются другие методы, нежели статистические (например, модель рабочего процесса, записанная на BPMN 2-- это именно модель, но она явно не относится к "традиционным" или "эталонным". Или модели DEMO, в которых явно предусматривается "выход в дискурс" по поводу вида модели процесса и распределения в нем ролей -- это не имитационные модели, и не "эталонные модели", это другие модели, о которых речь чуть позже).
Конечно, моделировать сверхсложные системы человечество еще не умеет. Любые виды моделей для сверхсложных систем носят ограниченный характер. Но единственный способ, которым вчерашние сложные системы сегодня становятся простыми, а сверхсложные просто сложными -- это как раз моделирование, роль которого во всех его многочисленных ипостасях только "неуклонно возрастает", невзирая на все оговорки про ограниченность их применения только осмысленными случаями.
Развиваются сейчас все виды моделирования, слово "модель" при этом стремительно омонимизируется, границы применимости буквально всех видов моделирования растут, границы между разными видами моделирования размываются, и говорить о "повышении роли" можно только как о "более стремительном повышении" по отношению к "стремительнейшему повышению".
Тезис о "повышении роли эталонных моделей" хотелось бы откорректировать прежде всего с терминологической точки зрения. Как я понимаю, речь идет о неформальных описаниях типа process reference model (каковым описанием является, например, набор практик жизненного цикла ISO 15288). Я рекомендую переводить такие reference model как "типовые описания". Да, таких "типовых описаний" становится много -- но я бы остерегся говорить о них именно как о "моделях". Кресты металлические, кресты католические -- нельзя путать. Гена Лебедев как-то ходил по коридору гостиницы в г.Находка и приставал ко всем: "Дайте мне любой договор -- хотя бы договор на продажу кошки, и я из него сделаю договор на продажу опциона!". Ага, "типовой договор" -- это именно что reference model. "Рыба", или в Украине -- "коза" документа. Типовое описание того или сего: можно назвать это "эталонной моделью", но зачем?! Да, онтологию и архитектуру можно задать неформальным "типовым текстом", но я бы не назвал это "повышением роли эталонных моделей".
Структурированные сборники "лучших практик" или даже "хороших практик" (какие же они "лучшие", ежели их применяют все, кому не лень! "лучшие" -- это которые уже лучше, чем эти застандартизированные "хорошие") типа ITIL, или PMBoK или CMMI, или даже ISO15288, а также всевозможные метамодели для enterprize achitecture типа ORM-ODP, захмановщины или FEA -- это нормальные неформальные описания, и говорить о них, как о "моделях" (подразумевающих все-таки "исполнение", "приведение в действие для получения ответа на вопросы") мне представляется неправильным. Ну, или слово "модель" для этого используется совсем в другом смысле слова -- "автомобиль модели Ford T", "обувь модельного ряда 2009г.", "фотомодель". Структурированное изложение чего-то "типового" является, конечно, "моделированием" в самом широком смысле этого слова, но я бы все-таки сравнил это с использованием слова "проект" в музыкальной промышленности: "проект продюсера Пупкина "Запевайки" добился успеха таким своим проектом, как альбом "Отпевайка", и проект "Выпевайка" турне "Запеваек" с "Отпевайкой" по ближнему подмосковью вчера был представлен Пупкиным поклонникам его проекта". Ничего специального и особенного в reference models я не усматриваю. Не будем же мы назвать модным словом reference model "ассортиментный минимум товаров" или "ассортиментный минимум услуг", хотя по смыслу это ровно то самое?
Если речь идет не о неформальных описаниях, а формальном языке моделирования, "модели модели", то тут чаще говорят не о reference model, а о metamodel. Так, SPEM -- это не reference model для инжиниринга практик и жизненных циклов, а именно что metamodel.
Но об "опережающем повышении роли" каких моделей я бы говорил и выпячивал как (уже даже несвежий) тренд, так это о формально-языковых "порождающих" (generative) моделях. Я бы их так же назвал эээ... архитектурными, или эээ... абстрактносинтаксическими, хотя их использование не сводится к выражению архитектуры или "абстрактного синтаксиса" выражаемых эээ... явлений. В этих моделях речь идет прежде всего о самоценности возможности формального многостороннего описания системы, каковое описание породит затем детальное описание, достаточное для верификации, валидации и (главное!) реализации системы.
Важно иметь возможность формальной записи архитектурного описания. Важно иметь возможность формальной записи требований к системе. А потом запустить аппарат "порождения" (трансформации, интерпретации, компиляции, "вычислений" в общем виде -- не сводящимся к математическим символьным или численным). Это и имеется ввиду, когда говорят о "моделецентричном" подходе в отличие от "безмодельного" подхода, где порождение делается не из явной формальной модели, а прямо "из идеи в голове" -- безо всякой выписанной архитектуры или письменных требований прямо из головы в код, из головы в чертеж.
Эти языковые модели представляют собой некоторый текст (часто с несколькими альтернативными текстовыми и графическими нотациями), который затем рассматривается как текст на "языке программирования", т.е. "исполняется" ("интерпретируется", "трансформируется") некоторым специальным заранее определенным образом. Сюда в полной мере относится использование SysML для моделирования систем: нельзя утверждать, что тексты на SysML являются "эталонными моделями" или представляют собой эмулятор системы, или они имитационно моделируют систему (хотя желание, чтобы это было так, ярко выражено). Тексты на SysML представляют собой "требования" (включая логическую и физическую архитектуру, тоже относимые к "требованиям").
Первый шаг для таких моделей -- это сама возможность многостороннего "логически-архитектурного" описания системы на формальных языках, структурированного описания требований к системе. На этом первом шаге ни о каком "порождении" более детальных описания (например, кода для софта, или рабочих чертежей для железа, или инструкций оператора для людей) речи еще не идет. На этом шаге главная задача -- выбор ряда подходящих рабочих онтологий для многостороннего описания, а также выразительных нотаций, облегчающей составление и чтение таких описаний многочисленными заинтересованными сторонами. "Модели для понимания и коммуникации", на знамени которых стоит самый успешный пример UML-моделирования. Ключевым для успеха UML было озарение: "одного типа диаграмм не хватает". В результате использование UML для архитектурной деятельности (arhitecting) стало обыденным.
Второй шаг -- это возможность "порождения" (интерпретации, "вычисления", или как говорят компиляторщики "выполнения в особом смысле записи на языке программирования" -- получение из высокоуровневого кода низкоуровневого кода/чертежей, и передача их на "реализацию" путем "исполнения", "показа", или даже "изготовления в железе"). Для этого часто вносятся изменения в "универсальные языки моделирования", используемые на первом шаге (например, так из UML появлялись "исполняемый" xUML и "трансформируемый" UMLX). В этом плане "порождающее моделирование" практически сливается с "программированием" и "проектированием".
Третий шаг -- это озарение: "заранее предписанных видов диаграмм не хватает". Отсюда расширяемость UML (вниз-вбок через MOF, и вверх-в-стороны через "стереотипы"), а также гениальная догадка, что UML со стереотипами не похож на удобный для непрограммистов язык моделирования. Для непрограммистов удобным языком моделирования является их привычный DSL, а если хочется сделать несколько тематических узкопрофессиональных групп описаний (view) с использованием разных методов описания (viewpoint), то разные потребные DSL можно заставить "ожить" (т.е. иметь возможность их "исполнить", или на их основе "породить" низкоуровневые описания) путем использования общей "основы" (как MOF для разных диграмм UML) и специального входящего в состав языка IDE (тоже не новая идея: Smalltalk определялся неразрывно с IDE, а не просто как "текст с синтаксисом"). Martin Fowler назвал такие мультиDSL-IDE "language workbenches" (http://martinfowler.com/articles/languageWorkbench.html), а я -- "языковыми капищами", http://ailev.livejournal.com/683311.html).
В наиболее современном виде этот класс "порождающих" моделей развивается сейчас в таких инициативах, как OMG MDA (http://www.omg.org/mda/) и различных инициативах language workbenches (Intentional Software, JetBrains MPS, MetaEdit etc. -- http://martinfowler.com/bliki/IntentionalSoftware.html), а также в онтологических САПР (где множество различных представлений одного и того же объекта объединяются в единую модель на базе "схемы" -- линейки разных специализированных САПР, поддерживающих ISO15926 в качестве основы для общего репозитория модели, см., например, http://www.bentley.com/en-US/Products/OpenPlant+PowerPID/).
Эти "порождающие модели" нельзя назвать "эталонными" ни в каком смысле (разве что вспомнив одно из определений архитектуры -- "описание, удовлетворяющее целому классу применений, целому классу реализаций, а не одному экземпляру системы"), но эти модели не являются и классическими "математическими моделями" в том плане, что по ним не проводится численного анализа. К математическим моделям "символического анализа" я бы тоже эти модели не относил (хотя за уши принятуть, конечно, можно: математика ведь настолько обща, что под ее крышу можно затянуть все что угодно).
"Порождающее моделирование" является сейчас лидером, именно о нем говорится в "моделецентричной" системной инженерии (а не об имитационном моделировании: хотя "запуск на исполнение" порожденного по модели кода может привести в том числе и к имитационному расчету, не вопрос). Моделецентрическая системная инженерия -- это сегодня использование специализированных САПР (САПР -- это же, что софтовое IDE, только для "некомпьютерного железа"), поддерживающих именно что множество DSL для разных специальных инженерий (например, диаграммы P&ID), но в общей интерактивной среде разработки (interactive development environment, IDE) над объединенной общей для всех "специальностей" датацентричной моделью, хранящейся в репозитории.
Системная инженерия ждала 10 лет, когда "многодиаграммное универсальное описание" в UML перешло из программной инженерии в системную инженерию в варианте SysML. Не нужно ждать 10 лет, чтобы сообразить сделать то же самое для тренда, обобщающего "многодиаграммный принцип" до ситуации multiDSL в рамках language workbenches или "много САПР вокруг одного репозитория". Можно думать о том, как сделать "универсальную систему автоматизации проектирования" на базе моделецентричности так же, как десять лет назад думали об "универсальной системе моделирования" для софта -- и породили высоко кастомизируемые Rational Rose, Objecteering, Artisan Studio и т.д.