Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

SysMoLan Studio

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

Текущие языки системного моделирования (SysML, AADL, Capella для моделирования целевых систем, UML для моделирования программных систем, ArchiMate для моделирования предприятий, SyM для связи системного и мультифизического моделирования в Modelica) не дают этих возможностей. Проект SysArchi, предпринятый Русским отделением INCOSE в 2018 году показал, что системное моделирование целевых и обеспечивающих систем в рамках ArchiMate 3.0 крайне неудобно, а традиционных языках системного моделирования по факту невозможно моделировать предприятие.

Исследовательский проект .15926 TechInvestLab по созданию моделера и платформы инженерного моделирования на базе инженерной онтологии и форматов языка ISO 15926 показал неудобство работы с низкоуровневыми представлениями для концептуального моделирования и подчеркнул необходимость использования языка программирования как для описания моделей, так и для манипуляций с моделями (создание моделей, запросы к модели). Сам проект .15926 имел акцент на создание системы мэппинга (интеграции данных) инженерных моделей, полученных в составе различных систем и меньше уделял внимание на аспектах создания системных моделей инженерами. В то же время проект .15926 показал, что программное создание объектов моделирования и представление моделей систем в текстовом и псевдографическом виде очень и очень перспективно, графические же представления "визуального моделирования" ограничены в их использовании. Это положение примата текстового представления для манипулирования большими и подробными моделями было подробно обосновано в книге А.Левенчука "Визуальное мышление. Доклад о том, почему им нельзя обольщаться". Проект по моделеориентированному концептуальному проектированию с использованием визуальных представлений на ArchiMate и манипулированием этими представлениями из языка R показал перспективность подхода использования языка программирования для работы с архитектурными системными моделями так же, как .15926 показал это для моделей интеграции инженерных данных (проект описан в книге В.Мизгулина "Системный инженер. Как начать карьеру в новом технологическом укладе").

По итогам этого исследовательского проекта TechInvesLab и русское отделение INCOSE в 2015 году выступили с инициативой создания языка системного моделирования SysMoLan, который преодолеет недостатки существующих архитектурных языков и сможет как синтаксически удобно выражать знания по структурам целевой и обеспечивающей системы, так и решать задачи интеграции данных (мэппинга различных инженерных моделеров).

В 2018 году эта инициатива получила развитие: было предложено реализовать SysMoLan как встроенный предметно-ориентированный язык (DSL) в рамках языка технических вычислений Julia. Этот же выбор сделали авторы языка инженерного моделирования Modelica, создавшие DSL Modia в Julia. Выбор Julia как хост-языка для языка системного моделирования помогает решить множество задач, плохо решаемых при других архитектурных решениях: проблемы расширения системного языка, взаимодействие различных видов инженерных моделей и моделей предприятия, наличие языка запросов к создаваемой модели, возможность оптимизации моделей (дифференцируемое программирование).

Ещё одно направление предварительное направление исследовательских работ касалось сред моделирования, которые развивались в некоторое подобие PLM-системы, в которых использовался датацентрический "прожекторный" подход с хранением всех данных (программ, моделей, параметров моделей, "скриптов" отдельных расчётов) с учётом управления конфигурацией и изменениями. Появилось множество примеров подобных систем управления конфигурацией и изменениями, интегрированных с различными вариантами моделеров (прежде всего речь идёт о связке CAD+разнообразные инженерные моделиры+PLM), аналогичные системы появлялись и в области моделирования архитектуры предприятия. В программировании за подобными системами закрепилось наименование "студии".

Предлагается создать SysMoLan Studio, представлящую из себя моделер и платформу системного моделирования для целевых и обеспечивающих систем. Моделер этой системы "из коробки" должен поддерживать ведение системных холархий (breakdown structures: system, product, work, etc. -- в соответствии со стандартом IEC81346) и описания входящих в них систем, в то же время предоставляя возможность для верхнеуровневого (архитектурного) описания систем и подсистем, входящих в эти холархии в соответствии со стандартом ISO42010. Первоначальный акцент в моделировании будет на создание структурных моделей целевых и обеспечивающих систем, а не на задачи мэппинга. Проще всего думать о SysMoLan Studio как об "Archi для системного языка", но в отличие от Archi там будет:
-- высокоуровневый язык системного моделирования SysMoLan, в котором удобно моделировать архитектуры и потребности/требования как целевых систем, так и обеспечивающих систем
-- параллельное представление на текстовом DSL-в-Julia и псевдографических отображениях (двустороннее "связывание данных", как в модели MVVC).
-- консоль работы с моделью с полноценным языком Julia для аналитических приложений, интеграции данных инженерных моделей, расширений SysMoLan, подключения альтернативных представлений и т.д.

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

Подробности:
-- цепочка текстов "SysMoLan" -- https://ailev.livejournal.com/1443879.html
-- проект "студии" -- https://ailev.livejournal.com/1280626.html (и там trainer studio, systems engineering studio, conceptual studio)
-- .15926 Editor and Platform -- https://github.com/TechInvestLab/dot15926
-- SysArchi -- системное моделирование в ArchiMate 3.0 -- https://ailev.livejournal.com/1444887.html
-- В.Мизгулин, "Системный инженер. Как начать карьеру в новом технологическом укладе" -- https://www.litres.ru/vyacheslav-mizgulin/sistemnyy-inzhener-kak-nachat-kareru-v-novom-tehnologicheskom-uklade/
-- А.Левенчук, "Визуальное мышление. Доклад о том, почему им нельзя обольщаться" -- https://ailev.livejournal.com/1437344.html
-- поиск-ориентированая инженерия -- https://ailev.livejournal.com/1122876.html
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 45 comments

vvagr

September 24 2018, 16:32:39 UTC 1 month ago Edited:  September 24 2018, 16:36:06 UTC

"Моделер этой системы "из коробки" должен поддерживать ведение системных холархий (breakdown structures: system, product, work, etc. -- в соответствии со стандартом IEC81346) и описания входящих в них систем, в то же время предоставляя возможность для верхнеуровневого (архитектурного) описания систем и подсистем, входящих в эти холархии в соответствии со стандартом ISO42010. "

Хотелось бы понимать - что значит "описания входящих в них систем" и "предоставляя возможность для верхнеуровневого (архитектурного) описания".
Описания входящих в них систем -- это разные view, описывающие систему на том или ином уровне системной иерархии. Я просто уточнил, что для первой реализации мне было бы достаточно иметь архитектурные view уровня детальности как в SysArchi (а не какие-нибудь view трёхмерных моделей с моделями для метода конечных элементов из САПР). Но редактор таких view хотелось бы иметь "из коробки", сразу после редактора разбиений. То есть хотелось бы прямо управлять конфигурацией (разбиения) и моделировать архитектуру как-то более детально и удобно, чем просто указывая разбиения.
И второй важный вопрос - должна ли первая версия кроме холархий поддерживать классификаторы. Я утверждаю что должна. И тогда вопрос - на каких классификаторах верхнего уровня (онтологиях или онтиках) основываться? Означают ли ссылки на IEC81346 и 42010 что просто из этих стандартов тупо берутся списки объектов, и используются как типы для объектов, создаваемых в моделлере?
Вот я не уверен, что мы можем обойтись лишь is_a и is_part_of (это пахнет "семантическими сетями" из далёких 80-х, я ещё в середине 80-х делал моделер с такими двумя типами отношений). А какую онтику вообще брать на верхнем уровне, нужно обсуждать отдельно. Опыт ведь подсказывает, что тупо взятые из стандарта онтики оказываются потом кривыми, и мало что добавляют, кроме фразы "соответствуют стандарту".
"Вот я не уверен, что мы можем обойтись лишь is_a и is_part_of"
А можно пример, где нужно ещё что-то, кроме "is"?
"Вот я не уверен, что мы можем обойтись лишь is_a и is_part_of"
А можно пример, где нужно ещё что-то, кроме "is"?

ailev

1 month ago

fractaler

1 month ago

ailev

1 month ago

fractaler

1 month ago

ailev

1 month ago

fractaler

1 month ago

ailev

1 month ago

fractaler

1 month ago

fractaler

1 month ago

И тогда вопрос - на каких классификаторах верхнего уровня (онтологиях или онтиках) основываться?

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

vit_r

1 month ago

vvagr

1 month ago

vit_r

1 month ago

vvagr

1 month ago

vit_r

1 month ago

ailev

1 month ago

vit_r

1 month ago

Для начала хорошо бы формально описать модель. А лучше несколько. На чём угодно - JSON, S-expressions, Python, на любом придуманном прямо сейчас псевдо-языке. Как цель, для чего должен быть удобен этот SysMoLan.

А после рассмотреть эти модели с позиций предшествовавших инструментов и стандартов (включая и проект .15926), чтобы понять, почему они там непредставимы (или представимы с существенным неудобством и когнитивным/машинным boilerplate). Иначе ошибки прошлого будут повторены опять и снова.
Конечно. С двумя замечаниями:
-- ошибки в языке всё одно будут сделаны.
-- поскольку текущая команда нацелена существенно на учебные применения и мечтает о каких-то графических view "для менеджеров", то представимость моделей и ужасы реализации при всех заявлениях о текстовой части будут проверяться на графических view. И мечта о полноценном языке моделирования тут может сильно скукожиться. Архитектурно это самое сложное: чисто текстовый инструмент реализовать не дадут, а графическое представление может убить проект с самой расшикарной формальной моделью. Меня это пугает больше всего. Но акцент на моделировании "для людей" (человек как интерпретатор модели), а не на мэппинге (компьютер как интерпретатор модели). Хотя компьютерные преобразования модели, конечно, предусматриваются "из коробки".

Я бы, конечно, тоже формально описывал модель сначала (язык SysMoLan), а о том, как будут выглядеть графические view в Editor и как реализацию новых view описывать на Platform, обсуждал потом.

Пока я лишь помню, что описать какую-то систему с предприятием на архитектурном самом верхнем уровне в ArchiMate можно (несмотря на невероятную онтологическую кривость тамошней только относительно формальной модели -- кривости указаны, например, в материалах по SysArchi), а в .15926 что-то описать архитектурно было запретительно трудно -- и механика с паттернами не помогала, паттернов было слишком много, и они были слишком формальны. Онтологически корректные модели никто не мог моделировать, а .15926 онтологическую кривизну не поощрял. Так что "уровень онтологичности языка" тут обсуждаемая штука.

Ну, и накопилось некоторое количество идей в ходе разработки SysMoLan (там ведь много чего в комментах раскидано в постах 2015 года), их нужно достать в связи с новыми вводными данными -- уроки прошлых проектов были ещё свежи в голове. Тут ещё проблема в том, что формальную модель сразу можно было бы писать на Julia (использовать ли тамошние графовые пакеты, универсальные языки запросов и т.д. -- открытый). Но Julia и тамошнюю экосистему толком пока никто не знает из разработчиков. Я бы прежде всего опыт Modia (Modelica на Julia) изучал там, хотя этот опыт очень специфический, конечно.

justy_tylor

1 month ago

ailev

1 month ago

justy_tylor

1 month ago

vit_r

1 month ago

ailev

1 month ago

justy_tylor

1 month ago

ailev

1 month ago

Для создания языков нужны лингвисты.
Только единожды за историю была ситуация, когда лингвист написал хоть как-то жизнеспособный язык программирования. Увы, результат оказался весьма write-only на проектах больше "админского скрипта". Статьи, которые Ларри написал в процессе разработки Perl 6, намного интереснее, чем сами новые и старые версии Perl.

Для понимания и создания языков программирования полезно знакомство с материалами лингвистики и когнитивной лингвистики. Но помимо этого нужно хорошо понимать предметную область. Например, так: https://justy-tylor.livejournal.com/252880.html

vit_r

1 month ago

justy_tylor

1 month ago

vit_r

1 month ago

justy_tylor

1 month ago

vit_r

1 month ago

justy_tylor

1 month ago

По опыту построения "Architecture as code" и ковыряния с Archi - технически все не так сложно.
У меня была задача заставить архитекторов следовать Hypothsis Driven Development. Рекомендация - моделировать изменения атомарно, используя Drivers,
Goals,
Stakeholders,
Outcomes,
Assessments,
Capabilities
с использованием Архимейта. (где влияние школы я думаю понятно). Концепция - архитектура и код нужно контролировать одинаково. Взяли Архи и разобрали xml формат в котором редактор хранит модели и viewpoints. С помощью (лома и azure) написали тесты к XML файлам и закрепили тесты стандартными средствами visual studio team service ( можно github или bitbucket) на проверку Pull Requestов. Таким образом получилось: архитектор или группа архитекторов забирает модель из git репозитория с git pull & git checkout. После обсуждения изменение документируется в архимейте и git push в отдельную ветку. В своей ветке архитектор может делать что хочет. Для перехода в следующую стадию нужно сделать Pull Request в основной репозиторий. При создании pull request c помощью webhooks срабатывают тесты и не дают пройти изменению если оно не соответствует атомарности (одна гипотиза за раз) или нет изменений в IT системе (архитектор ты работу не доделал). Если все тесты прошли PR можно Approve и тогда изменение входит в основную модель. В этот же момент можно задать webhook действие в DevOps стек - создать новый проект в jira для разработчиков и полную dev ops pipe line для продолжения изменения в релиз.

Итак, это было вступление. по поводу моделлера:
моделер нужно рассматривать как часть эко системы и надо демонстрировать ценность не только на уровне альф архитектуры/дизайна, но и далее по жизненному циклу - IMHO visual paradigm много теряет отказываясь интегрироваться с Jira/github.

Если оттолкнуться от github или bitbucket как репозиторий основного (основных) описание, и использовать родные инструменты git pull/git push/git commit + pull request для контроля конфигураций и разрешения конфликта то платформа для написания плагинов уже есть и множество кубиков:
* Например Archi модель можно выгрузить в Neo4J и использовать стандартные стредства визуализации и обработки данных графовой базы
* Опять же Archi можно выгрузить и в postres sql и прикрутить yED интерфейс через java/c#.
* через какой нибудь Javascript D3 написать github diff плагин для archi, это решит проблему коллаборативной работы.

А главное если модель живет как код и следует правилам обращения с кодом можно писать обработку модели и в Julia и в Java/Whatever с условием что токен действия и полное описание передаются через гитхаб.


Абсолютно согласен, примерно так и думаю. Любой моделер сам по себе должен втыкаться с систему версионирования (где хранятся результаты моделирования и другими моделерами тоже) и систему управления изменениями (issue tracker). У меня об этом большой комплект статей был про студии -- https://ailev.livejournal.com/1280626.html (он есть в списке "литературы", и там внутри по ссылкам всё подробней прописано).
да, я это все прочитал поэтому и откоментировал: мое предложение сместить точку обсуждения и первоначальной работы с IDE/Jupyter/VS code/Eclipse на: это средство автоматизации архитектуры, "настройка" над гитхабом, которая живет в начале жизненного цикла. Моделер должен не втыкаться в трекер и систему версионирования, а возглавить.

ailev

3 weeks ago