CBF Studio业务建模示例（4）-业务模型设计

文章目录

一业务需求分析
二业务模型设计
三业务活动设计
- 3.1 补充业务活动上下文
- 3.2 设定执行者岗位
- 3.3 设计活动泳道图
- 3.4 设计业务动作前导后继处理
- 3.5 设计互斥网关判断逻辑
- 3.6 设计定制化任务逻辑

一业务需求分析

由客户经理发起开立个人客户信息的请求，录入相关信息，提交信息后由审查员进行审核，审查员审核通过后持久化到数据库中。为维护个人客户信息流程同上。查看个人客户信息则直接发起，不需要经过审查。
本文仅针对开立个人客户信息为例，其余业务设计交给读者。根据上述需求就可以拆分出三个业务动作：

发起个人客户信息创建
审查个人客户信息
个人客户信息入库

那么从是否需要岗位职员处理、业务动作出入口参数等维度整理需求表如下：

业务动作	类型	执行岗位	入口参数	出口参数
创建个人客户信息	人工任务	客户经理	1.基本信息；2.联系信息列表（其余信息不做演示）
审核个人客户信息	人工任务	审查员	1.基本信息；2.联系信息列表	是否通过
个人客户信息入库	定制任务

整个业务流程则由运营部处理，并且“个人客户基本信息”、“个人客户联系信息列表”、“是否通过审查”等数据需要在整个业务流程中流转，实际上审查员在驳回请求的时候是可以将请求重新打回给客户经理的，为了化简示例，就直接将流程导向至结束。

二业务模型设计

按上述需求人工任务业务模型定义：

细化岗位设置和业务接口数据：

三业务活动设计

3.1 补充业务活动上下文

前面已经将“开立个人客户信息”业务活动定义好了，但是仅仅设置了执行机构、角色和授权，接下来需要细化设计。首先补充业务活动上下文数据定义：

3.2 设定执行者岗位

设置人工任务执行角色，客户经理毋庸置疑就是发起流程的用户，而审查员的话就简单粗暴的从所有审查员岗位中找出第一个人来吧，实际上应该按某种量化维度设置的，比如说分派的任务最少、已登录等等。

3.3 设计活动泳道图

重头戏来了，利用可视化编排将整个业务流程串起来：

3.4 设计业务动作前导后继处理

前导处理的主要逻辑是从业务活动上下文中获取数据并传入业务动作的请求接口数据中，后继处理则相反：

3.5 设计互斥网关判断逻辑

需要注意的是互斥网关的分支处理逻辑判断是自上而下的，并且任何分支只要逻辑值为真，就会将流程导向至此分支的处理方向：

3.6 设计定制化任务逻辑

系统任务可以直接复用之前设计好的服务应用程序来完成相关实体数据的存储：

设计完成后发布业务工程即可。
（更多关于可视化建模开发工具的介绍可以关注领驭框架（北京）软件有限公司的微信公众号和我自己的订阅号，或者到公司主页（www.eframesoft.com）查询。）