2. Разработка модели и методов организации рабочих операций и бизнес-процесса

3. Разработка модели и методов организации рабочих операций и объектами рабочих операций бизнес-процесса

Для построения бизнес-процесса был использован BPM. Бизнес -процесс создан на основе диаграммы написанной на языке BPEL, которая автоматически генерируется, путем преобразования BPMN-диаграммы, если это диаграмма нарисована в одном из редакторов: Windows Workflow Framework .

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

Сервис для данной программы написана на WCF, а в WSDL генерируется. WSDL нужен для того чтобы знать какие данные отправлены на сервис и где сервис находится. WCF-это технология, где пишется логика обработки и которая реализует сервис с WSDL. WCF генерирует WSDL на основе C# классов. Для упрощения взаимодействии WCF-сервиса с БД используется Entity Framework container т.е он сам генерирует в SQL запросы. Совокупность силлабусов (точнее характеристики силлабусов) хранится в базе данных. Данное представление и хранение силлабусов удобно для формализации, алгоритмизации и машинной обработки.

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

3.1 Описание бизнес-процесса на BPMN

Нотация BPMN (Business Process Model and Notation - модель бизнес-процессов и нотация) используется для описания процессов нижнего уровня. Диаграмма процесса в нотации BPMN представляет собой алгоритм выполнения процесса. На диаграмме могут быть определены события, исполнители, материальные и документальные потоки, сопровождающие выполнение процесса. Каждый процесс может быть декомпозирован на более низкие уровни. Декомпозиция может производиться в нотациях BPMN или EPC. При декомпозиции процесса BPMN, расположенного на диаграмме SADT, стрелки с диаграммы SADT на диаграмму BPMN не переносятся.

В нотации BPMN выделяют пять основных категорий элементов:

· элементы потока (события, процессы и шлюзы);

· данные (объекты данных и базы данных);

· соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

· зоны ответственности (пулы и дорожки);

· артефакты (сноски).

Таким образом на BPMN бизнес-процесс «Подготовка к новому учебному году » имеет вид как на рисунке 8.

Рисунок 8. BPMN-диаграмма выполнения процесс "Сбор Силлабусов и УМКД"

Start - Запуск системы

Create new syllabus -Создание нового силлабуса

Confirmation- Подтверждение силлабуса при правильном заполнении

Rejected - Отклонение силлабуса при нахождении ошибки

Confirmed - Утверждено

Программная реализация бизнес процесса «Подготовка к новому учебному году » может быть написана на языке BPEL. Которая получается автоматический, путем преобразования BPMN-диаграммы, если это диаграмма нарисовано в одном из редакторов: Windows Workflow Framework, Oracle JDevolopment, Windows K2.

3.2 Краткое описание Windows Workflow Foundation 

Windows Workflow Foundation (WF) представляет собой технологию компании Microsoft для определения, выполнения и управления рабочими процессами (англ. workflow). Данная технология входит в состав .NET Framework 3.0, который изначально установлен в Windows Vista и может быть установлен в Windows 2003 Server и Windows XP SP2. WF ориентирована на визуальное программирование и использует декларативную модель программирования.

WF поддерживается в Visual Studio 2005 в виде расширения (add-on), в состав которого входит визуальный дизайнер процессов и визуальный отладчик, позволяющий отладить созданный процесс. В Visual Studio 2008 эта функциональность входит изначально.

При помощи WF могут быть описаны три типа процессов:

- последовательный процесс (Sequential Workflow) -- переход от одного шага в другой без возвратов обратно;

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

- процесс, управляемый правилами (Rules-driven Workflow) -- частный случай последовательного процесса, в котором переход на следующий шаг определяется набором правил.

Библиотека WF, являясь одной из реализаций парадигмы Workflow, предоставляет следующие основные возможности: 

- богатый набор функциональных блоков; 

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

-сохранение и возобновление экземпляров Workflow в процессе их исполнения; 

-использование Workflow дизайнера в вашем приложении; 

-интеграция с WCF; 

-пошаговая диагностика непосредственно в Workflow дизайнере;

- и многое другое. 

3.3 Краткое описание Детерминированного конечного автомата

Все бизнес- операции имеют одинаковые диаграммы так как бизнес-процессы построены на основе математической модели Теория детерминированных конечных автоматов как показано на рисунке 9, 10 и 11.

1. Силлабус	2.РУП
3.Учебная нагрузка

Рисунок 9. Рисунок 8. BPMN-диаграмма выполнения операции формирование

Рисунок 10. Workflow Учебного процесса

Рисунок 11. Последовательность Учебного процесса

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

Недетерминированный конечный автомат (НКА) является обобщением детерминированного.

Детерминированным конечным автоматом (ДКА) называется устройство, описываемое следующими параметрами:

Q - конечное множество состояний.

У - конечное множество входных символов.

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

q₀ - начальное состояние, принадлежит Q.

F - множество допускающих состояний, является подмножеством Q.

И функционирующие следующим образом:

Автомат начинает работу в состоянии q₀.

Если автомат находится в состоянии q_i, а на вход поступает символ b, то автомат переходит в состояние д(q_i, b).

Работа ДКА заключается в распознавании цепочек символов, принадлежащих множеству У. Если, обработав цепочку, автомат оказался в допускающем состоянии, то цепочка считается допустимой, если нет, то нет. Таким образом, ДКА задаёт некоторый язык - множество допускаемых им цепочек, алфавит этого языка - множество У.

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

Рисунок 12. Простой детерминированный конечный автомат.



Второй вариант изображения автоматов - таблица переходов.

Таблица 2. Тот же самый конечный автомат.

	0	1
->	q0	q1	q0
*	q1	q1	q0

3.4 Общие сведения WCF

Сервис для данной программы написана на WCF, а в WSDL генерируется. WSDL нужен для того чтобы знать какие данные отправлены на сервис и где сервис находится. WCF-это технология, где пишется логика обработки и которая реализует сервис с WSDL. WCF генерирует WSDL на основе C# классов. Для упрощения взаимодействии WCF-сервиса с БД используется Entity Framework container т.е он сам генерирует в SQL запросы. Совокупность силлабусов (точнее характеристики силлабусов) хранится в базе данных. Данное представление и хранение силлабусов удобно для формализации, алгоритмизации и машинной обработки.

Если в двух словах, то WCF (a.k.a. Windows Communication Foundation) -- это очередной Фреймворк для построения распределенных приложений и межпроцессного взаимодействия, который является логическим развитием предыдущих подобных технологий компании Майкрософт, в частности Веб-сервисов, .Net Remoting и DCOM. И если предшественники были заточены на выполнение какого-то конкретного круга задач, то WCF - это скорее мультипарадигменная технология, вобравшая в себе все лучшее от своих предшественников, добавив при этом, конечно же, кое-каких собственных проблем.

WCF -- это, прежде всего, технология для построения сервис-ориентированной архитектуры приложений (SOA -- Service-Oriented Architecture), что позволяет абстрагироваться от конкретной технологи, на которой этот сервис реализован и пользоваться им из других приложений, написанных на любой другой платформе, языке, технологии; главное, чтобы реализация клиента отвечала определенным правилам. Кроме того, логика самого сервиса и его реализация полностью отделена от коммуникационной составляющей, и мы можем декларативно изменять способ взаимодействия с сервисом путем изменения конфигурационного файла. Мы можем изменить протокол взаимодействия, адрес, настроить максимальное количество подключений, ограничить размер пакетов и тайм-аут подключения к сервису, тайм-аут выполнения операции, надежность доставки и многое другое. WCF «не выносит свой сор из избы» и не показывает наружу никакие платформенно - зависимые детали реализации сервиса, такие как сборки, конкретные классы сервиса, типы аргументов или исключения. Вместо этого сервис представляет собой группу операций, определенных в некотором интерфейсе, которые получают некоторые абстрактные входные/выходные параметры; все это дело описывается с помощью WSDL (Web Service Description Language) и может быть выставлено наружу через, так называемые mex-endpoints (Metadata Exchange Endpoints). Это позволяет получить «метаданные» сервиса подключившись к этому интерфейсу, получить описание сервиса и всех его операций и сгенерировать соответствующий прокси класс для заданного языка или платформы. Именно это позволяет написать сервис с помощью WCF, а использовать его из Java/Python/Ruby и чего угодно еще.

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

private void CreateSyllabusButton_Click(object sender, RoutedEventArgs e)

{

using(DataServiceClient client = new DataServiceClient())

{

WSSyllabus syllabus = new WSSyllabus();

syllabus.AcademicYear = Convert.ToInt32(AcademicYear.Text);

syllabus.Category = Category.Text;

syllabus.Credits = Convert.ToInt32(CreditHour.Text);

syllabus.Language = Language.Text;

syllabus.Major = Major.Text;

WSSubject wssub = (WSSubject)Subject.SelectedItem;

syllabus.Subject = wssub;

syllabus.Years = Convert.ToInt32(Years.Text);

client.CreateSyllabus(syllabus);

}

}

3.5 Описание WSDL-сервисов

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

Вкратце охарактеризуем WSDL-язык.

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

Язык описания веб-сервисов (Web services Description Language, WSDL) предназначен для унифицированного представления внешних интерфейсов веб-службы. Текущая версия протокола (на момент написания этой лекции) WSDL 2.0 и она имеет некоторые отличия от предыдущих версий (см.табл. 1 и рис. 3).

В спецификации WSDL 1.1 было определено 4 шаблона обмена сообщениями (типы операций):

- Однонаправленные операции (One-way): операция может принимать сообщение, но не будет возвращать ответ.

- Запрос-ответ (Request-response): операция может принять запрос и должна вернуть ответ.

- Вопрос-ответ (Solicit-response): операция может послать запрос и будет ждать ответ на него.

Извещение (Notification): операция может послать сообщение, но не будет ожидать ответ.

В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1

WSDL описание:

<wsdl:service name="DataService">

<wsdl:port name="BasicHttpBinding_IDataService" binding="tns:BasicHttpBinding_IDataService">

<soap:address location="http://localhost:54099/DataService.svc"/>

</wsdl:port>

</wsdl:service>

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

а также наименование интерфейса всех методов

<wsdl:portType name="IDataService">

<wsdl:operation name="CreateSubject">

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/CreateSubject" message="tns:IDataService_CreateSubject_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/CreateSubjectResponse" message="tns:IDataService_CreateSubject_OutputMessage"/>

</wsdl:operation>

<wsdl:operation name="GetSubject">

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/GetSubject" message="tns:IDataService_GetSubject_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/GetSubjectResponse" message="tns:IDataService_GetSubject_OutputMessage"/>

</wsdl:operation>

<wsdl:operation name="CreateSyllabus">

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/CreateSyllabus" message="tns:IDataService_CreateSyllabus_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/CreateSyllabusResponse" message="tns:IDataService_CreateSyllabus_OutputMessage"/>

</wsdl:operation>

<wsdl:operation name="GetSyllabus">

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/GetSyllabus" message="tns:IDataService_GetSyllabus_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/GetSyllabusResponse" message="tns:IDataService_GetSyllabus_OutputMessage"/>

</wsdl:operation>

<wsdl:operation name="Login">

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/Login" message="tns:IDataService_Login_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/LoginResponse" message="tns:IDataService_Login_OutputMessage"/>

</wsdl:operation>

<wsdl:operation name="GetRup">

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/GetRup" message="tns:IDataService_GetRup_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/GetRupResponse" message="tns:IDataService_GetRup_OutputMessage"/>

</wsdl:operation>

<wsdl:operation name="CreateRup">// создание руппов

<wsdl:input wsaw:Action="http://tempuri.org/IDataService/CreateRup" message="tns:IDataService_CreateRup_InputMessage"/>

<wsdl:output wsaw:Action="http://tempuri.org/IDataService/CreateRupResponse" message="tns:IDataService_CreateRup_OutputMessage"/>

</wsdl:operation>

</wsdl:portType>

В данном отрывке описаны наименования методов в интерфейсе IDataService :

CreateSubject, GetSubject, CreateSyllabus, GetSyllabus, Login, GetRup, CreateRup

а также типы данных(входящих и исходящих). Например IDataService_CreateRup_InputMessage, IDataService_CreateRup_OutputMessage

в элементе:

wsdl:types

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

<wsdl:binding name="BasicHttpBinding_IDataService" type="tns:IDataService">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="CreateSubject">

- Описывается тип используемого протокола, с присвоением к "привязке"(binding)

Пример Силлабуса в WSDL(структура объекта):

<xs:complexType name="WSSyllabus">

<xs:sequence>

<xs:element minOccurs="0" name="AcademicYear" type="xs:int"/>

<xs:element minOccurs="0" name="Category" nillable="true" type="xs:string"/>

<xs:element minOccurs="0" name="Credits" type="xs:int"/>

<xs:element minOccurs="0" name="Id" type="xs:int"/>

<xs:element minOccurs="0" name="Language" nillable="true" type="xs:string"/>

<xs:element minOccurs="0" name="Major" nillable="true" type="xs:string"/>

<xs:element minOccurs="0" name="Semester" nillable="true" type="xs:string"/>

<xs:element minOccurs="0" name="Status" nillable="true" type="tns:WSStatus"/>

<xs:element minOccurs="0" name="Subject" nillable="true" type="tns:WSSubject"/>

<xs:element minOccurs="0" name="Years" type="xs:int"/>

</xs:sequence>

</xs:complexType>

- Каждое поле представляет данные по типу, например AcademicYear - академический год тип integer(целое число), micOccurs - количество встречаемости в данном "объекте"

Пример РУП:

<xs:complexType name="WSRup">

<xs:sequence>

<xs:element minOccurs="0" name="Laboratory" type="xs:int"/>

<xs:element minOccurs="0" name="Lectures" type="xs:int"/>

<xs:element minOccurs="0" name="Practical" type="xs:int"/>

<xs:element minOccurs="0" name="SroTotal" type="xs:int"/>

<xs:element minOccurs="0" name="Srop" type="xs:int"/>

<xs:element minOccurs="0" name="Syllabus" nillable="true" type="q1:WSSyllabus" xmlns:q1="http://schemas.datacontract.org/2004/07/DataService.Entity"/>

<xs:element minOccurs="0" name="TotalHours" type="xs:int"/>

</xs:sequence>

</xs:complexType>

Пример Нагрузка:

<xs:complexType name="WSLoad">

<xs:sequence>

<xs:element minOccurs="0" name="TeacherId" type="xs:int"/>

<xs:element minOccurs="0" name="SpecialityId" type="xs:int"/>

<xs:element minOccurs="0" name="HourTypeId" type="xs:int"/>

<xs:element minOccurs="0" name="Value" type="xs:int"/>

</xs:sequence>

</xs:complexType>

3.6 Описание ADO.NET Entity Framework

ADO.NET Entity Framework (EF) -- объектно-ориентированная технология доступа к данным, является object-relational mapping (ORM) решением для .NET Framework от Microsoft. Предоставляет возможность взаимодействия с объектами как посредством LINQ в виде LINQ to Entities, так и с использованием Entity SQL. Для облегчения построения web-решений используется как ADO.NET Data Services (Astoria), так и связка из Windows Communication Foundation и Windows Presentation Foundation, позволяющая строить многоуровневые приложения, реализуя один из шаблонов проектирования MVC, MVP или MVVM.

ORM (англ. object-relational mapping, рус. объектно-реляционное отображение) -- технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как проприетарные, так исвободные реализации этой технологии.

Платформа Entity Framework представляет собой набор технологий ADO.NET, обеспечивающих разработку приложений, связанных с обработкой данных.Архитекторам и разработчикам приложений, ориентированных на обработку данных, приходится учитывать необходимость достижения двух совершенно различных целей. Они должны моделировать сущности, связи и логику решаемых бизнес-задач, а также работать с ядрами СУБД, используемыми для сохранения и получения данных. Данные могут распределяться по нескольким системам хранения данных, в каждой из которых применяются свои протоколы, но даже в приложениях, работающих с одной системой хранения данных, необходимо поддерживать баланс между требованиями системы хранения данных и требованиями написания эффективного и удобного для обслуживания кода приложения.

Entity Framework позволяет работать с данными в форме специфических для домена объектов и свойств, таких как клиенты и их адреса, без необходимости обращаться к базовым таблицам и столбцам базы данных, где хранятся эти данные. Entity Framework дает разработчикам возможность работать с данными на более высоком уровне абстракции; создавать и сопровождать приложения, ориентированные на данные, используя меньше кода, чем в традиционных приложениях. Поскольку Entity Framework является компонентом .NET Framework, приложения Entity Framework могут работать на любом компьютере, где установлена платформа .NET Framework, начиная с версии 3.5 с пакетом обновления 1 (SP1).

Пример Entity Framework container:

В данном исходном коде описываются entity - объекты трансляции базы данных в ООП модели, это важно для дальнейшей реализации всей программы

using System;

using System.Collections.Generic;

using System.Data.Entity;

using System.Linq;

using System.Web;

namespace DataService.Entity

{ public class DBEntities : DbContext

{ public DBEntities():base(nameOrConnectionString: "DBEntities") { }

public DbSet<Syllabus> Syllabuses { get; set; }

public DbSet<Subject> Subjects { get; set; }

public DbSet<Status> Status { get; set; }

public DbSet<Role> Roles { get; set; }

public DbSet<User> Users { get; set; }

public DbSet<Rup> Rups { get; set; }

}}

3.7 Возможности С#

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

C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет строгую статическую типизацию, поддерживает полиморфизм, перегрузку операторов, указатели на функции-члены классов, атрибуты, события, свойства, исключения, комментарии в формате XML. Переняв многое от своих предшественников -- языков C++, Delphi, Modula и Smalltalk -- С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем: так, C# не поддерживает множественное наследование классов (в отличие от C++) или вывода типов (в отличие от Haskell).

Почему Си-шарп? Языков программирования есть очень много и все они разные и предназначены для решения различных задач. Си-шарп отлично подходит для быстрого написания настольных приложений с удобным интерфейсом. Кроме того, он относится к одному из языков технологии ASP.NET для разработки веб-приложений. Этот сайт, грубо говоря, написан на С#. Он отлично подходит для того, чтобы с него начинать изучение программирования. Востребован и перспективен. Главной альтернативой С# является Java. И у первого и у второго языка есть свои преимущества и недостатки.

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

Как объектно-ориентированный язык, C# поддерживает понятия инкапсуляции, наследования и полиморфизма. Все переменные и методы, включая метод Main - точку входа приложения - инкапсулируются в определения классов. Класс может наследовать непосредственно из одного родительного класса, но может реализовывать любое число интерфейсов. Для методов, которые переопределяют виртуальные методы в родительском классе, необходимо ключевое слово override, чтобы исключить случайное повторное определение. В языке C# структура похожа на облегченный класс: это тип, распределяемый по стопкам, реализующий интерфейсы, но не поддерживающий наследование.

Для сохранения в БД:

Обновление предметов в окне Создать силлабус.

private void refreshSubjects()

{

using (DataServiceClient client = new DataServiceClient())

{

var subjects = client.GetSubject();

Subjects = subjects.ToList();

}

Subject.ItemsSource = Subjects;

}

Приложение "Подготовка к новому учебному году " реализована на базе реляционной СУБД (системы управления базами данных) PostgreSQL.

3.8 Краткое описание PostgreSQL

PostgreSQL - это полноценная SQL СУБД с большим списком возможностей и огромным количеством людей по всему миру, которые используют и разрабатывают эту СУБД. В отличие от ещё одной свободной СУБД: MySQL, разработка которой изначально ориентировалась на веб, разработка PostgreSQL ориентировалась на использование в сложных приложениях. Именно поэтому упор всегда делался на надёжность, наличие развитой функциональности и соответствие стандартам. При этом, конечно, PostgreSQL можно точно также использовать и в веб-приложениях, где данная СУБД показывает неизменно отличные результаты, при лучшей масштабируемости и настраиваемости. Пример таблиц показана на рисунке 13:

Рисунок 13. SQL - таблицы

Вывод по третьей главе.

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



4. Проектирование конструктора бизнес-процесса (workflow engine) базы данных

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

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

При дальнейшем исследовании было обнаружено что это является коллекцией запросов(Requests) состояния(States), Переходов(Transitions), действия(Actions), и т.д. это и является рабочими процессами.

4.1 Что такой рабочий процесс(Workflow)

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

Рабочие задания получают и обрабатывают сотрудники предприятия (исполнители) с помощью средств информационной системы в рамках настроенных правил выполнения процесса (моделей бизнес-процессов). Бизнес-процесс разбит на серию функций (задач), которые необходимо выполнить в совокупности для реализации цели процесса. Организации имеют множество бизнес-процессов, которые могут быть автоматизированы в рамках системы workflow. На каждой функции в выполнении поставленной задачи принимают участие различные исполнители или рабочие группы. Иногда выполнение задачи занимает достаточно длительное время и в ней участвует несколько организаций. Для упрощения выполнения совокупности задач процессов применяются информационные системы класса Workflow.

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

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

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

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

Рисунок 14. Блок-схема повторяемых процессов

4.2 Таблицы Процесс и Пользователи

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

Процесс

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

Таблица Процесс очень прост , так как содержит только ID и Имя, как показана на рисунке 15:

Рисунок 15. Таблица Process

Эта таблица -центральная точка отсчета для остальной части конструкции; большинство таблиц в этой базе данных (например, States, Transitions, Requests, и т.д.) должны быть связаны в этой таблице, прямо или косвенно.

Пользователи

Также нужна таблица список пользователей, которые могут войти в это приложение; это будет таблица соответствия, который имеет все наши пользователи в этом приложении. Это будет выглядеть как на рисунке 16:

Рисунок 16. Таблица User

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

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

Администраторы Процессов

Также нужно для небольшого набора пользователей возможность редактировать сам процесс т.е. Администраторы процессов. Таблица для Администраторов процесса имеет взаимосвязь между таблицей Процесс и Пользователи many-to-many как показано на рисунке 17:

Рисунок 17. Связь между таблицами

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

4.3 Таблицы Детали Запроса и Данные

Части Запроса.

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

Основная информация: название(title), дата создания(a create date), создать пользователя(a create user) и текущее состояние ID(state ID).

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

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

Файлы: Любые физические файлы, которые относятся к отдельному Запросу.

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

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

Основы Запроса.

Запросы являются уникальными для процессов; Запрос может существовать только в одном процессе. Основному Запросу нужен только одна часть информации от пользователя (название) и остальная основная информация Запроса зависит от работы Процесса. Таблица Запроса выглядит как на рисунке 18:

Рисунок 18. Таблица Request

· Title (Название): Название Запроса.

· CurrentStateID: Идентификатор состояния Запрос в настоящее время.

Запрос данных

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

Рисунок 19. Таблица RequestData

Полный дизайн с Request и RequestData показана на рисунке 20:

Рисунок 20. Таблица связь между таблицами

Теперь нужны три дополнительные таблицы, чтобы знать что включает в себя запрос. Сначала это заинтересованные стороны(Stakeholders).

Заинтересованные стороны(Stakeholders)

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

Рисунок 21. Таблица RequestStakeholders

Примечания и файлы

Чтобы пользователи могли добавлять Примечания на Запрос, например, что они могли записывать дополнительную информацию, не содержащиеся в данных Запроса или Состояния. Таблица Примечания выглядит как на рисунке 22:

Рисунок 22. Таблица RequestNote

Для того, чтобы пользователи могли загружать файлы, относящиеся к Запроса непосредственно в эту базу данных (более расширяемой решение может быть для хранения файлов на файловом сервере где-то, но для простоты мы будем хранить файлы в базе данных для этой конструкции). Нужно хранить имя файла, тип MIME, и фактическое содержание файла в этой таблице. Таблица RequestFile представлена на рисунке 23:



Рисунок 23. Таблица RequestFile

После реализации информации Запроса, полный дизайн показан на рисунке 24:

Рисунок 24. Таблица связь между таблицами

4.4 Таблицы Состояние(States) и Переходы(Transitions)

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

Виды Состоянии(State Types)

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

Рисунок 25. Таблица StateType

Эта таблица всегда будет иметь следующие значения как на рисунке 26:

Рисунок 26. Значения таблицы StateType

Start: Должен быть только один раз для процесса. Это состояние где новый Запрос помещается, когда он создается.

Normal: обычная состояние без специального обозначения.

Complete: состояние, означающее, что любой Запрос в таком состоянии завершили нормально.

Denied (Отказано): состояние, где любой Запрос в таком состоянии было отказано (например, никогда не начиналась и не будет работать).

Cancelled (Отменено): состояние, означающее, что любой запрос в таком состоянии был отменен (например, работа была начата, но не завершена).

Состояния(States)

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

Рисунок 27. Таблица State

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

Переходы(Transitions)

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

Рисунок 28. Таблица Transition



Структура базы данных (с указанием только состоянии, переходов и таблицы процесса) выглядит как на рисунке 29:

Рисунок 29. Связь между таблицами

4.5 Таблицы Действия(Actions) и Деятельности(Activities)

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

· Действия(Actions): То, что пользователь может выполнять на Запрос.

· Деятельность(Activities): Результат перемещения Запрос к определенному состоянию или следующему конкретному Переходу(Transition.).

Действия(Actions)

Действие - это то, что пользователь может выполнять по Запросу(Request)(например утверждение документа).

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



Рисунок 30. Таблица ActionType

Так же, как в таблице StateType, эта таблица зависит от Процесса и постоянные. Для базы используется следующие типы Действий(Action Types) , которые показаны на рисунке 31:

Рисунок 31. Значение таблицы ActionType

Утвердить(Approve): предполагается, что Запрос должен перейти к следующему Состоянию.

Запретить(Deny): предполагается, что Запрос должен перейти к предыдущему Состоянию.

Отмена(Cancel): предполагается, что Запрос должен перейти к Состоянию Отменено(Cancelled state) в этом Процессе.

Перезапуск(Restart): предполагается, что Запрос будет перемещен обратно в состояние Start в Процессе.

Решение(Resolve): предполагает, что Запрос перемещается к Состоянию Завершено(Completed state).

Таблица для самих действий. Действия(Actions) являются уникальными для Процессов, и каждый имеет ActionType, поэтому таблица выглядит как на рисунке 32:

Рисунок 32. Таблица Action

Для ActionTypes и Action выглядит как на рисунке 33:

Рисунок 33. Связь между таблицами

Переходы Действии

Отношения между Переходом(Transition) и Действий(Action) является many-to-many (многие-к-многим) как показано на рисунке 34:

Рисунок 34. Связь между таблицами



Деятельность(Activities).

Деятельность -это то, что может произойти в результате Запроса ввода Состояния или после Перехода.

Например, на рисунке 13.

Рисунок 13. Блок-схема повторяемых процессов

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

Была создана таблица для того чтобы знать какие виды действий можно сделать. Эта таблица, как и StateType ActionType, не является уникальным для Процесса и может рассматриваться постоянный. Вот дизайн для таблицы ActivityType показана на рисунке 35:



Рисунок 35. Таблица ActivityType

Так же, как ActionType, значения ActivityType статичны. Его значения показаны на рисунке 36:

Рисунок 36. Значение ActivityType

Добавить Примечание(Add Note): Указывает, что нужно автоматически добавить примечание на Запрос.

Отправить на e-mail(Send Email): Указывает, что нужно отправлять по электронной почте одному или нескольким получателям.

Добавить заинтересованные стороны(Add Stakeholders): Указывает, что нужно добавлять один или несколько лиц в качестве заинтересованных сторон по этому Запросу.

Удалить заинтересованные стороны(Remove Stakeholders): Указывает, что нужно удалять один или несколько заинтересованных сторон из этого Запроса.

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



Рисунок 37. Таблица Activity

Состояние и Переход деятельности

Взаимосвязь Деятельности с Состоянием и Переходом в двух ситуациях:

- Когда Запрос переходит в Состояние

- Когда Запрос следует Переход

Это означает необходимо связать Деятельность с Состоянием и Переходом, например, как рисунке 38:

Рисунок 38.Связь между таблицами

Схема базы данных (показывающий Процесс, Состояние, Переходы, Действия, и Деятельности) выглядит следующим образом, как на рисунке 39:



Рисунок 39. Схема базы данных (Процесс, Состояние, Переходы, Действия, и Деятельности)

4.6 Таблицы Группы и Задачи (Groups and Targets)

Теперь нужно определить кто именно может выполнять Действия или получать Деятельности это Задачи(Targets).

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

Группы

Группа - группа пользователей, которые выполняют соответствующие функции.

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

Таблица Группа довольно прост как на рисунке 40:



Рисунок 40. Таблица Group

И таблица для представления, какие пользователи в данной группе, которая имеет взаимосвязь many-to-many . Эта таблица называется GroupMember, рисунок 41:

Рисунок 41. Таблица

Задачи(Targets)

В этой системе люди ориентированы; только люди могут совершать действие Запросом. Чтобы связать лица (или группы) которые могут выполнять Действия и получать Активности было создано таблица Задачи. Задачи является набор стандартных представлений человека, которые имеют определенные роли по отношению к Запросу или Процессу. Используется следующие цели:

· Создатель Запроса (Request Creator, Requester)

· Запрос Заинтересованных лиц (Request Stakeholders)

· Участники группы(Group Members)

· Администраторы Процесса(Process Admins)

Таблица Задачи выглядит как на рисунке 42:



Рисунок 42. Таблица Target

Это еще один статическая таблица (как StateType, ActionType и ActivityType). Вот данные, которые используется для этой конструкции показаны на рисунке 43:

Рисунок 43. Значение таблицы Targets

Задачи Действии и Задачи Активности (Action Targets and Activity Targets)

Таблица Задачи нужен в двух случаях:

· какие люди могут выполнять соответственные Действия

· в какие люди могут получить Активности

т.е. нужно определить, кто и какие действительно может представить Действия чтобы считаться действительным. Ведь мы не хотим, чтобы дворник Абзал утверждал Рабочий Учебный План Университета. Имея это в виду, дизайн таблицы выглядит как на рисунке 44:

Рисунок 44. Таблица ActionTargets

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

В зависимости от вида деятельности Задачи для этой деятельности разные например может получать электронную почту, или быть добавлены в список заинтересованных сторон для запроса, и т.д. Таблица ActivityTarget похожа на таблицу ActionTarget и показана на рисунке 45:

Рисунок 45. Таблица ActionTargets

Зависимости какие отношении Группы с Задачей:

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

Если Группа это Деятельность Задачи, то все члены группы получают деятельность (например, каждый в группе получает письмо).

Дизайн для Действий, Деятельности, Группы и Задачи выглядит как на рисунке 46:



Рисунок 46. Связь между таблицами

Запрос Действия (Request Actions)

Последним кусочком схемы является таблица Запрос Действия, рисунок 47.

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

Рисунок 47. Таблица RequestAction

Эти последние две колонки (IsActive и IsComplete) очень важны для фактического исполнения этой таблицы.

Использование этой таблицу.

1. Когда Запрос переходит в Состояние, мы получаем все исходящие Переходы из этого Состояния. Для каждого Действия в этих Переходах, нужно добавить запись в RequestAction, с каждой записью, имеющей IsActive = 1 и IsCompleted = 0.

2. Пользователь может представить Действие в любой момент. Каждый представленное Действие состоит из ActionType, в RequestID, и UserID.

3. Когда Действие представляется, проверяется RequestActions для указанного Запроса. Если представленное Действие совпадает с одним из активных RequestActions (где IsActive = 1), устанавливает, что IsActive = 0 и IsCompleted = 1".

4. После обозначения представленного Действия как заполненную, проверяется все Действия для этого Перехода в этом Запросе. Если все RequestActions отмечены как Выполнены(Completed), то отключаем все остальные действия (путем установки IsActive = 0, например, все действия для Переходов, которые не соответствуют).

Пример Пошаговое руководство:

USERS: Jane (ID 1), Tom (ID 2), Gary (ID 3)

GROUPS: Руководство (ID 1), включает Tom и Gary

STATES: A (Type: Start), B (Type: Normal), C (Type: Denied)

TRANSITIONS: A -> B (ID 1), A -> C (ID 2), B -> C (ID 3)

TRANSITION ACTIONS:

1)A -> B: Утверждено Запрашивающим (Requester) (ID 1) AND Утверждено руководителем(ID2)

2) A -> C: Отказано Руководителем (ID

3) B -> C: Отказано Запрашивающим (Requester) (ID 4)

Например Джейн создает Запрос, который сразу же помещается в Состояние А.

На этот момент, система ищет всех исходящих переходов из Состояния А и находит два из них, Переходы 1 и 2. Затем она загружает следующие данные в RequestActions:

Таблица 3. Данные в RequestActions

RequestID	ActionID	TransitionID	IsActive	IsComplete
1	1	1	YES	NO
1	2	1	YES	NO
1	3	2	YES	NO

Теперь Запрос просто сидит в своем нынешнем Состоянии, ожидая Действий, которое будет утверждено.

Jane представляет это действие:

ACTION: 

User ID: 1 

ActionType: Approve (Утвердить)

Request ID: 1 

( «Пользователь 1 одобряет Запрос 1")

Так что Действия совпадает с первым RequestAction в таблице, он отмечается как завершенной:

Таблица 4. Данные в RequestActions(действие Jane )

RequestID	ActionID	TransitionID	IsActive	IsComplete
1	1	1	NO	YES
1	2	1	YES	NO
1	3	2	YES	NO

В данной ситуации , все Действия не соответствует для Перехода, так что ничего не происходит на Запрос; он остается в Состоянии А.

...