Каким бы мог быть мегамоделер
Мультимодель -- это совокупность моделей всех частных описаний (view) из полного системного описания (system description). Мегамодель была изначально введена как онтология для model-driven engineering (model driven engineering, https://en.wikipedia.org/wiki/Model-driven_engineering, а сам термин из статьи 2004г. http://www-adele.imag.fr/Les.Publications/intConferences/SETRAa2004Fav.pdf). Вся эта "моделеориентированная инженерия" всё никак не взлетит, ибо моделировать на хорошем языке программирования (текстовом!) оказывается обычно не хуже, чем на хорошем языке моделирования -- но без этой головной боли по переключению между самыми разными парадигмами моделирования, моделерами, IDE и т.д.. Поэтому позаимствуем слово и чуть-чуть подправим его значение: мегамодель у нас будет совокупностью системного описания и оформляющих интересы стейкхолдеров методов описания (viewpoint, главным в котором являются метамодели aka спецификации языков описаний, языки описания метамоделей и так далее "до самого верха" абстракций). Коннективистские модели добавляют сюда пикантности и непоняток, но и с ними разберёмся, чуть попозже. Итого: сумма всех view и viewpoint системы (включая оригинальное намерение авторов термина -- включая view и viewpoint на сами эти термины veiw и veiwpoint) -- это и есть мегамодель.
Если есть модель, то есть метод описания, если есть метод описания, то есть и поддерживающий её инструмент: моделер. Я склонен считать метод описания не только дисциплиной, но и практикой, включающей всё необходимое для описания -- то есть и инструменты тоже, и даже практические примеры для образца. Моделер входит в практику моделирования. Если есть мегамодель, то есть и мегамоделирование (т.е. моделирование, метамоделирование, трансформации моделей и т.д., а также выход на онтологизирование и программирование и даже проектирование -- всё, что обсуждается в системной информатике: http://ailev.livejournal.com/1272169.html) -- значит, есть и мегамоделер.
Я уже делал заход на формулирование критериев оценки софта для моделирования в http://ailev.livejournal.com/1041274.html. Сейчас же я попробую более подробно прописать, как мог бы выглядеть мегамоделер с позиций системной информатики.
Первый же постулат -- поскольку речь идёт о программировании-моделировании-онтологизировании-проектировании, мегамоделер должен совмещать функции:
-- редактора формальных текстов [vim, atom], графового редактора [yEd], табличного редактора [Excel], редактора неформальных текстов с картинками [Word, PowerPoint]
-- моделеры, [Meta-edit, Eclipse EMF, классические UML/SysML моделеры]
-- мэпперы [наш редактор онтологий dot15926]
-- 3D моделера [NX, CATIA, Inventor], 2D моделера [Photoshop, Illustrator]
-- IDE языка программирования, [IntelliJ, тот же Eclipse]
-- математического пакета [Matematica, Jupyther, MATCAD, SimuLink, Modelica]
-- PLM, ALM [ENOVIA, Teamcenter, Jazz и даже GitHub, отчасти и Simantics в части работы с метаданными -- всё, что про управление конфигурацией и изменениями, а в силу этого про интеграцию данных и мастер-данные]
Эти функции общие для всех мегамоделеров, это "беспредметное ядро" -- их нужно наследовать от инструмента для построения мегамоделеров, от systems framework.
Чтобы стать мегамоделером, нужно добавить к такому "системному движку" набор плагинов-viewpoints, как к игровому движку добавляют собственно игру и её моды. Дальше это уже не "движок", а "игра", т.е. не systems framework, а "мегамоделер таких-то систем".
Весь этот зверинец ползёт в сторону обеспечения мегамодели, которая состоит в том числе из множества view в различных viewpoint, правил их комплексирования и трансформации. Мы понимаем при этом, что речь идёт и о программах, и об онтологиях, и о "просто моделях" -- описания системы могут оказаться текстами, трёхмерными моделями, факт-ориентированными и объектными диаграммами, а также алгоритмами на языках программирования или языках мэппинга и запросов. Как нам сделать такой софт, который вытянет весь этот зверинец? А ещё лучше -- не сделать, а просто взять готовый!
Прежде всего, мы видим, что весь помянутый софт systems framework медленно дрейфует в этом направлении поддержки системной информатики, в направлении унификации мегамоделирования-мегапрограммирования. Главные тренды в нём:
-- многоязыкость "из коробки" (Atom настраивается на разные языки, Eclipse поддерживает разные языки, Jupyther имеет разные языковые ядра]
-- программируемость "снизу доверху" [атом определяется как hackable text editor, даже Word программируется на Visual Basic, в .15926 консоль Питона выведена на переднюю панель]
-- разделение редактора-фронтэнда и PLM/ALM бэкенда [раньше редактор держал всё "внутри себя"], и уж как минимум стыковка с системами ведения версий [git] и issue trackers [это реже, но и тут полно "плагинов к Redmine" или чего-то подобного]
-- хитрая вёрстка разных view (в том числе view для viewpoint -- всякие справки, палитры и т.д.): от одного окна к нескольким синхронизированным, к окнам-ноутбукам с множеством ячеек. Алан Кей давно говорил, что приложения скоро будут верстаться -- вот это оно.
-- облачность и распределённость (аспект location для инструмента), в том числе распределённые репозитории и реестры http://ailev.livejournal.com/1259878.html подсистем управления конфигурацией и изменениями
-- возможность коллективного редактирования [Google Docs, Autodesk Fusion]
-- проход на поздние стадии жизненного цикла (стык с софтом DevOp, поддержка testing и deployment)
Для меня тут выделяются (коммерческие продукты я пока не рассматриваю, но там тоже кое-что в этом направлении делается):
-- Eclipse (платформа, поддерживающая и классические программистские IDE, даже Julia -- http://juliacomputing.com/blog/2016/02/06/Eclipse-JuliaDT.html, даже Modelica -- https://www.openmodelica.org/doc/OpenModelicaUsersGuide/latest/mdt.html, и чисто "редакторы моделей" -- тот же Archi как раз отсюда). Монстр, поддерживает вёрстку множества различных view, обслуживающих разные viewpoint в рамках одного приложения "из коробки". Только что вышел очередной релиз Eclipse, Neon -- https://www.eclipse.org/neon/noteworthy/. Тяжёлый и универсальный инструмент.
-- Jupyter, поддержка не столько "многооконности", сколько "многоклеточности" в рамках одного окна -- зоны комментариев, кода, input и output вполне себе верстаются в рамках одного view на язык. Сам же framework хостит уже более 40 языков вычислительного компьютинга. Это лёгкий и нацеленный на вычислительные модели инструмент для вычислительных приложений (interactive data science and scientific computing).
Честно говоря, наш .15926 тоже развивался в эту сторону "универсальной платформы мегамоделирования" aka systems framework, только всего там было мало: основной язык один, разделения на бэкенд и фронтэнд не произошло (но revisions и merges поддерживались), разнообразие view было предусмотрено, но по факту реализовалось хорошо только "бесконечное дерево" для представления графов онтологий -- https://github.com/TechInvestLab/dot15926. Получился не совсем "мегамоделер данных жизненного цикла" (хотя замах какой-то на это был), а "просто моделер онтологий ISO 15925 и отчасти OWL", эдакий "эксель для онтологий", программировать работу с данными в котором можно было влёгкую из Питона, а данные были не столько табличны (хотя с Exel там был реализован стык!), сколько онтологичны -- триплы. Замысел же был -- наращивать число доступных view в других представлениях (кроме табличного и онтологического, работать с просто текстами, и дальше по всему списку потребностей -- архитектура позволяла, разве что язык программирования при этом должен был быть Питоном).
Интересно, что моделеориентированность (все эти model-driven engineering, architecture, programming и т.д.) в инженерии не выживает по факту. Архитектурные графические языки по большому счёту маргинальны, исполняемые архитектуры маргинальны, графические standalone DSL оказываются маргинальны -- и потому что самих архитекторов мало, и потому как блок схемы при росте объема кода становятся неконкурентоспособными по сравнению с текстами. А в текстовых языках выигрывают:
-- либо регулярные способы представления кучерявых данных (базы данных, безо всяких претензий на "специальный графический язык" или даже "специальный удобный текстовый язык"), если обработки рутинны и однообразны (они уходят в код "бизнес-логики"),
-- либо регулярные способы представления кучерявых обработок (программы, возможно на расширяемом языке программирования, возможно и с доступом к базе данных со сваянной "на коленке" схемой).
Все же эти "сначала сделаем красивую модель, потом из неё получим код" превращаются в "сначала напишем высокоуровневый код, а потом из него либо макросгенерим, либо просто выполним код уровнем пониже -- если там окажется много данных, положим их в базу данных или даже в простой JSON, ибо XML уже давно отстой и мы забыли, что он предназначался для выражения сложноструктурных данных без баз данных". Моделирование таки заменилось программированием, онтологизирование осталось наколеночным моделированием данных ad hoc (работают с онтиками, а не онтологиями -- без автоматизации понимания значений дальше не пройти, онтологии запредельно трудоёмки по их созданию и использованию).
Остались ли DSL? Да, остались -- но тренд на их "особость" и разнообразный инструментарий по их созданию сошли на нет: языки продолжают плодиться, а вот language workbenches стухли (похоже, что гонка на http://www.languageworkbenches.net/ закончилась в 2014, про intentional programming тоже мало кто вспоминает -- https://en.wikipedia.org/wiki/Intentional_programming), и даже поменяли название с оригинального workbench на более приживающийся для разных платформ framework. Многоязыковость царит, но DSL оказались внутренние (вмазанные в расширяемый хост-язык), в сочетании с развивающимися активно платформами вёрстки множества view для разных viewpoints, которая была описана выше -- а все средства автоматизации по созданию языков, компиляторов и редакторов ушли немедленно внутрь этих платформ. Standalone не выжили ни DSL, ни средства их создания: каждый DSL оказался втянут в экосистему, где его пишут (руками или другим кодом), он сам вычисляется-оценивается на каких-то данных (которые тоже откуда-то берутся в каком-то формате), и при этом порождает тоже какой-то вывод (код, или данные). А средства создания оказались втянуты в необходимость поддерживать все эти окошки-окошки или ноутбуки, фронтэнды, бэкенды и т.д. в современных мегамоделерах (где существенная часть моделей оказалась программными исполняемыми моделями на полнотьюринговых языках, а другая существенная часть моделей оказалась моделями в базах данных -- в том числе разных вариантах NoSQL базах).
Теперь нужно поглядеть на пост про системную информатику (http://ailev.livejournal.com/1272169.html) и подумать: куда этот весь инструментарий программирования-моделирования-онтологизирования тащить? Чего не хватает для поддержки системного подхода в информатике?
Мне кажется, что системная информатика показывает единство всех этих редакторов-исполнительных сред-систем управления конфигурацией, показывает принципы мегамоделирования: откуда оно берётся (разнообразие concerns разных стейкхолдеров), каким образом унифицируется (понятия view, viewpoints, привязка их в качестве описаний к воплощению системы, выход на управление конфигурацией, необходимость коллективной разработки, внимание к левой и правой частям V-диаграммы -- т.е. поддержка полного жизненного цикла).
Это означает, что можно осознанно поглядеть на зоопарк редакторов-мэпперов-моделеров-САПР-PLM-и т.д. (см. далеко не полный списочек в начале этого поста) и осознанно прикинуть ту общую точку, куда все эти системы ползут: ползут они к мегамоделеру, который поддерживает множество самых разных фронтэндов для описания системы, находящегося в бэкэнде, плюс надо ещё поддерживать работу обеспечивающей системы. Ключевым тут является то, что view и viewpoints много, а в одной вычислительной системе собрать все view и viewpoints не получится -- так что всё время нужно будет работать с "чужими данными", "чужими моделями", "чужими языками", всем чужим.
Можно идти "снизу" (например, IPython, который пошёл в Jupyter в сторону поддержки коллаборации и многоязыковости -- но в котором не так всё просто с поддержкой множества viewpoints, даже если cells в ноутбуке объявить view, то потом не так просто их модифицировать на ходу -- Eclipse тут сто очков вперёд даст), можно сверху (монструозный Eclipse, который уже перераспух и испытывает все ужасы работы с legacy архитектурой и кодом -- но в котором "окошки" отличненько верстаются и уживаются IDE и моделеры и среда их разработки, но и ему тяжело дотянуться до ALM/PLM поддержки, она сейчас всё больше standalone), можно сбоку и сикось-накось.
Но перед этим нужно сообразить, какова была бы "идеальная архитектура" для среды поддержки системного (с системным подходом в голове) программирования/проектирования/моделирования/онтологизирования -- и сколько из этой архитектуры можно было бы реализовать.
Что тут ещё нужно учесть, чтобы жизнь мёдом не казалась?
-- часть моделей это фото (растровые!), а часть моделей это текст на естественном языке, и поэтому потребуется работа с распределёнными представлениями, нейронные сети и прочие не слишком привычные view. Хотя в ноутбуках Jupyter с этим как-то приноравливаются работать, но там ещё не началась работа с view-viewpoint внутри самих сеток, см., например http://ailev.livejournal.com/1266411.html как шаги ровно в этом направлении нахождения view-viewpoints "внутри сеток". Да, сетки не модульны, но что-то там аналогичное модульности есть, это придётся поддерживать в софте: view в распределённых представлениях будет делиться на какие-то модели в распределённых же представлениях, ансамбли этих моделей и их отладка-вёрстка при разработке тоже могут потребоваться.
-- внутри там должны жить ещё и персональные и групповые агенты-помощники (от предложений автокомплита http://ailev.livejournal.com/1269236.html и предупреждений о конфигурационных коллизиях до более интересных функций: http://ailev.livejournal.com/1254114.html, вплоть до работы на нейроинтерфейсах по замеру когнитивной нагрузки http://openmeta.livejournal.com/236784.html и далее по линии openmeta и нейронета.
Но это всё бантики и заделы на будущее, пока и без этого интересно.
Упражнение "как мог бы выглядеть снаружи (требования) и изнутри (архитектура) мегамоделер с опорой на SysMoLan" я предоставляю читателям. Можно представить SysMoLan как набор расширений для Julia, можно считать что это просто набор всего доступного в языковом плане (а хоть и SysML), собранное в кучку, можно говорить о развитии Modelica и исполняющих её сред во все стороны сразу, можно универсализовать представление view в каком-то из инженерных САПР (а хоть и в Inventor -- мне уже приходилось как-то обсуждать такое). Выборов много, но данный пост предоставляет критерии и рамки для оценки таких выборов, а пост про системную информатику http://ailev.livejournal.com/1272169.html представляет собой критерии и рамки для оценки текущего поста.
Если есть модель, то есть метод описания, если есть метод описания, то есть и поддерживающий её инструмент: моделер. Я склонен считать метод описания не только дисциплиной, но и практикой, включающей всё необходимое для описания -- то есть и инструменты тоже, и даже практические примеры для образца. Моделер входит в практику моделирования. Если есть мегамодель, то есть и мегамоделирование (т.е. моделирование, метамоделирование, трансформации моделей и т.д., а также выход на онтологизирование и программирование и даже проектирование -- всё, что обсуждается в системной информатике: http://ailev.livejournal.com/1272169.html) -- значит, есть и мегамоделер.
Я уже делал заход на формулирование критериев оценки софта для моделирования в http://ailev.livejournal.com/1041274.html. Сейчас же я попробую более подробно прописать, как мог бы выглядеть мегамоделер с позиций системной информатики.
Первый же постулат -- поскольку речь идёт о программировании-моделировании-онтологизировании-проектировании, мегамоделер должен совмещать функции:
-- редактора формальных текстов [vim, atom], графового редактора [yEd], табличного редактора [Excel], редактора неформальных текстов с картинками [Word, PowerPoint]
-- моделеры, [Meta-edit, Eclipse EMF, классические UML/SysML моделеры]
-- мэпперы [наш редактор онтологий dot15926]
-- 3D моделера [NX, CATIA, Inventor], 2D моделера [Photoshop, Illustrator]
-- IDE языка программирования, [IntelliJ, тот же Eclipse]
-- математического пакета [Matematica, Jupyther, MATCAD, SimuLink, Modelica]
-- PLM, ALM [ENOVIA, Teamcenter, Jazz и даже GitHub, отчасти и Simantics в части работы с метаданными -- всё, что про управление конфигурацией и изменениями, а в силу этого про интеграцию данных и мастер-данные]
Эти функции общие для всех мегамоделеров, это "беспредметное ядро" -- их нужно наследовать от инструмента для построения мегамоделеров, от systems framework.
Чтобы стать мегамоделером, нужно добавить к такому "системному движку" набор плагинов-viewpoints, как к игровому движку добавляют собственно игру и её моды. Дальше это уже не "движок", а "игра", т.е. не systems framework, а "мегамоделер таких-то систем".
Весь этот зверинец ползёт в сторону обеспечения мегамодели, которая состоит в том числе из множества view в различных viewpoint, правил их комплексирования и трансформации. Мы понимаем при этом, что речь идёт и о программах, и об онтологиях, и о "просто моделях" -- описания системы могут оказаться текстами, трёхмерными моделями, факт-ориентированными и объектными диаграммами, а также алгоритмами на языках программирования или языках мэппинга и запросов. Как нам сделать такой софт, который вытянет весь этот зверинец? А ещё лучше -- не сделать, а просто взять готовый!
Прежде всего, мы видим, что весь помянутый софт systems framework медленно дрейфует в этом направлении поддержки системной информатики, в направлении унификации мегамоделирования-мегапрограммирования. Главные тренды в нём:
-- многоязыкость "из коробки" (Atom настраивается на разные языки, Eclipse поддерживает разные языки, Jupyther имеет разные языковые ядра]
-- программируемость "снизу доверху" [атом определяется как hackable text editor, даже Word программируется на Visual Basic, в .15926 консоль Питона выведена на переднюю панель]
-- разделение редактора-фронтэнда и PLM/ALM бэкенда [раньше редактор держал всё "внутри себя"], и уж как минимум стыковка с системами ведения версий [git] и issue trackers [это реже, но и тут полно "плагинов к Redmine" или чего-то подобного]
-- хитрая вёрстка разных view (в том числе view для viewpoint -- всякие справки, палитры и т.д.): от одного окна к нескольким синхронизированным, к окнам-ноутбукам с множеством ячеек. Алан Кей давно говорил, что приложения скоро будут верстаться -- вот это оно.
-- облачность и распределённость (аспект location для инструмента), в том числе распределённые репозитории и реестры http://ailev.livejournal.com/1259878.html подсистем управления конфигурацией и изменениями
-- возможность коллективного редактирования [Google Docs, Autodesk Fusion]
-- проход на поздние стадии жизненного цикла (стык с софтом DevOp, поддержка testing и deployment)
Для меня тут выделяются (коммерческие продукты я пока не рассматриваю, но там тоже кое-что в этом направлении делается):
-- Eclipse (платформа, поддерживающая и классические программистские IDE, даже Julia -- http://juliacomputing.com/blog/2016/02/06/Eclipse-JuliaDT.html, даже Modelica -- https://www.openmodelica.org/doc/OpenModelicaUsersGuide/latest/mdt.html, и чисто "редакторы моделей" -- тот же Archi как раз отсюда). Монстр, поддерживает вёрстку множества различных view, обслуживающих разные viewpoint в рамках одного приложения "из коробки". Только что вышел очередной релиз Eclipse, Neon -- https://www.eclipse.org/neon/noteworthy/. Тяжёлый и универсальный инструмент.
-- Jupyter, поддержка не столько "многооконности", сколько "многоклеточности" в рамках одного окна -- зоны комментариев, кода, input и output вполне себе верстаются в рамках одного view на язык. Сам же framework хостит уже более 40 языков вычислительного компьютинга. Это лёгкий и нацеленный на вычислительные модели инструмент для вычислительных приложений (interactive data science and scientific computing).
Честно говоря, наш .15926 тоже развивался в эту сторону "универсальной платформы мегамоделирования" aka systems framework, только всего там было мало: основной язык один, разделения на бэкенд и фронтэнд не произошло (но revisions и merges поддерживались), разнообразие view было предусмотрено, но по факту реализовалось хорошо только "бесконечное дерево" для представления графов онтологий -- https://github.com/TechInvestLab/dot15926. Получился не совсем "мегамоделер данных жизненного цикла" (хотя замах какой-то на это был), а "просто моделер онтологий ISO 15925 и отчасти OWL", эдакий "эксель для онтологий", программировать работу с данными в котором можно было влёгкую из Питона, а данные были не столько табличны (хотя с Exel там был реализован стык!), сколько онтологичны -- триплы. Замысел же был -- наращивать число доступных view в других представлениях (кроме табличного и онтологического, работать с просто текстами, и дальше по всему списку потребностей -- архитектура позволяла, разве что язык программирования при этом должен был быть Питоном).
Интересно, что моделеориентированность (все эти model-driven engineering, architecture, programming и т.д.) в инженерии не выживает по факту. Архитектурные графические языки по большому счёту маргинальны, исполняемые архитектуры маргинальны, графические standalone DSL оказываются маргинальны -- и потому что самих архитекторов мало, и потому как блок схемы при росте объема кода становятся неконкурентоспособными по сравнению с текстами. А в текстовых языках выигрывают:
-- либо регулярные способы представления кучерявых данных (базы данных, безо всяких претензий на "специальный графический язык" или даже "специальный удобный текстовый язык"), если обработки рутинны и однообразны (они уходят в код "бизнес-логики"),
-- либо регулярные способы представления кучерявых обработок (программы, возможно на расширяемом языке программирования, возможно и с доступом к базе данных со сваянной "на коленке" схемой).
Все же эти "сначала сделаем красивую модель, потом из неё получим код" превращаются в "сначала напишем высокоуровневый код, а потом из него либо макросгенерим, либо просто выполним код уровнем пониже -- если там окажется много данных, положим их в базу данных или даже в простой JSON, ибо XML уже давно отстой и мы забыли, что он предназначался для выражения сложноструктурных данных без баз данных". Моделирование таки заменилось программированием, онтологизирование осталось наколеночным моделированием данных ad hoc (работают с онтиками, а не онтологиями -- без автоматизации понимания значений дальше не пройти, онтологии запредельно трудоёмки по их созданию и использованию).
Остались ли DSL? Да, остались -- но тренд на их "особость" и разнообразный инструментарий по их созданию сошли на нет: языки продолжают плодиться, а вот language workbenches стухли (похоже, что гонка на http://www.languageworkbenches.net/ закончилась в 2014, про intentional programming тоже мало кто вспоминает -- https://en.wikipedia.org/wiki/Intentional_programming), и даже поменяли название с оригинального workbench на более приживающийся для разных платформ framework. Многоязыковость царит, но DSL оказались внутренние (вмазанные в расширяемый хост-язык), в сочетании с развивающимися активно платформами вёрстки множества view для разных viewpoints, которая была описана выше -- а все средства автоматизации по созданию языков, компиляторов и редакторов ушли немедленно внутрь этих платформ. Standalone не выжили ни DSL, ни средства их создания: каждый DSL оказался втянут в экосистему, где его пишут (руками или другим кодом), он сам вычисляется-оценивается на каких-то данных (которые тоже откуда-то берутся в каком-то формате), и при этом порождает тоже какой-то вывод (код, или данные). А средства создания оказались втянуты в необходимость поддерживать все эти окошки-окошки или ноутбуки, фронтэнды, бэкенды и т.д. в современных мегамоделерах (где существенная часть моделей оказалась программными исполняемыми моделями на полнотьюринговых языках, а другая существенная часть моделей оказалась моделями в базах данных -- в том числе разных вариантах NoSQL базах).
Теперь нужно поглядеть на пост про системную информатику (http://ailev.livejournal.com/1272169.html) и подумать: куда этот весь инструментарий программирования-моделирования-онтологизирования тащить? Чего не хватает для поддержки системного подхода в информатике?
Мне кажется, что системная информатика показывает единство всех этих редакторов-исполнительных сред-систем управления конфигурацией, показывает принципы мегамоделирования: откуда оно берётся (разнообразие concerns разных стейкхолдеров), каким образом унифицируется (понятия view, viewpoints, привязка их в качестве описаний к воплощению системы, выход на управление конфигурацией, необходимость коллективной разработки, внимание к левой и правой частям V-диаграммы -- т.е. поддержка полного жизненного цикла).
Это означает, что можно осознанно поглядеть на зоопарк редакторов-мэпперов-моделеров-САПР-PLM-и т.д. (см. далеко не полный списочек в начале этого поста) и осознанно прикинуть ту общую точку, куда все эти системы ползут: ползут они к мегамоделеру, который поддерживает множество самых разных фронтэндов для описания системы, находящегося в бэкэнде, плюс надо ещё поддерживать работу обеспечивающей системы. Ключевым тут является то, что view и viewpoints много, а в одной вычислительной системе собрать все view и viewpoints не получится -- так что всё время нужно будет работать с "чужими данными", "чужими моделями", "чужими языками", всем чужим.
Можно идти "снизу" (например, IPython, который пошёл в Jupyter в сторону поддержки коллаборации и многоязыковости -- но в котором не так всё просто с поддержкой множества viewpoints, даже если cells в ноутбуке объявить view, то потом не так просто их модифицировать на ходу -- Eclipse тут сто очков вперёд даст), можно сверху (монструозный Eclipse, который уже перераспух и испытывает все ужасы работы с legacy архитектурой и кодом -- но в котором "окошки" отличненько верстаются и уживаются IDE и моделеры и среда их разработки, но и ему тяжело дотянуться до ALM/PLM поддержки, она сейчас всё больше standalone), можно сбоку и сикось-накось.
Но перед этим нужно сообразить, какова была бы "идеальная архитектура" для среды поддержки системного (с системным подходом в голове) программирования/проектирования/моделирования/онтологизирования -- и сколько из этой архитектуры можно было бы реализовать.
Что тут ещё нужно учесть, чтобы жизнь мёдом не казалась?
-- часть моделей это фото (растровые!), а часть моделей это текст на естественном языке, и поэтому потребуется работа с распределёнными представлениями, нейронные сети и прочие не слишком привычные view. Хотя в ноутбуках Jupyter с этим как-то приноравливаются работать, но там ещё не началась работа с view-viewpoint внутри самих сеток, см., например http://ailev.livejournal.com/1266411.html как шаги ровно в этом направлении нахождения view-viewpoints "внутри сеток". Да, сетки не модульны, но что-то там аналогичное модульности есть, это придётся поддерживать в софте: view в распределённых представлениях будет делиться на какие-то модели в распределённых же представлениях, ансамбли этих моделей и их отладка-вёрстка при разработке тоже могут потребоваться.
-- внутри там должны жить ещё и персональные и групповые агенты-помощники (от предложений автокомплита http://ailev.livejournal.com/1269236.html и предупреждений о конфигурационных коллизиях до более интересных функций: http://ailev.livejournal.com/1254114.html, вплоть до работы на нейроинтерфейсах по замеру когнитивной нагрузки http://openmeta.livejournal.com/236784.html и далее по линии openmeta и нейронета.
Но это всё бантики и заделы на будущее, пока и без этого интересно.
Упражнение "как мог бы выглядеть снаружи (требования) и изнутри (архитектура) мегамоделер с опорой на SysMoLan" я предоставляю читателям. Можно представить SysMoLan как набор расширений для Julia, можно считать что это просто набор всего доступного в языковом плане (а хоть и SysML), собранное в кучку, можно говорить о развитии Modelica и исполняющих её сред во все стороны сразу, можно универсализовать представление view в каком-то из инженерных САПР (а хоть и в Inventor -- мне уже приходилось как-то обсуждать такое). Выборов много, но данный пост предоставляет критерии и рамки для оценки таких выборов, а пост про системную информатику http://ailev.livejournal.com/1272169.html представляет собой критерии и рамки для оценки текущего поста.