基於UML和ASP.NET實現三層B/S結構系統開發

基於UML和ASP.NET實現三層B/S結構系統開發作者：胡穎輝 寧賽飛　　 來源：IBM

摘 要 進行良好的系統分析和設計是軟體項目開發的關鍵，構架設計的合理與否往往決定了項目的成敗。本文結合一個項目的開發，闡述了基於UML的系統建模過程和基於ASP.NET實現物件導向的三層結構應用系統的方法。

　關鍵詞 ASP.NET； 三層結構； UML建模； 系統開發

架構設計是軟體開發的基礎，並往往決定一個項目的成敗。三層結構是目前流行的架構設計模式，它是在由Buschmann等提出的“層模式”[1]基礎上發展起來的，由展示層、商務邏輯層和資料訪問層三個階層組成。它通過分解來管理問題的複雜性，同時還可以有效地重複使用商務邏輯並保留與昂貴資源（如資料庫）的重要串連[2,3]。

　基於ASP.NET能夠充分發揮其完全物件導向的技術特點，實現三層結構B/S系統架構，從而提高開發效率，增強系統的可維護性和擴充性。本文結合一個“學產生績管理系統”的開發，研究如何基於UML進行三層B/S結構的系統建模，及其在ASP.NET下的應用實現。

　1 三層結構系統模型
　架構設計是非常進階的設計，也是系統設計的關鍵，主要是定義和說明包（子系統），以及包與包之間的相互依賴與通訊機制。系統構架模型的合理與否將決定系統的可維護性、擴充性和開發效率。

　包通常所需要處理的是要麼是一個具體的功能區域（商務邏輯），要麼是一個具體的技術地區（技術邏輯）。商務邏輯主要考慮的是對系統業務功能的實現，而技術邏輯則是進一步考慮使用者介面、資料庫或通訊機制等形成的技術方案。把技術邏輯和商務邏輯區分開來是極其重要的，這是為了當修改程式的某一部分時不會對另一部分產生影響，更加便於進行“複用”，同時易於應對來自商務邏輯的變更需求。

　三層結構是一種成熟、簡單並得到普遍應用的應用程式架構，它將應用程式結構劃分三層獨立的包，包括使用者展示層、商務邏輯層、資料訪問層。其中將實現人機介面的所有表單和組件放在展示層，將所有商務規則和邏輯的實現封裝在負責商務邏輯組件中，將所有和資料庫的互動封裝在資料訪問組件中。其結構如1所示：

　圖1 三層結構

三層結構是一種嚴格分層方法，即資料訪問層只能被商務邏輯層訪問，商務邏輯層只能被展示層訪問，使用者通過展示層將請求傳送給商務邏輯層，商務邏輯層完成相關商務規則和邏輯，並通過資料訪問層訪問資料庫獲得資料，然後按照相反的順序依次返回將資料顯示在展示層。

　2 三層B/S結構的學生管理系統開發
　下面通過一個學生管理系統的開發，說明三層B/S結構系統從UML建模到基於ASP.NET進行實現的完整開發過程，UML建模工具採用的是Rational Rose。

　2.1 需求分析
　軟體需求分析是系統開發的第一步也是最重要的一個環節，其基本任務是準確地回答“系統做什嗎？”這個問題，這需要在對使用者需求進行充分調研的基礎上，深入理解並描述出軟體的功能、效能、介面等方面的需求，可以使用UML建模作為需求分析和系統設計的有效方法。

　分析的目的是為了獲得和描述系統中所有的要求，因此分析階段是一種典型的與使用者或客戶合作的過程，通常由開發人員同使用者或客戶共同完成。在這個階段，開發人員不應該考慮代碼或程式實現的細節，而應該把精力放在對現有商務邏輯的理解上，通過與使用者之間的充分溝通，逐步理解並描述出得到使用者確認的系統模型，包括用例模型和領域（domain，系統中關鍵的類）模型。

　2.1.1 用例模型
　軟體開發人員在對使用者進行需求調研的過程中，使用者往往並不能立即準確描述出未來系統應該提供一些什麼樣的功能。因此，需要開發人員理解和分析需求，並將系統應該具有的功能通過使用案例圖直觀的描述出來，方便使用者理解並做出評判，開發人員從而可以根據使用者的反饋不斷調整用例模型，直至完全正確、充分描述清楚系統功能。

　用例建模主要是分離出系統的活動參與者(Actor)和用例(Use Case)，用例是指對系統提供的功能的一種描述，而活動參與者是那些可能使用這些用例的人或外部系統，通過使用案例圖可以描述出系統外部的執行者、系統的用例，以及它們之間的聯絡。本學生管理系統的使用案例圖見圖2。

　用例模型還需要進一步對每個用例進行詳細描述，進一步說明用例的名稱、基本事件流和備選事件流、前置條件和後置條件等，並形成文檔。限於篇幅，這裡就不多說了。
　
　圖2 使用案例圖

2.1.2 領域建模
　分析過程中還要詳細地列舉領域(domain ，系統中關鍵的類)，為了進行領域分析，需要充分理解用例模型，也可以與使用者及領域專家組織一次集體研討會談，嘗試找出所有必須處理的關鍵概念以及它們之間的相互關係，並最終分析出域類圖。3為本系統的域類圖。

　需要強調的是：在本階段，對領域進行分析的類圖還是處於“草圖”狀態。定義的操作和屬性不是最後的版本，只是在本階段看來比較合適。後期將通過動態行為分析不斷得出新的操作，這是一個逐步完善和發展的過程。

　2.2 系統設計
　系統設計的目的是產生一個可用的、完整的解決方案，並且能夠比較容易地將方案轉換成程式碼。這個階段在三層結構的架構設計模型基礎上，將考慮所有的實現技術問題，對分析階段的模型進行擴充和細化，分析階段定義的類進一步擴充，定義新的類來處理技術方面的問題，並形成最後的UML模型。

　推動不斷進行詳細設計的方法是對每個用例進行動態建模，描述如何通過類圖中的對象協作實現用例中的功能，由於一開始對系統的認識是很不夠的，前面建立的類往往隨著動態建模的深入，發現存在缺陷或不夠完整，需要對分析中得到的域類圖進行不斷修正和調整，擴充形成商務邏輯包。同時，隨著對使用者介面、資料庫訪問等技術實現的深入建模，不斷建立新的使用者介面類（如表單、控制項）和資料訪問類，形成使用者介面包和資料訪問包。

　本學生管理系統經過詳細設計後，在域類圖基礎上進行擴充後形成的商務邏輯包類圖如4所示。
　
　圖3 域類圖

　圖4 商務邏輯包類圖

建立立的資料訪問包類圖如5所示。所有的資料訪問類都定義了一個基類DBCommon，該基類包含屬性DBConnectionString，通過該屬性可以獲得資料庫連接字串。還包括一個方法GetDataView，可以實現在資料庫中執行查詢獲得一個DataView。這些屬性和方法被所有的資料訪問類繼承，可以直接使用。

圖5 資料訪問包

關於使用者介面包的類圖比較簡單，主要是通過介面設計，設計出表單及控制項等介面元素，並根據動態建模時需要涉及的使用者介面訪問動作，定義所引起的相關事件，這些方面都在表單類中進行定義，並組成使用者介面包，這裡就不詳細介紹。
動態建模通常採用的方法是使用UML中的時序圖描述用例，一個時序圖針對某個用例中的一個“情境”進行分析。所謂“情境”是指一個用例中事件發展的一條路線。根據活動參與者的不同輸入或行為，通常一個用例會有多個“情境”，也就需要分析出多個時序圖。通過時序圖描述一個情境中各個對象之間所進行的通訊，同時可以分析出系統中相應的類需要具備的操作，從而不斷擴充和細化類的設計。如果需要進一步描述類的狀態變化情況和操作流程，可以使用UML中的狀態圖和活動圖表。

　圖6 登入情境

　動態建模時產生的時序圖較多，這裡無法一一闡述。圖6給出了登入系統情境的時序圖，在使用者介面包中定義了一個LoginForm類，其對應的Web表單為使用者登入表單頁面Login.aspx，圖6描述了在該表單中實現使用者登入的情境。

　2.3 基於ASP.NET的系統實現
　前面系統設計動態模型時，通過時序圖已經對每個用例的各項功能所涉及的情境進行了詳盡的描述，按照時序圖的規定把每個用例都分別進行編碼實現即可。下面結合學生管理系統中的“登入系統”用例，介紹基於ASP.NET進行系統實現的方法。
首先需要考慮分包，ASP.NET中包對應的就是命名空間。在本學生管理系統中，規定商務邏輯包的命名空間為ResultManage.BusinessRule，資料訪問包的命名空間為ResultManage.DataAccess，而使用者介面包的命名空間為ResultManage.Web。

　然後進行商務邏輯包和資料訪問包中相關類的設計，對於“登入系統”用例，從6的登入情境時序圖中可以看出，相關的類有商務邏輯包的Users類和資料訪問包的UsersDB類，分別對這些類的屬性和方法進行定義和實現，並設計一些測試案例或測試程式對其進行單元測試。

　最後按照使用者介面包和6的登入情境時序圖中的規定，對使用者登入表單頁面Login.aspx進行設計實現，其實現登入的代碼如下所示：

private void btnLogin_Click(object sender, System.EventArgs e) { //獲得使用者登入資訊 string UserName = txbUserName.Text; string Password = txbPassword.Text; try { if (Users.Login(UserName , Password)) //檢查使用者登入資訊 { //建立身分識別驗證票 FormsAuthentication.SetAuthCookie(UserName, false); //顯示歡迎資訊 ShowWelcomeMessage(UserName); } else { Message.Text = "使用者登入失敗！"; } } catch (SqlException sqlexception) { //提示資料庫操作錯誤資訊 Response.Write(sqlexception.Message); } } 代碼中對於業務的處理，通過調用商務邏輯包Users類的Login方法實現登入資訊的檢查，其代碼如下： public static bool Login(string UserName , string Password) { if (UserName == "") { return false; } else { //檢查資料庫中是否存在符合的使用者 return UsersDB.CheckLogin(UserName , Password); } }

上述Users類的Login方法的代碼中，首先進行商務邏輯檢查，判斷使用者名稱是否為空白，涉及資料庫訪問則通過資料訪問類完成，通過資料訪問包的UsersDB類的CheckLogin方法從資料庫中檢查是否存在符合相應登入資訊的使用者。

　前面已經提到，包括UsersDB類在內的資料訪問層所有類都從一個基類DBCommon繼承，該基類封裝了所有資料庫訪問類公用的特性，其中包括定義了公用屬性：資料連線字串DBConnectionString。UsersDB類的CheckLogin方法中使用DBConnectionString進行資料庫的串連，並調用資料庫中預存程序CheckLogin尋找使用者登入資訊是否正確。

　3 結束語
　本文介紹了三層B/S結構系統的UML建模和基於ASP.NET進行實現的過程和方法，實現的三層結構不僅程式邏輯上結構清晰，而且由於容易發生需求變更的商務邏輯部分實現了分離，因此具有更強的可擴充性和可維護性。同時這種系統在部署時具有很強的靈活性，可以將各個包分別編譯成.NET組件，安裝在多台伺服器。較典型的是使用者介面包安裝在Web伺服器，商務邏輯包安裝在應用伺服器，資料訪問包安裝在資料庫伺服器或進一步分離，從而實現多級分布的部署方式，實現更好的延展性和安全性，滿足大規模的企業級B/S應用系統的需求。

　參考文獻
　1 Frank Buschmann, Regin Meunier, Hans Rohnert et al. Pattern-Oriented Software Architecture[M]. New York: John Wiley & Sons Ltd, 1996.1~50
　2 T.J. Popp. Software Architecture Development for Produce Line Software[A]. Proceedings of the 18th IEEE Digital Avionics Systems Conference[C]. USA:IEEE Computer Society Press, 1999. 106~111
　3孫昌愛，金茂忠，劉超. 軟體體繫結構研究綜述. 軟體學報[J]，2002，13(7)：1228~1237
收稿日期：4月17日 修改日期：4月30日

　作者簡介：胡穎輝（1971-），男，碩士研究生，主要研究方向：軟體工程。