业务流设计的规范化实现

MILY: 宋体; mso-ascii-font-family: "Times New Roman"; mso-hansi-font-family: "Times New Roman"">目前，一般管理应用系统程序设计的实现是通过分析需求，确定业务流程，设计数据库，确定各功能模块，进行系统设计，然后进行编码工作。这样一个系统工程往往需要业务员、项目经理、系统分析人员，数据库开发管理人员和编码测试人员分工合作，才能使系统顺利的进行开发。而这中间很重要的一个环节就是业务流程的确定和数据库的设计。在一般的系统开发中这是两个独立的环节，需要独立的人员和周期。由于需求的变动性，经常出现设计好的业务流程需要调整或整个修改的情况，如果这一情况出现在数据库设计前，一般处理的代价较小，也比较容易调整，但是如果数据库已经设计结束，并且很多部分已经进行了编码工作后再做这种调整就是一件代价很大的工程。因为很多流程和编码对数据库的依赖性很强，如果流程的修改需要改动数据库将导致很多编好的流程和代码必须重新编写，这样用户和开发方都要承担很大的时间和资金压力。

本文作者试图通过应用一种规范化的业务流设计方法较好的解决这一困难。其设计思想是将数据库的设计前置到需求分析和业务流分析阶段，建立一个业务定制阶段，需求的变化体现在业务定制标准数据库中，而不影响或很少影响完整的业务数据库设计，变动的需求最后体现在个别的业务表设计和部分业务的编程中，最大限度的减少其对整体修改的要求，从而达到快速响应变化的需求的目的。

这一设想的具体实现首先体现在业务定制数据库的设计上。其设计思想是进行业务分离，将一个个具体的业务抽象为一些业务类，每个业务类代表一个简单的业务操作。设计一个业务类别表如下表 

一．业务录入阶段

首先是业务人员或管理人员了解需求后可以直接进入业务定制程序，按其了解的业务进行业务定制操作，录入各分立业务的基本属性。这一阶段对操作人员没有编程能力的要求，只要求将业务流程分解为各个单独的业务，同时将该业务需要的所有对象属性加以说明。在这里业务人员可以参看和修改权限内的业务类别，业务类别的属性也可以增减和修改。

二．业务确认阶段

项目经理对录入的所有业务进行分析，将大的业务进行拆分，尽量使业务具有原子性。然后对业务属性进行归类和整理，对同一业务流中跨不同业务的对象进行统一定义。

三．业务属性分析

数据库设计人员介入，设定所有业务属性的具体数据定义，如数据类型，字段长度、在业务属性中的序号等。这一阶段可以对适合建立数据库表的一些业务属性进行基本业务表设计，以提高后面的处理效率。

四．业务窗口设计

每个业务流的设计基本采取标准设计界面，左侧是业务流的属性和一些功能按钮，右侧为业务窗口，主要显示本业务的业务属性。编码主要是通过一些事件编程而得到当前业务的业务属性，然后将当前业务的属性存入业务实例参数表或基本业务表，完成本项业务。例如图书馆借书，其基本业务属性为读者编号、当前时间、图书编号、到期时间等，在读者实际借书时还需要“借书”的业务类编号和为这次借书分配的“借书”实例编号。把这些都存入业务实例参数表，就完成了一次借书业务。从这里可以看到，实际业务实例参数表里面可以保存很多业务，而且是以纵列的形式保存的。如果业务量不是特别大，实际可以不设计另外的数据库表就可以完成日常管理。当然，对于业务比较固定，业务量比较大的系统，可以设计一些日常的数据库表，把业务参数以这样表的数据形式保存下来。

(未完待续)

原文转自：http://www.ltesting.net