Новое средство коллективной разработки интерфейсов прикладных систем

Нами разработан оригинальный программный продукт – среда для создания интерфейса (экранных форм) к уже существующим или вновь разрабатываемым прикладным системам (Live Universal Interface, LUI). В чем же особенность нового средства?

Несмотря на большое разнообразие инструментов, при производстве ПО очень часто приходится сталкиваться с ситуацией, когда задача создания пользовательского интерфейса оказывается более ресурсоёмкой, чем задача реализации прикладной бизнес-логики. Проект начинает «теряться» в экранных формах. Как правило, это связано с тем, что даже при наличии достаточно совершенных инструментов программист вынужден самостоятельно строить алгоритмы для обработки событий при вводе и отображении данных. Он должен управлять отображением информации на экране посредством элементарных команд в тесной взаимной связи с бизнес-логикой приложения. При этом нести полную ответственность за конечный результат!

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

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

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

Имеющийся в компании «Форс» опыт практического использования LUI при разработке программного обеспечения позволяет судить о реальной эффективности применения данного инструмента и утверждать, что он обеспечивает следующие

Преимущества LUI

• LUI позволяет значительно снижать уровень затрат на разработку экранных интерфейсов приложений (в некоторых проектах достигнуто 3-х кратное уменьшение времени разработки по сравнению с ранее использовавшимся Фреймворком на основе Apache Wicket);
• LUI позволяет быстро прототипировать автоматизированные системы, сосредоточившись на первоочередной задаче автоматизации бизнес-процессов;
• Приложения, написанные с применением LUI можно эффективно развивать и модифицировать - любые изменения в экранном интерфейсе вносятся прямо в работающую систему без её остановки, а связанные с ними этапы подготовки локальных модификаций, верификации изменений, компиляции и сборки больше не потребуются;
• LUI обеспечивает дополнительные потребительские качества разрабатываемого программного продукта, например, сочетание свойств, присущих традиционному "тонкому" клиенту с "длинными" транзакциями и широкими возможностями поиска информации (QBE - Query by Example);
• Применение LUI позволяет рассчитывать на длительный период жизни приложения, поскольку замена средства отображения интерфейса на более современное не потребует изменения интерфейсных форм и уж тем более не затронет логику прикладной системы.

LUI позволяет быстро реализовывать учётные, финансовые, расчётные системы для любых отраслей. Возможности инструментария по праву оценят коллективы разработчиков рынков B2B, B2G, G2B, G2C и, в некоторых случаях, даже B2C. Инструмент может оказаться чрезвычайно полезен для решения IT-задач в бизнес-консалтинге и в иных случаях, когда необходимо быстро и с минимальными затратами предоставить прототип (опытный образец) автоматизированной системы.

Основные особенности LUI

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

Базовые концепции LUI

Здесь перечислены принципы, которыми руководствовались разработчики LUI при его проектировании и реализации.

• Алгоритмы изменений интерфейсных элементов в процессе работы форм описываются декларациями её динамических свойств, а не процедурами обработки событий в формах. «Движок» обеспечивает адекватность отображения текущих значений свойств каждого элемента и формы в целом на протяжении всей жизни формы.
• Набор свойств элемента фиксирован и согласован. То есть, нет таких свойств элементов, значения которых могут противоречить друг другу или быть несовместимыми.
• Элементы и их свойства достаточно абстрактны, чтобы не попадать в зависимость от конкретной реализации интерфейсного «движка». То есть, свойства оперируют понятиями, а не физическими устройствами.
• Программы на языке, обеспечивающем декларации динамических фрагментов, не порождают необработанных исключений. В любой момент времени вычисление динамического фрагмента возвращает какое-то значение без отображения ошибок.
• Динамические фрагменты вычисляются только при необходимости и только непосредственно в момент их востребованности.
• При обработке клиентского события единожды вычисленный динамический фрагмент не перевычисляется при повторных использованиях в различных свойствах, если динамические фрагменты текстуально эквивалентны.
• «Движок» при реакции на событие передаёт клиентскому монитору команды по изменению интерфейсных элементов, минимизируя трафик - то есть, отправляются только новые или реально изменившиеся свойства форм.

Абстрагирование свойств

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

Пример: чтобы визуально выделить элемент среди других элементов интерфейса разработчик прикладной системы не должен оперировать такими свойствами, как шрифт (вдруг «движок» алфавитно-цифровой?), цвет (вдруг «движок» монохромный?), фон и т.п. Он оперирует ролями, о которых условлено с разработчиком «движка», такими как "Внимание", "Опасность", "Незаметный" и т.п. А уже разработчик конкретного движка, ориентируясь на поставленные цели и исходя из предоставленного ему инструментария, интерпретирует эти роли. При существенных расхождениях во мнении об интерфейсных реализациях свойств элементов интерфейса разработчик «движка» реализует средства кастомизации (настройки) под конкретного Заказчика или даже Пользователя.

Таким образом, разработка прикладной системы окажется полностью отделённой от средства (среды и языка) разработки «движка» или нескольких «движков», которыми осуществляется и будет осуществляться в будущем визуализация труда программиста прикладной системы.

Отказ от обработки событий

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

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

Динамические свойства

Значение свойства может быть константой (надпись на кнопке, признак активности элемента, тип данных ячейки и т.п.). В этом случае свойство определено ещё до начала работы формы и не меняется до закрытия формы. Однако внутри (или вместо) значения формы можно использовать текстовые конструкции, заключённые в фигурные скобки, которые называются Динамическим фрагментом. Их наличие - указание интерпретатору, что в момент применения значения свойства содержание фигурных скобок будет проинтерпретировано, вычислено и заменено (включая и сами скобки) на результат вычисления.

Пример динамического свойства - заголовка таблички с объектами договора:

Это свойство содержит динамический фрагмент в виде запроса к базе данных, опирающийся на входной параметр CONTRID. Ноль перед параметром страхует от пустого значения параметра CONTRID. Так как вся динамика в этом примере опирается только на входной параметр, то считаться она будет один раз за всё время жизни формы - при загрузке.

Другой пример - динамическое свойство Заголовок, выполненное на процедурном языке JavaScript, который тут используется как декларативный:

Этот динамический фрагмент опирается на меняющееся свойство формы - RowNum - номер текущей строки списка, а также на значение ячейки CODE текущей строки. В какой момент нужно перевычислять динамическое значение решает «движок». Он знает когда у него меняется номер строки или значение ячейки CODE. Программисту писать обработчики событий, чтобы перевычислить и заменить свойство Заголовок, уже не надо!

Схема взаимодействия частей универсального интерфейса

LUI			Приложение Бизнес-логика База данных API → 3 Выполнение прикладного кода
Клиентский монитор 1 Событие (клавиатура, мышь, таймер)	Сервер интерфейса → 2 Необходимые манипуляции с элементами интерфейса и их свойствами ← 4 Формирование команд действий с формами и элементами форм ↓ 5 Формирование команд действий с элементами форм, свойства которых зависели от выполненных изменений
← 6 Применение команд изменения элементов интерфейса

1. На клиентском устройстве, где отображаются интерфейсные формочки, возникает событие, требующее реакции сервера интерфейса. Это такое событие, которое теоретически может повлечь перевычисление зависимых динамических свойств каких-то элементов интерфейса. Конечно, первопричиной возникновения события являются некий клик мышкой, нажатие клавиши на клавиатуре и т.п., но Клиентский монитор транслирует в Сервер интерфейса уже более осмысленные события с их параметрами: перемещение курсора в другое поле/строку/ячейку, нажатие на кнопку, изменение значения поля, выбор пункта меню и т.п.
2. Сервер интерфейса имеет обработчик каждого типа события, поступившего с Клиентского монитора. Он производит необходимые манипуляции с формами, элементами и их значениями. Если в процессе используются свойства элементов, то вычисляются их динамические значения.
3. Выполнение прикладной бизнес-логики посредством вызова процедур приложения - напрямую или через API или даже прямое манипулирование данными.
4. Формирования команд в терминах Клиентского монитора, которые производят необходимые визуальные изменения на клиентском устройстве. При использовании свойств элементов интерфейса вычисляются их динамические значения.
5. Определение иных свойств элементов интерфейса, которые могли бы измениться в результате обработки события. Формирования команд для отправки в Клиентский монитор, которые применят изменившиеся свойства.
6. Клиентский монитор преобразует абстрактные команды Сервера интерфейса в реальные изменения на экране у клиента.

Инфраструктура проекта

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

Ниже перечислены элементы инфраструктуры проекта, необязательные для использования в каждом Проекте.

• Пользователи системы: Регистрация пользователя администратором; Смена пароля администратором, пользователем по желанию, принудительно при первом входе, и/или принудительно с некоторой регулярностью; Временная деактивация (блокировка) пользователя.
• Разграничение доступа: Пополняемый справочник типов объектов прав, в отношении которых будет проводится разграничение доступа; Указание видов возможных прав (просмотр, изменение, выполнение и т.п.) для каждого типа объектов прав; Ведение групп пользователей, задание для каждой группы программного кода, выполняющегося при добавлении пользователя в группу и при исключении его из группы; Назначение явных прав группам пользователей на различные объекты прав; Просмотр эффективных прав пользователей, определение - от чего они зависят.
• Аудит: Пополняемый справочник типов записей аудита; Аудит подключений/отключений пользователя от Приложения; Аудит выполнения пользователем внутреннего функционала Приложения; Аудит изменения данных (добавление, модификация, удаление строк) таблиц базы данных.
• Поддержка многоязычности: Пополняемый справочник языков, указание родственных языков; Указание текущего языка для всех, для некоторых пользователей, и/или для некоторых режимов работы Приложения; Переключение языков пользователем в процессе работы в Приложением; Возможность ввода текстового значения поля для каждого определённого языка.
• Алфавиты: Пополняемый справочник правил контроля корректности ввода и автомодификации текстов;
• Сообщения: Пополняемый справочник многоязычных текстов ошибок, сообщений и предупреждений. Сообщения могут явно активироваться из программного кода с передачей параметров. Сообщения в виде ошибок могут быть привязаны к ограничениям (constraint) СУБД или exception процедурного языка и активироваться автоматически.
• Параметры: Именованные значения, которые классифицируются по

  a). Способу сохранения:

  • Реальный параметр. Это параметр, имеющий значение по умолчанию и сохраняющий установленное значение для других сеансов работы системы (пополняемый справочник параметров).
  • Виртуальный параметр. Значение такого параметра устанавливается и живёт только в процессе текущего сеанса работы приложения.

  б). Способу изменения:

  • Только для чтения. Будучи установленным в некоторое значение, такой параметр не может быть изменён приложением.
  • Изменяемый параметр. Даже если такой параметр глобальный, в процессе функционирования он может поменять своё значение, но правда только до окончания текущего сеанса.

  в). Месту применения:

  • Глобальный параметр. Имеет одно значение, одинаковое для вего приложения. Изменения значения влияет на все точки применения этого параметра.
  • Локальный параметр. Такой параметр имеет разные значения, в зависимости от тех или иных обстоятельств. Например, значение может быть индивидуально для каждого Пользователя приложения.

  г). Способу задания начального значения:

  • Статический параметр. Имеет конкретное значение-константу, заданное по умолчанию или в процессе работы приложения.
  • Динамический параметр. Это декларативно заданный алгоритм получения значения, который вычисляет значение в момент первого обращения к параметру. Этот алгоритм может опираться на значения других статических и динамических, реальных и виртуальных, локальных и глобальных, изменяемых и не изменяемых параметров.
• Специальные даты: Интерфейс имеет календарь для выбора значения полей типа Дата/Время. В календаре по умолчанию имеет 2 типа дней - рабочие и выходные. Пользователь может внести корректировки, заменив тип любого дня года на праздничный, выходной или рабочий. Набор возможных типов дней может быть расширен. Эти изменения становятся видны в календаре. Впоследствии определение типа календарного дня может использовать логика приложения.

Поставка

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

• Поставка промышленной версии LUI для linux-based систем
• Оказание услуг технической поддержки
• Миграция существующих приложений на LUI
• Обучение LUI
• Доработка и настройка LUI под Ваши требования

Для получения этих услуг пишите по адресу lui@fors.ru, или звоните по телефону: +7 495 913-7575

LUI для PostgreSQL

Особенности данной версии:

• Метаданные форм хранятся в СУБД PostgreSQL
• Поддерживаются несколько соединений с разными СУБД
• Поддерживаются соединения с СУБД PostgreSQL и Oracle
• Декларативные языки - SQL, JavaScript, PL/pgSQL
• Процедурные языки - PL/pgSQL, JavaScript

Файл	Описание	Действие
LUI_Install_2.0.3.exe	Программа установки LUI для PostgreSQL под Windows 7+	Скачать
LUI_Setup4PostgreSQL.pdf	Инструкция по инсталляции LUI для PostgreSQL	Скачать
LUI_GettingStarted.pdf	Первые шаги по настройке LUI (создание Приложения и т.п.)	Скачать
LUI_Concepts.pdf	Описание и концепции LUI для PostgreSQL	Скачать
LUI_Styles_Editor.pdf	Редактор стилей LUI	Скачать

Файл	Описание
http://lui.fors.ru/LUI_Install_2.0.3.exe	Программа установки LUI для PostgreSQL под Windows 7+
http://lui.fors.ru/LUI_Setup4PostgreSQL.pdf	Инструкция по инсталляции LUI для PostgreSQL
http://lui.fors.ru/LUI_GettingStarted.pdf	Первые шаги по настройке LUI (создание Приложения и т.п.)
http://lui.fors.ru/LUI_Concepts.pdf	Описание и концепции LUI для PostgreSQL
http://lui.fors.ru/LUI_Styles_Editor.pdf	Редактор стилей LUI

LUI для Oracle

Особенности данной версии:

• Метаданные форм хранятся в СУБД Oracle
• Поддерживается одно соединение и только с СУБД Oracle
• Декларативный язык - Oracle SQL, Oracle PL/SQL
• Процедурный язык - Oracle PL/SQL

Файл	Описание	Действие
LUI_Oracle.rar	Дистрибутив установки LUI для Oracle	Скачать
LUI_Setup4Oracle.pdf	Инструкция по инсталляции LUI для Oracle	Скачать
UI_Concepts.pdf	Описание и концепции LUI для Oracle	Скачать

Файл	Описание
http://lui.fors.ru/LUI_Oracle.rar	Дистрибутив установки LUI для Oracle
http://lui.fors.ru/LUI_Setup4Oracle.pdf	Инструкция по инсталляции LUI для Oracle
http://lui.fors.ru/UI_Concepts.pdf	Описание и концепции LUI для Oracle

Если вам требуются дистрибутивы для других операционных систем, просим обращаться с этим запросом по адресу E-mail: lui@fors.ru

Демонстрация форм, работающих на LUI

Нажав на одну из кнопок справа, вы запустите демонстрационную форму.
В этих формах можно:

• Навигироваться по пунктам, строкам, ячейкам и полям - мышью или клавиатурой;
• В Списках переходить в режим многострочного выделения - кликая мышью с нажатым CTRL на нужные строки списка;
• Вызывать локальное меню действий в формах, применимых к объекту, где был сделан клик правой кнопкой мыши - к ячейке, полю, строке, пункту, заголовку или всей форме;
• Вызывать локальное меню действий со столбцами списков - кликая на заголовке столбца левой кнопкой мыши;
• Перемещать мышью границы окон, столбцов и внутренних областей;
• В Списках переходить в режим QBE (Query by Example) - клавишей F7; Применять введённые условия QBE - клавишей F8;
• Принудительно обновлять данные в списке - клавишей F8;
• Выполнять действия - нажимая кнопки в формах, на ToolBar списков, в полях и ячейках форм.

Обращаем внимание, что в демонстрационном режиме все изменения в базе, сделанные при помощи форм LUI, не сохраняются!

Этапы развития LUI

Изначально LUI развивался, как интерфейс продукта компании «Форс» - Тиражируемой Автоматизированной Системе Расчётов (Билинг) для предприятий связи - АСР «Fastcom». Поскольку Fastcom использовал Oracle Forms для взаимодействия с пользователем, логично, что первый «движок» LUI был реализован именно на этом продукте.

Реализация на Oracle Forms (использовалась с 2002 по 2016 гг.)

Oracle Forms Клиентский монитор Сервер интерфейса Рабочие области форм

⇔

Oracle Server Интерпретатор SQL, PL/SQL Приложение

Со временем стало понятно, что Forms перестал развиваться корпорацией Oracle как продукт. Последняя версия Oracle Forms в техническом плане не удовлетворяет потребностям LUI. Было принято решение создавать новый «движок», на более современной и продвинутой платформе. Начиная с 2008 года он начал разрабатываться, а с 2009 года - использоваться в АСР Fastcom. Два «движка» функционировали одновременно. Совсем отказаться от реализации «движка» под Oracle Forms не позволяло то обстоятельство, что в АСР Fastcom всё ещё имелись формы, разработанные непосредственно на Oracle Forms, которые легко вызывались из «движка» LUI на Oracle Forms и наоборот.

Реализация на JavaScript + Ajax (использовалась с 2009 по 2014 гг.)

Интернет-браузер Клиентский монитор Сервер интерфейса

⇔

Oracle Server Рабочие области форм Интерпретатор SQL, PL/SQL Приложение

Однако и этот «движок» не устроил по ряду параметров. В частности, по быстродействию. И потому, начиная с 2013 года начал разрабатываться ещё один браузерный «движок», легко масштабируемый по производительности и, таким образом, выдерживающий нагрузку в десятки тысяч пользователей, работающих одновременно. Новый вариант заменил предыдущую реализация в 2015 году и этот переход был практически незаметен как для конечных пользователей, так и для разработчиков бизнес-логики Приложения.

Реализация на Java (используется с 2015 по настоящее время)

Браузер Клиентский монитор

⇔

Tomcat Сервер интерфейса

⇔

Oracle Server Рабочие области форм Интерпретатор SQL, PL/SQL Приложение

Это очень хорошо отлаженный «движок», удовлетворяющий всем требованиям обслуживаемых им Приложений. Но область применения его - приложения, написанные на СУБД Oracle. Хотелось бы расширить эту область применения. Поэтому, в настоящий момент доступен ещё один «движок» - с гибко подключаемыми языковыми модулями и модулями доступа к БД:

Классическая трёхзвенная архитектура (используется с 2019 года)

Браузер Клиентский монитор

⇔

Сервер приложений Сервер интерфейса Рабочие области форм Расширяемый интерпретатор

⇔

Сервер Приложения Приложение

Здесь декларативные и процедурные языки подключаются как внешние модули. Таким образом, динамические структуры могут описываться языками SQL, PL/pgSQL, JavaScript, Java, Perl и т.п., а также их комбинациями!

Новая реализация обеспечивает приложению возможность поддерживать одновременно несколько соединений к одной или разным Базам данных, в том числе, СУБД различных типов! (Oracle, Postgres, MySQL, MSSQL Server и др.) К примеру, в формах типа «Мастер-Деталь» мастер список будет извлекать данные из одной БД, а детальные записи будут извлекаться из другой.
Этот принцип позволит:

• Интегрировать между собой системы с различными СУБД, не используя трудно отлаживаемые и ненадёжные гетерогенные db-link’и;
• Плавно, частями, безболезненно мигрировать прикладную систему из одной СУБД в другую.

Другая фундаментальная возможность этой реализации: работа как в режиме «длинных транзакций», так и в режиме «коротких транзакций»:

1. «Короткая транзакция» начинается и заканчивается в процессе обработки одного интерфейсного события, что очень хорошо подходит для систем массового назначения - для условно бесконечного числа пользователей;
2. «Длинная транзакция» поддерживается в промежутке между событиями, что даёт управление блокировками на уровне БД, целостность чтения данных и откатов к началу транзакции. Этот режим очень подходит для внутрикорпоративных систем с критической ответственностью за целостность и корректность данных;
3. Комбинированный вариант, когда одни соединения с СУБД работают в режиме «коротких транзакций», а другие - в режиме «длинных транзакций».