Я бы посмотрел на какое-нибудь реально используемое приложение с открытым кодом, сделанное с таким подходом (в котором основная база — это графовое хранилище с OWL). Не на академический пример, а на инструмент, который для практических целей применяют люди, вообще не знающие, что такое OWL. Как wordpress какой-нибудь. Это должно демонстрировать преимущества такой системы в чисто практическом, а не идеологическом смысле, а ведь только таковые и имеют значение. Знаю про data.world, но это всё-таки немного не то — ближе к СУБД, чем к приложению для конечного пользователя.
Domain Driven Design учит нас, что программная система есть воплощение модели предметной области. Сущностям в реальном мире соответствуют сущности в программе. Но более аккуратно будет сказать, что модель в системе почти никогда не бывает одна — их всегда много, потому что разные организации, подразделения одной организации и даже разные группы пользователей видят мир по-разному. Для одной и той же ситуации в реальности можно изобрести бесконечное количество моделей, и применимость каждой из них зависит от поставленной цели.
Например, сущность InventoryItem для склада имеет одни параметры (местоположение, объём занятого места, владелец, ...). Для мастерской она отображается в разные сущности, например, Part, Tool, RawMaterial,… — которые, хотя и лежат на складе, но в процессах мастерской совсем разные функции выполняют.
Выбирая правильную модель для данных, вы смотрите на то, какие типичные операции с этими данными будут производиться и, следовательно, решаете, как должны храниться данные, чтоб указанные операции были возможны. Хотя бы на глаз оцениваете вычислительную сложность этих операций. Изучаете требования к правам доступа, потому что бывает, что требуется хранить, условно, имя в одном месте, а email в другом, в изолированных друг от друга хранилищах. Иначе вы не получите контракт.
Я не верю, что может существовать один-единственный наилучший способ создавать модели данных, хранить их, делать запросы, и всё это — эффективно.
Имея сколько-то миллиардов иммутабельных строк в таблице, я скорее всего возьму колоночную СУБД. В другом месте — документ-ориентированное хранилище, потому что надо динамически менять схему. В третьем — ElasticSearch для поиска, где-то ещё — Redis для кэша, и так далее.
Это не бинарная шкала, это континуум применимости разных моделей к разным кусочкам реального мира для разных целей. Здесь нет ничего чёрно-белого, ничего единственно правильного, никакой генеральной линии партии.
Data centric manifesto, однако же, выглядит очень чёрно-белым: за всё хорошее и против всего плохого, — и крайне хайповым. Data centric revolution… сам этот апломб опускает уровень обсуждения с технического на идеологический; не люблю такого. С чего авторы решили, что это революция? Чем это принципиально отличается от привычной для больших организаций схемы, когда в центре стоит какая-нибудь Oracle, а вокруг неё крутится сотня приложений? Схемы, от которой люди годами пытаются уйти, потому что взаимные зависимости между приложениями сводят их с ума? Вы поменяли табличку (или каокой-нибудь rdfs:domain) в интересах приложения X, и у вас приложения Z, P и N стали валиться удивительным и необычным образом. Мы это уже проходили и заработали некое количество седых волос, нет?
Потом, конечно, появился новый хайп в виде микросервисов, которые тоже подходят не всегда. Но когда-нибудь же надо позврослеть? Осознать, что серебряной пули нет и никогда не будет. Реальный мир сложен. Наша профессия как его отражение тоже сложна. Хватит качаться, повиснув на маятнике моды, в поиске универсальных решений сложных проблем, и метаться то туда, то сюда, снова и снова, и конца этому не видно. Нет таких решений. Надо в каждом отдельном случае думать головой, анализировать, опираться на опыт, подлечивать граблями набитые шрамы.
Моё мнение заключается в том, что семантические технологии могут быть полезны скорее для общения между системами, которые могут хранить данные и манипулировать ими внутри так, как им заблагорассудится, потому что метод этой манипуляции данными внутри приложения может быть в таком случае оптимизирован до предела, радуя программистов, сокращая carbon footprint и генерируя квадриллионы розовых пони в фемтосекунду.
Кроме того, не потребуется тогда даже переписывать гигатонны существующего кода в угоду очередной сверкающей блёстками идеологии, что было бы астрономически дорого.
1) Спасибо, интересно.
2) Есть ли источники по теме, которые вы бы посоветовали, чтобы ознакомиться с разными вариантами?
3) Все тексты и user stories пишутся в Jira или в отдельной системе?
4) Помимо документации на каждую задачу отдельно, есть ли общая документация по архитектуре системы, которая меняется реже?
5) Если да, то как решается задача её стандартизации и актуальности?
6) Пишутся ли все тексты руками, или в них есть кусочки, которые генерируются автоматически (пример: список полей в таблице)?
Можно попытаться начать с упомянутых RDF/OWL как с наиболее близкой технологии из существующих. Но для самого OWL, насколько я знаю, не существует человекопонятных средств разработки, и его использование в широкой практике проблематично. Кроме того, представляется, что законодательство — это очень крепкий орешек в плане составления для него онтологии, поскольку оно охватывает практически все стороны жизни. Необходимо задать огромное количество понятий и отношений между ними, притом так, чтоб это было понятно машине.
Вот мне сейчас пришла мысль: как можно закодировать первый закон робототехники "робот не может допустить, чтобы человеку был причинён вред"?
Многобукв
Для этого необходимо определить понятия:
"человек"
"вред"
"причинение вреда человеку" (отношение между двумя этими понятиями)
"недопустимость"
Что нужно сделать, чтобы робот понимал это?
Поскольку посредством сенсоров робот может изучать мир вокруг себя и выделять в нём отдельные объекты, "человека" можно определить как объект, удовлетворяющий каким-либо признакам, формализовать которые явно — необязательно. Может быть, в ПО робота находится уже обученная нейросеть, которая получает на вход данные от сенсоров и возвращает оценку — человек или не человек, и таким образом наблюдаемому объекту присваивается семантическая метка. За неё можно ухватиться.
"Причинение вреда человеку" — ещё сложнее. Не берусь судить, возможно ли научить нейросеть это определять. Но допустим, что возможно, и у робота есть другая обученная нейросеть, которая выдаёт вероятность того, что данному объекту типа "Человек" причиняется вред.
Этих двух компонент вроде бы достаточно, чтобы можно было зафиксировать нарушение Первого закона, но недостаточно, чтобы робот его исполнил. Для этого робот должен иметь в виду:
Какой объект причиняет вред объекту Человек?
Каким образом этот вред причиняется?
И, наконец, исходя из этих условий, какие действия должны быть предприняты для того, чтобы робот выполнил Первый закон наиболее эффективным образом?
Когда эти вопросы будут решены, то есть закон смогут выполнять машины, — свойственные юриспруденции проблемы будут решены раз и навсегда.
Можно выложить большое количество кода в Open Source, но от этого не будет пользы, если у пользователей нет особо инструментов его анализа и — главное — выполнения. Единственный инструмент выявления противоречий в законодательстве и его применения к реальности — это человеческий мозг.
Пытаясь добиться максимальной ясности и точности изложения, законодательство в то же время пользуется естественным языком, что и для человека нечитабельно, и машине недоступно. И поэтому требуется профессия юриста как своего рода интерфейса между законом и пользователем.
Рано или поздно наступит момент, когда станет возможным описывать законодательство на формальном логическом семантическом языке (тебе привет, RDF/OWL), понятном машине и поддающемся верификации. В идеале, модули на этом языке можно загружать в системы моделирования с целью хотя бы приблизительно оценить их влияние на экономическую и политическую ситуацию. Ну и машины, понимающие закон, станут способны автоматически исполнять его.
Написали правку — промоделировали, верифицировали, прогнали тесты, провели развёртывание в децентрализованную сеть — и через сутки по всей стране разрешено к использованию новое лекарство. Или летающие дроны стали самостоятельно соблюдать новые правила безопасности полётов.
(Мысль наверняка не новая, и на этот счёт уже, вероятно, существует и какая-нибудь антиутопия о тотальном контроле, но с такой системой и государство становится куда более децентрализованным, и процедура принятия правок в его исходный код становится более контролируемой.)
Мне не приходилось внедрять BPM на практике, изучал его только теоретически — читал книги, спецификацию BPMN, смотрел продукты типа BizAgi, читал ругательные статьи о том, что BPMN не имеет под собой математического формализма, — и пытался понять, как всё это может быть мне полезно. Так что этот комментарий можно считать диванным теоретизированием.
Статья перекликается с постом The Churn by Robert C. Martin: http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html Среди всего прочего, Роберт Мартин указывает на то, что всякий новый язык или технология неизбежно лишены тех средств разработки, анализа кода, тестирования и рефакторинга, что уже созданы для языков предыдущего поколения, и потому продуктивность разработки на новом языке по определению ниже. Ну, для BPM проблема усложняется ещё и добавлением дополнительных измерений, как вы указали.
А теперь следующий вопрос. А почему, собственно, нужно бросаться из крайности в крайность и отказываться от нормальных средств разработки? BPMN-диаграмма — это исполняемая программа, написанная на визуальном языке. Пользователи и аналитики в большинстве случаев не могут изменять эту диаграмму так, чтобы при этом покрывать изменения юнит-тестами и гарантировать, что в остальных частях системы ничего не сломается. Таким образом, модифицирующая функция BPM не очень работает. Но зато визуальная схема, то есть, — функция документирования и мониторинга, — сама по себе была бы очень полезна для понимания логики системы и происходящих в ней сию секунду процессов даже в самых простых системах, где внедрять BPM никто и не собирался, а рисовать это всё руками не имеет смысла. Почему бы не сделать следующим образом.
Логика процесса реализуется в коде приложения на разработанном для этих целей DSL, имеющем такие сущности как задача, условие, цикл, начало или конец процесса, подпроцесс. Контроль типов, статический анализ, отладка, тестирование, рефакторинг — всё на месте. Пример библиотеки для Python: viewflow. Не искал ещё аналога для Scala, — думаю, там можно сделать многократно красивее.
Такие вещи, как определение текущего шага для данного пользователя, или вывод всей схемы в графическом виде с иллюстрацией её состояния в реальном времени — делаются автоматически, что резко упрощает документирование системы. Разумеется, возможны аннотации типа стилей схемы или расположения квадратиков, но в целом визуальная схема целиком определяется тем, что в коде написано.
У BPM есть одна (потенциальная) возможность, которая вроде бы есть шаг вперёд по сравнению с традиционной разработкой: если изменить процесс с версии 1 на версию 2, то в зависимости от возможности и необходимости можно либо 1) продолжать выполнять старые уже запущенные процессы на версии 1, а новые запускать уже на версии 2, — либо 2) перевести старые процессы на версию 2 прямо в процессе выполнения. Мне представляется, что такую возможность можно и без BPM реализовать, это зависит исключительно от того, насколько хорошо система разбита на компоненты и как они друг с другом взаимодействуют. Запустить две копии одного компонента, где в одной будет старый код, а в другой новый, и разделять по ним процессы — совсем не за гранью возможного. И всё это — с контролем типов, рефакторингом, etc.
Что вы думаете о таком подходе, и как вы относитесь к перспективам использования DSL в системах автоматизации бизнес-процессов в принципе?
Я бы посмотрел на какое-нибудь реально используемое приложение с открытым кодом, сделанное с таким подходом (в котором основная база — это графовое хранилище с OWL). Не на академический пример, а на инструмент, который для практических целей применяют люди, вообще не знающие, что такое OWL. Как wordpress какой-нибудь. Это должно демонстрировать преимущества такой системы в чисто практическом, а не идеологическом смысле, а ведь только таковые и имеют значение. Знаю про data.world, но это всё-таки немного не то — ближе к СУБД, чем к приложению для конечного пользователя.
Domain Driven Design учит нас, что программная система есть воплощение модели предметной области. Сущностям в реальном мире соответствуют сущности в программе. Но более аккуратно будет сказать, что модель в системе почти никогда не бывает одна — их всегда много, потому что разные организации, подразделения одной организации и даже разные группы пользователей видят мир по-разному. Для одной и той же ситуации в реальности можно изобрести бесконечное количество моделей, и применимость каждой из них зависит от поставленной цели.
Например, сущность
InventoryItemдля склада имеет одни параметры (местоположение, объём занятого места, владелец, ...). Для мастерской она отображается в разные сущности, например,Part,Tool,RawMaterial,… — которые, хотя и лежат на складе, но в процессах мастерской совсем разные функции выполняют.Выбирая правильную модель для данных, вы смотрите на то, какие типичные операции с этими данными будут производиться и, следовательно, решаете, как должны храниться данные, чтоб указанные операции были возможны. Хотя бы на глаз оцениваете вычислительную сложность этих операций. Изучаете требования к правам доступа, потому что бывает, что требуется хранить, условно, имя в одном месте, а email в другом, в изолированных друг от друга хранилищах. Иначе вы не получите контракт.
Я не верю, что может существовать один-единственный наилучший способ создавать модели данных, хранить их, делать запросы, и всё это — эффективно.
Имея сколько-то миллиардов иммутабельных строк в таблице, я скорее всего возьму колоночную СУБД. В другом месте — документ-ориентированное хранилище, потому что надо динамически менять схему. В третьем — ElasticSearch для поиска, где-то ещё — Redis для кэша, и так далее.
Это не бинарная шкала, это континуум применимости разных моделей к разным кусочкам реального мира для разных целей. Здесь нет ничего чёрно-белого, ничего единственно правильного, никакой генеральной линии партии.
Data centric manifesto, однако же, выглядит очень чёрно-белым: за всё хорошее и против всего плохого, — и крайне хайповым. Data centric revolution… сам этот апломб опускает уровень обсуждения с технического на идеологический; не люблю такого. С чего авторы решили, что это революция? Чем это принципиально отличается от привычной для больших организаций схемы, когда в центре стоит какая-нибудь Oracle, а вокруг неё крутится сотня приложений? Схемы, от которой люди годами пытаются уйти, потому что взаимные зависимости между приложениями сводят их с ума? Вы поменяли табличку (или каокой-нибудь
rdfs:domain) в интересах приложения X, и у вас приложения Z, P и N стали валиться удивительным и необычным образом. Мы это уже проходили и заработали некое количество седых волос, нет?Потом, конечно, появился новый хайп в виде микросервисов, которые тоже подходят не всегда. Но когда-нибудь же надо позврослеть? Осознать, что серебряной пули нет и никогда не будет. Реальный мир сложен. Наша профессия как его отражение тоже сложна. Хватит качаться, повиснув на маятнике моды, в поиске универсальных решений сложных проблем, и метаться то туда, то сюда, снова и снова, и конца этому не видно. Нет таких решений. Надо в каждом отдельном случае думать головой, анализировать, опираться на опыт, подлечивать граблями набитые шрамы.
Моё мнение заключается в том, что семантические технологии могут быть полезны скорее для общения между системами, которые могут хранить данные и манипулировать ими внутри так, как им заблагорассудится, потому что метод этой манипуляции данными внутри приложения может быть в таком случае оптимизирован до предела, радуя программистов, сокращая carbon footprint и генерируя квадриллионы розовых пони в фемтосекунду.
Кроме того, не потребуется тогда даже переписывать гигатонны существующего кода в угоду очередной сверкающей блёстками идеологии, что было бы астрономически дорого.
1) Спасибо, интересно.
2) Есть ли источники по теме, которые вы бы посоветовали, чтобы ознакомиться с разными вариантами?
3) Все тексты и user stories пишутся в Jira или в отдельной системе?
4) Помимо документации на каждую задачу отдельно, есть ли общая документация по архитектуре системы, которая меняется реже?
5) Если да, то как решается задача её стандартизации и актуальности?
6) Пишутся ли все тексты руками, или в них есть кусочки, которые генерируются автоматически (пример: список полей в таблице)?
Можно попытаться начать с упомянутых RDF/OWL как с наиболее близкой технологии из существующих. Но для самого OWL, насколько я знаю, не существует человекопонятных средств разработки, и его использование в широкой практике проблематично. Кроме того, представляется, что законодательство — это очень крепкий орешек в плане составления для него онтологии, поскольку оно охватывает практически все стороны жизни. Необходимо задать огромное количество понятий и отношений между ними, притом так, чтоб это было понятно машине.
Вот мне сейчас пришла мысль: как можно закодировать первый закон робототехники "робот не может допустить, чтобы человеку был причинён вред"?
Для этого необходимо определить понятия:
Что нужно сделать, чтобы робот понимал это?
Этих двух компонент вроде бы достаточно, чтобы можно было зафиксировать нарушение Первого закона, но недостаточно, чтобы робот его исполнил. Для этого робот должен иметь в виду:
Когда эти вопросы будут решены, то есть закон смогут выполнять машины, — свойственные юриспруденции проблемы будут решены раз и навсегда.
Можно выложить большое количество кода в Open Source, но от этого не будет пользы, если у пользователей нет особо инструментов его анализа и — главное — выполнения. Единственный инструмент выявления противоречий в законодательстве и его применения к реальности — это человеческий мозг.
Пытаясь добиться максимальной ясности и точности изложения, законодательство в то же время пользуется естественным языком, что и для человека нечитабельно, и машине недоступно. И поэтому требуется профессия юриста как своего рода интерфейса между законом и пользователем.
Рано или поздно наступит момент, когда станет возможным описывать законодательство на формальном логическом семантическом языке (тебе привет, RDF/OWL), понятном машине и поддающемся верификации. В идеале, модули на этом языке можно загружать в системы моделирования с целью хотя бы приблизительно оценить их влияние на экономическую и политическую ситуацию. Ну и машины, понимающие закон, станут способны автоматически исполнять его.
Написали правку — промоделировали, верифицировали, прогнали тесты, провели развёртывание в децентрализованную сеть — и через сутки по всей стране разрешено к использованию новое лекарство. Или летающие дроны стали самостоятельно соблюдать новые правила безопасности полётов.
(Мысль наверняка не новая, и на этот счёт уже, вероятно, существует и какая-нибудь антиутопия о тотальном контроле, но с такой системой и государство становится куда более децентрализованным, и процедура принятия правок в его исходный код становится более контролируемой.)
Мне не приходилось внедрять BPM на практике, изучал его только теоретически — читал книги, спецификацию BPMN, смотрел продукты типа BizAgi, читал ругательные статьи о том, что BPMN не имеет под собой математического формализма, — и пытался понять, как всё это может быть мне полезно. Так что этот комментарий можно считать диванным теоретизированием.
Статья перекликается с постом The Churn by Robert C. Martin: http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html Среди всего прочего, Роберт Мартин указывает на то, что всякий новый язык или технология неизбежно лишены тех средств разработки, анализа кода, тестирования и рефакторинга, что уже созданы для языков предыдущего поколения, и потому продуктивность разработки на новом языке по определению ниже. Ну, для BPM проблема усложняется ещё и добавлением дополнительных измерений, как вы указали.
А теперь следующий вопрос. А почему, собственно, нужно бросаться из крайности в крайность и отказываться от нормальных средств разработки? BPMN-диаграмма — это исполняемая программа, написанная на визуальном языке. Пользователи и аналитики в большинстве случаев не могут изменять эту диаграмму так, чтобы при этом покрывать изменения юнит-тестами и гарантировать, что в остальных частях системы ничего не сломается. Таким образом, модифицирующая функция BPM не очень работает. Но зато визуальная схема, то есть, — функция документирования и мониторинга, — сама по себе была бы очень полезна для понимания логики системы и происходящих в ней сию секунду процессов даже в самых простых системах, где внедрять BPM никто и не собирался, а рисовать это всё руками не имеет смысла. Почему бы не сделать следующим образом.
У BPM есть одна (потенциальная) возможность, которая вроде бы есть шаг вперёд по сравнению с традиционной разработкой: если изменить процесс с версии 1 на версию 2, то в зависимости от возможности и необходимости можно либо 1) продолжать выполнять старые уже запущенные процессы на версии 1, а новые запускать уже на версии 2, — либо 2) перевести старые процессы на версию 2 прямо в процессе выполнения. Мне представляется, что такую возможность можно и без BPM реализовать, это зависит исключительно от того, насколько хорошо система разбита на компоненты и как они друг с другом взаимодействуют. Запустить две копии одного компонента, где в одной будет старый код, а в другой новый, и разделять по ним процессы — совсем не за гранью возможного. И всё это — с контролем типов, рефакторингом, etc.
Что вы думаете о таком подходе, и как вы относитесь к перспективам использования DSL в системах автоматизации бизнес-процессов в принципе?