РЕФЕРАТ

Работа содержит 70 страниц, 10 рисунков. Было использовано 54

источника. Цифровая экономика, какая есть предпосылкой 4-й индустриальной

революции,

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

глобальном пространстве. Вместе с тем, уровень автоматизации рабочих

процессов, являющихся основой разнообразных сервисов, нет есть

совершенным, их строят в недостаточно автоматизированном режиме из-за

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

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

Цель работы: повысить эффективность постройки рабочих процессов за

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

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

функциональными сервисами на основе онтологической модели, какую легко

корректировать, а также предложенных инструментальных средств постройки да

модификации бизнес процессов

Объект исследование: процесс постройки рабочих процессов в

современных информационных системах под время предоставление

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

Предмет исследования: Математические модели и методы, средства

построения рабочих процессов, а также особенности проектирования

программного обеспечения постройки бизнес-процессы.

Задачи:

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

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

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

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

процессов на основе формализованного описания

Провести экспериментальное исследование предложенного метода

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

помощью средств современных СУБД да методов описания онтологических

моделей.

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

Основные методы исследования общей задачи – формализация,

системный подход и опыт. Методы формализации используются для облегчения

разработки комплекса программного обеспечения Методы системного подхода

– для тестирование исполнение рабочих процессов да их компонентов.

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

системы с другими системами.

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

Проведен обзор и анализ существующих методов построения рабочих

процессов, который позволил заключить, рабочие процессы, которые являются

основой разнообразных сервисов, строят в недостаточно автоматизированном

режиме через отсутствие моделей и математического аппарата, который

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

элементов таких моделей.

Проведено анализ инструментальных средств, что позволяют сохранять

формализованные описания в долгосрочном хранилище данных, показавший

удобство использование нереляционная БД для задач данного типа.

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

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

автоматизированными или совсем неавтоматизированные.

Предложено метод формирование рабочих процессов на основе входных

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

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

что позволило повысить эффективность постройки рабочих процессов за счет

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

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

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

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

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

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

Разработано инструментальные средства ведение реестра

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

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

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

взаимодействия с системой, какой разрешает легко формировать бизнес-

процессы в терминах предметной области

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

процессов Результаты эксперимента показали целесообразность использование

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

нетребовательностью системы к вычислительных ресурсов

Применение предложенного подхода подтверждается прототипом

программного инструментария, обеспечивающего автоматизацию разработки

рабочих процессов, сосредотачиваясь на этапах планирование да

проектирование, учитывая как функциональные, да и нефункциональные

требования, реализуя превращение рабочего процесса независимо от вычислений

в его модель исполнение. Данный подход позволит генерировать бизнес

процессы на основе заданных функциональных сервисов да ограничений

наложенных онтологией предметной области

Публикации:



Построение рабочих процессов на основе онтологии предметной

области

Ключевые слова: онтология, рабочие процессы,

функциональные сервисы, автоматизация процесса.

4 
 
 
 
СОДЕРЖАНИЕ 
ВВЕДЕНИЕ  ................................................................................................................ 13 
РАЗДЕЛ 1  ................................................................................................................... 15 
Обзор рабочих процессов да методов их автоматизированной постройки  ...... 15 
1.1.
 
Обзор методов да инструментов анализа рабочих процессов  ............ 16 
1.2.
 
Средства описания рабочих процессов  ................................................ 19 
1.3.
 
Компонентами диаграммы потока данных есть такие элементы  ...... 21 
Выводы  ............................................................................................................ 22 
РАЗДЕЛ 2  ................................................................................................................... 23 
Онтология  ................................................................................................................... 23 
2.1.
 
Понятие онтологии  ................................................................................. 23 
2.2.
 
Элементы онтологии  ............................................................................... 24 
2.3.
 
Языки онтологий  ..................................................................................... 25 
2.4.
 
Средства хранение данных в цифровом мире  ...................................... 27 
Выводы  ............................................................................................................ 31 
РАЗДЕЛ 3  ................................................................................................................... 32 
Онтологии рабочих процессов да их компонентов  .............................................. 32 
3.1.
 
Формализованный описание функциональных сервисов  ................... 32 
3.2.
 
Формализованное описание инфраструктуры поддержки выполнения 
рабочих процессов  ......................................................................................... 33 
3.3.
 
Автоматизированное построение рабочих процессов с применением 
онтологии  ........................................................................................................ 34 
3.4.
 
Алгоритм формирование рабочего процесса  ....................................... 36 
3.5.
 
Анализ онтологии предметной области  ................................................ 36 
3.6.
 
Выбор пользователем сервисов при создании нового рабочего процесса 
.................................................. .................................................. ....................... 37 
3.7.
 
Операции алгебраической системы расчетов  ....................................... 39 
3.8.
 
Режим отладка  ......................................................................................... 43 
Выводы  ............................................................................................................ 43 

5 
 
РАЗДЕЛ 4  ................................................................................................................... 45 
Тестирование предложенного подхода относительно постройки рабочего 
процесса на примере подписи документа  ............................................................... 45 
4.1. Модель данных  ........................................................................................ 48 
Выводы  ............................................................................................................ 54 
РАЗДЕЛ 5  ................................................................................................................... 56 
Стартап-проект  .......................................................................................................... 56 
5.1.
 
Описание идеи проекта (товара, послушай, технологии)  ................... 56 
5.2.
 
Технологический аудит идеи проекта  .................................................. 57 
5.3.
 
Анализ рыночных возможностей запуска стартап-проекта  ............... 58 
Выводы  ............................................................................................................ 62 
ОБЩИЕ ВЫВОДЫ ПО РАБОТЫ  .......................................................................... 63 
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ  ............................................... 65 

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

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

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

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

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)), широко распространена в индустрии.

1.1

Обзор методов да инструментов анализа рабочих процессов

Краткий обзор методов и инструментов анализа рабочих процессов

показал, что существуют два типы анализа, которые учитывают вычислительный

процесс:

Анализ времени проектирования (моделирование и проверка). Могут

быть использованы средства моделирования Монте-Карло, а также анализ сетей

Петри, поскольку существуют подходы трансформации для BPMN [16], UML

AD [17], EPC [18], BPEL [19] к сетей Петри с их дальнейшим анализом.

Диаграммы USLD могут быть проанализированы за помощью онтологического

анализа услуг [20]

Анализ времени исполнение (например, процесс добычи на основе

журналов выполнение) [21]

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

как Pegasus, Cactus, ASKALON, GLUE и и т.д. [22]. Все упомянутые да

проанализированы текущие возможности для этого этапа задания очень

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

четко описаны в [23]. Центральной критикой есть то, что этап анализа

требований применяется в основном вручную.

В работе [12] рассмотрен алгебра построения рабочих процессов, но это

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

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

дополнительную сложность постройки алгебраической структуры, особенно,

когда система есть территориально распределенной и имеет значительную

постоянно изменяющуюся количество сервисов и рабочих процессов

В работе [20] предложено инструментарий для постройки да анализа

рабочих процессий, но все же таки предложенный подход нет достаточно

автоматизирует само формирование последовательности вычислений в

зависимости от условий и ограничений предметной области

Таким образом, можно заключить, что стратегии адаптации систем под

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

проектирование да реинжиниринга услуг (есть проектирование да модификаций

существующих бизнес- процессов) плохо формализовано и проверено, требуется

несколько итераций за участия аналитиков, системных архитекторов,

значительных расходов времени да ресурсов

Существует достаточно много инструментальных средств для описания

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

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

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

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

рабочих процессов кластеризации цифровых данных в работе [24] предложено

применение онтологических моделей, что позволило именно

в зависимости от характеристик потока входных данных

управлять процессом исполнение вычислений. В данной сфере почти нет

используют онтологии для описания рабочих процессов, хочет онтология

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

визуально отразить его.

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

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

ограничений предметной области, отражающих взаимодействие между ними, а

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

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

интеллектуального среды, на

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

от состояния данных предметной области

Преимуществом онтологического подхода есть то, что онтологическая

модель строится с применением связей в виде графов, разрешая применять

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

режиме реального времени, основываясь на описании входных и выходных

параметров каждого функционального сервиса.

Онтология – описание концепций и отношений в определенной

предметной области, пригоден для автоматизированной обработки. Чаще

онтология сначала описывает базовые элементы предметной области, а потом ее

расширяют к самых маленьких деталей [25]. В онтологии описываются все

связи между этими элементами. Важным фактором является то, что онтологии

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

точки зрения применимости, чем полноты [26].

Рабочий процесс ( workflow ) – схема организации последовательности

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

пользователям. Может включать связанные с ним вычислительные

подпроцессы, информационные зависимости, последовательность принятие

решений, проведение некоторых вычислений.

Для отображения потока работ применяют блок-схему или граф

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

Последовательность исполнение вычислений сказывается стрелки.

Поток работ с информационной точки зрения – способ представления

информации в различных объектов, принимающие участие в рабочем процессе

[10].

Обычно рабочий процесс может быть описан с использованием

формальных или неформальных методов поточных диаграмм, которые

показывают направлены потоки между этапами обработки. Отдельные шаги

обработки или компоненты рабочего процесса могут быть в основном

определены тремя параметрами [27]:



Описание входа: информация, данные да ресурсы, необходимы

для рабочего процесса.



Правила преобразования: алгоритмы, которые

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



Описание выхода: информация, данные да ресурсы, обработаны

рабочим процессом да готовы для передачи в следующие сервисы.

Компоненты могут быть соединены только за условия, если выходная

информация одного компонента отвечает входной информации следующего

компонента, а также удовлетворяет условиям предметной области. Таким

образом, семантическое описание должно включать обязательно описание

входных, исходных данных и цель-описание функциональных сервисов, что

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

(функциональных сервисов) обработки одних и тех же данных, то нужно

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

также желательно указать характеристики эффективности исполнение заданных

функций, такие как: точность, скорость, да другие. [11]

Это связано с тем, что информация, оперирующая рабочий процесс, слабо

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

в зависимости от характеристик потока входных данных. Но с точки зрения

обработки данных, информацию нужно структурировать и обучить систему на

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

разных методов

1.2

Средства описания рабочих процессов

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

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

в процессах, преобразующие данные, предоставляющие услуги или

обрабатывающие информацию. Он может быть изображен как

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

персонала, или один или несколько простых или сложных механизмов.

С более абстрактной или высшей точки зрения рабочий процесс может

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

поток может ссылаться на документ, услугу или продукт, передаваемый с

одного шага на другой.

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

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

такими как информационные технологии, команды, проекты да иерархии.

Система управления рабочими процессами (WfMS) – это программная

система для настройки, выполнения и мониторинга определенной

последовательности процессов и задач, с целями повышения

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

организации. Или системы могут быть ориентированы на процессы или на

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

Система управление рабочим процессом может также включать расширяемый

интерфейс, чтобы внешние программные приложения могли быть

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

которые обеспечивают более быстрый время отзыва да повышение

производительности

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

категории:



Система маршрутизации – это основная функция WfMS. Она выполняет

маршрутизацию потока информации или документооборота, передает

информацию от одного рабочего элемента к следующему. Эта система не

обрабатывает данные.



Система распределения – это функция является расширением. Она обнаруживает

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

компонентам системы. Благодаря динамическом назначению, рабочий процесс

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

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



Система координации – эта функция координирует одновременную

деятельность, предотвращая конфликтам ресурсов (выделение

процессорного времени да оперативной памяти) или конфликтам

приоритетов



Система агентов – это компонент, что автоматически запускает сервис,

контролирует его исполнение да получает от него данные.



Система помощников – этот компонент осуществляет регулировка

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

методов может быть использован следующим. Это основной метод, что

используется в искусственном интеллект.

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

Диаграмма потока данных (ДПД) – это способ представления потока

данных процесса или системы (обычно это информационная система). ДПД

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

субъекта и самого процесса. Диаграмма потока данных не имеет потока

управления, не существует правил принятия решений и нет имеет петель.

Конкретные операции на основе данных могут быть представлены блок-схеме.

Для каждого потока данных по крайней мере одна из конечных точек

(источники и / или назначение) должно существовать в процессе. Уточненное

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

разделяющей этот процесс на подпроцессы

Схема потока данных есть частью инструментов моделирование

структурированного анализа При использовании UML диаграмма деятельности

обычно принимает роль диаграммы потока данных. Особой формой плана

потока данных является план ориентированного на сайт потока данных.

1.3

Компонентами диаграммы потока данных есть такие элементы:

Процесс (процесс) – часть системы, какая превращает входы в выходы.

Символом процесса есть круг, овал, прямоугольник или прямоугольник с

закругленными углами (соответственно к типа обозначение). Процесс

называется одним словом, кратким предложением или фразой, явно

выражающей его сущность.



Поток данных (data flow) – показывает передачу информации из одной

части системы на другую. Символ потока — стрелка. Поток должен иметь

имя, которое определяет, какая информация (или какой материал)

перемещается. Исключения есть потоками, где понятно, какая

информация передается через субъекты, которые связаны с этими

потоками. Поток должен передавать только один тип информации.

Стрелка показывает направление потока. Потоки связывают процессы,

склады и терминаторы



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

дальнейшего использования. Символом хранилища являются две

горизонтальные линии. Имя состава – это множественное

существительное – оно происходит от входящих и выходных потоков

состава. Состав нет должен быть просто файлом данных. Поэтому

просмотр состав в ДПД нет зависит от реализации. Поток со состав

обычно представляет собой чтение данных, хранящихся на складе, а поток

на склад обычно выражает ввод или обновление данных (иногда также

удаление данных). Состав представлен двумя параллельными линиями,

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

как UML-буферный узел).



Терминал доступа (terminator) – это интерфейс взаимодействия системы с

внешним средой (человеком и/или другой системой).

Выводы

В связи с переходом к цифровизации в современном мире

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

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

широко используют рабочие процессы да функциональные сервисы в разных

сферах.

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

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

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

процессов

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

вершина – сервис, а каждая стрелка – поток данных) и диаграмм (набор

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

Для контроля выполнения рабочих процессов существуют системы

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

частности отсутствие поиска функциональных сервисов в в пределах

предметной области.

РАЗДЕЛ 2.

ОНТОЛОГИЯ

В информатике онтология включает представление, формальное

наименование и определение категорий, свойств да отношений между

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

предметные области.

1.1.

Понятие онтологии

Каждый элемент онтологии позволяет ограничить сложность и

организовать информацию в данные да знания. со созданием новой онтологии

надеются улучшить да облегчить решение проблем заданной предметной

области.

Поскольку Google начал инициативу под названием Граф знаний

(Knowledge Graph [27]), значительное количество исследований использовало

графов знаний фразы как обобщенный термин. Несмотря на отсутствие четкого

определения терминов графа знаний, его иногда используют как синоним

онтологии. Одна общая интерпретация состоит в том, что граф знаний является

совокупностью взаимосвязанных описаний сущностей – объектов реального

мира, событий, ситуаций или абстрактных понятий. В отличие от онтологий,

графы знаний, такие как Google Knowledge Graph, часто содержат большие

объемы фактической информации с меньше формальной семантикой. В

некоторых контекстах граф знаний используется для обозначения любой базы

знаний, какая представлена в виде графов.

Общим для онтологий как в информационной науке, да и в философии есть

попытка представить сущности, идеи и события со всеми их взаимосвязанными

свойствами и отношениями в соответствии с системой категорий. В обеих

областях существует значительная работа над проблемами инженерии

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

(например, фундаментализм и когерентность в философии, (BFO и Cyc в

искусственном интеллекте). Прикладная онтология считается духовным

наследником предыдущей работы в философии, однако много нынешних

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

областей.

Искусственный интеллект сохраняет самую большую внимание по

отношению прикладной онтологии в подполье, таких как обработка

естественной языки в машинном переводе да представления знаний, но

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

образование, без намерения внести свой вклад в AI.

1.2.

Элементы онтологии

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

этих классов, их атрибуты и значение этих свойств.

Класс (понятие) – абстрактные группы, коллекции или наборы объектов.

могут содержать в себе экземпляры и/или другие классы.

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

Атрибуты – элементы онтологии, что имеют имя и значение да

используются для хранения информации, присущей конкретному элемент.

Значение атрибута может быть составленным типом данных.

Отношение – важные компоненты онтологии, так как они показывают как

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

обладающий значением есть другой класс.

Функциональные термы – сложные структуры, сформированные с

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

срока в утверждении

Ограничение – формально изложены описания того, что имеет быть

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

данных.

Правила – суждения в виде предложения if-then (если тогда),

описывающих логические выводы, которые можно сделать с утверждение в

определенный форме.

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

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

применение.

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

1.3.

Языки онтологий

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

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

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

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

рассуждений, поддерживающих обработку этих знаний. Языки онтологий, как

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

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

Язык веб-онтологии (OWL) – это семья языков представление знаний для

авторских онтологий. Онтология является формальным способом описания

таксономий и сетей классификации, которые, по сущности, определяют

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

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

Онтологии напоминают иерархии классов в объектно- ориентированном

программирование, но есть несколько критических отличий. Иерархии классов

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

которые развиваются довольно медленно (обычно ежемесячные ревизии), тогда

как онтологии должны представлять информацию в Интернете и, как

ожидается, будут развиваться почти постоянно. Аналогично, онтологии, как

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

информации в Интернет, который происходит от различных гетерогенных

источников данных. Иерархии классов, с другой стороны, должны быть

достаточно статическими и опираться на гораздо менее разнообразные и

структурированные источники данных, такие как корпоративные базы данных.

Языки OWL характеризуются формальной семантикой. Они построены на

стандарте XML W3C (World Wide Web Consortium) для объектов, которые

называются средой описания ресурсов (RDF). OWL да RDF привлекли

значительный академический, медицинский и коммерческий интерес.

RDF сначала разработана как модель данных метаданных. Он стал

использоваться в качестве общего метода для концептуального описания или

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

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

программах управление знаниями.

Модель данных RDF похожа на классические концептуальные подходы к

моделирование (такие как диаграммы объектных отношений или классов). Она

основывается на идеи создание утверждений о ресурсы (в частности, веб-

ресурсы) в выражениях формы субъект-предикат-объект. Субъект обозначает

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

между субъектом и объектом.

Например, один с способов представить понятие «Небо имеет цвет синий»

в RDF есть как: субъект, что обозначает "небо", предикат, что обозначает "имеет

цвет", и объект, что обозначает "синий". Поэтому RDF использует субъект

вместо объекта (или объектной сущности) на отличие от типичного подхода

модели объектно- атрибутивного значение в объектно-ориентированному

дизайне: сущность (небо), атрибут (цвет) и значение (синий).

RDF – абстрактно модель с несколькими форматами сериализации (есть

форматами файлов), поэтому конкретное кодирование ресурсов или троек

варьируется от формата в формат.

Этот механизм описания ресурсов есть основным компонентом

семантической активности W3C: эволюционный этап всемирной паутины, в

котором автоматизированное программное обеспечение может хранить,

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

обработана и распространена по всему интернета машиной, в свою очередь,

разрешая пользователям иметь дело с информацией с больше эффективностью и

уверенностью. Просто модель данных RDF и способность моделировать

разрозненные, абстрактные понятия также привели к ее все большего

использование в программах управление знаниями, нет связанных с

деятельностью Semantic Web.

1.4.

Средства хранение данных в цифровом мире

В современном мире существует много систем для сохранение данных: от

записей на бумаги в такие системы хранения данных, как базы данных. Для

систематизированного сохранение больших объемов данных очень удобно

использовать базы данных, поэтому что они позволяют быстро Найти

информацию за заданными критериям.

Базы данных (БД) – организованный набор данных, что сохраняется да

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

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

моделирование. В общем случае база данных имеет схемы, таблицы,

представления, сохранены процедуры те другие объекты. Современные базы

данных кроме самих данных сохраняет еще и их описание и средства

обработки этих данных. Доступ к этим данным обычно обеспечивается

«системой управления базами данных».

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

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

позволяют пользователям взаимодействовать с одной или несколькими базами

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

(хотя могут существовать ограничения доступа к определенных данных).

Программное обеспечение СУБД дополнительно включает в себя

основные средства, что позволяют администрировать БД. Совокупность СУБД,

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

названа «системой баз данных». Часто термин «база данных» также

используется для определения любой СУБД, системы баз данных или

приложений, связанных с базой данных.

Существующие СУБД обеспечивают различные функции, позволяющие

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

четырьмя основными функциональными группами:



Определение данных – создание, модификация и удаление определений,

что определяют организацию данных.



Обновление – вставка, модификация да удаление фактических данных.



Получение информации – получение информации в форме,

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

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

базе данных или в новой форме, полученной путем изменения или

объединения существующих данных из базы данных.



Администрирование – регистрация и мониторинг пользователей,

обеспечение безопасности данных, мониторинг производительности,

поддержание целостности данных, борьба с контролем параллелизма и

восстановление информации, которая была повреждена некоторой

событием, например, неожиданной отказом системы.

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

базы данных. «Система баз данных» ссылается на модель базы данных, систему

управление базы данных и базы данных.

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

в связи с моделями баз данных, которые она поддерживает. Реляционные

базы данные стали доминирующими в 1980-х годах. Эти данные моделируются

в виде строк и столбцов в ряде таблиц и в большинства случаев используют SQL

запросы для считывание и записи данных. В 2000-х приобрели популярность

нереляционные базы данных называются NoSQL, поэтому что они используют

разные языки запросов.

NoSQL базы данных обеспечивают механизм для хранения и поиска

данных, которые моделируются средствами, отличными от табличных

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

NoSQL баз данных является то, что они легкие в проектировании, их легче

масштабировать «горизонтально» для кластеризации, на отличие от

реляционных БД. Структуры данных, что используются базами данных NoSQL

(например, ключ-значение, широкий столбец, график или документ) отличаются

от используемых по по умолчанию в реляционных базах данных – это делает

некоторые операции более быстрыми в NoSQL, на отличие от реляционных БД.

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

рассматривают как «более гибкие», нож таблицы реляционных баз данных.

Базы данных NoSQL все чаще используются в больших данных и веб-

приложениях реального времени

Одной из NoSQL баз данных является MongoDB – кросс-платформенная

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

JSON-подобные документы со схемой База данных разработана корпорацией

MongoDB Inc. да лицензирована под лицензией Server Side Public Лицензия

(SSPL).

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

возможности:



Специальные запросы – MongoDB поддерживает поля, поиски за

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

выражений. Запросы могут возвращать конкретные поля документов, а

также включать определены пользователем функции JavaScript. Запросы

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

результатов заданного размера.



Индексация – поля в документе MongoDB могут быть индексированные

за помощью первичных и вторичных индексов.



Репликация – MongoDB обеспечивает высокую доступность данных за

помощью репликации данных Набор реплик состоит из двух или более

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

первичной или вторичной. реплики в любое время. Все запросы чтения и

записи выполняются по по умолчанию на первичной реплике. Вторичные

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

встроенной репликации Когда жемчужина реплика не доступна, другие

реплики автоматически проводят «голосование», чтобы определить, какая

вторичная реплика должна стать первичной. За с помощью отдельных

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

повышение производительности.



Балансировка нагрузки – MongoDB масштабируется горизонтально,

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

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

работать на нескольких серверах, балансируя нагрузку или дублируя

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

оборудование.



Хранилище данных – MongoDB может быть использовано как файловая

система, называемая GridFS, с функциями балансировки нагрузки и

репликации данных на нескольких машинах для хранение файлов.



Агрегация – MongoDB предоставляет три способы исполнение агрегации:

консолидационный конвейер (the aggregation pipeline), функция map-

reduce и методов агрегации для одного назначение (and single-purpose

aggregation).

Выполнение серверного JavaScript кода – JavaScript может использоваться в

запросам, функциях агрегации (например, MapReduce) и присылаться

непосредственно в базу данных для исполнение.



Ограниченные коллекции – MongoDB поддерживает коллекции с

фиксированными размерами, которые называются ограниченными

коллекции. Этот тип коллекции поддерживает порядок вставки и, как

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

Наиболее существенными преимуществами системы баз данных MongoDB

есть то, что она поддерживает иерархическую модель данных, какая имеет

предоставляет более эффективный Поиск да разрешает гибко

модифицировать схемы хранение документов.

Выводы

Анализ существующих средств хранение информационных ресурсов

разрешает заключить, что онтологии и методы организации информации на их

основе есть эффективными при стремительному увеличении информационных

ресурсов

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

считывать, обрабатывать да записывать за помощью простого программного

кода.

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

редактирование онтологии

Проанализировав структуры моделей хранения информации в базах

данных (реляционные да нереляционные), было определено, что для сохранение,

систематизации да структуризации цель-описаний наиболее эффективной будет

MongoDB.

РАЗДЕЛ 3.

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

В многих случаях одну и ту же задачу можно решить разными методами.

Характер обработки данных определяется вероятностными свойствами

наблюдений, проведенных на некоторых данных, поэтому для описания всех

правил установление связей на основе входных данных с целью определения

наиболее эффективного метода решения одной и той же задачи может быть

использован онтологию

3.1.

Формализованный описание функциональных сервисов

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

процессов на основе онтологий предметных областей для повышение

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

применение математических моделей.

Функциональный сервис (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 – максимальный время для исполнение сервиса

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

3.2.

Формализованный описание инфраструктуры поддержки

исполнение рабочих процессов

В автоматизированных системах выполнения рабочих процессов

выполняется по с помощью систем управления рабочими процессами и могут

быть описаны по помощью диаграмм потока данных.

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

быть представлена в виде:

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 – терминал доступа, интерфейс взаимодействия системы с

внешним средой.

3.3.

Автоматизированная построение рабочих процессов с

применением онтологии

Для постройки рабочего процесса нужно выполнить операцию

пересечения каждый с каждым для всех сервисов за условия существование

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

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

совпадения данных с их мета-описаниями в сервисе.

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

виде:

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.4.

Алгоритм формирование рабочего процесса

Каждый рабочий процесс может быть создано специалистом предметной

области по выбранным параметрам функциональных сервисов или выбран

среди предложенных системой автоматически сгенерированных вариантов.

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

Анализ онтологии предметной области да функциональных

сервисов системой и хранение этих данных в базу данных

Выбор пользователем сервисов, что будут использованы в рабочем

процессе, среди доступных сервисов в базе знаний с помощью веб-

интерфейса

Формирование системой сценария исполнение рабочего процесса на

основе набора сервисов и правил сочетания этих сервисов, заданных

специалистом или предметной областью да хранение рабочего

процесса в базу данных

3.5.

Анализ онтологии предметной области

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

специалиста виде за с помощью онтологии.

При импортировании онтологии системой будет проанализировано

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

будет передана в базы знаний.

3.6.

Выбор пользователем сервисов при создании нового рабочего

процесса

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

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

При создании нового рабочего процесса пользователю будет предложено

выбрать сервисы из репозитория сервисов заданной предметной области,

учитывая знание с базы знаний.

Рис 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.7.

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

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

быть выбрано такие операции сочетания сервисов

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

Рис 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.8.

Режим отладки

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

возможность просматривать, редактировать и временно хранить проходящие

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

исполнение рабочего процесса.

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

Выводы

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

разрешил учесть ограничение рабочей области и настроить процесс

автоматического исполнение да отслеживание состояния этих рабочих

процессов

Разработано формализованный описание предметной области, что

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

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

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

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

который может быть быстро построен за счет учета ограничений предметной

области.

Предлагаемый метод разрешает автоматически редактировать рабочие

процессы да создавать новые на основе заданных входных данных, что

уменьшить расход времени при исполнении этих действий.

РАЗДЕЛ 4.

ТЕСТИРОВАНИЕ ПРЕДЛОЖЕННОГО ПОДХОДА ПО ПОСТРОЕНИЯ

РАБОЧЕГО ПРОЦЕССА НА ПРИМЕРЫ ПОДПИСИ ДОКУМЕНТА

Для рассмотрения примера описания рабочего процесса было

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

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

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

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

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

4.1.

Модель данных

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



Executor – исполнитель, функциональный сервис;



Selector – избиратель, сервис выбора следующего сервиса;



Collector – сборщик, сервис объединение данных одного типа за

областью допустимых значений



Informator – информатор, сервис , отправляющий

сообщения пользователю;



Tool – утилита, системный сервис для взаимодействий разных видов;

4.1.1.

Функциональный сервис

Функциональный сервис (S executor ) – сервис, принимающий на вход набор

данных, выполняет операцию над ими да отдает на выход новые данные.

Сохранение функциональных сервисов выполняется с помощью файловой

системы, а мета- описания сервисов находятся в базе данных. Все цель-описания

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

отдельных коллекциях базы данных.

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

функциональные сервисы:



DocumentChecker – сервис проверки документов пользователями



FormDocumentPack – сервис формирование пакета документов для

распространение в системе

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

данных

И executor = { I from , И checkBy , I doc , И это }, где:

И от = { N, D, T }

N – from

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

T – User

И checkBy = { N, D, T

} N – checkBy

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

T – User

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

4.1.2.

Сервис выбора следующего сервиса

Сервис выбора следующего сервиса (S selector ) – микросервис,

принимающий на вход один из заранее заданных статусов, данные, которые

должны быть переданы в другой сервис да список сервисов для каждого

статуса.

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



CheckedSelector – сервис обработки состояния проверки документа



ApprovedSelector – сервис обработки состояния утверждение документа

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

использована модель

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

4.1.3.

Сервис информатор

Сервис информатор (S informator ) – сервис, который может

проинформировать пользователей системы через выбранный

канал связи (email, sms, web-push)

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

сервисы информаторы:



MessageSender – сервис информирования пользователя

через канал электронных сообщений



ShareDocuments – сервис распространения

утвержденных документов пользователям через систему web-push

Для сервиса информирования пользователя через

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

данных:

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

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

topic – тема сообщение

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

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

модель данных:

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

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

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

4.1.4.

Сервисы взаимодействия с пользователем

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

взаимодействия пользователя и системы

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



WorkflowBuilder – постройщик рабочего процесса



WorkflowExecutor – исполнитель рабочего

процесса Да такие сервисы-интерфейсы:



Веб-сервис для авторизации пользователя системы



Веб-интерфейс для взаимодействия пользователя с компонентами

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



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

построены рабочие процессы в понятному для человека виде

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

пользователи.

4.2.

Объекты рабочего процесса

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



Administrator – администратор системы



Специалист – специалист в определенный предметный области



User – пользователь системы

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

роли:



User – пользователь, что может подавать запросы на подпись

документов



Checker – пользователь, что проверяет документы



Arbiter – пользователь, что согласовывает документы



Approver – пользователь, что утверждает документы



CEO – директор



Supervisor – пользователь, который может

распространять утвержденные документы

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



Read – пользователь системы имеет право просматривать сервисы да

процессы



Edit – пользователь системы имеет право на редактирование

метаданных сервисов да рабочих процессов



CreateWorkflow – пользователь имеет право на создание новых

бизнес процессов



ChangeRoles – пользователь имеет право изменять

роли других пользователей

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



Check – пользователь с данным разрешением имеет возможность

проверять документы



View – пользователь имеет возможность просматривать документы



Edit – пользователь имеет возможность редактировать документы



Approve – пользователь имеет возможность утверждать документы



Sign – пользователь имеет право утверждать и

подписывать документы



Share – пользователь имеет право на распространение документов

Выводы

Для хранение цель-описаний функциональных сервисов, получение этих

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

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

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

сформирован пример описания бизнес-процесса и его данных. Описаны разные

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

Предлагаемый подход протестировано на примере алгоритма рабочего

процесса подписи документа, показавшего уменьшение времени на

формирование бизнес процесса и позволил более понятно визуализировать

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

РАЗДЕЛ 5.

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

Проведено маркетинговый анализ стартап проекта ради определение

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

направлений реализации этого внедрение.

5.1.

Описание идеи проекта (товара, послушай, технологии)

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

процессов на базе онтологии Подробное содержание приведено в таблицы 5.1.

Таблица 5.1

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

Содержа

ние идеи

Направлени

я применение

Польза для

пользовател

Идея состоит в повышении

эффективности

1. Учебные

Система

построения рабочих процессов

за счет

заведения

распространение

автоматизации, уменьшение объема

ручной

сообщений

труда и за счет

использования

пользователям от

определенного набора правил

построения

преподавателей

связей между функциональными сервисами

на

2. Автоматизация

Постоянно

повторяющиеся

основе онтологической модели,

которую легко

сложных

расчеты по

корректировать, а также

предложенных

расчетов на

одинаковыми схемами

инструментальных средств построения и

основе заданных

будут занимать

модификации бизнес процессов

математических

намного меньше

времени в

правил

пользователя

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

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

производится с следующими проектами-конкурентами:



Microsoft SharePoint;



UML;

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

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

Таблица 5.2.

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

№

п/п

Технико-

экономические

характеристики

идеи

(потенциальные)

товары/концепции

конкурентов

(слабо

сторона)

(нейтрально

сторона)

(сильная

сторона)

Мой

проект

Microsoft

SharePoint

UML

Стоимость

обслуживание

Низкая

Высокое.

Низкая

да

Стоимость

эксплуатации

Низкая

Средняя

Низкая

да

Оценочная скорость

работы

Высока

Средняя

да

Достоверность

потери данных

Низкая

Средняя

да

Безотказность

Высока

Низкая

Высокая

да

Безопасность

использовани

Высока

Средняя

да

Удобство

взаимодействия с

промежуточными

данным

Высока

Средняя

да

Удобство

использовани

Высока

Средняя

да

5.2.

Технологический аудит идеи проекта

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

продукт предложенной информационной системы.

Таблица 5.3.

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

№

п/п

Идея

проекта

Технологии

ее

реализаци

Наличие

технологи

Доступност

технологий

Анализ

онтологии

предметно

й области

Онтологические

модели сохранены в

обще- определенном

формате OWL

Технология

доступна и доступна

для использование

Технология есть

доступной и

стандарт открытый

Система

хранение

данных

Использовано

нереляционную БД,

как пример –

бесплатная СУБД

MongoDB

Технология

доступна и

бесплатная для

использование

Технология

есть

доступной

Построен

ие

рабочих

процессо

Собственная

реализация

системы

позволяет гибко

управлять

системой

Технологии будет

представлено в виде

проекта с открытым

кодом после

патентование

Технология

доступна

разработчикам и

альфа-

пользователям

5.3.

Анализ рыночных возможностей запуска стартап-проекта

5.3.1.

Анализ спроса

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

Таблица 5.4.

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

№

п/п

Показатели состояния рынке

(наименование)

Характеристика

Общий объем продажа, грн/усл.ед

Данные

отсутствуют

Динамика рынке (качественно оценка)

Растет

Наличие ограничений для входа (указать

характер ограничений)

Технологические

Специфические требования к

стандартизации да сертификации

Отсутствуют

Средняя норма рентабельности в отрасли (или

по рынке), %

Отсутствуют

Оценив данные, приведенные в таблице можно заключить, что рынок

является рентабельным и относительно простым для входа, потому что

отсутствуют специальные регуляции да отсутствие монополистов рынке.

5.3.2.

Анализ предложения

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

Таблица 5.5.

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

Особенности

конкурентного

среды

В чем проявляется данная

характеристика

Воздействие на

деятельность

предприятия

(возможны действия

компании, чтобы быть

конкурентоспособной)

1. Тип конкуренции

есть чистым, пока не

сформировался рынок

и нет

образовались

олигополии

Отсутствие доминирующих

игроков на рынке, или если

таковые есть, то слишком

перегружены

Быстрое развитие и

реализация

дополнительных

возможностей в

проекте

2. Уровень

конкурентной борьбы

есть

межнациональным

Распространение проекта

достаточно простым, так как

реализация может быть

развернутая локально.

Быстрое распространение

на зарубежные рынки сбыта

и в корпорациях.

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

3. Конкуренция

есть отраслевой

Решение данной проблемы

может быть выполнено только в

информационной сфере

Обязательная реакция на

отзывы пользователей для

улучшение качества

продукта

4. Конкуренция

за видами товаров

являются

товарно-видовой.

Проявляется в желании создать

бесплатный и удобный для

пользователя продукт

Увеличение скорости

разработки.

5. Характером

конкурентных

преимуществ есть

неценовой

Использование технологии

приобретают популярность и

могут быть интересные

пользователю.

Акцентированное внимание

на ускоренные постройки

рабочих процессов для

уменьшение затраченного

времени пользователей.

6. За

интенсивности

конкуренция есть

немарочной

Каждый продукт использует

разные технологии решение

проблемы.

Обеспечение конкерентной

преимущества за счет

ускоренного процесса

разработки и тестирование.

5.3.3.

Анализ условий конкурецких в отрасли

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

Таблица 5.6.

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

Прямые

конкуренты

в отрасли

Потенциал

ьные

конкурент

Поставщики

Клиенты

Товары-

замените

ли

Навести

список прямых

конкурентов

Определить

барьеры

вхождение в

рынок

Определить

факторы силы

поставщиков

Определи

ть

факторы

силы

потребите

лей

Фактор

ы угроз с

стороны

замените

лей

на данный

Возможность

входа

Проект

Пользовател

момент на

на рынок есть, за

базируется

только

нет ставят

рынке есть

достаточно

помощью

на собственных

условия для

большие

игроки,

продукта, что

разработках да

разработки,

хочет они

будет удобным в

разработках с

поэтому что

имеют

использовании да

открытым

проектов в

реализацию,

что

быстрым при

кодом.

заданной

нет

исполнении, а

сфере

удовлетворяет

также

немного.

большинство

будет нуждаться

пользователей.

немного ресурсов

для исполнение

на рынке уровень конкуренции нет достаточно высокий, поэтому выход на

рынок нет является сложным на данный момент. Но рынок развивается

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

достаточно сильные игроки на рынке, что может усложнить дальнейший

развитие стартапа.

Для обеспечение конкурентоспособности проекта необходимо обеспечить

скорость разработки, сократить время выполнения операций в системе и

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

быстрого устранение программных недостатков

5.3.4.

Факторы конкурентоспособности показано в таблицы 5.7.

Таблица 5.7.

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

№

п/п

Фактор

конкурентоспособности

Обоснование (наведение факторов,

что делают фактор для сравнение

конкурентных проектов

значимым)

Стоимость эксплуатации

Проект бесплатный, пользователи

могут развернуть его на своих

серверах или на облачных сервисах,

что

позволит минимизировать

расходы на обслуживание

Безопасность использование

Благодаря поэтому, что проект

развернуто локально, все данные

пользователей сохраняются

исключительно локально

Удобство

взаимодействия с

промежуточными

данным

В системе имеется среда отладка

процессов, что разрешает хранить и

редактировать промежуточные

результаты в удобном для

пользователя виде

Удобство использование

Взаимодействие с системой

происходит за с помощью веб-

интерфейса разрешает пользоваться

ею на будь

котором современном устройства

5.3.5.

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

Таблица 5.8.

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

№

п/п

Фактор

конкурентоспособности

Балл

ы 1-

Рейтинг товаров-конкурентов

в сравнить с собственным

продуктом

–3

–2

–1

Стоимость обслуживание

Стоимость эксплуатации

Оценочная скорость работы

Достоверность потери данных

Безотказность

Безопасность использование

Удобство

взаимодействия с

промежуточными

данным

Удобство использование

5.3.6.

SWOT-

анализ

Таблица 5.9.

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

Сильные стороны:

дешевизна эксплуатации

гибкость системы,

автоматизированная

построение процессов

Слабый стороны:

необходимы онтологии

предметных областей,

нужен специалист предметной

области

Возможности:

быстрое создание рабочих

процессов

небольшие системные требования

возможность развернуть локально.

Угрозы:

уменьшение спроса на продукт,

появление конкурентов на рынке

Выводы

Проанализированные возможности развития стартап-проекта

показывают, что выйти на рынок на данный момент возможен, хотя в

ближайшее время могут появиться новые конкуренты, поэтому систему

нужно развивать стремительно.

Преимуществами разработанного проекта есть бесплатность

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

облачных технологий.

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

процессов есть нетребовательной к ресурсам сервера, что позволит сэкономить

затраты на оборудование.

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

В работе предложено автоматизированную построение рабочих процессов

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

и рабочих процессов, а также операции автоматизированного формирования

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

онтологическими моделями.

Проведен обзор и анализ существующих методов построения рабочих

процессов, который позволил заключить, рабочие процессы, которые являются

основой разнообразных сервисов, строят в недостаточно автоматизированном

режиме через отсутствие моделей и математического аппарата, который

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

элементов таких моделей.

Проведено анализ инструментальных средств, что позволяют сохранять

формализованные описания в долгосрочном хранилище данных, показавший

удобство использование нереляционная БД для задач данного типа.

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

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

автоматизированными или совсем неавтоматизированные.

Предложено метод формирование рабочих процессов на основе входных

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

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

что позволило повысить эффективность постройки рабочих процессов за счет

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

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

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

процесса можно ускорить построение бизнес-процессов, что позволит

минимизировать расходы времени пользователя за счет уменьшение объема

ручной труды да за счет использование определенного набора правил

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

онтологической модели, какую легко корректировать, а также предложенных

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

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

репозиторию сервисов и бизнес-процессов за счет ввода и использования

ключевых слов да привязанности сервиса к предметной области.

Проанализировано текущие реализации бизнес-процессов да

сравнительно разные стороны их реализаций и реализации стартап-проекта для

понимания возможностей да препятствий при выходе с проектом на рынок да

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

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

Бокай А: Построение онтологических моделей FaaS-сервисов

Четвертая индустриальная революция [Электронный ресурс] // Режим

доступа: https:// www.ukrinform.ru/rubric-society/2385951-ukraina-perehodit-

na- cifrovuu-ekonomiku-cto-eto-oznacaet.html.

Кот. Т: Метод проектирование потоков задач в системе OSS/BSS, 2011, 159с.

Kornel Terplan. OSS Essentials: Support System Solutions for Service Providers

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

Business процесс Model and Notation [Электронный ресурс] // Режим

доступа: http://www.omg.org/spec/BPMN/2.0/.

http://www.internet-of-services.com/index.php?id=264.

erwin Business Process [Электронный ресурс] // Режим доступа:

https://erwin.com/products/erwin-business-process/.

Sparx Systems [Электронный ресурс] // Режим доступа:

http://www.sparxsystems.com/products/index.html.

Visio [Электронный ресурс] // Режим доступа:

http://office.microsoft.com/en- us/visio/.

10.

Workflow Patterns [Электронный ресурс] // Режим доступа:

http://www.workflowpatterns.com/.

11.

Workflow Automation [Электронный ресурс] // Режим доступа:

https://web.archive.org/web/20130907014418/http:/nocsmart.com/index.php?o

ption=com_content&view=article&id=17&Itemid=135.

12.

Информационная технология создание да поддержки порталов

инженерных знаний : автореф. дис. канд. техн. наук : 05.13.06 / Р. Л.

Новогрудская; Нац.

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

13.

Advanced Approach to Web Service Composition.

14.

Грабустс П.С. КОНЦЕПЦИЯ ОНТОЛОГИИ ОСНОВАННАЯ НА

ЗНАНИЯХ ДЛЯ КЛАСТЕРИЗАЦИИ ЧИСЛОВЫХ ДАННЫХ, Open

Semantic Technologies for Intelligent Systems.

15.

Egon Börger. Применить к моделированию бизнес-процессов: a critical

analysis of BPMN, workflow patterns and YAWL, Springer, September 2011.

– 14 pages..

16.

Transformation of BPMN models for Behaviour Analysis:

http://www.win.tue.nl/~jmw/_media/public/transformationforbehaviouranalysis

.pdf. .

17.

Baresi, L.; Pezzè, M.: На formalizing UML с высоким уровнем Petri Nets. In:

Agha, GA; De Cindio, F.; Розенберг, Г.: См. Vol. 2001: Конкурентный

объект-ориентированный программирование и петри Nets, Advances in

Петри Nets, pages 276-304.

18.

Nuttgens, M.; Feld, T.; Zimmermann, V. Business Process Modeling with EPC

and UML: Transformation or Integration? // in: Schader, M.; Кортхаус, A.

(Hrsg.): The Unified Modeling Language - Technical Aspects and Applications,

Proceedings (Маннхайм, Октябрь .

19.

Ouyang, C., Verbeek, E., Aalst van der, WMP, Breutel, S., Dumas, M.,

Hofstede ter, AH.: Формальные семантики и аналитика контроля пульса в

WS- BPEL. Technical report (revised version), Queensland University of

Technology (октябрь 2005).

20.

Абдукальиков, R. CSE Dept., Concordia Univ., Монреаль, QC, Canada Hussain,

; Kassab, M. ; Орманджева, О.” Quantifying the Impact of Different Non-

functional Requirements and Problem Домов on Software Effort Estimation”.

21.

Ian J. Taylor. Workflows for e-Science, Scientific Workflows for Grids / Ian J.

Taylor, Ewa Deelman, Dennis B. Gannon, Matthew Shields. - Springer; 1st

Edition, 2006.- 552 pages..

22.

W. van der Aalst. BPM и Workflow Analysis. BPTrends, 5(4): 1-2, Апрель

2007.

23.

Kot, T., Reverchuk, A., Globa, L., Schill, A. (2012): A novel approach to

increase efficiency of OSS/BSS workflow planning and design. BIS 2012

Конференция. Springer, May 2012.

24.

National Institute of Standards and Technology. “Software Errors Cost US

Экономия $59.5 Billion Annually” (NIST 2002–10).

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

25.

What is an Ontology? [Электронный ресурс] // Режим доступа: http://www-

ksl.stanford.edu/kst/what-is-an-ontology.html.

26.

Negru, Stefan; Лохманн, Steffen; Haag, Florian (7 April 2014) "VOWL: Visual

Notation for OWL Ontologies" [Электронный ресурс]. Режим доступа:

http://vowl.visualdataweb.org/v2/.

27.

Michael L. Pinedo (7 January 2012) “Scheduling: Theory, Algorithms, and

Systems”: https://books.google.com/books?id=QRiDnuXSnVwC.

28.

Introducing the Knowledge Graph [Электронный ресурс] // Режим доступа:

https://googleblog.blogspot.com/2012/05/introducing-knowledge-graph-things-

not.html.

29.

Patel-Schneider, Peter F.; Horrocks, Ian; Patrick J., Hayes (2004-02-10). "OWL

Web Ontology Language Semantics and Abstract Syntax". http s://www.w3.or

g/TR /2004/REC-owl-semantics-20040210/syntax.html.

30.

OWL 2 Web Ontology Language Document Overview (Second Edition)

[Электронный ресурс]. Режим доступа: https:// www.w3.org/TR/owl2-

overview/.

31.

RDF Schema 1.1 [Электронный ресурс]. Режим доступа: https://

www.w3.org/TR/rdf-schema/.

32.

WebStotm - The smartest JavaScript IDE (integrated development environment)

[Электронный ресурс] // Режим доступа:

http s://www.jetbrains.com/websto rm/.

33.

Node.js® - As an asynchronous event driven JavaScript runtime, Node is

designed to построить scalable network applications [Электронный ресурс] //

Режим доступа: https://nodejs.org/.

34.

What is MongoDB? [Электронный ресурс] // Режим доступа: https://

www.mongodb.com/what-is-mongodb.

35.

Protégé - Free, open-source ontology editor and framework for строительство

intelligent systems [Электронный ресурс] // Режим доступа:

http://protege.stanford.edu.

36.

Musen, Mark (2015). "The Protégé Project: A Look Back and a Look Forward".

AI Matters. 1 (4): 4–12. doi:10.1145/2757001.2757003 https ://www. ncbi

.nlm.nih.gov/pmc/articles/PMC4883684/.

37.

Kot T. Applying business process modeling method when Telecommunication

services development / Kot T., Globa L., Schill A. // 21-st International Crimean

Конференция "Crimico'2011". Конференция materials. - Sevastopol, Crimea,

Украина - 2011 - Vol.1 - P.457.

38.

Ouyang C. From Business процесс Models to Process-Oriented Software

Systems / C. Ouyang, WMP van der Aalst, M. Dumas, AHM ter Hofstede, J.

Mendling // ACM Transactions on Software Engineering and Methodology

2009 - Vol.19 - P. 1-37..

39.

Kot, T., Reverchuk, A., Globa, L., Schill, A. Метод of non-functional

requirements balancing when service разработка. Proceedings of the

International Multi-Conference ACS-AISBIS на Szczecin, Poland, May-June

2012, 9 pp.

40.

Kot T., Globa L., Schill A. Applying business process modeling method when

telecommunication services разработка. – Microwave and Telecommunication

Technology (CriMiCo), 2011, 21-st International Crimean Конференция.

Процессы. – Sevastopol, Украина, 20.

41.

Ryan KL Ko. Business Process Management (BPM) Стандарты: A Survey /

Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee. - Business процесс

Management Journal, Emerald Group Publishing Limited. Volume 15 Issue 5.

(2009). – 48 p..

42.

J. Mendling, KB Lassen, U. Zdun: "On the Transformation of Control Flow

между Block-Oriented and Graph-Oriented Process Modeling Languages."

IJBPIM. Special Issue on Model-Driven Engineering of Executable Business

процесс Models., vol. 3, num. 2, pp. .

43.

J. Mendling, K. Lassen, U. Zdun: "Transformation Strategies between Block-

Oriented and Graph-Oriented Process Modelling Languages ." MKWI 2006,

Band 2, XML4BPM Track, GITO-Verlag Berlin, 2006, ISBN 3-936771-62-6,

pp. 297-312.

44.

http://www.softwareag.com/corporate/products/aris_platform/default.asp.

45.

Quan Tran “NFR-Assistant: Tool support for achieving quality”, Application-

Specific Systems and Software Engineering and Technology, 1999. ASSET '99.

Процессы. 1999 IEEE Symposium..

46.

Axel van Lamsweerde “Requirements Engineering: From System Goals to UML

Models to Software Specifications”, John Wiley and Sons , 2009, 650 p..

47.

E. Yu, P. Giorgini, N. Maiden, J. Mylopoulos “Social Modeling for

Requirements Engineering» Кембридж, MA: MIT Press. 2011.

48.

Chung, L., Nixon, B. A., Yu, E. and Mylopoulos, J., Non-Functional

Requirements in Software Engineering, Kluwer Academic Publishers, Boston,

2000.

49.

Chung L., “Респосновление и использование нефункциональных

требований: A процесс Oriented Approach” Ph.D. Thesis, Dept. of Comp.

Science. University of Toronto, June 1993. Also tech. Rep. DKBS-TR-91-1..

50.

Breitman, K. K, Leite JCSP и Finkelstein Anthony. The World's Stage: A

Survey on Requirements Engineering С помощью Real-Life Case Study.

Journal of the Brazian Компьютер Society No 1 Vol. 6 Jul. 1999 pp:13:37.

51.

Бойм, Барри и Ин, Хох. "Identifying Quality-Requirement Conflicts". IEEE

Software,March 1996, pp. 25-35..

52.

Линдстром, DR Five Ways to Destroy a Development Project” IEEE Software,

September 1993, pp. 55-58..

53.

Oberle, D., Bhatti, N., Brockmans, S., Niemann, M., Janiesch, C. (2009).

Countering Service Information Challenges в Интернете, Журнал of Business

& Information System Engineering, 1(5), Gabler Verlag, 2009, pp. 370-390.

54.

Objectiver [Электронный ресурс] // Режим доступа:

http://www.objectiver.com/.