1、 上次課重點,廣義軟件設計的含義。 2. 廣義軟件設計過程的兩個動作及其含義。 3. 軟件設計（如非特別說明，均指一般意義上的）的方法分類。 4. 軟件設計活動步驟。 5. 軟件設計要素（* 正確性 * 健壯性 * 靈活性 * 可重用性 * 高效性）。 6. 軟件體系結構的概念。,課 程 內 容, 軟件體系結構概論 軟件體系結構建模 軟件體系結構風格 軟件體系結構描述 動態(tài)軟件體系結構 Web服務體系結構 基于體系結構的軟件開發(fā) 軟件體系結構的分析與測試 軟件體系結構評估 軟件產品線體系結構, 軟件體系結構建模的種類,第2章 軟件體系結構建模,2.1 軟件體系結構建模概述, 結構模型 框架模型

2、 動態(tài)模型 過程模型 功能模型, 軟件體系結構建模的種類,第2章 軟件體系結構建模,2.1 軟件體系結構建模概述, 結構模型 這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連接件和其他概念來刻畫結構，并力圖通過結構來反映系統(tǒng)的重要語義內容，包括系統(tǒng)的配置、約束、隱含的假設條件、風格、性質等。 研究結構模型的核心是體系結構描述語言。, 軟件體系結構建模的種類,第2章 軟件體系結構建模,2.1 軟件體系結構建模概述, 框架模型 框架模型與結構模型類似，但它不太側重描述結構的細節(jié)而更側重于整體的結構。 框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。, 軟件體系結構建模

3、的種類,第2章 軟件體系結構建模,2.1 軟件體系結構建模概述, 動態(tài)模型 動態(tài)模型是對結構或框架模型的補充，研究系統(tǒng)的“大顆?！钡男袨樾再|。例如，描述系統(tǒng)的重新配置或演化。動態(tài)可以指系統(tǒng)總體結構的配置、建立或拆除通信通道或計算的過程。, 軟件體系結構建模的種類,第2章 軟件體系結構建模,2.1 軟件體系結構建模概述, 過程模型 過程模型研究構造系統(tǒng)的步驟和過程。 結構是遵循某些過程腳本的結果。, 軟件體系結構建模的種類,第2章 軟件體系結構建模,2.1 軟件體系結構建模概述, 功能模型 功能模型認為體系結構是由一組功能構件按層次組成，下層向上層提供服務。 功能模型可以看作是一種特殊的框架模型

4、。, “4+1”模型概述,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,Kruchten在1995年提出了“4+1”的視圖模型。 “4+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、開發(fā)視圖和場景視圖來描述軟件體系結構。 每一個視圖只關心系統(tǒng)的一個側面，5個視圖結合在一起才能反映系統(tǒng)的軟件體系結構的全部內容。, “4+1”模型概述,第2章 軟件體系結構建模,2.2 “4+1”視圖模型, 邏輯視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,邏輯視圖主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務。在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象，這些抽象主要來自問題

5、領域。這種分解不但可以用來進行功能分析，而且可用作標識在整個系統(tǒng)的各個不同部分的通用機制和設計元素。 在面向對象技術中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。, 邏輯視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,可以從Booch標記法中導出邏輯視圖的標記法，只是從體系結構級的范疇來考慮這些符號，用Rational Rose進行體系結構設計。, 邏輯視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,邏輯視圖中使用的風格為面向對象的風格，邏輯視圖設計中要注意的主要問題是要保持一個單一的、內聚的對象模型貫穿整個系統(tǒng)。, 邏輯視圖,第2章 軟

6、件體系結構建模,2.2 “4+1”視圖模型,對于規(guī)模更大的系統(tǒng)來說，體系結構級中包含數十甚至數百個類 。, 開發(fā)視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,開發(fā)視圖也稱模塊視圖，主要側重于軟件模塊的組織和管理。 開發(fā)視圖要考慮軟件內部的需求，如軟件開發(fā)的容易性、軟件的重用和軟件的通用性，要充分考慮由于具體開發(fā)工具的不同而帶來的局限性。 開發(fā)視圖通過系統(tǒng)輸入輸出關系的模型圖和子系統(tǒng)圖來描述。, 開發(fā)視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,與邏輯視圖一樣，可以使用Booch標記法中某些符號來表示開發(fā)視圖。, 開發(fā)視圖,第2章 軟件體系結構建模,2.2 “4+1”

7、視圖模型,在開發(fā)視圖中，最好采用4-6層子系統(tǒng)，而且每個子系統(tǒng)僅僅能與同層或更低層的子系統(tǒng)通訊，這樣可以使每個層次的接口既完備又精練，避免了各個模塊之間很復雜的依賴關系。 設計時要充分考慮，對于各個層次，層次越低，通用性越強，這樣，可以保證應用程序的需求發(fā)生改變時，所做的改動最小。開發(fā)視圖所用的風格通常是層次結構風格。, 開發(fā)視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型, 進程視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,進程視圖側重于系統(tǒng)的運行特性，主要關注一些非功能性的需求。 進程視圖強調并發(fā)性、分布性、系統(tǒng)集成性和容錯能力，以及從邏輯視圖中的主要抽象如何適合進

8、程結構。它也定義邏輯視圖中的各個類的操作具體是在哪一個線程中被執(zhí)行的。 進程視圖可以描述成多層抽象，每個級別分別關注不同的方面。在最高層抽象中，進程結構可以看作是構成一個執(zhí)行單元的一組任務。它可看成一系列獨立的，通過邏輯網絡相互通信的程序。它們是分布的，通過總線或局域網、廣域網等硬件資源連接起來。, 進程視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,通過擴展Booch對Ada任務的表示法，來表示進程視圖。, 進程視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型, 物理視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,物理視圖主要考慮如何把軟件映射到硬件上，它通

9、常要考慮到系統(tǒng)性能、規(guī)模、可靠性等。解決系統(tǒng)拓撲結構、系統(tǒng)安裝、通訊等問題。 當軟件運行于不同的節(jié)點上時，各視圖中的構件都直接或間接地對應于系統(tǒng)的不同節(jié)點上。因此，從軟件到節(jié)點的映射要有較高的靈活性，當環(huán)境改變時，對系統(tǒng)其他視圖的影響最小。, 物理視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,大型系統(tǒng)的物理視圖可能會變得十分混亂，因此可以與進程視圖的映射一道，以多種形式出現，也可單獨出現。, 物理視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,ACS系統(tǒng)的物理視圖, 物理視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,具有進程分配的小型ACS系統(tǒng)的物理視圖

10、, 物理視圖,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,具有進程分配的大型ACS系統(tǒng)的物理視圖, 場景,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,場景可以看作是那些重要系統(tǒng)活動的抽象，它使四個視圖有機聯系起來，從某種意義上說場景是最重要的需求抽象。在開發(fā)體系結構時，它可以幫助設計者找到體系結構的構件和它們之間的作用關系。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的。 場景可以用文本表示，也可以用圖形表示。, 場景,第2章 軟件體系結構建模,2.2 “4+1”視圖模型,本地呼叫場景的一個原型, 小結,第2章 軟件體系結構建模,2.2 “4+

11、1”視圖模型,邏輯視圖和開發(fā)視圖描述系統(tǒng)的靜態(tài)結構，而進程視圖和物理視圖描述系統(tǒng)的動態(tài)結構。 對于不同的軟件系統(tǒng)來說，側重的角度也有所不同。例如，對于管理信息系統(tǒng)來說，比較側重于從邏輯視圖和開發(fā)視圖來描述系統(tǒng)，而對于實時控制系統(tǒng)來說，則比較注重于從進程視圖和物理視圖來描述系統(tǒng)。,第2章 軟件體系結構建模,2.3 體系結構的核心模型, 軟件過程,第2章 軟件體系結構建模,2.4 體系結構的生命周期模型,需求分析,建立體系結構,測試,實現,設計, 生命周期模型,第2章 軟件體系結構建模,2.4 體系結構的生命周期模型,第2章 軟件體系結構建模,2.5 軟件體系結構抽象模型,選讀,功能需求說明：客戶所說的諸如“用戶應該能”或者“系統(tǒng)應該”，這是最可能的功能需求。功能需求描述了系統(tǒng)所展示的可觀察的行為，大多數是處于執(zhí)行者-系統(tǒng)響應順序的環(huán)境中。功能需求定義了系統(tǒng)應該做什么，它們組成了軟件需求規(guī)格說明的一部分。分析者應該明確，每個人應該理解系統(tǒng)為什么“必須”執(zhí)行某一功能。所提出的功能需求有時反映了過時的或無效的業(yè)務過程，而這些過程不能加入到新系統(tǒng)中。,非功能需求說明：是指軟件產品為滿足用戶業(yè)務需求而必須具有且除功能需求以外的特性。軟件產品的非功能性需求包括系統(tǒng)的性能、可靠性、可維護性、可擴充性和對技術