基于文檔對象模型的軟件設計

文檔對象模型是一種較為抽象的系統設計模式，就是將要處理的信息進行整理和抽象，運用面向對象軟件設計方法，確定各種信息的組織關系和繼承關系，形成一種樹狀結構來精確描述業務數據。[袁永福版權所有]

基于數據庫的軟件設計案例分析

根據我的初步調查，在.NET部門中的軟件研發過程中，排除用戶需求和系統實施階段，在軟件設計和開發階段存在的前3個主要問題有

1.       軟件人員開發工作效率不高。

2.       開發人員編寫的代碼不夠規范。

3.       軟件組件重用少。

經過分析，這些問題都源于目前.NET部門系統設計方法還不夠先進。在此使用近期開發的“XX OA升級”項目進行案例分析。該系統設計過程如下

1.軟件功能模塊圖

在該系統的設計說明書中，首先列出了如下圖所示的軟件的功能模塊

2.建立邏輯-物理模塊映射

然后建立如下表所示的邏輯-物理模塊映射

             

3.列出數據屬性

列出本軟件涉及的信息數據實體中的各個數據項目，比如對于警員信息列出如下的數據屬性清單。

4.用戶界面設計

列出各種信息實體的數據屬性清單后，即根據用戶需求來設計和安排用戶界面。比如對于新增警員功能，安排到頁面Police_reg_page.aspx，其用戶界面設計如下

警員新增 姓名*   警號*   性別*   出生年月日*   ……   ……   單位名稱 本單位名稱                             保存                      離開

 

此外還根據流程還安排了各個功能頁面之間的調用關系，比如對于警員管理安排了如下頁面調用關系。

5.頁面功能設計

       根據用戶需求開始設計一些頁面的功能。比如對于上圖具有以下功能設計：

step1:

業務說明：在新增保存中需判斷警號的重復性

 

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.       測試，發布。

 

若經過實踐證明電子政務文檔對象模型是可行的，實用的。則公司可以考慮使用電子政務文檔對象模型來開發電子政務產品軟件。

小結

在這里，我對項目軟件黑匣子功能和電子政務文檔對象模型的創新建議進行了詳細的說明。重點說明了一下電子政務文檔對象模型。

目前公司在軟件開發中遇到的一些問題其根源是基于數據庫的軟件設計方法，若不對此進行改進，則研發生產力提升比較費力，開發電子政務產品軟件將不大可行。

而基于數據的軟件設計方法將是軟件業界的發展趨勢，也是公司提升軟件生產力，開發電子政務產品軟件的必由之路。結合公司的基本情況，電子政務文檔對象模型將是基于數據的軟件設計的最佳實踐。若能成功的運用電子政務文檔對象模型，則公司對于電子政務業務規律和軟件設計的境界將有不小的提升。希望公司能認真考慮電子政務文檔對象模型，至少也要考慮基于數據的軟件設計方法。[袁永福版權所有]