CC BY
20
УДК 65.011.56:65.03
Т. А. Воронин, Г. Г. Арунянц
ОСОБЕННОСТИ ПОСТРОЕНИЯ ПРОГРАММНОГО КОМПЛЕКСА РТ-Q-l АВТОМАТИЗИРОВАННОГО ФОРМИРОВАНИЯ ТАРИФОВ ДЛЯ РЕГИОНАЛЬНОЙ СИСТЕМЫ ТЕПЛОСНАБЖЕНИЯ
Приведены результаты создания универсального программного комплекса РТ-Q-l автоматизированного формирования и анализа тарифов в сфере теплоснабжения, анализа и выбора среды ее разработки. Обоснована целесообразность применения модели SaaS, обеспечивающей наиболее простой обмен данными в охватываемом информационном поле и позволяющей существенно снизить стоимость внедрения и эксплуатации разрабатываемого программного обеспечения. Приведены особенности структурной организации, информационного и программного обеспечения программного комплекса РТ-Q-l.
The article presents the results of the universal program complex PT-Q-1 for the automated setting and the analysis of tariffs in district heating system. The authors study the feasibility of the SaaS model application which provides for the simplest data interchange in the relevant information space and allows reducing significantly the software implementation cost and maintenance. The structural organization, information and the software of the program PT-Q-l complex features are given.
Ключевые слова: тариф, алгоритм, структура, информационное обеспечение, программное обеспечение, программный комплекс, графический интерфейс, кросс-платформенное приложение, пользовательский интерфейс.
Keywords: rate, algorithm, structure, information support, software, program complex, graphic interface, cross-platform application, user interface.
63
Введение
Региональная система теплоснабжения, включающая предприятия (ТЭЦ, котельные и др.), производящие тепловую энергию, и организации, занимающиеся ее передачей и распределением, является важной составляющей экономики региона. Сегодня к таким системам предъявляются повышенные требования к их управляемости, доступности и надежности. Решение проблем обоснования всех производимых затрат на производство и оказание услуг представляются полезными при модификации затратного механизма формирования и анализа тарифов и дифференцированного тарифного регулирования. В условиях сложной структурной организации системы энергоснабжения региона и обоснованной необходимости пересмотра тарифа не менее 4 раз в год [1], эффективное решение таких задач становится возможным только с использованием автоматизированных информационных систем (АИС), реализующих специально разрабатываемые для этих целей алгоритмы
© Воронин Т. А., Арунянц Г. Г., 2018
Вестник Балтийского федерального университета им. И. Канта. Сер.: Физико-математические и технические науки. 2018. № 1. С. 63 - 73.
и системы эффективного информационного обмена в рамках общего поля «региональная служба по государственному регулированию цен и тарифов (СГРЦТ) — субъекты регулирования».
Проведенные авторами исследования принципов и подходов к автоматизации указанных процессов позволили поставить и решить задачу разработки универсального комплекса РТ-Q-l автоматизированного формирования и анализа тарифов в сфере теплоснабжения регионов [2].
1. Разработка программного комплекса РТ-Q-l
64 Для реализации концепции максимально простого обмена данны-
ми в указанном информационном поле с целью установления единых правил для всех субъектов регулирования было принято решение свести к минимуму сложности, связанные с установкой и эксплуатацией разрабатываемого программного комплекса, как субъектами регулирования, так и СГРЦТ [1].
При выборе среды разработки было принято решение о разработке программного комплекса РТ-Q-l с применением «облачных вычислений», учитывая известные их возможности сведения к минимуму трудностей внедрения и эксплуатации сложных программных комплексов (как финансового, так и технического характера). При этом хранение и обработка данных реализуется не на стороне пользователя, а на стороне компании, предоставляющей соответствующий интернет-сервис. Сегодня в организациях, занимающихся проблемами управления на различных уровнях, наблюдается увеличение количества разнородной по архитектуре и используемыми операционными системами (ОС) вычислительной техники. Естественным становится стремление сделать эти устройства взаимозаменяемыми, что связывается с двумя подходами:
1) разработка кросс-платформенного программного обеспечения (ПО);
2) разработка ПО в виде SaaS-сервиса с обеспечением доступа к нему через интернет-браузер [3].
При этом по характеру облачного сервиса прежде всего выделялись следующие модели обслуживания:
1. SaaS (software as a service) распространения ПО, при которой разработчик разрабатывает его и занимается его поддержкой, а заказчикам предоставляется доступ к ПО с возможностью использования его через Интернет.
2. PaaS (platform as a service), при которой на основе платформы, размещенной на сервере, заказчик может разрабатывать собственные приложения.
3. IaaS (infrastructure as a service) с удаленным размещением IT-инфра-структуры компании и предоставлением пользователям доступа к ней.
Анализ рассмотренных категорий облачных вычислений и подходов к реализации облачных сервисов позволил сделать предварительный вывод о целесообразности применения модели SaaS с доступом через Web-браузер.
С позиций разработки и построения программного комплекса РТ-Q-l использование такой модели заказчику нет необходимости нести затра-
ты на внедрение, обновление, поддержку ПО и оборудования для его работы. В отличие от классической формы использования ПО (лицензирования) заказчик несет относительно небольшие затраты, носящие периодический характер. При этом предполагается возможность временного приостановить его использование. В отличии ASP-систем (application service provider) при использовании модели SaaS заказчик оплачивает доступ программному комплексу (единому для всех), которым наравне с ним пользуются все заказчики; разработчик SaaS-системы обеспечивает развитие и своевременное обслуживание программного комплекса. Кроме того, использование единого программного комплекса позволяет планировать распределение вычислительных мощностей, что обеспечивает снижение стоимости эксплуатации ПО и, естественно, сказывается на цене услуг для его заказчика.
Факторы, которые могут ограничивать использование данной модели сводятся к следующему:
— значительная экономия ресурсов разработчика SaaS-систем достигается за счет «эффекта масштаба», поэтому SaaS-системы зачастую неэффективны при необходимости глубокой адаптации под каждого заказчика;
— многие заказчики опасаются использовать SaaS-системы из соображений безопасности (возможность утечки информации), хотя этот факт зачастую не подтверждается практикой;
— для работы с SaaS-системой необходимо подключение к Интернету.
Исходя из этого, применение концепции SaaS-системы является целесообразным для решения задачи наиболее простого обмена данными в информационном поле «СГРЦТ - субъекты регулирования», где оно позволит ускорить процесс внедрения и снизить затраты на обслуживание заказчика. Принципиальная схема информационного обмена в информационном поле «СГРЦТ — субъекты регулирования» при использовании концепции SaaS показана на рисунке 1.
65
Рис. 1. Схема информационного обмена при использовании концепции SaaS
Наиболее распространенным языком программирования в SaaS является язык php, интерпретатор которого запускается на Web-сервере, а ПО представляет собой набор скриптов, хранящихся в исходных кодах. Часть разработчиков отдают предпочтение языкам ASP, Phyton, Perl. Существуют специализированные редакторы, которые упрощают написание кода и поиск ошибок в нем. Они позволяют создавать скрипты под разные интерпретаторы (php, ASP и др.).
Анализ возможности использования различных программных платформ при создании комплекса РТ-Q-l, в том числе Ruby on Rails (версии 5.0.2 и 4.2), Zend Framework (версии З и 2) и Eclipse (версии 4.6 Neon и 4.5 Mars) показывает, что практически все они в той или иной степени пригодны в качестве инструмента для решения поставленной задачи. Немаловажным фактором при выборе программной платформы стал тот факт, что основной упор разработчиками Zend Framework был сделан на обеспечение возможности построения надежных, хорошо защищенных и современных кросс-платформенных WEB-приложений.
Zend Framework представляет собой библиотеку классов, на основе которой по определенным правилам разрабатывается приложение. Отмечается, что использование этих библиотек в значительной степени сокращает время на проектирование и разработку приложения [4 — 6]. Это достигается за счет применения ранее созданного и выверенного программного кода.
Zend Framework, как и RoR, реализует архитектурный шаблон MVC. Так, с учетом опыта работы авторов с языком PHP и базами данных MySQL, был сделан вывод о том, что наиболее полно отвечающей всем предъявленным критериям и удобной для разработки программной платформой при разработке программного комплекса РТ-Q-l является Zend Framework 2.0. Кросс-платформенные SDK (SowftwareDevelopmen-Kit — комплект средств разработки) позволяют снизить трудозатраты при разработке ПО под Linux и Windows, а кросс-платформенные IDE (Integrated Development Environment — интегрированная среда разработки) [4] делают разработку приложений еще проще, устраняя при этом недоработки SDK.
Специальное алгоритмическое обеспечение комплекса РТ-Q-l разрабатывалось из условия возможности его функционирования практически на любых современных ЭВМ. Кроме того, с учетом возможностей использования SaaS как принципа построения приложений, при котором клиентские приложения обеспечивают только за ввод и вывод информации в серверную часть ПО, несомненным аргументом в пользу реализации РТ-Q-l в виде SaaS-приложения становится возможность постоянного обновления используемых алгоритмов. Для успешной их реализации могут быть использованы языки программирования php и Java. В качестве системы управления базами данных (СУБД) для РТ-Q-l предложено использовать MySQL, SQLlite или другую СУБД, применяемую в SaaS-сервисах в связке Web-сервера Apache и интерпретатора php.
При разработке базовых алгоритмов комплекса РТ-О-1 автоматизированного расчета тарифов на тепловую энергию за основу была принята утвержденная Федеральной службой по тарифам [7], соответствующим образом модифицированная авторами с целью обеспечения возможности ее эффективного использования при реализации поставленной задачи [8].
2. Структура программного комплекса РТ^-1
В результате проведенных исследований по формированию структуры программного комплекса РТ^-1 последний представлялся двумя ключевыми подсистемами:
1) формирование необходимой валовой выручки регулируемой организации (ФНВВ-1);
2) расчет тарифов на тепловую энергию (РТ-1).
Каждая из указанных подсистем состоит из отдельных программных модулей, перечень которых приведен в таблице 1 [1]. Все необходимые для расчетов исходные данные, получаемые с использованием действующих в организациях (субъектах региональной системы теплоснабжения) средств контроля и учета, накапливаются и хранятся в базах банных (БД) соответствующих подсистем комплекса РТ-О-1. На всех уровнях комплекса осуществляется контроль полноты и правильности заполнения таблиц БД с использованием процедур диагностики.
Принятая концепция разработки сложных программных продуктов, к которым в полной мере относится комплекс РТ-О-1, позволила построить его общую структуру с использованием результатов системного анализа и декомпозиции общей задачи расчета тарифов на отдельные функциональные подсистемы, включающие наборы взаимосвязанных программных модулей. При этом не исключается возможность их раздельного функционирования в процессе решения отдельных задач комплекса.
Проведенный анализ состава решаемых в рамках комплекса задач и особенностей реализации предложенных базовых машинно-ориентированных алгоритмов их решения позволили выявить основные режимы его работы (рис. 2) и поставить задачу разработки внутрисистемных и дружественных пользовательских интерфейсов его подсистем.
Проведенный анализ различных подходов к созданию больших программных комплексов сложной структуры, каждый из которых имеет свои достоинства и недостатки, обусловленные принятым построением программной системы, показал, что из всех рассмотренных подходов в большей степени с точки зрения эффективности применения к организации комплекса РТ-О-1 представлялся вариант реализации децентрализованной архитектуры, при которой управление всеми функциональными программными подсистемами осуществляется единой управляющей подсистемой, с общим для всех подсистем интерфейсом взаимодействия с пользователями и БД. При этом могут быть успешно реализованы условия абсолютной автономности входящих в состав РТ-0-1 функциональных подсистем.
67
Таблица 1
Перечень подсистем (модулей) комплекса РТ-О-1
68
Обозначение Наименование
ФНВВ-1. Формирование необходимой валовой выручки регулируемой организации
МЭОР-1 Формирование необходимой валовой выручки методом экономически обоснованных расходов (метод 1)
МИУТ-1 Формирование необходимой валовой выручки методом индексации установленных тарифов (метод 2)
МОДИ-1 Формирование необходимой валовой выручки методом обеспечения доходности инвестированного капитала (метод 3)
МСА-1 Формирование необходимой валовой выручки методом сравнения аналогов (метод 4)
РТ-1. Расчет тарифов на тепловую энергию
Т.ТМ-1 Расчет тарифов на тепловую энергию (мощность) без учета стоимости услуг на передачу тепловой энергии
Т.УПТ-1 Расчет тарифов на услуги по передаче тепловой энергии, теплоносителя
Т.ТЭ-1 Расчет тарифов на тепловую энергию (мощность), поставляемую теплоснабжающими организациями
Т.ТЭП-1 Расчет тарифов на тепловую энергию (мощность), поставляемую потребителям
Т.Тн-1 Расчет тарифов на теплоноситель
Т.ГВ-1 Расчет тарифов на горячую воду в открытых системах теплоснабжения
Т.УПМ-1 Расчет платы за услуги по поддержанию резервной тепловой мощности при отсутствии потребления тепловой энергии для категорий (групп) социально значимых потребителей
Т.ПТ-1 Расчет платы за подключение к системе теплоснабжения
При таком подходе каждая подсистема реализуется с использованием уникального ПО для нее функционального и локальной БД. Общая структура программного комплекса РТ-О-1 приведена на рисунке 3.
Обеспечивающее ПО (интерфейс взаимодействия пользователя и БД) является одинаковым для всех его подсистем. В этом случае основным назначением управляющей подсистемы становится объединение информационных ресурсов всех локальных подсистем в единое информационное пространство (банк данных) для их работы. ПО управляющей подсистемы обеспечивает реализацию процедур вызова необходимой подсистемы, ее инициализацию для решения конкретной задачи и организации ее работы (диалог с пользователем, ввод/вывод данных).
69
Рис. 2. Основные режимы работы комплекса РТ-<2-1
УПРАВЛЯЮЩАЯ ПОДСИСТЕМА
ФУНКЦИОНАЛЬНОЕ ПО
Обеспечивающее ПО системы
л
Банк данных системы
Обеспечивающие ПО подсистем №1...М
Базы данных подсистем №1...М
ФУНКЦИОНАЛЬНЫЕ ПО №1.. .М
ПОДСИСТЕМЫ № 1...М
Рис. 3. Общая структура программного комплекса РТ-<2-1
Результаты работы локальной подсистемы вместе с данными, введенными пользователем, реплицируются в банк данных комплекса для последующего использования управляющей подсистемой и другими функциональными подсистемами. Организация изменения в какой-либо подсистеме становится возможной благодаря использования единого адресного пространства. Все локальные подсистемы при такой организации должны иметь идентичную архитектуру (рис. 4), а вся структура (архитектура) функционирует как единая система (комплекс).
70
ПРЕДСТАВЛЕНИЕ ДАННЫХ И ОРГАНИЗАЦИЯ ДИАЛОГА
| П О ЛЬЗ О В А Т Е Л Ь
г___ А
[Подсистемам^ [Подсистемам! [Подсистема^!
, 1 ь [Подсистемам!
Рис. 4. Логика работы функциональной подсистемы РТ-О-1
При выборе принципов разработки отдельных функциональных подсистем учитывались результаты предварительного анализа их взаимосвязей (зависимости по результатной информации) в процессе решения поставленных задач в условиях организованного доступа к общему банку данных системы (табл. 2).
С целью обеспечения эффективности функционирования комплекса РТ-О-1 разработка его информационного обеспечения проводилась с использованием подхода, основанного на единстве информационного пространства. В качестве модели организации данных была принята реляционная модель. В условиях большой структурной и содержательной сложности разрабатываемой БД комплекса и необходимости эффективного внешнего представления в принятой форме содержащихся в ней данных был предложен единый подход к формированию дружественного интерфейса. Решение такой задачи в первую очередь связывалось с необходимостью анализа состава и разделения полей данных БД на группы в соответствии с принятым в работе [8] подходом, предполагающим формирование их имен в виде последовательности: адресная часть, уникальный индекс элемента и информационная часть. Нормализация структур данных проводилась в соответствии с положениями теории нормальных форм [9].
Таблица 2
Связи подсистем комплекса РТ-Q-l по результатной информации
- - 1 2 3 4 5 6 7 8 9 10 11 12
МЭОР-1 1
МИУТ-I 2 1
МОДИ-1 3 1 1
МСА-1 4 1 1
Т.ТМ-1 5 1 1
Т.УПТ-1 6 1 1
Т.ТЭ-1 7 1
Т.ТЭП-1 8 1 1 1
Т.ТН-1 9
Т.ГВ-1 10 1 1
Т.УПМ-1 11 1 1 1
Т.ПТ-1 12
71
Принятый принцип децентрализации хорошо поддерживает условия автономности входящих в его состав функциональных подсистем [10]. Информация, необходимая для координации информационного обмена между локальными подсистемами в процессе их взаимосвязанного функционирования, хранится в БД управляющей подсистемы. При этом каждая подсистема комплекса имеет свою локальную БД. Условно-постоянная справочная информация хранится в соответствующих таблицах локальной БД. Там же хранятся и таблицы оперативной информации соответствующей установленным временным периодам. Структурированная результатная информация хранится в таблицах результатов локальных БД. С целью достижения приемлемого уровня адаптивности пользовательского интерфейса было принято решение о целесообразности реализации процедуры динамического его формировании при решении стандартных задач взаимодействия на базе метаданных о связях и структуре используемого элемента с другими элементами.
Информация о свойствах объектов комплекса и настройках, необходимая для реализации процедур автоматического формировании пользовательских интерфейсов и обслуживания структур данных комплекса, организованно хранится в БД метаинформации. При таком подходе может быть исключена необходимость разработки интерфейса для каждого элемента.
По характеру своего функционирования программный комплекс РТ-Q-l, как и автоматизированные системы управления деятельностью теплоснабжающих организаций региона в целом, является активной системой «человек-машина», включающей множество взаимосвязанных и взаимозависимых объектов. Просмотр и печать документов (отчетов), сформированных в процессе работы соответствующих модулей комплекса, осуществляется с использованием прикладных программ MS Office (Word, Excel) и Adobe Reader или их аналогов.
Перед началом работы отдельных подсистем (модулей) РТ-Q-l запускается комплекс процедур диагностики БД и устранения найденных ошибок. Главное окно универсального пользовательского интерфейса отображает все необходимые для управления элементы, с ис-
72
пользованием которых осуществляется выбор режима его работы и последующий вызов интерфейса соответствующей локальной подсистемы. При вызове через главное окно комплекса диалоговых окон для работы соответствующей локальной подсистемы реализуется процедура активации отдельных режимов.
Различие решаемых в отдельных подсистемах комплекса РТ-Q-l задач делает уникальным элементный состав их пользовательских интерфейсов с обязательным наличии в них следующих режимных элементов: «Работа с БД», «Диагностика», «Расчет», «Отчеты», «Настройка», «Помощь», «О программе». Начало работы с РТ-Q-l начинается с запуска подсистемы «Авторизация», после чего пользователю предоставляется доступ к подсистемам РТ-Q-l. Навигация дублируется в главном меню программы. В зависимости от предоставленных прав доступа пользователь может запустить одну из четырех подсистем: «Работа с БД», «Программные модули (Расчет)», «Работа с отчетами». «Настройка».
Ввод и редактирование полей справочников и оперативных массивов проводится с использованием режима «Работа с БД». При формировании форм для печати как заполнение полей справочников и оперативных массивов применяется режим «скролинг» в графическом интерфейсе комплекса РТ-Q-l. Наряду с обеспечением на основе данных архива РТ-Q-l формирования новых отчетов по заданным шаблонам, вывода их на печать и сохранение во внешних файлах, при реализации режима «Работа с отчетами» предусматривается возможность работы с ранее сформированными отчетами.
В РТ-Q-l также предусмотрен режим «Диагностика», обеспечивающий слежение за степенью корректности и готовности (достаточности) данных, используемых для реализации той или иной процедуры расчета, формирование и выдачу сообщений о найденных несоответствиях в части полноты заполнения полей таблиц БД и соответствия установленным ограничениям.
Режим «Справка» обеспечивает формирование и вывод на экран по запросу пользователя контекстно-зависимой справочной информации по составу и порядку выполнения различных операций в процессе функционирования комплекса, включая общую информацию о системе, а также представление структурных и алгоритмических особенностей решаемых в рамках комплекса задач.
В целом логика функционального ПО комплекса РТ-Q-l представляется двумя уровнями:
— первый включает набор хранимых в БД комплекса и других БД процедур обработки данных с использованием средств на языке SQL, выполняемых СУБД;
— второй включает процедуры обработки в программном коде функциональных модулей комплекса.
На СУБД при этом возлагается и решение проблемы оптимизации хранимых процедур, имеющих большую размерность и вложенность. Предусмотренный в РТ-Q-l режим «Справка» обеспечивает формирование и вывод на экран по запросу пользователя контекстно-зависимой справочной информации по составу и порядку выполнения различных операций в процессе функционирования комплекса, включая общую информацию о системе и реализованных в ней алгоритмах.
В целом результаты работы комплекса в виде формируемых отчетов используются на различных уровнях проверки, анализа и утверждения тарифов на производство и передачу тепловой энергии. В рамках комплекса РТ-Q-l планируется также реализация специальных программных процедур, обеспечивающих возможность проведения различных вычислительных экспериментов при различных наборах исходных данных, что дает возможность широкого использования комплекса при решении задач прогнозирования и обучения.
Список литературы
1. Арунянц Г. Г., Воронин Т. А., Айрапетов С. А. Процесс регулирования деятельности субъектов теплоснабжающего комплекса Калининградской области и пути его автоматизации // Научное обозрение. 2016. № 9. С. 231—238.
2. Арунянц Г. Г., Воронин Т. А., Айрапетов С. А. Концепция и особенности построения программного комплекса РТ-Q-l автоматизированного формирования тарифов в сфере теплоснабжения // Наука и бизнес: пути развития. 2016. № 3 (57). С. 66 — 73.
3. Денисов Д. В. Перспективы развития облачных вычислений // Прикладная информатика. 2009. № 5 (23). С. 52—58.
4. Здзиарски Дж. iPhone SDK. Разработка приложений. СПб., 2010.
5. Hartl M. Ruby on Rails Tutorial. Addison-Wesley, 2015.
6. Васвани В. Zend Framework. Разработка веб-приложений на PHP. СПб., 2012.
7. Об утверждении Методических указаний по расчету регулируемых цен (тарифов) в сфере теплоснабжения (с изменениями на 27 мая 2015 года) : приказ Федеральной службы по тарифам от 13 июня 2013 года № 760-э.
8. Арунянц Г. Г., Хузмиев И. К., Калинкин А. Ю. Особенности построения программного комплекса расчета и анализа потерь в электрических сетях // Вестник ФЭК РФ. 2001. №4. С. 47—54.
9. Харрингтон Д. Проектирование объектно-ориентированных баз данных. М., 2001.
10. Collins D. Designing Object-Oriented User Interfaces. Benjamin, 1995.
Об авторах
Тимофей Аркадьевич Воронин — асп., Калининградский государственный технический университет, Россия.
E-mail: voronin.timofey@gmail.com
Геннадий Георгиевич Арунянц — д-р техн. наук, проф., Калининградский государственный технический университет, Россия.
E-mail: Suro99@mail.ru
The authors
T. Voronin, PhD Student, Kaliningrad State Technical University, Russia.
E-mail: voronin.timofey@gmail.com
73
Prof. G. Arunyants, Kaliningrad State Technical University, Russia. E-mail: Suro99@mail.ru
