今年6月初，接到客户关于“集团客户事业部大客户项目订单”新需求，其业务设置了正常流程和升级流程（是指流程参与者增加了领导，对应的表单发生很小变化）。当时的解决方案是对表单做编程处理，解决差异性问题。

今天，与开发人员讨论设计时，发现专业信息应用类业务的管理，也面临类似情况，例如安全生产管理信息、信息专栏中，非流程类的业务，需要填写多张表单。

到此，对能力平台的设计应该做点儿调整，增加允许一个业务对应多个表单（也是具体某业务）。

设计方案见下文描述。

业务开始

先从模拟业务开始，模拟业务申请处理过程，“流程业务通常情况是这样的，工作人员填写业务申请单（填写表单），并准备好相关资料（添加附件），把业务申请单和资料打包（保存）后，送出传递给流程下一环节审批人。”，详见下图描述。

• 业务目录：为业务分类及具体业务的树形结构，叶子节点一般为业务表单名称；
• 业务申请单：为填写业务信息的申请表单，表单可以在多个流程上流转。

业务信息模型

业务模型描述

• 信息类业务，例如信息专栏，由多组信息构成，每组信息多有不同，在这里把这种信息看作表单式业务。因此，信息专栏/应用由多个通用信息或表单构成。
• 业务流程，一个业务可以对应多个表单，每个表单所对应的业务又可以拆分为多个独立的流程。

数据库关系模型

注：表单文档存储在文档型数据库（MongoDB）中，不在此体现。

关于业务分类管理

业务分类管理不是固定的，从软件系统角度来看是可以任意变化的，在设计上使用属性表的模式管理。

/*属性表*/
create table BPM_MANAGER.SM_ATTRIBUTE
(
  ATTR_ID      VARCHAR2(50) not null,
  ATTR_TYPE_ID VARCHAR2(50) not null,
  ATTR_VALUE   VARCHAR2(30) not null,
  ATTR_CODE    VARCHAR2(30),
  SORT_NO      INTEGER,
  STATUS_SIGN  INTEGER default 1 not null,
  ATTR_DESC    VARCHAR2(50)
)

/*属性类型表*/
create table BPM_MANAGER.SM_ATTRIBUTE_TYPE
(
  ATTR_TYPE_ID VARCHAR2(50) not null,
  TYPE_NAME    VARCHAR2(30) not null,
  TYPE_CODE    VARCHAR2(30),
  STATUS_SIGN  INTEGER default 1 not null,
  DESC_MEMO    VARCHAR2(200)
)

数据使用情况举例：

• 属性类型定义

• 属性定义

业务信息展现

业务信息展现分为业务定义信息展现和业务运行实例信息展现两种情况。

业务信息定义展现

业务信息展现界面如下图所示，由业务基础信息、表单、流程列表、流程评价（也叫业务评价）构成。其中，表单可能存在多个，那么对应的流程列表随着表单而变化。

注：上图中，遗漏附件，用于存储业务介绍文档（来源于业务开发时的需求），包括业务描述文档、流程图、表单等。因此，设计时把文档及图做为附件方式进行展现。

展现操作过程参考如下顺序图。

注：业务信息定义包含“业务全生命周期管理”，支持查看历史版本。

业务实例展现

设计对比分析

原设计

参照上述描述，原设计是业务下包括表单（1对1关系）和流程（1对多或1对0关系）。

在此设计模型下，针对开篇的需求，开发人员的解决方案是编码控制表单。相当于个性化处理。

注：原设计编码实现情况，业务信息展现内容不完整，偏离设计较大；开始业务申请部分，入口偏离设计较大，而填写表单及启动流程部分属于核心功能，大部分实现，且基本不受影响。

设计对比分析

注：专业信息是指无工作流的填写表单的业务，例如安全信息管理。

结论

通过上述分析，在业务流程部分编码阶段、信息管理设计阶段，为了满足用户需求，此设计变更方案是比较合理，且工作量变动不大，可以进行后续设计讨论。

参考：

1.用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路（二，续） 肖永威 2015年1月1日
2.UML建模实践——选“对”企业架构建模视角很关键 肖永威 2015年4月6日

2015年6月30日