Kruten的模型描述軟件體系結(jié)構(gòu)演示文稿現(xiàn)在是1頁\一共有40頁\編輯于星期一Kruten的模型描述軟件體系結(jié)構(gòu)現(xiàn)在是2頁\一共有40頁\編輯于星期一Kruchten的4+1模型描述軟件體系結(jié)構(gòu)

本章參考

PhilippeKruchten——《ArchitecturalBlueprints—The“4+1”

ViewModelofSoftwareArchitecture》現(xiàn)在是3頁\一共有40頁\編輯于星期一假定你是ModuleDesigner你最近加盟一家公司，并被安排在一個新項目的開發(fā)組中。雖然你富有經(jīng)驗，但是對此項目所涉及的領(lǐng)域還是一個新手。系統(tǒng)的高層體系結(jié)構(gòu)設(shè)計已經(jīng)完成。你的老板（項目經(jīng)理）讓你預(yù)計你將要完成的幾個模塊的開發(fā)時間。你怎么辦？現(xiàn)在是4頁\一共有40頁\編輯于星期一假定你是ModuleDesigner你來開發(fā)A2和A3，怎么開始？現(xiàn)在是5頁\一共有40頁\編輯于星期一假定你是Consultant(顧問)你是一個請來的顧問，對一個體系結(jié)構(gòu)設(shè)計進行評估。Modifiability和Performance是重要的體系結(jié)構(gòu)質(zhì)量因素。你會詢問什么樣的信息？現(xiàn)在是6頁\一共有40頁\編輯于星期一假定你是Consultant(顧問)面對這樣的圖，你會有什么反應(yīng)？現(xiàn)在是7頁\一共有40頁\編輯于星期一假定你是Consultant(顧問)面對這樣的圖，你會有什么反應(yīng)？現(xiàn)在是8頁\一共有40頁\編輯于星期一體系結(jié)構(gòu)描述方法軟件開發(fā)過程中各種角色之間交流設(shè)計思想的媒介進行上層分析的基礎(chǔ)。此基礎(chǔ)上可以驗證體系結(jié)構(gòu)設(shè)計方案，精煉或改變必要的方案讓別人理解系統(tǒng)的第一手資料現(xiàn)在是9頁\一共有40頁\編輯于星期一與ModuleDesigner交流基本想法是什么？我該做什么(如，實現(xiàn)哪些需求)？我該在哪做(如，這項功能實現(xiàn)在哪里)？我和誰交互？接口是什么？有什么可以重用的代碼？必須遵從什么約定(質(zhì)量目標、舊體系/接口、預(yù)算等)？有哪些硬性規(guī)定(設(shè)計、接口、約束等)？現(xiàn)在是10頁\一共有40頁\編輯于星期一與顧問交流體系結(jié)構(gòu)的必要需求(drivingrequirement)是什么(如，performance,availability,security,modifiability,

interoperability)？各種體系結(jié)構(gòu)視圖是如何描述的？抽象出來什么？功能怎樣分解？功能怎樣分配？使用什么硬件以及軟件怎樣布置在硬件上？采用了哪些體系結(jié)構(gòu)風(fēng)格？現(xiàn)在是11頁\一共有40頁\編輯于星期一這是什么？現(xiàn)在是12頁\一共有40頁\編輯于星期一上圖的毛病很多事情沒有說：組件類型連接件類型圓圈和箭頭代表什么？這種布局的意義是什么？為什么CP要放在上層？只畫出方框和線條不是體系結(jié)構(gòu)，只是體系結(jié)構(gòu)的開始現(xiàn)在是13頁\一共有40頁\編輯于星期一好的體系結(jié)構(gòu)描述的必要元素需求陳述商業(yè)環(huán)境、產(chǎn)品的背景、領(lǐng)域描述環(huán)境必須和什么系統(tǒng)交互、外部接口使用體系結(jié)構(gòu)圖用恰當(dāng)?shù)木€框簡潔的說明現(xiàn)在是14頁\一共有40頁\編輯于星期一好的體系結(jié)構(gòu)描述的必要元素考慮實現(xiàn)時的限制但是僅在它們能影響體系結(jié)構(gòu)設(shè)計的范圍內(nèi)被限定的下層結(jié)構(gòu)、處理器需求通常包含其他結(jié)構(gòu)圖體系結(jié)構(gòu)設(shè)計的原理它怎樣去符合需求與約束其他的設(shè)計現(xiàn)在是15頁\一共有40頁\編輯于星期一其他方面風(fēng)格/產(chǎn)品線問題設(shè)計可變的尺度體系結(jié)構(gòu)的那個方面必須不被改變？管理問題暗含開發(fā)團隊的組織結(jié)構(gòu)體系結(jié)構(gòu)評審情況其他設(shè)計問題代碼重用、標準的運用風(fēng)險分析運作、管理和維護現(xiàn)在是16頁\一共有40頁\編輯于星期一好描述線和框有不同的形狀/顏色，并有圖例說明用表格總結(jié)方案選擇等等各種問題圖并不試圖去表達很多信息：把信息分散到需要表達它的各個視圖中每個體系結(jié)構(gòu)視圖必須在一頁內(nèi)完成清晰地區(qū)分出哪些是體系結(jié)構(gòu)視圖，哪些不是現(xiàn)在是17頁\一共有40頁\編輯于星期一壞描述所有的線看起來都一樣箭頭不代表任何涵義箭頭代表很多涵義實現(xiàn)與文檔沖突沒有圖例太多的必要需求現(xiàn)在是18頁\一共有40頁\編輯于星期一視圖系統(tǒng)需要多種視圖來描述其中的一小部分是描述體系結(jié)構(gòu)的運行時視圖/動態(tài)視圖(組件和連接件)在高層分解成組件和連接件代碼視圖模塊關(guān)聯(lián)和依賴使用/調(diào)用/和…共享數(shù)據(jù)文件和目錄、工程和編譯文件、版本控制物理視圖把計算單元分配到各個進程或處理器現(xiàn)在是19頁\一共有40頁\編輯于星期一閱讀PhilippeKruchten,ArchitecturalBlueprints—The“4+1”ViewModelofSoftwareArchitecture,IEEESoftware12(6),1995,pp.42-50Release6ASegment/DesignSpecificationfortheECSProject,Section4.4.NASAReport305-CD-600-001,pages4-160-185.March2001/waisdata/toc/cd30560001toc.html現(xiàn)在是20頁\一共有40頁\編輯于星期一3.1“4十1”模型

Rational公司的PhilippeKruchten在1995年提出了用于體系結(jié)構(gòu)描述的“4十l”模型。該模型建立在體系結(jié)構(gòu)的Perry＆Wolf定義和BerryBoehm定義的基礎(chǔ)上。該模型采用多視圖模型的方法描述軟件體系結(jié)構(gòu)。為了最終能夠處理富于挑戰(zhàn)性的、大規(guī)模的軟件系統(tǒng)，該模型由5個視圖構(gòu)成。

u邏輯視圖

當(dāng)采用面向?qū)ο蟮脑O(shè)計方法時，邏輯視圖即是對象模型。

u過程視圖

描述系統(tǒng)的并發(fā)和同步方面的設(shè)計。

u物理視圖

描述軟件到硬件之間的映射關(guān)系，反映系統(tǒng)在分布方面的設(shè)計。

u

開發(fā)視圖

描述軟件在開發(fā)環(huán)境下的靜態(tài)組織。現(xiàn)在是21頁\一共有40頁\編輯于星期一對體系結(jié)構(gòu)進行的描述是圍繞著以上4個視圖展開的。然后，通過選擇出的一些用例對體系結(jié)構(gòu)加以說明。這些用例被稱作場景(scenarios)，它們構(gòu)成了第5個視圖。實際上，體系結(jié)構(gòu)在某種程度上是由場景演化而來的。

現(xiàn)在是22頁\一共有40頁\編輯于星期一體系結(jié)構(gòu)的概念在每個視圖里面都可以獨立應(yīng)用。這就是說，可以在每個視圖里面定義體系結(jié)構(gòu)的各種組成元素，如構(gòu)件、連接件等。對于不同的視圖，還可以選擇不同的體系結(jié)構(gòu)風(fēng)格，因此在同一個系統(tǒng)結(jié)構(gòu)中可以使用多種風(fēng)格。此外，在每一種視圖里，我們使用該視圖特定的符號。這避免了符號用法和意義的混亂。“4十1”視圖模型是一個十分通用的模型：可以便用其他的符號表示法，也可以使用其他的設(shè)計方法，尤其是邏輯視圖和過程視圖的分解。

現(xiàn)在是23頁\一共有40頁\編輯于星期一“4十1”模型實際上使得有不同需求的人員能夠得到他們對于軟件體系結(jié)構(gòu)想要了解的東西。系統(tǒng)工程師先從物理視圖，然后從過程視圖靠近體系結(jié)構(gòu)。最終使用者、客戶、數(shù)據(jù)專家從邏輯視圖看體系結(jié)構(gòu)；項目經(jīng)理、軟件配置人員從開發(fā)視圖看體系結(jié)構(gòu)。

現(xiàn)在是24頁\一共有40頁\編輯于星期一要指出的是，不是所有的軟件體系結(jié)構(gòu)都需要完整的“4十1”視圖。沒有用的視圖在體系結(jié)構(gòu)描述中可以被省略，例如對于非常小的系統(tǒng)，邏輯視圖和開發(fā)視圖有可能非常相似以至于沒有必要把它們分開描述。場景視圖在各種環(huán)境下都是有用的。

現(xiàn)在是25頁\一共有40頁\編輯于星期一3.2邏輯視圖的體系結(jié)構(gòu)：面向?qū)ο蟮姆纸?/p>

邏輯視圖主要支持功能需求——系統(tǒng)應(yīng)當(dāng)向用戶提供什么樣的服務(wù)。從問題域出發(fā)，采用面向?qū)ο蟮姆椒ǎ凑粘橄蟆⒎庋b、繼承的原則，進行分解，得到代表著系統(tǒng)的關(guān)鍵抽象表示的集合。這些抽象表示的具體形式就是對象和對象的類。這種分級不僅是為了功能分析，而且擔(dān)負著在系統(tǒng)的各部分中確定公共機制和設(shè)計元素的作用。使用Rational／Booch方法，通過類圖(classdiagram)和類模板(classtemplate)來表示邏輯體系結(jié)構(gòu)。類圖顯示了類的集合和它們的邏輯關(guān)系:關(guān)聯(lián)(association)、組合

(composition)、使用(usage)、繼承(inheritance)等。類模板則著眼于每個類的個體，強調(diào)類的主要操作，并確定對象的關(guān)鍵特征。當(dāng)十分需要定義一個對象的內(nèi)部行為時，要使用狀態(tài)轉(zhuǎn)換圖(statetransitiondiagram)，或者是狀態(tài)表(statechart)。相關(guān)類的集合可以歸到一起，稱作類的種屬(classcategory)。

現(xiàn)在是26頁\一共有40頁\編輯于星期一3.2.1邏輯視圖的符號表示法

邏輯體系結(jié)構(gòu)的符號表示法(見圖)，是從Booch方法派生而來的。它被極大地簡化了，尤其大量簡化了在這個設(shè)計階段作用不大的各種修飾，只考慮對于體系結(jié)構(gòu)有重要意義的元素在設(shè)計工具上，可以使用RationalRose等UML建模工具。公共的機制和服務(wù)在類設(shè)施

(classutilities)中定義。現(xiàn)在是27頁\一共有40頁\編輯于星期一3.2.2邏輯視圖的風(fēng)格邏輯視圖也可以采用面向?qū)ο蟮娘L(fēng)格。邏輯視圖設(shè)計的主要準則是，要設(shè)法在整個系統(tǒng)中保持一個單一的、連貫的對象模型，避免類和相關(guān)機制出現(xiàn)按照場地或處理器過早的分化。

3.2.3邏輯視圖的例子

原文中顯示了一個專用自動交換分機的例子。專用自動交換分機用于在通信終端之間建立連接。通信終端可能是電話機、中繼線(連接到中心室的線路)、專用線(專用自動交換分機和一般的交換分機之間的線路)、數(shù)據(jù)線、ISDN線等。不同的線路需要不同的線路接口卡的支持。線路控制器對象負責(zé)從線路接口卡接受信號，以及向它發(fā)送信號，并完成信號和一系列的事件(如開始、結(jié)束、計數(shù)等)之間的轉(zhuǎn)換。控制器還必須受到嚴格的實時要求的約束。為了適應(yīng)不同的接口，這個類有許多的子類。終端對象負責(zé)維護終端的狀態(tài)，并代表所在的線路提供通信服務(wù)。對話對象代表在一個對話中涉及的終端的集合。對話對象使用轉(zhuǎn)換目務(wù)(邏輯地址和物理地址之間的映射、路由等)和連接服務(wù)建立兩個終端之間的語音連接。現(xiàn)在是28頁\一共有40頁\編輯于星期一3.3過程視圖的體系結(jié)構(gòu)：過程分解

過程體系結(jié)構(gòu)考慮的是一些非功能性的需求，諸如性能、可用性等。它所要面對的問題有并發(fā)，分布，系統(tǒng)的完整性，容錯能力等。它還要考慮怎樣把過程體系結(jié)構(gòu)與邏輯視圖體系結(jié)構(gòu)的要點相適應(yīng)——對某個對象的某個操作實際上是在哪個控制線程上發(fā)生的。可以把過程體系結(jié)構(gòu)分為幾個抽象層次來描述，每個層次考慮不同的方面。在最高層次上，過程體系結(jié)構(gòu)可以被視為是一個邏輯網(wǎng)絡(luò)的集合。每個獨立執(zhí)行的邏輯網(wǎng)絡(luò)都是由通信程序(即“過程”)構(gòu)成的。這些邏輯網(wǎng)絡(luò)分布在一個通過LAN或WAN連接起來的硬件資源集合上。多個邏輯網(wǎng)絡(luò)可能同時存在，并共享同樣的物理資源。例如，邏輯網(wǎng)絡(luò)的概念可用于區(qū)分在線處理系統(tǒng)和離線處理系統(tǒng)。

現(xiàn)在是29頁\一共有40頁\編輯于星期一3.3過程視圖的體系結(jié)構(gòu)：過程分解

軟件被分為獨立的任務(wù)的集合。每個任務(wù)是一個獨立的控制線程，可以在一個處理節(jié)點上獨立單獨調(diào)度。因此可以將任務(wù)分為主任務(wù)和輔任務(wù)。主任務(wù)是需要單獨解決的體系結(jié)構(gòu)元素。輔任務(wù)是由于實現(xiàn)原因而在本地加入的附加任務(wù)(緩沖，超時，等等)，例如可以將它們實現(xiàn)為輕量級的線程。主任務(wù)通過一套完善定義的任務(wù)間通信機制進行通信：同步的或異步的基于消息的通信服務(wù)、遠程過程調(diào)用、時間廣播等。不應(yīng)當(dāng)假設(shè)通信中的主任務(wù)處于同一個過程中或處在同一個處理節(jié)點上。輔任務(wù)的通信可以采用共享內(nèi)存的方式或其他雙方約定的方式。

基于過程體系結(jié)構(gòu)設(shè)計圖，可以估計出消息流和過程負荷。

現(xiàn)在是30頁\一共有40頁\編輯于星期一3.3.1過程視圖的符號表示法

在輔助工具的選擇上，可以考慮使用TRW提供的UNAS(UniversalNetworkArchitectureServices)產(chǎn)品。它可用于把各種過程和任務(wù)構(gòu)建并實現(xiàn)為過程的邏輯網(wǎng)絡(luò)。UNAS里面包含的一個工具SALE(SoftwareArchitectureLifecycleEnvironment)支持這樣的符號表示法。SALE允許過程體系結(jié)構(gòu)的圖形化描述，包括對可能的任務(wù)間通信路徑的規(guī)格說明。然后，從這種規(guī)格說明可以自動生成相應(yīng)的Ada或C十十語言源代碼。

現(xiàn)在是31頁\一共有40頁\編輯于星期一3.2.2過程視圖的風(fēng)格

有多種風(fēng)格適合過程體系結(jié)構(gòu)。例如管道和過濾器、客戶／服務(wù)器及其變體(多客戶／單服務(wù)器，多客戶／多服務(wù)器)等。

3.2.3過程視圖的例子

現(xiàn)在是32頁\一共有40頁\編輯于星期一3.4開發(fā)視圖的體系結(jié)構(gòu)：子系統(tǒng)分解

開發(fā)視圖，關(guān)注的是在軟件開發(fā)環(huán)境中軟件模塊的實際組織。軟件被打包成可以由單個或少量程序員開發(fā)的各種小的部分：程序庫或子系統(tǒng)。子系統(tǒng)被組織成層次化的體系，每一層為上一層提供一個嚴密的、明確定義的接口。系統(tǒng)的開發(fā)體系結(jié)構(gòu)用模塊圖和子系統(tǒng)圖來表示，在圖中可以顯示出“導(dǎo)入”和“導(dǎo)出”關(guān)系。完整的開發(fā)體系結(jié)構(gòu)只有在軟件系統(tǒng)的所有元素被識別出來之后才能被描述。控制開發(fā)體系結(jié)構(gòu)的原則是：分割、編組、可視。開發(fā)體系結(jié)構(gòu)主要考慮的是內(nèi)部需求，這些需求目的是要使開發(fā)相關(guān)的活動更易于進行，如軟件管理、軟件復(fù)用、開發(fā)工具集所造成的約束、編程語言等。開發(fā)體系結(jié)構(gòu)是許多開發(fā)話動的基礎(chǔ)，包括需求配置、團隊組織和工作分配、成本估算和成本規(guī)劃、項目進度監(jiān)控、軟件可重用性和可移植性分析、軟件安全分析等。它是建立軟件產(chǎn)品線的基礎(chǔ)。

現(xiàn)在是33頁\一共有40頁\編輯于星期一3.4.1開發(fā)視圖的符號表示法與前面類似，開發(fā)視圖的符號表示法采用Booch表示法的變體，并且只考慮對于體系結(jié)構(gòu)有重要意義的元素，如圖所示。在RationnalRose中，可以繪制模塊層和子系統(tǒng)層的開發(fā)體系結(jié)構(gòu)圖，還可以在反向工程中從已經(jīng)開發(fā)的源代碼(Ada或C十十)得出系統(tǒng)的開發(fā)體系結(jié)構(gòu)圖。

現(xiàn)在是34頁\一共有40頁\編輯于星期一3.4.2開發(fā)視圖的風(fēng)格

對于開發(fā)視圖，我們建議采用分層風(fēng)格，定義4—6層的子系統(tǒng)。每一層都有明確責(zé)任。設(shè)計規(guī)則是，某一層的子系統(tǒng)只能依賴于本層或其下層的子系統(tǒng)。這樣做的目模塊間相互依賴而構(gòu)成的復(fù)雜網(wǎng)絡(luò)最小化，并使得系統(tǒng)可以采用逐層的策略完成釋放。現(xiàn)在是35頁\一共有40頁\編輯于星期一3.4.3開發(fā)視圖的例子

下圖用5個層次表示了航空交通管制系統(tǒng)產(chǎn)品線的開發(fā)組織。此開發(fā)體系結(jié)構(gòu)圖3-4(b)中描述的邏輯體系結(jié)構(gòu)相對應(yīng)的。現(xiàn)在是36頁\一共有40頁\編輯于星期一3.5物理視圖的體系結(jié)構(gòu)：從軟件到硬件的映射

物理體系結(jié)構(gòu)主要考慮的是非功能性的系統(tǒng)需求，如系統(tǒng)的可用性、可靠性(容錯性)、性能(信息吞吐量)和可擴展性。軟件系統(tǒng)在計算機網(wǎng)絡(luò)的各個處理節(jié)點上運行。各種被確定出的元素——網(wǎng)絡(luò)、過程、任務(wù)和對象——需要映射到