业务对象状态图模式

目录

版本信息... 1

1. 概述... 3

1.1. 术语... 3

2. 状态图模式... 3

2.1. 数据库记录状态图... 3

2.2. 法规状态图... 4

2.2.1. 基本状态图... 4

2.2.2. 简单状态图... 5

2.2.3. 业务规则基本状态图... 5

2.2.4. 业务规则简单状态图... 6

2.2.5. 业务规则审核状态图... 7

2.3. 结算状态图... 8

2.3.1. 费用状态图... 8

2.3.2. 部分核销费用状态图... 9

2.3.3. 结算单据状态图... 10

2.4. 问题处理状态图... 11

2.5. 单据管理状态图... 12

2.5.1. 单据管理基本状态图... 12

2.5.2. 单据管理简单状态图... 13

2.5.3. 单据管理存档状态图... 14

 

 

业务对象状态图模式

1. 概述

关键业务对象的状态转换对于分析应用系统应该包含哪些功能，明确功能需要实现的业务逻辑以及正确实现应用功能都是非常重要的，然而业务对象状态分析具有较大难度。在不断的功能分析和应用开发过程中， 我们对很多业务对象进行了状态分析，绘制了其状态图，并且依据这些状态图进行功能的分析和程序实现，在程序被使用的过程中又发现了原来的状态图存在的问题，然后修改状态图使其进一步趋于完善。

在对业务对象进行状态分析的过程中，我们也发现很多业务对象具有相同的状态图，有些业务对象的状态图则非常相似。因此如果能够将已知的业务对象的状态图进行分析整理，在遇到新的业务对象时就可以基于现有的业务对象状态分析进行套用、裁减或者扩展，这将具有下列好处：

Ø         降低业务对象状态分析的难度

Ø         提高状态分析的效率

Ø         提高状态分析的一致性

 

本文档就是基于上面的考虑，将比较成熟的状态图分析结果进行归纳整理，分析他们应用的场景以及对应业务对象在功能定义、数据库设计和应用结构设计方面的建议。

1.1. 术语

使用：状态图里的使用指被其他业务对象引用。

 

2. 状态图模式

2.1. 数据库记录状态图

数据库记录状态图是所有数据库记录缺省就具有的状态变化图，任何一个业务对象存放于数据库则必然具有这个状态图，即存储在数据库表中业务对象除了具有其自身的状态图外，还必然具有此状态图，业务对象的状态变化是两个状态图共同作用的结果。

图1 数据库记录状态图

 

数据库记录通过创建而成为存在且未被引用的状态，处于此状态的记录可以被修改、删除和引用。记录被修改并不改变其状态，但是可以改变其标识信息（如主键）；记录被删除是物理地将记录从数据库中删除；记录被引用是指记录被其他表记录作为外键引用。处于存在且被引用状态的记录只可以进行有限度的修改，不同业务记录的修改限度不同。

2.2. 法规状态图

法规状态图是一套状态图集，其中每种状态图共享相同的状态集，只是使用的状态数量和状态转换有差异，并且状态图集中的各状态图有一定的关联，可以认为是从最简单的状态图经过不断的扩展而成为了越来越复杂的状态图。

法规状态图集包含如下状态图：

Ø         基本状态图

Ø         简单状态图

Ø         业务规则基本状态图

Ø         业务规则简单状态图

Ø         业务规则审核状态图

 

法规状态图集适用于描述政策、规则、法律、标准等业务对象的状态，这类业务对象最少具有“生效”、“失效”的状态，而且有些还要求可以追溯历史情况或者需要边距复杂的发布过程。

法规状态图集共享的状态集如下：

代码	中文名称	英文名称
DFT	草稿	Draft
CFM	确定	Confirm
ASS	审核	Assess
RLS	发布	Release
ACT	生效	Active
IAT	失效	Inactive
ELN	消除	Eliminate

 

2.2.1. 基本状态图

基本状态图是只具有“生效”和“失效”两个状态的状态图。业务对象被创建后就处于生效状态，可以被使用，失效、限制修改。当业务对象处于“失效”状态时只可以将其变为生效状态不允许进行任何其他操作。

基本状态图一般用于管理应用的基础信息，如性别、职位、价格登记等。例如职位表中有“总经理”、“副总经理”、“总监”、“高级经理”、“经理”、“主管”、“组长”、“员工”等，最初这些职位都被使用，但是可能公司改变职位体系，将“总经理”改为“总裁”，则可以将总经理这个记录的状态变为失效，而新增加总裁记录且处于生效状态。

基本状态图且存储于数据库表的业务对象其状态和行为是两状态状态图和数据库记录状态图共同作用的结果，在分析具有两状态状态图的业务对象的行为和状态变化时应该将两种状态混合考虑。做法是建立状态表，看两个状态图的组合状态是否可能存在，再根据每个状态的可执行动作查看组合状态的动作。

图2 基本状态图

2.2.2. 简单状态图

简单状态是指具有“草稿”、“生效”、“失效”状态的状态图。通过创建生成草稿状态的业务对象，处于草稿状态的业务对象可以被修改、生效，而不可以被使用；处于生效状态的业务对象可以被使用、失效、限制修改，当它未被引用时还可以被撤销生效；处于失效状态的业务对象可以被生效。

简单状态图比基本状态图进展了一步，在维护业务对象时可以在草稿状态多次修改，到适当的时候再使其生效。但是简单状态图仍然存在两方面的问题，一是没有历史可追踪，二是不能支持多层审批的情况。简单状态图适用于系统规则的管理，系统规则是由程序逻辑总结出的规则，程序根据系统规则存储的信息决定该如何执行，由于系统规则比较复杂，维护过程比较长，所以需要草稿状态，另外由于是系统级的规则所以不必进行审核、审批等的管理，且历史上的规则是什么并不是非常重要，因此使用简单状态图是比较恰当的。

图3  简单状态图

2.2.3. 业务规则基本状态图

业务规则基本状态图在简单状态图的基础上增加了“发布”、“消除”状态，并且业务对象具有生效日期和失效日期，从而具有业务规则基础状态图的业务对象可追溯其历史。

通过创建产生草稿状态的业务对象，在草稿状态下可以消除、发布和修改业务对象；处于消除状态的业务对象不可以做任何动作（不能被外部引用，但是可以被用来作为模板创建新的业务对象）；处于发布状态的业务对象可以撤销发布或变为生效状态，需要注意的是转变为生效是由于时间的变化而自动的，并非外界的动作；处于生效状态的业务对象可以被使用或转变为失效状态，并且转变为失效状态也是由于时间的变化而自动的。

由于业务规则是需要追溯其历史的，即历史上规则是什么样是需要知道的，所以一旦业务规则生效后就绝对不允许修改，因为生效了就认为已经使用，使用了就不能再做任何修改，否则将不能知道历史上规则是如何设置的。当业务规则还没有失效时，业务规则中的失效日期其实是没有被使用的，则此时是可以修改业务规则的失效日期的，但是修改后的失效日期必须大于当天，即失效日期必须大于当天才可以被修改，且修改结果也必须大于当天。业务规则基本状态图适用于业务规则的管理，业务规则是指为了规范业务管理而制定的各业务职能的规则，业务规则直接影响到业务的执行，因此当业务出现问题时必须明确问题出在哪里？是规则的问题还是执行的问题，所以业务规则需要追溯历史。

图4  业务规则基本状态图

 

2.2.4. 业务规则简单状态图

业务规则简单状态图在业务规则基本状态图的基础上增加了“确定”状态，这样具有业务规则简单状态图的业务对象就可以具有更加复杂的发布流程，即可以在完成编辑后将业务对象保存为“确定”状态，然后由权限更高的角色发布业务对象。

虽然业务规则简单状态图已经支持了一定程度的发布流程，但是在实践中真正需要的发布流程远比业务规则简单状态图复杂。因此后面会在业务规则简单状态图的基础上增加审核状态从而支持更复杂的发布流程。但是这样不断通过增加状态并不能解决所有问题，因为在复杂的审核审批流程中往往还涉及发布的分支和合并问题，支持更复杂的发布流程的方法是在业务规则简单状态图的基础上外挂发布处理流程，一旦业务对象进入确定状态即开始启动外挂发布流程，只有在外挂发布流程通过后业务对象才成为发布状态。

图5  业务规则简单状态图

2.2.5. 业务规则审核状态图

业务规则审核状态图在业务规则简单状态图的基础上增加了“审核”状态，使得业务对象可以进行更复杂的发布流程。目前价格表使用业务规则审核状态图。

图6  业务规则审核状态图

2.3. 结算状态图

结算状态图是结算相关的状态图集，各状态图共享相同的状态集。结算状态图集包括：

Ø         费用状态图

Ø         结算单据状态图

2.3.1. 费用状态图

费用状态图适用于描述应收、应付费用的生命周期。费用状态图包括“草稿”、“确定”、“出帐”、“核销”、“消除”和“不存在”几种状态。

费用状态图中需要注意：

Ø         人工创建的费用为“草稿”状态，系统自动创建的费用为“确定”状态。

Ø         只有处在草稿状态才可以删除和修改。

 

某些需求要求费用项目还可以部分核销，则状态图包括部分核销状态。

图7  费用状态图

2.3.2. 部分核销费用状态图

部分核销状态图在费用状态图的基础上增加了部分核销状态，当业务的单项费用金额比较大时支持费用部分核销就非常重要。

部分核销费用状态图中需要注意：

Ø         对部分核销费用状态图，对费用核销时费用处于那种状态是由核销金额决定的。

图8  部分核销费用状态图

2.3.3. 结算单据状态图

结算单据状态图在部分核销费用状态图的基础上去掉了“出帐”状态。

 

图9  结算单据状态图

2.4. 问题处理状态图

问题处理状态图是标识了问题处理的生命周期。问题是一个广义的概念，包括程序开发中的Bug，客户服务中的问题，系统支持中的故障等都适用。所有这些问题基本上都可以概括为提出问题、问题指派、处理并解决问题，为了监控问题解决的质量，最后还对问题解决进行确认，只有被最终确认的问题才认为被解决。问题处理状态图如下图所示。

问题处理状态图需要关注的要点如下：

Ø         组织内部的人员可以直接创建“确定”状态的问题，而组织外部的人员只能创建处于“草稿”状态的问题。例如对于应用系统测试，系统终端用户如果发现了Bug，可以创建一条问题记录，但是此问题记录是处于“草稿”状态的，“草稿”状态的问题记录必须经过内部测试员的确认才可以成为“确定”状态的问题记录。对于客户服务支持业务，客户可以通过公司网站等反馈问题，但是这些问题是处于草稿状态的，只有内部负责客户服务支持的人员才可以将其状态变为“确定”状态，从而认为这个问题是需要进一步处理和解决的。

Ø         指派是指将问题指派给某个人来处理并解决，处于“确定”、“指派”和“处理”状态的问题可以被指派。在问题处理和解决的过程中很可能并非最初被指派的人就可以将问题解决，而是需要再转派给其他人解决或者拒绝指派，将问题重新转化为确定状态等待再次指派。例如对于应用系统测试，某个问题发现后可能被指派给负责某模块程序的开发组长，再由开发组长进一步指派给具体的程序员。

Ø         “解决”和“关闭”状态的区别在于解决是问题处理人认为问题已经解决了，而关闭是问题处理的监控人在征询各方，特别是问题提出人的意见后认为问题确实被解决才达成的状态。只有关闭的问题才可以被认为是彻底的被解决了。

 

图10  问题处理状态图

2.5. 单据管理状态图

单据管理状态图描述单据（或单号）从最初的获得到最终使用完成的整个状态，主要适用于运单、提单、发票等等单据的管理。由于不同单据在不同公司的管理模式不同，其状态图并不完全相同，因此单据管理状态图也是状态图集，包括：

Ø         单据管理基本状态图

Ø         单据管理简单状态图

Ø         单据管理存档状态图

 

此状态图集的共享状态为：

代码	中文名称	英文名称
RG	登记	Register
AV	可用	Available
HD	占控	Hold
US	使用	Use
RT	归还	Return
AC	存档	Archive

2.5.1. 单据管理基本状态图

单据管理基本状态图包含“登记”、“可用”、“占控”、“使用”，其状态图如下图所示。

单据管理基本状态图需要关注的要点为：

Ø         单据被登记后并不能被使用，必须要标记为可用才可以使用和发放。例如一次性印刷5万张单据，则可以将单号直接登记，但是如果这5万单据都可以被使用的化，则单据会被使用得无序。所以在登记后要将单据再标记为可用，这样才可以被使用或者发放给其他人。

Ø         发放记录的是单据当前所属人，单据在最初登记后缺省归登记人保存。在标记为可用时必须标记单据由谁负责，并且还可以多次转交就通过发放这个操作。

Ø         “占控”是一个中间状态，主要是解决用户并发使用系统时，可能出现的抢号情况。当需要使用单号时，首先找到处在可用状态的单据，然后可以供用户应用，此时单据处于“占控”状态，当正式确定单据被使用后才将其变为使用状态，单据处于“占控”状态应该只是临时性的。

图11  单据管理基本状态图

 

2.5.2. 单据管理简单状态图

单据管理简单状态图在单据管理基本状态图的基础上增加归还状态，这是由于某些单据可能包括多联，在使用后某些留底联需要归还。其状态图如下：

图12  单据管理简单状态图

2.5.3. 单据管理存档状态图

单据管理存档状态图在简单状态图的基础上增加了存档状态，供某些单据需要在归还后存档的单据使用。

图13  单据管理存档状态图