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

Ну, проектирование/конструирование (и программирование в смысле проектного управления, создание программ работ) -- это частный случай, просто абстрагирование будущего, будущих полных темпоральных частей целевой абстрагируемой (т.е. проектируемой/конструируемой/целевой для программы работ) системы.

Конечно, акценты тут разные:
-- программирование (поскольку сюда неявно включается алгоритмика как абстрагирование действий и работа с данными как абстрагирование объектов и свойств со всеми оговорками, что объекты могут сами по себе абстрагировать действия) тут наиболее общо, но оно позволяет "оживлять" абстракции, манипулировать ими, строить имитационные модели. В программировании также уделяется много внимания формализму моделирования: синтаксису и семантике. Глубина абстрагирования -- метапрограммирование.
-- Моделирование тоже наиболее общо, ибо это сама суть абстрагирования: оставлять в одной системе самое важное от другой, абстрагирование в чистом виде. Но, увы, акцент на запуск модели на исполнение, "оживление" этой абстракции тут не делается. Ничего, мы пойдём другим путём: при языках моделирования очень часто можно найти каки-то более-менее полноценные (полнотьюринговые) языки программирования -- как языки запросов или декларативные языки ограничений. Например, SPARQL при RDF (чтобы не сложилось впечатления, что речь идёт только о процедурных языках) или OCL при UML/SysML. Глубина абстрагирования -- гирлянда метамоделей.
-- Онтологизирование само по себе наиболее общо, ибо в программировании и моделировании неважно что абстрагируется, а онтологизирование обращает внимание на реальность мира и аспекты "истинности" моделирования (глубоко занимается самим отношением абстракции), привносит философскую логику и заставляет задумываться о способах моделирования пространства, времени, а также задумываться о преобразованиях одних классов моделей в другие, парадигмах абстрагирования и их совместимости друг с другом. Глубина абстрагирования даже не рассматривается, ибо органически входит в дисциплину.
-- Обучение тоже наиболее общо, ибо обращает внимание на эпистемологический аспект абстрагирования, "как получили эту абстракцию", а не онтологический "что там наабстрагировали". Глубина абстрагирования явно обсуждается в современном machine learning. А ещё обсуждаются разные парадигмы моделирования, включая многоуровневые распределённые представления (machine learning).

Работа с абстракциями, воплощёнными в текст и коды (понимаемый широко, "всё есть текст", включая паттернирование "символами" на картинках и т.д.) -- это информатика, работа агентов (людей и компьютеров) с текстами и кодами я разбирался с этим тут:http://ailev.livejournal.com/1008054.html, дисциплины информатики там были философская логика, когнитивная наука, лингвистика, компьютерная наука. По факту, к уже выраженному в этих прежних (это был июнь 2012) текстах добавилось (машинное) обучение. Ну, и "компактное описание" я заменил на "абстрагирование" (тут я шёл как раз от deep learning, в коннекционистской парадигме уровни нейронной сети как раз уровни абстракции, равно как и в гирляндах символического метамоделирования -- цепочек классификаций и специализаций).

Логический уровень, уровень абстракции, уровень объективации, все эти "мета" -- это всё про одно и то же (http://ailev.livejournal.com/1073932.html):

Подробней про разные "мета" -- http://ailev.livejournal.com/1204705.html, про формальное образование в этой области --http://ailev.livejournal.com/1263511.html, логические уровни Бейтсона (эпистемологические, "обучения", а не онтологические его результатов) затрагиваются в разделе "когнитивной архитектуры" http://ailev.livejournal.com/1210678.html, многступенчатая объективация и объективизация --http://ailev.livejournal.com/1132449.html. И, конечно, сюда нужно добавить коннективизм в количестве: отношение между представлениями в разных уровнях нейронной сетки, разные уровни абстракции и архитектуры из разных стеков (уход от чистой иерархии слоёв-уровней, выход в сложные fully differentiable architectures с памятью, вниманием, различными обработчиками логики, выполнением алгоритмов и т.д.). 

Системный подход включает в себя абстрагирование как основной метод борьбы со сложностью, включая абстрагирование в рамку деятельностного подхода (ага, подход в подходе): 
-- Конкретное абстрагирование оформляет (frame) интерес стейкхолдера (деятельностной позиции, абстракции мыслящего существа, оставим на потом спекуляции про мыследействующих и абстрагирующих существ). Так сказать, "теория субъективной информации" (http://ailev.livejournal.com/66325.html, 2003).
-- Мереология ведущее отношение для абстрагирования (системы это холоны), она даёт возможность договориться по поводу того, что именно в реальном мире в конечном итоге абстрагируется в длинных цепочках метаабстрагирования. Системный подход -- это аналог структурного (иерархического) внимания в окружающий мир. Это позволяет строить описания каких-то частей мира, соответствующим системам в их границах, отделять фон от систем. В моих учебниках это "zoom-select". Подробней это раскрывается в http://ailev.livejournal.com/860017.html
-- есть жизненный цикл системы (указание на обеспечивающую систему -- http://ailev.livejournal.com/1248044.html), практики абстрагирования (практики определения и документирования определений -- создания полного описания) в этом жизненном цикле обязательны. Моделирование всегда было неотъемлемой составной частью системного подхода, а проектирование -- составной частью системноинженерного подхода. Программирование в какой-то момент через кибернетику тоже неудачно пыталось вписаться (пока не стало понятно, что кибернетика с её обратной связью совсем-совсем не эквивалентна информатике как таковой, и даже классической computer science как части информатики).
-- Поскольку деятельность коллективна, стейкхолдеров в ней много и ещё больше их интересов, то абстрагирований тоже нужно много, и разных для удовлетворения разных интересов. Но все полученные абстракции связаны между собой тем, что они про одну и ту же систему (или её части): любая абстракция это абстракция системы (или типа систем).
-- в силу коллективности деятельности, любое абстрагирование по мере роста его объема становится абстрагированием-в-большом (programming-in-the-large -- и см. как пример http://ailev.livejournal.com/748188.html, 2009г., и тамошний разбор сервис-ориентирования в современном программировании)
-- абстракции есть всегда, если есть система (наше знание о том, что есть система -- это уже абстракция), но они должны быть документированы для работы с ними -- разница между system definition и system description.
-- каждая абстракция имеет модальность (алеатическую, деонтическую, темпоральную), эти модальности могут меняться в ходе жизненного цикла.

Если соединить системный подход и расширенную распределёнными представлениями и коннекционизмом (http://ailev.livejournal.com/1228029.html) информатику (т.е. учесть, что все тексты и коды -- это описания тех или иных систем на разных уровнях абстрагирования, и эти описания отвечают разным интересам коллективно действующих стейкхолдеров), то будет системная информатика. Конечно, при этом придётся как-то справиться с коннекционисткой проблематизацией и в информатике (все эти end-to-end fully differentiable architectures) и в системном подходеhttp://ailev.livejournal.com/1252230.html

Такое описание системной информатики даёт возможность более-менее однообразного переформулирования множества самых разных проблем, ранее несопоставимых и развивавшихся в рамках самых разных дисциплин -- инженерного моделирования, программирования, лингвистики, машинного обучения, философской логики и т.д..

Например, можно считать, что все существующие языки -- это на каком-то уровне абстракции различные частные методы описания (viewpoint) каких-то определённых (view) системы.

Заново подойти к SysMoLan как языку системного абстрагирования (онтологизирования, программирования, моделирования и т.д.) --http://ailev.livejournal.com/1127145.html (2014 -- обратите внимание, там как раз попытка выйти на "системную информатику", но на примере одного языка и без попыток обозначить предметную область, чисто на "обобщениях из практики"), http://ailev.livejournal.com/1169972.html (2015, требования к формализму), или даже ещё более старым идеям Симултрека (http://ailev.livejournal.com/611877.html -- 2008, "Датацентрика -- это концептоцентрика. Документоцентрика -- это символоцентрика"). 

В принципе, можно было бы ввести концепцию "достроения языка до системного", считая каждый язык каким-то частным методом описания (veiwpoint), порождающим "частное описание" (veiw, которое само состоит из набора моделей -- всё строго по ISO 42010). Для этого нужно понять, что же означает в информатике наличие какого-то текста на языке? Означает только одно: исполнение его в каком-то смысле. В этом-то и секрет, что исполнение или оценка языка совершенно необязательно предписаны! Одна и та же модель/программа/онтология (не заморачиваемся тут разницей между definition и description -- например, разницей между онтологией и онтологическим описанием) может быть оценена (eval) или исполнена (execute) в разных смыслах: из одного текста можно породить разными способами много других, например можно текст программы интерпретировать, а можно сначала компилировать (т.е. изготовить по образцу одного текста другой текст). и только потом интерпретировать. Программа для станка с ЧПУ так вообще приводит при её интерпретации к изменениям в реальном мире (впрочем, даже обычная компьютерная программа тоже приводит к изменениям в реальном мире, только очень маленьким -- типа краски из пикселей на бумаге или по-разному пропускающих свет фотонов на экране). А 3D-модель тоже оказывается вполне исполнима: она декларативна, но это не мешает её исполнять 3D-принтеру, воплощая систему. Так сказать, "обратное моделирование", reverse modeling, воплощение!

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

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

В этом плане системная информатика должна как-то собирать различные описания в кучку. Скажем, в проекте http://rosettacode.orgсравниваются описания решений математических главным образом задач на разных языках программирования. Там есть классический T-shirt: описание задачи (текст выходных данных + что нужно сделать), алгоритм (что делается = модель-решение для "что нужно сделать", текст на языке программирования) и output (текст выходных данных). Если брать языки моделирования, то сразу становится очевидным, что их нельзя сравнить с языками программирования: там нет этой тройки текстов "вход-алгоритм-выход". Но это не совсем так! С точки зрения системной информатики, всё это моделирование имеет смысл только для ответа на какие-то вопросы. Это просто означает, что есть ситуация (описание модели), модель (код, формальный текст решения для данной ситуации -- результат абстрагирования, выраженный в языке какой-то метамодели) и есть вопросы, которые задаются модели, предполагающие её исполнение в каком-то смысле. То есть интерпретатор тут не "виртуальная машина языка" (читающая программу и выполняющая её над входными данными -- интерес при этом фиксирован: выполнение программы), а "виртуальная машина модели" (читающая запрос для какого-то интереса и выполняющая его над моделью как входными данными). Этот интерпретатор может быть либо человеком, либо нет -- и тогда язык запросов это и есть язык моделирования! Это хорошо видно на парах декларативных языков OCL и UML (и любая запись на UML может быть выражена в OCL!), SPARQL и RDF/OWL. Получается, что языки моделирования -- это какие-то подмножества для своих часто стремящихся к полнотьюринговости языков запросов, просто выраженные в другом синтаксисе и отражающие только часть возможностей языка запросов.

Замечу, что этот подход отличается от "интеграции моделей на базе онтологий", к чему вели и Sztipanovits в http://ailev.livejournal.com/675208.html и https://www.simantics.org/ и наш собственный заход в dot15926. Онтологии никуда не делись, но они "внутри". И появилось явно выполнение этих онтологий, они не рассматриваются вне языка запросов. А язык запросов к онтологиям оказывается просто хорошим языком программирования, во всей его полноте и мощи. Ну, или его можно легко реализовать с учётом какой-то специфики модели -- тоже как встроенный DSL.

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

Либо можно пойти другим путём: нужно взять язык с развитой рефлексией и метапрограммированием (например, какой-нибудь Лисп. См., например, контекст появления Лиспа в дискуссии про универсальные языки моделирования/программирования http://justy-tylor.livejournal.com/246591.html и http://justy-tylor.livejournal.com/246877.html) и считать, что это и есть системный язык -- и порождать дальше языки моделирования из него по потребности (ну, или писать на нём в соответствии с удачными другими языками моделирования). Например, можно думать о том, чтобы (пока justy-tylor не предложит какого более удачного решения) брать тот же язык Julia, в котором в части рефлексии и метапрограммирования вполне Лисп внутри, и
-- реализовать на нём DSL для выражения моделей ArchiMate 3.0 (при этом можно даже сохранить вывод этих моделей в виде правильных графических диаграмм! Это ж просто будет такой viewpoint -- графическое описание). Дальше два использования: 1. просто глазеть на диаграммы, используя подмножество языка для удобной их текстовой записи (или даже удобного графического редактирования), 2. выполнение запросов. Учитывая, что ArchiMate 3.0 подразумевает расширения себя разными атрибутами и типами элементов, то легко можно представить самые разные запросы -- от "сколько практик у нас в модели" до "посчитай необходимую производительность для сервера" (этот пример про подсчёты на основании диаграмм архимейта -- прямо из книжки автора языка. Но там ArchiMate даётся как внешний DSL, и этот подсчёт реализуется независимыми от языка средствами. А у нас ArchiMate является встроенным DSL к Julia, поэтому просто пишем на Julia запрос к структурам ArchiMate-на-Julia. Julia к этому ArchiMate является и языком ограничений (хотя так не принято называть, это ж не логический язык!) и языком запросов (хотя так тоже не принято называть, не подразумевается какой-то модели данных) -- но если допустить, что внутри самого языка (а не сбоку на диске) есть модель, то всё становится на свои места.
-- выполнить план по линии Modelica-на-Julia, описанный в третьем пункте тут: http://ailev.livejournal.com/1271980.html
* * *
Тем, кто меня читает много лет, должно быть всё понятно. Кто читает совсем недавно -- не будет понятно ничего. Единственное, что могу посоветовать, это попробовать прочесть посты и материалы по ссылкам из текста. Если и там непонятно -- то в тех материалах тоже много ссылок, и так "до дна", пока не станет понятно. 

По-хорошему, дальше две линии работ:
-- нужно как-то вытащить все эти обрывки мыслей по ссылкам, развернуть их, причесать и сделать учебник. Ибо как россыпь постов это всё необозримо. Когда-то у меня было такое же состояние дел в части системного мышления, пока я не сосредоточился и не написал учебник, аж две версии (http://techinvestlab.ru/systems_engineering_thinking). Вот и тут нужно писать учебник системной информатики, при всех текущих с ней непонятках.
-- взять какой-то язык с похожим на лисповое метапрограммированием (а хоть и Julia -- заодно там нет тяжёлого наследства программистской объект-ориентированности), и дорастить его до языка системного моделирования (оно же программирование, оно же онтологизирование, оно же проектирование и т.д.). Точнее, "спустить" его до DSL моделирования в его составе (что потребует описания на нём соответствующих метамоделей).
-- ну, и нужно отслеживать что там происходит в части коннекционистского моделирования-как-обучения (моделирования естественного языка, моделирования языков программирования, моделирование планов и цепочек действий, выражения концептов и понятности моделей-в-распределённых-представлениях и т.д.).
* * *
UPDATE: системная информатика -- это "информатика с системным мышлением в голове". Системная инженерия тоже так определяется: как "просто инженерия", только с системным мышлением в голове (ср., например, с http://ailev.livejournal.com/1157398.html).

UPDATE: некоторая дискуссия к этому посту ещё и тут: https://www.facebook.com/ailevenchuk/posts/10207409851418535