一定UML吗？——看看结构化设计实例

一定UML吗？——看看结构化设计实例

 

背景：

自从OOA、OOD被业界推崇以来，运用UML进行需求分析、架构设计几乎成为圣经，似乎使用迭代和UML就先进了、OO了，用传统的方法就是落后了、非OO了。事实上无论运用什么工具或方法，只要能够充分反映软件内在的本质就可以了。

传统的软件工程中主要有如下建模工具：IPO模型、万诺模型、ER模型、JACKSON模型、DFD模型、程序流程图等，与之对应的详细设计方法主要是结构化设计法。在几年的MIS项目实践中我对传统软件工程领域中较为推崇的有：ER模型、Petri网、DFD模型、JACKSON模型和程序流程图。ER模型主要运用于领域模型设计、Petri网运用于工作流建模、DFD模型主要用于数据动态关联建模、Jackson模型主要运用于非ER环境的复杂数据结构建模及其相关算法（变换）建模、程序流程图用于对重要算法或处理过程进行说明。

在我的项目中，主要运用的工具仍然是UML，但是在上述的一些环节中，我和我的团队仍然会运用传统软件工程领域中的一些建模方法，特别是现在流程重构需求较多以及大量的快速开发工具被运用的情况下，传统的东西似乎用得越来越多。我的实际经验表明，运用好传统的软件工程方法，会比一味的追求OOA、OOD更有效果。

以下就以开发中的一个实例进行说明，限于商业考虑，只能在此将一些有代表性的文档拿出来讨论，希望大家能一块来讨论。

一、用户业务流程说明

客户是一个较大的机构，位于市区，在当地区县、乡镇均设有下级部门，为了提高企业库存周转率、防止库存积压导致现金占用的现象，该企业实行预算控制、集中采购。

未上信息系统以前，区县、乡镇到市区领用物资的时候需要经历多道审批手续，时间长、管理成本大、数据滞后混乱。

通过和客户认真沟通，并结合各职能部门的职责，对企业内部相关流程进行了重构、优化，并对一些机构的职责进行了微调。下图给出的就是整理后“按照物资进行领料”的工作流图，该图截取自JBPM的设计器，本质上一个Petri网。由于JBPM未能够将泳道在图上可视化表达，因此又让美工通过PS加上了泳道。

 

 

 

二、ER模型

在实际为客户解决问题的过程中，我们分析并设计出了一个较为庞大的领域模型，主要的工具是PowerDesign，由于此处给出的实例是大家常见的一个需求情况，因此不给出数据库设计的实例。

 

三、流程中关键环节的数据处理过程

1、当物料分发系统中的ERP领料单处于编辑状态时，要将ERP系统中的对应的ERP单号填写到该单据中，且ERP单号不能重复。当ERP领料单编辑完成后，可以提交ERP领料单到上级部门进行审核。如果觉得该单据制的不对，也不能通过修改进行调整过来，可以直接将该单据放弃。

提交ERP单据和放弃ERP单据的数据流向入下图所示。

 

 

 

2、归口部门审核，有同意和拒绝两种情况。

 

3、预算部门的审核，有同意和拒绝两种情况。

 

4、ERP的审核，有同意和拒绝两种情况。

 

5、入库部门的审核，有同意和拒绝两种情况。

 

 

四、开发过程说明

1、数据库使用PowerDesigner 12.1 进行设计，首先进行概念模型建模（ER），通过概念模型生成物理模型，通过物理模型生成Oracle建库脚本；

2、通过概念模型生成OO模型，然后编辑OO模型与物理模型的映射关系，生成POJO类和基于Hibernate的DAO；

3、用JUNIT对自动生成的DAO进行全面测试，未发现问题；

4、分析业务流程后，建立JBPM业务协作模型，并依据分析出来的DFD编写JBPM各节点的Action Handler，发布并部署JBPM；

5、使用BSTEK，快速生成开发界面，软件界面大致分为三种（1）简单的CRUD，由BSTEK快速生成，基本上不编写代码；（2）与工作流程中各交互页面在BSTEK上设计，用户提交后，将用户表单的数据直接映射到JBPM的任务上下文中，并触发流程事件，由ActionHandler来完成后续的数据具体操作；（3）其他的一些传统页面。

 

五、项目特点

1、持久化层直接由软件生成，可以说是模型驱动开发；

2、流程参与人员、业务逻辑处理单元之间协作关系均由JBPM调度，也是模型驱动开发；

3、业务逻辑层和人机交互层彻底通过JBPM隔离；

4、使用BSTEK快速开发工具完成人机交互界面。

 

另：项目中还运用了kettle、mondrian+jpivote、jfreereport、jfreechart、jboss portal、jboss sso等开源中间件，有机会一个个给大家介绍吧