第八章面向?qū)ο笤O(shè)計(jì)內(nèi)容提綱軟件體系結(jié)構(gòu)–基本概念與設(shè)計(jì)文檔體系結(jié)構(gòu)風(fēng)格–倉庫體系結(jié)構(gòu)–模型／視圖／控制器結(jié)構(gòu)–控制結(jié)構(gòu)–客戶機(jī)／服務(wù)器結(jié)構(gòu)–分層體系結(jié)構(gòu)設(shè)計(jì)模式–抽象工廠（AbstractFactory）模式–狀態(tài)（State）模式–外觀（Fa?ade）模式–觀察者（Observer）模式軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)包括一組軟件部件、軟件部件的外部的可見特性及其相互關(guān)系，其中軟件外部的可見特性是指軟件部件提供的服務(wù)、性能、特性、錯誤處理、共享資源使用等。–系統(tǒng)的總體組織結(jié)構(gòu)和全局控制結(jié)構(gòu)–通信、同步和數(shù)據(jù)訪問的協(xié)議–設(shè)計(jì)元素的組成與功能分配–非功能需求–系統(tǒng)的物理部署–備選設(shè)計(jì)方案的選擇軟件體系結(jié)構(gòu)

包依賴性

?依賴性–PackageA的一些成員引用PackageB的某些成員–PackageB的變化可能會影響到PackageA循環(huán)依賴的消除

循環(huán)依賴的消除

體系結(jié)構(gòu)風(fēng)格?軟件體系結(jié)構(gòu)風(fēng)格是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式，它反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特性，并指導(dǎo)如何將各個模塊和子系統(tǒng)有效地組織成一個完整系統(tǒng)。?典型的軟件體系結(jié)構(gòu)風(fēng)格–倉庫或知識庫結(jié)構(gòu)–模型／視圖／控制器體系結(jié)構(gòu)–控制結(jié)構(gòu)–客戶機(jī)／服務(wù)器結(jié)構(gòu)–分層體系結(jié)構(gòu)倉庫結(jié)構(gòu)?倉庫或知識庫結(jié)構(gòu)（Repositoryarchitecture）倉庫結(jié)構(gòu)

倉庫結(jié)構(gòu)是一種以數(shù)據(jù)為中心的體系結(jié)構(gòu)，它包含一個中心數(shù)據(jù)庫和一組相互獨(dú)立的處理中心數(shù)據(jù)的子系統(tǒng)，主要適合于數(shù)據(jù)由一個子系統(tǒng)產(chǎn)生而由其他子系統(tǒng)使用的情形。?優(yōu)點(diǎn)：在共享數(shù)據(jù)模型穩(wěn)定的情況下，擴(kuò)展新的子系統(tǒng)十分容易?缺點(diǎn)：子系統(tǒng)與共享數(shù)據(jù)之間的耦合度很高，共享數(shù)據(jù)將對系統(tǒng)的性能和子系統(tǒng)的修改產(chǎn)生瓶頸。?應(yīng)用：現(xiàn)代編譯器、管理信息系統(tǒng)、CAD系統(tǒng)和CASE工具集等。倉庫結(jié)構(gòu)倉庫結(jié)構(gòu)

模型/視圖/控制器結(jié)構(gòu)（Model/View/ControllerArchitecture）–該結(jié)構(gòu)是為同樣的數(shù)據(jù)提供多個視圖的應(yīng)用程序而設(shè)計(jì)的，它將交互系統(tǒng)的組成分解成模型、視圖、控制器三種部件。?視圖是應(yīng)用程序中用戶界面相關(guān)的部分，即用戶看到并與之交互的界面。?控制器工作就是根據(jù)用戶的輸入，控制用戶界面數(shù)據(jù)顯示和更新模型對象的狀態(tài)。?模型是應(yīng)用程序的主體部分，表示業(yè)務(wù)數(shù)據(jù)或者業(yè)務(wù)邏輯。–該結(jié)構(gòu)適合于交互式系統(tǒng)，特別是同一個模型需要多個視圖的情況。模型/視圖/控制器結(jié)構(gòu)

模型/視圖/控制器結(jié)構(gòu)控制結(jié)構(gòu)?該結(jié)構(gòu)關(guān)心的是子系統(tǒng)之間的控制流–集中式控制

?一個子系統(tǒng)專門負(fù)責(zé)控制，控制其他子系統(tǒng)的啟動和停止。它也可能將控制交給一個子系統(tǒng)，但在控制完成后控制權(quán)仍然要?dú)w還給它。

–基于事件的控制

?控制信息不是集中于一個子系統(tǒng)中，而是每個子系統(tǒng)都能接收來自外部的事件并對此作出響應(yīng)。這些事件可能來自其他子系統(tǒng)或來自系統(tǒng)的環(huán)境。控制結(jié)構(gòu)控制結(jié)構(gòu)客戶機(jī)／服務(wù)器結(jié)構(gòu)?客戶機(jī)／服務(wù)器結(jié)構(gòu)（Client/ServerArchitecture）

–在客戶機(jī)／服務(wù)器體系結(jié)構(gòu)中，作為服務(wù)器的子系統(tǒng)為其他客戶機(jī)的子系統(tǒng)提供服務(wù)，作為客戶機(jī)的子系統(tǒng)負(fù)責(zé)與用戶的交互。?瘦客戶機(jī)模型

–所有的應(yīng)用處理和數(shù)據(jù)管理都是在服務(wù)器上執(zhí)行，客戶機(jī)只是負(fù)責(zé)數(shù)據(jù)表示部分。–由于繁重的處理負(fù)荷全部集中在服務(wù)器和網(wǎng)絡(luò)上，有可能造成性能上的問題?？蛻魴C(jī)／服務(wù)器結(jié)構(gòu)?胖客戶機(jī)模型–服務(wù)器只負(fù)責(zé)對數(shù)據(jù)的管理，客戶機(jī)上的軟件實(shí)現(xiàn)應(yīng)用邏輯與用戶的交互。–系統(tǒng)管理更加復(fù)雜，因?yàn)閼?yīng)用程序的改變必須在客戶機(jī)上重新安裝。?三層的客戶機(jī)／服務(wù)器體系結(jié)構(gòu)分層體系結(jié)構(gòu)?層次化是一種概念，它將軟件設(shè)計(jì)組織成為類或組件的層次或集合，在同一個層次上的類或組件完成一個特定的目的。?良好的層次結(jié)構(gòu)可以易于系統(tǒng)的擴(kuò)展與維護(hù)，不同的層次之間通過接口進(jìn)行通信。?三層體系結(jié)構(gòu)（Three-tierArchitecture）–表示層：窗口、報(bào)表等用戶界面元素–應(yīng)用邏輯層：管理業(yè)務(wù)過程的任務(wù)和規(guī)則–存儲層：持久化存儲機(jī)構(gòu)分層體系結(jié)構(gòu)MiniLibrary：軟件體系結(jié)構(gòu)設(shè)計(jì)模式?回顧學(xué)過的數(shù)據(jù)結(jié)構(gòu)–Trees,Stacks,Queues–它們給軟件開發(fā)帶來了什么？?問題–在軟件體系結(jié)構(gòu)設(shè)計(jì)中是否存在一些可重用的解決方案？?答案是肯定的–設(shè)計(jì)模式使我們可以重用已經(jīng)成功的經(jīng)驗(yàn)–Pattern＝Documentedexperience設(shè)計(jì)模式設(shè)計(jì)模式?設(shè)計(jì)模式描述了軟件系統(tǒng)設(shè)計(jì)過程中常見問題的解決方案，它是從大量的成功實(shí)踐中總結(jié)出來的且被廣泛公認(rèn)的實(shí)踐和知識。?設(shè)計(jì)模式的好處–使人們可以簡便地重用已有的良好設(shè)計(jì)–提供了一套可供開發(fā)人員交流的語言–提升了人們看待問題的抽象程度–幫助設(shè)計(jì)人員更快更好地完成系統(tǒng)設(shè)計(jì)–模式是經(jīng)過考驗(yàn)的思想，具有更好的可靠性和擴(kuò)展性設(shè)計(jì)模式的風(fēng)險(xiǎn)?設(shè)計(jì)模式不是萬能的–模式可以解決大多數(shù)問題，但不可能解決遇到的所有問題–應(yīng)用一種模式一般會“有得有失”，切記不可盲目應(yīng)用–濫用設(shè)計(jì)模式可能會造成過度設(shè)計(jì)，反而得不償失?設(shè)計(jì)模式是有難度和風(fēng)險(xiǎn)的–一個好的設(shè)計(jì)模式是眾多優(yōu)秀軟件設(shè)計(jì)師集體智慧的結(jié)晶–在設(shè)計(jì)過程中引入模式的成本是很高的–設(shè)計(jì)模式只適合于經(jīng)驗(yàn)豐富的開發(fā)人員使用設(shè)計(jì)模式的基本要素?模式名稱–一個助記名，便于交流和思考?問題–描述應(yīng)該在何時使用模式，解釋了設(shè)計(jì)問題和問題存在的前因后果?解決方案–描述設(shè)計(jì)的組成部分，它們之間的相互關(guān)系以及各自的職責(zé)和協(xié)作方式?效果–描述模式應(yīng)用的效果以及應(yīng)權(quán)衡的問題設(shè)計(jì)模式的類型?創(chuàng)建型模式–創(chuàng)建型模式描述了實(shí)例化對象的相關(guān)技術(shù)，解決了與創(chuàng)建對象有關(guān)的問題。–創(chuàng)建型模式使用繼承來改變被實(shí)例化的類，而一個對象創(chuàng)建型模式將實(shí)例化委托給另一個對象。?典型的模式–工廠方法（FactoryMethod）、抽象工廠（AbstractFactory）–生成器（Builder）、原型（Prototype）、單件（Singleton）設(shè)計(jì)模式的類型?結(jié)構(gòu)型模式–結(jié)構(gòu)型模式描述了在軟件系統(tǒng)中組織類和對象的常用方法，避免了一個類被賦予過多職責(zé)而破壞類的封裝性和信息的隱藏，和類之間功能重疊的問題。–結(jié)構(gòu)型模式采用繼承機(jī)制來組合接口或?qū)崿F(xiàn)。?典型的模式–適配器Adapter、橋接Bridge、組成Composite–裝飾Decorator、外觀Facade、享元Flyweight、代理Proxy設(shè)計(jì)模式的類型行為模式–行為模式負(fù)責(zé)分配對象的職責(zé)，為對象間協(xié)作建模提供了有效的策略。–行為模式使用繼承機(jī)制在類件分配行為。?典型的模式–職責(zé)鏈ChainofResponsibility、命令Command、–解釋器Interpreter、迭代器Iterator、中介者M(jìn)ediator–備忘錄Memento、觀察者Observer、狀態(tài)State

–策略Strategy、模板方法TemplateMethod、訪問者Visitor設(shè)計(jì)模式示例?抽象工廠（AbstractFactory）模式–抽象工廠模式是用于封裝具體的平臺，從而使應(yīng)用程序可以在不同的平臺上運(yùn)行。?狀態(tài)（State）模式–狀態(tài)模式允許一個對象在其內(nèi)部狀態(tài)改變時改變自己行為。?外觀（Fa?ade）模式–外觀模式用簡單的統(tǒng)一接口封裝子系統(tǒng)，從而降低類之間的相關(guān)性。?觀察者（Observer）模式–觀察者模式用于定義對象之間一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生變化時，所有依賴于它的對象都將得到通知而被自動更新。AbstractFactoryAbstractFactoryStateFa?adeObserver面向?qū)ο笤O(shè)計(jì)的制品–設(shè)計(jì)類–用例實(shí)現(xiàn)（從設(shè)計(jì)角度）–設(shè)計(jì)子系統(tǒng)與接口–體系結(jié)構(gòu)描述（從設(shè)計(jì)角度）–部署圖–體系結(jié)構(gòu)描述（從部署角度）設(shè)計(jì)原則模塊化（Modularity）

–將一個復(fù)雜的大系統(tǒng)分解成若干個相對簡單的較小部分，稱為子系統(tǒng)（Subsystem）。耦合（Coupling）–耦合表示兩個子系統(tǒng)（或類）之間的關(guān)聯(lián)程度。–當(dāng)一個子系統(tǒng)（或類）發(fā)生變化時對另一個子系統(tǒng)（或類）的影響很小，則稱它們是松散耦合的；反之，如果變化的影響很大時，則稱它們是緊密耦合的設(shè)計(jì)原則耦合（Coupling）

設(shè)計(jì)原則?內(nèi)聚（Cohesion）–內(nèi)聚性是子系統(tǒng)內(nèi)部的相關(guān)程度。–當(dāng)子系統(tǒng)中彼此相關(guān)的多個對象執(zhí)行類似的任務(wù)時，則認(rèn)為該子系統(tǒng)是高內(nèi)聚的；反之，當(dāng)子系統(tǒng)內(nèi)的多個對象彼此不相關(guān)時，則認(rèn)為是低內(nèi)聚的。–高內(nèi)聚的方法做且僅做一件事，這會很容易理解與維護(hù)。

?舉例：如果使用一個方法changeItem()完成書目的讀取、增加、修改和刪除等若干方法的功能，有什么問題嗎？–高內(nèi)聚的類表示且僅表示一種類型的對象。

?舉例：在大學(xué)系統(tǒng)中使用Professor而不用Employee，為什么？

面向?qū)ο笤O(shè)計(jì)的過程MiniLibrary：軟件體系結(jié)構(gòu)

MiniLibrary：軟件體系結(jié)構(gòu)

MiniLibrary：軟件體系結(jié)構(gòu)

識別設(shè)計(jì)元素

識別設(shè)計(jì)元素

?確定設(shè)計(jì)元素的基本原則–如果一個“分析類”比較簡單，代表著單一的邏輯抽象，那么可以將其映射為“設(shè)計(jì)類”。通常，主動參與者對應(yīng)的邊界類、控制類和一般的實(shí)體類都可以直接映射成設(shè)計(jì)類。–如果“分析類”的職責(zé)比較復(fù)雜，很難由單個“設(shè)計(jì)類”承擔(dān)，則應(yīng)該將其映射成“子系統(tǒng)接口”。通常，被動參與者對應(yīng)的邊界類被映射成子系統(tǒng)接口。–子系統(tǒng)的劃分應(yīng)該符合高內(nèi)聚低耦合的原則。?問題：MiniLibrary系統(tǒng)的分析類哪些應(yīng)該直接映射成設(shè)計(jì)類？哪些應(yīng)該映射成子系統(tǒng)？MiniLibrary：識別設(shè)計(jì)元素

MiniLibrary：識別設(shè)計(jì)元素

識別子系統(tǒng)接口–在確定了設(shè)計(jì)元素之后，需要描述子系統(tǒng)的行為，也就是準(zhǔn)確定義接口操作的集合。同時，還要確定“子系統(tǒng)接口”與其他設(shè)計(jì)元素之間的依賴關(guān)系。數(shù)據(jù)存儲策略

?數(shù)據(jù)文件–數(shù)據(jù)文件是由操作系統(tǒng)提供的存儲形式，應(yīng)用系統(tǒng)將數(shù)據(jù)按字節(jié)順序存儲，并定義如何以及何時檢索數(shù)據(jù)。?關(guān)系數(shù)據(jù)庫–在關(guān)系數(shù)據(jù)庫中，數(shù)據(jù)是以表的形式存儲在預(yù)先定義好的成為Schema的類型中。?面向?qū)ο髷?shù)據(jù)庫–與關(guān)系數(shù)據(jù)庫不同的是，面向?qū)ο髷?shù)據(jù)庫將對象和關(guān)系作為數(shù)據(jù)一起存儲。數(shù)據(jù)存儲策略

?何時選擇文件？–存儲大容量數(shù)據(jù)、臨時數(shù)據(jù)、低信息密度數(shù)據(jù)?何時選擇數(shù)據(jù)庫？–并發(fā)訪問要求高、系統(tǒng)跨平臺、多個應(yīng)用程序使用相同數(shù)據(jù)?何時選擇關(guān)系數(shù)據(jù)庫？–復(fù)雜的數(shù)據(jù)查詢–數(shù)據(jù)集規(guī)模大?何時選擇面向?qū)ο髷?shù)據(jù)庫？–數(shù)據(jù)集處于中等規(guī)模–對象間沒有規(guī)則聯(lián)系部署子系統(tǒng)?部署圖反映了系統(tǒng)中軟件和硬件的物理架構(gòu)，表示系統(tǒng)運(yùn)行時的處理節(jié)點(diǎn)以及節(jié)點(diǎn)中組件的配置。檢查系統(tǒng)設(shè)計(jì)?檢查“正確性”–每個子系統(tǒng)都能追溯到一個用例或一個非功能需求嗎？–每一個用例都能映射到一個子系統(tǒng)嗎？–系統(tǒng)設(shè)計(jì)模型中是否提到了所有的非功能需求？–每一個參與者都有合適的訪問權(quán)限嗎？–系統(tǒng)設(shè)計(jì)是否與安全性需求一致？?檢查“一致性”–是否將沖突的設(shè)計(jì)目標(biāo)進(jìn)行了排序？–是否有設(shè)計(jì)目標(biāo)違背了非功能需求？–是否存在多個子系統(tǒng)或類重名？檢查系統(tǒng)設(shè)計(jì)?檢查“完整性”–是否處理邊界條件？–是否有用例走查來確定系統(tǒng)設(shè)計(jì)遺漏的功能？–是否涉及到系統(tǒng)設(shè)計(jì)的所有方面（如硬件部署、數(shù)據(jù)存儲、訪問控制、遺留系統(tǒng)、邊界條件）？–是否定義了所有的子系統(tǒng)？?檢查“可行性”–系統(tǒng)中是否使用了新的技術(shù)或組件？是否對這些技術(shù)或組件進(jìn)行了可行性研究？–在子系統(tǒng)分解環(huán)境中檢查性能和可靠性需求了嗎？–考慮并發(fā)問題了嗎？方法建模?方法建模的過程

–找出滿足基本邏輯要求的操作–補(bǔ)充必要的輔助方法

?初始化類的實(shí)例?驗(yàn)證兩個實(shí)例是否等同?……

–完整地描述操作

?確定方法的名稱、參數(shù)、返回值、可見性等?應(yīng)該遵從程序設(shè)計(jì)語言的命名規(guī)則

–簡要說明方法的內(nèi)部實(shí)現(xiàn)邏輯方法建模屬性建模?定義屬性–具體說明屬性的名稱、類型、缺省值、可見性等?基本原則–將所有屬性的可見性設(shè)置為private；–僅通過set方法更新屬性；–僅通過get方法訪問屬性；–在屬性的set方法中，實(shí)現(xiàn)簡單的有效性驗(yàn)證，而在獨(dú)立的驗(yàn)證方法中實(shí)現(xiàn)復(fù)雜的邏輯驗(yàn)證。屬性建模狀態(tài)建模?在詳細(xì)設(shè)計(jì)階段，狀態(tài)建模一般只發(fā)生在依賴狀態(tài)展示不同行為的類上。關(guān)系建模?在對象設(shè)計(jì)階段，需要進(jìn)一步確定詳細(xì)的關(guān)聯(lián)關(guān)系、依賴關(guān)系和聚合關(guān)系等。?不同對象之間的可能連接用戶界面的設(shè)計(jì)原則

用戶控制式–用戶啟動行為并取得結(jié)果，如果程序取得控制權(quán)的話，用戶也要獲得必要的反饋（一個沙漏、一個等待的指示器或其他類似的東西）。?界面一致性–遵循標(biāo)準(zhǔn)和常規(guī)的方式，應(yīng)該讓用戶處在一個熟悉的和可預(yù)見的環(huán)境之中。

?若應(yīng)用是為Windows開發(fā)的，則應(yīng)采用Windows“外觀和感覺”；?菜單、活動按鈕、屏幕區(qū)域等的命名和編碼、對象在屏幕上處于什么位置的標(biāo)準(zhǔn)等的一致性也不能低估。?用戶界面的設(shè)計(jì)原則

?界面容錯性–一個好的界面應(yīng)該以一種寬容的態(tài)度允許用戶進(jìn)行實(shí)驗(yàn)和出錯，用戶在出現(xiàn)錯誤時能夠方便地從錯誤中恢復(fù)。?界面可適應(yīng)性–界面可適應(yīng)性是指用戶界面應(yīng)該根據(jù)用戶的個性要求及其對界面的熟知程度而改變，即滿足定制化和個性化的要求。–所謂定制化是在程序中聲明用戶的熟知程度，用戶界面可以根據(jù)熟知程度改變外觀和行為；–所謂個性化是使用戶按照自己的習(xí)慣和愛好來設(shè)置用戶界面元素。用戶界面的設(shè)計(jì)原則

?界面美觀性–界面美觀性是視覺上的吸引力，主要體現(xiàn)在具有平衡和對稱性、合適的色彩、各元素具有合理的對齊方式和間隔、相關(guān)