Суть принципа Low Code состоит в том, чтобы перенести как можно больше логики из программного кода приложения на уровень настроек, которые может изменять аналитик, а не программист. Считается, что такой подход позволяет сделать разработку менее трудоемкой и ускорить вывод в продуктив новых возможностей ПО. На практике для реализации этого принципа создаются громоздкие платформы и фреймворки с конфигураторами, которые требуют длительного обучения работающего с ними персонала, замедляют выполнение программ и ограничивают их функциональность. Тем не менее, сама идея переноса логики из программного кода в настройки (данные) приложения продуктивна. В этой статье мы обсудим, как можно ее реализовать с помощью средств онтологического моделирования.
Большинство приложений до сих пор строятся по модели MVC (Model – View – Controller), при которой на разных уровнях программного кода закладывается логика работы с данными, логика представления и логика взаимодействия с пользователем. Чаще всего приложения строятся по трехзвенной схеме, т.е. имеют серверную и клиентскую части, а также базу данных. Понятно, что при таком подходе любое изменение логической структуры данных вызывает необходимость изменять физическую структуру таблиц в базе, а также вмешиваться во все три уровня программного кода. Не спасает и микросервисная архитектура, т.к. структура API каждого сервиса обычно также жестко связана со структурой данных. Все это делает длительным и дорогостоящим процесс адаптации приложений под новые бизнес-требования, связанные с изменением структуры данных и логики их обработки. На практике приложения почти всегда "догоняют" требования бизнеса, но из-за постоянного поступления новых требований никогда их не "догонят". В результате ИТ-система никогда не удовлетворяет полностью функциональным требованиям несмотря на то, что на ее поддержку тратятся существенные ресурсы.
MVC и трехзвенная архитектура, безусловно, проверенные и достойные паттерны проектирования ПО, но не настало ли время перехода к более современным методикам? Мы предлагаем создавать приложения, опираясь на онтологическую модель предметной области. Такие приложения мы будем называть модель-ориентированным, потому что их поведение во многом контролируется со стороны модели.
Онтологическая модель – это машинно-читаемое представление знаний о какой-либо предметной области, представленное в соответствии со спецификациями консорциума W3C: RDF/RDFS/OWL. Онтологическая модель может использоваться для описания структуры данных, также в нее можно поместить и сами данные. Методологически модель делится на два слоя – TBox, в котором содержатся утверждения о классах и свойствах (грубо говоря, о структуре данных), и ABox, содержащий сами данные. Технологически оба слоя представляются в виде графа. Это делает их однородными: управлять и данными, и их описанием можно при помощи одних и тех же средств, таких как SPARQL-запросы, структура которых не отличается при изменении самих данных или их структуры (в отличие от языка SQL, где управление структурой данных и самими данными происходит с помощью запросов разных типов). Важными преимуществами онтологических моделей является возможность отнесения каждой сущности к нескольким типам – а не к одному, как в реляционных СУБД, где таблица, в которой находится запись, определяет единственный ее тип. Каждое свойство того или иного информационного объекта в онтологическом мире может иметь несколько значений, в том числе аннотированных меткой языка или типа данных.
Но и это еще не все. В онтологической модели можно описать и правила обработки информации. Для этого существует несколько способов. Правила контроля логической целостности можно описать в соответствии со спецификацией SHACL Constraints. Правила обогащения, дополнения информации на основе логических выводов описываются в соответствии со спецификацией SHACL Advanced Functions (SHACL Rules). Эта же спецификация задает способы представления в модели математических формул. Каждое правило является набором объектов онтологии, так же, как и любой элемент структуры или данных.
Можно описать в модели и правила трансформации данных, и правила формирования пользовательского интерфейса, и бизнес-логику выполнения приложения – для этого потребуется использовать одну из готовых онтологий или создать свою. Затем нужно написать программный код, который будет интерпретировать структуру и правила модели, и перестраивать логику своей работы в соответствии с вносимыми в них изменениями. Таким образом, онтологическое моделирование позволяет объединить в едином технологическом представлении (графе) сами данные, описание их структуры и логики обработки. Это позволяет ликвидировать искусственно созданный в некоторых методологиях разрыв между этими элементами приложений.
Модель-ориентированное приложение позволит максимально быстро реализовывать некоторые виды функциональных требований. Например, если появляется новый вид объектов данных, описывающих бизнес-объекты, которые надо обрабатывать в приложении в соответствии с некоторой логикой, достаточно будет внести изменения в модель, не трогая программный код – и приложение заработает так, как нужно. Если, конечно, оно было соответствующим образом спроектировано.
Проиллюстрируем различия традиционного и модель-ориентированного подходов к разработке и поддержке прикладного ПО. Для этого сравним, как в обоих подходах выполняются определенные этапы разработки приложения.
| Традиционный подход | Модель-ориентированное приложение |
|---|---|
| Описание структуры данных | |
Чаще всего используются реляционные СУБД, в которых структура данных воплощена в структуре таблиц. При проецировании информации о бизнес-объектах в SQL-базу приходится идти на некоторые компромиссы: например, сведения о физических лицах и индивидуальных предпринимателях скорее всего окажутся в разных таблицах, поскольку у них разный набор свойств, хотя в реальности каждый ИП является физ. лицом. Если какой-то человек интересен в системе и как физ. лицо, и как ИП – скорее всего, для отражения информации о нем будет создано две строки в двух разных таблицах, что вызовет проблемы с обновлением данных. Если используются key-value или документ-ориентированные хранилища, структура данных не описывается явно на уровне базы. Это можно рассматривать как преимущество, однако это усложняет контроль целостности данных и совместную работу разработчиков над программой, т.к. каждый из них потенциально может выбирать любые ключи для отражения тех или иных признаков объектов данных. | Структура данных описывается путем создания классов и свойств. Класс – это множество объектов, обладающих какими-либо общими характеристиками. Классы могут образовывать множество иерархий надкласс-подкласс. Можно задавать любые причудливые конфигурации классов – например "Все контрагенты, кроме ИП и физических лиц". Определения свойств в онтологической модели существуют независимо от классов. Это значит, например, что свойством "Длина" могут обладать объекты разных классов – например, предметы мебели и кузова грузовых машин, что позволяет сравнивать разнотипные объекты по значению одного и того же свойства. Каждый объект может входить в любое число классов одновременно. Набор применимых к объекту свойств наследуется от всех его классов и их надклассов. Для создания классов и свойств обычно за основу берется какая-либо онтология верхнего уровня, разработанная профессионалами в области концептуального моделирования. Затем она расширяется необходимыми доменными (отраслевыми) онтологиями, что позволяет обеспечить интероперабельность данных. Наконец, недостающие классы и свойства вписывает в получившийся набор аналитик-онтолог. |
| Хранение фактических данных | |
В реляционных СУБД данные помещаются в таблицы, в документ-ориентированных – в коллекции. Как правило, разработчики приложения должны сами заботиться о сегментировании и шардировании больших наборов данных, использовать различные механизмы масштабирования СУБД, оптимизировать производительность запросов. | "Родным" для онтологического мира способом хранения информации являются хранилища триплетов – графовые СУБД класса RDF triple store. Такие СУБД плохо подходят для хранения транзакционной информации, зато хороши для хранения аналитической. Если бизнес-приложение работает в режиме близком к реальному времени и постоянно выполняет операции изменения данных, для хранения информации обычно применяют платформы виртуализации данных, которые проецируют наборы объектов определенных классов (но не структуру модели и не правила) в реляционные СУБД. При этом для потребителя данных информация остается единым графом. Разработчику не нужно думать о физической структуре хранения информации, а саму эту структуру можно менять по ходу работы системы, не внося никаких изменений в код. |
| Описание логики обработки данных | |
В традиционном подходе вся логика работы с данными описывается в программном коде. Описание логики обычно жестко связано со структурой данных. | Логика описывается в виде объектов онтологии, представляющих различные виды правил: обогащения и трансформации данных, построения пользовательского интерфейса, выполнения бизнес-процессов. |
| Управление изменениями | |
В процессе эксплуатации приложения обычно поступает поток новых бизнес-требований, которые могут быть связаны с изменениями регуляторных требований и нормативных актов, с новыми бизнес-гипотезами или трансформацией бизнес-процессов. В классическом подходе реализация каждого требования формализуется в виде задачи и ставится в очередь на выполнение. В исполнении задачи могут участвовать разные специалисты: одни изменяют структуру данных в СУБД, другие модифицируют пользовательский интерфейс (фронт-энд), третьи – логику обработки (бэк-энд). Выполнение даже простого требования обычно занимает продолжительное время, от нескольких недель до месяцев. В это время бизнес вынужден решать свои неотложные задачи вне автоматизированной системы. | Для реализации многих функциональных требований аналитику достаточно внести изменения в модель данных (что никак не влияет на существующие данные, если не позаботиться об этом явно) и в логику их обработки, описанную в модели в виде правил. Правильно написанное модель-ориентированное приложение "подхватит" эти изменения на лету и перестроит логику своей работы так, как требуется. Даже если потребуется перезапустить приложение – вмешательства в его программный код скорее всего удастся избежать. Изменения в модели можно распространять пакетами между контурами разработки, тестирования и продуктива, не трогая само приложение. Это позволяет существенно ускорить вывод в продуктив новых возможностей и сократить затраты на адаптацию приложения. |
Создание первоначальной версии приложения, управляемого со стороны модели, может потребовать чуть больше усилий аналитиков и программистов, чем разработка по традиционной схеме. Зато эксплуатация такого приложения в условиях изменяющихся требований будет гораздо более экономичной. Самое главное – она позволит быстро удовлетворять функциональные требования бизнеса, что важно для формирования конкурентных преимуществ организации.
Приведем пример из практики наших специалистов. Крупная информационная система должна обрабатывать сведения о миллионах событий, относящихся к сотням тысяч различных объектов в режиме, близком к реальному времени. Структура информации об объектах и событиях постоянно изменяется, поскольку изменяется и мир вокруг нас. Создавать такую систему на основе реляционной СУБД было бы крайне нерациональным выбором: число типов объектов и событий измеряется тысячами, а алгоритмов их обработки – сотнями. Все это подвержено быстрым изменениям. Поддержка изменения структуры данных и логики их обработки создали бы огромную нагрузку на разработчиков системы.
Было принято решение использовать онтологическую модель для описания структуры данных и логики их обработки, а данные хранить в виртуализированных хранилищах. Программный код системы решено было написать таким образом, чтобы в случае появления новых типов объектов и событий, изменений в алгоритмах их обработки он не требовал перезапуска приложения. Эта возможность пригодилась не раз, и в сумме экономия рабочего времени разработчиков многократно превысила "избыточные" затраты на первоначальное проектирование и разработку. Главное же – удалось сократить до считанных дней или недель интервал от появления функционального требования до вывода готового функционала в продуктив.
Если в вашей организации существует необходимость в разработке бизнес-приложений, работающих со сложной и изменчивой структурой данных – мы будем рады включиться в процесс проектирования, разработки и сопровождения таких приложений. Сценарий использования онтологических моделей, описанный в этой статье, демонстрирует наиболее зримые и важные для бизнеса преимущества этой технологии перед традиционными практиками разработки. Он воплощает все преимущества подхода Low Code и при этом свободен от его недостатков, т.к. разработка может происходить на любом языке программирования и не требует от программистов каких-либо специфических знаний.
