Теория категорий и системная инженерия: мокрый остаток
Диаграммных языков огромное множество: блок-схемы, сети Петри, SBGN (Systems Biology Graphical Notation -- http://www.sbgn.org/), BPMN, радиосхемы, сигнальные диаграммы в теории управления и т.д.. В них нужно как-то разбираться, ибо кажется что все они про одно и то же -- но каждый раз оказывается, что про разное. Так, в UML как диаграммном языке 14 видов диаграмм, в SysML из них используется 7 и добавляется 2 новых. Что в этом диаграммном зоопарке общего, что разного? Ежели хочется создать SysMoLan как язык моделирования, то неплохо бы теоретически убедиться, что в нём выразимо как можно больше типов инженерных диаграмм и в нём есть необходимые солверы для типовых вычислений по этим диаграммам. Другими словами, чтобы моделер не повторял в своей модели данных картинку диаграммы, а чтобы отражал её суть -- определение диаграммы (абстрактный синтаксис и инженерную/физическую семантику), а не её описание (конкретный синтаксис).
Этой работой занимается John Baez в рамках проекта Network Theory (http://math.ucr.edu/home/baez/networks/networks_1.html, стартован в 2011г.), этот проект движется потихоньку (http://math.ucr.edu/home/baez/control/control_talk_erlangen.pdf -- про полноту изобразительных средств для сигнальных диаграмм, 2014г., http://math.ucr.edu/home/baez/circuits.pdf -- про диаграммы электрических и гидравлических сетей/цепей). В работах Баеза начали появляться прямые упоминания системной инженерии в связи с теорией категорий -- см., например, картинку объявления о системноинженерном семинаре 1959 года в MIT тут и комментарий к ней в http://math.ucr.edu/home/baez/week292.html. Солверов это всё тоже касается: например, попытка выяснить: вероятностные или квантовые расчёты нужно применять для моделирования сетей/цепей, или квантовые расчёты обобщают вероятностные, или есть их общее для сетей/цепей пересечение? Целая книжка на эту тему: http://math.ucr.edu/home/baez/stoch_stable.pdf
Главный вопрос тут, конечно -- "зачем" все эти теоркатегорные мэппинги между разными дисциплинами математики и инженерии. Есть ли что-нибудь такое, что раньше нельзя было посчитать, а сегодня посчитали? Похоже, ничего такого нет -- новых расчётов или повышения точности для старых расчётов не предложено (или я плохо читал?). Считать, что экономится человеческое знание, тоже нельзя: всё это "похожее" редко приходится рассматривать одним и тем же людям -- разные инженеры делают разные расчёты. Хотя я не знаю, как бы выглядело разделение труда, если бы стало понятно, что "разные расчёты" и "разные диаграммы" вдруг являются вариантами одного и того же расчёта, одной и той же диаграммы. Ну, и при таком подходе можно формально проверить: достаточно ли полна модель данных для выражения тех или иных инженерных диаграмм, достаточно ли данных для тех или иных солверов, достаточно ли алгоритмов для тех или иных солверов.
Интересно бы сравнить впрямую эти два способа интеграции (в мышлении и компьютерах) различных инженерных моделей:
-- на базе общей математики и физики (придания физического смысла математическим моделям, в том числе структурным математическим моделям), Баез, кажется, хотел бы идти этим путём
-- на базе классического онтологического подхода (базы данных, хранящие модели на языках моделирования отдельно, и отдельно алгоритмы их обсчёта -- самые разные алгоритмы, обсчитывающие самое разное по этим моделям).
Мне кажется, нужно как-то учитывать оба этих подхода.
Вот мой план, по которому можно было бы как-то попасть в инженерный рай с использованием теории категорий:
1. Ограничиться задачей архитектурного синтеза (слово "ограничиться" тут выглядит издёвкой, ну да ладно). Архитектурный синтез -- это когда мы пытаемся взаимно оптимизировать компонентное описание (одну или несколько принципиальных схем -- "как оно работает") и модульное описание (продукты, детали и т.д. -- "из чего мы это сделаем, и сколько оно будет стоить"). Про размещения и прочая пока умолчим.
3. Про принципиальные схемы -- можно идти по линии, намеченной Баезом сотоварищи.
4. Понять, как описывать модули. Это всяческие BOM, это описания протоколов (интерфейсов).
5. Разобраться с формализацией архитектурного синтеза. Тут уже тьма самых разных работ:
-- неформальный ТРИЗ: можно начинать с проглядывания трёх текстов: АРИЗ-85В http://www.triz-ri.ru/triz/triz02.asp, типовых приёмов разрешения противоречий http://www.triz-ri.ru/triz/triz04.asp и стандартных решений изобретательских задач -- http://www.triz-ri.ru/triz/triz06.asp.
-- contract-based design (группа Генриха Брудни): работы по Heterogeneous reactive systems and component based design со страницы http://people.rennes.inria.fr/Albert.Benveniste/, https://chess.eecs.berkeley.edu/design/2012/discussions/Pdf/ASVDammPasserone_CDC_EJC.pdf, трансляция контрактов в логический язык (как я понимаю, аналогично можно транслировать и в теоркатегорный язык) http://arxiv.org/pdf/1311.3631.pdf, грамматика языка целей и контрактов (Goal Contracts Specification Language): https://project.inria.fr/plasma-lab/gcsl/
-- суперкомпиляторы: http://sober-space.livejournal.com/83013.html и далее по ссылкам в моих репликах
-- Марк Левин, Технология поддержки решений для модульных систем. Электронная книга. 341 с. 2013.
http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf
-- Кузнецов Н.А. и др. -- Метода анализа и синтеза модульных информационно-управляющих систем: http://libgen.org/get?nametype=orig&md5=c3943a8b391b4277fe2ce83e1352e568
-- пример с трассировкой выбранного модуля пожарной сигнализации к размещениям в презентации С.Ковалёва (собственно, там уже теоркатегорный подход был использован): http://incose-ru.livejournal.com/50098.html
-- ... этот список можно продолжать до бесконечности.
Интересно, что этот архитектурный синтез во многих современных работах уже выходит на киберфизику.
Удастся ли как-то найти общее идейное, понятийное и вычислительное ядро во всех этих методах, даже если использовать теорию категорий? А потом на базе этого ядра сделать архитектурный моделер с редактором компонентных и модульных диаграмм плюс архитектурный солвер, вычисляющий мэппинг/трассировку между этими диаграммами, плюс оптимизатор, ставящий под контроль изменения в диаграммах? Язык этого моделера и был бы SysMoLan, а теория категорий рулила бы вычислениями в солвере и оптимизаторе. У инженеров бы тогда не было вопросов, а универсальное понимание всех этих разнообразных методов пошло бы в основу курсов по практикам архитектурной работы в системной инженерии.
Это, конечно, очень сырой план, поэтому в этом посте я привёл не сухой, а мокрый остаток наших обсуждений последнего месяца. Но за неимением других планов будем работать по этому.
Этой работой занимается John Baez в рамках проекта Network Theory (http://math.ucr.edu/home/baez/networks/networks_1.html, стартован в 2011г.), этот проект движется потихоньку (http://math.ucr.edu/home/baez/control/control_talk_erlangen.pdf -- про полноту изобразительных средств для сигнальных диаграмм, 2014г., http://math.ucr.edu/home/baez/circuits.pdf -- про диаграммы электрических и гидравлических сетей/цепей). В работах Баеза начали появляться прямые упоминания системной инженерии в связи с теорией категорий -- см., например, картинку объявления о системноинженерном семинаре 1959 года в MIT тут и комментарий к ней в http://math.ucr.edu/home/baez/week292.html. Солверов это всё тоже касается: например, попытка выяснить: вероятностные или квантовые расчёты нужно применять для моделирования сетей/цепей, или квантовые расчёты обобщают вероятностные, или есть их общее для сетей/цепей пересечение? Целая книжка на эту тему: http://math.ucr.edu/home/baez/stoch_stable.pdf
Главный вопрос тут, конечно -- "зачем" все эти теоркатегорные мэппинги между разными дисциплинами математики и инженерии. Есть ли что-нибудь такое, что раньше нельзя было посчитать, а сегодня посчитали? Похоже, ничего такого нет -- новых расчётов или повышения точности для старых расчётов не предложено (или я плохо читал?). Считать, что экономится человеческое знание, тоже нельзя: всё это "похожее" редко приходится рассматривать одним и тем же людям -- разные инженеры делают разные расчёты. Хотя я не знаю, как бы выглядело разделение труда, если бы стало понятно, что "разные расчёты" и "разные диаграммы" вдруг являются вариантами одного и того же расчёта, одной и той же диаграммы. Ну, и при таком подходе можно формально проверить: достаточно ли полна модель данных для выражения тех или иных инженерных диаграмм, достаточно ли данных для тех или иных солверов, достаточно ли алгоритмов для тех или иных солверов.
Интересно бы сравнить впрямую эти два способа интеграции (в мышлении и компьютерах) различных инженерных моделей:
-- на базе общей математики и физики (придания физического смысла математическим моделям, в том числе структурным математическим моделям), Баез, кажется, хотел бы идти этим путём
-- на базе классического онтологического подхода (базы данных, хранящие модели на языках моделирования отдельно, и отдельно алгоритмы их обсчёта -- самые разные алгоритмы, обсчитывающие самое разное по этим моделям).
Мне кажется, нужно как-то учитывать оба этих подхода.
Вот мой план, по которому можно было бы как-то попасть в инженерный рай с использованием теории категорий:
1. Ограничиться задачей архитектурного синтеза (слово "ограничиться" тут выглядит издёвкой, ну да ладно). Архитектурный синтез -- это когда мы пытаемся взаимно оптимизировать компонентное описание (одну или несколько принципиальных схем -- "как оно работает") и модульное описание (продукты, детали и т.д. -- "из чего мы это сделаем, и сколько оно будет стоить"). Про размещения и прочая пока умолчим.
3. Про принципиальные схемы -- можно идти по линии, намеченной Баезом сотоварищи.
4. Понять, как описывать модули. Это всяческие BOM, это описания протоколов (интерфейсов).
5. Разобраться с формализацией архитектурного синтеза. Тут уже тьма самых разных работ:
-- неформальный ТРИЗ: можно начинать с проглядывания трёх текстов: АРИЗ-85В http://www.triz-ri.ru/triz/triz02.asp, типовых приёмов разрешения противоречий http://www.triz-ri.ru/triz/triz04.asp и стандартных решений изобретательских задач -- http://www.triz-ri.ru/triz/triz06.asp.
-- contract-based design (группа Генриха Брудни): работы по Heterogeneous reactive systems and component based design со страницы http://people.rennes.inria.fr/Albert.Benveniste/, https://chess.eecs.berkeley.edu/design/2012/discussions/Pdf/ASVDammPasserone_CDC_EJC.pdf, трансляция контрактов в логический язык (как я понимаю, аналогично можно транслировать и в теоркатегорный язык) http://arxiv.org/pdf/1311.3631.pdf, грамматика языка целей и контрактов (Goal Contracts Specification Language): https://project.inria.fr/plasma-lab/gcsl/
-- суперкомпиляторы: http://sober-space.livejournal.com/83013.html и далее по ссылкам в моих репликах
-- Марк Левин, Технология поддержки решений для модульных систем. Электронная книга. 341 с. 2013.
http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf
-- Кузнецов Н.А. и др. -- Метода анализа и синтеза модульных информационно-управляющих систем: http://libgen.org/get?nametype=orig&md5=c3943a8b391b4277fe2ce83e1352e568
-- пример с трассировкой выбранного модуля пожарной сигнализации к размещениям в презентации С.Ковалёва (собственно, там уже теоркатегорный подход был использован): http://incose-ru.livejournal.com/50098.html
-- ... этот список можно продолжать до бесконечности.
Интересно, что этот архитектурный синтез во многих современных работах уже выходит на киберфизику.
Удастся ли как-то найти общее идейное, понятийное и вычислительное ядро во всех этих методах, даже если использовать теорию категорий? А потом на базе этого ядра сделать архитектурный моделер с редактором компонентных и модульных диаграмм плюс архитектурный солвер, вычисляющий мэппинг/трассировку между этими диаграммами, плюс оптимизатор, ставящий под контроль изменения в диаграммах? Язык этого моделера и был бы SysMoLan, а теория категорий рулила бы вычислениями в солвере и оптимизаторе. У инженеров бы тогда не было вопросов, а универсальное понимание всех этих разнообразных методов пошло бы в основу курсов по практикам архитектурной работы в системной инженерии.
Это, конечно, очень сырой план, поэтому в этом посте я привёл не сухой, а мокрый остаток наших обсуждений последнего месяца. Но за неимением других планов будем работать по этому.