系統(tǒng)分析與設(shè)計第5章

5系統(tǒng)架構(gòu)設(shè)計前面介紹的內(nèi)容涉及到的是系統(tǒng)分析階段，本章我們將介紹關(guān)于系統(tǒng)設(shè)計階段的內(nèi)容及注意事項。分析活動的結(jié)果是規(guī)范，規(guī)定了基于這些需求提出的系統(tǒng)會完成什么工作；而設(shè)計生成的方案用于滿足分析得到的要求。本章介紹:系統(tǒng)設(shè)計階段的任務(wù)包括系統(tǒng)架構(gòu)設(shè)計（即設(shè)計軟件系統(tǒng)的模塊層次結(jié)構(gòu)），數(shù)據(jù)庫的設(shè)計、應(yīng)用邏輯和資源的設(shè)計；學習要求:本章主要討論系統(tǒng)架構(gòu)設(shè)計、應(yīng)用邏輯和資源的設(shè)計；本章導讀本章目錄5.1架構(gòu)設(shè)計（總體設(shè)計）5.1.1架構(gòu)師的定位及其應(yīng)掌握的知識體系5.1.2軟件架構(gòu)的設(shè)計目標、設(shè)計策略和原則5.1.3常用的軟件架構(gòu)風格及使用情況分析5.1.4分層架構(gòu)5.1.5客戶/服務(wù)器架構(gòu)5.1.6教學管理系統(tǒng)架構(gòu)選擇和設(shè)計示例5.2從需求到設(shè)計的轉(zhuǎn)換5.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換5.2.2工資管理系統(tǒng)數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換示例5.2.3.從需求模型到軟件架構(gòu)5.2.4軟件設(shè)計模式5.2.5GRASP設(shè)計模式5.2.6GOF設(shè)計模式5.3系統(tǒng)資源設(shè)計5.3.1系統(tǒng)應(yīng)用邏輯設(shè)計5.3.2系統(tǒng)物理設(shè)計及實現(xiàn)本章小結(jié)和習題軟件體系結(jié)構(gòu)通常被稱為架構(gòu)；對該名詞的認識，主流的觀點有很多，如ANSI/IEEE610.12-1990軟件工程標準詞匯對于體系結(jié)構(gòu)的定義、美國卡內(nèi)基梅隆大學軟件工程研究所的MaryShaw和DavidGarlan的觀點等；目前，通用的觀點認為，軟件架構(gòu)是指軟件系統(tǒng)的結(jié)構(gòu)和風格設(shè)計、使用方案和行為的設(shè)計，以及軟件功能構(gòu)件的區(qū)分、歸類、構(gòu)件接口和它們之間數(shù)據(jù)交換的規(guī)范和標準。架構(gòu)設(shè)計應(yīng)按照數(shù)據(jù)、過程、接口和網(wǎng)絡(luò)構(gòu)件，給出系統(tǒng)構(gòu)造使用的技術(shù)?！?.1架構(gòu)設(shè)計（總體設(shè)計）

1.架構(gòu)師的定位

在系統(tǒng)分析與設(shè)計中，起關(guān)鍵作用的人員有兩類：系統(tǒng)架構(gòu)師和軟件架構(gòu)師。兩者既有相似的特質(zhì)，也有各具特色的能力和要求。系統(tǒng)架構(gòu)師(1)職責:一是理解系統(tǒng)的業(yè)務(wù)需求，制定系統(tǒng)的整體框架（包括技術(shù)框架和業(yè)務(wù)框架）二是對系統(tǒng)框架相關(guān)技術(shù)和業(yè)務(wù)進行培訓，指導開發(fā)人員開發(fā)，并解決系統(tǒng)開發(fā)、運行中出現(xiàn)的各種問題。主要責任之一是對系統(tǒng)的重用、擴展、安全、性能、伸縮性、簡潔性等做系統(tǒng)級的把握。(2)能力要求:一是系統(tǒng)架構(gòu)相關(guān)的知識和經(jīng)驗二是很強的自學能力、分析能力、解決問題的能力三是寫作、溝通表達、培訓的知識和經(jīng)驗。

§5.1.1架構(gòu)師的定位及其應(yīng)掌握的知識體系軟件架構(gòu)師的角色是主導系統(tǒng)全局的分析、設(shè)計和實施，負責軟件架構(gòu)和關(guān)鍵技術(shù)的決策。(1)職責領(lǐng)導與協(xié)調(diào)整個項目中的技術(shù)活動（分析、設(shè)計和實施等）推動主要的技術(shù)決策，并最終表達為軟件構(gòu)架確定和文檔化系統(tǒng)中相對構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設(shè)計、實施和部署等“視圖”確定設(shè)計元素的分組以及這些主要分組之間的接口為技術(shù)決策提供規(guī)則，平衡各類涉眾的不同關(guān)注點，化解技術(shù)風險，并保證相關(guān)決定被有效的傳達和貫徹理解、評價并接收系統(tǒng)需求評價和確認軟件架構(gòu)的實現(xiàn)。

軟件架構(gòu)師作為整個軟件系統(tǒng)結(jié)構(gòu)的總設(shè)計師，其知識體系、技能和經(jīng)驗決定了軟件系統(tǒng)的可靠性、安全性、可維護性、可擴展性和可移植性等方面的性能。§5.1.1架構(gòu)師的定位及其應(yīng)掌握的知識體系

通過對比軟件架構(gòu)師和系統(tǒng)分析師在軟件開發(fā)中的職責和角色，不難發(fā)現(xiàn)軟件架構(gòu)師與系統(tǒng)分析師所必需的知識體系也是不盡相同的系統(tǒng)分析師的主要職責是在需求分析、開發(fā)管理、運行維護等方面,而軟件架構(gòu)師的重點工作是在架構(gòu)與設(shè)計這兩個關(guān)鍵環(huán)節(jié)上。

因此在系統(tǒng)分析師必須具備的知識體系中對系統(tǒng)的構(gòu)架與設(shè)計等方面知識體系的要求就相對低些；而軟件架構(gòu)師在需求分析、項目管理、運行維護等方面知識的要求也就相對低些。§5.1.1架構(gòu)師的定位及其應(yīng)掌握的知識體系二、架構(gòu)師應(yīng)掌握的知識體系軟件架構(gòu)師所應(yīng)具備的軟件知識主要包括：最好要有系統(tǒng)開發(fā)全過程經(jīng)驗；對

IT建設(shè)生命周期各個環(huán)節(jié)有深入了解，比如：系統(tǒng)/模塊邏輯設(shè)計、物理設(shè)計、代碼開發(fā)、項目管理、測試、發(fā)布、運行維護等深入掌握1-2種主流技術(shù)平臺上開發(fā)系統(tǒng)的方法了解多種應(yīng)用系統(tǒng)的結(jié)構(gòu)了解架構(gòu)設(shè)計領(lǐng)域的主要理論、流派、框架。

成為一名合格的軟件架構(gòu)師必須至少具備兩方面的知識：信息系統(tǒng)綜合知識體系和軟件架構(gòu)知識體系。

信息系統(tǒng)綜合知識體系包括：計算機系統(tǒng)綜合知識；系統(tǒng)配置和方法方面的知識；典型系統(tǒng)應(yīng)用的知識；系統(tǒng)開發(fā)知識；安全性和可靠性技術(shù)方面的知識；標準化方面的知識；信息化基礎(chǔ)方面的知識；數(shù)學和英語基礎(chǔ)知識?！?.1.1架構(gòu)師的定位及其應(yīng)掌握的知識體系軟件架構(gòu)知識體系包括(1)系統(tǒng)計劃(2)軟件架構(gòu)設(shè)計(3)設(shè)計模式(4)系統(tǒng)設(shè)計(5)軟件建模(6)分布式系統(tǒng)設(shè)計(7)嵌入式系統(tǒng)設(shè)計(8)系統(tǒng)可靠性分析與設(shè)計(9)系統(tǒng)的安全性和保密性設(shè)計(10)復雜架構(gòu)設(shè)計§5.1.1架構(gòu)師的定位及其應(yīng)掌握的知識體系軟件架構(gòu)是一個軟件系統(tǒng)從整體到部分的最高層次的劃分，描述軟件系統(tǒng)中構(gòu)件如何形成整體架構(gòu)，構(gòu)件相互之間如何發(fā)生作用，這些都是關(guān)于軟件系統(tǒng)本身結(jié)構(gòu)的重要信息。目的:1.使軟件系統(tǒng)能夠達到為用戶提供最佳的功能和服務(wù)狀態(tài)2.使軟件和系統(tǒng)的結(jié)合達到最佳運行性能3.合理和最佳地利用系統(tǒng)的各項資源4.在軟件的開發(fā)、部署、運行、維護、升級換代上提供最大的靈活性5.為系統(tǒng)提供最大的安全性、穩(wěn)定性和可靠性的各項質(zhì)量素質(zhì)。

因此，軟件架構(gòu)的設(shè)計目標包括：可靠性、安全性、可擴展性、可定制化、可延伸性、可維護性、客戶體驗特性、市場時機等幾個因素?！?.1.2軟件架構(gòu)的設(shè)計目標、設(shè)計策略和原則§5.1.2軟件架構(gòu)的設(shè)計目標、設(shè)計策略和原則軟件架構(gòu)設(shè)計的策略主要包括以下四個方面：一是全面認識需求。需求分析的好壞對整個項目的成敗起著決定性的作用。為了更好地設(shè)計軟件架構(gòu)，需要建立多維度、檢查表式的“需求分類圖譜”。二是關(guān)鍵需求決定架構(gòu)的選擇。架構(gòu)的選擇和設(shè)定既要照顧全面需求，又要突出重點，既要滿足必須的需求，又要在理解全面需求的基礎(chǔ)上，設(shè)計和選擇更合理的架構(gòu)。三是多視圖探尋架構(gòu)。著名的“4+1”視圖架構(gòu)包含邏輯視圖、進程視圖、物理視圖、開發(fā)視圖和場景視圖，強調(diào)從多個視角對同一個問題進行建模和設(shè)計，不同視圖側(cè)重點不同，可根據(jù)具體情況做適當選擇和增減。四是盡早驗證架構(gòu)。驗證架構(gòu)的技術(shù)可分為兩種：原型法（RUP稱為可執(zhí)行架構(gòu)）和框架法。根據(jù)構(gòu)建原型法的基礎(chǔ)可將原型法分為水平原型和垂直原型；根據(jù)后續(xù)環(huán)節(jié)中是否保留原型內(nèi)容，可將原型法分為拋棄原型和進化原型。§5.1.2軟件架構(gòu)的設(shè)計目標、設(shè)計策略和原則框架有多種分類方法:按照在不同階段的使用目的不同可分為：技術(shù)框架、業(yè)務(wù)框架按照框架的透明程度可分為：白盒框架、黑盒框架和灰盒框架按照系統(tǒng)不同層次應(yīng)用框架的技術(shù)可分為：應(yīng)用框架、中間件框架和基礎(chǔ)平臺框架按照框架的基礎(chǔ)可分為：垂直框架和水平框架；分類標準內(nèi)容在不同階段的使用目的不同技術(shù)框架、業(yè)務(wù)框架（針對不同領(lǐng)域）框架的透明程度白盒框架、黑盒框架和灰盒框架系統(tǒng)不同層次應(yīng)用框架的技術(shù)應(yīng)用框架、中間件框架和基礎(chǔ)平臺框架框架的基礎(chǔ)垂直框架和水平框架§5.1.2軟件架構(gòu)的設(shè)計目標、設(shè)計策略和原則軟件架構(gòu)設(shè)計必須遵循的原則包括：滿足功能性需求和非功能需求；實用性原則；滿足復用的要求，最大程度地提高開發(fā)人員的工作效率。詳細地講，軟件架構(gòu)設(shè)計的原則可從以下四個方面提出指導：1、設(shè)計總綱。包括領(lǐng)域視角原則、系統(tǒng)視角原則、重用原則、商業(yè)目標原則、一致性原則、夠用/簡單原則、變化點分離原則、邏輯與物理分離原則、支持分階段交付原則等九個方面。§5.1.2軟件架構(gòu)的設(shè)計目標、設(shè)計策略和原則2、子系統(tǒng)/模塊劃分原則。包括高內(nèi)聚、低耦合原則、數(shù)據(jù)冗余最小原則、通用的平面劃分原則、數(shù)據(jù)一致性原則、通用的層次劃分原則、分層的單向依賴原則、無循環(huán)依賴原則、避免跨層通訊原則、解耦原則、實現(xiàn)無關(guān)性原則、靈活部署原則等十一個方面。3、接口設(shè)計原則。包括標準化原則、擴展性原則、兼容性原則、抽象性原則等四個方面。4、質(zhì)量屬性設(shè)計原則。包括可重用性、可擴展性、可修改性、可移植性、兼容性、可伸縮性、可裁減性、性能原則、可用性/可靠性原則、安全性、可測試性/可調(diào)試性、可安裝性、可生產(chǎn)性/可制造型、可配置性、成本、易懂性、可維護性等十七個方面?！?.1.3常用的軟件架構(gòu)風格及使用情況分析根據(jù)我們關(guān)注的角度不同，可以將軟件架構(gòu)分成三種：邏輯架構(gòu)、物理架構(gòu)和系統(tǒng)架構(gòu)。邏輯架構(gòu)指軟件系統(tǒng)中元件之間的關(guān)系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件等等物理架構(gòu)指軟件元件是怎樣放到硬件上的。系統(tǒng)架構(gòu)指的是系統(tǒng)的非功能性特征，如可擴展性、可靠性、強壯性、靈活性、性能等。系統(tǒng)架構(gòu)的設(shè)計，要求架構(gòu)師具備軟件和硬件的功能和性能的過硬知識，這一工作是架構(gòu)設(shè)計工作中最困難的工作。§5.1.3常用的軟件架構(gòu)風格及使用情況分析框架、模式的定義及他們之間的區(qū)別和聯(lián)系框架(Framework)是某種應(yīng)用的半成品，是完成特定系統(tǒng)的一組供選用構(gòu)件,一般從分層的觀點看，認為框架是底層的，接近系統(tǒng)的，軟件開發(fā)者在框架上構(gòu)建自己的軟件架構(gòu)，開發(fā)自己的應(yīng)用程序。框架一般是成熟、穩(wěn)健的，可以處理系統(tǒng)很多細節(jié)問題，比如，事務(wù)性、安全性，數(shù)據(jù)流控制等問題；框架一般都經(jīng)過很多人使用，所以結(jié)構(gòu)很好、擴展性也很好，而且它是不斷升級的，使用框架的開發(fā)者可以直接享受別人升級代碼帶來的好處；框架一般是處于底層應(yīng)用平臺（如JAVAEE）和高層業(yè)務(wù)邏輯之間的中間層。按照目前主流的設(shè)計環(huán)境，常見的框架包括JAVA框架、.Net框架和基于C++的框架三種。§5.1.3常用的軟件架構(gòu)風格及使用情況分析模式（Pattern），Alexander給出的經(jīng)典定義是：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心。通過這種方式，你可以無數(shù)次地使用那些已有的解決方案，無需再重復相同的工作。通俗地說，模式其實就是解決某一類問題的方法論，即把解決某類問題的方法總結(jié)歸納到理論高度?！?.1.3常用的軟件架構(gòu)風格及使用情況分析按照解決問題的類型不同，模式可分為架構(gòu)模式(ArchitecturalPattern)、設(shè)計模式(DesignPattern)和代碼模式(CodingPattern)。三者的區(qū)別在于各自抽象層次的不同。架構(gòu)模式是一個系統(tǒng)的高層次策略，涉及到大尺度的構(gòu)件以及整體性質(zhì)，架構(gòu)模式的好壞可以影響到總體布局和框架結(jié)構(gòu)。設(shè)計模式是中等尺度的結(jié)構(gòu)策略，能夠?qū)崿F(xiàn)一些大尺度構(gòu)件的行為和它們之間的關(guān)系，設(shè)計模式的好壞不會影響到系統(tǒng)的總體布局和總體框架，只定義出子系統(tǒng)或構(gòu)件的微觀結(jié)構(gòu)。

代碼模式是特定的范例和與特定語言有關(guān)的編程技巧，代碼模式的好壞會影響到一個中等尺度構(gòu)件內(nèi)部、外部的結(jié)構(gòu)或行為的底層細節(jié)，但不會影響到一個部件或子系統(tǒng)的中等尺度的結(jié)構(gòu)，更不會影響到系統(tǒng)的總體布局和大尺度框架。§5.1.4分層架構(gòu)從軟件設(shè)計發(fā)展的歷史和現(xiàn)代流行的軟件開發(fā)觀點看，分層架構(gòu)是軟件分析和設(shè)計的基本的、具有普遍適應(yīng)性的思想方法。分層架構(gòu)最典型的例子應(yīng)該是計算機網(wǎng)絡(luò)的體系結(jié)構(gòu)。國際標準化組織ISO的開放系統(tǒng)互聯(lián)OSI將網(wǎng)絡(luò)體系結(jié)構(gòu)劃分為七層協(xié)議的模型，包括：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。嚴格的分層系統(tǒng)在不相鄰的層之間不發(fā)生直接的聯(lián)系。但在某些層次系統(tǒng)中處于某一層的構(gòu)件可以調(diào)用所在層之下的服務(wù)，不僅限于相鄰的下一層。分層架構(gòu)設(shè)計一個主要的目的，就是把系統(tǒng)劃分成為很多“板塊”。劃分的方式通常有兩種，橫向劃分和縱向劃分。橫向劃分一般將系統(tǒng)按照商業(yè)目的或功能進行劃分，比如一個“書店管理系統(tǒng)”可以劃分成為進貨、銷售、庫存管理、員工管理等等縱向劃分則按照抽象層次的高低，將系統(tǒng)劃分成“層”，或叫Layer①。比如“一個公司的內(nèi)網(wǎng)管理系統(tǒng)”通?？梢詣澐殖蔀橄旅娴膸讉€層次：網(wǎng)頁層，也就是用戶界面層，負責顯示數(shù)據(jù)、接受用戶輸入；領(lǐng)域?qū)?，包括JavaBean或者COM對象、B2B服務(wù)等構(gòu)件，封裝必要的商業(yè)邏輯，負責根據(jù)商業(yè)邏輯決定顯示什么數(shù)據(jù)、以及如何根據(jù)用戶輸入的數(shù)據(jù)進行計算；數(shù)據(jù)庫層，負責存儲數(shù)據(jù)，按照查詢要求提供所存儲的數(shù)據(jù)；操作系統(tǒng)層，比如WindowsNT或者Solaris等；硬件層，比如SUNE450服務(wù)器等?！?.1.4分層架構(gòu)典型的三層結(jié)構(gòu)包括：表示層、領(lǐng)域?qū)?、基礎(chǔ)架構(gòu)層。表示層邏輯主要處理用戶和軟件的交互，如視窗圖形界面（WIMP）和基于html的界面，其職責就是為用戶提供信息，以及把用戶的指令翻譯后傳送給業(yè)務(wù)層和基礎(chǔ)架構(gòu)層；基礎(chǔ)架構(gòu)層邏輯包括處理和與其他系統(tǒng)的通信，代表系統(tǒng)執(zhí)行任務(wù)等，例如數(shù)據(jù)庫系統(tǒng)交互，和其他應(yīng)用系統(tǒng)的交互等；領(lǐng)域?qū)舆壿嬘袝r也稱業(yè)務(wù)邏輯，包括輸入和存儲數(shù)據(jù)的計算、驗證表示層傳回來的數(shù)據(jù)，根據(jù)表示層的指令指派一個基礎(chǔ)架構(gòu)層邏輯。表示層領(lǐng)域（業(yè)務(wù)）層基礎(chǔ)架構(gòu)層§5.1.4分層架構(gòu)

一種改進的分層架構(gòu)包括表示層、控制/中介層、領(lǐng)域?qū)印?shù)據(jù)映射層、數(shù)據(jù)源層。

表示層和領(lǐng)域?qū)又g的中介（控制）層，主要針對一些非可視的控件，例如為特定的表示層組織信息格式、在不同的窗口間導航、處理交易邊界、提供服務(wù)的外觀模式接口等。把行為分配給表示層可以簡化問題，但表示層模型會比較復雜，所以，把這些行為放到非可視化的對象中，并提取出一個表示-領(lǐng)域中介層是值得的。

領(lǐng)域?qū)雍突A(chǔ)架構(gòu)層之間的中介層屬于數(shù)據(jù)映射層，是上層的領(lǐng)域?qū)雍蛿?shù)據(jù)連接的辦法之一。與表示-領(lǐng)域中介層一樣，數(shù)據(jù)映射層有時候有用，但不是所有時候都有用。

表示層控制/中介層領(lǐng)域（業(yè)務(wù)）層數(shù)據(jù)源層數(shù)據(jù)映射層§5.1.4分層架構(gòu)§5.1.5客戶/服務(wù)器架構(gòu)客戶/服務(wù)器（Client/Server）結(jié)構(gòu)通?？s寫為C/S結(jié)構(gòu)，

C/S體系結(jié)構(gòu)有三個主要組成部分：數(shù)據(jù)庫服務(wù)器、客戶應(yīng)用程序和網(wǎng)絡(luò).

C/S體系結(jié)構(gòu)將應(yīng)用一分為二，服務(wù)器（后臺）負責有效地管理系統(tǒng)的資源，包括：（1）數(shù)據(jù)庫安全性的要求；（2）數(shù)據(jù)庫訪問并發(fā)性的控制；（3）數(shù)據(jù)庫前端的客戶應(yīng)用程序的全局數(shù)據(jù)完整性規(guī)則；（4）數(shù)據(jù)庫的備份與恢復?？蛻魴C（前臺）完成與用戶的交互任務(wù)，主要任務(wù)包括：（1）提供用戶與數(shù)據(jù)庫交互的界面；（2）向數(shù)據(jù)庫服務(wù)器提交用戶請求并接收來自數(shù)據(jù)庫服務(wù)器的信息；（3）利用客戶應(yīng)用程序?qū)Υ嬖谟诳蛻舳说臄?shù)據(jù)執(zhí)行應(yīng)用邏輯要求。C/S架構(gòu)的缺點也比較多，主要表現(xiàn)在：由于對客戶端軟硬件配置要求較高而導致開發(fā)成本較高；因大部分事務(wù)處理工作集中在客戶端完成，故客戶端程序設(shè)計復雜；客戶端一般只是事務(wù)處理，界面單一、枯燥；用戶界面風格不一，使用繁雜，不利于推廣使用；由于客戶端用不同開發(fā)工具開發(fā)的軟件一般互不兼容，軟件移植困難；對分散到各個客戶端的軟件維護和升級也比較困難；新技術(shù)不能輕易應(yīng)用等?！?.1.5客戶/服務(wù)器架構(gòu)三層C/S體系結(jié)構(gòu)將應(yīng)用功能分成表示層、功能層和數(shù)據(jù)層三個部分：表示層是應(yīng)用的用戶接口部分，擔負著用戶與應(yīng)用間的對話功能，主要用于檢查用戶從鍵盤等設(shè)備輸入的數(shù)據(jù)，顯示應(yīng)用輸出的數(shù)據(jù)，檢查的內(nèi)容也只限于數(shù)據(jù)的形式和取值的范圍，不包括有關(guān)業(yè)務(wù)本身的處理邏輯。

功能層又稱應(yīng)用邏輯層，是應(yīng)用邏輯處理的核心，是連接客戶端和數(shù)據(jù)庫服務(wù)器的中介和橋梁，響應(yīng)用戶發(fā)來的請求，執(zhí)行某種應(yīng)用邏輯任務(wù)，同時向數(shù)據(jù)庫服務(wù)器發(fā)送SQL請求，數(shù)據(jù)庫服務(wù)器將數(shù)據(jù)和結(jié)果通過應(yīng)用服務(wù)器最終返回給客戶端。數(shù)據(jù)層的主要組成部分就是數(shù)據(jù)庫管理系統(tǒng)，負責管理對數(shù)據(jù)庫中數(shù)據(jù)的讀寫工作，該層主要任務(wù)是實現(xiàn)數(shù)據(jù)的存儲、數(shù)據(jù)的訪問控制、數(shù)據(jù)完整性約束和并發(fā)控制等等?！?.1.5客戶/服務(wù)器架構(gòu)瀏覽器/服務(wù)器（Browser/Server，B/S）包括：瀏覽器/Web服務(wù)器/數(shù)據(jù)庫服務(wù)器三層。B/S體系結(jié)構(gòu)主要是利用不斷成熟的WWW瀏覽器技術(shù)，結(jié)合瀏覽器的多種腳本語言，用通用瀏覽器實現(xiàn)原來需要復雜的專用軟件才能實現(xiàn)的強大功能，并節(jié)約開發(fā)成本?！?.1.5客戶/服務(wù)器架構(gòu)B/S架構(gòu)的優(yōu)點是：基于B/S體系結(jié)構(gòu)的軟件簡化了客戶端，系統(tǒng)安裝、修改和維護全在服務(wù)器端解決。用戶在使用系統(tǒng)時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能；B/S體系結(jié)構(gòu)模式特別適用于網(wǎng)上信息的發(fā)布；B/S體系結(jié)構(gòu)還提供了異種機、異種網(wǎng)、異種應(yīng)用服務(wù)的聯(lián)機、聯(lián)網(wǎng)、統(tǒng)一服務(wù)的最現(xiàn)實的開放性基礎(chǔ)。

B/S體系結(jié)構(gòu)的缺點是：缺乏對動態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能；系統(tǒng)擴展能力差，安全性難以控制；應(yīng)用系統(tǒng)在數(shù)據(jù)查詢等響應(yīng)速度上，要遠遠地低于C/S體系結(jié)構(gòu)；數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務(wù)處理(OnLineTransactionProcessing，OLTP)應(yīng)用。§5.1.5客戶/服務(wù)器架構(gòu)根據(jù)教學管理系統(tǒng)的需求描述，軟件架構(gòu)設(shè)計可以選擇分層架構(gòu)中的C/S和B/S混合體系結(jié)構(gòu)，鑒于教務(wù)管理人員對教學管理系統(tǒng)的操作較多，建議選擇通過內(nèi)部局域網(wǎng)訪問的C/S體系結(jié)構(gòu)，而一般的學生和其他使用該教學管理系統(tǒng)的人員，則可以選擇B/S體系結(jié)構(gòu)構(gòu)建。該教學管理系統(tǒng)的架構(gòu)選擇和設(shè)計示意圖參見?！?.1.6教學管理系統(tǒng)架構(gòu)選擇和設(shè)計示例客戶層應(yīng)用層DBMS層操作系統(tǒng)層硬件層瀏覽器端局域網(wǎng)客戶端一般用戶教務(wù)人員DBMS層操作系統(tǒng)層硬件層§5.2從需求到設(shè)計的轉(zhuǎn)換軟件設(shè)計可在多個層面進行。一般地，總體設(shè)計（也稱為系統(tǒng)設(shè)計或架構(gòu)設(shè)計）提出影響整個系統(tǒng)結(jié)構(gòu)方面的標準，而詳細設(shè)計則提出類的設(shè)計以及系統(tǒng)詳細的工作機制。軟件總體設(shè)計的方法主要有面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計、結(jié)構(gòu)化設(shè)計和面向?qū)ο蟮脑O(shè)計面向數(shù)據(jù)結(jié)構(gòu)設(shè)計的基本原則是基于系統(tǒng)輸入/輸出數(shù)據(jù)進行的設(shè)計，首先確定數(shù)據(jù)結(jié)構(gòu)，然后賦予每個過程與它所操作的數(shù)據(jù)相同的數(shù)據(jù)結(jié)構(gòu)，主要針對以數(shù)據(jù)為核心的、規(guī)模比較小的系統(tǒng)設(shè)計，最著名的是MichaelJackson、Warnier和Orr的技術(shù)，這種面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計遠沒有像結(jié)構(gòu)化設(shè)計那樣流行，而且隨著面向?qū)ο蠓缎偷某霈F(xiàn)，它基本上已經(jīng)不再使用了，本書不再對此進行專門討論結(jié)構(gòu)化設(shè)計是一種面向過程的設(shè)計或稱為面向數(shù)據(jù)流的設(shè)計方法，是應(yīng)用最廣泛的設(shè)計方法之一，可以建立良好的系統(tǒng)結(jié)構(gòu)，也可以與結(jié)構(gòu)化分析方法、結(jié)構(gòu)化程序設(shè)計方法前后呼應(yīng)，形成統(tǒng)一、完整的系列化方法，該方法以需求分析階段獲得的數(shù)據(jù)流圖為基礎(chǔ)，通過一系列映射機制，把數(shù)據(jù)流圖變換為軟件結(jié)構(gòu)圖；面向?qū)ο笤O(shè)計的詳細內(nèi)容我們將在第六章中闡述；本節(jié)主要闡述結(jié)構(gòu)化方法中，從需求到設(shè)計的轉(zhuǎn)換。需求分析階段，我們已經(jīng)通過結(jié)構(gòu)化分析方法產(chǎn)生了數(shù)據(jù)流圖。結(jié)構(gòu)化設(shè)計能方便地將數(shù)據(jù)流圖（DataFlowDiagram,DFD)轉(zhuǎn)換成軟件結(jié)構(gòu)圖。DFD中從系統(tǒng)的輸入數(shù)據(jù)流到系統(tǒng)的輸出數(shù)據(jù)流的一連串連續(xù)變換形成了一條信息流。根據(jù)數(shù)據(jù)流類型不同，可分為變換型和事務(wù)型兩種類型。在進行軟件結(jié)構(gòu)設(shè)計時，首先對數(shù)據(jù)流圖進行分析，然后判斷屬于哪一種類型，根據(jù)不同的數(shù)據(jù)流類型，通過一系列映射，把數(shù)據(jù)流程轉(zhuǎn)換為軟件結(jié)構(gòu)圖。§5.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換一、變換型數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的映射

變換型數(shù)據(jù)處理問題的工作機理是變換中心將從輸入端接收的數(shù)據(jù)加工處理后，發(fā)送給輸出端輸出結(jié)果，如圖所示。

當數(shù)據(jù)流這種特征時，就稱為變換型數(shù)據(jù)流。

變換型數(shù)據(jù)流DFD可明顯地分為三大部分：邏輯輸入、變換中心（主加工）、邏輯輸出。§5.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換變換型數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的映射機制：首先，設(shè)計軟件結(jié)構(gòu)的頂層和第１層。

設(shè)計一個主模塊，并用系統(tǒng)的名字為它命名，作為系統(tǒng)的頂層。第１層為每一個邏輯輸入設(shè)計一個輸入模塊，功能是為主模塊提供數(shù)據(jù)；為每一個邏輯輸出設(shè)計一個輸出模塊，功能是將主模塊提供的數(shù)據(jù)輸出；為中心變換設(shè)計一個變換模塊，功能是將邏輯輸入轉(zhuǎn)換成邏輯輸出。主模塊控制和協(xié)調(diào)第１層的輸入模塊、變換模塊和輸出模塊的工作?！?.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換然后，設(shè)計軟件結(jié)構(gòu)的下層結(jié)構(gòu)。每個邏輯輸入模塊有２個下屬模塊：一個接收數(shù)據(jù)；另一個把數(shù)據(jù)變換成上級模塊所需要的數(shù)據(jù)格式。而接收數(shù)據(jù)模塊同時又是輸入模塊，又要重復上述工作。如此循環(huán)下去，直到輸入模塊已經(jīng)涉及到物理輸入端為止。同樣，每個邏輯輸出模塊有２個下屬模塊：一個是將上級模塊提供的數(shù)據(jù)變換成輸出的形式；另一個是將它們輸出。對于每一個邏輯輸出，在數(shù)據(jù)流圖上向物理輸出端方向移動，遇到物理輸出為止。設(shè)計中心變換模塊的下層模塊沒有通用的方法，一般應(yīng)參照數(shù)據(jù)流圖的中心變換部分和功能分解的原則來考慮如何對中心變換模塊進行分解。§5.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換二、事務(wù)型數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的映射事務(wù)型數(shù)據(jù)處理問題的工作機理是接受一項事務(wù)，根據(jù)事務(wù)處理的特點和性質(zhì)，由事務(wù)中心選擇分派一個適當?shù)奶幚韱卧缓蠼o出結(jié)果。

通常事務(wù)中心位于幾條處理路徑的起點，從數(shù)據(jù)流圖上很容易標識出來，因為事務(wù)處理中心一般會有“發(fā)射中心”的特征，所以各式各樣活動流都以事務(wù)中心為起點呈輻射狀流出，如圖所示?！?.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換

事務(wù)中心主要完成下述任務(wù)：接收輸入數(shù)據(jù)（輸入數(shù)據(jù)又稱為事務(wù)）；分析每個事務(wù)以確定它的類型；根據(jù)事務(wù)類型選取一條活動通路。

通常，事務(wù)中心前面的部分叫做接收路徑，發(fā)射中心后面各條發(fā)散路徑叫做事務(wù)處理路徑。對于每條處理路徑來講，還應(yīng)該確定它們自己的流特征。

§5.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換事務(wù)型數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的映射機制如下：首先，設(shè)計軟件結(jié)構(gòu)的頂層和第１層。軟件結(jié)構(gòu)圖的頂層是系統(tǒng)的事務(wù)控制模塊。第１層是由事務(wù)流輸入分支和事務(wù)分類處理分支映射得到的程序結(jié)構(gòu)。也就是說，第１層通常是由兩部分組成：取得事務(wù)和處理事務(wù)?！?.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換然后，設(shè)計軟件結(jié)構(gòu)的下層結(jié)構(gòu)。設(shè)計事務(wù)流輸入分支的方法與變換分析中輸入流的設(shè)計方法類似，從事務(wù)中心開始，沿輸入路徑向物理輸入端移動。

每個接收數(shù)據(jù)模塊的功能是向調(diào)用它的上級模塊提供數(shù)據(jù)，它需要有兩個下屬模塊：一個接收數(shù)據(jù)；另一個把這些數(shù)據(jù)變換成它的上級模塊所需要的數(shù)據(jù)格式。接收數(shù)據(jù)模塊同時又是輸入模塊，也要重復上述工作。如此循環(huán)下去，直到輸入模塊已經(jīng)涉及到物理輸入端為止。§5.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換事務(wù)處理分支結(jié)構(gòu)映射成一個分類控制模塊，它控制下層的處理模塊。對每個事務(wù)建立一個事務(wù)處理模塊。

如果發(fā)現(xiàn)在系統(tǒng)中有類似的事務(wù)，就可以把這些類似的事務(wù)組織成一個公共事務(wù)處理模塊。但是，如果組合后的模塊是低內(nèi)聚的，則應(yīng)該重新考慮組合問題。

事務(wù)中心模塊按照所接受的事務(wù)的類型，選擇某一個事務(wù)處理模塊執(zhí)行。每個事務(wù)處理模塊可能要調(diào)用若干個操作模塊，而操作模塊又可能調(diào)用若干個細節(jié)模塊。不同的事務(wù)處理模塊可以共享一些操作模塊。不同的操作模塊又可以共享一些細節(jié)模塊?！?.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換三、變換－事務(wù)混合型數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的映射

一般來講，一個稍微復雜一些的項目就不可能是單一的變換型，也不可能是單一的事務(wù)型，通常是變換型數(shù)據(jù)流和事務(wù)型數(shù)據(jù)流的混合體。在具體的應(yīng)用中一般以變換型為主，事務(wù)型為輔的方式進行軟件結(jié)構(gòu)設(shè)計?！?.2.1從數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換下面給出一組數(shù)據(jù)流圖轉(zhuǎn)換為軟件結(jié)構(gòu)圖的示例。圖5-22是工資管理系統(tǒng)的數(shù)據(jù)流圖和“工資管理”處理框的展開示意圖?！?.2.2工資管理系統(tǒng)數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換示例本系統(tǒng)中的“工資處理”子系統(tǒng)屬于變換型結(jié)構(gòu)。變換結(jié)構(gòu)是一種線性結(jié)構(gòu)。它可以明顯地分成邏輯輸入、主加工和邏輯輸出。變換分析過程可以分為三步：

（1）

找出系統(tǒng)的邏輯輸入、主加工和邏輯輸出?！肮べY處理”子系統(tǒng)的邏輯輸入是“考勤記錄”和“固定工資”，主加工是“計算工資”，邏輯輸出是“打印工資表”。

（2）設(shè)計頂層模塊和第一層模塊。系統(tǒng)的主加工就是系統(tǒng)的頂層模塊，其功能就是整個系統(tǒng)的功能“計算工資”。第一層模塊按照輸入、變換、輸出等分支來處理，并起一個合適的模塊名。第一層模塊與頂層模塊傳遞的數(shù)據(jù)應(yīng)該同數(shù)據(jù)流圖相對應(yīng)。

（3)設(shè)計中、下層模塊。對輸入、變換、輸出模塊逐個分解，便可以得到初始結(jié)構(gòu)圖。

§5.2.2工資管理系統(tǒng)數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換示例§5.2.2工資管理系統(tǒng)數(shù)據(jù)流圖到軟件結(jié)構(gòu)圖的轉(zhuǎn)換示例§5.2.3.從需求模型到軟件架構(gòu)當軟件需求相當復雜時，非功能性需求在整個系統(tǒng)中就會占據(jù)重要位置；當系統(tǒng)生命周期比較長時，系統(tǒng)就會有擴展性要求；當系統(tǒng)基于構(gòu)件或集成的需要，或者基于業(yè)務(wù)流程再造的需要時；綜合上述考慮，進行軟件總體架構(gòu)設(shè)計。

§5.2.3.從需求模型到軟件架構(gòu)一般地，軟件系統(tǒng)有如下需求：業(yè)務(wù)需求描述問題域中的業(yè)務(wù)目標和范圍；用戶需求表達問題域中的用戶期望和結(jié)果；系統(tǒng)需求指出待構(gòu)建系統(tǒng)必須完成的全部任務(wù)和功能集合，定義了系統(tǒng)做什么；軟件需求是指系統(tǒng)需求分配給軟件的部分；功能性需求包括軟件系統(tǒng)為滿足業(yè)務(wù)需求和用戶需求所必須包括的明確功能；而非功能性需求則指的是關(guān)于軟件系統(tǒng)屬性、特性、特征的描述，同時也是對解決方案的限制。§5.2.3.從需求模型到軟件架構(gòu)軟件需求工程中關(guān)注的質(zhì)量屬性主要包括：性能（如：吞吐量、響應(yīng)能力、并發(fā)能力）持續(xù)可用性（與平均無故障時間有關(guān)，操作有效性、操作效率）可擴展性（如：業(yè)務(wù)增加、組織擴張）安全性（如：數(shù)據(jù)訪問安全、系統(tǒng)作業(yè)安全）互操作性/可集成性、可維護性、可移植性（如：硬件、OS、數(shù)據(jù)庫）可靠性（如：平均無故障時間、算法精度、操作響應(yīng)能力）可重用性（如：通用功能提取、產(chǎn)品構(gòu)件化、框架）健壯性/魯棒性（如：容錯能力）易用性（如：人機交互復雜性、操作導航能力）可測試性（如：設(shè)計可評估性、代碼執(zhí)行測試的效果）§5.2.3.從需求模型到軟件架構(gòu)軟件需求工程中關(guān)注的約束性需求是項目顯式或隱式的對系統(tǒng)的限制，包括投資成本、開發(fā)周期、技術(shù)要求、人員素質(zhì)、項目或產(chǎn)品的技術(shù)指標等。

約束性需求是系統(tǒng)應(yīng)遵循的規(guī)則，如：財務(wù)軟件的國際會計準則、電信產(chǎn)品的國家技術(shù)標準、數(shù)控或工控系統(tǒng)的誤差要求等。軟件架構(gòu)設(shè)計時，除了滿足系統(tǒng)功能的基本要求外，更多的是需要綜合考慮軟件的質(zhì)量屬性和約束性需求?！?.2.4軟件設(shè)計模式簡單地說，設(shè)計模式是對軟件設(shè)計問題的可重用的解決方案。

重用設(shè)計比重用代碼更有意義，可充分利用已有的軟件開發(fā)經(jīng)驗，為設(shè)計提供共同的詞匯，方便交流和書寫開發(fā)文檔，降低錯誤的可能性，還節(jié)省時間。面向?qū)ο笤O(shè)計，就是在系統(tǒng)設(shè)計的過程中，通過把系統(tǒng)分成相對獨立但又相互聯(lián)系的對象組合的一種設(shè)計方法。對象具有屬性和行為，對象間通過消息進行交互（協(xié)作）。面向?qū)ο蠓治龊驮O(shè)計一般有以下幾個關(guān)鍵步驟：

1.發(fā)現(xiàn)對象。找出系統(tǒng)應(yīng)該有哪些對象構(gòu)成。

2.建模對象的屬性。對象具有哪些屬性。

3.建模對象的行為。對象具有哪些行為，或者說對象需要做什么，它的職責是什么。

4.建模對象的關(guān)系。對象與對象之間的關(guān)系是什么，怎樣進行交互、協(xié)作等等。面向?qū)ο笤O(shè)計模式可以分為兩類：GRASP（GeneralResponsibilityAssignmentSoftwarePatterns，通用職責分配軟件模式）和GoF（GangofFour,“四人幫”設(shè)計模式）。§5.2.4軟件設(shè)計模式GRASP是CraigLarman在《ApplyingUMLandPatterns》一書中首先提出的，作者稱其為設(shè)計模式，其實，稱其為面向?qū)ο蟮脑O(shè)計原則更合適一些。

與GoF等設(shè)計模式不同的是，GoF等設(shè)計模式是針對特定問題而提出的解決方法，而GRASP則是站在面向?qū)ο笤O(shè)計的角度，告訴我們怎么樣設(shè)計問題空間中的類與它們的行為責任，以及明確類之間的相互關(guān)系等等，用來解決面向?qū)ο笤O(shè)計的一些問題。GRASP可以說是GoF等設(shè)計模式的基礎(chǔ)。GRASP的核心思想是“職責分配”，GRASP的主要特征是對象職責分配的基本原則，主要應(yīng)用在分析和建模上。GRASP沒有為編程開發(fā)人員提供具體的模板形式的程序代碼示例，只是提出將現(xiàn)實世界的業(yè)務(wù)功能抽象成應(yīng)用系統(tǒng)的具體軟件對象的過程中，應(yīng)用系統(tǒng)的開發(fā)人員應(yīng)當遵循的一些基本原則。§5.2.4軟件設(shè)計模式也就是說，如何把現(xiàn)實世界的業(yè)務(wù)功能抽象成對象，如何決定一個系統(tǒng)有多少對象，每個對象都包括什么職責，GRASP模式給出了最基本的指導原則。

GRASP模式的責任是類間的一種合約或義務(wù)，也可以理解成一個業(yè)務(wù)功能，分為知道責任（表示知道什么）和行為責任（表示做什么），包括行為、數(shù)據(jù)、對象、關(guān)系的創(chuàng)建和控制等。

責任不是類的方法，類的方法用于實現(xiàn)行為責任，而責任更可以理解成是系統(tǒng)應(yīng)提供的一個業(yè)務(wù)功能。責任的分配可使用順序圖或協(xié)作圖來表達，面向?qū)ο蟮脑O(shè)計過程就是將責任分配給對象的過程?！?.2.4軟件設(shè)計模式§5.2.5GRASP模式在面向?qū)ο蟮脑O(shè)計過程中，經(jīng)常會出現(xiàn)如下一些問題。問題1：找出對象的行為（職責）之后，怎么樣分配這些行為呢？也就是說怎么確認“行為”屬于哪個對象呢？問題2：如果2個對象之間有協(xié)作關(guān)系，他們之間最好通過什么樣的方式協(xié)作呢？問題3：已經(jīng)被抽象出來的對象，如何面對將來可能發(fā)生的變化呢？GRASP提出9個基本模式，用于解決以上設(shè)計過程中遇到的各種問題。序號模式名稱特點備注1信息專家（InformationExpert）類的職責分配問題基本模式2創(chuàng)建者（Creator）類的實例的創(chuàng)建職責問題基本模式3高內(nèi)聚（HighCohesion）降低類的復雜程度，簡化控制基本模式4低耦合（LowCoupling）降低類之間的關(guān)聯(lián)程度，適應(yīng)可變性基本模式5控制者(Controller)解決事件處理職責問題基本模式6多態(tài)性（Polymorphism）把基于類型的可變行為的定義職責分配給行為發(fā)生的類擴展模式7純虛構(gòu)（PureFabrication）把非問題領(lǐng)域中的職責分配給人工定義的類擴展模式8間接性（Indirection）解決類的關(guān)聯(lián)問題擴展模式9變化預(yù)防（ProtectedVariations）設(shè)計穩(wěn)定的接口來應(yīng)對將來可能發(fā)生的變化或其它不安定的因素擴展模式一、信息專家模式問題描述：信息專家模式是GRASP模式中解決類的職責分配問題的最基本的模式，主要應(yīng)用于“當我們發(fā)現(xiàn)了系統(tǒng)對象和職責之后，職責的分配原則（職責將分配給哪個對象執(zhí)行）是什么？”的環(huán)境中。解決方案：職責的執(zhí)行需要某些信息，把職責分配給該信息的擁有者。換句話說，某項職責的執(zhí)行需要某些資源，只有擁有這些資源的對象才有資格執(zhí)行職責。一般地，如果滿足面向?qū)ο笤O(shè)計中的封裝性的設(shè)計，都會滿足信息專家模式，因為信息專家是對類的屬性（信息），以及對類的屬性的操作的封裝，它符合對象封裝性的概念?！?.2.5GRASP模式好處：-信息的擁有者類同時就是信息的操作者類，可以減少不必要的類之間的關(guān)聯(lián)。各類的職責單一明確，容易理解。用法舉例：假定“學生成績管理系統(tǒng)”中的用例1要求為：管理員創(chuàng)建題庫（把題條加入題庫）；再細化一下：管理員創(chuàng)建題庫（把題條加入題庫）：如果題庫中已經(jīng)存在所給的題條，則退出，否則加入題條。針對上述用例1，存在3個對象：管理員用戶User，題條SubjectItem，題庫SubjectLibrary；2個職責：判斷（新加入的題條是否與題庫某題條相等），加入（題條的加入）；§5.2.5GRASP模式這2個職責究竟應(yīng)該由哪個對象執(zhí)行？我們使用信息專家模式來分析：首先，判斷2個題條是否相等，只要判斷題條的ID屬性（關(guān)鍵屬性）是否相等就可以了。題條的ID是屬于題條的，所以對它的操作應(yīng)該放在題條SubjectItem里。其次，題條的加入需要操作的數(shù)據(jù)有兩部分，一部分是新加入的題條本身，另一部分是題庫（加入到題庫），題條是題庫一部分，所以題條的加入應(yīng)放題庫SubjectLibrary里完成。如果把以上2個職責放在第三方類中，無疑增加了它們與第三方類之間的耦合關(guān)系?！?.2.5GRASP模式二、創(chuàng)建者模式問題陳述：創(chuàng)建者模式是GRASP模式中解決類的實例的創(chuàng)建職責問題的模式。解決方案：如果出現(xiàn)以下條件之一為真的情況，類A的實例的創(chuàng)建職責就分配給類B。1．B包含A2．B聚集A3．B記錄A4．B頻繁使用A5．B有A初始化數(shù)據(jù)§5.2.5GRASP模式創(chuàng)建者模式提倡類的實例（對象）創(chuàng)建職責由聚集或包含該對象的對象創(chuàng)建。注：創(chuàng)建者模式只是一個原則，如果類A，B之間沒有包含或聚集關(guān)系，應(yīng)該先考案是否有“B記錄A”，或者“B有A初始化數(shù)據(jù)”的關(guān)系，然后是“B頻繁使用A”的關(guān)系。另外，作為代替方案，一般的采用工廠（Factory）創(chuàng)建方案。如果不遵循創(chuàng)建者模式，把類的實例的創(chuàng)建職責交給無關(guān)的類，類之間的關(guān)系會變得復雜化，降低系統(tǒng)的可維護性和可擴展性。一般來說，應(yīng)用創(chuàng)建者模式，可以從上到下設(shè)計好類之間的包含或聚集關(guān)系階層圖，讓每個類負責創(chuàng)建自己包含的類的實例?！?.2.5GRASP模式好處:-整個結(jié)構(gòu)清晰易懂-有利于類或構(gòu)件的重用-防止職責的分散-降低耦合性用法舉例：有一個用戶窗口MainWindow，包含Menu，ToolBar，Dialog等，Dialog上布置有Textbox，Button等元素。因為MyMenu，MyToolBar，MyDialog由MainWindow所包含，MyTextbox，MyButton被MyDialog包含，MainWindow由Main類調(diào)用?！?.2.5GRASP模式根據(jù)創(chuàng)建者模式所提倡的方法，它們的實例的創(chuàng)建職責的分配應(yīng)該是：MainWindow的實例由Main創(chuàng)建；MyMenu，MyToolbar，MyDialog的實例由MainWindow創(chuàng)建；MyTextbox，MyButton的實例由MyDialog創(chuàng)建。

反過來，如果MyMenu，MyToolBar，MyDialog等實例的創(chuàng)建都放在Main類里，那么Main就跟它們產(chǎn)生一種“關(guān)聯(lián)”關(guān)系，如果

MyMenu，MyToolBar，MyDialog等發(fā)生修改，Main也不得不跟著一起修改，也就是說大大增強了Main類跟它們之間的耦合關(guān)系；而

Main類本身，也聚集了多余的實例創(chuàng)建功能，降低了Main類的聚合性?！?.2.5GRASP模式三、高內(nèi)聚模式問題陳述：怎么做才能降低類的復雜程度，簡化控制？高內(nèi)聚模式是GRASP模式中為降低類的復雜程度，簡化控制而提出的面向?qū)ο笤O(shè)計的原則性模式。高內(nèi)聚與低耦合模式是GRASP其他模式的根本。解決方案：緊密相關(guān)的功能（職責）應(yīng)該分配給同一個類。所謂內(nèi)聚，是指單個物體（類）內(nèi)部的功能聚集度。比如，只包含有相互關(guān)聯(lián)的功能的類，具有高內(nèi)聚性，同時，它的外部表現(xiàn)（作用，意圖）也就明顯一方面很難理解它的作用和意圖，另一方面，一旦需求變化，擴展性就差。好處：-聚集相關(guān)功能，結(jié)構(gòu)清晰，容易理解-只聚集相關(guān)功能，使得類的職責單一明確，從而降低類的復雜程度，使用簡單§5.2.5GRASP模式四、低耦合模式問題陳述：怎么做才能降低類之間關(guān)聯(lián)程度，能適應(yīng)需求的變化呢？低耦合模式是GRASP模式中為降低類之間的關(guān)聯(lián)程度，適應(yīng)可變性而提出的面向?qū)ο笤O(shè)計的原則性模式。解決方案：為類分配職責時，應(yīng)該盡量降低類之間的關(guān)聯(lián)關(guān)系（耦合性）。亦即，應(yīng)該以降低類之間的耦合關(guān)系作為職責分配的原則。所謂耦合，是指多個物體（類）之間的物理或者意思上的關(guān)聯(lián)程度。在面向?qū)ο蠓椒ㄖ?，類是最基本的元素，耦合主要指不同類之間相互關(guān)聯(lián)的緊密程度。面向?qū)ο罄锏年P(guān)聯(lián)，主要指一個類對另一個類的調(diào)用，聚合（包含），參數(shù)傳遞等關(guān)系。比如，所謂2個關(guān)聯(lián)得非常緊密的類（高耦合），是指其中一個類發(fā)生變化（修改）時，另一個類也不得不跟著發(fā)生變化（修改）?！?.2.5GRASP模式面向?qū)ο笤O(shè)計要求類之間滿足“低耦合”原則，它是衡量一個設(shè)計是否優(yōu)良的一個重要標準，因為“低耦合”有助于使得系統(tǒng)中某一部分的變化對其它部分的影響降到最低程度。好處:-獨立性，有利于重用。-適應(yīng)需求變化，一旦發(fā)生變化時，可以把影響縮小到最小范圍。內(nèi)聚與耦合的辯證關(guān)系高內(nèi)聚要求把緊密關(guān)聯(lián)的功能（職責）聚集在同一個類中，防止功能的擴散和類的無謂增加，從而減少類之間的關(guān)聯(lián)，降低類之間的發(fā)生耦合的機率。高內(nèi)聚要求把不相關(guān)的功能分散到不同的類，類增加了，勢必造成相互關(guān)聯(lián)類的增加，從而增大類之間發(fā)生耦合的機率。高內(nèi)聚與低耦合是GRASP模式的核心概念，是其它GRASP模式的根本。面向?qū)ο笤O(shè)計，應(yīng)該考慮效率，實現(xiàn)難度等因素，同時兼顧高內(nèi)聚與低耦合性。

§5.2.5GRASP模式五、控制器模式問題陳述：在用戶接口層(UI)之外，應(yīng)該由哪個類來處理（控制）系統(tǒng)操作（事件）呢？或者說，當觸發(fā)一個系統(tǒng)事件時，應(yīng)該把對事件的處理職責分配給UI層之外的哪個層呢？控制器模式是GRASP模式中解決事件處理職責問題的模式。解決方案:把系統(tǒng)事件的處理職責分配給控制器類。擔當控制器類角色的候補類可能為：-系統(tǒng)全體，設(shè)備，子系統(tǒng)等的表現(xiàn)類（FacadeController）-系統(tǒng)事件發(fā)生的用例的控制類，通常被命名為Handler，Coordinator，Session等（用例或Session的控制器）。整個系統(tǒng)事件都使用同一個控制器?？刂破髂Ｊ较喈斢谥腗VC設(shè)計模式的C（Controller）部分，提倡用一個專門的類來處理所有的系統(tǒng)事件?！?.2.5GRASP模式好處:應(yīng)用控制器模式的系統(tǒng)，對系統(tǒng)事件進行集中處理，所以：-防止同類職責的分散。滿足高內(nèi)聚，低耦合原則。-有利于共通處理（前處理，后處理等）。變化的高適應(yīng)能力。能夠把變化的修改范圍控制在最小范圍（控制器）之內(nèi)。用法舉例：MVC模式MVC模式Model-View-Controller頭字母的縮寫，中文翻譯為“模型-視圖-控制器”模式（或者模型）。該模式把一個GUI應(yīng)用劃分為業(yè)務(wù)邏輯處理（M），畫面表示（V），控制（C）三部分，并以此為基礎(chǔ)進行設(shè)計和開發(fā)?！?.2.5GRASP模式MVC的構(gòu)成要素包括Model，View，Controller三部分。Model模型部分主要用來負責業(yè)務(wù)邏輯的處理，數(shù)據(jù)的保持。Model是MVC模式的核心部分，它也是一個應(yīng)用需要實現(xiàn)的最主要的部分：進行業(yè)務(wù)邏輯的處理。View視圖,負責數(shù)據(jù)的輸出，畫面的表示。Controller控制器。負責接收從視圖發(fā)送過來的數(shù)據(jù)，同時控制Model與View部分?！?.2.5GRASP模式MVC模式輸入輸出流程圖參見圖：1.Controller接收用戶輸入2.Controller調(diào)用Model進行業(yè)務(wù)邏輯處理（控制）3.Controller通知/調(diào)用View進行畫面描畫處理（控制）4.View根據(jù)需要適當參照Model的值5.View進行畫面描畫處理

使用MVC模式，分離模型、視圖與控制器，使得這三部分功能相對獨立，一方面可以讓系統(tǒng)的設(shè)計開發(fā)工作分工明確，方便開發(fā)人員的互相合作；另一方面，按照

MVC模式劃分的系統(tǒng)的各部分功能保持獨立，有利于構(gòu)件復用?！?.2.5GRASP模式六、多態(tài)性模式問題陳述：根據(jù)類型（類）的不同而發(fā)生變化的行為的定義職責，應(yīng)該分配給誰？多態(tài)性模式是GRASP擴展模式的一種，它通過多態(tài)操作把基于類型的可變行為的定義職責分配給行為發(fā)生的類。問題比較抽象難懂，我們通過舉例來解釋一下。比如物體的移動行為，不同的物體有不同的移動方法，比方說汽車與人的移動方法不一樣。在面向?qū)ο笤O(shè)計中，怎么樣分配此類行為的定義職責呢？或者說，此類行為應(yīng)該在哪定義怎么定義呢？§5.2.5GRASP模式解決方案:多態(tài)性模式提倡通過多態(tài)操作把基于類型的可變行為的定義職責分配給行為發(fā)生的類。多態(tài)性是面向?qū)ο蟮闹匾拍钪弧Ｋ^多態(tài)性，簡單地說，就是具有同一接口的不同對象對相同的消息具有不同的行為。或者說同一消息作用于不同的對象，而產(chǎn)生不同的結(jié)果。傳統(tǒng)的設(shè)計方法，當類型發(fā)生變化時，利用條件判斷語句對類型進行判斷，然后執(zhí)行不同的行為。多態(tài)性模式把各變化的“行為”定義職責分別分配給具有相同操作行為界面的通用接口的實現(xiàn)子類，利用多態(tài)性適應(yīng)行為的可變性。好處：-避免重復代碼-避免重復的分歧條件-易擴展。只要實現(xiàn)了統(tǒng)一的通用接口，便可實現(xiàn)行為的擴展§5.2.5GRASP模式用法舉例：物體的移動行為，應(yīng)用多態(tài)性設(shè)計模式設(shè)計的類圖如圖所示：這樣的話，如果我們需要擴展“移動”行為，只需簡單地創(chuàng)建一個實現(xiàn)IRunner接口的類。其他應(yīng)用多態(tài)性模式的例子還有如：GoF設(shè)計模式之命令模式和策略模式等?！?.2.5GRASP模式七、純虛構(gòu)模式問題陳述：非問題領(lǐng)域中的職責應(yīng)該分配給誰？或者說，按照信息專家等模式分配職責時，存在某些不恰當?shù)穆氊煏r，應(yīng)該怎么做？所謂不恰當?shù)穆氊?，是指難以分配的職責：在保證高內(nèi)聚，低耦合的條件下，某些職責難以分配給現(xiàn)存的任何問題領(lǐng)域里的類。純虛構(gòu)模式是GRASP擴展模式之一，它把非問題領(lǐng)域中的職責分配給人工定義的類。解決方案：純虛構(gòu)模式提倡把那些非問題領(lǐng)域的職責分配給人工生成的或者容易實現(xiàn)此類職責的概念類?！?.2.5GRASP模式DomainClass的概念我們設(shè)計對象的時候應(yīng)該盡量保持與現(xiàn)實世界里的對象一致。這種與現(xiàn)實世界里的對象保持一致的從業(yè)務(wù)分析中抽象出來的類叫做“DomainClass”。它相當于上述問題領(lǐng)域里的類。比如一個簡單的用例：用戶注冊。用戶就是一個“DomainClass”，它是現(xiàn)實世界里的業(yè)務(wù)對象。相當于這里的“問題領(lǐng)域里的類”。用戶注冊需要操作數(shù)據(jù)庫，【數(shù)據(jù)庫操作】是系統(tǒng)功能實現(xiàn)的一個必需功能，它不是現(xiàn)實世界里存在的業(yè)務(wù)對象，它是一個非DomainClass。如果把【數(shù)據(jù)庫操作】看作一個行為職責，它就相當于這里所說的“非問題領(lǐng)域里的職責”。一般來說，DomainClass與非DomainClass的功能如果聚集在一個類里，就破壞了“高內(nèi)聚”原則。§5.2.5GRASP模式好處：-高內(nèi)聚。不必分配問題領(lǐng)域以外的職責給各Domain類，從而保證各Domain類內(nèi)部功能上的高度聚集性。-低耦合。問題領(lǐng)域以外的職責被分配給第三方非Domain類，一方面可以降低各Domain類之間的關(guān)聯(lián)程度，另一方面可以比較漂亮地整合系統(tǒng)的各方面的職責。-重用性。各Domain類由于功能上的聚集與關(guān)聯(lián)度的降低，可以更容易地得到重用。用法舉例：以上述“用戶注冊”的用例為例，對于問題領(lǐng)域里的類“用戶（User）”，如果把“數(shù)據(jù)庫操作的職責”分配給“用戶（User）”，那么User類的內(nèi)聚性大大降低。應(yīng)用純虛構(gòu)模式，應(yīng)該人工定義一個數(shù)據(jù)庫管理的概念類UserDbMgr，把數(shù)據(jù)庫操作的功能分配給它完成。§5.2.5GRASP模式八、間接性模式問題陳述：為了避免類之間的直接關(guān)聯(lián)，應(yīng)該給什么樣的類分配“關(guān)聯(lián)”責任？間接性模式是GRASP模式中解決類的關(guān)聯(lián)問題的模式。解決方案:當多個類之間存在復雜的消息交互（關(guān)聯(lián)）時，間接性模式提倡類之間不直接進行消息交互處理（非直接），而是導入第三方類，把責任（多個類之間的關(guān)聯(lián)責任）分配給第三方類，降低類之間的耦合程度?！?.2.5GRASP模式好處:-高內(nèi)聚。通過把“關(guān)聯(lián)”的功能分散到第三方類，原來的類可以更加關(guān)注自身功能的實現(xiàn)。-低耦合。原本關(guān)聯(lián)類之間不直接關(guān)聯(lián)，降低類之間的耦合性。高重用性。第三方類對“關(guān)聯(lián)”功能的集中處理，與原來的類對自身功能的專注，有利于類的重用。用法舉例：應(yīng)用間接性模式的一個最好范例是GoF模式的中介者模式。

§5.2.5GRASP模式九、變化預(yù)防模式問題陳述：對存在于系統(tǒng)、子系統(tǒng)或?qū)ο蟮仍刂械母鞣N變化或不安定的因素，為了不產(chǎn)生對其他元素的不利影響，在它們中間應(yīng)該怎么樣分配職責？變化預(yù)防模式是GRASP擴展模式之一，它設(shè)計穩(wěn)定的接口來應(yīng)對將來可能發(fā)生的變化或其它不安定的因素。解決方案：該模式提倡在可預(yù)測的變化或不安定因素的周圍，用穩(wěn)定的接口來承擔職責。在面向?qū)ο笤O(shè)計中，面向接口編程便符合變化預(yù)防模式的概念。有人把變化預(yù)防模式稱為Don'tTalktoStrangers（別跟陌生人說話），因為這兩者的考慮方法一致?！?.2.5GRASP模式Don'tTalktoStrangers別名Demeter法則：只跟直接依賴的對象通信，也就是說2個對象之間，能不關(guān)聯(lián)的就盡量不要關(guān)聯(lián)。所謂直接依賴的對象，例如有一個對象A，直接依賴的對象有：1，

A對象本身2，

A的屬性成員對象3，通過參數(shù)傳送給A的對象（A的方法里參數(shù)）4，

A的方法內(nèi)部生成的對象好處：-提高系統(tǒng)對變化的應(yīng)對能力。一旦系統(tǒng)的可預(yù)見的不安定因素發(fā)生變化（比如追加功能等），只需要生成一個已有的穩(wěn)定接口的實現(xiàn)類就可以了，無需修改原來的類。-高內(nèi)聚。具體的功能在各子類中實現(xiàn)，各類的內(nèi)部功能具有高度聚集性。-低耦合。用戶類只跟穩(wěn)定接口通信，減少了跟其它陌生對象的關(guān)聯(lián)的機會，降低了類之間的耦合性?！?.2.5GRASP模式應(yīng)用舉例：例：把一段字符串保存到文件，打印機等輸出設(shè)備。這是一個可變的或者說存在不安定因素的功能需求，因為輸出設(shè)備除了文件，打印機之外，還可能有數(shù)據(jù)庫，屏幕終端，網(wǎng)絡(luò)輸出流等。應(yīng)用變化預(yù)防模式，我們?yōu)槠涠x一個能實現(xiàn)輸出功能的穩(wěn)定接口IOutputer，而具體的功能在具體的子類中實現(xiàn)，比如打印機輸出類

PrinterOutputer，數(shù)據(jù)庫輸出類DatabaseOutputer，文件輸出類FileOutputer等。使用此“輸出功能”的用戶只要知道接口就行了?！?.2.5GRASP模式《DesignPatterns:ElementsofReusableObject-OrientedSoftware》（即后述《設(shè)計模式》一書）是由

ErichGamma、RichardHelm、RalphJohnson和

JohnVlissides合著（Addison-Wesley，1995）。這幾位作者常被稱為"四人組（GangofFour）"，而這本書也就被稱為"四人組（或

GoF）"書。根據(jù)模式的目標，GOF設(shè)計模式將它們分成創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式。創(chuàng)建型模式處理的是對象的創(chuàng)建過程，結(jié)構(gòu)型模式處理的是對象/類的組合，行為型模式處理類和對象間的交互方式和任務(wù)分布。根據(jù)模式主要的應(yīng)用對象，又可以分為主要應(yīng)用于類的和主要應(yīng)用于對象的?！?.2.6GOF設(shè)計模式1．創(chuàng)建型模式(creationalpattern)抽象了創(chuàng)建對象的過程，使用系統(tǒng)不依賴于系統(tǒng)中對象是如何創(chuàng)建、組合和表示的。

創(chuàng)建型模式包括：工廠方法(FactoryMethod)、抽象工廠(AbstractFactory)、生成器(Builder)、原型(Prototype)、單件(Singleton)?！?.2.6GOF設(shè)計模式2．結(jié)構(gòu)型模式(structuralpattern)主要描述如何組合類和對象以獲得更大的結(jié)構(gòu)。結(jié)構(gòu)型模式包括：適配器(Adapter)、橋接(Bridge)、組成（Composite)、裝飾(Decorator)、刻面(Facade)、享元(Flyweight)、代理(Proxy)。3．行為型模式(behavioralpattern)主要描述算法和對象間職責的分配，主要考慮對象（或類）之間的通信模式。行為型模式包括：職責鏈(ChainofResponsibility)、命令(Command)、解釋器(Interpreter)、迭代器(Iterator)、中介者(Mediator)、備忘錄(Memento)、觀察者(Observer)、狀態(tài)(State)、策略(Strategy)、模板方法(Templatemethod)、訪問者(Visitor)。

由上表可知，Adapter這個設(shè)計模式既可以作用于類，也可以作用于對象。實際上，Adapter設(shè)計模式有2種使用方式，一種是通過類之間的多重繼承（類Adapter設(shè)計模式），另一種是通過組合的形式（對象Adapter設(shè)計模式）?！?.2.6GOF設(shè)計模式1．創(chuàng)建型模式的簡要說明

FactoryMethod：定義一個創(chuàng)建對象的接口，但由子類決定需要實例化哪一個類；可改變的方面是：實例化子類的對象。

AbstractFactory：提供創(chuàng)建相關(guān)的或相互依賴的一組對象的接口，使我們不需要指定類；可改變的方面是：產(chǎn)品對象族。

Builder：將一個復雜對象的結(jié)構(gòu)與它的描述隔離，使我們使用相同的結(jié)構(gòu)就可以得到不同的描述；可改變的方面是：如何建立一種組合對象。

Prototype：使用一個原型來限制要創(chuàng)建的類的類型，通過復制這個原型得到新的類；可改變的方面是：實例化類的對象。

Singleton：保證一個類只有一個實例，并提供一個全局性的訪問點；可改變的方面是：類的單個實例。

§5.2.6GOF設(shè)計模式2．結(jié)構(gòu)型模式的簡要說明

Adapter：將一個類的接口轉(zhuǎn)換成用戶希望得到的另一種接口，它使原本不相容的接口得以協(xié)同工作；可改變的方面是：與對象的接口。

Bridge：將類的抽象概念和它的實現(xiàn)分離，使它們可以相互獨立地變化；可改變的方面是：對象的實現(xiàn)。

Composite：將對象組成樹結(jié)構(gòu)來表示局部和整體的層次關(guān)系，客戶可以統(tǒng)一處理單個對象和對象組合；可改變的方面是：對象的結(jié)構(gòu)和組合。

Decorator：給對象動態(tài)地加入新的職責，它提供了用子類擴展功能的一個靈活的替代；可改變的方面是：無子類對象的責任。

§5.2.6GOF設(shè)計模式

Fa?ade：給一個子系統(tǒng)的所有接口提供一個統(tǒng)一的接口，它定義了更高層的接口，使該子系統(tǒng)更便于使用；可改變的方面是：與子系統(tǒng)的接口。

Flyweight：提供支持大量細粒度對象共享的有效方法；可改變的方面是：對象的存儲代價。

Proxy：給另一個對象提供一個代理或定位符號，以控制對它的訪問；可改變的方面是：如何訪問對象及對象位置?！?.2.6GOF設(shè)計模式3．行為型模式的簡要說明

ChainofResponsibility：通過給多個對象處理請求的機會，減少請求的發(fā)送者與接收者之間的耦合；將接收對象鏈接起來，在鏈中傳遞請求，直到有一個對象處理這個請求；可改變的方面是：可滿足請求的對象。

Command：將一個請求封裝為一個對象，從而將不同的請求對象化并進行排隊或登記，以支持撤消操作；可改變的方面是：何時及如何滿足一個請求。

Interpreter：給定一種語言，給出它的語法的一種描述方法和一個解釋器，該解釋器用這種描述方法解釋語言中的句子；可改變的方面是：語言的語法和解釋。

Iterator：提供一種順序訪問一個聚集對象中元素的方法，而不需要暴露它的低層描述；可改變的方面是：如何訪問、遍歷聚集的元素。

§5.2.6GOF設(shè)計模式Mediator：定義一個對象來封裝一系列對象的交互；它保持對象間避免顯式地互相聯(lián)系，從而消除它們之間的耦合，還可以獨立地改變對象間的交互；可改變的方面是：對象之間如何交互以及哪些對象交互。

Memento：在不破壞封裝的條件下，獲得一個內(nèi)部狀態(tài)并將它外部化，從而可以在以后使對象恢復到這個狀態(tài)；可改變的方面是：何時及哪些私有信息存儲在對象之外。Observer：定義一個對象的一對多的信賴關(guān)系，當一個對象改變狀態(tài)時，所有與它有信賴關(guān)系的對象都得到通知并自動更新；可改變的方面是：信賴于另對象的對象數(shù)量，信賴對象如何保持最新數(shù)據(jù)。State：允許一個對象在內(nèi)部狀態(tài)改變時的行為，對象看起來似乎能改變自己的類；可改變的方面是：對象的狀態(tài)?！?.2.6GOF設(shè)計模式Strategy：定義一族算法，對每一個都進行封裝，使它們互相可交換；它使算法可以獨立于用戶而變化；可改變的方面是：算法。Templatemethod：：定義一個操作的算法骨架，使某些步驟決定于子類；它使子類重定義一個算法的某些步驟，但不改變整個算法的結(jié)構(gòu)；可改變的方面是：算法的步驟。Visitor：描述在一個對象結(jié)構(gòu)中對某些元素需要執(zhí)行的一個操作；它使我們在不改變被操作元素類的條件下定義新操作；可改變的方面是：無須改變其類而可應(yīng)用于對象的操作。§5.2.6GOF設(shè)計模式§5.3系統(tǒng)資源設(shè)計軟件工程領(lǐng)域的發(fā)展包含程序設(shè)計方法的發(fā)展、軟件需求的發(fā)展和軟件環(huán)境的發(fā)展三個方面。

程序設(shè)計方法的發(fā)展由原先以功能分解為主的結(jié)構(gòu)化程序設(shè)計方法逐漸過渡到面向?qū)ο蠓椒ǎ?/p>

軟件需求的發(fā)展則從最初的科學計算發(fā)展到實際生活應(yīng)用，再發(fā)展到管理信息系統(tǒng)應(yīng)用，現(xiàn)在已經(jīng)發(fā)展到各種分布式系統(tǒng)應(yīng)用；

伴隨著程序設(shè)計方法和軟件需求的發(fā)展，軟件環(huán)境的發(fā)展也已經(jīng)從文字界面、單任務(wù)、單線程環(huán)境經(jīng)過圖形界面下多任務(wù)、多線程環(huán)境過度到跨平臺的網(wǎng)絡(luò)（分布式）、多種語言并存的開發(fā)環(huán)境。

因此，在為系統(tǒng)設(shè)計合適的解決方案時，系統(tǒng)設(shè)計人員除了需要考慮系統(tǒng)架構(gòu)外，還需要考慮目標處理環(huán)境和資源。

本節(jié)主要介紹當前開發(fā)平臺中常用的應(yīng)用邏輯結(jié)構(gòu)設(shè)計和系統(tǒng)物理設(shè)計，以及設(shè)計過程所涉及到的構(gòu)件圖和部署圖的描述?！?.3.1系統(tǒng)應(yīng)用邏輯結(jié)構(gòu)設(shè)計在軟件開發(fā)環(huán)境的支持下，軟件開發(fā)框架發(fā)展歷史參見圖所示，目前單機領(lǐng)域軟件系統(tǒng)的開發(fā)已經(jīng)極少，以該發(fā)展歷史圖為指導，系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)設(shè)計可以結(jié)合系統(tǒng)實際情況，選擇客戶/服務(wù)器、瀏覽器/服務(wù)器、分布式應(yīng)用程序架構(gòu)或WebServices框架進行設(shè)計。單機時代客戶/服務(wù)器時代瀏覽器/服務(wù)器時代分布式應(yīng)用程序架構(gòu)時代WebServices時代客戶/服務(wù)器模式是一種分布式計算應(yīng)用，使用一個應(yīng)用程序(客戶)和另一個程序(服務(wù)端)交換數(shù)據(jù)，客戶端和服務(wù)端一般使用同樣的語言來編寫，使用相同的協(xié)議來相互通信，采用點對點的工作方式，服務(wù)器端運行系統(tǒng)軟件，存放集中式數(shù)據(jù)，而客戶端運行應(yīng)用軟件，集中處理業(yè)務(wù)邏輯。該方式采用客戶端開發(fā)，資源獨占方式運行，部署時，工作集中在客戶端，軟件維護比較困難；典型的應(yīng)用系統(tǒng)是各類關(guān)系數(shù)據(jù)庫系統(tǒng)，開發(fā)工具可以選擇微軟公司的Visual系列開發(fā)環(huán)境。瀏覽器/服務(wù)器模式是一種分布式計算應(yīng)用，是客戶/服務(wù)器模式的一種典型應(yīng)用。該模式在服務(wù)器端完成全部計算工作，客戶端使用通用瀏覽器，只用于數(shù)據(jù)的顯示（頁面）。開發(fā)工作量主要集中在服務(wù)器端（頁面描述可以根據(jù)是服務(wù)器解釋還是客戶機解釋而使得工作方式和工作量都有所不同）。部署工作也和主要集中在服務(wù)器端，客戶端只需要常規(guī)的瀏覽器軟件即可進行訪問，客戶端實現(xiàn)了零維護，解決了客戶/服務(wù)器模式中的維護問題，典型應(yīng)用系統(tǒng)是靜態(tài)/動態(tài)網(wǎng)頁發(fā)布系統(tǒng)?！?.3.1系統(tǒng)應(yīng)用邏輯結(jié)構(gòu)設(shè)計分布式應(yīng)用程序架構(gòu)是隨著Internet/Intranet的快速發(fā)展，分布式數(shù)據(jù)存儲管理的需要、多種軟件系統(tǒng)、企業(yè)應(yīng)用集成（EAI）以及電子商務(wù)、電子政務(wù)、電子海關(guān)等應(yīng)用需求而引發(fā)的一種新的模式。該架構(gòu)的基礎(chǔ)是OSI七層模型，即物理、數(shù)據(jù)鏈路、網(wǎng)絡(luò)、傳輸、會話、表示、應(yīng)用層，所采用的協(xié)議是RS232、TCP/IP、IIOP、DCE-RPC等，遠程過程調(diào)用RPC所用的協(xié)議包括Socket、SMTP、FTP、

HTTP、

COM+、CORBA、SOAP等，表現(xiàn)形式有C/S、B/S、DNA多層架構(gòu)等。分布式應(yīng)用程序架構(gòu)的實現(xiàn)有多種，比較典型的實現(xiàn)包括微軟公司的分布式應(yīng)用程序架構(gòu)DNA模型：COM、DCOM、COM+；由OMG提出的公共對象請求代理架構(gòu)CORBA（CommonObjectRequestBrokerArchitecture）；以及由SUN公司提出的JAVAEE架構(gòu)?！?.3.1系統(tǒng)應(yīng)用邏輯結(jié)構(gòu)設(shè)計三種模型的特點特點DNA模型CORBA模型JAVAEE模型優(yōu)點獨立于語言；有較完善的事務(wù)處理及安全機制；獨立于語言；實現(xiàn)了跨平臺；實現(xiàn)了跨平臺；應(yīng)用可以配置到包括Windows平臺在內(nèi)的任何服務(wù)器端環(huán)境中去；缺點過分依賴Windows操作系統(tǒng)，沒有實現(xiàn)跨平臺；技術(shù)復雜，實現(xiàn)困難；各結(jié)點均需安裝ORB；技術(shù)復雜，難于實現(xiàn)；龐大而復雜，并且技術(shù)和標準的更新相對較慢各框架缺陷各不相同；基本概念構(gòu)件類、接口、方法；接口描述：MIDL構(gòu)件類、接口、方法；接口描述：IDLJDBC：訪問關(guān)系型數(shù)據(jù)庫的API；JTA，JTS：Java事務(wù)處理API，Java事務(wù)處理服務(wù)器；Servlet：服務(wù)器端運行的小程序；Applet：客戶端運行的小程序；JSP：Java服務(wù)器頁面；EJB：EnterpriseJavaBean；運行機制注冊表、WindowsSCM、調(diào)用者維護構(gòu)件生存期；可跨空間調(diào)用；ORB、由ORB維護構(gòu)件生存期；可跨空間、跨時間調(diào)用構(gòu)件；只要是基于Java的開發(fā)工具都實現(xiàn)了RMI。開發(fā)工具微軟系列開發(fā)工具；JDeveloper，JBuilder，C＋＋Builder，SunONE，Delphi等；實現(xiàn)J2EE：JBuilder，JDeveloper，SunONE等；§5.3.1系統(tǒng)應(yīng)用邏輯結(jié)構(gòu)設(shè)計WebServices架構(gòu)是分布式應(yīng)用程序架構(gòu)的一種特例。WebServices架構(gòu)涉及到的技術(shù)包括SOAP（簡單對象傳輸協(xié)議）實現(xiàn)對象訪問、WSDL（WebServices描述語言）完成對象界面描述和UDDI（統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議）發(fā)現(xiàn)對象界面，WebServices以SOAP為消息格式，用WSDL描述自身的實現(xiàn)，用UDDI實現(xiàn)自動發(fā)現(xiàn)機制，其對象實現(xiàn)可采用EJB、COM+、

CORBA以及任何可用于對象實現(xiàn)的技術(shù)。WebServices的工作機制參見圖5-36所示：§5.3.1系統(tǒng)應(yīng)用邏輯結(jié)構(gòu)設(shè)計

SOAP（simpleobjectaccessprotocol，簡單對象訪問協(xié)議）支持分布式環(huán)境中的遠程方法調(diào)用、支持富信息和復雜數(shù)據(jù)類型傳輸、支持任意負載的消息處理、獨立于供應(yīng)商和平臺、支持HTTP，F(xiàn)TP和SMTP等多種傳輸機制。

SOAP定義了一個“envelope”對象，使用“envelope”包