CC BY
97
Разработка модуля автоматизированной системы расчетов для визуализации текстовых данных
К.Е. Косоруков,
ДЦис 5-1
Веб-приложения за последнее время прочно вошли в онлайновый мир, постепенно вытесняя обычные компьютерные программы. В настоящий момент перед программистами насыщенных интернетприложений (RIA - Rich Internet Applications) возникает проблема создания простых, но одновременно многофункциональных веб-интерфейсов, позволяющих пользователю быстро выполнять их с помощью повседневные задачи и таким образом освоиться в системе, получая лишь положительные эмоции. Однако известно, что, чем больше вебприложение приближается к своему родоначальнику, - программе под определенную операционную систему - тем более ресурсоемкий и громоздкий код приходится писать разработчикам для придания интерфейсу стандартного вида, к которому пользователи операционных систем с оконным менеджером привыкали несколько лет, переходя таким же образом из текстового режима в графические оболочки. В свою очередь, это отрицательно сказывается на производительности как конечного решения, так и сотрудников фирмы, создавшей данный продукт. Основываясь на этом заключении, можно сказать, что направлением деятельности команды разработчиков становятся не только прямые обязанности, которыми являются разработка технического задания, стандартов кодирования и написание собственно кода для решения конкретной задачи, но и выбор оптимального средства для минимизации затрат ресурсов. Под последними понимается, например, время выполнения алгоритмов, по которым работает система, оперативная и постоянная память сервера, время проектирования и кодирования разработчиком дополнительной функциональности.
53
В данной статье рассмотрены методы разработки на одном из популярных JavaScript-фреймворков для решения этой проблемы на примере модуля биллинговой системы «Алант», созданной и развивающейся в компании «АВК-Коммьюникейшнз». Модуль позволяет визуализировать текстовые данные, которые накапливаются в базе данных за определенный срок и нуждаются в систематизации.
ExtJS - библиотека, написанная на языке JavaScript, задумывавшаяся изначально как расширение Yahoo UI Library, но со временем превратившаяся в отдельный проект. Имеет двойное лицензирование: есть возможность использовать как GPL v3, так и коммерческую лицензию компании Sencha. Основным ее направлением является создание клиент-серверных веб-приложений, похожих на desktop-приложения.
Фреймворк характеризуется наличием огромного числа компонентов, похожих на стандартные элементы управления систем с графическим оконным интерфейсом. Так, на рис. 1 показано небольшое приложение для отображения текстовых данных в виде столбчатых диаграмм с использованием компонентов «кнопка» (Button), «диаграмма» (Chart) и «окно» (Window).
При подключении библиотеки разработчик получает сразу все необходимые инструменты, чтобы быстро соорудить удобный и, что
Рис. 1. Пример приложения, сделанного на фреймворке ExtJS
54
важно, независимый от браузера пользовательский интерфейс. Присутствует оболочка для AJAX-коммуникации в виде отдельного компонента, содержащая из возможностей в том числе:
- автоматическую распаковку и упаковку данных форм в форматы XML и JSON при передаче их на сервер;
- динамическое обновление хранилищ и коллекций данных во время выполнения сценария;
- поддержку жестов для iOS-устройств;
- шаблон проектирования Model-View-Controller, с помощью которого реализуется подгрузка необходимых программе компонентов (а также параллельно поддерживается определенный порядок разработки, стандарты кодирования), отслеживание хода выполнения программы без ручных операций по установке и разбору заголовков запроса и ответа и многое другое.
За высокую функциональность разработчик платит объемом исходного кода: в последней доступной на сегодняшний день версии (4.2.1) он составляет около 500 килобайт, что заметно сказывается на скорости загрузки страницы.
Каждый компонент (например, панель с закладками) описывается JavaScript-кодом; в основе каждого компонента лежит термин «конфигурационный объект». Это стандартный объект языка JavaScript, поля которого и их значения соответствуют таковым в документации ExtJS [2]. В листинге 1 приведен фрагмент исходного кода, реализующий компонент «окно»:
Ext.create('Ext.window.Window', {
title: 'Hello',
height: 200,
width: 400,
layout: 'vbox',
items: [{
xtype: 'grid',
border: false,
columns: [{header: 'World'}],
store: Ext.create('Ext.data.ArrayStore', {})
}]
}).show();
Листинг 1. Пример компонента «окно»
Результат выполнения вышенаписанного листинга показан
на рис. 2.
55
Hello 0
World
Рис. 2. Результат выполнения листинга 1. Компонент «окно» с содержимым в виде компонента «таблица»
Функция Ext.createQ из листинга 1 является основой для создания любого компонента с помощью фреймворка ExtJS. Первым параметром в нее передается название типа объекта, который необходимо создать (в данном случае - окно), вторым - конфигурационный объект с параметрами данного компонента. Таким образом, ExtJS реализует парадигму наследования практически эмулируя классы, какие, например, существуют в C++ или в PHP. В листинге 1 создается окно с заголовком «Hello», с высотой в 200 и шириной в 400 пикселей с применением макета типа «vbox» (подробнее о нем можно прочитать в документации фреймворка [2]). В массиве items конфигурационного объекта показан еще один способ инициализации компонента, на сей раз без Ext.createQ, а только лишь самим конфигурационным объектом. Это не всегда удобно по причинам особенностей языка JavaScript, но допустимо, если компонент не будет в дальнейшем изменяться. Свойство xtype в первом элементе массива items задает название компонента через его псевдоним (в данном случае, таблица). При объявлении данного элемента интерфейса необходимо задать хранилище (store) и столбцы (columns), которые будут отображаться в таблице из всех имеющихся в нем данных. Более подробное описание конфигурации элементов можно найти в официальной документации [2].
Проблема, впоследствии решенная с применением ExtJS, возникла в одном из крупных существующих проектов, работающих на биллинговой информационной системе «Атлант». Существовавший ранее модуль визуализации текстовых данных, получаемых из базы, стал использовать нерационально большие временные ресурсы при очень маленьком задействовании физических ресурсов сервера. В результате более 80% времени при выполнении задачи сервер фактически простаивал, а СУБД (Oracle 11g) оказалась занятой настолько, что клиенты ощу-
56
щали значительные задержки при работе с системой. Так как данная функция используется часто, а клиентов даже в ночные часы не становится намного меньше, было решено оптимизировать алгоритмы работы модуля таким образом, чтобы найти компромисс между временем отклика системы и использованием ею серверных ресурсов. Математически данную проблему можно выразить графиком, показанным на рис. 3а.
Рис. 3а. Проблема нерационального использования модулем ресурсов
сервера
График p2(t) отражает желаемое течение процесса выполнения задачи, которой заведует модуль системы.
График p1(t) - фактическое.
R - максимальная нагрузка на сервер в настоящее время.
R2 - доля ресурсов сервера, которая будет задействована при выполнении задачи по желаемому сценарию.
T- время выполнения задачи после оптимизации.
Задача оптимизации сводится к нахождению алгоритма работы модуля, который удовлетворял бы следующим требованиям:
1. Время выполнения задачи Тне превышает рекомендуемое значение Tmax. Оценка верхней границы, Tmax, опирается на результаты исследований средней продолжительности пребывания пользователя на странице в ожидании ответа информационной системы [4].
2. R2 - минимально возможная доля ресурсов сервера, обеспечивающая время T, - такова, что выделение большей, чем R, доли не приводит к уменьшению затрачиваемого времени T, или же выигрыш во времени пренебрежимо мал, т. е. ск/ск ^ 0 при r> R2, где т(г) -функция зависимости времени от ресурсов (рис. 3б).
57
! I Выделенные
; ; ресурсы г, %
R, R, 100
Рис. 36. Взаимосвязь объема выделенных ресурсов сервера и времени выполнения задачи
Было предложено решение, основанное на использовании дочерних процессов модулем, которое схематически изображено на рис. 4.
Рис. 4. Предложенное решение проблемы, представленной на рис. 3а и рис. 3 б
В локальной базе данных (SQLite) создается несколько таблиц, в которые сохраняются текстовые данные для визуализации, являющиеся счетами клиентов. Таким образом, обращение к удаленной главной базе (Oracle 11g) происходит всего один раз, что освобождает ее ресурсы на большую часть времени работы модуля в отличие от прошлого решения, когда база опрашивалась с той же целью многократно на протяжении всего процесса. ER-диаграмма локальной базы данных со связями и ключами для всех необходимых сущностей представлена на рис. 5.
58
W1
(О
Рис. Б. ER-диаграмма базы данных модуля визуализации со связями и ключами
Введем некоторые понятия.
Конвертер - процесс, непосредственно осуществляющий формирование документов по счетам.
Агент - процесс, контролирующий процессы-конвертеры.
Выгрузка - основной процесс, который распределяет задания по формированию документов из текстовой информации между конкретными агентами.
Общая схема работы следующая.
1. На первом этапе работы модуль предлагает пользователю (в данном случае, администратору системы) создать новое задание. С помощью фильтра (рис. 6) необходимо задать критерии выборки данных для визуализации. После нажатия на кнопку «Найти счета» под фильтром появляется таблица, которая содержит типы визуализируемых документов и найденное по заданным критериям количество записей в главной базе.
2. Далее пользователь, проставив визуализируемые типы документов флажками, имеет возможность сохранить позиции последних, чтобы при создании следующего задания их не приходилось выбирать заново. Либо он нажимает сразу кнопку «Выгрузить N документов» и передает управление программе.
3. После нажатия на «Выгрузить N документов» управление передается модулю визуализации. Первое, что он делает, - помещает все записи, которые попадают под критерии сформированного пользовательского фильтра, в отдельную базу данных, управляемую встраиваемой СУБД SQLite.
4. Далее управление передается главному процессу выгрузки. Количество дочерних процессов-агентов, которое было задано администратором системы, создается именно на этом шаге. В базу данных, управляемую SQLite, помещается вся необходимая информация о созданных процессах, а также о самом процессе выгрузки.
5. Процессы-агенты аналогично создают дочерние процессы, которые называются процессами-конвертерами. Каждый конвертер занимается определенной порцией данных, которую получает из встраиваемой базы данных на SQLite.
6. Процесс-конвертер определяет, какому типу принадлежит документ, и на основе этого выбирает соответствующий вид конечного документа, после чего формирует файл из данных и помещает его в папку текущего задания. После завершения визуализации процесс, в случае отсутствия ошибок, благополучно завершается. Если происходит ошибка - она обязательно регистрируется в журнале событий.
7. Все три типа процессов регистрируют по ходу своей работы различные сообщения: информацию о ходе работы, ошибки, предупреждения.
60
8. После завершения каждого процесса родительский процесс (если он есть) отслеживает, не осталось ли в операционной системе «процессов-призраков». Если остались, то они завершаются принудительно, чтобы не расходовать системные ресурсы впустую.
9. При завершении очередного процесса родительский процесс, если он имеется, определяет, есть ли возможность запустить на место завершившегося новый процесс. Если есть, следует запуск. Это повторяется до тех пор, пока не кончатся все возможные незапущенные дочерние процессы для текущего родительского.
10. Подмодуль завершает свою работу, когда завершается главный процесс задания, выгрузка. Далее следует оповещение пользователя, который может создать новое задание или завершить работу с подмодулем визуализации.
Интерфейс модуля написан на ExtJS. Он состоит из нескольких страниц с панелью с вкладками, с помощью которых можно создать новое задание, отследить статус работы отдельных процессов, посмотреть общую информацию по текущему главному процессу задания, а также выполнить поиск записей в журнале, который составляется по мере работы. Пример страницы интерфейса показан на рис. 6.
Рис. 6. Страница интерфейса для создания нового задания
61
Основными элементами данной страницы являются:
1. Фильтр поиска клиентов, для которых нужно сформировать документы. Он включает в себя возможность выбора клиентов, у которых определенный юридический статус: физическое или юридическое лицо.
2. Точка выставления - внутренняя системная метка, которой может управлять администратор системы применительно к каждому клиенту. Может быть OFF-NET и ON-NET.
3. Департаменты - имеется возможность выбора всех клиентов, которые принадлежат какому-либо подразделению или фирме. Управляется аналогично администратором. Департаменты могут быть подчиненными друг другу (один департамент содержит много более мелких депараментов-филиалов), для поиска по ним необходимо проставить соответствующую галочку.
4. Отчетный период - возможность задать временной промежуток, за который необходимо сформировать документы.
5. Сумма счета - состояние счета клиента.
После нажатия на кнопку «Найти счета» формируется таблица «Документы», в которой показываются типы документов для визуализации, тип юридического статуса клиента, а также количество самих записей. При нажатии на «Сохранить по умолчанию» выбранные позиции сохраняются в удаленной базе с помощью поля в таблице типов документов. Если же администратор системы нажимает «Выгрузить», то модуль запускает сформированное из выбранных типов документов и отфильтрованных клиентов задание, передавая управление серверной стороне.
Внутреннее устройство части этой страницы (фильтр клиентов) представлено в листинге 2.
abh.massexport.task.Filter = Ext.extend(Ext.form.FormPanel, { title: 'Фильтр', height: 230, makeltems: function(){ this.defaults = { width: 200
};
this.items = [{
xtype: 'base.form.ComboBox', makeStore: function(){ this.store = new Ext.data.ArrayStore({ fields: ['code', 'name'],
data: [[0, 'Все'], [1, 'Физическое лицо'], [2, 'Юридическое
лицо']]
})
},
62
valueField: 'code', displayField: 'name', fieldLabel: 'Юридический статус', value: 0,
},
{
xtype: 'checkboxgroup', fieldLabel: 'Сумма счета', width: 400, name: 'v_summ', items: [{
boxLabel: 'положительная', name: 'v_possumm', inputValue: 1, checked: true
}
]
}];
},
initComponent: function(){ this.makeltemsQ;
abh.massexport.task.Filter.superclass.initComponent.apply (this,
arguments);
}
});
Ext.reg('abh.massexport.task.Filter',
abh.massexport.task.Filter);
Листинг 2. Фильтр клиентов в интерфейсе создания нового задания
В ExtJS инициализация компонента начинается с метода initComponent, который позволяет предварительно выполнить необходимые действия до отображения конечного результата на экране. В нем необходимо вызвать конструктор родительского компонента с помощью метода %componentName%.apply() с массивом arguments [3]. В примере выше, в этой функции объекта типа abh.massexport.task.Filter, унаследованного с помощью метода Ext.extend() от типа Ext.form.FormPanel (форма с полями), вызывается метод makeitemsQ, который создает дополнительные элементы, включенные в панель. В данном случае, это выпадающий список типа base.form.ComboBox, унаследованный от Ext.form.ComboBox точно таким же способом, как сама панель формы, но в отдельном файле, который подгружен во время
63
исполнения скрипта из листинга 2. Метод makeStore() создает хранилище, как оно создавалось в листинге 1 для элемента типа «таблица». Свойство displayField позволяет установить поле хранилища, которое будет отображаться на экране в элементе выпадающего списка для каждой записи, а свойство valueField - поле, которое будет приниматься в качестве атрибута значения для каждого пункта списка. Свойство fieldLabel задает метку с пояснением назначения поля около его контейнера, а value - начальное значение, которое уже будет выбрано.
Еще одним элементом панели формы является группа флажков (checkboxgroup). Через свойство xtype аналогично, как и для остальных компонентов, задается тип отображаемого элемента. Массив items в этой группе содержит элементы, каждый из которых является флажком. В качестве примера в листинге создается флажок с меткой «положительная сумма». На самом деле, в этот массив возможно включить любой другой элемент, но в таком случае нельзя будет предсказать поведение браузера при отображении панели с формой, так как каждый компонент в фреймворке имеет определенную область применения и проектирование нестандартных интерфейсов не приветствуется.
Таким образом, подводя итоги, об ExtJS можно сказать следующее.
1. ExtJS освобождает программиста от работ, связанны с версткой макета: весь интерфейс создается с помощью языка JavaScript и является полностью кроссбраузерным.
2. Все компоненты этого фреймворка написаны по одному принципу. Достаточно освоить несколько базовых приемов создания компонентов, чтобы делать понятные и практичные интерфейсы, не прибегая к помощи дизайнера.
3. Он отлично работает в связке с серверными языками, такими, как PHP [3], что было опробовано при практической реализации модуля автоматизированной системы расчетов.
Проблема, рассмотренная в статье, на данный момент успешно решена с помощью реализации описанных алгоритмов. Сейчас модуль эффективно функционирует в составе проекта и может быть доработан исходя из пожеланий заказчика.
Библиографический список
1. Пауэлл Т Ajax. Настольная книга программиста / Т. Пауэлл. - М. : Эксмо, 2009. - 720 c. ISBN 978-5-699-35337-8.
2. Официальная документация фреймворка ExtJS v 4.2.1: http://docs.sencha.com/ext-js/4-2.
3. Официальная документация языка PHP: http://php.net.
4. Strickland A. Beginning PHP RIA Using ExtJS. - aPress, 2012. -350 c. ISBN 978-1-430-2-3309-1.
64
