【正文】 橫軸通過時間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的。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ǔn)化是質(zhì)量保證的手段之一 ； 從微觀看 ， 過程還可擁有具體的手段來改善和保證軟件質(zhì)量 [17]。目前市場上領(lǐng)先的軟件過程主要有 RUP、 OPENProcess和 OOSP。 軟件過程是指實施于軟件開發(fā)和維護(hù)中的階段、方法、技術(shù)、實踐及相關(guān)產(chǎn)物的集合。簡單地講，對象通常是從問題空間或解空間的詞匯中抽取出來的東西；類是對具有共同性質(zhì)的一組對象（從建模者的視角）的描述。 現(xiàn)代的軟件開發(fā)采用面向?qū)ο蟮挠^點進(jìn)行建模。這種觀點除了傾向于產(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)物和繪制軟件藍(lán)圖的標(biāo)準(zhǔn)圖 形化語言 ， 可以用 UML 對軟件密集型系統(tǒng)的制品進(jìn)行可視化、詳述、構(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)用程序搭建一個具有較強靈活性和擴(kuò)展性的 平臺 [15]）。可以選擇 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 平臺下，最常見的則是。 解決的辦法是 “ 依賴注入 ” 。這給程序的維護(hù)帶來極大的困難。 對于數(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ù)實體進(jìn)行操作，因此程序集 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 認(rèn)證和授權(quán)管理 22 OrderProcessor 后臺處理進(jìn)程，處理訂單隊列 數(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ā)人員 通過對項目各方面的性能評估進(jìn)而在比較 .NET 和 Java 的高下。所以，一個簡單的判斷法則就是： 如果您的系統(tǒng)層內(nèi)頻繁變動（甚至整層替換 ）的 可能性很大，而 API 變動可能性很小，就使 用分層；而如果 API 可能會頻繁變動，那就要謹(jǐn)慎使用分層架構(gòu)了。如在級聯(lián)修改中提到的 “ 在分頁的同時還能分部門 ” 的新需求，就是對 API 進(jìn)行的變動。對待分層架構(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 部分，負(fù)責(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ū)印?主要負(fù)責(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ù)訪問層： 有時候也稱為是持久 層，其功能主要是負(fù)責(zé)數(shù)據(jù)庫的訪問，可以訪問數(shù)據(jù)庫系統(tǒng)、二進(jìn)制文件、文本文檔或是 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)、相互制約的各個部分所組成的。