【正文】 這一問題的一個極端情況是領(lǐng)域模型過于龐大，包括了許多冗余的抽象；另一個極端是領(lǐng)域模型過小，缺少基本的體系結(jié)構(gòu)抽象。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 小結(jié) （ 3）難以適度控制領(lǐng)域模型 領(lǐng)域驅(qū)動的方法和用例驅(qū)動的方法在構(gòu)造軟件體系結(jié)構(gòu)時都用到了領(lǐng)域模型。 除此之外，需求自身也可能被不正確的描述，既有可能提出過度要求，也有可能要求不足?？蛻粜枨筇峁┑氖菍ο到y(tǒng)中問題的設(shè)想，而體系結(jié)構(gòu)的目標是提供能用來實現(xiàn)系統(tǒng)的解決方案的設(shè)想。因為這時對于分析和設(shè)計模型沒有足夠的知識，難以確定體系結(jié)構(gòu)的適當(dāng)邊界。但是，這可能會帶來項目的不可管理性，因為項目的許多開發(fā)過程將無法得到體系結(jié)構(gòu)的指導(dǎo)。 一般來講，體系結(jié)構(gòu)的確定應(yīng)當(dāng)在分析和設(shè)計階段之前或之后完成。 領(lǐng)域驅(qū)動的體系結(jié)構(gòu)設(shè)計方法從領(lǐng)域模型導(dǎo)出體系結(jié)構(gòu)抽象。 用例驅(qū)動的體系結(jié)構(gòu)設(shè)計方法從用例模型導(dǎo)出體系結(jié)構(gòu)抽象，用例模型表示了系統(tǒng)預(yù)期要實現(xiàn)的功能。這些方法被分類為：工件驅(qū)動的、用例驅(qū)動的、模式驅(qū)動的和領(lǐng)域驅(qū)動的。這種情況下，全面的解決方案領(lǐng)域分析對于提供穩(wěn)定的抽象也可能是不夠充分的，因為解決方案領(lǐng)域中的概念自身也存在著波動。在這些相關(guān)領(lǐng)域的概念上，人們還沒有取得共識，這些研究領(lǐng)域還有待于進一步發(fā)展。大型的領(lǐng)域模型將可能妨礙尋找體系結(jié)構(gòu)抽象。首先，解決方案領(lǐng)域分析并不是為軟件體系結(jié)構(gòu)設(shè)計而定義的，而是為實現(xiàn)軟件開發(fā)等活動中的系統(tǒng)資源重用而定義的。盡管解決方案領(lǐng)域分析提供了對整個領(lǐng)域建模的潛力，而且這種潛力對于導(dǎo)出領(lǐng)域體系結(jié)構(gòu)是必需的，但是，這并不足以驅(qū)動體系結(jié)構(gòu)設(shè)計過程。正如前面描述的，在系統(tǒng)重用研究領(lǐng)域中，這一活動被稱作領(lǐng)域工程。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 域驅(qū)動（ domaindriven）的方法 缺點： （ 2）解決方案領(lǐng)域分析不夠充分。類似于用例那樣，場景關(guān)注的也是問題領(lǐng)域和系統(tǒng)的外部行為。 一些領(lǐng)域驅(qū)動的體系結(jié)構(gòu)設(shè)計方法把領(lǐng)域解釋成問題領(lǐng)域。 （ 2）解決方案領(lǐng)域分析不夠充分。 ◇ 模式驅(qū)動（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 域驅(qū)動（ domaindriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 域驅(qū)動（ domaindriven）的方法 主要用于產(chǎn)品線體系結(jié)構(gòu)設(shè)計和特定領(lǐng)域的軟件體系結(jié)構(gòu)設(shè)計。假設(shè)在某問題中，經(jīng)過問題分析階段之后，我們認為要組合使用分層模式、管道－過濾器模式和倉庫模式。分別對這些模式進行定義并不能表示出模式之間的相關(guān)性。 在開發(fā)軟件體系結(jié)構(gòu)時，常常要組合使用多種模式。當(dāng)前，對于這一匹配過程并沒有嚴格的方法可循，模式的應(yīng)用仍然基于軟件工程師的經(jīng)驗和通用知識。過濾器接收輸入數(shù)據(jù)，進行處理，提供輸出數(shù)據(jù)；管道在一個過濾器的輸出和另一個過濾器的輸入之間發(fā)送數(shù)據(jù)。 ◇ 模式驅(qū)動（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 例如，對于一個給定的問題，選擇使用管道－過濾器模式。 在選擇了模式之后，模式的應(yīng)用也并不是一個簡單直接的過程。這妨礙了查找模式的過程，也進而妨礙了體系結(jié)構(gòu)的確定。這樣，對于同一問題，可能有多種體系結(jié)構(gòu)模式可供選擇。 為了簡化對模式的選擇和管理，改進對模式的理解，人們通常把具有共同特點的模式分類到相同的組中。由于應(yīng)用領(lǐng)域中的軟件系統(tǒng)千變?nèi)f化，所以，也就有無數(shù)的體系結(jié)構(gòu)抽象和體系結(jié)構(gòu)模式。盡管這些分類為軟件體系結(jié)構(gòu)設(shè)計提供了使用的工具，但是它們沒有也無法覆蓋所有范圍內(nèi)的體系結(jié)構(gòu)開發(fā)問題。 對于模式驅(qū)動的體系結(jié)構(gòu)設(shè)計方法而言，必要的條件之一是有充足的模式庫可用。 （ 4）對于模式的組合沒有提供很好的支持。 （ 2）對模式的選擇僅依靠通用知識和軟件工程師的經(jīng)驗。進而用“解決方案”這一子概念來提供所給出問題的解決方案。如果發(fā)現(xiàn)一個模式的意圖和給出的問題相關(guān)，那么就分析它的上下文描述。主要由 4個概念組成： ●意圖：表示使用模式的基本原則； ●上下文：表示問題的產(chǎn)生環(huán)境； ●問題：表示上下文環(huán)境中經(jīng)常出現(xiàn)的問題； ●解決方案：是以元素及其關(guān)系的抽象描述的形式來表示對問題的解決方案。體系結(jié)構(gòu)模式類似于設(shè)計模式，實際上它就是體系結(jié)構(gòu)風(fēng)格的另一種名稱。軟件設(shè)計模式常常用在設(shè)計階段。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 模式驅(qū)動（ patterndriven）的方法 軟件工業(yè)界已經(jīng)廣泛接受了軟件設(shè)計模式的概念。 ◇ 用例驅(qū)動（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 模式驅(qū)動（ patterndriven）的方法 體系結(jié)構(gòu)模式關(guān)心的是體系結(jié)構(gòu)級別的元素及其交互。而且，在把分析和設(shè)計類分組成包、以及把包組合為最終的體系結(jié)構(gòu)等方面，該方法提供的支持也很有限，主要依靠軟件工程師的通用知識。 該方法中，分析和設(shè)計模型被分組為包。因此，即使確定了所有的相關(guān)用例，從用例模型確定體系結(jié)構(gòu)抽象仍將是較為困難的。用例主要關(guān)注的是系統(tǒng)的問題域和外部行為。工件是從文本形式的需求中得出的，這類似于工件驅(qū)動的方法。這意味著分析和設(shè)計類是從用例中確定的。 ◇ 用例驅(qū)動（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 缺點： （ 3）用例沒有為體系結(jié)構(gòu)抽象提供堅實的基礎(chǔ)。 為了進行體系結(jié)構(gòu)描述，需要選擇與體系結(jié)構(gòu)相關(guān)的用例。在了解用例之前，很難回答這一問題，因為用例實際上定義了所要開發(fā)的是什么。 該方法在定義用例模型之前進行商業(yè)模型和領(lǐng)域模型的定義。 （ 4）包的語義過于簡單，難以作為體系結(jié)構(gòu)構(gòu)件。 （ 2）對于如何選擇與體系結(jié)構(gòu)相關(guān)的用例沒有提供系統(tǒng)的支持?！?3：分組”和“ 4：組合”這兩個功能都受到“通用知識”概念的支持。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 用例驅(qū)動（ usecasedriven）的方法 然后，分析和設(shè)計模型被分組為包，這在圖中表示為“ 3：分組”。這在圖中被表示為分別從“工件”和“通用知識”引出的指向“ 2：實現(xiàn)”的箭頭線。用例實現(xiàn)決定了任務(wù)在系統(tǒng)內(nèi)部是怎樣進行的?！邦I(lǐng)域模型”描述領(lǐng)域上下文中最重要的類。 如前所述，“非形式化的規(guī)格說明”表示文本形式的需求規(guī)格說明。 用例模型和非形式化的需求規(guī)格說明共同構(gòu)成了系統(tǒng)的需求規(guī)格說明。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 用例驅(qū)動（ usecasedriven）的方法 在需求工作流中，以用例的形式捕捉客戶的需求，構(gòu)成用例模型。 統(tǒng)一過程由 6個核心工作流組成：商業(yè)模型、需求、分析、設(shè)計、實現(xiàn)和測試。核心工作流定義了過程的靜態(tài)內(nèi)容，用活動、工人和工件描述了過程。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 用例驅(qū)動（ usecasedriven）的方法 統(tǒng)一過程使用的是一種用例驅(qū)動的體系結(jié)構(gòu)設(shè)計方法。參與者通過用例使用系統(tǒng)。 目的： 作為系統(tǒng)預(yù)期功能及其環(huán)境的模型，并在客戶和開發(fā)者之間起到合約的作用。 （ 3）對子系統(tǒng)的組合支持不足。以它作為導(dǎo)出體系結(jié)構(gòu)抽象的來源作用不夠。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 工件驅(qū)動（ artifactdriven）的方法 工件驅(qū)動的體系結(jié)構(gòu)設(shè)計方法的例子包括廣為流行的面向?qū)ο蠓治龊驮O(shè)計方法 OMT和 OAD。我們把這些體系結(jié)構(gòu)設(shè)計方法分類為： 工件驅(qū)動（ artifactdriven）的方法； 用例驅(qū)動（ usecasedriven）的方法； 模式驅(qū)動（ patterndriven）的方法； 域驅(qū)動（ domaindriven）的方法。 體系結(jié)構(gòu)描述：定義了軟件體系結(jié)構(gòu)的規(guī)格說明。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計方法的元模型 第三階段：體系結(jié)構(gòu)規(guī)格說明。一般，每種工件都有一套與之相關(guān)的試探法，用來標識相關(guān)的工件實例。 工件：表示某一方法的工件描述。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計方法的元模型 第二階段：提取解決方案 的結(jié)構(gòu)。 領(lǐng)域知識：表示在解決某一問題中所應(yīng)用的知識的范圍。 客戶：表示那些關(guān)心軟件體系結(jié)構(gòu)設(shè)計的系統(tǒng)相關(guān)人員。包括需求規(guī)格說明文檔、與客戶面談、客戶發(fā)布的原型等。 系統(tǒng) /產(chǎn)品知識是指關(guān)于一個系統(tǒng)、一個系統(tǒng)族或一個產(chǎn)品的知識。解決方案領(lǐng)域知識還包括如何從這一解決方案領(lǐng)域生產(chǎn)軟件系統(tǒng)。 解決方案領(lǐng)域知識是指提供領(lǐng)域概念的知識。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計方法的元模型 商業(yè)領(lǐng)域知識是指商業(yè)過程觀點下的與問題有關(guān)的知識。 元模型中有三處用到了領(lǐng)域知識的概念。該原理使部件行為和表示的改變特別容易，尤其是那些不影響接口的改變，例如對運行性能的提高。如果部件的接口和實現(xiàn)分離，那么它就更容易在系統(tǒng)中進行改變。該原理強調(diào)“一個客戶只應(yīng)該知道它需要知道的東西”。另外，該原理還允許獨立于其他部件的應(yīng)用而實現(xiàn)一個部件的功能。實現(xiàn)部分對部件客戶來說是不可用的。 實現(xiàn)部分包括了實現(xiàn)部件所提供功能的實際代碼。該接口對部件的客戶是可訪問的。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 任何一個部件都應(yīng)該包含兩個部分，接口和實現(xiàn)。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 由于獨立于特定的上下文環(huán)境，純實現(xiàn)部件更容易重用和維護，而策略部件通常是與特定應(yīng)用相關(guān)的，需要隨著應(yīng)用的變化而變化。 實現(xiàn)部件負責(zé)全面規(guī)范算法的執(zhí)行，執(zhí)行中不需要對上下文相關(guān)信息進行決策。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 軟件系統(tǒng)的部件應(yīng)該實現(xiàn)策略或處理問題，但不能同時處理兩者。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 例如，在多層體系結(jié)構(gòu)的組件設(shè)計中，在多種應(yīng)用場景中擔(dān)任不同角色的同一個組件，需要和可以使用不同的接口定義。相互協(xié)作完成某一個特定任務(wù)的部件應(yīng)該和在其他任務(wù)中執(zhí)行計算的部分分離開來。其他形式的內(nèi)聚還有：邏輯內(nèi)聚、時間內(nèi)聚、過程內(nèi)聚、通信內(nèi)聚、順序內(nèi)聚和不規(guī)則內(nèi)聚。最期望獲得的是功能內(nèi)聚，它說明一個模塊或是部件內(nèi)的所有元素都協(xié)同來提供具有良好邊界的行為。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 內(nèi)聚用來衡量單一模塊內(nèi)功能和元素間聯(lián)系性的程度。緊密的耦合就會使系統(tǒng)變得復(fù)雜，因為如果一個模塊和另外的模塊有很密切的關(guān)聯(lián)的話，這個模塊就很難理解、調(diào)試、維護。耦合強調(diào)模塊之間的特征，而內(nèi)聚強調(diào)模塊內(nèi)部的特性。另外它對于系統(tǒng)的運行設(shè)計和管理調(diào)度也提供了方便，例如，對于動態(tài)鏈接庫的選擇應(yīng)用、程序運行體的覆蓋和交換都是十分有益的。模塊化與封裝原理的聯(lián)系非常密切。模塊化的主要做法，就是在一個系統(tǒng)內(nèi)引入具有良好定義的分界，依此來處理系統(tǒng)的復(fù)雜性。例如，在一個應(yīng)用中為了提高運行性能，可能需要對某一部件的內(nèi)部數(shù)據(jù)結(jié)構(gòu)進行直接訪問；而在另外一個應(yīng)用中，可能因為對其性能已經(jīng)滿意了，就不需要對其數(shù)據(jù)的直接訪問了。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 然而，部件應(yīng)該隱藏什么取決于具體的應(yīng)用。封裝原理經(jīng)常被用來作為實現(xiàn)信息隱藏的方法。 信息隱蔽對用戶隱藏了部件的實現(xiàn)細節(jié)，用來更好地處理系統(tǒng)的復(fù)雜性和減少各部件之間的耦合。例如，通過對象、模塊設(shè)計和訪問接口設(shè)計分別提供了這兩種封裝。封裝有利于非功能特性實現(xiàn)，例如可變性和可重用性。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計 ◇ 體系結(jié)構(gòu)設(shè)計的原則 封裝是將構(gòu)成抽象的屬性和行為結(jié)合在一起，并區(qū)分不同抽象的方法。例如，自上而下設(shè)計將一個任務(wù)或部件分成可以獨