基于文档对象模型的软件设计-阿里云开发者社区

基于数据库的软件设计案例分析

根据我的初步调查，在.NET部门中的软件研发过程中，排除用户需求和系统实施阶段，在软件设计和开发阶段存在的前3个主要问题有

1. 软件人员开发工作效率不高。

2. 开发人员编写的代码不够规范。

3. 软件组件重用少。

经过分析，这些问题都源于目前.NET部门系统设计方法还不够先进。在此使用近期开发的“XX OA升级”项目进行案例分析。该系统设计过程如下

1.软件功能模块图

在该系统的设计说明书中，首先列出了如下图所示的软件的功能模块

2.建立逻辑-物理模块映射

然后建立如下表所示的逻辑-物理模块映射

序号			1	2	3	4	5
	逻辑模块物理模块	本逻辑功能特有业务功能	0.01 通用列表	0.02 表单功能	0.03 字典功能	0.04 权限管理	0.05 统计报表
1	1、警员管理	1.01警员新增		√	√	√
		1.02警员修改		√	√	√
		1.03警员查询、删除	√		√	√
		1.03警员统计					√

3.列出数据属性

列出本软件涉及的信息数据实体中的各个数据项目，比如对于警员信息列出如下的数据属性清单。

序号	名称	必填项	字典项	查询项	列表项	说明
1	姓名	√		√	√
2	性别	√	√	√	√
3	出生年月日	√
4	警号	√		√	√
5	其他内容

4.用户界面设计

列出各种信息实体的数据属性清单后，即根据用户需求来设计和安排用户界面。比如对于新增警员功能，安排到页面Police_reg_page.aspx，其用户界面设计如下

警员新增

姓名*		警号*
性别*		出生年月日*
……		……
单位名称	本单位名称

保存离开

此外还根据流程还安排了各个功能页面之间的调用关系，比如对于警员管理安排了如下页面调用关系。

5.页面功能设计

根据用户需求开始设计一些页面的功能。比如对于上图具有以下功能设计：

step1:

业务说明：在新增保存中需判断警号的重复性

业务处理类 Sky.OAWeb.Dress.police_reg_page
实现方法：	protected void Btn_AddPolice _ServerClick(object sender,EventArgs e)	警号重复性校验、提交保存数据库
插入数据表 Police

6.算法设计

若需处理的业务数据中存在一些算法，还需要对相关算法进行一些设计说明，可能要画一些流程图。

7.数据接口设计

若应用系统和其他系统存在一些数据接口，或者使用第三方组件。则需要进行相关设计。

8.数据库设计

根据前面的数据实体的数据属性来设计对应的数据表和字段结构。例如能设计出如下数据库表结构

表格Declaretemp的列清单

名称	注释	长度	数据类型	默认值
ID	主键	40	varchar(40)
rdeptid	添加部门ID		int	0
unitid	添加单位ID		int	0
chinaname	中文名	20	varchar(20)	''
sex	性别男为0，女为1		tinyint	0
policeno	警号	10	varchar(10)	'32'
dressyear	着装时间，年份	4	varchar(4)	'2000'
dresslevel	服装级别普通为0，高级为1		tinyint	0
dressequipid	服装装备表ID		int	0
equiptype	装备类型，1为服装、2为鞋子、3为帽子、4为服饰装具		Tinyint	0

这样，一个应用系统的设计大体上就出来了。而软件开发人员按照这个系统设计文档来开发软件。

基于数据库的软件设计方式

根据上述软件设计过程，可以看出系统设计很多只是对客户需求的简单整理和罗列，并没有精确而灵活多变的数据描述方法。因此一个系统的设计很多时候转换为数据库设计，形成基于数据库的软件设计。这样软件设计和开发人员很容易流于数据属性的形式，而不深入进行抽象整理，不能采用分类比较的方式进行数据的整理和归纳，从而形成如下问题

1.软件开发人员工作效率不高

目前业界软件设计以及开发还没有进行大工业化生产，还是手工生产，是靠一个个软件开发人员使用最原始最天然的脑力劳动来生产。由于人类大脑的生理特征，越复杂的软件需求其设计工作强度越大且开发时间越长，因此客户需求复杂度和软件设计工作量是非线性增长。这种现象是很长一段时期内无法改变的。

采用基于数据库的软件设计方法，客户需求越复杂，形成如下客户需求复杂度和软件设计工作量的关系图。在该图中，横轴是客户需求复杂度，大体和数据库字段数成一定的比例，纵轴是软件设计工作强度，而灰色的三角形区域的面积就是软件设计工作量。

而在实际中，客户需求复杂度是不断增加的，于是软件设计和开发工作量是快速增长的，其增长速度是超过公司软件研发人员的人力资源的增长速度。

比如在2010年4月，.NET部门目前同时开发和维护着23个软件项目，而开发人员只有37人，平均每个项目包括1.6个人，实际上还有少数人一个人承担5、6个项目。相对于软件设计和开发工作量的飞速增加，软件开发能力并没有很大的发展，这样对比，软件开发人员的工作效率自然就显得不高了。因此要解决软件开发人员工作效率不高的问题，需要提高软件开发能力。为此公司进行部门重组，实行考核激励制度能是种途径，不过改良目前的基于数据库的软件设计方法也有助于改善这个问题。

2.软件组件重用少

基于数据库的软件设计会导致软件组件重用较少的问题。由于采用基于数据库的设计，因此软件功能很多是进行数据库的相关操作，由于现在软件开发基础框架和数据库系统已经提供了很好的针对数据库的开发接口，软件开发人员无需编写高技术含量的代码即可实现功能。

由于存在进度压力，软件开发人员为了尽快完成任务，不可避免的尽快编写代码，由于功能基本上能自己搞定，于是各自为战。软件开发人员之间也存在代码文件的交流，但较少软件组件的交流，于是软件组件重用的群众基础薄弱，软件组件重用自然就少了。

软件组件重用比较少，这导致软件开发人员重复劳动，提高项目成本，不利于低成本战略；项目绑定到具体的个人，大量的技术资源是分散到个人掌握而不是由公司集中掌握，于是公司的不可避免的人力资源的流失导致公司的技术资源的流失。这些对公司的运营带来长期的逐渐积累的问题。

3.开发人员编写的代码不够规范

基于数据库的软件开发也会导致开发人员编写的代码不够规范。由于基于数据库的软件研发无需编写高技术含量的代码，允许开发人员各自为战，团队合作不够，思想、技术和代码的交流不够。于是个人按照个人的风格编写代码。目前公司有代码书写规范，但没有代码结构规范。源代码的书写规范很容易遵守和检查，但代码结构规范目前基本上没有约束。

在基于数据库的软件研发中，软件开发人员是从数据库层面上开始开发软件，就像在一个平地画了一个圈子然后添砖加瓦盖房子。由于未对软件结构做出额外的设计，此时所得的软件必然是极具个人风格。个性过于鲜明的缺乏统一规范的软件代码是无法大量复制重用的，其维护成本较高。

综上，公司在软件开发过程中遇到的一些问题，其根源就是基于数据库的软件设计和开发的方法。

基于文档对象模型的软件设计

文档对象模型基本概念

首先说明一下文档对象模型的概念，文档对象模型，简称DOM，是一种软件设计模式。软件设计人员需要对要处理的数据进行整理和抽象，确定出一个个数据概念实体，然后运用面向对象软件设计方法，确定出各个数据概念实体中的继承关系和组织关系，形成一种树状的结构来精确的描述业务数据。文档对象模型优势在于复杂业务数据的描述，但不善于工作流等业务数据处理。

文档对象模型在IT业界应用广泛，XML就是文档对象模型的具体应用，它展示了其强大的数据描述能力，此外MS.NET类库中也实现了一些文档对象模型，IE浏览器、MS Word等许多通用软件产品根据其编程接口可以推测其内部大量采用文档对象模型技术。

文档对象模型是一种通用的软件设计模式，可以用于各种软件的设计开发，而电子政务文档对象模型是文档对象模型在电子政务软件开发中的具体应用。文档对象模型在产品软件中的设计开发中得到很好的应用，但在项目软件中研发尚未得到推广应用，因此这方面值得深入研究。

基于文档对象模型的软件设计案例

我正在开发的报表通用软件产品中运用的基于文档对象模型的软件设计方法，在这里以此为案例说明一下基于文档对象模型的软件设计方法。

软件功能模块设计

首先根据软件功能需求确定出如下图所示的软件功能模块，这点和目前公司的软件设计过程一样。

文档对象层次模型设计

我对于各个软件功能点，进行整理和综合考虑，确定出如下图所示的系统文档对象层次模型。并根据数据序列化的要求设计出对象和数据库表的映射关系。

文档对象继承模型设计

根据文档对象层次模型中的各个对象的数据依赖关系，设计出如下的文档对象继承模型。

这样就完成了系统文档对象模型的设计，然后笔者就以这个为起点进行软件的后续设计和开发。

案例分析

这个案例展示了一个典型的基于文档对象模型的软件设计，对比基于数据库的软件设计模式，基于文档对象模型的软件设计中，数据库的地位大为降低，只是作为一个数据序列化的容器。因此基于DOM的软件设计是以数据为中心的，而不是数据库为中心。

在这个案例中，基于DOM的软件设计过程主要步骤有

1. 收集用户需求。

2. 对用户需求进行分析，初步规划出各个数据信息实体，但还不详细罗列出各个数据实体中的具体数据项目。比如在此前案例提到的警员就是一个数据信息实体，在本案例中应用程序本身就是一个最大的数据实体。

3. 分析各个数据实体之间的从属层次关系。比如在本案例中，应用程序包含多个报表项目、多个用户，而报表项目包含多个报表文档。

4. 根据数据实体之间的从属层次关系，相互搭配，设计出文档对象层次模型。

5. 整理和罗列出各个数据实体的数据项目。比如在本案例中，报表模板文档对象和报表文件目录对象的数据项目整理如下

6. 分析出各个数据实体之间的数据项目的交集。比如在本案例中，报表模板文档对象和报表文件目录对象的数据实体存在如下交集。

7. 根据数据实体之间的依赖和包容关系，以及数据实体数据项目共享情况，设计出文档对象继承模型。比如在本案例中由于报表模板文档对象和报表文件目录对象存在大量的数据项目的重复，因此可以将重复的数据项目提取出来形成一个新的过渡数据实体，而报表模板文档对象和报表文件目录对象从这个临时的过渡数据实体派生而来。

使用上述方法就可以设计出文档对象继承和派生模型。

8. 接着收集分析文档对象模型中各个数据实体的持久化需求，说白了就是确定哪些数据实体的内容需要保存在数据库中。

9. 整理出数据持久化需求，根据那些要持久化的数据实体的数据项目来设计数据库结构。这样数据库中数据表和文档对象模型中的一些数据实体形成了映射关系。

10. 经过上述步骤，一个完整的文档对象模型就设计出来的，接着就按照传统的方法进行用户界面、算法、数据接口之类的系统设计了。

下表就是基于数据库的软件设计和基于文档对象模型的软件设计的执行步骤对比表

步骤	基于数据库的软件设计	基于DOM的软件设计
1	收集用户需求	收集用户需求
2	分析出各个数据信息实体	分析出各个数据信息实体
3	罗列出数据实体的数据项目	分析各个数据实体之间的层次关系
4		设计出文档对象层次模型
5		罗列出数据实体的数据项目
6		分析各个数据实体的依赖和包容关系
7		设计出文档对象继承模型
8		收集数据实体持久化需求
9	根据数据实体的数据项目设计数据库结构	根据数据持久化需求设计数据库结构
10	用户界面、算法、数据接口设计	用户界面、算法、数据接口设计

从基于文档对象模型的软件设计步骤可以看出，描述数据的地位上升了，而数据库的地位下降了，于是引出了数据库的地位问题。

面向数据的信息化系统

在采用基于DOM的软件设计时，软件设计人员首先要认清数据库在软件设计中的地位的问题。

在此前的时期，客户对信息化要求不高，理解也不深，其主要目标就是数据的录入、存储和简单的查询。于是客户关注于数据库，软件开发人员迎合客户的需求设计和开发了以数据库为中心的信息化系统。

如下图所示，在这个系统中，客户是关心数据库，软件设计和开发是创造数据库，数据是保存在数据库，用户界面展示数据库，应用软件操作数据库，计算机网络是连接数据库，防火墙是保护数据库。

随着时代的发展，客户对信息化的要求不断提高，此时客户越来越多的关注于数据本身，希望能从数据中获得更多的价值，此时客户会基于数据提出更多更复杂多变的需求，而软件开发人员应当迎合客户需求的变化来设计和开发以数据为中心的信息化系统。

如下图所示，在这个以数据为中心的系统中，客户是关心数据，软件设计和开发是创造数据，数据是长期保存在数据库中，用户界面展示数据，应用软件操作数据，计算机网络是传输数据，防火墙是保护数据。

若现在软件开发人员还使用基于数据库的软件设计和开发，则不能迎合客户的需求，不能理解客户提出诸多需求的本质驱动力，研发力量使用方向不够精准，软件的设计和开发也就难以实现客户需求。此时开发人员就像使用狙击步枪扫射，浪费子弹，效率自然不高了。基于数据库的软件设计中过于强调数据库的中心地位，而忽视用户数据本身的特性，从而导致研发力量使用方向不够精准，在追赶快速发展的客户需求时显得力不从心，从而引发了一系列的问题。

以数据为中心的软件设计和开发对软件设计人员的自身素质，公司的研发管理等方面提出更高的要求。软件的设计和开发需要以数据库为中心转变成以数据为中心，这是时代发展的趋势，软件开发人员需要与时俱进。

更进一步联想，在近期业界开始推广的SOA软件开发技术，它就是一种以数据为中心的软件开发技术，在这种技术中，数据库的地位变得非常低微了。

电子政务文档对象模型

基于文档对象模型的软件设计方法就是以数据为中心的，这是适应行业软件发展的趋势的。

公司重要的业务领域是电子政务，文档对象模型在电子政务软件开发中的具体应用就是电子政务文档对象模型。类似的文档对象模型在税务软件开发中的具体应用就是税务文档对象模型，在企业信息化软件中的具体应用就是企业信息文档对象模型。

优点

电子政务文档对象模型具有以下优点

增强软件重用

电子政务文档对象模型一开始就是为了软件重用的最大化。在开发过程中大量应用面向对象编程方法，这能解决公司目前的软件组件重用少的问题。

灵活的软件架构规模

电子政务文档对象模型呈现一种可拆解的树状结构，其运用可大可小，可拆分其中的某些分支来搭配使用，既适应大型软件系统正规开发，也可用于频繁的软件小修改。堪称软件开发人员手中的如意金箍棒。

技术和知识积累

在大量的电子政务软件开发实践中频繁的出现了新的信息处理对象，这些信息对象可进行整理和规范，并添加到电子政务文档对象模型中，使得电子政务对象模型具有吸收知识积累的作用，这能降低电子政务文档对象模型的初期开发成本。还能帮助软件开发部解决目前的项目软件研发难于实现技术和知识积累的问题。

帮助代码结构规范

文档对象模型很容易建立规范简约的编程接口，符合人们的日常思维，从而降低其使用成本。这能帮助解决开发人员编写的代码结构不够规范的问题。

其实这点也不难理解，如下图所示，

电子政务文档对象模型就像一颗树，开发人员不断的添加代码让其中的树枝变粗，或者开发出新的小树杈，但树的整体形状不会变形，而且所有的开发人员不会脱离这棵树来编写游离的代码。这样电子文档对象模型这个宏观结构制约了开发人员编写代码的微观结构。

电子政务文档对象模型系统有效的组织了各个软件开发人员的技术资源，可以成为技术资源的容器，而电子政务文档对象模型是属于公司的，因此能帮助解决技术资源分散控制在个人手里而不是集中控制在公司里的问题。

软件架构寿命长

电子政务文档对象模型由于其开放包容的结构使其寿命非常长，设计得好的话，能连续使用至少5年时间，这能长期而稳定的输出价值。例如天博报表软件里面就使用了文档对象模型技术，其构造的报表文档对象模型是从2005年开始开发的，一直用到现在，虽然添加了很多功能，但基本框架是没有大的变化；天博报表软件包含了40万行源代码，但软件模块结构没混乱，仍然能进行很好的控制。

产品软件其基本架构需要长期稳定，能使用许多年而不换掉，而电子政务文档对象模型的长寿使其足以承担电子政务产品软件的基础架构，它能帮助将电子政务项目软件升级为电子政务产品软件。

公司领导多次提出开发电子政务产品软件的设想。由于电子政务文档对象模型具有上述优点，它将是开发电子政务产品软件的比较好的技术方案。

缺点

文档对象模型技术及其派生的电子政务文档对象模型技术也有其缺点，主要如下

1. 不能推广普及。文档对象模型技术是一种比较高级的软件开发技术，掌握该技术的人比较少，使用成本高，不可能在所有的软件设计和开发中推广使用。

2. 应用成本高。掌握文档对象模型技术的开发人员比较稀缺，人力资源成本高；而且需要对客户需求进行很深入细致的分析，时间长。因此文档对象模型技术的应用成本高。

3. 应用范围不广。文档对象模型技术很适合信息处理的产品软件的设计和开发，但不适合项目软件的开发。因为产品软件能大批量的复制应用能分摊使用文档对象模型技术的高成本，而且产品软件的生命周期很长，能很好的利用文档对象模型知识积累的优势；而项目软件没有这种能力。

4. 文档对象模型不能独立使用。文档对象模型注重于描述数据，而不是实现软件功能。因此不能独立使用，还需要其功能性的软件模块才能形成一个完整实用的软件。

5. 运行速度慢。文档对象模型运行速度慢，不适合高性能大运算量的软件开发，但足以满足常规的信息处理软件的性能要求。

应用

电子政务文档对象模型专注于电子政务业务数据的描述，而目前.NET或JAVA部门框架侧重于工作流、数据库操作、用户界面等软件功能的实现，电子文档对象模型不是替代部门框架，而是依赖部门框架运行并引导部门框架的运用。因此电子政务文档对象模型和部门框架两者是相辅相成的，电子政务文档对象模型是钢筋，那部门平台是混凝土，两者相结合就成为建设电子政务软件的钢筋混凝土。

根据公司的基本情况，在电子政务软件开发中使用文档对象模型的步骤可以为

1. 统一认识，认识到基于数据库的软件设计要转变为基于数据的软件设计。

2. 选择一个工期要求比较宽松的规模不大的电子政务项目或者一个自研项目作为试点，最好是C/S的，不用工作流技术。

3. 组织一些开发人员设计和开发软件，使用文档对象模型技术。

4. 修改部门框架，添加专门为文档对象模型的开发接口。

5. 将电子政务文档对象模型和部门框架进行集成。

6. 测试，发布。

若经过实践证明电子政务文档对象模型是可行的，实用的。则公司可以考虑使用电子政务文档对象模型来开发电子政务产品软件。

小结

在这里，我对电子政务文档对象模型的创新建议进行了详细的说明。重点说明了一下电子政务文档对象模型。

目前公司在软件开发中遇到的一些问题其根源是基于数据库的软件设计方法，若不对此进行改进，则研发生产力提升比较费力，开发电子政务产品软件将不大可行。

本文转自xdesigner 51CTO博客，原文链接：http://blog.51cto.com/xdesigner/631034，如需转载请自行联系原作者

基于文档对象模型的软件设计

热门文章

最新文章

相关课程

相关电子书