【正文】 4）包的語(yǔ)義過(guò)于簡(jiǎn)單，難以作為體系結(jié)構(gòu)構(gòu)件。 ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 1）難以適度把握領(lǐng)域模型和商業(yè)模型的細(xì)節(jié)。 該方法在定義用例模型之前進(jìn)行商業(yè)模型和領(lǐng)域模型的定義。這就帶來(lái)了如何適度把握這些模型的細(xì)節(jié)的問(wèn)題。在了解用例之前，很難回答這一問(wèn)題，因?yàn)橛美龑?shí)際上定義了所要開(kāi)發(fā)的是什么。 ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 2）對(duì)于如何選擇與體系結(jié)構(gòu)相關(guān)的用例沒(méi)有提供系統(tǒng)的支持。 為了進(jìn)行體系結(jié)構(gòu)描述，需要選擇與體系結(jié)構(gòu)相關(guān)的用例。但在確定哪些用例是“體系結(jié)構(gòu)相關(guān)”時(shí)，缺乏客觀標(biāo)準(zhǔn)，僅憑一些啟發(fā)式規(guī)則和軟件工程師的評(píng)估。 ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 3）用例沒(méi)有為體系結(jié)構(gòu)抽象提供堅(jiān)實(shí)的基礎(chǔ)。 在選擇出與體系結(jié)構(gòu)相關(guān)的用例之后，對(duì)它們進(jìn)行實(shí)現(xiàn)。這意味著分析和設(shè)計(jì)類(lèi)是從用例中確定的。用例實(shí)現(xiàn)受到工件的啟發(fā)式規(guī)則的支持，還受到軟件工程師的通用知識(shí)的支持。工件是從文本形式的需求中得出的，這類(lèi)似于工件驅(qū)動(dòng)的方法。盡管用例對(duì)于理解和表示用戶需求是實(shí)用的，但它并不能為導(dǎo)出體系結(jié)構(gòu)設(shè)計(jì)抽象提供堅(jiān)實(shí)的基礎(chǔ)。用例主要關(guān)注的是系統(tǒng)的問(wèn)題域和外部行為。在用例實(shí)現(xiàn)中，解決方案領(lǐng)域和內(nèi)部系統(tǒng)中的透明或隱藏抽象將難以標(biāo)識(shí)。因此，即使確定了所有的相關(guān)用例，從用例模型確定體系結(jié)構(gòu)抽象仍將是較為困難的。 ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 4）包的語(yǔ)義過(guò)于簡(jiǎn)單，難以作為體系結(jié)構(gòu)構(gòu)件。 該方法中，分析和設(shè)計(jì)模型被分組為包。包，類(lèi)似于工件驅(qū)動(dòng)的方法中的子系統(tǒng)，主要也是分組機(jī)制，因此其語(yǔ)義也很簡(jiǎn)單。而且，在把分析和設(shè)計(jì)類(lèi)分組成包、以及把包組合為最終的體系結(jié)構(gòu)等方面，該方法提供的支持也很有限，主要依靠軟件工程師的通用知識(shí)。這也可能帶來(lái)錯(cuò)誤定義的體系結(jié)構(gòu)邊界及其交互。 ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 體系結(jié)構(gòu)模式關(guān)心的是體系結(jié)構(gòu)級(jí)別的元素及其交互。 體系結(jié)構(gòu)設(shè)計(jì)模式本身不是軟件體系結(jié)構(gòu)，而是體系結(jié)構(gòu)層次的一種抽象表示。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 軟件工業(yè)界已經(jīng)廣泛接受了軟件設(shè)計(jì)模式的概念。軟件設(shè)計(jì)模式的目的在于編制一套可重用的基本原則，用于開(kāi)發(fā)高質(zhì)量的軟件系統(tǒng)。軟件設(shè)計(jì)模式常常用在設(shè)計(jì)階段。 也有研究者在軟件開(kāi)發(fā)過(guò)程中的體系結(jié)構(gòu)分析階段應(yīng)用設(shè)計(jì)模式。體系結(jié)構(gòu)模式類(lèi)似于設(shè)計(jì)模式，實(shí)際上它就是體系結(jié)構(gòu)風(fēng)格的另一種名稱(chēng)。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 體系結(jié)構(gòu)模式描述的概念指的是對(duì)體系結(jié)構(gòu)模式的描述。主要由 4個(gè)概念組成： ●意圖：表示使用模式的基本原則； ●上下文：表示問(wèn)題的產(chǎn)生環(huán)境； ●問(wèn)題：表示上下文環(huán)境中經(jīng)常出現(xiàn)的問(wèn)題； ●解決方案：是以元素及其關(guān)系的抽象描述的形式來(lái)表示對(duì)問(wèn)題的解決方案。 為了確認(rèn)模式，就要對(duì)各個(gè)可用模式的意圖進(jìn)行掃描。如果發(fā)現(xiàn)一個(gè)模式的意圖和給出的問(wèn)題相關(guān)，那么就分析它的上下文描述。如果上下文描述仍然能夠和給出的問(wèn)題相匹配，則處理過(guò)程進(jìn)入“應(yīng)用”階段。進(jìn)而用“解決方案”這一子概念來(lái)提供所給出問(wèn)題的解決方案。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 1）在處理范圍廣泛的體系結(jié)構(gòu)問(wèn)題時(shí)，模式庫(kù)可能不夠充分。 （ 2）對(duì)模式的選擇僅依靠通用知識(shí)和軟件工程師的經(jīng)驗(yàn)。 （ 3）模式的應(yīng)用并不是一個(gè)簡(jiǎn)單直接的過(guò)程，它需要對(duì)問(wèn)題進(jìn)行全面的分析。 （ 4）對(duì)于模式的組合沒(méi)有提供很好的支持。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 1）在處理范圍廣泛的體系結(jié)構(gòu)問(wèn)題時(shí)，模式庫(kù)可能不夠充分。 對(duì)于模式驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法而言，必要的條件之一是有充足的模式庫(kù)可用。當(dāng)前已經(jīng)存在眾多的體系結(jié)構(gòu)模式（風(fēng)格）分類(lèi)。盡管這些分類(lèi)為軟件體系結(jié)構(gòu)設(shè)計(jì)提供了使用的工具，但是它們沒(méi)有也無(wú)法覆蓋所有范圍內(nèi)的體系結(jié)構(gòu)開(kāi)發(fā)問(wèn)題。這一問(wèn)題的原因在于，體系結(jié)構(gòu)由表示對(duì)特定領(lǐng)域的抽象的概念和定義這些概念的組成方式及其相互聯(lián)系的模式組成。由于應(yīng)用領(lǐng)域中的軟件系統(tǒng)千變?nèi)f化，所以，也就有無(wú)數(shù)的體系結(jié)構(gòu)抽象和體系結(jié)構(gòu)模式。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 2）對(duì)模式的選擇僅依靠通用知識(shí)和軟件工程師的經(jīng)驗(yàn)。 為了簡(jiǎn)化對(duì)模式的選擇和管理，改進(jìn)對(duì)模式的理解，人們通常把具有共同特點(diǎn)的模式分類(lèi)到相同的組中。不同的體系結(jié)構(gòu)設(shè)計(jì)方法可能有不同的分類(lèi)原則。這樣，對(duì)于同一問(wèn)題，可能有多種體系結(jié)構(gòu)模式可供選擇。但是，在如何確定優(yōu)先次序、如何在不同模式間進(jìn)行取舍和平衡等問(wèn)題上，當(dāng)前的體系結(jié)構(gòu)設(shè)計(jì)方法并沒(méi)有提供明確的支持。這妨礙了查找模式的過(guò)程，也進(jìn)而妨礙了體系結(jié)構(gòu)的確定。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 3）模式的應(yīng)用并不是一個(gè)簡(jiǎn)單直接的過(guò)程，它需要對(duì)問(wèn)題進(jìn)行全面的分析。 在選擇了模式之后，模式的應(yīng)用也并不是一個(gè)簡(jiǎn)單直接的過(guò)程?？梢园涯Ｊ娇闯墒且环N模板，它由構(gòu)件及其相互關(guān)系組成，在使用時(shí)，必須與問(wèn)題領(lǐng)域的概念和概念之間的關(guān)系相匹配。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 例如，對(duì)于一個(gè)給定的問(wèn)題，選擇使用管道－過(guò)濾器模式。在這種模式中，過(guò)濾器作為構(gòu)件，管道作為連接件。過(guò)濾器接收輸入數(shù)據(jù)，進(jìn)行處理，提供輸出數(shù)據(jù)；管道在一個(gè)過(guò)濾器的輸出和另一個(gè)過(guò)濾器的輸入之間發(fā)送數(shù)據(jù)。在應(yīng)用這種模式時(shí)，存在的問(wèn)題有：應(yīng)當(dāng)把哪些領(lǐng)域概念表示成管道，把哪些領(lǐng)域概念表示成過(guò)濾器？它們的結(jié)構(gòu)是怎樣的？等等。當(dāng)前，對(duì)于這一匹配過(guò)程并沒(méi)有嚴(yán)格的方法可循，模式的應(yīng)用仍然基于軟件工程師的經(jīng)驗(yàn)和通用知識(shí)。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 缺點(diǎn)： （ 4）對(duì)于模式的組合沒(méi)有提供很好的支持。 在開(kāi)發(fā)軟件體系結(jié)構(gòu)時(shí)，常常要組合使用多種模式。這些模式通常并不是相互獨(dú)立的，而是存在著相互聯(lián)系。分別對(duì)這些模式進(jìn)行定義并不能表示出模式之間的相關(guān)性。但是，當(dāng)前并沒(méi)有系統(tǒng)的方法或明確的原則說(shuō)明應(yīng)當(dāng)如何組合模式。假設(shè)在某問(wèn)題中，經(jīng)過(guò)問(wèn)題分析階段之后，我們認(rèn)為要組合使用分層模式、管道－過(guò)濾器模式和倉(cāng)庫(kù)模式。我們應(yīng)當(dāng)怎樣組織這 3種模式？哪種模式是基本的？它們之間有著怎樣的依賴(lài)關(guān)系？當(dāng)前的模式驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法并不能為這些問(wèn)題提供滿意的答案。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 域驅(qū)動(dòng)（ domaindriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 域驅(qū)動(dòng)（ domaindriven）的方法 主要用于產(chǎn)品線體系結(jié)構(gòu)設(shè)計(jì)和特定領(lǐng)域的軟件體系結(jié)構(gòu)設(shè)計(jì)。 缺點(diǎn)： （ 1）問(wèn)題領(lǐng)域分析在導(dǎo)出體系結(jié)構(gòu)抽象方面效果較差。 （ 2）解決方案領(lǐng)域分析不夠充分。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 域驅(qū)動(dòng)（ domaindriven）的方法 缺點(diǎn)： （ 1）問(wèn)題領(lǐng)域分析在導(dǎo)出體系結(jié)構(gòu)抽象方面效果較差。 一些領(lǐng)域驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法把領(lǐng)域解釋成問(wèn)題領(lǐng)域。例如， DSSA方法從非形式化的問(wèn)題聲明開(kāi)始，并從基于場(chǎng)景的領(lǐng)域模型導(dǎo)出體系結(jié)構(gòu)抽象。類(lèi)似于用例那樣，場(chǎng)景關(guān)注的也是問(wèn)題領(lǐng)域和系統(tǒng)的外部行為。因此，可以看出，這些從問(wèn)題領(lǐng)域?qū)С鲶w系結(jié)構(gòu)抽象的方法，如 DSSA方法，在導(dǎo)出正確的體系結(jié)構(gòu)抽象的問(wèn)題上，效果更差。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 域驅(qū)動(dòng)（ domaindriven）的方法 缺點(diǎn)： （ 2）解決方案領(lǐng)域分析不夠充分。 有些解決方案領(lǐng)域分析方法是獨(dú)立于軟件體系結(jié)構(gòu)設(shè)計(jì)的，它們?yōu)榇_認(rèn)潛在的可重用資源提供了系統(tǒng)的過(guò)程。正如前面描述的，在系統(tǒng)重用研究領(lǐng)域中，這一活動(dòng)被稱(chēng)作領(lǐng)域工程。和系統(tǒng)工程、問(wèn)題領(lǐng)域工程不同，解決方案領(lǐng)域分析所關(guān)心的內(nèi)容超出單個(gè)系統(tǒng)的范圍，它關(guān)心的是一個(gè)系統(tǒng)族或問(wèn)題領(lǐng)域，以確認(rèn)該解決方案領(lǐng)域的可重用資源。盡管解決方案領(lǐng)域分析提供了對(duì)整個(gè)領(lǐng)域建模的潛力，而且這種潛力對(duì)于導(dǎo)出領(lǐng)域體系結(jié)構(gòu)是必需的，但是，這并不足以驅(qū)動(dòng)體系結(jié)構(gòu)設(shè)計(jì)過(guò)程。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 域驅(qū)動(dòng)（ domaindriven）的方法 這有兩方面的原因。首先，解決方案領(lǐng)域分析并不是為軟件體系結(jié)構(gòu)設(shè)計(jì)而定義的，而是為實(shí)現(xiàn)軟件開(kāi)發(fā)等活動(dòng)中的系統(tǒng)資源重用而定義的。由于進(jìn)行解決方案領(lǐng)域分析的范圍可能非常廣，往往導(dǎo)致領(lǐng)域模型過(guò)于巨大，包括了一些對(duì)于構(gòu)造相關(guān)的軟件體系結(jié)構(gòu)而言并無(wú)必要的抽象。大型的領(lǐng)域模型將可能妨礙尋找體系結(jié)構(gòu)抽象。其次是解決方案領(lǐng)域的內(nèi)聚性可能不夠強(qiáng)，不夠穩(wěn)定，因而難以為體系結(jié)構(gòu)設(shè)計(jì)提供堅(jiān)實(shí)的基礎(chǔ)。在這些相關(guān)領(lǐng)域的概念上，人們還沒(méi)有取得共識(shí)，這些研究領(lǐng)域還有待于進(jìn)一步發(fā)展。顯然，很難提供一個(gè)比來(lái)自于解決方案領(lǐng)域還要好的體系結(jié)構(gòu)設(shè)計(jì)解決方案。這種情況下，全面的解決方案領(lǐng)域分析對(duì)于提供穩(wěn)定的抽象也可能是不夠充分的，因?yàn)榻鉀Q方案領(lǐng)域中的概念自身也存在著波動(dòng)。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 小結(jié) 本節(jié)定義了體系結(jié)構(gòu)設(shè)計(jì)的元模型，并使用這一模型分析、比較和評(píng)估了幾種體系結(jié)構(gòu)設(shè)計(jì)方法。這些方法被分類(lèi)為：工件驅(qū)動(dòng)的、用例驅(qū)動(dòng)的、模式驅(qū)動(dòng)的和領(lǐng)域驅(qū)動(dòng)的。 在工件驅(qū)動(dòng)的方法中，體系結(jié)構(gòu)抽象被表示為分組的工件，它們是從需求規(guī)格說(shuō)明導(dǎo)出的。 用例驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法從用例模型導(dǎo)出體系結(jié)構(gòu)抽象，用例模型表示了系統(tǒng)預(yù)期要實(shí)現(xiàn)的功能。 模式驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法試圖通過(guò)從去定義的模式庫(kù)中選擇體系結(jié)構(gòu)模式來(lái)開(kāi)發(fā)體系結(jié)構(gòu)。 領(lǐng)域驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法從領(lǐng)域模型導(dǎo)出體系結(jié)構(gòu)抽象。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 小結(jié) 每種方法都有不足之處，總的說(shuō)來(lái)，可以總結(jié)為如下幾點(diǎn)： （ 1）在規(guī)劃體系結(jié)構(gòu)設(shè)計(jì)階段所遇到的困難 在軟件開(kāi)發(fā)過(guò)程中，對(duì)體系結(jié)構(gòu)設(shè)計(jì)階段進(jìn)行規(guī)劃是一個(gè)兩難問(wèn)題。 一般來(lái)講，體系結(jié)構(gòu)的確定應(yīng)當(dāng)在分析和設(shè)計(jì)階段之前或之后完成。如果把這一過(guò)程放在分析和設(shè)計(jì)模型被確定之后，體系結(jié)構(gòu)的定義可以更加準(zhǔn)確，因?yàn)轶w系結(jié)構(gòu)的邊界將受到影響。但是，這可能會(huì)帶來(lái)項(xiàng)目的不可管理性，因?yàn)轫?xiàng)目的許多開(kāi)發(fā)過(guò)程將無(wú)法得到體系結(jié)構(gòu)的指導(dǎo)。 另一方面，如果把這一過(guò)程放在分析和設(shè)計(jì)模型被確定之前，又會(huì)帶來(lái)其他問(wèn)題。因?yàn)檫@時(shí)對(duì)于分析和設(shè)計(jì)模型沒(méi)有足夠的知識(shí)，難以確定體系結(jié)構(gòu)的適當(dāng)邊界。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 小結(jié) （ 2）客戶需求不是體系結(jié)構(gòu)抽象的穩(wěn)固基礎(chǔ) 對(duì)于要開(kāi)發(fā)的軟件系統(tǒng)，客戶需求不同于體系結(jié)構(gòu)設(shè)想?？蛻粜枨筇峁┑氖菍?duì)系統(tǒng)中問(wèn)題的設(shè)想，而體系結(jié)構(gòu)的目標(biāo)是提供能用來(lái)實(shí)現(xiàn)系統(tǒng)的解決方案的設(shè)想。這二者之間差異巨大，從客戶需求并不能顯而易見(jiàn)地導(dǎo)出體系結(jié)構(gòu)抽象。 除此之外，需求自身也可能被不正確的描述，既有可能提出過(guò)度要求，也有可能要求不足。 因此，有時(shí)采用客戶需求導(dǎo)出體系結(jié)構(gòu)并不可取。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 小結(jié) （ 3）難以適度控制領(lǐng)域模型 領(lǐng)域驅(qū)動(dòng)的方法和用例驅(qū)動(dòng)的方法在構(gòu)造軟件體系結(jié)構(gòu)時(shí)都用到了領(lǐng)域模型。不受控制的領(lǐng)域工程可能導(dǎo)致領(lǐng)域模型缺乏實(shí)際使用時(shí)所需要的恰當(dāng)細(xì)節(jié)。 這一問(wèn)題的一個(gè)極端情況是領(lǐng)域模型過(guò)于龐大，包括了許多冗余的抽象；另一個(gè)極端是領(lǐng)域模型過(guò)小，缺少基本的體系結(jié)構(gòu)抽象