Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Язык системного моделирования

Меня включили в некоторую весьма специфическую частную переписку по поводу MBSE, аргументы сторон этой переписки были примерно следующие:
-- ничего "системного" в вашей MBSE нет, только обрывки. Какое-то моделирование систем было и раньше, та же системная динамика. Системного языка и системной инженерии вы не развиваете, это всё языки описания систем и развитие инженерии систем -- к системной инженерии и системному подходу это отношения не имеет. В SysML систем нет. SysML и Modelica про "моделирование систем", а не про "системное моделирование". Мозги с хорошо поставленным системным мышлением ваше моделирование не поддержит, а только отразит бледным светом уже принятые без подобного моделирования уникальные инженерные решения.
-- наоборот, это у вас не системная инженерия, а системные humanities (искусства, истории, философия и прочие байки с иллюстрациями), сплошное blah-blah-blah. Пока не будет формальных методов, не будет инженерии. То есть у вас не системная инженерия, а системные humanities. А у нас хоть и не системные, но модельки, и мы вдесятеро быстрее работаем часто на тех же задачах, ибо с blah-blah-blah переходим на прямые вычисления или логический вывод.

Ужас ситуации в том, что правы обе стороны: MBSE сегодняшнее это про "моделирование систем" и точно не "системное моделирование", а классическая системная инженерия -- это humanities, формальных общепринятых средств выражения для основного своего понятия ("система") нет.

Это существенно сказывается и на способе обучения студентов: сегодня им дают отдельно формальные дисциплины (математику, программирование, моделирование в разных языках), а отдельно -- рассказывают много-много баек про применение системного подхода в жизни, с многочисленными неформальными иллюстрациями типа V-диаграммы. Это мгновенно проявляется, когда обсуждается организация онлайн-курсов: курсы по системной инженерии ожидалось бы, что больше похожи на курсы по программированию или физики, а они оказываются больше похожими на курсы по humanities.

Тут нужно также помянуть про трудности верхнеуровневого моделирования (неочевидность полезности моделирования в его текущем виде, неудержание целостности на этом верхнем уровне, отсутствие моделера, непонятность моделей ключевым стейкхолдерам, отсутствие практик коллективного моделирования, отсутствие практики накопления знаний моделирования, хотя бы в форме библиотек -- подробнее в http://ailev.livejournal.com/1056723.html).

На мой взгляд, ситуацию решит в формальный язык системного моделирования, который:

1. будет основан в том числе на логицистской линии введения формальности в предмет (подробнее в http://ailev.livejournal.com/1059168.html), и не будет зациклен исключительно на матане и матстатистике. Формализация -- это про формальные рассуждения прежде всего, и только во вторую очередь про квантификацию.

2. будет содержать "из коробки" понятие системы (в том числе модуля, жизненного цикла и т.д.) во всём его разнообразии (подробнее в докладе "О понятии системы в системной инженерии" http://ailev.livejournal.com/1056311.html), что требует и особого представления времени (а именно, 4D), и поддержки экстенсионализма (для совмещения функциональных и физических объектов), и много других онтологических выборов.

3. будет содержать вариант Upper Ontology, чтобы задавать общую картину мира для всех мэппящихся затем к системным моделям предметным моделям (это означает, что онтологических выборов, определяемых по пункту 2 -- много больше. Там и мереология, и что такое информация, и что такое модель, и как выражать единицы измерения, и много-много разного другого).

4. будет основан на факт-ориентированной парадигме, а не программистской объект-ориентированной (чтобы избежать ситуации "что для одного проекта объект, то для другого атрибут, и наоборот"

5. будет поддерживать минимально следующие синтаксисы:
-- абстрактный (т.е. формально определять концепты -- т.е. при полном отсутствии определения любых объектов в связи с какими-то характеристиками нотации/презентации), но с сериализацией (чтобы иметь возможность передачи моделей из одного моделера в другой) для абстрактной модели
-- текстовый (чтобы иметь возможность работать с большими моделями)
-- графический (чтобы быть максимально выразительным на маленьких модельках, т.е. для презентационных целей)

6. будет иметь штатные возможности расширения (т.е. поддерживать модульность в самом языке -- можно вспомнить про "онтолеты" или "моделеты", использование паттернов для формулирования DSL, поддержку библиотек как в той же Modelica, или поддержку библиотек паттернов моделирования, позволять метаописание других уровней языка, если в этом возникает необходимость -- это прямая отсылка к дискуссии о DSL, повторение рассуждений, которые привели к созданию MOF -- http://ailev.livejournal.com/1053878.html). Тут пока целина непахана.

7. обеспечит формальность (т.е. будет иметь формально проверяемую непротиворечивость и безошибочность моделей), но при этом не требуется decidability (приемлемого времени логического вывода). Это означает, что совсем необязательно использовать какие-то подмножества классических логик первого порядка, или даже полный вариант FOL. Вполне возможны варианты современных логик, в том числе логик высокого порядка. Это очень спорные требования, но на эту тему есть обширная дискуссия, и это осознанный дизайн-выбор.

8. будет поддерживать "из коробки" стык с численными моделями (например, модели могут обсчитываться, как модели на Modelica -- но при этом структурирование модели делается стандартными возможностями языка по описанию систем. Это примерно та же линия рассуждений, которая заставляет людей из комьюнити SysML думать о связке с Modelica. Но Modelica -- это совсем-совсем другой синтаксис, плюс объект-ориентированность, так что нужно "переизобрести" моделику, сделать её по-настоящему встроенной в язык системного моделирования). Как именно поддерживать стык с численными моделями нужно подглядывать у Simantics (http://simantics.org).

9. Поскольку будет "из коробки" понятие модуля/подсистемы, то возможно и встраивание constraints для них (это может быть выходом на contract-based design и другие методы оптимизации дизайна, подробнее в http://incose-ru.livejournal.com/31890.html).

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

11. будет понятно выражать информацию не только о самой целевой системе и её операционном окружении, но и информацию об обеспечивающей системе, задающей жизненный цикл системы (например, развивая линию OMG Essence -- http://ailev.livejournal.com/1051048.html).

12. Будет поддержан современным моделером (т.е. язык без реализации его -- это не язык, а хотелка, упражнение в фантазии), подробнее про критерии современности моделера -- http://ailev.livejournal.com/1041274.html

Какие у нас будут плюшки после появления этого языка? А такие же, как у физиков, когда они воспользовались математикой, и программистов, когда они закладывали основы современного компьютинга: появится системное моделирование, и с этого момента humanities традиция в области системной инженерии будет постепенно превращаться в более-менее традиционную формальную дисциплину. У системных инженеров появится своя письменность, знания будут накапливаться в том числе и формальные (т.е. будут появляться библиотеки архитектурных решений, например), а предметные модельки будут эффективно объединяться.

MBSE сможет перейти в MDSE (http://ailev.livejournal.com/1015692.html), т.е. от поглядывания на свои модели как вспомогательные, хотя и крайне полезные артефакты, системный инженер будет использовать менее детальные и более асбтрактные модели как основные свои выходные рабочие продукты, воплощающий результаты своего труда (сейчас этими воплощающими системное мышление результатами являются тонны самых разных полуформальных диаграмм, текстовых документов и верхние уровни предметных моделей). К этим моделям будет применим generative design и generative manufacturing подход, когда добавляя справочные данные, мы в диалоге получаем более детальные и менее абстрактные модели, доходя до предметных моделей, в том числе таких моделей, которые являются программами по изготовлению и сборке целевой системы.

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

С чего начать, если реализовывать такой проект?

С абстрактного синтаксиса и его сериализации, проверяя, как укладывается в него понятие "система". Для этой цели лучше всего подходит пока ISO 15926, но именно в части понятия "система" были исследования Мэтью Веста с его HQDM. Сериализация, хотя и не идеальная, есть в ISO 15926. HQDM, в принципе, имеет мэппинг в ISO 15926. Так что с этим вполне можно разобраться.

Затем нужен какой-то внешний синтаксис, позволяющий моделировать быстро, наглядно, и в больших количествах. Это может быть поначалу и текстовый синтаксис. Затем почти сразу потребуется графический синтаксис, и здесь нам может быть в помощь подход к диаграммам, предлагаемый книжкой BORO и какое-нибудь средство саморазводки типа тех, что используются в yEd (http://ailev.livejournal.com/1052859.html).

Потом нужно будет победить средства расширения языка и явно обеспечить его модульность.

В общем, двигаться нужно последовательно по каждому из указанных пунктов, и везде искать какие-то уже имеющиеся прототипы и частные решения, которые можно было бы взять в работу.
.
Собственно, какой-то начальный набор "системных" паттернов в ISO 15926 и поддержка в .15926 Editor внятной нотации для моделирования в этих "системных" паттернах спасли бы в части начальных экспериментов. Ибо в абстрактном синтаксисе и его деревянном отображении много не намоделируешь, а выразительность "родных" диаграмм оставляет желать (плюс это диаграммы Части 2, а с тех пор у нас появились и темплейты, и паттерны -- для них же ничего ещё не придумано), чтобы трудиться их реализовывать. Может быть, какой-то простейший текстовый синтаксис спасёт, а может быть и какие-то другие нотационные идеи.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 16 comments