Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Порождающее моделирование и моделеориентированная системная инженерия

Современное употребление слова "модель" по смыслу размыто не меньше, чем его обобщение -- "описание". Когда мы пишем "моделе-ориентированная системная инженерия" (model-based systems engineering, MBSE, http://www.incose.org/newsevents/news/details.aspx?id=151), то можно прочесть и как "описание-ориентированная системная инженерия". Но ведь любая инженерия описание-ориентирована, так как в самой ее основе лежат описания: тексты, чертежи, диаграммы, графики, формулы и т.д.. Зачем вводить новый термин для привычной практики, и подчеркивать, что это будущее системной инженерии?

Я думаю, что новый термин был введен для относительно нового типа моделей. MBSE -- это не про любые описания, ассоциируемые с "моделями". MBSE не про имитационные модели и эмуляторы. MBSE не про использование Modelica (http://modelica.org/, нейтральный по отношению к производителям софта, объектно-ориентированный, основанный на уравнениях язык для удобного моделирования физических систем, содержащих, например, механические, электрические, электронные, гидравлические, термальные, контролирующие или процесс-ориентированные компоненты) или не про использование моделей метода конечных элементов (например, http://www.ncac.gwu.edu/vml/models.html). Также MBSE не про использование сложных мультифизичных моделей в имитационном моделировании киберфизических систем, когда мы должны одновременно проводить вычисления для нескольких моделей разной природы (см. обсуждение этой проблемы в http://www.infoq.com/presentations/Model-Based-Design-Janos-Sztipanovits). И даже MBSE не про типовые наборы практик (process reference models), которые мы можем видеть в ISO 15288 и других стандартах дисциплин системной инженерии.

Моделеориентированная системная инженерия -- это про порождающие модели. Термин "порождающие" (generative) имеет тот же самый смысл, что и в "порождающей грамматике", которая была введенна Хомским (и не должна путаться с порождающими моделями в статистике, http://en.wikipedia.org/wiki/Generative_model). "Порождать" было использовано Хомским как технический термин в особом смысле. Когда говорят, что "грамматика порождает предложение", имеют ввиду то, что грамматика "присваивает структурное описание" предложению (Chomsky, Noam, 1965. Aspects of the Theory of Syntax. MIT Press, на русском http://www.twirpx.com/file/19189/). Модели в MBSE порождают описания системы в том же самом смысле, что порождающая грамматика порождает предложения. В сущности, моделе-ориентированная системная инженерия занимается применением метамодельных уровней (уровни описаний описаний, языковые уровни) для описывания систем.

Каждый уровень этажерки моделей (модель M0, метамодель M1, мета-метамодель M2 и т.д.) может быть уточнен (детализирован) и/или трансформирован ("компилирован", "транслирован"), чтобы "породить" другое описание, адресующее интерес одной или более заинтересованных сторон. В конце концов, эти исчерпывающие описания будут достаточны для реализации, интеграции, верификации и валидации системы.

Ключевая характеристика моделе-ориентированной системной инженерии -- это поддержка одновременного использования множества методов описания (viewpoints), т.е. одновременного применения множества методов моделирования для получения множества групп описаний (views), которые адресуют различные интересы соответствующих заинтересованных лиц.

15 лет назад не так часто подчеркивалось применение множества групп описаний. Моделирование было обычно мономоделированием, которое обеспечивало каждый раз только один тип группы описаний, и обеспечение связей между объектами и отношениями в разных группах описаний было для инженеров большой проблемой. OMG UML (http://www.uml.org/) был прорывным языком, который принес парадигму множественности методов/групп описаний в мейнстрим программной инженерии. Его 5 типов диаграмм позволили связно отражать различные аспекты программных систем. Более того, UML расширяем стандартным способом, и системная инженерия с десятилетним лагом (как обычно) к программной инженерии получила средство для описания этого множества методов/групп описаний в форме SysML, являющегося расширением UML. ISO 42010 (стандарт рекомендованной практики архитектурных описаний) получил язык для своей поддержки.

UML вместе с MOF (Meta Object Facility, http://www.omg.org/mof, обеспечивает взаимосвязанность всех моделей на UML) является основным языком моделеориентированной архитектуры (MDA, model-driven architecture, http://www.omg.org/mda) консорциума по стандартизации OMG. MDA уже переосмысливается, чтобы ее предмет был расширен с программной инженерии на системную инженерию (http://www.calimar.com/Papers/Model%20Driven%20Architecture%20for%20SE-Why%20Care.pdf, http://www.lboro.ac.uk/departments/el/sedc/documents/presentations/model-driven-architecture.pdf и много других).

Главное достоинство MDA -- это множество уровней абстракции (иерархия уровней метамоделирования) и множество обеспечиваемых метамоделями методов описания с прописанными правилами соответствия методов описаний (viewpoint correspondence rules). Главный недостаток MDA -- это ограниченность этой архитектуры языком UML. Почему UML является недостатком? Потому что в междисциплинарном проекте мы не можем ожидать, что все специалисты-пользователи говорят на UML или SysML, даже если мы расширим эти языки специфичными для предметных областей стереотипами.

В то же время в программной инженерии образовалась и быстро растет другая ветвь модельного движения, которая связана с понятием предметно-специфичного языка (DSL, domain-specific language), обеспечивающего применяемый экспертами метод описания для получения предметно-специфичной группы описаний. DSL объединяет (концептуальную) метамодель и (графическую и/или текстовую) нотацию. Это отличается от MDA, в которой предписываются нотации и метамодели, основанные только на MOF/UML. Тем самым программисты должны обеспечивать отдельную интерактивную среду разработки (IDE, interactive development environment) для каждого DSL, а затем эксперты-непрограммисты будут использовать эти предметно-специфичные IDE для моделирования их систем.

Все САПР могут быть рассмотрены как наборы таких IDE для инженерных предметно-специфичных языков (например, диаграмм P&ID для моделирования гидравлических систем). Если мы хотим создать модель завода непрерывного цикла (например, нефтеперерабатывающего завода), то предстоит трудный выбор между моделированием гидравлических систем в MDA/SysML и традиционным P&ID-моделированием. Предметно-специфические языки современных САПР легко выигрывают. Но потом мы все равно должны объединить все эти несовместимые между собой модели на разных DSL в одну связанную модель завода.

У нас есть две возможности предоставить такую связанность для зоопарка различных DSL: 1. Онтологическое совмещение (mapping) метамоделей различных DSL, и тем самым совмещение моделей в датацентрическом репозитории моделей. 2. Использование языковых рабочих мест (language workbenches).

Онтологическое совмещение сегодня используется всеми основными поставщиками САПР, хотя при этом используются разные "верхние" (upper) онтологии и предметные таксономии: ISO 15926 для непрерывных производств, ISO 18269/PSL для (в том числе бизнес) процессов, ISO 16739/BIM для строительства и т.д.. Это хорошая возможность справиться с зоопарком устаревших системам, которые поддерживают "старые добрые предметно-специфичные языки инженерного моделирования". Онтологическое совмещение -- относительно недавнее движение (начавшееся с работ 1994г. по созданию модели данных перерабатывающих производств Shell, http://www.matthew-west.org.uk/Publications.html), его корни лежат в моделировании данных при разработке программных средств. Те, кто воспринял этот онтологический подход, двигаются сегодня к применению уже готовых инструментов семантического веба (http://semanticweb.org/) и вдобавок к исключительно моделированию данных и интеграции данных начинают эксперименты по логическому выводу (reasoning), таким образом обеспечивая "исполнение" ("executing") онтологических моделей. Интересно, что UML не слишком распространен в онтологических кругах, а OMG озабочена совмещением (mapping) метамоделей MDA/MOF и разработанных вне OMG "верхних" и "средних" онтологий (http://www.omg.org/ontology). Нужно заметить, что большинство онтологов (или модельеров данных) вышли из программистов, программных аналитиков и архитекторов баз данных, т.е. из областей, которые де факто сейчас часть программной инженерии, а не системной инженерии.

Языковые рабочие места -- это новые IDE, специально посвященные созданию связанных наборов DSL (http://martinfowler.com/articles/languageWorkbench.html). Эту парадигму для разработки программных средств пробуют сейчас не слишком много разработчиков (http://martinfowler.com/bliki/IntentionalSoftware.html). Разработка "языконезависимого интерпретатора/компилятора" и "языконезависимого (в т.ч. графического) редактора" является очень сложной задачей. Зато перспективы очень заманчивы: каждый эксперт-непрограммист может получить собственный кастомизированный (инженерный, финансовый, управленческий и т.д.) DSL, и все эти DSL, адресующие множество различных интересов заинтересованных сторон, будут работать совместно. Более того, эти отдельные обеспечивающие разделение интересов (separation of concerns) описания далее могут обрабатываться различными способами и для различных нужд: проверяться на непротиворечивость, транслироваться на выходные языки, используемые затем заводскими обрабатывающими инструментальными центрами, транслироваться в исполняемые имитационные модели и т.д.. Благодаря свободе выбора языков, это может быть лучше, чем MDA/UML (или MDA/SysML), и так же предотвращать потерю связности общей модели. Сейчас это движение исключительно программистов, системные инженеры не знают об этом DSL-тренде в целом и тренде разработки языковых рабочих мест в частности.

Системная инженерия может, как обычно, ждать 10 лет до заимствования из программной инженерии этих новых подходов к моделированию, или начинать экспериментировать с новыми технологиями немедленно. Моделеориентированная системная инженерия не должна быть синонимом SysML-ориентированной системной инженерии. SysML -- это только отправной пункт для моделеориентированной системной инженерии, а не пункт назначения.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 18 comments