CC BY
59
НАУЧНО-ТЕХНИЧЕСКИИ ВЕСТНИК ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ, МЕХАНИКИ И ОПТИКИ июль-август 2016 Том 16 № 4 ISSN 2226-1494 http://ntv.i1mo.ru/
SCIENTIFIC AND TECHNICAL JOURNAL OF INFORMATION TECHNOLOGIES, MECHANICS AND OPTICS July-August 2016 Vol. 16 No 4 ISSN 2226-1494 http://ntv.ifmo.ru/en
УДК 004.42
КРИТЕРИИ ОЦЕНКИ И МОДЕЛИ ИНФОРМАЦИОННЫХ СИСТЕМ, ОБЛАДАЮЩИХ СВОЙСТВОМ ПОВЕДЕНИЯ В.Н. Шведенко3, О.В. Щекочихинь, П.В. Шведенкоь' c
a ООО «Регул +», Санкт-Петербург, 197101, Российская Федерация
ь Костромской государственный технологический университет, Кострома, 156005, Российская Федерация c Университет ИТМО, Санкт-Петербург, 197101, Российская Федерация Адрес для переписки: Slim700@yandex.ru
Информация о статье
Поступила в редакцию 12.04.16, принята к печати 10.06.16 doi: 10.17586/2226-1494-2016-16-4-649-654 Язык статьи - русский
Ссылка для цитирования: Шведенко В.Н., Щекочихин О.В., Шведенко П.В. Критерии оценки и модели информационных систем, обладающих свойством поведения // Научно-технический вестник информационных технологий, механики и оптики. 2016. Т. 16. № 4. С. 649-654. doi: 10.17586/2226-1494-2016-16-4-649-654
Аннотация
Исследован вопрос создания информационных систем управления предприятием, обладающих свойством поведения. Поведение информационной системы рассматривается с точки зрения целенаправленного расширения ее функций, потребность в которых возникает вследствие изменчивости внешней и внутренней среды предприятия. Для создания систем с поведением предлагается использовать интегрированные информационные системы, которые строятся из узкоспециализированных, малофункциональных приложений. Предложены критерии классификации информационных систем с поведением по набору функций, по вариантам передачи управления в приложение, по уровню интеграции ее компонентов. Раскрыта классификация по уровням интеграции компонентов информационной системы. В рамках классификации предложено 4 варианта структурных моделей интегрированных систем. Первый вариант интеграции строится на основе брокеров сообщений, при этом достигается автоматическая передача данных и запуск соответствующих приложений. Второй вариант строится на основе интегрированной базы данных, что позволяет приложениям работать в соответствии с установленным регламентом. Третий вариант интеграции осуществляется на уровне сервисов и позволяет строить структуры с заранее не определенной конфигурацией интернирующихся приложений для решения актуальной задачи. Четвертый вариант интеграции строится на уровне интерпретации метаданных для системы распределенных баз данных и приложений, взаимодействующих с этими базами. Поведение системы возникает в случае, когда новое приложение автоматически обменивается входными и выходными данными с другими компонентами информационной системы, а также имеет возможность гибкой настройки параметров взаимодействия функций. Ключевые слова
информационная система, интеграция, поведение информационной системы, методы интеграции, брокеры, сервисы, данные, метаданные
EVALUATION CRITERIA AND MODELS OF INFORMATION SYSTEMS WITH THE PROPERTY OF BEHAVIOR V.N. Shvedenko3, O.V. Schekochikhinb, P.V. Shvedenkob,c
a LLC "Regul +", Saint Petersburg, 197101, Russian Federation ь Kostroma State University of Technology, Kostroma, 156005, Russian Federation c ITMO University, Saint Petersburg, 197101, Russian Federation Corresponding author: Slim700@yandex.ru
Article info
Received 12.04.16, accepted 10.06.16 doi: 10.17586/2226-1494-2016-16-4-649-654 Article in Russian
For citation: Shvedenko V.N., Schekochikhin O.V., Shvedenko P.V. Evaluation criteria and models of information systems with the property of behavior. Scientific and Technical Journal of Information Technologies, Mechanics and Optics, 2016, vol. 16, no. 4, pp. 649-654. doi: 10.17586/2226-1494-2016-16-4-649-654
Abstract
The paper focuses on the creation of enterprise management information systems with the property of behavior. Behavior of information system is considered from the standpoint of its functions targeted expansion; the need for them arises from the variability of the external and internal environment. To create a system with behavior, integrated information systems are encouraged to be used constructed from highly specialized, low functional applications. Classification criteria of information systems with behavior are proposed by a set of functions, by options of control transfer to the application, by the integration level of information system components. Classification is revealed by integration levels of information system components. Within the classification four options for structural models of information systems are suggested. The first option is based on the integration of message brokers with achieving of automatic data transfer and the launch of the relevant applications. The second option is based on an integrated database that enables applications to operate in accordance with established regulations. The third version of the integration is carried out on the level of services and gives the possibility to build structures with preliminary uncertain configuration of intern applications for the actual problem solution. The fourth option is based on integration level of the interpretation of metadata for distributed database systems and applications that interact with these databases. The system behavior comes into existence in case of new application automatically exchanges input and output data with the other components of information system and has the possibility of flexible parameter setting of functions interaction. Keywords
information system, integration, information system behavior, integration methods, brokers, services, data, metadata
Введение
Жизненный цикл информационной системы (ИС) связан с периодически возникающей потребностью вносить в нее изменения, которые определяются диверсификацией, изменением организационной структуры, приобретением нового технологического оборудования и другими внешними и внутренними причинами. Изменения внешней среды заставляют руководство бизнеса пересматривать целевые ориентиры своей деятельности, которые связаны с ассортиментной, ценовой, сбытовой политикой и т.п. Смена целевых ориентиров бизнеса зависит от кризисных ситуаций в экономике, влияния конкурентов, изменения нормативно-правовой базы.
Существует два подхода к проектированию ИС - создание монолитных и интегрированных информационных систем. Расширение функциональных возможностей монолитных ИС осуществляется за счет создания новых версий программных продуктов или приложений, что наблюдается практически у всех крупнейших разработчиков программного обеспечения (ПО) (ORACLE, MS и т.п.). Это приводит к отставанию функциональных возможностей ИС управления от потребностей бизнеса. Сведение к минимуму затрат на адаптацию и эксплуатацию ИС при получении новых функций и новых возможностей для управления предприятием является актуальной задачей, которая решается с помощью технологий создания интегрированных информационных систем [1, 2].
Для построения интегрированных ИС используются объектно-ориентированные технологии [3-5], метамоделирование систем [6, 7], облачные технологии [8-10], архитектурные решения на основе единой шины данных [11-14]. При перенастройке интегрированной ИС под изменившиеся условия ее эксплуатации возникают проблемы согласования форматов передачи данных, идентификации информационных объектов [5], сохранении информационных ресурсов в интегрированной базе или хранилище данных, интеграции нового приложения в ИС [15, 16].
Для решения указанных проблем предлагается метод совершенствования функциональных возможностей ИС управления предприятием путем наделения ее свойством поведения. Поведение ИС рассматривается с точки зрения целенаправленного расширения ее функций, потребность в которых возникает вследствие изменчивости внешней и внутренней среды предприятия.
Поведение информационных систем в условиях динамической внешней и внутренней среды
предприятия или организации
Целевые ориентиры бизнеса определяют архитектуру ИС предприятия, формируют потоки данных и набор показателей контроля и управления процессами.
Поскольку внешняя и внутренняя среда предприятия формирует цели и задачи ИС, то в зависимости оп состояния среды ИС с поведением будет настраиваться на решение соответствующего класса задач. При изменении либо внешней, либо внутренней среды предприятия возникает потребность в обработке новой информации либо известной информации новыми методами.
Если алгоритмы обработки данных, реализованные в модулях ИС, не позволяют подготовить информацию для принятия решений, то необходимо интегрировать в систему приложение, в котором реализован требующийся алгоритм обработки данных.
Новое приложение может работать независимо, в этом случае необходимо ввести данные, обработать информацию, получить результат и передать данные в другое приложение. При такой работе приложения нельзя говорить о системе с поведением. Поведение системы возникает в случае, когда новое приложение автоматически обменивается входными и выходными данными с другими компонентами ИС, а также имеет возможность гибкой настройки параметров взаимодействия функций.
Критерии оценки информационных систем с поведением
Наделение интегрированной ИС свойством поведения позволяет расширять ее функциональные возможности без корректировки исходного кода или перенастройки отдельных компонентов системы.
Поведение системы зависит от ее элементов, которыми являются приложение, действующее в рамках ИС, библиотека функций, система управления базой данных (СУБД), база данных (БД), интегрирующий модуль, который может быть реализован в виде брокера или сервиса.
Системы с поведением можно классифицировать по следующим критериям.
1. Набор функций, которые последовательно или параллельно должны выполняться в приложении. Входные и выходные данные, которые подаются на обработку приложением, задаются внешней средой и определяются целью запуска приложения на исполнение.
2. Варианты передачи управления в приложение: ключи, конфигурационные файлы (ini, реестр, xml, json), БД под управлением СУБД, метамоделирование структуры данных с возможностью ее расширения, метамоделирование бизнес-процесса, которое позволяет формировать систему показателей состояния объектов и субъектов, участвующих в процессе.
3. Уровень интеграции компонентов ИС: уровень брокеров, уровень данных, уровень сервисов, уровень интерпретирования метаинформации.
4. Виды обработки данных: статистическая обработка данных, корреляционный анализ, многофакторный анализ, интеллектуальный анализ данных с использованием нейронных сетей, когнитивный анализ.
Структурные модели интеграции элементов информационной системы с поведением
Критерии классификации ИС с поведением по набору функций, по вариантам передачи управления в приложение, по уровню интеграции компонентов ИС связаны между собой, и эти связи определяются целями и задачами поддержки организационного управления предприятием. В настоящей работе подробно раскрыта классификация по уровням интеграции компонентов ИС. При построении интегрированной системы в ее структуре обязательно должен присутствовать интегрирующий блок, который выполняет следующие задачи: определение формата обмена данными, формирование запроса на получение данных, передача в БД полученных результатов.
Интеграция на уровне брокеров. Данный уровень интеграции использует набор интерфейсов программирования приложений (API). Достигаемая цель интеграции - автоматическая передача данных и запуск исполняемого кода. Для конечного пользователя интегрированные компоненты представляет единую систему.
Преимущества: универсальность - практически всегда можно создать дополнительный программный модуль, который будет обращаться в обе системы различными способами, например, в одну через БД, а в другую через удаленный вызов процедур.
Недостатки: большое количество связей n(n-1) между приложениями, сложность, трудоемкость, а следовательно, высокая стоимость разработки, внедрения и владения.
Если для взаимодействия компонентов ИС используется уровень брокеров, то задачи интегрирующего блока решает соответствующий адаптер компонента системы (рис. 1).
Рис. 1. Фрагмент структурной схемы интеграции на уровне брокеров
Интеграция на уровне данных. На данном уровне интеграции приложения настраиваются на работу с единой БД или несколькими связанными между собой БД. Цель интеграции - конечные пользователи работают с едиными данными, а обрабатывают их разными инструментами.
Преимущества: низкая стоимость интеграции, а при использовании одной СУБД это становится очень заманчивым решением.
Недостатки: разрушение целостности данных. Если БД не экранирована хранимыми процедурами и не имеет необходимых ограничений целостности в виде указания каскадных операций и триггеров, то разные приложения могут приводить данные в противоречивые состояния. Если же база экранирована и
целостность обеспечивается, то в этом случае в параллельно работающих с одной БД приложениях будут дублирующие части кода, выполняющие одинаковые или похожие операции. Кроме того, при изменениях структуры базы необходимо отдельно переписывать код всех приложений, с ней работающий.
При использовании единой объектно-ориентированной СУБД для задач интеграции возникают проблемы дублирования данных либо сложности извлечения данных из иерархических структур. Для решения названных проблем можно использовать параллельные структуры, что позволяет извлекать экземпляры объектов, избегая избыточности данных и разных аномалий.
При интеграции приложений на уровне данных необходим дополнительный модуль настройки единой БД, который позволяет однозначно определять источник данных, формат и регламент передачи данных, формат хранения данных, приложение, которое реализует соответствующий алгоритм обработки данных. Это наиболее трудоемкий вариант с точки зрения создания и отладки интегрированной системы (рис. 2).
Приложение 1 -—
Модуль настройки баз данных
Приложение 2 —Т^-
Адаптор 1 СУБД о
С11
— База данных
Адаптор 3 СУБД
У :
12.
Адаптор 2 СУБД
Адаптор 4 СУБД
Приложение 3
Приложение 4
Рис. 2. Структурная схема интеграции на уровне единой базы данных
Интеграция на уровне сервисов. При интеграции на уровне сервисов чаще всего используется сервис-ориентированная архитектура (80А) и шина данных (рис. 3). Сервис представляет собой одну или несколько прикладных функций приложения, реализующих логику информатизируемого процесса. Основными достоинствами использования сервисов являются возможность многократного использования, слабая связанность сервисов друг с другом.
Приложение 1 Приложение 2 Приложение 3
о о о
Сервис 1 Сервис 2 Сервис 3
О ^ о ^ о ^
Шина данных
И
Адапто] СУБД 1 3
База
данных 1
п
Адаптор СУБД 2
База
данных 2
Рис. 3. Структурная схема интеграции на уровне сервисов
Цель интеграции - быстрая отработка корпоративной бизнес-логики. Интеграция основана на фиксации интерфейсов и форматов данных с двух сторон.
Преимущества: низкая стоимость интеграции, быстрое объединение сильно различающихся систем без их модификации и разработки новых модулей. Дополнительным преимуществом интеграции на уровне сервисов является возможность использования облачных технологий для интеграции приложений в ИС.
Недостатки: присутствует фиксация, а если структуры или процессы изменяются, то образуются проблемы и узкоспециализированные, частные решения. При интеграции на уровне сервисов важно применение стандартизованных компонентов. Также возникает проблема обеспечения безопасности данных в такой гетерогенной системе.
На данном уровне возможен вариант исполнения интеграции, где функции передачи данных будет выполнять человек, используя унифицированные интерфейсы отображения данных. Наиболее перспективной является автоматизированная интеграция с использованием облачных сервисов для организации взаимодействия разрозненных компонентов.
Функция поведения закладывается в интегрирующий сервис, который с минимальными затратами позволяет настроить обмен данными между приложениями (рис. 3).
Интеграция на уровне интерпретирования метаинформации. Цель интеграции - ИС хранит данные в самоописывающем хранилище, а пользователь может модифицировать данные, расширять структуру метаданных, переналаживая ИС под постоянно меняющиеся требования решаемой задачи. Метаданные позволяют однозначно идентифицировать свойства и формат описания информационных объектов при передаче данных между интегрируемыми приложениями.
Преимущества: гибкость подхода и упрощение модификации систем, снижение необходимого уровня квалификации пользователя при внесении изменений в структуру и функции.
Недостатки: сложность создания ПО с повышенным уровнем абстракции, сложность в реализации метамодели, сложность в сопоставлении информационных ресурсов в разных системах метаданных.
При организации интеграции на уровне интерпретирования метаинформации функцию поведения берет на себя подсистема анализа производственной информации и деятельности предприятия, которая описывает архитектуру ИС (рис. 4). Этой подсистемой определяется новая модель метаинформации. Задачи интеграции выполняет подсистема интеграции и синхронизации данных с внешними источниками данных.
Подсистема анализа производственной информации и деятельности предприятия
Подсистема оперативного контроля и мониторинга исполнения управленческих решений
Подсистема интеграции и синхронизации данных с внешними источниками данных
731
Подсистема управления регламентом работы внутри ИС
Подсистема организации общей информационной среды предприятия
V
Подсистема управления хранилищем данных
Рис. 4. Структурная схема взаимодействия компонентов информационной системы при интеграции
на уровне интерпретирования метаинформации
Заключение
В работе предложены критерии классификации интегрированных информационных систем по набору функций, выполняемых приложениями, вариантам передачи управления в приложение, уровням интеграции компонентов системы, видам обработки данных. На основе классификации рассмотрены четыре варианта реализации интеграции: уровень брокеров, уровень данных, уровень сервисов, уровень интерпретирования метаинформации. Для каждого варианта интеграции предложено архитектурное решение интегрированной информационной системы управления предприятием, наделяющее ее свойством поведения. Указаны достоинства и недостатки каждого решения.
Литература
1. Алаудинов А.Г. Построение единой системы интеграции данных в крупных корпорациях // Труды Международного симпозиума «Надежность и качество». 2011. Т. 1. С. 239-242.
2. Жижимов О.Л., Федотов А.М., Шокин Ю.И. Технологическая платформа массовой интеграции гетерогенных данных // Вестник НГУ Серия: Информационные технологии. 2013. Т. 11. №1. С. 24-41.
3. Шведенко В.Н., Волков А.А. Модель формирования параллельных структур в объектно-ориентированных СУБД // Программные продукты и системы. 2011. № 3. C. 3.
4. Волков А.А., Набатов Р.А., Щекочихин О.В. Адаптивная автоматизированная система сбора и отображения информации для управления предприятием // Научно-технический вестник СПбГУ ИТМО. 2008. № 46. С 3-6.
5. Шведенко В.Н., Веселова Н.С. Моделирование информационных ресурсов предприятия при процессной организации системы управления // Программные продукты и системы. 2014. №4. С. 260-264. doi: 10.15827/0236-235X. 108.260-264
6. Кузькин А.А., Смирнов С.В., Басов О.О. Модель обеспеченности стратегии развития информационных технологий в организации // Научно-технический вестник информационных технологий, механики и оптики. 2015. Т. 15. № 2. С. 305-312. doi: 10.17586/2226-1494-2015-15-2-305-312
7. Oleynik P.P. Using metamodel of object system for domain-driven design the database structure // Proc. 12th IEEE East-West Design and Test Symposium (EWDTS'2014). Kiev, Ukraine, 2014. Art. 7027052. doi: 10.1109/EWDTS.2014.7027052
8. Dean J., Ghemawat S. MapReduce: simplified data processing on large clusters // Proc. 6th Symposium on Operating System Design and Implementation. San Francisco, 2004. P. 137-150. doi: 10.1145/1327452.1327492
9. Laplante P.A., Zhang J., Voas J. What's in a name? Distinguishing between SaaS and SOA // IT Professional. 2008. V. 10. N 3. P. 46-50. doi: 10.1109/MITP.2008.60
10. Gagnon S., Nabelsi V., Passerini K., Cakici K. The next web apps architecture: challenges for SaaS vendors // IT Professional. 2011. V. 13. N 5. P. 44-50. doi: 10.1109/MITP.2011.90
11.Jensen K., Christensen S. CPN Tools State Space Manual. University of Aarhus, 2013. 49 p.
12.Jaeger P.T., Lin J., Grimes J.M., Simmons S.N. Where is the cloud? Geography, economics, environment, and jurisdiction in cloud computing // First Monday. 2009. V. 14. N 5. URL: http://firstmonday.org/ojs/index.php/fm/article/view/2456/2171.
13. Sadiku M.N.O., Musa S.M., Momoh O.D. Cloud computing: opportunities and challenges // IEEE Potentials. 2014. V. 33. N 1. P. 34-36. doi: 10.1109/MPOT.2013.2279684
14.Kaufman L.M. Data security in the world of cloud computing // IEEE Security and Privacy. 2009. V. 7. N 4. P. 61-64. doi: 10.1109/MSP.2009.87
15. Владимиров А.В. Агентное взаимодействие в информационной системе предприятия с адаптацией механизмов работы и интерфейса пользователя // Научно-технический вестник информационных технологий, механики и оптики. 2013. № 6(88). С. 105-111.
16. Сысолетин Е.Г., Аксенов К.А., Круглов А.В. Интеграция гетерогенных информационных систем современного промышленного предприятия // Современные проблемы науки и образования. 2015. № 1. С. 335.
Шведенко Владимир Николаевич
Щекочихин Олег Владимирович
Шведенко Пётр Владимирович
доктор технических наук, профессор, научный руководитель проекта, ООО «Регул +», Санкт-Петербург, 197101, Российская Федерация, shvn.d3@mail.ru
кандидат технических наук, доцент, доцент, Костромской государственный технологический университет, Кострома, 156005, Российская Федерация, Slim700@yandex.ru
студент, Университет ИТМО, Санкт-Петербург, 197101, Российская Федерация; аспирант, Костромской государственный технологический университет, Кострома, 156005, Российская Федерация, Pitk1@mail.ru
Vladimir N. Shvedenko Oleg V. Schekochikhin
Petr V Shvedenko
D.Sc., Professor, Project Supervisor, LLC "Regul +", Saint Petersburg, 197101, Russian Federation, shvn.d3@mail.ru
PhD, Associate professor, Associate professor, Kostroma State University of Technology, Kostroma, 156005, Russian Federation, Slim700@yandex.ru
student, ITMO University, Saint Petersburg, 197101, Russian Federation; postgraduate, Kostroma State Technological University, Kostroma, 156005, Russian Federation, Pitk1@mail.ru
