Системная мереология
Мой предыдущий пост про онтологии и SysMoLan https://ailev.livejournal.com/1449992.html поминает попытки онтологизации системной инженерии (прежде всего ST4SE), там в основе BFO 2.0. Работы Peter Simons (о них чуть ниже) показывают, что BFO негодная онтология для инженерных задач, её нельзя класть в основу инженерного моделирования: ибо она формально-мереологическая (мереология -- это дисциплина, обсуждающая отношение части и целого), рождает монстров. Как математика: она может выразить и те физические законы, которые красивы на бумаге, но которые в природе не наблюдаются. Вот теоретическая мереология ровно такая: красивые логические формулы, никакой связи с жизнью.
Корова Маргарита имеет своей частью хвост, корова Маргарита является частью коровьего стада. Нехорошо позволять говорить, что коровье стадо имеет хвост, хотя это вроде как мереологически корректно. Это корректно, но не системно, и это вроде как интуитивно понятно всем. Но интуитивно непонятно, можно ли говорить, что карбюратор -- часть автомобиля. Он отдельная часть автомобиля, или он часть топливной подсистемы, или часть двигателя?! Но вот говорить, что поршень или цилиндр двигателя это часть автомобиля -- интуитивно понятно, что это тоже неправильно, хотя "формально верно". Эмерджентность: обсуждение автомобиля требует обсуждения двигателя, но есть ли там внутри поршень -- это неважно. Управляем вниманием: на каждой границе системного уровня меняется интерес, меняются объекты внимания. Меняются ведущие дисциплины, меняется тусовка, поддерживающая разговор. На одном уровне обсуждаем хвосты и рога в корове (со всей проблематичностью выделения их как частей с определёнными границами!), на другом целых коров, быков в составе стада в целом. На одном уровне обсуждаем двигатель и салон, на другом -- поршень и цилиндр в двигателе. Разные интересы, разные языки, разные стейкхолдеры (в том числе роли которых обычно играют разные люди). Деление на части для системного подхода важно. Мереология для системного подхода важна.
Понятие "система" первого поколения привносит прежде всего понятие системного уровня с эмерджентностью. А второе поколение привносит понятие жизненного цикла со стейкхолдерами (ибо даже роботы яиц не несут, и эти системы нужно целенаправленно кому-то делать, кроме целевых и использующих систем есть обеспечивающие системы). Управление вниманием: что важно в целевой системе, что важно в её системном окружении (systems in operation environment -- системы времени работы готовой системы, функционирования/эксплуатации), что важно в части её появления на свет и последующего исчезновения (enabling systems, обеспечивающие системы).
Композиция (composition, отношения части-целого, дающие холархии) времени функционирования и процессы времени жизненного цикла ("от замысла до исчезновения/вывода из эксплуатации") -- вот это системный подход. И жизненный цикл со всеми его стейкхолдерами/интересантами определяет композицию/холархию. Делить на части систему нужно так, чтобы было удобно обсуждать эмерджентность.
Некоторые онтологи пошли по тому же пути, что и я, когда искал нормальную версию системного подхода. Я нашёл её там, где всякие варианты системного подхода жёстко проверялись реальной жизнью: в инженерии. Именно в инженерии приходится работать с разборкой-сборкой на части, и в инженерии приходится работать с жизненным циклом. Не разберёшься с частью-целым и жизненным циклом -- не сделаешь успешную систему. И то же самое происходит в онтологии.
Вот, например, свежие работы онтологов из команды ISO 15926 (последние апдейты тут -- июня 2018) по интеграции данных жизненного цикла: http://15926.org/topics/plant-lifecycle-model/index.htm. На диаграмме 81 онтологический объект, необходимый для обсуждения жизненного цикла какого-то объекта в непрерывном производстве (химзаводы, нефтепереработка, электростанции и т.д. -- где есть какой-то круглосуточный проток газов и жидкостей, и насосы и вентили в количестве). Можно обсуждать, насколько это общий случай, и насколько нужен такой уровень онтологического аннотирования, т.е. насколько по таким диаграммам можно проводить содержательные обсуждения жизненного цикла, а не только содержательные обсуждения онтологии жизненного цикла (типов) и данных жизненного цикла (данных об индивидах жизненного цикла). Меня это волнует: насколько уместен выбранный уровень абстрактности описания данных жизненного цикла и возможно ли по этим данным обсуждать сам жизненный цикл? Что содержательное могут обсуждать люди, интегрирующие данные? Это же данные: в них важна форма и логистика -- где взять, куда отдать, с чем отождествить. Это отдельная стейкхолдерская позиция, там свои интересы. И вот системный подход как раз может задать какие-то критерии для ограничений тамошнего моделирования: уровень в стеке абстрактности (на котором нужно обсуждать эмерджентность), место в спектре формальности (на котором уже можно как-то объединять формально-логически несовместимые view), уровень декомпозиции в системной холархии (опять же, для удобного обсуждения эмерджентности -- чтобы по разные стороны системного уровня говорить на разном языке). По этой линии можно брать моделирование системных холархий из самого ISO 15926, из HQDM от Matthew West, или опираться больше на работы Chris Partridge по BORO (нужно же и об инженерии предприятия не забывать! книжка по большей части об этом), но у него там есть и работы по DM2 (онтология для систем в NATO, она ведь и для инженерных систем).
А вот ещё один заход, в этот раз против классической философской/онтологической мереологии в пользу практической инженерной мереологии, возглавляет его сейчас Peter Simons (и поддерживает лично John Sowa): https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwZXRlcm1zaW1vbnN8Z3g6MmY0YmVjNThiYjM1N2VmZA коротко и полный отчёт (110 страниц) Charles Dement сотоварищи (причём без Симонса) по программе MEREOS 2000 года http://jfsowa.com/ikl/Dement01.pdf (постановка задачи на мереологию рабочих продуктов/артефактов в отличие от мереологии природных объектов -- то есть соотнесение мереологии и деятельности), http://www.tara.tcd.ie/bitstream/handle/2262/75103/Varieties%20of%20Parthood%20Compact.pdf это 2013 год с формулированием требований к отношению часть-целое. И вот в этом последнем тексте уже есть интересности, прямо указывающие на необходимость системного рассмотрения в отношении части-целое.
Многие из указанных в последнем тексте мереологических особенностей (типа "дырок" как частей системы) есть даже в моём учебнике. Но вот для полноценного моделирования нужно ещё и более детальное рассмотрение features (дно стеклянного стакана -- нет границы с остальным стаканом) и parts (отдельной части, где граница чётко определена какой-нибудь "сборкой"), а также частей в каких-нибудь материалах (например, золях, гелях или суспензиях, или микрокристаллов в металлическом сплаве).
Главное, на что указывает Simons в этом последнем тексте -- это то, что физические части имеют каузацию (ещё бы! Обсуждаются ведь артефакты, и каузация очевидна). Таким образом деление на части не произвольно, а привязано к пониманию причинно-следственных отношений. Это означает, что отношения часть-целое нужно рассматривать не сами по себе, а в привязке к каким-то схемам причинности. И хорошо определяемые отношения часть-целое, похоже, как-то должны использовать особенность человеческого мозга быть неплохим вычислителем причинности -- иначе они будут не слишком полезными, системный подход будет не способствовать хорошему мышлению, не сможет задействовать эту особенность человеческого мозга. Подробности про мозг как вычислитель причинности можно поглядеть в книге The Book of Why, о которой я писал в "ложь, наглая ложь, и причинный вывод (causal inference)" -- https://ailev.livejournal.com/1435703.html.
Тем самым инженер не бьёт систему на части произвольным образом, он бьёт систему на части, чтобы было удобней определять эту систему (думать о ней), удобней воплощать её (изготавливать в физическом мире), удобней работать с готовой системой, удобней выводить её из эксплуатации. Менеджер бьёт систему на части так, чтобы было удобней обеспечивать логистику этих частей системы и организовывать труд по созданию частей системы. Предприниматель бьёт использующую систему на части так, чтобы показать необходимость и место целевой системы для улучшения (или даже существования) использующей. В работах Simpson явно указывается, что инженерные части (в отличие от классических мереологических частей) характеризуются интересом, различающимся на разных стадиях жизненного цикла.
В принципе, это продолжение современными онтологами линии прагматического поворота в философии (работы Charles Sanders Pierce, любимый философ у John Sowa), а обращение к жизненному циклу -- это продолжение линии "процессной онтологии" (Alfred North Whitehead -- любимый философ у Peter Simons).
И тут мы должны вспомнить и о процессной онтологии ISO 18627 https://www.sciencedirect.com/science/article/pii/S1474667016375371 и о многочисленных похожих работах, которых гугление выдаёт десятками.
А уж если сюда включить близкие работы по interoperability (все они так или иначе пытаются определить взаимодействие между системами, которое относится к какому-то уровню системного рассмотрения), то этих работ и вовсе запредельное количество -- см., например, недавний обзор моделей взаимодействия https://www.sciencedirect.com/science/article/pii/S2452414X17300687
И нужно ещё учесть, что при рассмотрении модулей выделяют не просто отношение composition, но и два свойства ("модульность" -- https://ailev.livejournal.com/1294242.html):
-- компонуемость (composability) -- это про возможность сложить целую систему из частей-подсистем. Модульный аспект сборки, компоновки, создания холархии: интерфейсы воткнутся друг во друга, целая система, собранная из подсистем, заработает. Обратите внимание, что "выращиваемые" системы не компонуемы! Их не соберёшь из частей, и хотя в них тоже присутствует холархия, нельзя сказать, что на неё как-то существенно можно влиять, отдельные модули не взаимозаменяемы путём подключения к известному интерфейсу, требуются разные "врастания".
-- композициональность (compositionality) требует некоторого "композиторства" -- речь идёт о свойстве собранного из частей целого обходиться без неожиданной эмерджентности типа отрицательных побочных эффектов. Система композициональна по какому-то свойству, когда её это свойство напрямую трассируется к свойству отдельных модулей. Это хитрое антисистемное понятие, потому как целая композициональная система в отношении какого-то свойства не больше суммы своих частей, а равна сумме своих частей! Композициональная система имеет какое-то свойство, если её модули имеют это свойство, поэтому для композициональной системы простая сборка её из обладающих каким-то свойством модулей будет означать доказательство того, что вся система обладает этим свойством. Если модули системы критичны к работе во времени и требуется их синхронизация, то создать систему, синхронно работающую "в силу конструкции", обычно нельзя. Так что свойства с плохой композициональностью обычно попадают в список интересов стейкхолдеров отдельными пунктами и в проектах им уделяется много внимания.
Поскольку системы создаются из гетерогенных элементов, то компонуемость эксплуатирует полезную эмерджентность (нужная функция появляется в результате взаимодействия элементов), а композициональность наоборот, указывает на отсутствие вредной эмерджентности.
И не забываем, что огромное количество связанных с инженерными холархиями проблем было решено инженерами (не онтологами!) в ходе создания IEC 81346. Но это стандарт именований в первую очередь, и только по необходимости стандарт описания системных холархий -- это в нём во вторую очередь. Авторы стандарта в момент его создания даже не знали о системной инженерии, они её обнаружили много позже.
При создании SysMoLan (цепочка: https://ailev.livejournal.com/1443879.html, ) нужно тем самым:
-- определиться с системной мереологией: какие свойства и ограничения на отношение "часть-целое" накладывает системный подход (с его эмерджентностью и жизненным циклом. Прагматизм, каузальность, вот это всё). Понять, какие тут возможны онтологические выборы.
-- сосредоточиться и решить, на каком уровне формальности и в рамках какой онтологической парадигмы определять отношения часть-целое в SysMoLan.
-- уточнить всё для программных объектов, ибо маловато будет сказать, что "программа тоже объект" (у нас же киберфизические системы!)
-- а ещё при этом нужно будет договориться и о том, как именовать/обозначать (designation) части, связываемые в сопряжённые холархии целевых и обеспечивающих систем этими "хорошо определёнными" отношениями композиции: полными именами? бессмысленными уникальными идентификаторами? составными (по системным уровням) кодами как в IEC81346? как именуют части системы в программной инженерии -- но там же везде по-разному, и если про модули всё понятно (системы управления версиями рулят!), то про функции и размещения уже не очень?!
И помним про коннективизм и вероятностные онтологии, связанную с ними корпусную инженерию (https://ailev.livejournal.com/1009201.html),
различие и похожести задач моделирования данных (для целей интеграции данных жизненного цикла, как в ISO 15926, а краткий обзор state of the art в моделировании данных см. в https://ailev.livejournal.com/1451630.html) и системного моделирования (для целей системного анализа и модульного синтеза в ходе инженерии требований и инженерии системной архитектуры и архитектуры предприятия как обеспечивающей системы -- цели как в SysArchi, https://ailev.livejournal.com/1444887.html, SysML, AADL).
И без хоть каких-то решений на этом пути создавать SysMoLan Studio (https://ailev.livejournal.com/1446524.html) -- это пополнять бесконечное число неудачных моделеров (ибо шикарная IDE для убогого языка не будет никогда шикарной). Помним, что архитектурно там получается несколько разных уровней договорённостей (https://ailev.livejournal.com/1451630.html?thread=15915374#t15915374):
-- Пользовательский интерфейс: IDE для exploratory modeling. Выбор хост-языка (предполагаю, что это Julia).
-- Метаметамодель, языковые вопросы: формализм языка (foundational ontology). На каком языке работаем? Парадигма и синтаксис: виртуальная машина, поддерживающая моделирование.
-- Метамодель, и к ней онтологические вопросы: описание системы, т.е. онтология системы + полноценный онтологический язык/язык моделирования данных для интеграции данных жизненного цикла (частных, несистемных описаний). И вот тут upper ontology, онтологические паттерны и прочий разговор не про форматы, а про моделирование мира. Вот особенность SysMoLan главным образом должна быть тут, но без понимания, на каком холсте эту онтологическую картину рисуем (т.е. foundational ontology и способ алгоритмической с ней работы) до этого не договоримся.
-- Модель (в которую плавно переходит метамодель): middle ontology (сами пишем системную модель), описания domain ontology (подключаемых к системной модели уточняющих её частных описаний в разных форматах разных CAD и систем моделирования).
И вот без обсуждения и документирования онтологических примитивов, необходимых для моделирования системы (метамодели: взаимосвязанные холархии и жизненный цикл) мы никуда не сдвинемся. Без гипотезы, чем это моделирование будет лучше уже имеющихся сейчас вариантов -- весь проект SysMoLan это игра в "авось что-нибудь получится", а не инженерное предпринятие.
По опыту предыдущих заходов на такие проекты понятно, что это работа практически full time десятка активных грамотных инженеров и онтологов лет эдак на пять. При этом нет ни ресурсов на такую работу (обычно её спонсируют какие-то промышленные консорциумы, но это не про нас), ни пяти лет: за пять лет каток искусственного интеллекта глубоко и тяжело пропашет и онтологику в целом, и мереологию как её часть. А хоть и инженерную мереологию как она бытует в среде инженеров сейчас (например, IEC81346 стал очень популярен в BIM -- и за счет этого BIM стал по факту много системней), не дожидаясь, пока "народная инженерная мереология с де-факто вкраплениями системности" будет доработана до хоть какой-то консенсусно определённой "хорошей системной" (то есть удобной для управления вниманием коллектива стейкхолдеров при мышлении о проекте -- системный подход ведь для этого!).
Но эти соображения глобальной ресурсной и временнОй безнадёжности нас, конечно, не остановят. Мы будем продолжать лежать по направлению к цели.
Корова Маргарита имеет своей частью хвост, корова Маргарита является частью коровьего стада. Нехорошо позволять говорить, что коровье стадо имеет хвост, хотя это вроде как мереологически корректно. Это корректно, но не системно, и это вроде как интуитивно понятно всем. Но интуитивно непонятно, можно ли говорить, что карбюратор -- часть автомобиля. Он отдельная часть автомобиля, или он часть топливной подсистемы, или часть двигателя?! Но вот говорить, что поршень или цилиндр двигателя это часть автомобиля -- интуитивно понятно, что это тоже неправильно, хотя "формально верно". Эмерджентность: обсуждение автомобиля требует обсуждения двигателя, но есть ли там внутри поршень -- это неважно. Управляем вниманием: на каждой границе системного уровня меняется интерес, меняются объекты внимания. Меняются ведущие дисциплины, меняется тусовка, поддерживающая разговор. На одном уровне обсуждаем хвосты и рога в корове (со всей проблематичностью выделения их как частей с определёнными границами!), на другом целых коров, быков в составе стада в целом. На одном уровне обсуждаем двигатель и салон, на другом -- поршень и цилиндр в двигателе. Разные интересы, разные языки, разные стейкхолдеры (в том числе роли которых обычно играют разные люди). Деление на части для системного подхода важно. Мереология для системного подхода важна.
Понятие "система" первого поколения привносит прежде всего понятие системного уровня с эмерджентностью. А второе поколение привносит понятие жизненного цикла со стейкхолдерами (ибо даже роботы яиц не несут, и эти системы нужно целенаправленно кому-то делать, кроме целевых и использующих систем есть обеспечивающие системы). Управление вниманием: что важно в целевой системе, что важно в её системном окружении (systems in operation environment -- системы времени работы готовой системы, функционирования/эксплуатации), что важно в части её появления на свет и последующего исчезновения (enabling systems, обеспечивающие системы).
Композиция (composition, отношения части-целого, дающие холархии) времени функционирования и процессы времени жизненного цикла ("от замысла до исчезновения/вывода из эксплуатации") -- вот это системный подход. И жизненный цикл со всеми его стейкхолдерами/интересантами определяет композицию/холархию. Делить на части систему нужно так, чтобы было удобно обсуждать эмерджентность.
Некоторые онтологи пошли по тому же пути, что и я, когда искал нормальную версию системного подхода. Я нашёл её там, где всякие варианты системного подхода жёстко проверялись реальной жизнью: в инженерии. Именно в инженерии приходится работать с разборкой-сборкой на части, и в инженерии приходится работать с жизненным циклом. Не разберёшься с частью-целым и жизненным циклом -- не сделаешь успешную систему. И то же самое происходит в онтологии.
Вот, например, свежие работы онтологов из команды ISO 15926 (последние апдейты тут -- июня 2018) по интеграции данных жизненного цикла: http://15926.org/topics/plant-lifecycle-model/index.htm. На диаграмме 81 онтологический объект, необходимый для обсуждения жизненного цикла какого-то объекта в непрерывном производстве (химзаводы, нефтепереработка, электростанции и т.д. -- где есть какой-то круглосуточный проток газов и жидкостей, и насосы и вентили в количестве). Можно обсуждать, насколько это общий случай, и насколько нужен такой уровень онтологического аннотирования, т.е. насколько по таким диаграммам можно проводить содержательные обсуждения жизненного цикла, а не только содержательные обсуждения онтологии жизненного цикла (типов) и данных жизненного цикла (данных об индивидах жизненного цикла). Меня это волнует: насколько уместен выбранный уровень абстрактности описания данных жизненного цикла и возможно ли по этим данным обсуждать сам жизненный цикл? Что содержательное могут обсуждать люди, интегрирующие данные? Это же данные: в них важна форма и логистика -- где взять, куда отдать, с чем отождествить. Это отдельная стейкхолдерская позиция, там свои интересы. И вот системный подход как раз может задать какие-то критерии для ограничений тамошнего моделирования: уровень в стеке абстрактности (на котором нужно обсуждать эмерджентность), место в спектре формальности (на котором уже можно как-то объединять формально-логически несовместимые view), уровень декомпозиции в системной холархии (опять же, для удобного обсуждения эмерджентности -- чтобы по разные стороны системного уровня говорить на разном языке). По этой линии можно брать моделирование системных холархий из самого ISO 15926, из HQDM от Matthew West, или опираться больше на работы Chris Partridge по BORO (нужно же и об инженерии предприятия не забывать! книжка по большей части об этом), но у него там есть и работы по DM2 (онтология для систем в NATO, она ведь и для инженерных систем).
А вот ещё один заход, в этот раз против классической философской/онтологической мереологии в пользу практической инженерной мереологии, возглавляет его сейчас Peter Simons (и поддерживает лично John Sowa): https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwZXRlcm1zaW1vbnN8Z3g6MmY0YmVjNThiYjM1N2VmZA коротко и полный отчёт (110 страниц) Charles Dement сотоварищи (причём без Симонса) по программе MEREOS 2000 года http://jfsowa.com/ikl/Dement01.pdf (постановка задачи на мереологию рабочих продуктов/артефактов в отличие от мереологии природных объектов -- то есть соотнесение мереологии и деятельности), http://www.tara.tcd.ie/bitstream/handle/2262/75103/Varieties%20of%20Parthood%20Compact.pdf это 2013 год с формулированием требований к отношению часть-целое. И вот в этом последнем тексте уже есть интересности, прямо указывающие на необходимость системного рассмотрения в отношении части-целое.
Многие из указанных в последнем тексте мереологических особенностей (типа "дырок" как частей системы) есть даже в моём учебнике. Но вот для полноценного моделирования нужно ещё и более детальное рассмотрение features (дно стеклянного стакана -- нет границы с остальным стаканом) и parts (отдельной части, где граница чётко определена какой-нибудь "сборкой"), а также частей в каких-нибудь материалах (например, золях, гелях или суспензиях, или микрокристаллов в металлическом сплаве).
Главное, на что указывает Simons в этом последнем тексте -- это то, что физические части имеют каузацию (ещё бы! Обсуждаются ведь артефакты, и каузация очевидна). Таким образом деление на части не произвольно, а привязано к пониманию причинно-следственных отношений. Это означает, что отношения часть-целое нужно рассматривать не сами по себе, а в привязке к каким-то схемам причинности. И хорошо определяемые отношения часть-целое, похоже, как-то должны использовать особенность человеческого мозга быть неплохим вычислителем причинности -- иначе они будут не слишком полезными, системный подход будет не способствовать хорошему мышлению, не сможет задействовать эту особенность человеческого мозга. Подробности про мозг как вычислитель причинности можно поглядеть в книге The Book of Why, о которой я писал в "ложь, наглая ложь, и причинный вывод (causal inference)" -- https://ailev.livejournal.com/1435703.html.
Тем самым инженер не бьёт систему на части произвольным образом, он бьёт систему на части, чтобы было удобней определять эту систему (думать о ней), удобней воплощать её (изготавливать в физическом мире), удобней работать с готовой системой, удобней выводить её из эксплуатации. Менеджер бьёт систему на части так, чтобы было удобней обеспечивать логистику этих частей системы и организовывать труд по созданию частей системы. Предприниматель бьёт использующую систему на части так, чтобы показать необходимость и место целевой системы для улучшения (или даже существования) использующей. В работах Simpson явно указывается, что инженерные части (в отличие от классических мереологических частей) характеризуются интересом, различающимся на разных стадиях жизненного цикла.
В принципе, это продолжение современными онтологами линии прагматического поворота в философии (работы Charles Sanders Pierce, любимый философ у John Sowa), а обращение к жизненному циклу -- это продолжение линии "процессной онтологии" (Alfred North Whitehead -- любимый философ у Peter Simons).
И тут мы должны вспомнить и о процессной онтологии ISO 18627 https://www.sciencedirect.com/science/article/pii/S1474667016375371 и о многочисленных похожих работах, которых гугление выдаёт десятками.
А уж если сюда включить близкие работы по interoperability (все они так или иначе пытаются определить взаимодействие между системами, которое относится к какому-то уровню системного рассмотрения), то этих работ и вовсе запредельное количество -- см., например, недавний обзор моделей взаимодействия https://www.sciencedirect.com/science/article/pii/S2452414X17300687
И нужно ещё учесть, что при рассмотрении модулей выделяют не просто отношение composition, но и два свойства ("модульность" -- https://ailev.livejournal.com/1294242.html):
-- компонуемость (composability) -- это про возможность сложить целую систему из частей-подсистем. Модульный аспект сборки, компоновки, создания холархии: интерфейсы воткнутся друг во друга, целая система, собранная из подсистем, заработает. Обратите внимание, что "выращиваемые" системы не компонуемы! Их не соберёшь из частей, и хотя в них тоже присутствует холархия, нельзя сказать, что на неё как-то существенно можно влиять, отдельные модули не взаимозаменяемы путём подключения к известному интерфейсу, требуются разные "врастания".
-- композициональность (compositionality) требует некоторого "композиторства" -- речь идёт о свойстве собранного из частей целого обходиться без неожиданной эмерджентности типа отрицательных побочных эффектов. Система композициональна по какому-то свойству, когда её это свойство напрямую трассируется к свойству отдельных модулей. Это хитрое антисистемное понятие, потому как целая композициональная система в отношении какого-то свойства не больше суммы своих частей, а равна сумме своих частей! Композициональная система имеет какое-то свойство, если её модули имеют это свойство, поэтому для композициональной системы простая сборка её из обладающих каким-то свойством модулей будет означать доказательство того, что вся система обладает этим свойством. Если модули системы критичны к работе во времени и требуется их синхронизация, то создать систему, синхронно работающую "в силу конструкции", обычно нельзя. Так что свойства с плохой композициональностью обычно попадают в список интересов стейкхолдеров отдельными пунктами и в проектах им уделяется много внимания.
Поскольку системы создаются из гетерогенных элементов, то компонуемость эксплуатирует полезную эмерджентность (нужная функция появляется в результате взаимодействия элементов), а композициональность наоборот, указывает на отсутствие вредной эмерджентности.
И не забываем, что огромное количество связанных с инженерными холархиями проблем было решено инженерами (не онтологами!) в ходе создания IEC 81346. Но это стандарт именований в первую очередь, и только по необходимости стандарт описания системных холархий -- это в нём во вторую очередь. Авторы стандарта в момент его создания даже не знали о системной инженерии, они её обнаружили много позже.
При создании SysMoLan (цепочка: https://ailev.livejournal.com/1443879.html, ) нужно тем самым:
-- определиться с системной мереологией: какие свойства и ограничения на отношение "часть-целое" накладывает системный подход (с его эмерджентностью и жизненным циклом. Прагматизм, каузальность, вот это всё). Понять, какие тут возможны онтологические выборы.
-- сосредоточиться и решить, на каком уровне формальности и в рамках какой онтологической парадигмы определять отношения часть-целое в SysMoLan.
-- уточнить всё для программных объектов, ибо маловато будет сказать, что "программа тоже объект" (у нас же киберфизические системы!)
-- а ещё при этом нужно будет договориться и о том, как именовать/обозначать (designation) части, связываемые в сопряжённые холархии целевых и обеспечивающих систем этими "хорошо определёнными" отношениями композиции: полными именами? бессмысленными уникальными идентификаторами? составными (по системным уровням) кодами как в IEC81346? как именуют части системы в программной инженерии -- но там же везде по-разному, и если про модули всё понятно (системы управления версиями рулят!), то про функции и размещения уже не очень?!
И помним про коннективизм и вероятностные онтологии, связанную с ними корпусную инженерию (https://ailev.livejournal.com/1009201.html),
различие и похожести задач моделирования данных (для целей интеграции данных жизненного цикла, как в ISO 15926, а краткий обзор state of the art в моделировании данных см. в https://ailev.livejournal.com/1451630.html) и системного моделирования (для целей системного анализа и модульного синтеза в ходе инженерии требований и инженерии системной архитектуры и архитектуры предприятия как обеспечивающей системы -- цели как в SysArchi, https://ailev.livejournal.com/1444887.html, SysML, AADL).
И без хоть каких-то решений на этом пути создавать SysMoLan Studio (https://ailev.livejournal.com/1446524.html) -- это пополнять бесконечное число неудачных моделеров (ибо шикарная IDE для убогого языка не будет никогда шикарной). Помним, что архитектурно там получается несколько разных уровней договорённостей (https://ailev.livejournal.com/1451630.html?thread=15915374#t15915374):
-- Пользовательский интерфейс: IDE для exploratory modeling. Выбор хост-языка (предполагаю, что это Julia).
-- Метаметамодель, языковые вопросы: формализм языка (foundational ontology). На каком языке работаем? Парадигма и синтаксис: виртуальная машина, поддерживающая моделирование.
-- Метамодель, и к ней онтологические вопросы: описание системы, т.е. онтология системы + полноценный онтологический язык/язык моделирования данных для интеграции данных жизненного цикла (частных, несистемных описаний). И вот тут upper ontology, онтологические паттерны и прочий разговор не про форматы, а про моделирование мира. Вот особенность SysMoLan главным образом должна быть тут, но без понимания, на каком холсте эту онтологическую картину рисуем (т.е. foundational ontology и способ алгоритмической с ней работы) до этого не договоримся.
-- Модель (в которую плавно переходит метамодель): middle ontology (сами пишем системную модель), описания domain ontology (подключаемых к системной модели уточняющих её частных описаний в разных форматах разных CAD и систем моделирования).
И вот без обсуждения и документирования онтологических примитивов, необходимых для моделирования системы (метамодели: взаимосвязанные холархии и жизненный цикл) мы никуда не сдвинемся. Без гипотезы, чем это моделирование будет лучше уже имеющихся сейчас вариантов -- весь проект SysMoLan это игра в "авось что-нибудь получится", а не инженерное предпринятие.
По опыту предыдущих заходов на такие проекты понятно, что это работа практически full time десятка активных грамотных инженеров и онтологов лет эдак на пять. При этом нет ни ресурсов на такую работу (обычно её спонсируют какие-то промышленные консорциумы, но это не про нас), ни пяти лет: за пять лет каток искусственного интеллекта глубоко и тяжело пропашет и онтологику в целом, и мереологию как её часть. А хоть и инженерную мереологию как она бытует в среде инженеров сейчас (например, IEC81346 стал очень популярен в BIM -- и за счет этого BIM стал по факту много системней), не дожидаясь, пока "народная инженерная мереология с де-факто вкраплениями системности" будет доработана до хоть какой-то консенсусно определённой "хорошей системной" (то есть удобной для управления вниманием коллектива стейкхолдеров при мышлении о проекте -- системный подход ведь для этого!).
Но эти соображения глобальной ресурсной и временнОй безнадёжности нас, конечно, не остановят. Мы будем продолжать лежать по направлению к цели.