第2章軟件體系結構建模南京信息工程大學計算機與軟件學院教學目的與要求（1）了解表示軟件體系結構的五種模型；（2）熟悉“4+1”視圖模型；（3）掌握軟件體系結構的核心模型；（4）理解軟件體系結構的生命周期模型；（5）初步了解軟件體系結構抽象模型。2.1軟件體系結構建模概述2.2“4+1”視圖模型2.3軟件體系結構的核心模型2.4軟件體系結構的生命周期模型2.5軟件體系結構抽象模型主要內容教學重點與難點（1）邏輯視圖和開發視圖（2）軟件體系結構的核心模型（3）軟件體系結構的生命周期模型2.1軟件體系結構建模概述軟件體系結構建模的種類

1.結構模型2.框架模型3.動態模型4.過程模型5.功能模型1.結構模型這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連接件和其他概念來刻畫結構，并力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質等。研究結構模型的核心是體系結構描述語言。2.框架模型框架模型與結構模型類似，但它不太側重描述結構的細節而更側重于整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。3.動態模型動態模型是對結構或框架模型的補充，研究系統的“大顆粒”的行為性質。例如，描述系統的重新配置或演化。動態可以指系統總體結構的配置、建立或拆除通信通道或計算的過程。4.過程模型過程模型研究構造系統的步驟和過程。結構是遵循某些過程腳本的結果。5.功能模型功能模型認為體系結構是由一組功能構件按層次組成，下層向上層提供服務。功能模型可以看作是一種特殊的框架模型。2.2“4+1”視圖模型2.2.1“4+1”模型概述

Kruchten在1995年提出了“4+1”的視圖模型。“4+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、開發視圖和場景視圖來描述軟件體系結構。每一個視圖只關心系統的一個側面，5個視圖結合在一起才能反映系統的軟件體系結構的全部內容。2.2“4+1”視圖模型2.2.1“4+1”模型概述（續）邏輯視圖進程視圖開發視圖物理視圖最終用戶：功能需求場景編程人員：軟件管理系統集成人員：性能可擴充性、吞吐量等系統工程人員：系統拓撲、安裝、通信等2.2.2邏輯視圖(1)邏輯視圖主要支持系統的功能需求，即系統提供給最終用戶的服務。在邏輯視圖中，系統分解成一系列的功能抽象，這些抽象主要來自問題領域。這種分解不但可以用來進行功能分析，而且可用作標識在整個系統的各個不同部分的通用機制和設計元素。在面向對象技術中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。2.2.2邏輯視圖(2)可以從Booch標記法中導出邏輯視圖的標記法，只是從體系結構級的范疇來考慮這些符號，用RationalRose進行體系結構設計。構件實例繼承使用包含，聚集關聯類層次參數化類類服務類連接件邏輯視圖中使用的標記符號

2.2.2邏輯視圖(3)邏輯視圖中使用的風格為面向對象的風格，邏輯視圖設計中要注意的主要問題是要保持一個單一的、內聚的對象模型貫穿整個系統。ACS系統的邏輯視圖線路控制器：譯碼并把所有符號加入到線路接口卡中；終端：保持終端的狀態，代表本條線路的利益參與協商服務；會話：代表一組參與會話的終端，使用轉換服務和連接服務在終端之間建立語音路徑。2.2.2邏輯視圖(4)對于規模更大的系統來說，體系結構級中包含數十甚至數百個類。空中交通管制系統的一級類圖2.2.3開發視圖(1)開發視圖也稱模塊視圖，主要側重于軟件模塊的組織和管理。開發視圖要考慮軟件內部的需求，如軟件開發的容易性、軟件的重用和軟件的通用性，要充分考慮由于具體開發工具的不同而帶來的局限性。開發視圖通過系統輸入輸出關系的模型圖和子系統圖來描述。2.2.3開發視圖(2)與邏輯視圖一樣，可以使用Booch標記法中某些符號來表示開發視圖。開發視圖中使用的標記符號

2.2.3開發視圖(3)在開發視圖中，最好采用4-6層子系統，而且每個子系統僅僅能與同層或更低層的子系統通訊，這樣可以使每個層次的接口既完備又精練，避免了各個模塊之間很復雜的依賴關系。設計時要充分考慮，對于各個層次，層次越低，通用性越強，這樣，可以保證應用程序的需求發生改變時，所做的改動最小。開發視圖所用的風格通常是層次結構風格。2.2.3開發視圖(4)空中交通管制系統的五層結構2.2.4進程視圖(1)進程視圖側重于系統的運行特性，主要關注一些非功能性的需求。進程視圖強調并發性、分布性、系統集成性和容錯能力，以及從邏輯視圖中的主要抽象如何適合進程結構。它也定義邏輯視圖中的各個類的操作具體是在哪一個線程中被執行的。進程視圖可以描述成多層抽象，每個級別分別關注不同的方面。在最高層抽象中，進程結構可以看作是構成一個執行單元的一組任務。它可看成一系列獨立的，通過邏輯網絡相互通信的程序。它們是分布的，通過總線或局域網、廣域網等硬件資源連接起來。2.2.4進程視圖(2)通過擴展Booch對Ada任務的表示法，來表示進程視圖。進程視圖中使用的標記符號

2.2.4進程視圖(3)所有終端均由同一個終端進程進行處理，由其輸入隊列中的消息驅動。控制器對象在組成控制器進程的三個任務之一中執行，慢循環周期（200ms）任務掃描所有掛起終端，把任何一個活動的終端置入快循環周期（10ms）任務的掃描列表，快循環周期任務檢測任何顯著的狀態改變，并把改變的狀態傳遞給主控制器任務，主控制器任務解釋改變，通過消息與相應的終端進行通信。ACS系統的進程視圖（局部）

2.2.5物理視圖(1)物理視圖主要考慮如何把軟件映射到硬件上，它通常要考慮到系統性能、規模、可靠性等。解決系統拓撲結構、系統安裝、通訊等問題。當軟件運行于不同的節點上時，各視圖中的構件都直接或間接地對應于系統的不同節點上。因此，從軟件到節點的映射要有較高的靈活性，當環境改變時，對系統其他視圖的影響最小。2.2.5物理視圖(2)大型系統的物理視圖可能會變得十分混亂，因此可以與進程視圖的映射一道，以多種形式出現，也可單獨出現。物理視圖中使用的標記符號

2.2.5物理視圖(3)ACS系統的物理視圖2.2.5物理視圖(4)具有進程分配的小型ACS系統的物理視圖2.2.5物理視圖(5)具有進程分配的大型ACS系統的物理視圖2.2.6場景(1)場景可以看作是那些重要系統活動的抽象，它使四個視圖有機聯系起來，從某種意義上說場景是最重要的需求抽象。在開發體系結構時，它可以幫助設計者找到體系結構的構件和它們之間的作用關系。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的。場景可以用文本表示，也可以用圖形表示。2.2.6場景(2)本地呼叫場景的一個原型本節小結邏輯視圖和開發視圖描述系統的靜態結構，而進程視圖和物理視圖描述系統的動態結構。對于不同的軟件系統來說，側重的角度也有所不同。例如，對于管理信息系統來說，比較側重于從邏輯視圖和開發視圖來描述系統，而對于實時控制系統來說，則比較注重于從進程視圖和物理視圖來描述系統。2.3軟件體系結構的核心模型軟件體系結構的核心模型

構件：具有某種功能的可重用的軟件模板單元，表示了系統中主要的計算元素和數據存儲。構件有兩種：復合構件和原子構件。連接件：表示構件之間的交互。配置：表示構件和連接件的拓撲邏輯和約束。端口：組成構件的接口角色：組成連接件的接口2.4軟件體系結構的生命周期模型2.4.1軟件過程需求分析建立體系結構測試實現設計1.需求分析階段需求分析階段的任務是根據需求，決定系統的功能。需求是指用戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望，需求分析過程主要是獲取用戶需求，確定系統中所要用到的構件。體系結構需求：需求獲取、生成類圖、對類分組、把類打包成構件、需求評審。（注意：軟件質量屬性）2.建立軟件體系結構階段在這個階段，體系結構設計師主要從結構的角度對整個系統進行分析，選擇恰當的構件、構件間的相互作用關系以及對它們的約束，最后形成一個系統框架以滿足用戶需求，為設計奠定基礎。

(1)選擇體系結構風格

(2)映射關鍵構件：中間結構

(3)結構細化：體系結構說明書3.設計階段設計階段主要是對系統進行模塊化并決定描述各個構件間的詳細接口、算法和數據類型的選定，對上支持建立體系結構階段形成的框架，對下提供實現基礎。一旦設計了軟件體系結構，必須邀請獨立于系統開發的外部人員對體系結構進行評審。4.實現階段將設計階段設計的算法及數據類型進行程序語言表示，滿足設計體系結構和需求分析的要求，從而得到滿足設計需求的目標系統。（CBSD）5.測試階段包括單個構件的功能性測試和被組裝應用的整體功能和性能測試。2.4.2軟件體系結構生命周期模型1.非形式化描述2.規范描述和分析3.求精及其驗證4.實施5.演化和擴展6.提供、評價和度量7.終結1.軟件體系結構的非形式化描述一種軟件體系結構在其產生時，其思想通常是很簡單的，并常常由軟件設計師用非形式化的自然語言表示概念、原則。盡管對軟件體系結構的描述常用自然語言，但是該階段的工作卻是創造性和開拓性的。2.軟件體系結構的規范描述和分析通過運用合適的形式化數學理論模型對第1階段的體系結構的非形式化描述進行規范定義，從而得到軟件體系結構的形式化規范描述，以使軟件體系結構的描述精確、無歧義，并進而分析軟件體系結構的性質，如無死鎖性、安全性、活性等。分析軟件體系結構的性質有利于在系統設計時選擇合適的軟件體系結構，從而對軟件體系結構的選擇起指導作用，避免盲目選擇。3.軟件體系結構的求精及其驗證完成對已設計好的軟件體系結構進行驗證和求精。抽象是人們在處理復雜問題和對象時必不可少的思維方式，軟件體系結構也不例外。但是過高的抽象卻使軟件體系結構難以真正在系統設計中實施。因而，如果軟件體系結構的抽象粒度過大，就需要對體系結構進行求精、細化，直至能夠在系統設計中實施為止。在軟件體系結構的每一步求精過程中，需要對不同抽象層次的軟件體系結構進行驗證，以判斷較具體的軟件體系結構是否與較抽象的軟件體系結構的語義一致，并能實現抽象的軟件體系結構。4.軟件體系結構的實施將求精后的軟件體系結構實施于系統的設計中，并將軟件體系結構的構件和連接件等有機地組織在一起，形成系統設計的框架，以便據此實施于軟件設計和構造中。5.軟件體系結構的演化和擴展在實施軟件體系結構時，根據系統的需求，常常是非功能性的需求，如性能、容錯、安全性、互操作性、自適應性等非功能性質影響軟件體系結構的擴展和改動，這稱為軟件體系結構的演化。由于對軟件體系結構的演化常常由非功能性質的非形式化需求描述引起，因而需要重復第1步，如果由于功能和非功能性質對以前的軟件體系結構進行演化，就要涉及軟件體系結構的理解，需要進行軟件體系結構的逆向工程和再造工程。6.軟件體系結構的提供、評價和度量軟件體系結構的提供、評價和度量階段通過將軟件體系結構實施于系統設計后，根據系統實際的運行情況，對軟件體系結構進行定性的評價和定量的度量，以利于對軟件體系結構的重用，并取得經驗教訓。7.軟件體系結構的終結如果一個軟件系統的軟件體系結構進行多次演化和修改，軟件體系結構已變得難以理解，更重要的是不能達到系統設計的要求，不能適應系統的發展。這時，對該軟件體系結構的再造工程就不必要，也不可行，說明該軟件體系結構已經過時，應該擯棄，