Здравствуй, уважаемый Хабр!

Эта статья описывает объектно-ориентированный (или онтологический) Low-code подход к проектированию и разработке информационных систем на примере платформы «Системный Геном».

Рассматриваемый подход, на наш взгляд, позволит кратно сокращать трудозатраты и сроки разработки сложных корпоративных и государственных информационных систем.

Введение

В ходе известных событий, российский технологический ландшафт начал стремительно меняться. Уход иностранных вендоров (прежде всего, SAP и Oracle) оставил крупные организации на грани реализации значительных рисков.

Наиболее пугающий из них – возможность полной остановки производства в случае раскрытия критических уязвимостей используемых версий иностранного ПО. Рано или поздно эти уязвимости найдутся.

Неизбежно прогрессирующее отставание цифровых процессов от положения дел «на земле» из-за отсутствия постоянной поддержки и обновлений. Обкладывание SAP костылями – удовольствие дорогое и бесперспективное.

В этой сложной среде потребность в надежном, автономном и масштабируемом программном решении как никогда актуальна. В эту эпоху перемен мы предлагаем рассмотреть онтологический low-code подход для решения обозначенных рисков.

Онтологии – что это такое и зачем оно нужно?

В заголовке этой статьи многие могли обнаружить новое для себя слово, поэтому давайте для начала обратимся к википедии. Все начиналось с древнегреческой философии:

Онтоло́гия – учение о сущем; учение о бытии как таковом; раздел философии, изучающий фундаментальные принципы бытия, его наиболее общие сущности и категории, структуру и закономерности.

Позже этот термин стал применяться в информатике:

Онтоло́гия – попытка всеобъемлющей и подробной формализации некоторой области знаний с помощью концептуальной схемы.

Современные онтологии строятся по большей части одинаково, независимо от языка написания. Обычно они состоят из понятий (или классов), экземпляров (или объектов), атрибутов (или свойств) и отношений (или связей). С помощью этих четырех типов элементов формируются концептуальные схемы, предназначенные для моделирования предметных областей и процессов.

Онтологии в Системном Геноме

Концептуальные схемы, визуализирующие онтологии, могут выглядеть и применяться по-разному. Мы используем онтологический граф не только для моделирования предметных областей и процессов, но и непосредственно для их автоматизации. Как это работает?

Все начинается с создания проекта. В рамках экземпляра платформы проект представляет собой отдельную БД (либо кластер), и, как правило, приравнивается к организации. При необходимости масштабирования, крупная организация может быть представлена в нескольких проектах.

Проекты содержат приложения. Приложение соответствует функциональному модулю и представлено в виде отдельных бэкенда и фронтенда на веб-сервере. При необходимости масштабирования, веб-сервер может быть заведен за балансировщик и размножен. Приложения также могут быть спроектированы как микросервисы.

Дочерние узлы приложений могут быть трех типов – класс, объект, и ссылка. Все они являются потомками так называемых базовых классов. Часть базовых классов предназначена для моделирования предметных областей и процессов, другая часть применяется для создания информационных систем, оперирующих этими моделями.

Аналитики и архитекторы составляют конфигурации конечных приложений путем использования экземпляров базовых классов, и их связывания друг с другом.

Базовые классы – строительные блоки платформы

Состав базовых классов будет расширяться по мере развития системы, на сейчас он содержит примерно следующий набор элементов:

●     Контейнер. Служит для упорядочивания деревьев приложений.

●     Классы для описания БД – таблица, поля, ключи, индексы, триггеры, функции.

●     Классы для описания бэкенда – бизнес-объект (или просто класс), свойства бизнес-объектов, связи бизнес-объектов (1-1, N-1, N-N), CRUD-API (набор методов для работы с одним бизнес-объектом), GetAllAPI, произвольная API.

●     На уровне фронтенда – страница, портлет, стор, компоненты пользовательского интерфейса, обработчик (инструмент для сопоставления запросов и ответов API с компонентами пользовательского интерфейса и стором), произвольный JS-метод.

Потомки всех этих базовых классов образуют друг с другом сложные связи с помощью вложенности, наследования и ссылок. Итоговые конфигурации деревьев содержат как модели предметных областей, так и описания информационных систем для работы с ними.

В рамках визуального программирования на нашей платформе реализуется 70-80% функциональности конечных систем, оставшиеся 20-30% сложной логики и вычислений дописываются традиционными способами в гите поверх кода, сгенерированного из визуальных моделей.

Процесс работы в платформе Системный Геном

Основные пользователи нашей платформы – системные аналитики и архитекторы. Обе эти роли предполагают как владение предметными областями, так и понимание способов их автоматизации. Они принимают участие практически на всех этапах процесса разработки, от первичного интервьюирования, до передачи в сопровождение. И аналитики, и архитекторы в ходе разработки тратят большую часть своего времени на получение, формализацию и передачу знаний остальным участникам разработки.

Применение нашей платформы позволит минимизировать трудозатраты на коммуникации за счет того, что аналитики и архитекторы, получив на вход требования, могут самостоятельно реализовать большую их часть с помощью визуального программирования, оставив за программистами дополнение кодом тел сложных методов.

●     На первом этапе разработки аналитик собирает «каркасы» приложений, которые включают в себя полноценное описания предметной области на уровне базы и бэкенда, интерфейс пользователя, CRUD и GetAll операции, и объявления (перечень входящих и исходящих параметров) более сложных методов на любом из уровней стека.

●     Далее архитектор проводит ревью каркаса, и если его все устраивает, они совместно с аналитиком дополняют объявления методов комментариями с описанием логики и вычислений. Собранный каркас автоматически преобразуется в исходные коды на 3 уровнях стека, которые проверяются на валидность и кладутся в гит.

●     Разработчики дополняют исходники телами сложных методов.

●     Готовые исходники публикуются в виде приложений на отладочном стенде, где производится их проверка тестировщиками.

●     Проверенные приложения публикуются в продуктивном контуре.

Текущее состояние и планы

На сегодняшний день готов MVP платформы “Системный Геном”, который позволяет:

●     Моделировать предметные области и процессы на уровне моделей данных БД и бэкенда.

●     Создавать CRUD и GetAll API, оперирующие с одним бизнес-объектом, без написания кода.

●     Создавать объявления произвольных API, включающих набор входящих и исходящих атрибутов.

●     Верстать веб-страницы, содержащие компоненты пользовательского интерфейса.

●     Связывать компоненты пользовательского интерфейса с объектами и переменными в сторе страниц и приложений.

●     Создавать обработчики, использующие данные из стора для вызова API, и раскладывания данных из ответов обратно в стор, без кода.

●     Создавать объявления произвольных JS-методов, включающих набор входящих и исходящих атрибутов.

●     Дополнять тела произвольных SQL, C#, JS -методов кодом.

●     Публиковать собранные решения.

Совокупность представленных возможностей позволяет создавать конечные решения различного класса. Спектр доступных решений пока ограничен относительно узким набором компонент пользовательского интерфейса, но это ограничение временное.

По нашим оценкам, для того чтобы MVP превратился в полноценную версию 1.0, не хватает следующих элементов платформы:

●     Система контроля доступа. В предыдущей статье я описывал дизайн СКД, но в итоге мы пришли к более простому решению. Расскажу о нем в одной из следующих статей.

●     Набор инструментов для реализации стратегии “лоскутного покрытия” (API-коннектор, коннекторы к СУБД, экспорт/импорт файлов).

●     Набор сложных компонентов пользовательского интерфейса (диаграмма Ганта, доски с плашками, графики, картография, и т.д.).

Среда визуального программирования Системного Генома

Cреда визуального программирования является основным элементом нашей платформы. Эта среда упрощает сложные задачи программирования до удобных для пользователя визуальных операций, делая разработку ERP-решений доступной для системных аналитиков.

Продемонстрируем создание простейшего Web-приложения для регистрации накладных с единственным справочником товаров. Начнём проектирование приложения с создания бизнес-объектов и таблиц, затем сгенерируем API и создадим интерфейс приложения (страницы). Создаём узел (тип узла – «бизнес-объект») «Товар»:

Создание осуществляется простым перетаскиванием нужных узлов из панели базовых классов (2) в узел дерева приложения (1). Содержимое панели контекстно-зависимо (адаптируется к выбранному узлу дерева и его типу), что видно на следующем скриншоте (содержимое панели для узла типа «таблица»).

Создали бизнес-объект, указали его поля и их настройки (например, «Проверка на уникальность» позже трансформируется в unique constraint в таблице БД). Далее создаём узел (тип узла – таблица) «Товары» (1) и привязываем его (ссылаемся на него) к ранее созданному бизнес-объекту «Товар» (2). Для автоматической генерации структуры таблицы воспользуемся пунктом «Синхронизировать с таблицей» в контекстном меню (3):

Аналогичным образом создаём таблицы и бизнес-объекты «Накладная регистрация» (для «шапки» накладной) и «Накладная спецификация» (для списка товаров накладной) и привязываем бизнес-объекты к таблицам.

В бизнес-объекте «Накладная спецификация» добавляем узел «Связь многие к одному» и связываем его с бизнес-объектом «Накладная регистрация» (1); аналогично добавляем узел «Связь один к одному» и связываем его с бизнес-объектом «Товар» (2).

Обратите внимание, что после синхронизации бизнес-объектов с таблицами поля связи между таблицами (и Foreign Key Constraints в БД) создадутся и привяжутся автоматически – на скриншоте выше узлы (3) и (4) указывают соответственно на поля таблицы «Накладные спецификация», а узлы (5) и (6) связывают её соответственно с таблицами «Накладные регистрация» и «Товар»:

На этом проектирование бизнес-объектов и таблиц можно пока считать завершённым и перейти к проектированию API и созданию интерфейса.

Начнём с бизнес-объекта «Товар» и сгенерируем для него REST API – для этого воспользуемся компонентом «API Генератор», «привяжем» его к бизнес-объекту и с помощью контекстного меню сначала сформируем CRUD API (onPUT удалим за ненадобностью), а затем GetAll:

В результате получили типизированный API-интерфейс с уже заполненными входящими и исходящими параметрами и шаблонным телом методов (1), параметры и код (2) которых можно изменить вручную при необходимости:

Аналогично генерируем (или создаём вручную) API для бизнес-объектов «Накладная регистрация» и «Накладная спецификация». Наконец, можно переходить к проектированию интерфейса и обработчиков.

Создаём страницу (1) и добавляем в неё компоненты (кнопки, поля ввода, таблицу и её колонки и т.д.), для удобства можно воспользоваться визуальным редактором (2). Обратите внимание на автоматически созданные и привязанные (можно изменить вручную) переменные стора для колонок таблицы и других компонентов – (3) и (4):

После этого добавляем узел «Обработчик» (1), указываем ему метод API (2) и выбираем «Синхронизировать с API» (3) в контекстном меню:

В результате чего будет сформирован список параметров и можно будет связать их с переменными стора (например, с ранее созданными переменными стора страницы):

После чего добавляем в страницу событие OnLoad (1) и привязываем к нему наш обработчик (2):

Повторяем шаги с обработчиками для методов onPOST (1) и onDELETE (2) – обратите внимание на привязку входящего параметра обработчика к идентификатору выделенной строки таблицы (3):

И привязываем их к методам «Кликнули» кнопки «Создать» (1) и кнопки колонки «Удалить» (2) соответственно. В событие «Отработало» (3) вызываем уже знакомый нам обработчик «Получить все товары» для рефреша данных таблицы:

И – вуаля! После генерации и публикации приложения страница «Товары» уже будет работать – данные будут корректно отображаться, создаваться и удаляться:

Аналогичным образом генерируем и создаём API, обработчики и страницы для бизнес-объектов «Накладная регистрация» и «Накладная спецификация»:

Страница накладных с двумя входящими и одной исходящей накладной:

Страница спецификации накладной:

Таким образом, простейшей каталог товаров, регистрация накладных и их спецификаций, уже корректно отображаются и работают.

Попробуем сделать что-то чуть более сложное – например, подсчитать баланс (количество товаров на складе с учётом прихода-расхода по трём накладным). Для удобства подсчёта баланса создаём фиктивный бизнес-объект (1) и обработчик для него (2), код которого придётся, увы, писать вручную (3):

Создаём простейшую страницу с таблицей на 2 колонки, вызываем обработчик в OnLoad и указываем переменные для колонок таблицы:

Генерируем, публикуем приложение и проверяем результат:

Заключение

Уход иностранных вендоров создает проблемы в российских организациях, но в то же время, открывает возможности для роста и самообеспечения нашего технологического сектора. Данный обзор предназначен для начала обсуждения путей развития корпоративного ИТ-сектора, и применении онтологического low-code подхода в рамках суверенизации отечественного ИТ-ландшафта.