CC BY
16
Все многообразие подходов к управлению конкурентоспособностью обобщено авторами и представлено в табл. 3 по группам: общенаучные, управленческие, экономические, рыночные, социальные, комбинированные и уровневые.
Перечисленные в таблице подходы к управлению конкурентоспособностью призваны дополнять
друг друга путем различных комбинаций, приемлемых в той или иной ситуации.
В соответствии с этим предлагается рассматривать систему управления конкурентоспособностью как совокупность взаимосвязанных подсистем, каждая из которых выполняет определенные функции. Для реализации функций необходимо использовать весь научно-методический потенциал.
СПИСОК ЛИТЕРАТУРЫ
1. Александров В. Л., Перелыгин А. В., Соколов В.Ф. Судостроительное предприятие в условиях рынка: проблемы адаптации и развития / Под общей редакцией В. Л. Александрова СПБ.: Судостроение, 2003.
2. Гладышева И. В. Прогнозирование конкурентоспособности промышленного предприятия. Автореферат дис. на соискание ученой степени канд. экон. наук. СПб., 2006.
3. Колесников С. И. Развитие инновационной деятельности в России // Компетентность 2006. № 1112/40. С. 11.
4. Кротков А. М., Еленева Ю. Я. Конкурентоспособность предприятия: подходы к обеспечению, критерии, методы оценки//Маркетинг в России и за рубежом. 2001. № 6.
5. Лесных В. В. Российский оборонно-промышленный комплекс: стоит ли спешить с интеграцией // ЭКО. 2007. С. 3-21.
И. В. Прокофьева, С. В. Шибанов, О. А. Шевченко Модель метаданные и программные средства
ОБМЕНА В СИСТЕМЕ ЭЛЕКТРОННЫХ ПЛАТЕЖЕЙ
В настоящее время любая организация нуждается в своевременном доступе к информации. Огромные потоки информации, циркулирующие в современном мире и имеющие тенденцию к увеличению, необходимо структурировать, хранить и извлекать. В связи с этим базы данных (БД), представляющие собой хранилища данных, стали основой информационных систем (ИС) многих организаций. Многие организации, использующие ту или иную систему управления базами данных (СУБД), без особого труда могут манипулировать информацией, находящейся в их информационных системах. Тем не менее, часто возникают ситуации, когда необходим обмен данными с другой организацией (например, с организацией-партнером), использующей собственную ИС. При этом,
нередки случаи, когда ИС, участвующие в обмене данными, являются разнородными, что усложняет задаче обмена. Разнородность ИС может быть обусловлена разными типами используемых СУБД и форматов БД, различиями в схемах БД. Например, атрибуты в схемах БД могут иметь одинаковые имена и представлять абсолютно различные понятия. Аналогично, атрибуты с разными именами могут представлять собой одну и ту же характеристику.
Традиционно решением задачи обмена данными между двумя разнородными ИС является разработка протокола обмена данными и создание, в соответствии с этим протоколом, приложений, позволяющих осуществить экспорт или импорт информации для обеих систем. При постоянном рас-
ширении состава организаций-партнеров, как следствие, при большом количестве разнородных ИС, участвующих в обмене данными, что предполагает различия в экспортируемых и импортируемых данных, протоколах обмена, традиционный подход становится трудоемким, требующим постоянной технической поддержки. В настоящее время проблема взаимодействия разнородных распределенных систем решается во многих промышленных СУБД, например, в Oracle и SQL Server.
Так, Oracle позволяет скрывать от пользователя разнородность распределенных систем с помощью служб поддержки разнородных баз данных и специальных агентов поддержки систем, отличных от Oracle. В SQL Server имеется Data Transformation Services (DTS). Однако можно отметить ограниченность множества СУБД, к которым возможно получить доступ с помощью подобных средств. И даже при разработке и унификации средств взаимодействия разнородных систем невозможно гарантировать, что не возникнет ситуация, когда необходимо взаимодействовать со старыми версиями СУБД или локальными СУБД, изначально не предназначенными для подобных операций.
Проблема реализации взаимодействия (обмена данными) для разнородных распределенных ИС
возникла при разработке автоматизированной информационной системы «Электронный платеж», разрабатываемой в ОАО Губернский банк «Тарханы» (г. Пенза) и предназначенной для приема и учета коммунальных и иных платежей. В процессе функционирования ИС «Электронный платеж» постоянно взаимодействует с ИС поставщиков услуг и агентов по приему платежей, регулярно обмениваясь данными. Взаимодействие осуществляется через глобальную сеть Интернет. Архитектура разнородной распределенной системы показана на рис. 1.
Поставщиками услуг являются организации, предоставляющие физическим лицам различные услуги. Например, коммунальные службы, компании сотовой связи, интернет-провайдеры и т. д. Агентами по приему платежей являются организации, принимающие от физических лиц какие-либо наличные платежи за оказанные услуги. Например, федеральная почтовая служба, банки, торговые сети, такие как «Евросеть», и т. д. Как показала практика, поставщики услуг и агенты предлагают для организации обмена данными собственные протоколы, не соответствующие протоколу, определяемому системой «Электронный платеж». Это обусловлено техническими, экономическими, юридическими и другими причинами.
МОДУЛЬ ИМПОРТА ДАННЫХ
Настройка шаблонов протоколов экспорта данных Разбор шаблона, выполнение импорта данных в соответствии с протоколом
МОДУЛЬ ЭКСПОРТА ДАННЫХ
Настройка шаблонов протоколов импорта данных Разбор шаблона, выполнение экспорта данных в соответствии с протоколом
МОДУЛЬ ПРЕОБРАЗОВАНИЯ ФОРМАТА ФАЙЛА
Целевой ^ —Ч XML
формат, (возможен
определяемый другой
шаблоном формат)
Рис. 1. Архитектура разнородной системы по приему и учета у различных платежей населения
Традиционный подход предполагает, что практически для каждого поставщика или агента необходимо было реализовать программные средства, осуществляющие выгрузку или загрузку данных в соответствии с тем или иным протоколом обмена. Учитывая, что состав поставщиков услуг и агентов по приему платежей постоянно расширяется, традиционный подход сулил серьезные накладные расходы и увеличивал срок вне-
дрения нового поставщика или агента в систему. Это, в свою очередь, тормозило развитие системы, осложняло ее тиражируемость.
Был разработан механизм, позволяющий отказаться от написания программных средств, реализующих каждый из вновь возникающих протоколов, а заменить все это многообразие программного обеспечения совокупностью модулей экспорта/импорта данных (рис. 2).
ИС «Электронный платеж»
Рис. 2. Состав модулей для обмена данными в системе «Электронный платеж»
Одним из звеньев описываемой системы является модуль преобразования формата файла. Его реализация выполняется с помощью стандартных средств, имеющихся во многих средах разработки программного обеспечения. Совокупность программных средств, реализующих преобразование данных в различные форматы, объединены в Ш1-библиотеку, к которой, в случае необходимости, выполняется обращение из программ разбора шаблонов протоколов.
Реализация модулей импорта и экспорта данных базируется на использовании метаданных. В классическом представлении под метаданными понимаются все физические данные, содержащиеся в программах и других средах, и знания, имеющиеся у людей и представленные в любой форме, собранные как внутри, так и вне
организации, и содержащие информацию о физических данных организации в целом, а также технических процессах и бизнес-процессах. Учитывая, что значительная часть служебных задач может решаться и реально решается без участия человека, метаданные подразделяются на два вида:
— человекочитаемые метаданные (Human-Readable Metadata), предназначенные для задач, которые решаются с участием человека;
— машиночитаемые метаданные (Machine-Readable Metadata), предназначенные для автоматического решения задач определенного класса.
В данном случае машиночитаемые метаданные просматриваются, создаются и редактируются пользователем с помощью программы настройки шаблонов протоколов, в которой пользователь может выполнить определение метаданных, описы-
вающих протоколы обмена данными. Описание протокола выполняется с помощью конструкций, задающих правила извлечения данных из БД, структуру файла протокола и правила проверки импортируемых данных.
Модель метаданных, позволяющая описать протокол обмена данными с помощью разработанного нами шаблона, состоит из нескольких уровней (рис. 3):
— общий уровень (метаописание), протокол обмена данными, который представляет собой формальное описание самого протокола (например, «протокол экспорта данных для поставщика 1»);
— атрибуты протокола. Здесь описываются такие характеристики, как операция (экспорт/импорт), кодировка получаемого файла, символ-разделитель (для формирования текстового варианта
файла), наименование списка контактов (по которым выполняется отправка файла протокола), целевой формат файла. Одной из характеристик является предусловие выполнения шаблона. Оно может задавать некоторые ограничения формирования протокола, на метаязыке (например, если большинство организаций получают данные в соответствии с заданным протоколом, то в предусловие можно задать номера договоров поставщиков, для которых не требуется выполнять откачку по данному протоколу). Метаязык - это язык настроек, предназначенный для вычисления грамматических выражений, состоящих из операций и операндов, а операнды, в свою очередь, состоят из констант и функций. Метаязык в нашей системе используется во многих модулях и является универсальным средством настройки:
Протокол обмена данными
Метаязык для определения предусловий
Параметры для создания файла протокола
Правила выбора данных из БД
Описание логических условий поиска данных
Структура файла протокола
( \ Правила контроля полученной информации
Рис. 3. Модель метаданных для описания протокола обмена данными
— определение параметров для создания файла протокола. На данном уровне возможно задать набор параметров, например, в случае необходимости экспортировать информацию, появившуюся в базе данных в заданный период, требуется определить для данного шаблона два параметра: дата начала и дата окончания периода, которые будут запрашиваться у пользователя для формирования файла протокола.;
— описание самого файла протокола (структура файла протокола): порядок данных в файле, источник данных (наименование таблицы базы данных и поле указанной таблицы), формальное описание данных;
— правила выбора данных из базы данных. В соответствии с этим описанием формируется запрос к базе данных. Здесь определяются таблицы, в которых расположены данные, критерии отбора записей из этих таблиц, параметры сортировки данных, а также выполняется иерархическое связывание частей запроса (определяются связи между таблицами, из которых происходит выбор информации). Это наиболее сложный уровень, имеющий несколько подуровней, которые в свою очередь позволяют описать логические условия поиска данных в таблице;
— правила контроля полученной информации (является подмодулем описания файла протокола и
используется только при описании протоколов импорта данных), закачиваемой в базу данных. Здесь могут быть заданы простые проверки на соответствие формата импортируемой информации формату данных в системе, на наличие обязательных данных, а также сложные описания проверки соответствия полученной информации и информации, уже содержащейся в базе данных. В случае сложной проверки выполняется определение способов обращения к данным в базе аналогично тому, как это осуществлялось на уровне, описанном перед этим.
Программные средства разбора шаблонов протоколов реализуют машинный анализ метаданных. Для определенного протокола здесь в соответствии с настройками, заданными шаблоном, выполняется генерация текстового файла, содержащего программный код, запуск которого приводит к созданию файла протокола. Полученная программа выполняет запрос параметров, определенных в шаблоне, осуществляет выбор данных, с помощью полученного запроса, создает файл протокола, структура которого также соответствует настройке, обращается, в случае необходимости, к модулю преобразования формата файла и отправляет итоговый файл по адресам из списка контактов.
Реализация описанного механизма выполнялась для СУБД Progress на встроенном языке 4GL. Рассмотрим работу программных средств разбора шаблонов протоколов на примере сгенерированной ими программы, которая выполняет создание файла протокола, отправляемого поставщикам услуг и содержащего информацию о необходимых перечислениях денежных средств.
Осуществляя анализ метаданных, описывающих параметры для создания файла протокола, получаем код, фрагменты которого приведены далее:
def input param dt as dat no-undo.
Далее в программе этот параметр будет использоваться для выбора информации из БД. Разбирая правила выбора данных из БД, получаем:
for each agr no-lock where agr.agrtype = «АГТ» and agr.sts = 1, each citprp of agr no-lock, each citpay of citprp no-lock where citpay.dts = dt and
citpay.stsagt <> 9:
end.
В соответствии со структурой файла протокола, определенной в шаблоне, генерируется следующий программный код:
for each protfld no-lock where protfld.id = prot.id: create t-tbl. assign
t-tbl.nmbfld = protfld.nmbfld t-tbl.val = {&protfld.fld} t-tbl.idfld = {&prot.idfld}.
end.
for each t-tbl no-lock break by t-tbl.idfld by t-tbl. nmbfld:
if last-of(t-tbl.idfld) then do: str = str + chr(13) + chr(10). put unformatted str. str = " end. else do:
str = str + t-tbl.val + prot.sprt. end.
end.
Полученный файл протокола отправляется соответствующему поставщику или агенту по списку контактов, определенному в атрибутах протокола:
run sysssmtpmail.p(prot.mails, prot.theme, "text", "", vfile, prot.flnm, output perr, output pmsg).
{stderror.i}
Выводы. Описанный механизм и программные средства, разработанные в соответствии с ним, применяются в системе «Электронный платеж» для выполнения обмена данными с поставщиками и агентами по приему платежей.
Предлагаемая схема обмена данными в разнородной распределенной системе достаточно универсальна, но не лишена недостатков. Так, например, в ряде случаев требуется включать в файлы протоколов дополнительную информацию, не предназначенную для автоматического разбора информационной системой, которая должная отделяться от основных данных символами комментарий и иметь формальный вид. Так же часто необходимо структурировать файл протокола: группировать данные в отношении того или иного признака (например, для поставщика могут понадобиться отдельные файлы по платежам, принятым каждым из агентов). Все перечисленные и другие задачи нуждаются в решении. Таким образом, предложенный механизм обмена данными необходимо развивать, расширять возможности описания атрибутов протоколов и их характеристик.
