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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表示層控制/中介層領(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)通常縮寫為C/S結(jié)構(gòu)，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）

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

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

（3)設(shè)計(jì)中、下層模塊。對(duì)輸入、變換、輸出模塊逐個(gè)分解，便可以得到初始結(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)當(dāng)軟件需求相當(dāng)復(fù)雜時(shí)，非功能性需求在整個(gè)系統(tǒng)中就會(huì)占據(jù)重要位置；當(dāng)系統(tǒng)生命周期比較長(zhǎng)時(shí)，系統(tǒng)就會(huì)有擴(kuò)展性要求；當(dāng)系統(tǒng)基于構(gòu)件或集成的需要，或者基于業(yè)務(wù)流程再造的需要時(shí)；綜合上述考慮，進(jìn)行軟件總體架構(gòu)設(shè)計(jì)。

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

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

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

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

2.建模對(duì)象的屬性。對(duì)象具有哪些屬性。

3.建模對(duì)象的行為。對(duì)象具有哪些行為，或者說(shuō)對(duì)象需要做什么，它的職責(zé)是什么。

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

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

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

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

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

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

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

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

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

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

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

A對(duì)象本身2，

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

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

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

ErichGamma、RichardHelm、RalphJohnson和

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

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

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

由上表可知，Adapter這個(gè)設(shè)計(jì)模式既可以作用于類，也可以作用于對(duì)象。實(shí)際上，Adapter設(shè)計(jì)模式有2種使用方式，一種是通過(guò)類之間的多重繼承（類Adapter設(shè)計(jì)模式），另一種是通過(guò)組合的形式（對(duì)象Adapter設(shè)計(jì)模式）。§5.2.6GOF設(shè)計(jì)模式1．創(chuàng)建型模式的簡(jiǎn)要說(shuō)明

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

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

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

Prototype：使用一個(gè)原型來(lái)限制要?jiǎng)?chuàng)建的類的類型，通過(guò)復(fù)制這個(gè)原型得到新的類；可改變的方面是：實(shí)例化類的對(duì)象。

Singleton：保證一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)全局性的訪問(wèn)點(diǎn)；可改變的方面是：類的單個(gè)實(shí)例。

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

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

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

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

Decorator：給對(duì)象動(dòng)態(tài)地加入新的職責(zé)，它提供了用子類擴(kuò)展功能的一個(gè)靈活的替代；可改變的方面是：無(wú)子類對(duì)象的責(zé)任。

§5.2.6GOF設(shè)計(jì)模式

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

Flyweight：提供支持大量細(xì)粒度對(duì)象共享的有效方法；可改變的方面是：對(duì)象的存儲(chǔ)代價(jià)。

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

ChainofResponsibility：通過(guò)給多個(gè)對(duì)象處理請(qǐng)求的機(jī)會(huì)，減少請(qǐng)求的發(fā)送者與接收者之間的耦合；將接收對(duì)象鏈接起來(lái)，在鏈中傳遞請(qǐng)求，直到有一個(gè)對(duì)象處理這個(gè)請(qǐng)求；可改變的方面是：可滿足請(qǐng)求的對(duì)象。

Command：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而將不同的請(qǐng)求對(duì)象化并進(jìn)行排隊(duì)或登記，以支持撤消操作；可改變的方面是：何時(shí)及如何滿足一個(gè)請(qǐng)求。

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

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

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

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

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

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

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

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

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

HTTP、

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

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

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

SOAP定義了一個(gè)“envelope”對(duì)象，使用“envelope”包