Таблица 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