Введение
Недооцененная книга Криса Партриджа задает онтологию физического мира, которая полезна для любого моделирования и особенно полезна для инженеров занимающийся разработкой софта. Весь физический мир и существенную часть ментального мира можно разделить на следующие базовые типы: элементы, классы и кортежи. В разработке есть уровень понимания и операционный уровень. Обычно разработка происходит на операционном уровне, когда рассматриваются понятия и действия с ними. На уровне понимания понятия декомпозируются на базовые типы, что позволяет четко понять к чему они реферируют в реальном мире. Это дает неожиданные инсайты и упрощает разработку. Чем более сложная разработка, тем больше эффектов от понимания и упрощения. За моделью в софте всегда стоит какая-то реальная система и полезно понимать это. Онтология BORO помогает понимать устройство физической системы и моделировать ее.
Книга BORO
Посоветовали прочитать книжку BORO - Business Objects: Re-Engineering for Re-Use написанную Chris Partridge. http://borosolutions.net/sites/default/files/Business%20Objects%20-%20Re-Engineering%20for%20Re-Use%20(3rd%20Ed%20-%20early%20draft%20-%2020140927).pdf Первая версия книги была написана в 1996 году и в следующих переизданиях принципиальных изменений не было.
Книга задает онтологию физического мира - как разные понятия, с которыми мы сталкиваемся в жизни можно формализовать как объекты физического мира. Вопрос не такой простой, как кажется на первый взгляд. Рассмотрим, например, мой телефон на столе. Понятно, что это объект физического мира. А вот если мы перейдем к понятию “мобильный телефон” вообще, все становится сложнее. К чему реферирует понятие “мобильный телефон”? К чему реферирует понятие, ну, например, “готовка ужина”? Ответы на эти вопросы в терминах элементов, классов и кортежей есть в книге BORO
В курсах ШСМ https://system-school.ru/ прям существенно используются идеи из этой книги. Ссылки и совет прочитать BORO есть в курсе “Моделирование” и как задание ко второй главе в курсе “Системного мышления” Кроме того, мне посоветовал ее прочитать Анатолий Левенчук в комментариях "Моделирование" - результаты
Я бы советовал пройти [книжку BORO] … для работы сразу будет полезно, программистам это важно, но отсутствует в их учебных курсах
Необычный совет, если вдуматься. Что такого может дать подобная книга программистам? Впрочем, я недолго размышлял, а прочитал книгу и вот теперь пишу мысли по поводу.
Ответ в том, что программисты частенько размышляют в абстракциях, не доводя свои размышления до физического мира. А это не хорошо, т.к. все программы в конечном итоге создаются для того, чтобы помогать взаимодействовать с реальным мир. Книга помогает формализовать, что же это такое реальный мир.
Книга достаточно тяжелая, некоторые детали кажутся ненужными, диаграммы со сложным и непонятным UML раздражают. Вообще основы лучше даны в статье BORO Foundation Enterprise Ontology | BORO
Но все-же и в самой книге есть уникальный материал, в последних главах классные и важные примеры использования этой онтологии. Эти примеры и понимание связанное с ними можно прям сразу использовать в своих проектах.
Базовые типы
Все объекты онтологии делятся на три базовых типа
- элемент - 4D-физический объект с протяженностью в пространстве-времени
- класс - объединение объектов, возможно бесконечное. Объекты могут быть любого типа
- кортеж из двух объектов. Объекты также могут быть любого типа.
Итого, весь физический мир и часть объектов ментального мира можно представить в этой онтологии. Это означает, что можно понять к чему реферирует то или иное понятие. Например понятие “стул” будет реферировать к классу всех стульев. Т.е. представляем разные физические стулья в пространстве-времени и объединяем эти все эти объекты в класс. Тогда понятие “стул” в точности совпадает с этим классом всех физических стульев
С кортежами еще более интересно. Многие отношения между объектами сводится к кортежу. Например отношение часть-целое. Вот например, есть ноутбук, в нем есть клавиатура. Тогда клавиатура физический объект, ноутбук физический объект, Если мы рассмотрим кортеж “клавиатура”, ”ноутбук” то это пример отношения часть-целое. Все подобные кортежи составят класс кортежей и этот класс совпадает с отношением часть-целое. За счет того, что элементы рассматриваются в 4D, многие отношения типа “Аня смотрит в окно”, также можно декомпозировать в отношение часть-целое и в соответствующие кортежи. В этом конкретном случае “Аня смотрит в окно” - это процесс в виде 4D-объекта, частью которого является “Аня”, другой частью “окно”, еще могут быть неуказанные части такие как “пролетающий голубь за окном”, “подоконник на котором сидит Аня” и другие.
Получается довольно удобно и покрывает весь физический мир и довольно большую часть ментального.
Все же важно понимать, что покрывается не весь мир, с некоторыми понятиями довольно трудно работать в этой онтологии. Ну, например, понятие “бог” не очень понятно к чему реферирует, или понятие “злость”, или скажем понятие “обязательства продавца перед третьими лицами”. Есть и более тонкие различия. Понятие “яблоко” в онтологии BORO не будет совпадать с понятием “яблоко” в обычной речи. Почему? Потому что яблоко в BORO реферирует ко классу всех реальных яблок бывших и будущих в разных мирах, но яблоко из райского сада в него не попадает, его в онтологии BORO нет - ну по крайней мере непонятно, как его там выразить - кажется, что типы яблок из магазина и райского яблоко будут отличаться. https://youtu.be/2uWqFQBeqmY?t=108
В общем понятно, что с некоторыми понятиями, даже если они представимы в онтологии BORO могут быть сложности. С другой стороны даже размышление о том, к чему в реальном мире реферирует то или иное понятие оказывается довольно полезным.
Вообще, вот это разделение на “элементы”, “классы” и “кортежи” кажется довольно волюнтаристским. И да, наверное это так, такое разделение продиктовано больше соображениями удобства, различные понятия физические и ментальные хорошо без дополнительных прокладок раскладываются на эти типы. Если говорить о каком-то математическом понимании фундаментальности, наверное эти типы не совсем фундаментальны.
Моделирование
Сначала будет полезно проговорить, как устроены действия в реальном мире
Итак, предположим что в реальном мире какой-то агент что-то делает, в некоторый момент времени, возможно, в будущем. Если агент ничего не делает и ему ничего не требуется делать, то дальше не размышляем, прагматизм говорит, что можно игнорировать всё, что не влияет на реальность
Чтобы агент что-то сделал, он моделирует реальный мир. Т.е. реальный мир во всей своей полноте схлопывается до каких-то моделей, довольно маленьких по сравнению с реальным миром, но именно в этих моделях всё важное. Такое моделирование происходит всегда, когда агент принимает решения - осознанно или неосознанно он производит некоторые вычисления, например, в мозгу, а вычисления невозможно сделать в реальном мире, они делаются в модели, которая из реального мира берет лишь важнейшие детали.
Замечу что это общие рассуждения применимые вообще для любых действий любого агента. Даже обезьяна будет это делать, когда требуется сбить банан палкой.
Когда мы говорим о моделировании, то речь идет о том, что создается модель физического мира для некоторых целей. Пример такой модели - это программное средство созданное инженерами-программистами. Но вообще модели это не обязательно про софт. Любой агент создает модель для действий. Да и агент может быть разный: обезьяна, человек, человек со сложным софтом, организация, страна. Таким образом работает любое моделирование, это не специфично для BORO.
В связи с BORO меня в первую очередь интересовала разработка приложений, но, в целом, несмотря на то что и книга про разработку приложений, ее материал применим для любого моделирования любыми агентами, не обязательно в программной разработке, но и в мозгу или в каких-то документах.
Итак, будем считать, что требуется разработать некоторое приложение которое будет помогать с некоторыми действиями в физическом мире. Вообще это приложение может быть прям сильно связано с этими физическими действиями, тем не менее концептуально у нас есть отдельно физический мир и отдельно приложение, которое моделирует этот физический мир, производит некоторые вычисления с этой моделью Также есть взаимодействие между физическим миром и приложением.
Уровень понимания и операционный уровень
В книге одна из самых полезных и неожиданных концепций - это разделение на уровень понимания и операционный уровень, understanding vs operational level.
Уровень понимания это не про разработку, это то, что происходит до разработки приложения, собственно именно поэтому этот уровень легко пропустить. И именно благодаря этому онтология BORO полезна не только для разработки, но и в целом для понимания устройства мира. Впрочем в разработке это проявляется наиболее выпукло, поэтому в основном ведем речь про разработку.
Рассмотрим сначала как устроено моделирование на операционном уровне, “обычно”. Для этого смотрятся какие понятия нужны для выполнения задачи и какие действия с этими понятиями необходимо выполнить. Оказывается, можно годами размышлять на операционном уровне об объектах, о действиях над ними, не понимая глубоко, как они устроены и к чему реферируют. Причем может казаться, что понимание глубокое, но это иллюзия. Уровень понимания не затрагивается на операционном уровне, чтобы понять устройство объектов, надо специальным образом размышлять о том, как они устроены. Таково странное свойство человеческого разума, это и плюс и минус - очень легко можно размышлять о странных вещах, которые непонятно, что означает. В повседневной жизни это не страшно, потому что к каждому понятию прилагаются какие-то действия, которые можно с этим объектом производить.
Например, есть понятие “предложение о покупке товара” и есть какое-то понимание различных действий доступных для работы с этим понятием: “принять предложение”, “отказаться”, “отказаться и сделать встречное предложение”. Все эти действия и связь их с понятиями высвечиваются из некоторых знаний, который человек набирает в процессе знакомства с предметной областью.
Другой пример, понятие “дрель”, и различные действия доступные с ним “сверлить”, “положить на полку”.
Все эти рассуждения происходят на операционном уровне. Когда мы реализуем некоторое приложение, можно работать на операционном уровне, т.е. работать исходя из возможных действий с понятиями.
Если вдуматься, можно заметить проблему. А вдруг какие-то важные действия для работы с понятием пропущены. Но действий быть может очень большое количество и возможно проблема не решится и через год размышлений может оказаться, что какое-то важное хитрое действие пропущено, а реализация поддержки этого действия ломает весь софт.
Оказывается даже глубокое и экспертное знакомство с предметной областью может быть недостаточно для реального понимания объектов
Онтология BORO говорит, давайте смотреть не на возможные действия, которые можно делать с этим понятием, а на то как это понятие принципиально устроено. Это как раз уровень понимания.
Это принципиальное устройство прописывается в терминах типов: элементов, классов и кортежей.
Оказывается подобное принципиальное рассмотрение очень полезно и позволяет не пропустить ни одно из всех возможных действий, т.к. эти действия всегда происходят с понятием, а понятие строго определено в типах и реферирует к чему-то реальному. Причем в процессе разбиения понятия на типы может быть переосмысленно содержание понятий, понятия могут быть разбиты на какие-то другие. Итого, такое рассмотрение позволяет выстроить гибкую архитектуру, которая позволит описать любые сложности, которые могут возникнуть в будущем.
Интересно, что даже экспертное знакомство с предметной областью не позволит автоматически глядеть на мир таким образом, надо сначала понимать как смотреть на мир и только потом получается увидеть в понятиях классы, кортежи и элементы.
Упрощение сложного
Обычно разработка устроена так, что чем более сложная тема, тем более сложно устроена разработка. Есть некие задачи, в соответствии с этими задачами выделяются понятия, потом для этих понятий смотрится какие можно делать действия. Понятия и действия выделяются в соответствии с пониманием системы. С усложнением системы примерно линейно растет и сложность. Вообще сложность растет даже быстрее, т.к. сложные вещи взаимодействуют между собой. Тем не менее, обычно находятся какие-то паттерны, помогающие справиться со сложностью.
Онтология BORO утверждает удивительную штуку - если моделировать, имея ввиду реальный мир, то сложные вещи становятся простыми. Любая новая сложная вещь означает, что появилось некоторое понимание о том как устроен мир. Это понимание выражается в классах, кортежах, элементах. Причем этот процесс отнюдь не бесконечный. Если что-то было разделено в реальном мире на классы, элементы, кортежи - это уже “навсегда”. Никакие действия с этими объектами на разделение не влияют. Разделение может поменяться только если была допущена ошибка, что в общем-то редко происходит. Таким образом при добавлении новой функциональности, в том числе очень сложной, софт не усложняется в разы и даже наоборот, он может упроститься, т.к. добавление новой функциональности подсвечивает более сложную структуру реальности. А чем ближе к реальности построенная модель, тем лучше понимание, тем более точно можно отразить в модели то, что происходит в реальном мире. Таким образом мы моделируем в соответствии с пониманием реальности, какие есть в нем объекты, как эти объекты устроены, какого они типа и только потом думаем как в этих объектах выглядят задачи, которые необходимо решить.
Из-за того, что абсолютно понятно как устроены объекты, решение задач происходит проще, в том числе сложных.
В книге несколько примеров приведено: с географическими областями и с названиями. С географическими областями получается прикольно, что там много отношений часть-целое. Итого такие сущности как “Англия” или “Москва, ул. Володарского” или “СССР” оказываются одного типа. Тут важно, что все эти географические области рассматриваются как 4D-объекты. Еще ключевой момент - что 4D объекты могут быть вложены друг в друга. Вообще, по линии BORO очень много отношений оказываются вложением друг в друга, причем многоуровневыми.
С названиями еще более интересно. Для информационной системы логично иметь множество сущностей типа “Название”. В какой-нибудь базе данных может быть сотни столбцов в разных таблицах типа “Название”. Предлагаемая концептуализация без потери гибкости позволяет все названия вынести в одну табличку. Важно, что это не просто решение типа “давайте вынесем все названия в одну табличку”, а вполне объясняется почему это можно сделать с упрощением модели мира, оказывается “название” тоже реферирует к определенному реальному классу. Тут замечу, что конечно нет смысла условно менять базу и убирать все столбцы с “Названиями”, не затрагивая остальных табличек. Более того, названия можно оставить и напоследок, самые интересные и важные эффекты проявляются при работе с объектами близкими к предметной области.
Также интересно смотреть на события. События рассматриваются как мгновенный 3D-срез в 4D-объекте.
Переход от уровня понимания к операционному
На операционном уровне, если смотреть на систему как 4D-объект есть свои специфические проблемы. Они немного другие, нежели при классическом моделировании, когда происходят размышления сразу на операционном уровне без уровня понимания.
Любая система рассматривается как 4D-объект. Но в разработке существенным образом задействуется понятие текущего момента. Например, в CRM системе нас может интересовать какие есть клиенты вот сегодня. Это не вся клиентура во всей ее 4D-полноте, а вот прям срез в текущий момент времени.
В книге для этого предлагаются какие-то решения с динамическими состояниями, но тут важно понимать, что любые подобные рассуждения они операционного уровня, на уровне понимания их нет.
То же самое касается про знания, сохраняемые в софте, в книге это consiousness - сознание софта. Подобные знания должны быть доступны в определенный момент времени для того, чтобы что-то вычислять и в конечном итоге совершать взаимодействия с физической системой.
Софт как-то реагирует на входящую информацию, софт также может инициировать действия
Помним об этом, тогда реакция софта на входящую информацию - это синхронизация модели с реальным состоянием системы. Софт принимает информацию из реального мира, это означает что мир уже изменился и синхронизирует модель мира внутри себя в соответствии с полученными данными. Модель концептуально запаздывает по сравнение с миром. Пример, оператор курьерской доставки вводит информацию о посылке в софт, и софт синхронизирует состояние модели с тем, что в реальном мире появилась посылка.
В то же время исходящая информация - сигнал к действию, к изменению реального мира. Софт инициирует изменения в реальном мире и ожидает ответа от реального мира.
Вот эти рассуждения кажется очень полезным. Самое важное тут, что софт - это модель физического мира и существует не отдельно от него, а совместно и важно синхронизировать то, что происходит в реальном мире с моделью. Причем в модели отражается не весь мир в полноте, а лишь самые важные моменты. Еще кажется очень важным, что модель в софте догоняет реальный мир, а не наоборот. Т.е. если сначала в софте происходят изменения, а потом в физическом мире - это неправильно, софт вторичен по отношению к физическом миру.
Множество разных вопросов, что делать когда софт непонятно как привязан к физическому миру, например эта игра или скажем поисковая система. Тут несколько соображений.
- В любом случае софт что-то в физическом мире меняет, иначе он был бы никому не нужен, тут надо находить что он меняет.
- Что касается игр, они хоть и не существует в реальном мире, но существует в некотором вымышленном мире, наверное можно проводить схожие рассуждения с типизацией объектов вымышленного мира. Это надо проверять и думать
- Сложные системы могут взаимодействовать между собой, в том числе одни системы будут создавать другие. Всегда речь идет о каких-то объектах физического мира. Как только речь идет о физическом мире и о моделировании этого физического мира в софте можно думать указанным выше способом. В сложных ситуациях могут быть задействованы множество систем, множество моделей и соответствующего софта использующего модели
Общее впечатление
Книга на английском, читать было довольно тяжело. Но это полезный опыт, вся свежая информация в мире на английском, надо привыкать читать. Книжка более чем в 400 страниц. Под конец читалось гораздо легче.
В книге много диаграмм, которые показались не полезными, лучше бы все это было рассказано текстом. Кажется ее можно было бы сократить раза в два без ущерба для смысла и понимания.
Впрочем все это из-за того, что первое издание книги было в 1996 году, а в дальнейших переизданиях она кардинально не переписывалась.
В целом, книга конечно не легкое чтиво, да и выбранная структура и акцент на реинжиниринг, а не на создание нового софта приводит к тому, что первая половина книги рассказывает об общепринятых подходах к моделированию, а не о том подходе который предлагает BORO. Т.е. получается некоторый исторический экскурс вместо того, чтобы давать сразу “как надо”. Акцент на реинжиниринг, а не на создание нового софта также раздражает. Может это и полезно с чьей-то точки зрения, но вообще-то создается множество нового софта, для которого были бы полезны принципы рассказанные в книге, а тут даже название отталкивает.
Но если продраться через все это, материал полезный. Я прям поймал ощущение, когда оказалось, что моя разработка привязана к физическому миру, а не просто существует в компьютерах. Это круто, дает почву под ногами. Хотя, наверное, возможен и другой вариант, когда наоборот становится понятно, что почвы нет и разрабатываемый софт не нужен. Ну тоже хорошо, чем раньше это станет ясно тем лучше.
Использование материала
Мне непосредственно удалось применить материал книги к специфики трейдинга.
Получилось интересное понимание, что такое сделка, что такое ордер. Получилось довольно нетривиально, я нигде не встречал такое понимание трейдинга. Может читал недостаточно книг, а может действительно какое-то новое понимание
Это понимание привело к полному изменению архитектуры реализуемого мной софта, некоторые вещи стало проще делать.
Планирую написать про это статью, есть очень интересные моменты.
Текст также опубликован в личном блоге Telegram: Contact @burganov