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

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного

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

«Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

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

по направлению подготовки 09.03.04 Программная инженерия

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

Каликова Анастасия Рамилевна

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

Руководитель к.ф.-м.н., доцент, доцент кафедры информационных технологий в бизнесе Е.Б. Замятина

Пермь, 2018 год



Аннотация

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

Работа содержит 63 страницы, 3 приложения, 30 изображений.

2018 г. Кафедра информационных технологий в бизнесе.

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



Оглавление

Введение

Глава 1. Анализ предметной области коммуникаций компонентов в информационных системах

1.1 Анализ архитектурных решений

1.2 Анализ шаблонов взаимодействия

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

1.4 Анализ языков моделирования бизнес-процессов на базе XML

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

1.6 Технология Windows Workflow Foundation

1.7 Технология Windows Presentation Foundation

1.8 Технология Windows Communication Foundation

1.9 Порт фреймворка log4net

1.10 Выводы по главе

Глава 2. Формализация требований к разрабатываемому координатору сервисов и его проектирование

2.1 Формализация требований

2.2 Обоснование трудоемкости разработки

2.3 Техническое задание

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

Глава 3.Реализация и тестирование координатора сервисов 2

3.1 Реализация редактора бизнес-процессов

3.2 Реализация интерпретатора бизнес-процессов

3.3 Работа координатора на примере композиций сервисов

3.4 Публикация сервиса

Заключение

Библиографический список

Приложения

Введение

На сегодняшний день многие информационные системы выполняют ряд сложных функций, использующих трудоемкие вычисления. Для оптимизации работы часть компонентов перемещается в Интернет. Примером такой системы является лингвистический портал, разрабатываемый в рамках проекта «Разработка программного обеспечения для проведения корпусных исследований английского языка» [1]. Главными задачами портала являются анализ научной речи и упрощение преподавания английского языка для академических целей [2,3].

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

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

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

Объектом данного исследования является архитектура порталов. Предметом исследования являются методы взаимодействия компонентов в сервис-ориентированной архитектуре.

Целью данного исследования является проектирование и реализация интеграции компонентов портала для проведения лингвистических исследований.

Для достижения поставленной цели необходимо решить следующие задачи:

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

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

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

В области управления web-сервисами на сегодня существует несколько подходов к интеграции компонентов системы в сервис-ориентированной архитектурой. Среди них общая база данных, обмен файлами, удаленный вызов и асинхронный обмен сообщениями. У данных подходов есть ряд своих преимуществ и ограничений. В рамках данного исследования проведен сравнительный анализ данных методов [6], сделан выбор в пользу управляемой событиями модели доставки данных без запроса, а также проведен анализ языков моделирования бизнес-процессов на базе XML [7] и выбор модели, которая используется для проведения интеграции компонентов портала.

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



Глава 1. Анализ предметной области коммуникаций компонентов в информационных системах

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

1.1 Анализ архитектурных решений

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

Многоуровневый шаблон архитектуры

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

Рисунок 1.1. Многоуровневый шаблон архитектуры

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

Архитектурный шаблон посредника (mediator)

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

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

Архитектурный шаблон «Модель-Представление-Контроллер»

В подходе MVC (Model-View-Controller) логика работы с данными и пользовательским интерфейсом разделена (рис. 1.2).

Рисунок 1.2. Шаблон «MVC»

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

Клиент-серверный шаблон архитектуры

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

1.2 Анализ шаблонов взаимодействия

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

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

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



Рисунок 1.3. Управляемая событиями модель доставки данных без запроса

Синхронный режим запрос/ответ

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

Рисунок 1.4. Синхронный режим запрос/ответ



Асинхронная модель

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

Рисунок 1.5. Асинхронная модель

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

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

Стандарт WSFL

WSFL (Web Service Flow Language) - стандарт, разработанный Microsoft, позволяющий описывать как публичные, так и частные процессы [8]. При таком стандарте нет модуля, отвечающего за обмен сообщениями. Каждый модуль является независимым участником процесса, где организацию обмена сообщений выполняет новый экземпляр потока участника (модуля), инстанциирующего данный поток. Данную концепцию называют «хореографией» сервисов. Языки, описывающие такое взаимодействие и входящие в этот стандарт: WS-CDL (Web Service Choreography Description Language) и ebXML (Electronic Business using eXtensible Markup Language).

Стандарт BPEL4WS

BPEL4WS (Business Process Executive Language For Web Service) - стандарт, разработанный Microsoft, IBM, Siebel, BEA Systems и SAP, выполняющий оркестровку сервисов [9]. Под оркестровкой здесь понимается, что существует исполняемый процесс, позволяющий организовывать взаимодействие бизнес-процессов внутри системы. Остальные участники также являются независимыми, но друг с другом напрямую не общаются. Языки, описывающие такое взаимодействие и входящие в этот стандарт: BPEL (Business Process Executive Language) и XPDL (XML Process Definition Language).

1.4 Анализ языков моделирования бизнес-процессов на базе XML

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

Язык BPEL

Функциональность каждого индивидуального веб-сервиса лимитирована, поэтому для автоматизации многообразного бизнес-процесса требуется координировать выполнение нескольких веб-сервисов, для чего реализован язык BPEL [10]. Представление бизнес-процесса на языке BPEL - это XML-файл, в котором связываемые в рамках конкретного процесса веб-сервисы продемонстрированы в виде партнеров, передающих друг другу сообщения. Для разработчика программирование выполняемого бизнес-процесса при использовании языка BPEL не предполагает кодирование блоков, исполняющих конкретные бизнес-функции, а состоит в построении процесса из уже существующих модулей - веб-сервисов. С точки зрения зрительного моделирования бизнес-процессов при данном программировании каждый из функциональных блоков диаграммы выполняет один достаточно крупный шаг процесса, но не детализированные инструкции (вычисления, доступ к файлам и т. п.).

Язык XPDL

Основным противником BPEL является выдвигаемый консорциумом WfMC язык XPDL, хотя сам WfMC дробит области применения двух языков и даже определяет их 77 взаимодополняющими. XPDL был создан для сохранения и передачи диаграммам бизнес-процессов между программными решениями, один из которых предопределен для имитирования процесса, другой для чтения и редактирования, третий для выполнения процесса внутри BPMS, поддерживающей XPDL [11].

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



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

Система Serena Business Manager

Serena Business Manager (SBM) - платформа для управления бизнес-процессами предприятия любого масштаба и организации эффективного взаимодействия сотрудников и рабочих групп в рамках выполнения ими процессов, направленных на достижение стратегических целей компании (рис. 1.6).

Рисунок 1.6. Serena Business Manager

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

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

Система Oracle BPEL Process Manager

Oracle BPEL Process Manager это инструмент для создания и исполнения бизнес-процессов. Данное редство предоставляет комплексную и базированную на открытых стандартах методологию к созданию, разворачиванию и координации сквозными бизнес-процессами, которые могут располагать в себе как задачи для пользователей, так и автоматические действия (рис. 1.7).

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

Рисунок 1.7. Oracle BPEL Process Manager

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

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

Система Ansible

Ansible -- программный продукт без клиентской части с открытым исходным кодом для удаленной координации конфигурациями, созданное Майклом Де Хаанном в 2012 году

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

Рисунок 1.8.Пример сценария для Ansible

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

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

Сравнение инструментов по критериям

Формализуем проведенный анализ инструментальных средств по критериям, основанных на их преимуществах и недостатках. Список критериев:

Универсальное решение.

Низкие затраты на внедрение инструмента.

Наличие открытого кода.

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

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

Представим результаты сравнения в таблице (таблица 1.1).

Таблица 1.1 - Итоги сравнения инструментальных средств

Критерии	SBM	Oracle BPEL PM	Ansible
Универсальное решение	+	+	-
Низкие затраты	-	-	+
Наличие открытого кода	-	-	+
Доп. программные продукты	+	-	+
Завершенность кода	+	+	-

1.6 Технология Windows Workflow Foundation

В разрабатываемом координаторе модуль редактирования бизнес-процессов будет реализован с использованием технологии Windows Workflow Foundation (WWF) [12]. Данная технология позволяет управлять рабочими процессами с помощью трех основных типов процессов: последовательный процесс, конечный автомат и процесс, управляемый правилами. Пример рабочего процесса продемонстрирован на рисунке 1.9.



Рисунок 1.9.Пример рабочего процесса в WWF

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

1.7 Технология Windows Presentation Foundation

Интерфейсная часть координатора будет выполнена при использовании технологии Windows Presentation Foundation (WPF) [13]. WPF в сочетании с WWF позволяет настраивать элементы управления при разработке в нужном виде для разработчика. Такие настройки элементов управления делают редактирование процессов универсальным и абстрагированным от конкретной предметной области.



1.8 Технология Windows Communication Foundation

Модуль интерпретации будет использовать Windows Communication Foundation (WCF) [14]. Данная технология позволяет создавать веб-сервисы, отличительной чертой которых является поддержка сессий. Такой подход способен осуществлять многопользовательскую работу в системах, примером которой является лингвистический портал. Использование данного подхода позволяет создать универсальный инструмент.

1.9 Порт фреймворка log4net

В модуле интерпретации есть необходимость в проверке выполнения рабочих процессов. Для этого необходим инструмент логирования, который бы позволял отслеживать этапы вызовов методов сервисов. Таким инструментом будет являться порт фреймворка log4net [15]. Такой порт совмещает в себе ряд преимуществ фреймворка Apache log4j с новыми возможностями .Net платформы. Пример результата логирования отображен на рисунке 1.10.

Рисунок 1.10. Пример логирования с помощью log4net

1.10 Выводы по главе

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



Глава 2. Формализация требований к разрабатываемому координатору сервисов и его проектирование

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

2.1 Формализация требований

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

Рисунок 2.1. Текущая архитектура портала

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

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

Рисунок 2.2. Диаграмма прецедентов

Опишем в расширенном виде каждый прецедент, чтобы понимать действия акторов и реакцию сервиса на эти действия:

Название: Добавление компонента.

Акторы: Администратор.

Краткое описание: администратор добавляет по ссылке компонент портала в редактор бизнес-процессов

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

Взаимодействие актора с системой описано в таблице 2.1.

Таблица 2.1 - Развернутое описание прецедента «Добавление компонента»

Действия акторов	Отклик сервиса
Ввести ссылку на компонент.
Нажать кнопку «Добавить»	По ссылке получает контракт сервиса и список методов.
	Отображает компонент и список его методов в редакторе бизнес-процессов.

Название: Удаление компонента.

Акторы: Администратор.

Краткое описание: администратор удаляет компонент из редактора бизнес-процессов

Триггер: открыть редактор бизнес-процессов портала, добавить компонент.

Взаимодействие актора с системой описано в таблице 2.2.

Таблица 2.2 - Развернутое описание прецедента «Удаление компонента»

Действия акторов	Отклик сервиса
Выбрать компонент
Вызвать правой кнопкой контекстное меню
Нажать кнопку «Удалить»	Удаляет вызовы методы компонента из всех бизнес-процессов
	Удаляет компонент из редактора

Название: Добавление бизнес-процесса.

Акторы: Администратор.

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

Триггер: открыть редактор бизнес-процессов портала, добавить компоненты.

Взаимодействие актора с системой описано в таблице 2.3.

Таблица 2.3 - Развернутое описание прецедента «Добавление бизнес-процесса»

Действия акторов	Отклик сервиса
Добавить новую вкладку для бизнес-процесса
Выбрать метод компонента и перетащить на область с процессом	Создает бизнес-процесс с выбранным методом

Название: Изменение бизнес-процесса.

Акторы: Администратор.

Краткое описание: администратор изменяет бизнес-процесс.

Триггер: открыть редактор бизнес-процессов портала, добавить компоненты, добавить бизнес-процесс.

Взаимодействие актора с системой описано в таблице 2.4.

Таблица 2.4 - Развернутое описание прецедента «Изменение бизнес-процесса»

Действия акторов	Отклик сервиса
Выбрать на вкладках нужный бизнес-процесс
Добавить новый метод/правой кнопкой мыши удалить метод из процесса	Изменяет бизнес-процесс в соответствии с действиями администратора

Название: Удаление бизнес-процесса.

Акторы: Администратор.

Краткое описание: администратор удаляет бизнес-процесс.

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

Взаимодействие актора с системой описано в таблице 2.5.



Таблица 2.5 - Развернутое описание прецедента «Удаление бизнес-процесса»

Действия акторов	Отклик сервиса
Выбрать на вкладках нужный бизнес-процесс
Правой кнопкой мыши вызвать контекстное меню и выбрать «Удалить»	Удаляет бизнес-процесс

Название: Выгрузка в BPEL файл.

Акторы: Администратор.

Краткое описание: администратор сохраняет созданные процессы в удаленном BPEL файле.

Триггер: открыть редактор бизнес-процессов портала, создать бизнес-процессы.

Взаимодействие актора с системой описано в таблице 2.6.

Таблица 2.6 - Развернутое описание прецедента «Выгрузка в BPEL файл»

Действия акторов	Отклик сервиса
Нажать кнопку «Сохранить»	Обновляет файл на удаленном сервере со списком процессов на языке BPEL.

Название: Получение списка бизнес-процессов.

Акторы: Клиент портала.

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

Взаимодействие актора с системой описано в таблице 2.7.

Таблица 2.7 - Развернутое описание прецедента «Получение списка бизнес-процессов»

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



Название: Вызов бизнес-процесса.

Акторы: Клиент портала.

Краткое описание: клиент портала вызывает нужный процесс в результате запроса пользователя.

Взаимодействие актора с системой описано в таблице 2.8.

Таблица 2.8 - Развернутое описание прецедента «Вызов бизнес-процесса»

Действия акторов	Отклик сервиса
Вызвать метод на начало бизнес-процесса, передав параметры от пользователя	Открывает файл с описанием процессов на языке BPEL.
	Действия в рамках прецедента «Интерпретация BPEL файла»
	Возвращает результат работы компонентов портала по результату работы бизнес-процесса клиенту
Возвращает данные пользователю

Название: Интерпретация BPEL файла.

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

Взаимодействие актора с системой описано в таблице 2.9.

Таблица 2.9 - Развернутое описание прецедента «Интерпретация BPEL файла»

Отклик сервиса
Преобразование кода в процессы
Вызов методов компонентов портала в порядке определенном процессом.

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

Рисунок 2.3. Новая архитектура портала

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

Рисунок 2.4. Группировка прецедентов



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

2.2 Обоснование трудоемкости разработки

Обоснование трудоемкости разработки выполнено по методике Work Breakdown Structure (WBS), т.к. реализуемый проект имеет небольшой размер, команда проекта подразумевает маленькое количество ролей в команде, которое не превышает размер команды по MSF и при реализации проекта задачи имеют четкие границы, поэтому легко определить время на их разработку. Количество разработчиков на проект - 1.

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

Таблица 2.10 - Оценка трудоемкости

№	Работы	Оценка трудоемкости (ч.)	Стоимость работы (руб.)
1	Разработка ТЗ	9	3150
1.1	Разработка требований	9	3150
1.1.1	Определение требований к архитектуре	6	2100
1.1.2	Определение требований к функциям системы	3	1050
2	Разработка программы	83	29050
2.1	Проектирование архитектуры	13	4550
2.1.1	Определение системных компонент	5	1750
2.1.2	Построить диаграммы описания бизнес-процессов	8	2800
2.2	Реализация функций системы	70	24500
2.2.1	Оркестрирование сервисов портала	50	17500
2.2.2	Добавление новых сервисов	20	7000
3	Разработка документации	16	5600
3.1	Разработка руководства пользователя	8	2800
3.2	Разработка руководства программиста	8	2800

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

2.3 Техническое задание

После формализации требований к разрабатываемому инструменту можно описать их четкую постановку в техническом задании. А именно: универсальное управление разнородными компонентами, наличие визуального редактора для формирования бизнес-процессов в рамках пользовательских требований портала, сервис должен быть легко интегрирован в сервис-ориентированную архитектуру, сервис должен использовать стандарт BPEL4WS и язык BPEL, затраты на интеграцию должны быть меньше, чем у подобных коммерциализированных решений. Результат формализации требований к продукту зафиксированы в техническом задании. С текстом ТЗ можно ознакомиться в приложении А.

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

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

Проектирование редактора бизнес-процессов

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

Рисунок 2.5. Редактор бизнес-процессов

Чтобы интерфейс отвечал этим требованиям необходимо, чтобы он содержал следующие элементы:

Текстовое поле типа TextBox для ввода ссылки на сервис.

Кнопка типа Button для добавления сервиса портала в редактор по введенной ранее ссылке.

Контекстное меню типа ContextMenu для удаления выбранного сервиса из редактора.

Объект типа TreeView для отображения добавленных сервисов и их методов.

Объект типа TabControl для отображения созданных бизнес-процессов.

На каждой вкладке бизнес-процесса объект WorkflowDesigner.View для конструирования и редактирования процессов.

Объект типа WorkflowDesigner.PropertyInspectorView для отображения окна свойств редактируемого процесса.

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

Кнопка типа Button для выгрузки полученных процессов в BPEL файл.

Проектирование интерпретатора бизнес-процессов

Интерпретатор является сервисом, поэтому нужно описать его структуру и контракты с помощью диаграммы классов (рис. 2.6).

Рисунок 2.6. Диаграмма классов

Описание классов:

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

Класс ProcessClass является контрактом данных сервиса и определяет структуру хранения процесса. У каждого процесса есть имя, массив параметров, который ему передается от пользователя, результат выполнения процесса и сам процесс тип Activity, который содержит ссылки для вызовов методов сервисов портала.

Класс ProcessConvertor реализует интерфейс сервиса. Среди атрибутов есть список процессов, который были созданы администратором. Методы такие же как у интерфейса.

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

Рисунок 2.7. Диаграмма компонентов

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



Глава 3. Реализация и тестирование координатора сервисов

После этапа проектирования следует этап реализации и тестирования координатора бизнес-процессов. Инструментальными средствами выступили Visual Studio на языке высокого уровня С#. Возможности среды и языка очень велики, так что выбор инструментария можно считать эффективным.

Редактор будет выполнен в WPF (Windows Presentation Foundation) c использованием WWF (Windows Workflow Foundation) для корректной работы с потоками и активностями. Интерпретатор будет реализован как WCF-сервис, так как он является быстродейственным, переиспользуемым и динамически балансируемым по нагрузкам. По результатам данного этапа будут сформированы руководства пользователя и программиста.

3.1 Реализация редактора бизнес-процессов

Реализация интерфейса

Первым шагом при реализации редактора является добавление сервиса по ссылке. Пользователь вводит ссылку в текстовое поле, после чего редактор получает WSDL (Web-Services Description Language) описание сервиса, из которого получает список методов сервиса, его входные и выходные данные. На рисунке 3.1 приведен фрагмент кода по добавлению сервиса, а на рисунке 3.2 результат работы функции.



Рисунок 3.1.Добавление сервиса

Рисунок 3.2. Результат работы добавления сервиса

Также есть возможность удаления сервиса из списка путем нажатия кнопки «Удалить» в контекстном меню.

Далее на основе добавленных методов будем формировать бизнес-процесс. Для этого нам необходимо создать свою активность ServiceCall, наследуемую от класса System.Activities.NativeActivity. В ней опишем поля, которые будут хранить информацию о выбранном сервисе, методе, входных параметрах и результате выполнения сервиса. Результат описания представлен на рисунке 3.3.

Рисунок 3.3. Класс для вызова сервиса

Для созданной активности описывается дизайнер, который будет отображать свойства активности. К ним относятся входные параметры, которые пользователь будет задавать. Результат XAML описания представлен на рисунке 3.4.

Рисунок 3.4. Результат XAML описания дизайнера

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

Рисунок 3.5. Пример бизнес-процесса

Реализация сохранения

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



Рисунок 3.6. Пример BPEL файла

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

Для успешной настройки удаленного доступа был использованы хранилища сервиса Google Drive. При сохранении в файл редактор передает настройки авторизации и обновляет содержимое файла. Интерпретатор бизнес-процессов также удаленно получает содержимое удаленного файла через Google Drive API [16].

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

Рисунок 3.7. Авторизация в Google Drive

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

Рисунок 3.8.Доступ к файлу через Google Drive API

3.2 Реализация интерпретатора бизнес-процессов

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

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

Рисунок 3.9. Интерпретатор бизнес-процессов

3.3 Работа координатора на примере композиций сервисов

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

AuthorizeUser

GetCorpora

GetDocuments

GetDocument

MakeCommonCorpus

MakeCorpus

AddUser

UpdateUser

DeleteUser

AddDocument

UpdateDocument

DeleteDocument

UpdateCorpus

DeleteCorpus

FindDocuments

FindText

FindTextSimple

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

Рисунок 3.10. Сервис хранения документов

Далее создадим бизнес-процесс под именем «Authorize» в рабочей зоне путем перетаскивания в рабочую область по очереди методов авторизации, добавления и удаления пользователя (рис 3.11).

Рисунок 3.11. Создание процесса

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

Рисунок 3.12. Вызов процесса на выполнение

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

3.4 Публикация сервиса

Для публикации сервиса используется портал Azure [16]. Это общедоступное облако, позволяющее размещать различные виды решений: от веб-сервисов и хранилищ данных до конечного программного обеспечения (рис. 3.13).

Рисунок 3.13. Портал Azure

С помощью профиля публикации веб-приложений, предоставляемого Azure, и встроенных средств Visual Studio сервис был опубликован. Доступ к сервису возможен по ссылке: https://processconvertor.azurewebsites.net. Тестирование координатора сервисов

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

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

Таблица 3.1 - Тестирование добавления сервиса

№ теста	Входные данные	Ожидаемый результат	Реальный результат
1	Пустая строка	Сообщение, что ссылка не введена	Сообщение, что ссылка не введена
2	http://addinxwcfsample.apphb.com/SayHelloService.svc (WCF сервис)	Операции сервиса	Операции сервиса
3	https://www.cbr.ru/DailyInfoWebServ/DailyInfo.asmx (Web сервис)	Операции сервиса	Операции сервиса
4	Некорректная ссылка	Сообщение, что ссылка некорректна	Сообщение, что ссылка некорректна

Результат тестирования удаления сервиса из списка приведен в таблице 3.2.

Таблица 3.2 - Тестирование удаления сервиса

№ теста	Входные данные	Ожидаемый результат	Реальный результат
1	При удалении выбрана операция сервиса	Удаление сервиса из списка	Удаление сервиса из списка
2	При удалении выбран сервис	Удаление сервиса из списка	Удаление сервиса из списка
3	Попытка удаления пустого элемента TreeView	Сообщение, что не выбран сервис для удаления	Сообщение, что не выбран сервис для удаления

Далее тестируем сохранение в BPEL файл бизнес-процессов. Необходимо проверить несовпадение количества входных параметров с аргументами, несовпадение типов параметров и аргументов. Для примера возьмем процесс, в котором вызывается метод EnumValutes(Seld:boolean):object. Результат тестирования представлен в таблице 3.3.



Таблица 3.3 - Тестирование сохранения процессов

№ теста	Входные данные	Ожидаемый результат	Реальный результат
1	Процесс с пустым набором параметров	Сообщение об ошибке сохранения	Сообщение об ошибке сохранения
2	Процесс с 2-мя и более параметров	Сообщение об ошибке сохранения	Сообщение об ошибке сохранения
3	Процесс с 1 параметром, тип которого отличен от boolean	Сообщение об ошибке сохранения	Сообщение об ошибке сохранения
4	Процесс с 1 параметром, тип которого равен boolean	Сообщение, что сохранение успешно завершено	Сообщение, что сохранение успешно завершено

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

Таблица 3.4 - Тестирование интерпретатора процессов

№ теста	Входные данные	Ожидаемый результат	Реальный результат
1	Вызов функции (имя процесса, входные параметры)	Результат выполнения бизнес-процесса	Результат выполнения бизнес-процесса
2	Вызов функции (пустое имя процесса, пустые входные параметры)	Сообщение об ошибке вызова функции	Сообщение об ошибке вызова функции
3	Пустой входной список процессов	Сообщение об ошибке получения процессов	Сообщение об ошибке получения процессов

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



Заключение

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

проведен сравнительный анализ существующих методов интеграций компонентов информационных систем с сервис-ориентированной архитектурой;

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

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

выполнено проектирование сервиса интеграции и описано его место в общей архитектуре лингвистического портала;

выполнено проектирование пользовательского интерфейса;

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

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

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

Результаты исследования вместе с результатами работ Симоновой Н.А. и Гуляевым В.Ю. прошли апробацию на всероссийской научно-практической конференции молодых учёных с международным участием «Математика и междисциплинарные исследования - 2018» (ПГНИУ, г. Пермь). В секции «Прикладная лингвистика» доклад получил первое место.



Библиографический список

1. Разработка программного обеспечения для проведения корпусных исследований английского языка // НИУ ВШЭ в Перми URL: https://perm.hse.ru/bi/sfcr (дата обращения: 18.02.2018).

2. Бармина Е.И. Система для обработки корпусов текстов / Е.И. Бармина, Р.Н. Бушуев, Н.В. Котельникова, В.В. Ланин, О.А. Плотникова // Математика и междисциплинарные исследования - Пермь: Пермский государственный национальный исследовательский университет, 2016. - С. 245-250.

3. Копотев М.В. Введение в корпусную лингвистику: учеб. пособие для студентов филологических и лингвистических специальностей университетов / М.В. Копотев. - Прага: Animedia Company. - 2014. - 230 с.

4. Badr Y. Service-Oriented Workflow. Journal of Digital Information Management, 6(1), 120-127, 2018 г. URL: http://dblp.uni-trier.de/db/journals/jdim/jdim6.html pdf (дата обращения: 18.02.2018).

5. Leymann F. Web Services Flow Language, Specification. 2001 г. URL: http://xml.coverpages.org/WSFL-Guide-200110.pdf (дата обращения: 18.02.2018).

6. Выбор технологии для интеграции прикладных систем предприятия (EAI) - JCA, JMS или Web_сервисы? // IBM developerWorks. URL: https://www.ibm.com/developerworks/ru/library/ws-jcajms/index.html (дата обращения: 18.02.2018).

7. Самуйлов К.Е., Серебренникова Н.В., Чукарин А.В., Яркина Н.В. Основы формальных методов описания бизнес-процессов / Учеб. пособие. - М.: РУДН, 2008.

8. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов / Учеб. пособие. - М.: РУДН, 2008.

9. Michael Papazoglou, Willem-Jan van den Heuvel. Web Services Management: A Survey / IEEE Internet Computing - IEEE Computer Society, 2005.

10. Даниил Фейгин. Архитектуры и средства интеграции приложений / Открытые системы. СУБД №02 - Открытые системы, 2005.

11. Алексей Добровольский. Интеграция приложений: методы взаимодействия, топология, инструменты / Открытые системы. СУБД №09 - Открытые системы, 2006.

12. How to: Create a Custom Activity Designer // Microsoft. URL: https://docs.microsoft.com/en-us/dotnet/framework/windows-workflow-foundation/how-to-create-a-custom-activity-designer (дата обращения: 12.05.2018).

13. Windows Presentation Foundation. Microsoft Development Network . URL: https://msdn.microsoft.com/ru_ru/library/ms754130%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396 (дата обращения: 12.05.2018).

14. Developing Service_Oriented Applications with WCF // Microsoft. URL: https://msdn.microsoft.com/ru_ru/library/dd456779.aspx (дата обращения: 12.05.2018).

15. Apache log4net // Logging Services. URL: http://logging.apache.org/log4net (дата обращения: 16.05.2018).

16. Что такое Azure - облачные службы от Microsoft // Платформы и службы облачных вычислений Microsoft Azure. URL: https://azure.microsoft.com/ru-ru/overview/what-is-azure (дата обращения: 17.05.2018).

Размещено на Allbest.ru

...