公文转发流程自定义的数据建模.pdfVIP

公 文 转 发 流 程 自 定 义 的 数 据 建 模 开发比较复杂的企业多用户管理信息系统 (MIS) ，不可能不涉及到系统内多个用 户之间的数据文件的流转、 审批等功能的开发。 由于企业的需求总是随着时间推 移不断发生变化， 加之各个企业内部所设置的办公流程不尽相同， 一套通用性比 较好的管理信息系统应该能让系统管理员自己定义公文转发的流程。 尽管笔者没有机会在已参与开发了的 MIS 中实现出文件转发流程自定义的 功能，但是，早在 2002 年初就曾深入思考过这方面的设计。当时由于某些原因 不能公开自己的设计思路，现在市面上已经有不少 MIS 产品提供这样的功能， 笔者又已离职，所以是时候把我的设计思路整理出来，和大家分享。 首先，让我们分析需求，制定目标。 1)一般情况下，企业内的公文转发、审批是按部门或职位来转送，即对岗不 对人。例如：某个流程的某个环节需要财务总监审批，日后财务总监换人，该流 程应该不受影响。 而且，流程中某个环节可能出现某个部门中的任何一人都能审 批，或者需要该部门的所有人员共同审批。 2)流程中转送，审批的公文一般分为文件和表单 2 种格式。文件格式的公文 应该支持批处理， 即一次可以转发多个文件， 审批时可以只退回其中某一个不合 格的文件， 其他的文件可以转送到下一个环节继续处理。 表单格式的公文应该能 让用户自己定义表单格式，确定表单中的表项。同理，表单也应该支持批处理。 3)流程中处理公文的动作应该能让用户自己定义。 这样一旦日后增加了新的 处理动作，也不用修改 MIS 系统的底层数据建模。当然，要实现新的处理动作， 还是需要在业务逻辑层编写相应的代码， 不过和修改底层数据建模比起来， 工作 量要少得多。 4)每个流程的环节数不一定相同，应该能让用户设定环节数，指定公文流转 中每个环节的发送部门和接受部门，处理模式，最长等待时间。 5)当待处理的公文发出后， 系统应该在等待时间中定期向该流程中下个环节 的用户 (们)发出通知，提醒该用户 (们)及时处理，直至公文已被处理。如果超出 最长等待时间，公文还未被用户 (们)处理，此次流程处理失败。企业管理层可能 会要求记录相关信息，以便在日后业务流程重组 (BPR)时参考。 6)某些企业由于特殊原因，在某个流程中要求实现跨环节处理。例如，该流 程有 6 步，执行到第二个环节时要求处理后可以跳过中间三个环节， 直接转到最 后一个环节等候处理。 其实，这种情况下， 并不一定要在技术层面上实现其灵活 性，这种特例毕竟是少数。用户只需定义一个新流程，把上面流程的第 1，2，6 步复制加入进来， 2 个流程之间用流程名来区分即可。一个优秀的系统架构设计 师应该充分利用现有的工具，不要什么都自行架设开发。 上面的需求对灵活性要求较高， 抽象化程度较深， 所以在表现层和业务逻辑 层的开发量较大，初期投资较多，不过开发完毕后估计不需对底层数据库修改， 即可满足日后不断变化的公文流转需求。 如果不需要这么高的灵活性， 可以按实 际项目简化某些假设条件。 下面按照上面的需求进行用例 (use case)分析和数据建 模。 1)由于流程环节的发送方和接受方是对岗不对人， 我们应该先描画出整个企 业的机构设置，确定每个部门的权利职责。其中大的部门内可能有若干子部门， 每个子部门内又有不同职