基于分布式流程引擎业务建模方法V02Word文件下载.docx

基于分布式流程引擎业务建模方法V02Word文件下载.docx

《基于分布式流程引擎业务建模方法V02Word文件下载.docx》由会员分享，可在线阅读，更多相关《基于分布式流程引擎业务建模方法V02Word文件下载.docx（13页珍藏版）》请在冰豆网上搜索。

摘要4

1.业务建模的步骤5

2.需求分析5

3.业务流程定义6

4.业务要件定义6

4.1业务概述6

4.2流程定义7

5.任务定义11

6.数据对象定义14

7.画面定义14

8.设计REVIEW方法15

修改历史

更新时间

修改人

版本

章节

备注

2014-06-06

李海

0.1

新建

孟祥宝

0.2

原有内容进行细化，并增加数据对象定义、画面定义、设计REVIEW方法说明

摘要

本手册是基于我公司的分布式流程引擎框架，以实际业务为例，给出从业务要件定义开始，到任务收取，活动设计的完整业务建模的方法。

1.业务建模的步骤

1）需求分析

2）业务要件定义

3）流程任务定义

4）任务、活动设计

2.需求分析

需求分析，一般是通过现场调研的方式，和客户一起整理分析业务上的需求。

在充分理解客户现有业务的基础上，帮助客户理顺业务，并为客户设计出完善合理、满足客户业务需求的流程。

以河南省研究生管理云平台为例:

通过调研分析，针对研究生管理，需要有如下几大类主要业务（以一个学生从报考到毕业为主线）：

⏹招生管理

⏹学籍管理

⏹培养管理

⏹学生工作管理

⏹学位管理

然后针对每类业务，通过流程图的方式，准确的描述出客户的需求

参照如下模板：

3.业务流程定义

4.业务要件定义

要件定义是针对需求分析中的每类业务，进行细化，明确功能范围，包括如下两部分：

1.要件概述

⏹业务概述

⏹管理对象和用户规模

⏹生命周期

⏹管理内容

⏹业务事件

⏹主要的业务字典

2.流程定义

⏹归纳分析业务步骤中线上或者线下

⏹定义流程模板

4.1业务概述

以学籍管理为例

1）概述，明确管理对象及规模、生命周期、管理内容

2）业务事件

根据需求分析，存在如下业务事件与学籍相关：

新生入学，新生信息采集，在籍生报到注册，休学等学籍异动，毕业等

针对每个业务事件，是不是对所有的学生都是一样的呢？

这时暂时不确定，当做处理是不一样的，所以每个业务事件针对不同的对象，进一步细化，即每种对象都有各自对应的业务事件

对于每个事件的描述中，要描述清楚谁，在什么时候，什么地点，做什么事情，如何做，即who、when、where、what、how

3）业务字典

在分析业务事件的过程中，同时整理出业务字典

参考模板：

4.2流程定义

基于概述中定义的业务事件，根据业务事件对象，实际业务处理，来确定各个业务流程。

对于同一个业务事件，可能对每个对象都是一个不同的流程，也可能该业务事件对每个对象的处理是一样的，即作为一个流程。

另外，通过分析，不同的业务事件也可能作为一个流程来实现。

对于每个流程，首先要明确这个流程执行的前提条件、用户角色、处理的业务对象

第一步

针对业务概述中定义的业务事件进行分析细化，详细描述每个事件的完整的业务处理过程，不管是系统内还是系统外的。

原则上，每种业务事件对应一个ProcessMeta，而每个对象对应的业务事件作为这个业务事件的一个Template来实现。

比如，新生入学这个业务事件，针对两个业务对象，统招的和转学的，那么统招的和转学的入学事件就是新生入学这个ProcessMeta的两个Template。

第二步

基于第一步的业务处理流程，确定出那些业务处理是系统实现的，那些事系统外做的

第三步

基于第二步的分析，定义每个流程中的Task，即那些系统内的操作可以作为一个Task

第四步

根据定义出来的Task，定义出每个ProcessTemplate

要件定义实例参考：

5.任务定义

基于上一部流程的定义，针对每一个Task进行设计。

首先要详细说明该任务的执行频次，角色、前提条件、业务规则及该任务的输入输出参数（业务对象）；

然后设计该任务中的Activity，即该任务具体由哪些业务活动组成，每个业务活动是什么类型的，比如是画面，提供用户交互的活动，还是系统做的业务处理等，并通过图形方式，描述出该任务执行的过程。

下面以研究生报到注册为例：

明确该任务执行的一些前提条件，输入输出、业务规则等：

然后列出TaskTemplate列表，对每一个TaskTemplate进行说明，并定义出TaskTemplate在XML中的名称。

同一个TaskMeta下的所有Template都写到一个设计文档中：

归纳定义该任务中的业务活动，进一步定义出所有的Activity，包括：

1、该TaskTemplate的功能说明，每一步说明涉及到的对象，且数据对象的名字要和数据对象定义中的对象名字保持一致

2、ActivityMeta列表，即该TaskTemplate下面可以定义的ActivityMeta列表说明，包括ActivityMeta名称（中文）、配置ActivityMeta名（XML中配置名）、ActivityMeta主操作对象（对象名字要和数据对象定义中的对象名字保持一致）、输入输出说明（输入输出要求详细，不能笼统地描述输入输出参数，要将每一个参数说明清楚，参数名字要和数据对象表中的字段名字保持一样）

3、ActivityMeta所对应的ActivityTemplate列表说明，包括Activity模板名称（中文）、配置Activity模板名（XML中配置名）、所属Activity的Meta、Activity主操作对象（对象名字要和数据对象定义中的对象名字保持一致）、执行类型（自动或者画面发起）

第三步：

定义出Task执行的详细流程图，包括每一个Activity的详细说明，说明要求详细，最基本的要求包括以下几点：

1、流程的发起描述

2、后台每一个Activity执行的过程

3、Activity之间输入输出参数之间的关系

4、每一个Activity向前台返回的内容，包括画面ID或者其他数据

5、流程的结束描述

第四步：

1、定义每个Activity下的Function列表说明，包括：

包括Function名称（中文）、配置FunctionMeta名（XML中配置名）、Function主操作对象（对象名字要和数据对象定义中的对象名字保持一致）、Function输入输出（输入输出要求详细，不能笼统地描述输入输出参数，要将每一个参数说明清楚，参数名字要和数据对象表中的字段名字保持一样）。

2、定义Activity流程图以及详细的流程图说明：

说明要求和Activity流程图中的每一个Function定义保持一一对应。

每一个Function说明使用序号标注，先进行文字简单描述，再使用类SQL语言进行描述具体操作的数据对象、输入和输出参数。

任务定义参考模板：

6.数据对象定义

定义出该Task涉及到的所有数据对象，包括属性名称（中文）、属性名称、字段类型、限制、备注说明（属性格式、属性数据集等）

7.画面定义

画面定义包括画面原型、以及画面原型说明，画面原型说明包括：

1、画面初始化说明，如画面打开的时候画面上的默认值都是什么

2、级联查询的下拉框，默认值分别是什么

3、不同的角色打开画面的初始化值

4、如果控件绑定的后台数据，需要说明数据的来源

5、必输项说明

6、点按钮后前台向后台传递的数据

8.设计REVIEW方法

1、建立REVIEW、REVIEWING和Finish三个文件夹

2、设计人员将设计好的设计文档放到REVIEW文件夹中，设计文档从V1.01版本开始命名

3、REVIEW人员到REVIEW文件夹中将设计好的设计文档拷贝到REVIEWING文件夹中进行REVIEW，REVIEW通过的设计文档存放到Finish文件夹；

REVIEW不通过的设计文档在设计文档中进行批注。

4、设计人员每天到REVIEWING文件夹中查看自己最新版本的设计文档是否有批注，如果存在批注信息的设计文档，在REVIEW文件夹中按照批注信息进行完善修改设计文档，修改完毕将文档版本号增加至V1.02

5、REVIEW人员到REVIEW文件夹中查看是否存在新版本的设计文档，如果存在就继续3的操作

6、REVIEW的流程以此类推，最终所有的设计文档都被存放至Finish文件夹，供CODING人员使用。