?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Теория категорий и системная инженерия: мокрый остаток [21 Dec 2014|08:20pm]
Диаграммных языков огромное множество: блок-схемы, сети Петри, 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, а теория категорий рулила бы вычислениями в солвере и оптимизаторе. У инженеров бы тогда не было вопросов, а универсальное понимание всех этих разнообразных методов пошло бы в основу курсов по практикам архитектурной работы в системной инженерии.

Это, конечно, очень сырой план, поэтому в этом посте я привёл не сухой, а мокрый остаток наших обсуждений последнего месяца. Но за неимением других планов будем работать по этому.
8 comments|post comment

Микросервисы: второе пришествие агентов [21 Dec 2014|11:39pm]
Мартин Фаулер довольно давно уже написал про микросервисы: http://martinfowler.com/articles/microservices.html. Микросервисы там подаются в том числе и как альтернатива корпоративным шинам (smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool).

Движение к децентрализации и операционной модульности неизбежно: микротеории, микросервисы, независимо друг от друга определяемые API -- есть ведь только один вид единомыслия: единонемыслие (Салтыков-Щедрин тут прав, хотя речь и идёт об IT, не нужно забывать, что эту самую IT делают разные команды людей -- и недаром Мартин Фаулер поминает в своём тексте закон Конвея, когда говорит о микросервисах. Для меня это ничем не отличается от CYC с его микротеориями -- того же поля ягоды понижения монолитности общей конструкции).

TM Forum 9 декабря 2014 (пресс-релиз: http://www.tmforum.org/PressReleases/TMForumDeliversFirst/55368/article.html) выпустил набор стандартов Digital Servises Toolkit, которые затрагивают в том числе и сервисы для интернета вещей (IoT) -- http://www.tmforum.org/OpenDigitalEcosystem/16472/home.html

Technology Radar рекомендует держать микросервисы на холде (на январь 2015, это уже выложено в превью: http://www.thoughtworks.com/radar/techniques/microservice-envy). Это самая первая стадия в цепочке hold-assess-trial--adopt. Но в поле зрения радара микросервисы уже появились.

Я не думаю, что микросервисы ожидает счастье-пресчастье: шуму о них будет много, толк же будет получаться в очень ограниченной нише. Для меня это реинкарнация агентского подхода. Smart endpoints, говорите? Интернет вещей? Вот-вот: агентский подход, только без излишней начальной антропоморфности, со всем возможным повторением его трудной судьбы.

Интересно, что будет происходить в этих микросервисных архитектурах с моделированием данных.
15 comments|post comment

navigation
[ viewing | December 21st, 2014 ]
[ go | previous day|next day ]