Метод постройки бизнес-процессов на базе онтологии

РЕФЕРАТ

Работа содержит 70 страниц, 10 рисунков. Было использовано 54 источника. Цифровая экономика, какая есть предпосылкой 4-й индустриальной революции,

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

Цель работы: повысить эффективность постройки рабочих процессов за счет автоматизации, уменьшение объема ручной труды да за счет использование определенного набора правил постройки связей между функциональными сервисами на основе онтологической модели, какую легко корректировать, а также предложенных инструментальных средств постройки да модификации бизнес процессов

Объект исследование: процесс постройки рабочих процессов в современных информационных системах под время предоставление разнообразных сервисов конечным пользователям

Предмет исследования: Математические модели и методы, средства построения рабочих процессов, а также особенности проектирования программного обеспечения постройки бизнес-процессы.

Задачи:

Провести анализ методов постройки рабочих процессов да определить, что нужно для автоматизации построения рабочих процессов

Провести анализ инструментальных средств построения рабочих процессов Построить алгоритм формирования рабочих процессов на основе формализованного описания

Провести экспериментальное исследование предложенного метода формализованного описания и алгоритма построения рабочих процессов с помощью средств современных СУБД да методов описания онтологических моделей.

Методы исследований:

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

Теоретический результат исследование:

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

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

Проанализированы методы построения рабочих процессов рабочих процессов на базе онтологических моделей, которые есть недостаточно автоматизированными или совсем неавтоматизированные.

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

автоматизации, уменьшение объема ручной труды да за счет использование определенного набора правил постройки связей

Практический результат работы:

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

Разработано инструментальные средства ведение реестра функциональных сервисов, что позволило легко сходить да модифицировать сервисы да рабочие процессы, в которых они использованы.

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

Протестировано реализацию предложенного метода постройки рабочих процессов Результаты эксперимента показали целесообразность использование данной системы в связи со скоростью построения рабочих процессов и нетребовательностью системы к вычислительных ресурсов

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

Публикации:

Ключевые слова: онтология, рабочие процессы, функциональные сервисы, автоматизация процесса.

СОДЕРЖАНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

БД База данных

СУБД Система управление базами данных

ДПД Диаграмма потока данных

WfMS Workflow management system

ВВЕДЕНИЕ

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

Цель работы: повысить эффективность постройки рабочих процессов за счет автоматизации, уменьшение объема ручной труды да за счет использование определенного набора правил постройки связей между функциональными сервисами на основе онтологической модели, какую легко корректировать, а также предложенных инструментальных средств постройки да модификации бизнес процессов

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

Теоретический результат исследование:

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

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

Проанализированы методы построения рабочих процессов рабочих процессов на базе онтологических моделей, которые есть недостаточно автоматизированными или совсем неавтоматизированные.

Предложено метод формирование рабочих процессов на основе входных данных и по правилам соответствия параметров, а также учет областей допустимых значений и принадлежности сервисов к одной предметной области, что позволило повысить эффективность постройки рабочих процессов за счет автоматизации, уменьшение объема ручной труды да за счет использование определенного набора правил постройки связей

Практический результат работы:

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

Разработано инструментальные средства ведение реестра функциональных сервисов, что позволило легко сходить да модифицировать сервисы да рабочие процессы, в которых они использованы.

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

Протестировано реализацию предложенного метода постройки рабочих процессов Результаты эксперимента показали целесообразность использование данной системы в связи со скоростью построения рабочих процессов и нетребовательностью системы к вычислительным ресурсам.

РАЗДЕЛ 1.

ОБЗОР РАБОЧИХ ПРОЦЕССОВ ТА МЕТОДОВ ИХ АВТОМАТИЗИРОВАННОЙ ПОСТРОЕНИЯ

Дана работа есть продолжением предыдущих исследований в направлении автотизированной постройки рабочих процессов на базе онтологических моделей [1].

Развитие информационных технологий влечет за собой трансформацию всех сфер жизнедеятельности общества. Современное общество невозможно без цифровой экономики, формирование которой является в настоящее время одним из приоритетных направлений Для широких масс "цифровая экономика" будет означать новый уровень цифровых сервисов, когда в онлайн переходят оплаты коммунальных платежей, покупки и т.п., а для промышленности да бизнеса переход в цифровую экономику получил определение в мире как Industry 4.0 – четвертая индустриальная революция[2].

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

Значительную количество работ посвящено вопросом автоматизации постройки рабочих процессов, в частности работы 3-14.

Вычислительные независимые рабочие процессы разрабатываются с использованием графических стандартов, позволяя выполнять их формализацию с отражением их вероятных потоков и переходов в схематическом виде. Анализ показал, что на практике вычислительные независимые рабочие процессы обычно разрабатываются с использованием графических обозначений средствами, такими как BPMN 2.0 [5], UML AD (UML Диаграмма Действий), USLD [6] да инструменты, такие как CA ERwin процесс Modeler [7], Enterprise Architect [8] и MS Visio [9].

Недостатки BPMN 2.0 четко описаны в [15]. Центральный аргумент против использование регулярного BPMN состоит в поэтому, что управление ресурсами может быть выражено только через определенные абстракции (актеры, роли и т.п.) или исполнение задач в диалоге.

Тем нет меньше, BPMN, обеспечивая возможность вычислительной независимой от вычислительных рабочих процессов трансформации (Business процесс Execution Language (BPEL)), широко распространена в индустрии.

Краткий обзор методов и инструментов анализа рабочих процессов показал, что существуют два типы анализа, которые учитывают вычислительный процесс:

Для таких областей анализа используются такие программные средства, как Pegasus, Cactus, ASKALON, GLUE и и т.д. [22]. Все упомянутые да проанализированы текущие возможности для этого этапа задания очень ограничены. Недостатки методов и инструменты анализа рабочих процессов четко описаны в [23]. Центральной критикой есть то, что этап анализа требований применяется в основном вручную.

В работе [12] рассмотрен алгебра построения рабочих процессов, но это более сложный подход, поскольку требует детальной структуризации всех данных и сервисов, установка полного перечня связей, что образует дополнительную сложность постройки алгебраической структуры, особенно, когда система есть территориально распределенной и имеет значительную постоянно изменяющуюся количество сервисов и рабочих процессов

В работе [20] предложено инструментарий для постройки да анализа рабочих процессий, но все же таки предложенный подход нет достаточно автоматизирует само формирование последовательности вычислений в зависимости от условий и ограничений предметной области

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

Существует достаточно много инструментальных средств для описания да постройки рабочих процессов, но все они слабо автоматизированные да нуждаются участия человека. Решений, которые б разрешили выполнять реинжиниринг рабочих процессов в связи со изменением цель-описаний функциональных сервисов, на данный момент нет существует. Для построения рабочих процессов кластеризации цифровых данных в работе [24] предложено применение онтологических моделей, что позволило именно в зависимости от характеристик потока входных данных управлять процессом исполнение вычислений. В данной сфере почти нет используют онтологии для описания рабочих процессов, хочет онтология дает возможность формально описать процесс, структурировать его части да визуально отразить его.

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

основе которого можно автоматически строить рабочие процессы в зависимости от состояния данных предметной области

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

Онтология – описание концепций и отношений в определенной предметной области, пригоден для автоматизированной обработки. Чаще онтология сначала описывает базовые элементы предметной области, а потом ее расширяют к самых маленьких деталей [25]. В онтологии описываются все связи между этими элементами. Важным фактором является то, что онтологии создают для решения определенной задачи. поэтому ее нужно оценивать с точки зрения применимости, чем полноты [26].

Рабочий процесс ( workflow ) – схема организации последовательности выполнения задач в пределах единого сервиса, предоставляемого конечным пользователям. Может включать связанные с ним вычислительные подпроцессы, информационные зависимости, последовательность принятие решений, проведение некоторых вычислений.

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

Поток работ с информационной точки зрения – способ представления информации в различных объектов, принимающие участие в рабочем процессе [10].

Обычно рабочий процесс может быть описан с использованием формальных или неформальных методов поточных диаграмм, которые показывают направлены потоки между этапами обработки. Отдельные шаги обработки или компоненты рабочего процесса могут быть в основном определены тремя параметрами [27]:

Компоненты могут быть соединены только за условия, если выходная информация одного компонента отвечает входной информации следующего компонента, а также удовлетворяет условиям предметной области. Таким образом, семантическое описание должно включать обязательно описание входных, исходных данных и цель-описание функциональных сервисов, что выполняются в данном рабочем процессе. Если существует несколько методов (функциональных сервисов) обработки одних и тех же данных, то нужно добавить цель-описание алгоритмов, которые выполняют заданную функцию, а также желательно указать характеристики эффективности исполнение заданных функций, такие как: точность, скорость, да другие. [11]

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

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

С более абстрактной или высшей точки зрения рабочий процесс может рассматриваться как взгляд или представление реальной работы. Описываемый поток может ссылаться на документ, услугу или продукт, передаваемый с одного шага на другой.

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

Система управления рабочими процессами (WfMS) – это программная система для настройки, выполнения и мониторинга определенной последовательности процессов и задач, с целями повышения производительности, снижения затрат и улучшения обмена информацией в организации. Или системы могут быть ориентированы на процессы или на данные, и они могут представлять рабочий процесс как графические карты. Система управление рабочим процессом может также включать расширяемый интерфейс, чтобы внешние программные приложения могли быть интегрированы и обеспечивать поддержку рабочих процессов широкой области, которые обеспечивают более быстрый время отзыва да повышение производительности

Компоненты или подсистемы WfMS можно разделить на такие категории:

Каждый рабочий процесс может быть описано диаграммой потока данных.

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

Для каждого потока данных по крайней мере одна из конечных точек (источники и / или назначение) должно существовать в процессе. Уточненное представление процесса может быть сделано в другой схеме потока данных, разделяющей этот процесс на подпроцессы

Схема потока данных есть частью инструментов моделирование структурированного анализа При использовании UML диаграмма деятельности обычно принимает роль диаграммы потока данных. Особой формой плана потока данных является план ориентированного на сайт потока данных.

закругленными углами (соответственно к типа обозначение). Процесс называется одним словом, кратким предложением или фразой, явно выражающей его сущность.

Выводы

В связи с переходом к цифровизации в современном мире распространяется использование цифровых ресурсов для хранения и обработки пользовательских данных (да данных самих функциональных систем), для чего широко используют рабочие процессы да функциональные сервисы в разных сферах.

Проведенный анализ методов построения и описания рабочих процессов показывает, что большинство из них строятся человеком в ручном или полу-автоматическом режиме, что очень замедляет процесс создание самих рабочих процессов

Для отображение рабочих процессов используют теорию графов (каждая вершина – сервис, а каждая стрелка – поток данных) и диаграмм (набор элементов разных форм для отображения разных частей рабочего процесса).

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

РАЗДЕЛ 2.

ОНТОЛОГИЯ

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

Каждый элемент онтологии позволяет ограничить сложность и организовать информацию в данные да знания. со созданием новой онтологии надеются улучшить да облегчить решение проблем заданной предметной области.

Поскольку Google начал инициативу под названием Граф знаний (Knowledge Graph [27]), значительное количество исследований использовало графов знаний фразы как обобщенный термин. Несмотря на отсутствие четкого определения терминов графа знаний, его иногда используют как синоним онтологии. Одна общая интерпретация состоит в том, что граф знаний является совокупностью взаимосвязанных описаний сущностей – объектов реального мира, событий, ситуаций или абстрактных понятий. В отличие от онтологий, графы знаний, такие как Google Knowledge Graph, часто содержат большие объемы фактической информации с меньше формальной семантикой. В некоторых контекстах граф знаний используется для обозначения любой базы знаний, какая представлена в виде графов.

Общим для онтологий как в информационной науке, да и в философии есть попытка представить сущности, идеи и события со всеми их взаимосвязанными свойствами и отношениями в соответствии с системой категорий. В обеих областях существует значительная работа над проблемами инженерии онтологии и дебаты о том, насколько возможна нормативная онтология (например, фундаментализм и когерентность в философии, (BFO и Cyc в искусственном интеллекте). Прикладная онтология считается духовным наследником предыдущей работы в философии, однако много нынешних усилий больше касаются подробного формализованного описания предметных областей.

Искусственный интеллект сохраняет самую большую внимание по отношению прикладной онтологии в подполье, таких как обработка естественной языки в машинном переводе да представления знаний, но редакторы онтологии часто используются в ряде областей, таких как образование, без намерения внести свой вклад в AI.

Элементами онтологии обычно являются классы (понятия), экземпляры этих классов, их атрибуты и значение этих свойств.

Класс (понятие) – абстрактные группы, коллекции или наборы объектов. могут содержать в себе экземпляры и/или другие классы.

Экземпляр – это основные, низко уровневые компоненты онтологии

Атрибуты – элементы онтологии, что имеют имя и значение да используются для хранения информации, присущей конкретному элемент. Значение атрибута может быть составленным типом данных.

Отношение – важные компоненты онтологии, так как они показывают как классы связаны между собой. Обычно отношением является атрибут, обладающий значением есть другой класс.

Функциональные термы – сложные структуры, сформированные с определенных отношений, которые могут быть использованы вместо отдельного срока в утверждении

Ограничение – формально изложены описания того, что имеет быть истинным для того, чтобы некоторое утверждение было принято в качества входных данных.

Правила – суждения в виде предложения if-then (если тогда), описывающих логические выводы, которые можно сделать с утверждение в определенный форме.

Аксиомы – утверждение (включая правила) в логической форме, которые вместе составляют общую теорию, какую онтология описывает в своей области применение.

События – изменение атрибутов или отношений.

Онтологии обычно кодируются с использованием языков онтологии

В компьютерных наукам да искусственном интеллекте языки онтологии есть формальными языками, что используются для постройки онтологий Они позволяют кодировать знания о конкретных областях и часто включают правила рассуждений, поддерживающих обработку этих знаний. Языки онтологий, как правило, есть декларативными, почти всегда обобщение языков фреймов и обычно основываются на логике первого порядка или на логике описания

Язык веб-онтологии (OWL) – это семья языков представление знаний для авторских онтологий. Онтология является формальным способом описания таксономий и сетей классификации, которые, по сущности, определяют структуру знаний для разных областей: существительные, что представляют классы объектов, и глаголы, что представляют отношения между объектами. Онтологии напоминают иерархии классов в объектно- ориентированном программирование, но есть несколько критических отличий. Иерархии классов назначены для представление структур, что используются в исходном коде, которые развиваются довольно медленно (обычно ежемесячные ревизии), тогда как онтологии должны представлять информацию в Интернете и, как ожидается, будут развиваться почти постоянно. Аналогично, онтологии, как правило, намного более гибкие, поскольку они назначены для представление информации в Интернет, который происходит от различных гетерогенных источников данных. Иерархии классов, с другой стороны, должны быть достаточно статическими и опираться на гораздо менее разнообразные и структурированные источники данных, такие как корпоративные базы данных.

Языки OWL характеризуются формальной семантикой. Они построены на стандарте XML W3C (World Wide Web Consortium) для объектов, которые называются средой описания ресурсов (RDF). OWL да RDF привлекли значительный академический, медицинский и коммерческий интерес.

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

Модель данных RDF похожа на классические концептуальные подходы к моделирование (такие как диаграммы объектных отношений или классов). Она основывается на идеи создание утверждений о ресурсы (в частности, веб-ресурсы) в выражениях формы субъект-предикат-объект. Субъект обозначает ресурс, а предикат обозначает признаки или аспекты ресурса и выражает связь между субъектом и объектом.

Например, один с способов представить понятие «Небо имеет цвет синий» в RDF есть как: субъект, что обозначает "небо", предикат, что обозначает "имеет цвет", и объект, что обозначает "синий". Поэтому RDF использует субъект вместо объекта (или объектной сущности) на отличие от типичного подхода модели объектно- атрибутивного значение в объектно-ориентированному дизайне: сущность (небо), атрибут (цвет) и значение (синий).

RDF – абстрактно модель с несколькими форматами сериализации (есть форматами файлов), поэтому конкретное кодирование ресурсов или троек варьируется от формата в формат.

Этот механизм описания ресурсов есть основным компонентом семантической активности W3C: эволюционный этап всемирной паутины, в котором автоматизированное программное обеспечение может хранить, обменивать и использовать информацию, которая может быть считана, обработана и распространена по всему интернета машиной, в свою очередь, разрешая пользователям иметь дело с информацией с больше эффективностью и уверенностью. Просто модель данных RDF и способность моделировать разрозненные, абстрактные понятия также привели к ее все большего использование в программах управление знаниями, нет связанных с деятельностью Semantic Web.

В современном мире существует много систем для сохранение данных: от записей на бумаги в такие системы хранения данных, как базы данных. Для систематизированного сохранение больших объемов данных очень удобно использовать базы данных, поэтому что они позволяют быстро Найти информацию за заданными критериям.

Базы данных (БД) – организованный набор данных, что сохраняется да может быть доступно в компьютерных системах. Если база данных сложнее, то она разрабатывается с использованием формальных методов проектирование да моделирование. В общем случае база данных имеет схемы, таблицы, представления, сохранены процедуры те другие объекты. Современные базы данных кроме самих данных сохраняет еще и их описание и средства обработки этих данных. Доступ к этим данным обычно обеспечивается «системой управления базами данных».

Система управление базами данных (СУБД) – программный приложение, что складывается с интегрированного набора компьютерных программ, которые позволяют пользователям взаимодействовать с одной или несколькими базами данных и предоставляет доступ ко всем данным, содержащимся в базе данных (хотя могут существовать ограничения доступа к определенных данных).

Программное обеспечение СУБД дополнительно включает в себя основные средства, что позволяют администрировать БД. Совокупность СУБД, базы данных да приложений, что Имеющая связь с базами данных может быть названа «системой баз данных». Часто термин «база данных» также используется для определения любой СУБД, системы баз данных или приложений, связанных с базой данных.

Существующие СУБД обеспечивают различные функции, позволяющие управлять базой данных да ее данным, которые можно классифицировать за четырьмя основными функциональными группами:

И база данных, и ее СУБД соответствуют принципам конкретной модели базы данных. «Система баз данных» ссылается на модель базы данных, систему управление базы данных и базы данных.

Каждая система управление базами данных может быть классифицирована в связи с моделями баз данных, которые она поддерживает. Реляционные базы данные стали доминирующими в 1980-х годах. Эти данные моделируются в виде строк и столбцов в ряде таблиц и в большинства случаев используют SQL запросы для считывание и записи данных. В 2000-х приобрели популярность нереляционные базы данных называются NoSQL, поэтому что они используют разные языки запросов.

NoSQL базы данных обеспечивают механизм для хранения и поиска данных, которые моделируются средствами, отличными от табличных отношений, что используются в реляционных базах данных. Преимуществами NoSQL баз данных является то, что они легкие в проектировании, их легче масштабировать «горизонтально» для кластеризации, на отличие от реляционных БД. Структуры данных, что используются базами данных NoSQL (например, ключ-значение, широкий столбец, график или документ) отличаются от используемых по по умолчанию в реляционных базах данных – это делает некоторые операции более быстрыми в NoSQL, на отличие от реляционных БД. Иногда структуры данных, что используются базами данных NoSQL, также рассматривают как «более гибкие», нож таблицы реляционных баз данных. Базы данных NoSQL все чаще используются в больших данных и веб-приложениях реального времени

Одной из NoSQL баз данных является MongoDB – кросс-платформенная документо- ориентированная база данных. Серверный приложение использует JSON-подобные документы со схемой База данных разработана корпорацией MongoDB Inc. да лицензирована под лицензией Server Side Public Лицензия (SSPL).

Основными функциями да преимуществами MongoDB есть такие возможности:

Выполнение серверного JavaScript кода – JavaScript может использоваться в запросам, функциях агрегации (например, MapReduce) и присылаться непосредственно в базу данных для исполнение.

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

Выводы

Анализ существующих средств хранение информационных ресурсов разрешает заключить, что онтологии и методы организации информации на их основе есть эффективными при стремительному увеличении информационных ресурсов

Онтологические модели хранятся в текстовых форматах, что позволяет их считывать, обрабатывать да записывать за помощью простого программного кода.

Существуют разные программные средства для создание, отображение да редактирование онтологии

Проанализировав структуры моделей хранения информации в базах данных (реляционные да нереляционные), было определено, что для сохранение, систематизации да структуризации цель-описаний наиболее эффективной будет MongoDB.

РАЗДЕЛ 3.

ОНТОЛОГИИ РАБОЧИХ ПРОЦЕССОВ ТА ИХ КОМПОНЕНТОВ

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

Рассмотрим предложенный подход по автоматизации построения рабочих процессов на основе онтологий предметных областей для повышение производительности постройки процессов за счет уменьшение ручной труды да применение математических моделей.

Функциональный сервис (S) – сервис, что принимает на Вход набор данных, выполняет операцию над ими да отдает на выход новые данные. Сохранение функциональных сервисов выполняется с помощью файловой системы, а мета- описания сервисов находятся в базе данных. Все цель-описания функциональных сервисов каждой предметной области сохраняются в отдельных коллекциях базы данных. Сервисы могут быть простыми и сложными.

Рассмотрим модель простого сервиса: S = { Code, M, P } , где:

Code – программный код функционального сервиса

M – цель-описание функционального сервиса

P – физический путь к функционального сервиса

Цель-описание функционального сервиса ( M ) – это описание функции, ее входных и выходных параметров для дальнейшего отображение в пользовательскому интерфейсе да для учет ограничений при построении связей в рабочем процессе.

Цель-описание простого сервиса может быть представлено в виде:

M = { ID, F, {I 1 , … In}, {O 1 , …, On}, T }, где:

M = { ID, F, {I 1 , … I n }, {O 1 , …, O n }, T } – цель-описание, что включает такие параметры:

ID – идентификатор мета-описания, например:

ObjectID(“5cdd4fd0598ec622d023e048”)

F = { N, D, K, P } – множество параметров для описания функционального сервиса;

И и = { N, D, K, T } – множество параметров для описания входных параметров;

O и = { N, D, K, T } – множество параметров для описания выходных параметров, где:

N – название объекта (функционального сервиса, входящего/исходящего параметров), например « checkBankAccount »

D – описание объекту; характеристика вычислительных операций функционального сервиса, например: «Сервис проверяет, существует ли данная карта в банка назначение»

K – удобные для понимания человека ключевые слова для быстрого поиска сервиса или параметров

P – путь к функционального сервиса "./bank/checkBankAccount.js"

T – тип сервиса: "function", "process"; тип переменной «number», «string»… Proc = { CPU, R, t max , … } – описание нефункциональных параметров сервиса, где: C – количество вычислительных ядер, что нужны для исполнение сервиса

R – количество оперативной памяти

t max – максимальный время для исполнение сервиса

… – другие параметры

В автоматизированных системах выполнения рабочих процессов выполняется по с помощью систем управления рабочими процессами и могут быть описаны по помощью диаграмм потока данных.

Формально система управления рабочими процессами может быть представлена в виде:

WfMS = { S r , S d , S c , Sa , _ S ai } , где:

S r – система маршрутизации, выполняет маршрутизацию потока информации или документооборота, передает информацию от одного рабочего элемента к следующего;

S d – система распределения, выявляет исключительные обстоятельства и передает информацию назначенным компонентам системы;

S c – система координации, координирует одновременную деятельность, предотвращая конфликтам ресурсов (выделение процессорного времени и оперативной памяти) или конфликтам приоритетов;

S a – система агентов, автоматически запускает сервис, контролирует его исполнение да получает от него данные;

S ai – система помощников, осуществляет регулировка выборов следующих методов да предоставляет предложения, какой с методов может быть использован следующим.

Компоненты диаграммы потока данных может быть записано в виде:

DFD = { D p , D df , D w , D t } , где:

D p – процесс, часть системы, какая превращает входы в выходы;

D df – поток данных, показывает передачу информации с одной системы на другую;

D w – состав данных, используется для хранение данных для дальнейшего использование

D t – терминал доступа, интерфейс взаимодействия системы с внешним средой.

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

Формально построение рабочего процесса может быть представлено в виде:

P = { ∀ M иск,i ⋂ ∀ M иск,j | ∃ L ij } , где:

P = { ∀ M иск,i ⋂ ∀ M иск,j | L ij } – сгенерированный рабочий процесс, что складывается

из:

где:

М иск = { M зад ⋂ M обл } – выбор сервисов, что использованы в рабочем процессе,

М иск – функциональные сервисы, что использованы в рабочем процессе

M зад – заданные пользователем функциональные сервисы

М обл – функциональные сервисы данной предметной области

L ij = { M вик,i .O = M вик,j .I | VM вык,i .O ∈ V M иск,j .I } – определение связей рабочего

процесса за правилом совместимых входных да выходных параметров, где:

L ij – связи рабочего процесса

M вик,и .O – выходной параметр i-того функционального сервиса M вик,j .I – входной параметр j-того функционального сервиса VM вык,и .O – допустимы значение выходного параметра i-того сервиса VM вик, j.I – допустимы значение выходного параметра j-того сервиса

M обл = { M все ∈ SA } – выбор всех сервисов, что принадлежат предметный области,

где:

M обл – функциональные сервисы заданной предметной области M все – все, доступные в репозитории, функциональные сервисы SA – задана предметная область

Каждый рабочий процесс может быть создано специалистом предметной области по выбранным параметрам функциональных сервисов или выбран среди предложенных системой автоматически сгенерированных вариантов.

Алгоритм формирование рабочих процессов включает в себя такие этапы:

Описание предметной области может быть задано в удобном для специалиста виде за с помощью онтологии.

При импортировании онтологии системой будет проанализировано элементы онтологии и связи между ними После этого собранная информация будет передана в базы знаний.

При входе в веб-интерфейс пользователю будет предложено выбрать текущий бизнес-процесс или создать новый.

При создании нового рабочего процесса пользователю будет предложено выбрать сервисы из репозитория сервисов заданной предметной области, учитывая знание с базы знаний.

Рис 3.2. Условия выбора сервисов

Необходимыми условиями для создания потока данных между функциональными сервисами есть:

L Pij = ∀S f2 P i { ∃S f1 P j | T <Sf2Pi> = T <Sf1Pj> } , где:

L Pij – установлен связь передачи i-того параметра первого сервиса в j-й параметр второго сервиса

S f2 P i – i-й параметр следующего функционального сервиса T <Sf2Pi> – тип и-того параметра следующего функционального сервиса T <Sf2Pj> – тип j-того параметра предыдущего сервиса

∀L Pij { V <Sf1Pj> ∈ V <Sf2Pi> } ,где:

V <Sf1Pj> – допустимы значение выходного параметра первого сервиса

V <Sf2Pi> – допустимы значение входного параметра второго сервиса

Достаточными условиями для создание потока данных между функциональными сервисами есть:

Для более быстрого поиска нужного компонента, каждый сервис имеет описание да ключевые слово в понятному для человека виде.

под время формирование сценарии рабочего процесса пользователем может быть выбрано такие операции сочетания сервисов

Операция последовательного исполнения

Рис 3.3. Операция последовательного исполнение

Операция последовательного выполнения - E con , это операция, описывающая процесс передачи выходных данных одного функционального сервиса на Вход другого функционального сервиса

Тогда математическая модель данной операции будет выглядеть так S f [E con (S f1 , S f2 ]] = { M вх = S f1 M вх , М вых = S f2 M исх }, где:

M вх – входные данные полученного блока M вых – выходные дни данные блока, что будет получено

S f1 M вх – входные данные первого функционального сервиса S f2 M исх – выходные дни данные второго функционального сервиса

Операция параллельного исполнения

Рис 3.4. Операция параллельного исполнение

Операция параллельного выполнения - E par , это операция, описывающая процесс передачи исходных данных одного функционального сервиса на вход нескольких других функциональных сервисов.

Тогда математическая модель данной операции будет выглядеть так S f [E par (S f1 , { S fi })] = { M вх = S f1 M вх , М вых = { S fi M исх } }, где:

M вх – входные данные полученного блока M вых – выходные дни данные блока, что будет получено

S f1 M вх – входящие данные первого функционального сервиса S fi M исх – выходные дни данные других функциональных сервисов

Операция агрегации данных

Рис 3.5. Операция агрегации данных

Операция агрегации данных – E agr , это операция, описывающая процесс передачи выходных данных многих функциональных сервисов на Вход одного функционального сервиса

Тогда математическая модель данной операции будет выглядеть так S f [E agr ({S fi }, S f1 )] = {M вх = { S fi M вх }, М вых = S f1 M исх }, где:

M вх – входные данные полученного блока M вых – выходные дни данные блока, что будет получено

S fi M вх – входные данные каждого функционального сервиса S fi M исх – выходные дни данные последнего функционального сервиса

Операция логического выбора

Рис 3.6. Операция логического выбора

Операция агрегации данных – E sel , это операция, описывающая процесс передачи выходных данных одного функционального сервиса на Вход одного с других функциональных сервисов.

Тогда математическая модель данной операции будет выглядеть так S f [E sel (S f1 , { S fi } )] = { M вх = S f1 M вх , М вых = { S fi M исх | C i } }, где:

M вх – входные данные полученного блока M вых – выходные дни данные блока, что будет получено

S fi M вх – входные данные первого функционального сервиса S fi M исх – выходные дни данные второго функционального сервиса

C i – условие для передачи данных в i-тый функциональный сервис

Тогда процесс построения рабочего процесса можно представить в виде набора функциональных блоков, например:

Рис 3.7. Схематический пример рабочего процесса

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

После подтверждение пользователем сохранение рабочего процесса, последний будет добавлен в базу знаний и будет доступен для выполнения заданий группе пользователей.

Над всеми построенными рабочими процессами могут быть выполнены следующие действия, как:

Примечание: редактирование бизнес-процесса разрешено только создавшему пользователю данный бизнес процесс да специалисту предметной области

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

Рис 3.7. Схема режима отладка

Выводы

Предложено формализованный описание рабочих процессов, какой разрешил учесть ограничение рабочей области и настроить процесс автоматического исполнение да отслеживание состояния этих рабочих процессов

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

Предложен метод автоматизированного построения рабочих процессов, который может быть быстро построен за счет учета ограничений предметной области.

Предлагаемый метод разрешает автоматически редактировать рабочие процессы да создавать новые на основе заданных входных данных, что уменьшить расход времени при исполнении этих действий.

РАЗДЕЛ 4.

ТЕСТИРОВАНИЕ ПРЕДЛОЖЕННОГО ПОДХОДА ПО ПОСТРОЕНИЯ РАБОЧЕГО ПРОЦЕССА НА ПРИМЕРЫ ПОДПИСИ ДОКУМЕНТА

Для рассмотрения примера описания рабочего процесса было предложено да у модель бизнес-процесса подписи документа:

Рис 4.1. Модель бизнес процесса

Данную модель было проанализировано да представлено в виде блок-схемы:

Рис 4.2. Блок-схема рабочего процесса, часть 1

Рис 4.3. Блок-схема рабочего процесса, часть 2

Сервис может быть одного с таких типов:

Функциональный сервис (S executor ) – сервис, принимающий на вход набор данных, выполняет операцию над ими да отдает на выход новые данные. Сохранение функциональных сервисов выполняется с помощью файловой системы, а мета- описания сервисов находятся в базе данных. Все цель-описания функциональных сервисов каждой предметной области сохраняются в отдельных коллекциях базы данных.

Для выбранного рабочего процесса используются следующие функциональные сервисы:

Для сервиса проверки документов выбрана такая модель данных И executor = { I from , И checkBy , I doc , И это }, где:

И от = { N, D, T } N – from

D – инициатор проверки документа

T – User

И checkBy = { N, D, T } N – checkBy

D – лицо, какая должна проверить документ T – User

I doc = { N, D, T }

N – document

D – документ для проверки T – Document

И это = { N, D, T }

N – to

D – сервис, в какой будет передано результат проверки T – Service (S s )

O = { O status , O notes }, где: O status = {N, D, T }

N – status

D – статус проверки документа

T – enum { Approved | Edit | Rejected }

O notes = { N, D, T } N – notes

D – заметки по проверке документа T – string

Для сервиса формирования пакета документов выбрана следующая модель данных: I FormDocumentPack = { И от , I signedBy , I doc , И это }

I signedBy = { N, D, T } N – signedBy

D – лицо, какая подписала документ T – User

Сервис выбора следующего сервиса (S selector ) – микросервис, принимающий на вход один из заранее заданных статусов, данные, которые должны быть переданы в другой сервис да список сервисов для каждого статуса.

В предложенном рабочем процессе использовано такие сервисы селекторы:

Для сервиса выбора сервиса за состоянием проверки документа использована модель

I CheckedSelector = { I status , I data , { StatusHandler 1 , …, StatusHandler n } }, где: I status – enum { Approved | Edit | Rejected }

I data = { Document, Notes } StatusHandler onApprove – Service StatusHandler onEdit – Service StatusHandler onReject – Service

Для сервиса выбора сервиса за состоянием утверждение документа использована модель

I ApprovedSelector = { I status , I data , { StatusHandler 1 , …, StatusHandler n } }, где: I status – enum { Approved | Edit | Rejected }

I data = { Document, Notes } StatusHandler onApprove – Service StatusHandler onEdit – Service StatusHandler onReject – Service

Сервис информатор (S informator ) – сервис, который может проинформировать пользователей системы через выбранный канал связи (email, sms, web-push)

В предложенном рабочем процессе использованы следующие сервисы информаторы:

Для сервиса информирования пользователя через канал электронных сообщений использована такая модель данных:

I MessageSender = { I email , I topic , I message }, где:

И email – электронная почта пользователя для сообщения I topic – тема сообщение

I message – текст сообщения

Для сервиса распространение утвержденных документов выбрана такая модель данных:

I ShareDocuments – { I document , { И target1 , …, И targetn } }, где:

I document – утвержденный документ для распространение

И targetn – целевой пользователь для распространение информации

Сервис утилита (S tool ) – системный сервис для разных типов взаимодействия пользователя и системы

Было определено такие сервисы-утилиты:

Кроме сервисов в всех рабочих процессах существуют роли, право да пользователи.

В системе существуют такие роли:

Для избранного бизнес процесса было использовано такие дополнительные роли:

В каждой роли есть право. Системные право заданные таким списком:

Дополнительно в системе использовано такие роли:

Выводы

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

Протестировано систему на реальном примере рабочего процесса да сформирован пример описания бизнес-процесса и его данных. Описаны разные типы сервисов, что разрешает гибко управлять потоком данных.

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

РАЗДЕЛ 5.

СТАРТАП-ПРОЕКТ

Проведено маркетинговый анализ стартап проекта ради определение принципиальной возможности его рыночного внедрения и возможных направлений реализации этого внедрение.

Продуктом является система автоматизированного построения рабочих процессов на базе онтологии Подробное содержание приведено в таблицы 5.1.

Таблица 5.1

Описание идеи стартап-проекта

Продуктом есть система постройки рабочих процессов, поэтому Дальше будет проведен сравнительный анализ аналогичных проектов. Сравнение производится с следующими проектами-конкурентами:

Определение сильных, слабых и нейтральных характеристик идеи проекта, сравнивая с проектами конкуретов посещено в таблицы 5.2.

Таблица 5.2.

Определение сильных, слабых да нейтральных характеристик идеи проекта

В таблицы 5.3. проводится анализ технологий на основе, которых создается продукт предложенной информационной системы.

Таблица 5.3.

Технологическая выполнимость идеи проекта

Анализ приведенный в таблицы 5.4.

Таблица 5.4.

Предыдущая характеристика потенциального рынке стартап-проекта

Оценив данные, приведенные в таблице можно заключить, что рынок является рентабельным и относительно простым для входа, потому что отсутствуют специальные регуляции да отсутствие монополистов рынке.

В таблицы 5.5 показано особенности конкурентного среды

Таблица 5.5.

Ступенчатый анализ конкуренции на рынке

Продолжение таблицы 5.5.

В таблицы 5.6 приведенный дедальный анализ конкуренции в отрасли.

Таблица 5.6.

Анализ конкуреции в отрасли за М. Портером

на рынке уровень конкуренции нет достаточно высокий, поэтому выход на рынок нет является сложным на данный момент. Но рынок развивается достаточно быстро, поэтому в самый близкий время могут появиться достаточно сильные игроки на рынке, что может усложнить дальнейший развитие стартапа.

Для обеспечение конкурентоспособности проекта необходимо обеспечить скорость разработки, сократить время выполнения операций в системе и разработать систему отзывов клиентов для реализации желаний клиентов и быстрого устранение программных недостатков

Таблица 5.7.

Обоснование факторов конкурентоспособности

Таблица 5.8.

Сравнительный анализ сильных да слабых сторон проекта

Таблица 5.9.

SWOT- анализ стартап-проекта

Выводы

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

Преимуществами разработанного проекта есть бесплатность использование да оплата только за использование локальных ресурсов или облачных технологий.

Кроме того, дана реализация автоматизированной постройки рабочих процессов есть нетребовательной к ресурсам сервера, что позволит сэкономить затраты на оборудование.

ОБЩИЕ ВЫВОДЫ ПО РАБОТЕ

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

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

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

Проанализированы методы построения рабочих процессов рабочих процессов на базе онтологических моделей, которые есть недостаточно автоматизированными или совсем неавтоматизированные.

Предложено метод формирование рабочих процессов на основе входных данных и по правилам соответствия параметров, а также учет областей допустимых значений и принадлежности сервисов к одной предметной области, что позволило повысить эффективность постройки рабочих процессов за счет автоматизации, уменьшение объема ручной труды да за счет использование определенного набора правил постройки связей

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

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

Проанализировано текущие реализации бизнес-процессов да сравнительно разные стороны их реализаций и реализации стартап-проекта для понимания возможностей да препятствий при выходе с проектом на рынок да представление проекта общем круга пользователей.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

/ Kornel Terplan. - New York : Джон Wiley, 2001. – 610 pages. .

техн. ун-т Украины "Киев. политехн. ин-т". - Киев, 2015. - 20 c. - укp..

.pdf. .

<http://www.nist.gov/public_affairs/releases/n0 2 -10.htm> (2002).