《《軟件體系結構》課件》由會員分享，可在線閱讀，更多相關《《軟件體系結構》課件（33頁珍藏版）》請在裝配圖網上搜索。
1、課 程 內 容 軟件體系結構概論 軟件體系結構建模 軟件體系結構風格 軟件體系結構描述 動態(tài)軟件體系結構 Web服務體系結構 基于體系結構的軟件開發(fā) 軟件體系結構的分析與測試 軟件體系結構評估 軟件產品線體系結構 軟件體系結構建模的種類 第 2章 軟件體系結構建模 2.1 軟件體系結構建模概述 結構模型 框架模型 動態(tài)模型 過程模型 功能模型 軟件體系結構建模的種類 第 2章 軟件體系結構建模 2.1 軟件體系結構建模概述 結構模型 這是一個最直觀 、 最普遍的建模方法 。 這種方法 以體系結構的構件 、 連接件和其他概念來刻畫結構 ， 并力圖通過結構來反映系統(tǒng)的重要語義內容 ， 包括系 統(tǒng)的
2、配置 、 約束 、 隱含的假設條件 、 風格 、 性質等 。 研究結構模型的核心是體系結構描述語言 。 軟件體系結構建模的種類 第 2章 軟件體系結構建模 2.1 軟件體系結構建模概述 框架模型 框架模型與結構模型類似 ， 但它不太側重描述結構 的細節(jié)而更側重于整體的結構 。 框架模型主要以一些特殊的問題為目標建立只針對 和適應該問題的結構 。 軟件體系結構建模的種類 第 2章 軟件體系結構建模 2.1 軟件體系結構建模概述 動態(tài)模型 動態(tài)模型是對結構或框架模型的補充 ， 研究系統(tǒng)的 “ 大顆粒 ” 的行為性質 。 例如 ， 描述系統(tǒng)的重新配置 或演化 。 動態(tài)可以指系統(tǒng)總體結構的配置 、 建
3、立或拆 除通信通道或計算的過程 。 軟件體系結構建模的種類 第 2章 軟件體系結構建模 2.1 軟件體系結構建模概述 過程模型 過程模型研究構造系統(tǒng)的步驟和過程 。 結構是遵循某些過程腳本的結果 。 軟件體系結構建模的種類 第 2章 軟件體系結構建模 2.1 軟件體系結構建模概述 功能模型 功能模型認為體系結構是由一組功能構件按層次組 成 ， 下層向上層提供服務 。 功能模型可以看作是一種特殊的框架模型 。 “4+1”模型概述 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 Kruchten在 1995年提出了 “ 4+1”的視圖模型。 “ 4+1”視圖模型從 5個不同的視角包括邏輯視
4、圖 、 進 程視圖 、 物理視圖 、 開發(fā)視圖和場景視圖來描述軟件 體系結構 。 每一個視圖只關心系統(tǒng)的一個側面 ， 5個視圖結合在 一起才能反映系統(tǒng)的軟件體系結構的全部內容 。 “4+1”模型概述 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 邏輯視圖 進程視圖 開發(fā)視圖 物理視圖 最終用戶：功能需求 場景 編程人員：軟件管理 系統(tǒng)集成人員：性能 可擴充性 、 吞吐量等 系統(tǒng)工程人員：系統(tǒng) 拓撲 、 安裝 、 通信等 邏輯視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 邏輯視圖主要支持系統(tǒng)的功能需求 ， 即系統(tǒng)提供給 最終用戶的服務 。 在邏輯視圖中 ， 系統(tǒng)分解成一
5、系列 的功能抽象 ， 這些抽象主要來自問題領域 。 這種分解 不但可以用來進行功能分析 ， 而且可用作標識在整個 系統(tǒng)的各個不同部分的通用機制和設計元素 。 在面向對象技術中 ， 通過抽象 、 封裝和繼承 ， 可以 用對象模型來代表邏輯視圖 ， 用類圖來描述邏輯視圖 。 邏輯視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 可以從 Booch標記法中導出邏輯視圖的標記法 ， 只是從體系結 構級的范疇來考慮這些符號 ， 用 Rational Rose進行體系結構設 計 。 構件 實例 繼承 使用 包含 ， 聚集 關聯 類層次 參數化類 類服務 類 連接件 邏輯視圖 第 2章 軟件體系
6、結構建模 2.2 “4+1”視圖模型 邏輯視圖中使用的風格為面向對象的風格 ， 邏輯視圖設計中要 注意的主要問題是要保持一個單一的 、 內聚的對象模型貫穿整個 系統(tǒng) 。 會話 終端 控制器 轉換服務 連接服務 編號計劃 邏輯視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 對于規(guī)模更大的系統(tǒng)來說 ， 體系結構級中包含數十甚至數百個 類 。 顯示及用戶 接口 機械服務 基本元素 航空信息 空中交通管 理 飛行管理 外部接口網 關 仿真和培訓 開發(fā)視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 開發(fā)視圖也稱模塊視圖 ， 主要側重于軟件模塊的組 織和管理 。 開發(fā)視圖要考慮
7、軟件內部的需求 ， 如軟件開發(fā)的容 易性 、 軟件的重用和軟件的通用性 ， 要充分考慮由于 具體開發(fā)工具的不同而帶來的局限性 。 開發(fā)視圖通過系統(tǒng)輸入輸出關系的模型圖和子系統(tǒng)圖 來描述 。 開發(fā)視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 與邏輯視圖一樣 ， 可以使用 Booch標記法中某些符號來 表示開發(fā)視圖 。 構件 參照相關性模塊 連接件 子系統(tǒng) 層 開發(fā)視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 在開發(fā)視圖中 ， 最好采用 4-6層子系統(tǒng) ， 而且每個子 系統(tǒng)僅僅能與同層或更低層的子系統(tǒng)通訊 ， 這樣可以 使每個層次的接口既完備又精練 ， 避免了各個模
8、塊之 間很復雜的依賴關系 。 設計時要充分考慮 ， 對于各個層次 ， 層次越低 ， 通 用性越強 ， 這樣 ， 可以保證應用程序的需求發(fā)生改變 時 ， 所做的改動最小 。 開發(fā)視圖所用的風格通常是層 次結構風格 。 開發(fā)視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 公用構件 1 低層服務 支撐機制：通信、時間、儲存、資源管理等 2 航空類、空中交通管制類 3 空中交通管制功能區(qū)：飛行管理、雷達管理等 4 人機接口 外部系統(tǒng) 5 離線工具 測試工具 各種各樣的空中 交通管制系統(tǒng) 特定的空中交通 管制系統(tǒng)構件 空中交通管制 系統(tǒng)框架 分布式虛擬機 基本元素 硬件、操作系 統(tǒng)、數據庫
9、 領 域 特 定 領 域 無 關 通 用 空 中 交 通 管 制 代 碼 客 戶 定 制 進程視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 進程視圖側重于系統(tǒng)的運行特性 ， 主要關注一些非 功能性的需求 。 進程視圖強調并發(fā)性 、 分布性 、 系統(tǒng)集成性和容錯 能力 ， 以及從邏輯視圖中的主要抽象如何適合進程結 構 。 它也定義邏輯視圖中的各個類的操作具體是在哪 一個線程中被執(zhí)行的 。 進程視圖可以描述成多層抽象 ， 每個級別分別關注 不同的方面 。 在最高層抽象中 ， 進程結構可以看作是 構成一個執(zhí)行單元的一組任務 。 它可看成一系列獨立 的 ， 通過邏輯網絡相互通信的程序
10、。 它們是分布的 ， 通過總線或局域網 、 廣域網等硬件資源連接起來 。 進程視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 通過擴展 Booch對 Ada任務的表示法 ， 來表示進程視 圖 。 構件 事件廣播 雙向消息 遠程過程調用 消息 未指定 連接件 循環(huán)進程 簡化進程 進程 進程視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 控制器進程 慢周期控 制器任務 快周期控 制器任務 主控制 器任務 終端進程 物理視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 物理視圖主要考慮如何把軟件映射到硬件上 ， 它通 常要考慮到系統(tǒng)性能 、 規(guī)模 、 可靠性等
11、 。 解決系統(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)的物理視圖
12、 C 主 KKKKKKKK F 備份 F 主 F 備份 F 主 C 備份 物理視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 具有進程分配 的小型 ACS系統(tǒng) 的物理視圖 K 會話進程 F 終端進程 控制器進程 物理視圖 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 具有進程分 配的大型 ACS系統(tǒng)的 物理視圖 C 中心進程 備份節(jié)點 偽中心進程 F 會話進程 終端進程 偽中心進程 F 會話進程 終端進程 K 控制器進程 K 控制器進程 K 控制器進程 更多的K 類 處理器 線路接口卡 線路接口卡線路接口卡 場景 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型
13、場景可以看作是那些重要系統(tǒng)活動的抽象，它使四 個視圖有機聯系起來，從某種意義上說場景是最重要的 需求抽象。在開發(fā)體系結構時，它可以幫助設計者找到 體系結構的構件和它們之間的作用關系。同時，也可以 用場景來分析一個特定的視圖，或描述不同視圖構件間 是如何相互作用的。 場景可以用文本表示，也可以用圖形表示。 場景 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 本地呼叫場景的一個原型 （1 ）摘機 小王: 控制器 編號計劃小王: 終端 小王: 會話 （2 ）撥號音 （3 ）號碼 （4 ）號碼 （5 ）打 開會話 小結 第 2章 軟件體系結構建模 2.2 “4+1”視圖模型 邏輯視圖和開發(fā)視
14、圖描述系統(tǒng)的靜態(tài)結構，而進程 視圖和物理視圖描述系統(tǒng)的動態(tài)結構。 對于不同的軟件系統(tǒng)來說，側重的角度也有所不同。 例如，對于管理信息系統(tǒng)來說，比較側重于從邏輯視圖 和開發(fā)視圖來描述系統(tǒng)，而對于實時控制系統(tǒng)來說，則 比較注重于從進程視圖和物理視圖來描述系統(tǒng)。 第 2章 軟件體系結構建模 2.3 體系結構的核心模型 軟件體系結構 配置 連接件 構件 端口 角色 1:N 1:N 1:N 軟件過程 第 2章 軟件體系結構建模 2.4 體系結構的生命周期模型 需求分析 建立體系結構 測試 實現 設計 生命周期模型 第 2章 軟件體系結構建模 2.4 體系結構的生命周期模型 體系結構的非 形式化描述 體系結構的形式化 基礎（數學模型） 體系結構的 規(guī)范描述 體系結構演化 體系結構提供、 評價和度量 體系結構的終結 體系結構實施 體系結構求精的驗證 體系結構求精 體系結構的 性質分析 需要演化 或擴展否 否 是 需要求精 否 是 否 第 2章 軟件體系結構建模 2.5 軟件體系結構抽象模型 選讀 第 2章 軟件體系結構建模 本章作業(yè)與思考題 1、選擇一個規(guī)模合適的系統(tǒng)，為其建立 “ 4+1”模型。 2、引入了軟件體系結構以后，傳統(tǒng)軟件過程發(fā)生了哪 些變化？這種變化有什么好處？ 3、軟件體系結構的生命周期模型與軟件生命周期模型 有什么關系？
《軟件體系結構》課件
