Конвергенция: моделецентрическая программная, системная и контрольная инженерия
Продолжим пересказ презентации Janos Sztipanovits "Convergence: Model-Based Software, Systems And Control Engineering" (http://www.infoq.com/presentations/Model-Based-Design-Janos-Sztipanovits). Начало -- http://ailev.livejournal.com/673824.html.
Понятие "платформ" -- не интеграционных, как в MDA и ООП, а для выражения разных свойств динамизма, разных взаимосвязей во времени. "Платформы" -- это слои абстракции в моделецентричном дизайне (model-based design). Например, платформа архитектурных описаний софта, или она же -- платформа описания вычислений (computations). Мы двигаемся от одного слоя абстракции к другому слою, используя разные техники -- преобразования (transformations), синтез, уточнения (refinement). Это и есть моделецентрический дизайн (model-based design). [намеренно не использую тут слово "проектирование" -- как потому, что оно не "конструирование", так и потому, что оно в значении пересекается с проектом-project. Эта переводческая проблема еще ждет своего решения].
Проблемы при использовании моделецентрического дизайна в киберфизических системах:
-- инструменты автоматизации негибки в их design flow, а киберфизические системы весьма гетерогенны, да еще и быстро меняются -- так, что инструментарий их моделирования постоянно отстает. Тут нужно переходить от монолитных закрытых инструментальных сред к каким-то настраиваемым цепочкам открытых инструментов. Возможные решения: предметноспецифические языки моделирования (domain specific modeling languages, DSML), интеграция и трансляция DSML, метапрограммируемая инструментальная инфраструктура, интеграционные фреймворки (в их программистском значении -- не библиотеки, а наоборт, вызывающие структуры) для инструментов дизайна, генерация кода из моделей.
-- системная интеграция весьма гетерогенна и сложна. Тут нужно переходить к полномасштабному (end-to-end) моделированию, быстрому виртуальному прототипированию, специфичным для предметной области абстракциям. Возможные решения: предметноспецифические языки моделирования, интеграция и трансляция DSML, управление моделями (учет изменений состояния моделей, в том числе очень больших моделей и моделей, возникающих в ходе "параллельной разработки" concurrent engineering), DSML и эволюция моделей, архитектурные исследования и имитационное моделирование (simulation).
-- нужна высокая уверенность в дизайне, безопасность (safety, security) и возможность дешевого и быстрого лицензирования (certifiability) сейчас главная забота. Тут нужны специфичные для предметной области (а иногда и для отдельных проблем) интегральные абстракции, не теряющие семантической точности в их определении, чтобы можно было при интеграции как-то соотносить эти абстракции между собой. Возможное решение: явная (explicit), практичная и способствующая объединению (composable) семантика DSML.
Далее из всех этих проблем обсуждаются настраиваемые открытые цепочки инструментов моделирования, опирающиеся на общее семантическое основание. Вот три слоя инструментальной структуры модельно-интегрированных вычислений (model intergated computing, MIC):
Для того, чтобы отдельные инструменты моделирования корректно объединялись в цепочки, требуется метамодельное описание их самих и форматов данных, которыми эти инструменты обмениваются, а также спецификация для трансляции из форматов одних инструментов в форматы других инструментов. Также требуется корректно объединяющая данные моделирования среда хранения информации (persistance) -- "универсальная модель данных".
Пример: general modeling environment GME8 -- http://www.isis.vanderbilt.edu/projects/gme/, базирующаяся на нотации UML диаграмм классов и ограничений OCL. Folders, FCOs (first class objects -- Models, Atoms, Sets, References, Connections), Roles,Constraints and Aspects are the main concepts that are used to define a modeling paradigm. Для этой среды расширения пишутся на традиционных языках программирования с использованием MS COM.
Вся механика модельно-интегрированных вычислений опирается на преобразования моделей: во время вычисления входные модели преобразуются в выходные модели, и это описывается в GME8 на семантике преобразования графов -- тройки метамоделей: метамодель Входа, метамодель Выхода, и метамодель Преобразования. Из результирующего метамодельного графа генерируется исполняющий код. Создать моделер для DSML -- это описать соответствующие предметной области метамодели на UML+OCL, а затем получить готовый код моделера (редактора моделей). Что часто недооценивается, так это наличие структурной (математической структуры) семантики самих метамоделей.
Структура (математический формализм) модели не статична, она эволюционирует в динамике (например, в сетевых встроенных системах, networked embedded systems). И ограничения (constraints) тоже появляются в динамике, во времени. Как работать с этой поведенческой семантикой (behavioral semantics) -- дно из направлений исследований. Не только системы изменяются во времени, но и их модели. Поэтому должны появляться языки моделирования с поведенческой семантикой. Сейчас метамодели определяются с неформально статической семантикой, поведенческая семантика неявно определяется кодом симулятора, кодогенератором, пользовательским комьюнити. Поведенческая семантика определяется примерами и неформальными выражениями намерения (intent). Для некоторых языков моделирования такая формальная семантика разработана с огромными усилиями, нет "устаканившейся" методологии или формализма.
Все поведенческие модели должны быть как-то совместимыми друг с другом: если не знать, как свойства в разных моделях соотносятся друг с другом, нельзя быть уверенным, соотносятся ли друг с другом результаты моделирования. В автомобильной промышленности часто одни средства моделирования показывают, что дизайн безопасный, а другие -- что небезопасный. Это связано с тем, что нет средств семантического сопоставления результатов моделирования.
Эксплицитные методы получения поведенческой семантики: от AST (abstract syntax tree) переходим либо:
-- к коду на языке программирования (например, С++), затем получая либо модуль-модель, либо выполнимый код со спрятанной внутри поведенческой семантикой,
-- либо к правилам переписки графов с явно выражаемой динамикой, а уже от них к выполнимому коду или выполняемой спецификации. Это формальный метод, тут можно использовать формальный вывод.
Традиционно для моделирования киберфизических систем спользуются очень разные математические формализмы, и самая главная задача сейчас -- это понять, как можно объединять в ходе моделецентричного дизайна модели, использующие в своем основании такие разные формализмы. В качестве примера приведено описание моделирования экспериментов в аэродинамической трубе -- от поведения людей (модели Petri-net), моделей контроля и поведения самолета, до моделирования софта:
Нужно связать эти модели друг с другом, описать совместную симуляцию. Вот архитектура интеграции моделей, которую использовали для данного случая (слой интеграции моделей использует метамоделирование, и имеет достаточно богатый язык, чтобы выразить взаимодействие описываемых в нем моделей, причем с учетом сетевой специфики моделируемой системы -- а затем идет генерация кода для run-time):
Почему тут так сложно? Например, в моделировании электрических сетей на предмет исследования блэкаутов нельзя исходить из задержек, определяемых чисто "физической сетью": значительное число задержек связано не с физикой, а со временем отработки софта и людей. С другой стороны, нельзя моделировать только софт и людей, ибо тогда потеряется специфика электрической сети. Поэтому можно моделировать только вместе, но это как раз и вызывает содержательную проблему совмещения разных моделей.
DSML типа SysML (системная инженерия), AADL (avionics architecture description language) и другие предметно-ориентированные языки, которые развиваются путем распухания, это тупик для комплексирования моделей. Для комплексирования моделей требуется специальное изучение проблемы и создание специальных "внепредметных" языков общего назначания, опирающихся на математические формализмы. Эти языки будут довольно компактными, и помогут бороться с гигантскими и необъятными в своем стремлении ко всеохватности стандартами. Инициативы типа SysML и AADL хороши, но отражают сегодняшнее, а не завтрашнее мышление в моделировании.
Комплексирование моделей сводится не просто к сопоставлению свойств разных моделей, которые имеют там разные наименования. Это вопрос сущностной картины мира (онтологии в ее классическом философском значении). Например, при комплексировании непрерывных моделей (дифуры) и дискретных моделей (конечные автоматы) вообще непонятно, как из связывать друг с другом на уровне языка. Если хочется сделать имитационное моделирование такой системы, описываемой двумя такими моделями, немедленно придется понимать, что означает "связывать модели". Такая интеграция моделей порождает новые семантические предметные области (new semantic domains).
Future combat systems является примером использования моделирования для разработки требований. Требования для такой системы систем (Systems-of-Systems) всегда недостаточны. При обнаружении каждой новой проблемы группа Janosh Sztipanovits быстро определяет новый DSML, разрабатывает соответствующую проблеме модель, и затем выполняет комплексное моделирование уже совместно с этой моделью. Затем проводится анализ результатов, определяется новая проблема, и так требования появляются постепенно по ходу возникающей большой модели. Не было бы моделей, не было бы понимания требований.
Понятие "платформ" -- не интеграционных, как в MDA и ООП, а для выражения разных свойств динамизма, разных взаимосвязей во времени. "Платформы" -- это слои абстракции в моделецентричном дизайне (model-based design). Например, платформа архитектурных описаний софта, или она же -- платформа описания вычислений (computations). Мы двигаемся от одного слоя абстракции к другому слою, используя разные техники -- преобразования (transformations), синтез, уточнения (refinement). Это и есть моделецентрический дизайн (model-based design). [намеренно не использую тут слово "проектирование" -- как потому, что оно не "конструирование", так и потому, что оно в значении пересекается с проектом-project. Эта переводческая проблема еще ждет своего решения].
Проблемы при использовании моделецентрического дизайна в киберфизических системах:
-- инструменты автоматизации негибки в их design flow, а киберфизические системы весьма гетерогенны, да еще и быстро меняются -- так, что инструментарий их моделирования постоянно отстает. Тут нужно переходить от монолитных закрытых инструментальных сред к каким-то настраиваемым цепочкам открытых инструментов. Возможные решения: предметноспецифические языки моделирования (domain specific modeling languages, DSML), интеграция и трансляция DSML, метапрограммируемая инструментальная инфраструктура, интеграционные фреймворки (в их программистском значении -- не библиотеки, а наоборт, вызывающие структуры) для инструментов дизайна, генерация кода из моделей.
-- системная интеграция весьма гетерогенна и сложна. Тут нужно переходить к полномасштабному (end-to-end) моделированию, быстрому виртуальному прототипированию, специфичным для предметной области абстракциям. Возможные решения: предметноспецифические языки моделирования, интеграция и трансляция DSML, управление моделями (учет изменений состояния моделей, в том числе очень больших моделей и моделей, возникающих в ходе "параллельной разработки" concurrent engineering), DSML и эволюция моделей, архитектурные исследования и имитационное моделирование (simulation).
-- нужна высокая уверенность в дизайне, безопасность (safety, security) и возможность дешевого и быстрого лицензирования (certifiability) сейчас главная забота. Тут нужны специфичные для предметной области (а иногда и для отдельных проблем) интегральные абстракции, не теряющие семантической точности в их определении, чтобы можно было при интеграции как-то соотносить эти абстракции между собой. Возможное решение: явная (explicit), практичная и способствующая объединению (composable) семантика DSML.
Далее из всех этих проблем обсуждаются настраиваемые открытые цепочки инструментов моделирования, опирающиеся на общее семантическое основание. Вот три слоя инструментальной структуры модельно-интегрированных вычислений (model intergated computing, MIC):
Для того, чтобы отдельные инструменты моделирования корректно объединялись в цепочки, требуется метамодельное описание их самих и форматов данных, которыми эти инструменты обмениваются, а также спецификация для трансляции из форматов одних инструментов в форматы других инструментов. Также требуется корректно объединяющая данные моделирования среда хранения информации (persistance) -- "универсальная модель данных".
Пример: general modeling environment GME8 -- http://www.isis.vanderbilt.edu/projects/gme/, базирующаяся на нотации UML диаграмм классов и ограничений OCL. Folders, FCOs (first class objects -- Models, Atoms, Sets, References, Connections), Roles,Constraints and Aspects are the main concepts that are used to define a modeling paradigm. Для этой среды расширения пишутся на традиционных языках программирования с использованием MS COM.
Вся механика модельно-интегрированных вычислений опирается на преобразования моделей: во время вычисления входные модели преобразуются в выходные модели, и это описывается в GME8 на семантике преобразования графов -- тройки метамоделей: метамодель Входа, метамодель Выхода, и метамодель Преобразования. Из результирующего метамодельного графа генерируется исполняющий код. Создать моделер для DSML -- это описать соответствующие предметной области метамодели на UML+OCL, а затем получить готовый код моделера (редактора моделей). Что часто недооценивается, так это наличие структурной (математической структуры) семантики самих метамоделей.
Структура (математический формализм) модели не статична, она эволюционирует в динамике (например, в сетевых встроенных системах, networked embedded systems). И ограничения (constraints) тоже появляются в динамике, во времени. Как работать с этой поведенческой семантикой (behavioral semantics) -- дно из направлений исследований. Не только системы изменяются во времени, но и их модели. Поэтому должны появляться языки моделирования с поведенческой семантикой. Сейчас метамодели определяются с неформально статической семантикой, поведенческая семантика неявно определяется кодом симулятора, кодогенератором, пользовательским комьюнити. Поведенческая семантика определяется примерами и неформальными выражениями намерения (intent). Для некоторых языков моделирования такая формальная семантика разработана с огромными усилиями, нет "устаканившейся" методологии или формализма.
Все поведенческие модели должны быть как-то совместимыми друг с другом: если не знать, как свойства в разных моделях соотносятся друг с другом, нельзя быть уверенным, соотносятся ли друг с другом результаты моделирования. В автомобильной промышленности часто одни средства моделирования показывают, что дизайн безопасный, а другие -- что небезопасный. Это связано с тем, что нет средств семантического сопоставления результатов моделирования.
Эксплицитные методы получения поведенческой семантики: от AST (abstract syntax tree) переходим либо:
-- к коду на языке программирования (например, С++), затем получая либо модуль-модель, либо выполнимый код со спрятанной внутри поведенческой семантикой,
-- либо к правилам переписки графов с явно выражаемой динамикой, а уже от них к выполнимому коду или выполняемой спецификации. Это формальный метод, тут можно использовать формальный вывод.
Традиционно для моделирования киберфизических систем спользуются очень разные математические формализмы, и самая главная задача сейчас -- это понять, как можно объединять в ходе моделецентричного дизайна модели, использующие в своем основании такие разные формализмы. В качестве примера приведено описание моделирования экспериментов в аэродинамической трубе -- от поведения людей (модели Petri-net), моделей контроля и поведения самолета, до моделирования софта:
Нужно связать эти модели друг с другом, описать совместную симуляцию. Вот архитектура интеграции моделей, которую использовали для данного случая (слой интеграции моделей использует метамоделирование, и имеет достаточно богатый язык, чтобы выразить взаимодействие описываемых в нем моделей, причем с учетом сетевой специфики моделируемой системы -- а затем идет генерация кода для run-time):
Почему тут так сложно? Например, в моделировании электрических сетей на предмет исследования блэкаутов нельзя исходить из задержек, определяемых чисто "физической сетью": значительное число задержек связано не с физикой, а со временем отработки софта и людей. С другой стороны, нельзя моделировать только софт и людей, ибо тогда потеряется специфика электрической сети. Поэтому можно моделировать только вместе, но это как раз и вызывает содержательную проблему совмещения разных моделей.
DSML типа SysML (системная инженерия), AADL (avionics architecture description language) и другие предметно-ориентированные языки, которые развиваются путем распухания, это тупик для комплексирования моделей. Для комплексирования моделей требуется специальное изучение проблемы и создание специальных "внепредметных" языков общего назначания, опирающихся на математические формализмы. Эти языки будут довольно компактными, и помогут бороться с гигантскими и необъятными в своем стремлении ко всеохватности стандартами. Инициативы типа SysML и AADL хороши, но отражают сегодняшнее, а не завтрашнее мышление в моделировании.
Комплексирование моделей сводится не просто к сопоставлению свойств разных моделей, которые имеют там разные наименования. Это вопрос сущностной картины мира (онтологии в ее классическом философском значении). Например, при комплексировании непрерывных моделей (дифуры) и дискретных моделей (конечные автоматы) вообще непонятно, как из связывать друг с другом на уровне языка. Если хочется сделать имитационное моделирование такой системы, описываемой двумя такими моделями, немедленно придется понимать, что означает "связывать модели". Такая интеграция моделей порождает новые семантические предметные области (new semantic domains).
Future combat systems является примером использования моделирования для разработки требований. Требования для такой системы систем (Systems-of-Systems) всегда недостаточны. При обнаружении каждой новой проблемы группа Janosh Sztipanovits быстро определяет новый DSML, разрабатывает соответствующую проблеме модель, и затем выполняет комплексное моделирование уже совместно с этой моделью. Затем проводится анализ результатов, определяется новая проблема, и так требования появляются постепенно по ходу возникающей большой модели. Не было бы моделей, не было бы понимания требований.