运用图式分析抽取业务逻辑

从最早的电话交换网络,人们打电话需要由接线员在机房负责搭建两段通话桥梁,传统的纯纸介质财务记账已渐渐演化为电子记账,纸介质的已更多是负责存根与报表打印。随同时代科技的进步,许多企业单位在进行自己的传统业务与时,还依赖于一种人工手动处理阶段,有些也在开始尝试运用电子信息化构建自己的自动化协助处理平台,以支持日趋扩大的规模,各种横向的业务扩展以及纵向的业务数据分析辅助决策。这种电子信息化的需求将依然保持旺盛发展。

在面向领域的商业解决方案中,这里侧重于面对企业信息化建设,一大重点在于理清领域业务逻辑,生命周期,与职权范围,其他的大致也都是存储,获取,更新,分析,展示几大部分的BS或CS结构,自身的一点体验是运用合理的流程图去明确话领域业务逻辑。

通常,面向那些围业务与数据的流程处理案例,如信用卡申请审批流程,一方面牵扯到用户角色Role的界定(确定权限与职责),另一方面牵着业务进行到的阶段(确定数据状况与Role的关联)。确定好了这二维交叉关系,基本可以初步勾勒业务处理逻辑了。

下图为一个实际案例中的状态图,其中圆形标识了在整个业务流程中的所处状态,而箭头及标识标明影响对应状态变迁的时间与说指向的下一状态。

State Logic Flow

这种图展现在一种程式状态机,尽量从纷繁错杂的业务逻辑中抽取归纳出明确的状态,和变迁的时间,事实上这也是将现实中逻辑事务转交给机器解决的一重大关键之处,机器实际上是不能自动理解人的思维,机器为什么能够“智能”的解决一些问题,是因为已经把所有可变因素与程式给加载与程序内部。也就是说,理清业务逻辑也就是要明晰那些是变的,那些事不变的,消灭掉模菱两可的状态间一对多或多对多的关系,让我们集中注意力处理那些可变因素,做量化条理化,在业务开发中提供一个可达路径。

状态图(Statechart Diagram):是描述一个实体基于事件反应的动态行为,显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的:研究类、角色、子系统、或组件的复杂行为。

但是状态图中主要是反映业务状态上的这个维度变迁,另外一维度用户角色Role并没有展现出来,那么泳道图则是一个很好的表达方式了:

泳道图:一种UML活动图,能够清晰体现出某个动作发生在哪个部门。

泳道流程图(Swimlane Flowcharts)是一种反映商业流程中人与人之间关系的特殊图表。

Swimlane Workflow-SUM

上图是对一个部门的所有业务逻辑的一个聚合的全集分析,在纵坐标界定了用户角色与职责,横坐标界定了业务流程步骤,而内容取的各个状态会对应清晰的分布在Role与Step间,指尖的箭头与说明界定了触发事件与下一步状态,当然横纵坐标可以互换。

这一步在构建业务数据逻辑LDM(logic data model)也是具有指导与明确目的的作用。

但是在具体分析中,多个分支逻辑糅合在一起会有一定的干扰影响,通常,人如果能将目标集中放在一处,就做的更专一更优秀,同样看业务处理的结果不同,可以进行定性划分了几种枝干业务流程,也就是将Sum中的一团麻拆分为一个个更容易理解的Sub支线。如下图:

Swimlane Workflow-SUB for Approved (detail for download

上图分支流程图,按照业务处理性质与结果,划分的一种大的子类- Approved,即被通过的案例,图中只画出了Approved说需要的各个状态与步骤。

如果理清了各种子流程,结合构建共识的LDM后,可以更好的指导按照水平或者垂直的层次进行协同开发了。 附: