Внедрения Демо Мнения Oracle Контакты Работа

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

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

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

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 многообразие отношений интерфейсных элементов реализуется не описанием обработчиков событий, а декларативными динамическими свойствами. То есть свойства элементов интерфейса могут изменяться как при синтезе интерфейсных форм движком, так и уже в процессе их функционирования - в зависимости от входных параметров, значений контекстных элементов, параметров контента, изменяемых пользователем элементов, а также результатов запроса к прикладной системе (бизнес-логика).

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

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

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

Объекты договор{SQL:Select NVL(Max('а №'||CONTR_NO), 'ов') from CONTRACTS where ID=0{Param:CONTRID}}

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

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

{JavaScript:"{Var:RowNum}"?"Текущая строка №{Property:RowNum}, код={CODE}":"нет текущей строки"}

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

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

LUI

Приложение

  • Бизнес-логика
  • База данных
  • API

3 Выполнение прикладного кода
 

Клиентский монитор

1 Событие (клавиатура, мышь, таймер)
 

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

2 Необходимые манипуляции с элементами интерфейса и их свойствами

4 Формирование команд действий с формами и элементами форм

5 Формирование команд действий с элементами форм, свойства которых зависели от выполненных изменений

6 Применение команд изменения элементов интерфейса

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

Этапы развития 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. Хотелось бы расширить эту область применения. Поэтому, в настоящи момент активно создаётся ещё один «движок»:

Классическая трёхзвенная архитекрута (разрабатывается в настоящее время)

Браузер

Клиентский монитор

Сервер приложений

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

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

Приложение

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

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

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

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

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

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

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

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

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

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

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

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

Поставка

Продукт свободно доступен на сайте в виде файлов и архивов:

Скачать: Архив LUI + JDK + Tomcat (330 Мб)

Скачать архив:
Только LUI (23 Мб)

  • Руководство по установке и настройке интерфейса.doc
  • execute_from_sys.sql
  • Data.sql
  • lui.war
  • luiconfig.xml
  • Основы universalInterface.docx

Java Development Kit

Среда, необходимая для обеспечения работы Сервера приложений.
  • Самую свежую версию JDK можно скачать с сайта Oracle по ссылке. Далее, в разделе Java SE XuXXX (это номер последней версии JDK) выбрать «JDK Download». После перехода нажать «Accept License Agreement» и выбрать версию JDK для вашей операционной системы.
  • Скачать JDK 7u80: для Windows'32
  • Скачать JDK 7u80: для Windows'64

Apache Tomcat

Сервер приложений
  • Самую свежую версию Tomcat можно скачать с сайта по ссылке. Далее, в разделе «Download» (в левой части страницы), выберите ссылку «Tomcat 8», а затем выберите дистрибутив, соответствующий вашей операционной системе.
  • Скачать Tomcat 7.0.79: для Windows'32
  • Скачать Tomcat 7.0.79: для Windows'64

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

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

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

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

© ФОРС – Центр разработки. Все права защищены