Далее в 2003 году Эрик Эванс (Eric Evans) ввел понятие предметно-ориентированного проектирования (Domain-Driven Design, DDD) для набора программных и организационных практик, позволяющих разрабатывать сложные масштабируемые системы. Этот подход до сих пор активно используется, например, в микросервисной архитектуре и в информационной безопасности (см. Secure by Design). В этом подходе вводятся понятия: «модель», «проектирование по модели» (Model-Driven Design), «изоляция предметной области» и «изолированный контекст» (Bounded Context). Особенно интересно, что Эванс упоминает о предметно-ориентированных языках, как идеальном средстве описания модели конкретной предметной области, которая должна быть изолирована в своём контексте.

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

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

Введение

Рискну предположить, что в имитационном численном моделировании уже долгие годы наблюдается застой. Например, один из основных инструментов современного численного моделирования MATLAB появился ещё в 70-тые годы прошлого века, а графическая надстройка для него Simulink – в начале 2000-ных годов. Многие другие «более современные» системы моделирования имеют очень много общего с MATLAB – универсальный язык плюс графическая среда с возможностью построения модели с использованием блоков.

Неужели это предел развития? Может быть нет таких задач, которые не могли бы решить старые инструменты?

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

1. Взаимодействие сотен разных или схожих объектов (летательных аппаратов, кораблей, наземных и спутниковых систем) с учётом заправки и запасов топлива, износа конструкций и оборудования, необходимости замены, ремонта, расчёта поступления расходных материалов и так далее.

2. Крупное промышленное предприятие в условиях реконструкции с учётом изменения логистики поставок необходимых для производства материалов и компонентов, а также продолжения отгрузки продукции различных модификаций.

3. Биосфера в условиях человеческого влияния, как отрицательного, так и компенсационного.

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

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

• учёта реального (псевдо-реального) времени, например, для подключения полунатурных элементов или ручного управления (полного или частичного);

• работы в длительном режиме (часы, сутки, недели и т.д.);

• возможности изменять не только параметры модели, но и состав, структуру и поведение;

• делать эти изменения непосредственно во время моделирования.

Можно ли для таких задач использовать системы типа MATLAB? Наверное, можно, однако изначально они разрабатывались для другого. Приспособить их для подобных задач сложно, при попытке это сделать вы лишь добавите кирпичей в порог сложности использования.

Однако прежде, чем отметать проверенные временем системы, давайте разберёмся в чём причина их долголетия. Нам это может пригодится.

Доминирующие признаки, давшие преимущество в эволюции

Давайте рассмотрим MATLAB, как наиболее характерный инструмент старой школы. Для многих он ассоциируется с графической средой Simulink, однако, во-первых, эта графическая среда появилась лишь в 2000-х годах, когда MATLAB уже обрёл популярность и, во-вторых, она отнюдь не отменяет использование языка MATLAB, особенно в серьёзных задачах. Похожее решение используется и в системах на базе языка моделирования Modelica, SystemVerilog и даже в системах 3d-моделирования для описания поведения материалов на базе языков программирования шейдеров, а также во многих других системах из разных областей информационных технологий.

Другим доминирующим признаком долгоживущих систем моделирования можно назвать гибкость и открытость для создания расширений и дополнений. Для нашего образца – системы моделирования MATLAB – создано огромное количество расширений, начиная с Simulink и заканчивая такими, как инструменты для работы со стандартами качества в производстве (Simulink Check, Model Advisor, DO Qualification Kit и другие).

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

Кто-то может сказать: «А как же возможность формировать модель из блоков в графический среде? Это ли не доминирующий признак? Ведь практически все пользователи MATLAB пользуются этим инструментом!» Да, этот инструмент удобен для многих задач, но его необходимость вызывает сомнения и на эту тему можно долго дискутировать. Напомним только один момент – существование предела Дойча – в сложных моделях он довольно часто срабатывает. Тем не менее, признаем, что графическая среда «рисования» модели в виде блоков может быть удобна для задач моделирования, а значит должна быть реализуема как инструмент или расширение, но обязательно на базе языкового императива.

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

Языково-ориентированная парадигма для предметных областей

А теперь давайте вернёмся к языково-ориентированному программированию Мартина Уорда.

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

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

Тут важно отметить, что предметная ориентация языка может иметь разную глубину. Возьмём, к примеру, область моделирования управления летательными аппаратами. Тут можно выделить как минимум три уровня детализации языка описания модели: а) универсальный язык, как в MATLAB и других системах «старой школы»; б) часть модели можно описывать на языке обыкновенных дифференциальных уравнений (то есть могут быть языки для некоторого раздела математики) и, наконец, в) можно создать язык, который наилучшим образом описывает именно систему управления летательными аппаратами (а может быть несколько языков для этого). Например, для приведённой области моделирования важным аспектом является преобразование координат модели – для этого можно реализовать специальный оператор нового языка. А для описания банка аэродинамических коэффициентов – свой язык, наилучшим образом описывающий табличные функции от нескольких аргументов.

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

А теперь давайте вспомним проектирование по модели и изоляцию предметной области. Получается, что мы, используя предметно-ориентированный язык, формируем модель конкретного представления предметной области, которая моментально начинает работать без преобразования. Она сразу изолирована, имеет естественный интерфейс в виде параметров и переменных в терминах предметной области и готова к использованию, как в нашей модели, так и в других, если мы усложняем и расширяем нашу задачу моделирования. Особенно хочу подчеркнуть, что описание модели на предметно-ориентированном языке является максимально точным, т.к. не требует преобразования – она сразу работает. Это фундаментальное требование концепции проектирования по модели (Model-Driven Design) по Эвансу.

А ещё при такой архитектуре мы получаем дополнительный бонус – возможность вычисления этих изолированных представлений модели независимо – параллельно и/или распределённо.

И наконец, обращу ваше внимание на то, что приведённое описание не зацикливается на математическом имитационном моделировании, поскольку базируется на теории разработки программного обеспечения.

Адаптивная система моделирования

Что же у нас получается? Нужна система моделирования, которая в своём базовом исполнении должна предоставлять некоторый набор предметно-ориентированных языков для основных разделов математики/физики, иметь набор «супер-пупер» инструментов для работы с предметно-ориентированными языками, а также позволяющая создавать любые расширения, в том числе с возможностями графического формирования модели из блоков.

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

Адаптивная система моделирования (АСМ) – концепция построения и применения системы имитационного моделирования, предполагающая следующие базовые элементы:

• языково-ориентированная парадигма – простая и удобная технология разработки предметно-ориентированных языков;

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

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

Конкретный коллектив специалистов может взять эту систему с базовым набором инструментов и адаптировать её под свою задачу.

А теперь настало время рассмотреть примеры. В качестве работающего прототипа будем использовать АСМ SIMODO.

Простые примеры

На снимке экрана ниже численное решение задачи трёх тел с использованием системы моделирования SIMODO. Модель общего вида представлена системой дифференциальных уравнений в векторной форме, записанной в отдельном файле на декларативном языке s-ode (расширение файла «.s-ode»).

Сценарий моделирования, на котором задаются начальные условия и определяются параметры отображения информации во время моделирования, записывается на универсальном императивном языке s-script (расширение файла «.s-script»). Такой подход позволяет работать с моделью, как с типом, создавая произвольное количество реализаций этого и других типов и добавлять их на сцену моделирования. Универсализм императивного языка позволяет описывать различные сценарии использование моделей.

Следующая модель немного притянута за уши, но полезна для демонстрации самого подхода – движение центра масс с сопротивлением среды в векторной форме. Ниже – содержимое модуля «models/ДЦМ-трение.s-ode».

Язык s-ode использует реализацию дженериков системы языков SIMODO, что позволяет подставлять для используемых переменных различные типы данных. Конкретный тип определяется при задании начальных значений, а если есть вычисляемые переменные, то – типом значения, полученного при вычислении.

Реализация ПИД-регулятора для удержания этой модели в конкретной точке координат при наличии помехи типа ветра показана на снимке экрана ниже. Сценарий моделирования ожидаемо выполнен на универсальном языке s-script.

Мы рассмотрели два уровня языков: универсальный императивный язык s-script и универсальный математический язык описания обыкновенных дифференциальных уравнений s-ode. Теперь шагнём глубже. Рассмотрим не абстрактную задачу численного решения диффуров, а более конкретную задачу управления летательным аппаратом. Ниже описание модели движения центра масс летательного аппарата на языке следующего уровня, адаптированном для более конкретной предметной области.

Кому-то может показаться описание непонятным, но это нормально – важно, чтобы язык был понятен специалистам. Заметьте также, что в отличии от универсального языка s-ode параметры (переменные) имеют конкретный тип, а преобразование типов и в целом семантика модели может более качественно контролироваться анализатором. Кстати, анализатор языков SIMODO реализован с использованием технологии Language Server Protocol (LSP).

А вот описание на этом же языке системы управления, задачей которой является наведение аппарата на заданную точку с заданной скоростью:

Тут мультик работы с этими моделями. Ссылка на стартовый сценарий тут.

Следующая задача демонстрирует определение двух объектов по тем же моделям и задание для системы управления второго аппарата текущих координат первого. Получается погоня. Хотя, конечно, алгоритм довольной примитивный.

Мультик и стартовый сценарий погони.

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

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

Ещё немного усложним

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

Мультик и стартовый сценарий одного объекта, а также мультик и стартовый сценарий погони одного за другим.

На мультиках можно обратить внимание, что «кокпит» (это такой зелёненький прямоугольник) настроен на первый аппарат и начинает отображать углы тангажа и крена только для «полной» модели. Этот «кокпит», кстати, является расширением АСМ SIMODO, как и панель графиков, как и редактор, как и панель файловой системы, как и… То есть интегрированная среда моделирования АСМ SIMODO является оболочкой, которая сама по себе мало что умеет, её задача – предоставление интерфейсов для взаимодействия расширений. Но это – тема отдельного рассказа.

Банк атмосферы, двигателя и аэродинамики

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

Графики остальных банков легко построить с использованием языка s-script, как и этот.

Модель из другой области

Ниже представлен упрощённый тест для принятия решения о посадке беспилотника на языке логического вывода, который отчасти похож на Пролог.

Инструменты для работы с языками

Подробно описывать как разрабатываются языки в АСМ SIMODO было бы долго. Вкратце можно сказать следующее (надеюсь, получится достаточно безумно и непонятно):

1. Грамматики языков описываются в форме похожей на Бэкуса-Наура на языке fuze (это тоже язык SIMODO) и там же дополняются алгоритмами формирования абстрактного синтаксического дерева (АСД) (см. снимок экрана ниже).

2. Эти описания преобразуются в таблицы грамматик либо алгоритмом SLR, либо LR1, если SLR не может разобрать. Да, у нас нет продвинутых алгоритмов типа LALR, но пока SLR хватает (на самом деле это не совсем SLR, а его усиленный с применением шаманских танцев вариант, возможно, неизвестный науке).

3. Для разбора текста на конкретном языке используется универсальный парсер уровня LR1 (автомат с магазинной памятью), которому передаются подготовленные таблицы грамматики этого языка.

4. Парсер при выполнении редукции правила интерпретирует заданный алгоритм для формирования узла АСД.

5. Интерпретатор берёт полученное АСД и сразу начинает его выполнять.

Далее, при интерпретации тоже используется магия, но это – из другой сказки!

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

Пара слов о блок-диаграммах

В наше время сложно представить систему моделирования без красивых блок-диаграмм. Конечно, АСМ теоретически имеет возможность построения модели и сцены с использованием графики. Однако это является не обязательной функцией, а скорее дополнительной опцией. Вполне вероятно, что в АСМ SIMODO появится возможность работы с блоками, но до сих пор такой необходимости не возникало. Поэтому разработка блок-диаграмм постоянно переносится всё дальше и дальше, в отличии от, например, облачного моделирования или репозитория пользовательских расширений.

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

Заключение

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

В настоящее время система разрабатывается и используется в реальных задачах небольшим коллективом энтузиастов в свободное от работы и учёбы время на кафедрах ИУ1 и ИУ6 МГТУ им. Н.Э. Баумана. Исходные коды расположены тут, дистрибутивы можно скачать тут. Распространяется под лицензией MIT.

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