【正文】 橫軸通過時間組織，是過程展開的生命周期特征。RUP歸納和整理了很多在實踐中總結(jié)出來的軟件工程的最佳實踐，是一 個采用了面向?qū)ο笏枷耄⑶医Y(jié)合了項目管理、質(zhì)量保證等許多軟件工程知識綜合而成的一個非常完整和龐大的軟件方法。 RUP(Rational Unified Process， 統(tǒng)一軟件開發(fā)過程 )[19]是一 種基于構(gòu)件的迭代式開發(fā)方法 ， 該統(tǒng)一過程的出現(xiàn)恰恰滿足了現(xiàn)代軟件生產(chǎn)的需要 。然而，為了從 UML 中得到最大的收益，應(yīng)該考慮這樣的過程，它是：用況驅(qū)動的、以體系結(jié)構(gòu) 為中心的、迭代的和增量。從宏觀看 ， 過程的標(biāo)準化是質(zhì)量保證的手段之一 ； 從微觀看 ， 過程還可擁有具體的手段來改善和保證軟件質(zhì)量 [17]。目前市場上領(lǐng)先的軟件過程主要有 RUP、 OPENProcess和 OOSP。 軟件過程是指實施于軟件開發(fā)和維 護中的階段、方法、技術(shù)、實踐及相關(guān)產(chǎn)物的集合。簡單地講，對象通常是從問題空間或解空間的詞匯中抽取出來的東西；類是對具有共同性質(zhì)的一組對象（從建模者的視角）的描述。 現(xiàn)代的軟件開發(fā)采用面向?qū)ο蟮挠^點進行建模。這種觀點除了傾向于產(chǎn)生脆弱的系統(tǒng) 之外沒有其他本質(zhì)上的害處。按照這種方法，所有的軟件都用過程或函數(shù)作為其主要構(gòu)造塊。 在 OOAD（面向?qū)ο蠓治雠c設(shè)計）中使用 UML 的核心目標(biāo)是通過系統(tǒng)模型來學(xué)習(xí)并理解該 系統(tǒng) [18]。該圖可用于將復(fù)雜的設(shè)計劃分為多個更易于管理的較小設(shè)計。該圖可用于定義內(nèi)部的、面向?qū)ο蟮拇a結(jié)構(gòu)。該圖可用于理解系統(tǒng)元素之間的消息流程。該圖可用于研究系統(tǒng)的體系結(jié)構(gòu)。該圖可用于確保徹底理解給定的功能。本文主 要 用到的 6 種 圖的簡要概括如下： 用例圖顯示了系統(tǒng)的外部可視行為， 描述了系統(tǒng)外的人員和系統(tǒng)的動作，以及系統(tǒng)的響應(yīng) 。 UML 是為了交流。 第四章 系統(tǒng)分析與設(shè)計 23 第四章 系統(tǒng) 分析與設(shè)計 建模技術(shù)與工具 UML 簡介 UML(Unified Modeling Language，統(tǒng)一建模語言 )是一種 用于提取 OOAD 過程的產(chǎn)物和繪制軟件藍圖的標(biāo)準圖形化語言 ， 可以用 UML 對軟件密集型系統(tǒng)的制品進行可視化、詳述、構(gòu)造 和文檔化 [16]。 創(chuàng)建 BLL，調(diào)用 DALFactory，得到程序集指定類的實例，完成數(shù)據(jù)操作方法。 增加 里的配置信息，為 SQLServerDAL 的程序集。 創(chuàng)建 IDAL，實現(xiàn)接口。 SQLServerDAL 引用 Model 和 IDAL，被 DALFactory 加載的程序集，實現(xiàn)接口里的方法。 Model 無引用。 BLL 引用 IDAL， Model， 使用 DALFactory 創(chuàng)建實例。 下圖是本系統(tǒng) 的 概覽 （ 其中 網(wǎng)站 架構(gòu)是核心部分） ： 圖 系統(tǒng)開發(fā) 總體 架構(gòu) 項目結(jié)構(gòu)與簡介 圖 項目核心業(yè)務(wù)架構(gòu) 22 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 表 本系統(tǒng) 項目列表及簡述 表 序號 項目名稱 描述 1 Web 表示層 2 Model 業(yè)務(wù)實體層 3 BLL 業(yè)務(wù)邏輯層 4 DALFactory 數(shù)據(jù)層的抽象工廠 (用于創(chuàng)建反射 ) 5 IDAL 數(shù)據(jù)訪問層的接口定義 6 SQLServerDAL SQLServer 數(shù)據(jù)訪問層 7 DBUtility 數(shù)據(jù)庫訪問組件基礎(chǔ)類 各層的 實現(xiàn)步驟為： ModelIDALSQLServerDALDALFactoryBLLWEB。 ： CategoryDataProxy， ItemDataProxy， ProductDataProxy。 ProfileDALFactory： ProfileDAL 的工廠類 (反射選擇創(chuàng)建 Oracle 和 SQL Server的 ProfileDAL)。（創(chuàng)建具體表的緩存依賴） 。在 中使用依賴注入 技術(shù)，可以有效地 降低 模塊間依賴關(guān)系 ， 并在運行時為應(yīng)用程序動態(tài)注入依賴的具體內(nèi)容，以提升組件重用性 ,并為應(yīng)用程序搭建一個具有較強靈活性和擴展性的 平臺 [15]）?？梢赃x擇 SQLServer 或者 Oracle 數(shù)據(jù)庫。使用一個類的時候只對接口工作，不關(guān)心具體的實現(xiàn)，也不關(guān)心具體的類型。為了確保這個目的，在設(shè)計一個類時，要針對接口，而非實現(xiàn)（ Programming to an Interface， not an Implementation） 。 Petshop 中的設(shè)計模式 設(shè)計模式從本質(zhì)上說是一種規(guī)則，從形式上說，分為創(chuàng)建型、結(jié)構(gòu)型、行為型。如果此時需要修改數(shù)據(jù)訪問層的具體實現(xiàn)，只要不涉及到 IDAL 的接口定義，那么業(yè)務(wù)邏輯層就不會受到任何影響。注意圖中對數(shù)據(jù)訪問業(yè)務(wù)的調(diào)用，是通過接口模塊 IDAL 來完成的。 BLL 層 是業(yè)務(wù)邏輯層的核心模塊，它包含了整個系統(tǒng)的核心業(yè)務(wù) 。 此外，抽象出來的 IDAL 模塊，除了解除了向下的依賴之外，對于其上的業(yè)務(wù)邏輯層，同樣僅存在弱依賴關(guān)系，如下圖所示： B L LI D A LD A L F a c t o r y M o d e l業(yè) 務(wù) 邏 輯 層 ， 核 心 業(yè) 務(wù) 代 碼 都 在 其 中 。 SQLServerDAL 和 OracleDAL 模塊均實現(xiàn) IDAL 模塊的接口，其中包含的邏輯就是對數(shù)據(jù)庫的 Select， Insert， Update 和 Delete 操作。那么，抽象工廠模式中的相關(guān)工廠就可以簡化為一個工廠類了，所以我將這種模式稱之為 “ 具有簡單工廠特質(zhì)的抽象工廠模式 ” 。也就是說，我們可以在 文件中，配置好具體的 Factory 對象的完整的類名。而在 .Net 平臺下，最常見的則是。 解決的辦法是 “ 依賴注入 ” 。這給程序的維護帶來極大的困難。 對于數(shù)據(jù)訪問層來說，最 復(fù)雜 的是 SQL 語句的處理。 第三 章 系統(tǒng)架構(gòu)設(shè)計 19 層。抽象的接口模塊 IDAL，與具體的數(shù)據(jù)庫訪問實現(xiàn)完全隔離。將數(shù)據(jù)實體與其行為分開，使得兩者之間依賴減弱，當(dāng)數(shù)據(jù)行為發(fā)生改變時，并不影響 Model 模塊中的數(shù)據(jù)實體對象，避免了因一個類職責(zé) 過多、過大，從而導(dǎo)致該類的引用者發(fā)生 “ 災(zāi)難性 ” 的影響。由于這些業(yè)務(wù)邏輯對象，僅具有行為而與數(shù)據(jù)無關(guān)，因此它們均被抽象為一個單獨的接口模塊 IDAL。 第二類數(shù)據(jù)庫對 象則是數(shù)據(jù)的業(yè)務(wù)邏輯對象。雖然這些類的屬性分別映射了數(shù)據(jù)表的列，而每一個對象實例也恰恰對應(yīng)于數(shù)據(jù)表的每一行，但這些實體類卻并不具備對應(yīng)的數(shù)據(jù)庫訪問能力，由于數(shù)據(jù)訪問層和業(yè)務(wù)邏輯層都將對這些數(shù)據(jù)實體進行操作，因此程序集 Model 會被這兩層的模塊所引用。它們沒有行為，僅用于表現(xiàn)對象的數(shù)據(jù)。 第三 章 系統(tǒng)架構(gòu)設(shè)計 17 Petshop 的總體分層架構(gòu) 圖 Petshop 的總體分 層架構(gòu) [12] Petshop 項目列表及簡述 表 Petshop 項目列表及簡 述 表 [13] 序號 項目名稱 描述 1 Web 表示層 2 Model 業(yè)務(wù)實體層 3 BLL 業(yè) 務(wù)邏輯層 4 DALFactory 數(shù)據(jù)層 的 抽象工廠 5 IDAL 數(shù)據(jù)訪問層的接口定義 6 SQLServerDAL SQLServer 數(shù)據(jù)訪問層 7 OracleDAL Oracle 數(shù)據(jù)訪問層 8 DBUtility 數(shù)據(jù)庫訪問組件基礎(chǔ)類 9 CacheDependencyFactory 緩存依賴類的工廠類 10 ICacheDependency 緩存依賴類的接口定義 11 TableCacheDependency 緩存依賴實現(xiàn)類 12 IBLLStrategy 同步 /異步處理策略接口 （實現(xiàn)在 bll 根據(jù)配置反射選擇） 13 MessagingFactory 異時處理消息隊列的抽象工廠 14 IMessaging 異時處理消息隊列的接口定義 15 MSMQMessaging 異時處理消息隊列的實現(xiàn) 16 Profile Profile 的數(shù)據(jù)訪問層 17 ProfileDALFactory ProfileDAL 的工廠類（反射創(chuàng)建 ProfileDAL） 18 IProfileDAL Profile 的數(shù)據(jù)層接口定義 19 OracleProfileDAL Oracle 的 Profile Providers 做用戶狀態(tài)管理 20 SQLProfileDAL SQL Server 的 Profile Providers 做用戶狀態(tài)管理 21 Membership Membership 認證和授權(quán)管理 22 OrderProcessor 后臺處理進程，處理訂單隊列 數(shù)據(jù)庫 表示層 (WEB) 業(yè)務(wù)邏輯層 (BLL) 數(shù)據(jù)訪問層 (DAL) IDAL IoC(DAFactory) 實體類 (Model) 18 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) Petshop 各層模塊結(jié)構(gòu)圖 及主要層次簡介 D A L F a c t o r y I D A L M o d e lS Q L S e r v e r D A L創(chuàng) 建 D A L 對 象 的 工 廠訪 問 M S S Q L S e r v e r 數(shù) 據(jù) 庫 的數(shù) 據(jù) 訪 問 層 ， 實 現(xiàn) 了 I D A L 接 口數(shù) 據(jù) 訪 問 層 的 接 口 程 序 集數(shù) 據(jù) 訪 問 層 需 要 使 用 的 數(shù) 據(jù) 對 象 ， 即 為持 久 層 的 持 久 對 象 ， 只 有 屬 性 ， 沒 有 行 為 圖 數(shù)據(jù)訪問層的模塊結(jié)構(gòu)圖 層。所以其一經(jīng)推出，便成為了開發(fā)者、架構(gòu)師等人學(xué)習(xí)、研究的典范。 Petshop 是一個范例，微軟用它來展示 .Net 企業(yè)系統(tǒng)開發(fā)的能力。為 了用事實說話， 開發(fā)人員 通過對項目各方面的性能評估進而在比較 .NET 和 Java 的高下。所以，一個簡單的判斷法則就是： 如果您的系統(tǒng)層內(nèi)頻繁變動（甚至整層替換 ）的 可能性很大，而 API 變動可能性很小，就使 用分層；而如果 API 可能會頻繁變動，那就要謹慎使用分層架構(gòu)了。如在級聯(lián)修改中提到的 “ 在分頁的同時還能分部門 ” 的新需求，就是對 API 進行的變動。對待分層架構(gòu)，我們的態(tài)度應(yīng)當(dāng)是 先 明晰其本質(zhì)和利弊，然后根據(jù)具體情況做出理性的分析和抉擇。這是不言而喻的 ， 如果不采用分層 式結(jié)構(gòu)，很多業(yè)務(wù)可以直接 訪問 數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。如果在表示層中需要增加一個功能，為保證其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼。 然后是 分層架構(gòu)的弊端： 16 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 。 利于各層邏輯的復(fù)用 。 層與層間的依賴。 開發(fā)人員在開發(fā)某一層時就可以關(guān)注集中于這一層所用的思想、模式、技術(shù)，這樣，就等同于將分工帶來的生產(chǎn)力提高優(yōu)勢引入軟件開發(fā)。 由于某一層僅僅調(diào)用其相鄰下一層所提供的服務(wù)，所以，只要本層的 API和相鄰下一層的 API定義完整。在 Petshop 中，是利用 來設(shè)計的，因此包含了許多 Web 控件和相關(guān)邏輯。表示層一般為第三 章 系統(tǒng)架構(gòu)設(shè)計 15 Windows 窗體應(yīng)用程序或 Web 應(yīng)用程序。 表示層：是系統(tǒng)的 UI 部分，負責(zé)使用者與整個系統(tǒng)的交互。它的關(guān)注點主要集中在業(yè)務(wù)規(guī)則的制定、業(yè)務(wù)流程的實現(xiàn)等與業(yè)務(wù)需求有關(guān)的系統(tǒng)設(shè)計，也即是說它是與系統(tǒng)所應(yīng)對的領(lǐng)域（ Domain）邏輯有關(guān)，很多時候，也將業(yè)務(wù)邏輯層稱為領(lǐng)域?qū)印?主要負責(zé)數(shù)據(jù)的傳遞和處理，是 針對具體問題的操作，也可以說是對數(shù)據(jù)層的操作，對數(shù)據(jù)業(yè)務(wù)邏輯的 處理 。 業(yè)務(wù)邏輯層 ： 業(yè)務(wù)邏輯層是表示層和數(shù)據(jù)訪問層之間溝通的橋梁， 這一層為用戶界面層提供功能調(diào)用，同時它又調(diào)用數(shù)據(jù)訪問層所提供的功能訪問 數(shù)據(jù) 庫 [8]。如果要加入 ORM 的元素，那么就會包括對象和數(shù)據(jù)表之間的 mapping，以及對象實體的持久化。 數(shù)據(jù)訪問層： 有時候也稱為是持久 層，其功能主要是負責(zé)數(shù)據(jù)庫的訪問，可以訪問數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是 XML 文檔 。在三層結(jié)構(gòu)中，各層之間相互依賴，表示層依賴于業(yè)務(wù)邏輯層，業(yè)務(wù)邏輯層依賴于數(shù)據(jù)訪問層。 微軟推薦的 三層架構(gòu) (3tier application)通常意義上的三層架構(gòu)就是將整個業(yè)務(wù)應(yīng)用劃分為：表現(xiàn)層（ UI）、業(yè)務(wù)邏輯層（ BLL）、數(shù)據(jù)訪問層（ DAL）。其中，除最上層外，每一層僅提供若干服務(wù)供其相鄰的上層使用，但不知道上層的存在；除最下層外，每一層僅調(diào)用其臨近下層的服務(wù) [8]。 在 軟件體系架構(gòu)設(shè)計中， 分層式結(jié)構(gòu)是最常14 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 見，也是最重要的一種結(jié)構(gòu)。 錢學(xué)森就說過： “ 什 么叫系統(tǒng)？系統(tǒng)就是由許多部分組成的整體，所以系統(tǒng)的概念就是要強調(diào)整體，強調(diào)整體是由相互關(guān)聯(lián)、相互制約的各個部分所組成的。