軟件架構
- 架構模式是軟件設計中的高層決策
- 設計模式主要關注軟件系統的設計，與具體實現語言無關
- 慣用法則是實現時通過某種特定的程序設計語言來描述構件與構件之間的關系
架構文檔化的主要輸出結果是架構說明書和架構質量說明書
介紹
軟件架構設計包括提出
- 架構模型
- 產生架構設計
- 進行設計評審
軟件系統架構是善於軟件系統的結構、行為和屬性的高級抽象。
- 架構設計關注點
- 結構
- 屬性
- 交互作用
架構風格
介紹
軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式。
架構風格定義了一類架構所共有的特征，主要包括架構定義、架構詞匯表和架構約束。
定義
一個體系結構定義了一個詞匯表和一組約束
架構風格反映領域中眾多系統所共有的結構和語義特征
架構設計是一個迭代過程，在建立軟件架構的初期，選擇一個合適的架構風格是首要的，在此基礎上，開發人員通過架構模型，可以獲得關於軟件架構屬性的理解，為將來的架構實現與演化過程建立了目標。
- GUI：事件驅動
解釋器
- 強調用戶自定義
管道過濾器
-
- 支持分階段數據處理
隱式調用
- 調試器，本質是在斷點處設計一個事件監聽函數
閉環結構
-
適用於處理簡單的任務
-
機器裝配
-
不適用於復雜任務
分層結構
-
引入抽象層
-
低層不確定的實現細節在高層會變得確定
-
系統結構更加清晰
數據共享
- 現代編譯器
面向構件
介紹
軟件構件是部署、版本控制和替換的基本單位。
- 構件通常需要同時部署的院子構件
- 原子構件通常成組地部署，但他也能夠被單獨部署
原子構件 與 構件的區別
原子構件永遠不會被單獨的部署，盡管其可以單獨部署
大多數原子構件都屬於一個家庭，一次部署往往整個家庭
一個模塊是不帶單獨資源的原子構件
- 邏輯構件模型用功能描述系統的抽象設計
- 作為系統的設計藍圖以保證系統提供適當的功能
- 物理構件模型
- 技術設施產品、硬件分布和拓撲結構
- 了解系統的性能、吞吐率等許多非功能性屬性
構件特性
- 獨立部署單元
- 作為第三方的組裝單元
- 沒有（外部的）可見狀態
對象的特性
- 一個實例單元，具有唯一的標志
- 可能具有狀態，此狀態外部可見
- 封閉了自己的狀態
構件組裝
問題
- 構件失配
- 由於系統對構件基礎設施、控制模型和數據模型的假設存在沖突引起的失配
- 連接子失配
- 包括於系統對構件交互協議、構件連接子失配包括由於系統對構件交互協議、構件連接時數據格式的假設存在沖突引起的扮酷
CORBA
對象適配器
作用
在底層的傳輸平台與接收調用並返回結果的對象實現之間進行協調
目前采用的對象適配器規范是POAching（可移植對象適配器）
替代了傳統的BOA(基本對象適配器)
Servant 伺服對象
最終完成客戶請求的服務對象實現
伺服對象管理器
伺服對象激活器和伺服對象定位器
用來提供CORBA服務端的對象查找服務
活動對象映射表用來保存已注冊的CORBA對象標識和伺服對象之間的映射關系。
實體（Entity)
- 長期持久並主要用於事務性行為
- 由窗口管理其持久化
加工（Process）
- 同樣需要窗口管理其持久化，但沒有客戶端可以訪問的主鍵
會話（Session）
- 構件不需要窗口管理其持久化
- 自己管理自身狀態信息
服務（Service）
- 構件是無狀態的
COP 面向構件編程
需要的基本支持
- 多太性（可替代性）
- 模塊封裝性（高層次信息隱藏）
- 后期的綁定和裝載（部署獨立性）
- 安全性（類型和模塊安全性）
分布式系統
5層
- 表示層
- 實現用戶界面
- 表示邏輯層
- 為了生成數據
- 應用邏輯層
- 數據計算和分析
- 數據處理層
- 存儲和訪問數據庫的應用邏輯和命令
- 數據層
- 數據庫中實際存儲的業務數據
4+1 視圖
- 4+1視圖中，邏輯視圖用來描述軟件模塊的組織與管理
- 開發視圖：描述了軟件模塊的組織與管理
- 過程視圖描述設計的並發和同步特征。
ADL
- 組成部分
- 組件、組件接口、連接件、架構配置
C2
介紹
通過連接件綁定在一按照一組規則動作的並行構件風格。
C2風格中的系統組織規則如下
架構復審
架構設計、文檔化和復審是一個迭代的過程
-
通常會對一個可運行的最小化系統進行架構評估和測試
-
目標：
-
- 標識潛在的風險，及早發現架構設計的缺陷和錯誤
介紹
目的
為了標識潛在的風險，及早發現架構設計中的缺陷和錯誤
在架構復審過程中，主要由用戶代表與領域專家決定架構是否滿足需求、質量需求是否在設計中得到體現
架構文檔
- 軟件架構文檔是對軟件架構的一種描述，幫助程序員使用特定的程序設計語言實現軟件架構
原則
- 文檔從使用者的角度進行編寫
- 必須分發給所有與系統有關的開發人員
- 保持文檔更新，但不要太頻繁
- 避免不必要的重復
- 每次架構文檔的修改都應該記錄進行修改的原則
軟件架構設計
-
是降低成本、改進質量、按時和按需交付產品的關鍵因素。
-
滿足系統的性能、可維護性
-
使不同利益相關的人達到一致的目標
-
支持項目計划和項目管理等活動
-
能夠有效地管理復雜性
軟件體系結構
文檔化過程
輸出結果：體系結構規格說明 和 測試體系結構需求的質量設計說明書
文檔的完整性和質量是軟件體系結構成功的關鍵因素
文檔從使用者的角度進行編寫
必須頒發給所有與系統有關的開發人員
且必須保證開發者手上的文檔是最新的
軟件架構需求
- （軟件架構需求不應該包括設計構件的過程）
基於架構的軟件設計 - ABSD
- 功能分解
- 采用架構風格實現質量屬性與商業需求
- 采用模板設計軟件結構
- ABSD方法是一個自頂向下，遞歸細化的過程，軟件系統的架構通過該方法得到細化，直到能產生軟件架構的類
- 強調由商業、質量和功能需求的組合驅動軟件架構設計。
- 強調采用視角和視圖來描述軟件架構
- 采用用例和質量場景來描述需求
設計策略
-
Ping/ Echo 主要提高系統的可用性
-
限制訪問
- 提高系統的安全性
-
運行時注冊
- 提高系統的可修改性
-
主動冗余
- 系統的可靠性
-
隊列調度
- 提高系統的性能
-
信息隱藏
- 提高系統的可修改性
-
記錄回放
- 可測試性
設計模式
-
訪問者模式
-
- 在不改變原來的類結構（活動節點）的基礎上增加新功能
三種模式
創建型
通過采用抽象類所定義的接口，封裝了系統中對象如何創建、組合
- abstract factory
- builder
- factory method
- prototype
- singletoin
結構型模式
主要用於如何組合已有的類和對象以獲得更大的結構
- adaptor
- bridge
- composite
- decorator
- facade
- flyweight
- proxy
行為型模型
主要用於對象之間的職責及其提供服務的分配方式
- chain of responsibility
- command
- interpreter
- iterator
- mediator
- memento
- observer
- state
- strategy
- template matehod
- visitor
外觀模式
- 要求外部與一個子系統的通信必須通過一個統一的外觀對象進行
- 為子系統中的一組接口提供一個一致的界面
軟件系統架構評估
ATAM
- 軟件體系結構的設計結果進行評估
- ATAM並不是一種精確的評估方法，該方法表現的主要形式是評審會議
在系統開發之前，性能、可能性、安全性和可修改性等質量屬性進行評價和折中。
ATAM分 為四個主要的活動階段
- 需求收集
- 架構視圖
- 描述
- 屬性模型
強調以視圖做為架構評估的核心概念
- 效用樹
- 對質量屬性的描述進行刻畫與排序
在識別出質量屬性描述后，通常采用效用樹對質量屬性的描述進行刻畫與排序
架構評價的理解和應用
敏感點：是實現一個特定質量屬性的關鍵特征
權衡點：會影響一個或多個屬性，並對多個屬性來說都是第三點
領域分析
- 領域分析的主要目的是獲得領域模型
- 領域模型描述領域中系統之間共同的需求，即領域需求
- 領域設計的主要目標是獲取DSSA（需求的解決方案）
- 領域實現的主要目標是依據領域模型和DSSA開發和組織可重用信息，並對基礎軟件架構進行實現
DSSA
介紹
DSSA是一個具有三個層次的系統模型，包括領域開發環境、領域特定應用開發環境和應用執行環境
- 應用工程師主要在領域特定應用開發環境中工作
作用
以一個特定問題領域為對象，形成由領域參考模型、參考需求、參考架構等組成的開發基礎架構，其目標是支持一個特定領域中多個應用的生成。
基本活動
領域分析、領域設計、領域實現
架構需求
UML
UML對系統架構的定義是系統的組織結構
- 邏輯視圖：（設計視圖），它表示了設計模型中在架構方面具有重要意義的部分，即類、子系統、包和用例實現的子集
- 進程視圖：是可執行線程和進程作為活動類的建模，它是邏輯視圖的一次執行實例，描述了並發與同步結構
- 實現視圖：對組成基於系統的物理代碼的文件和構件進行建模
- 部署視圖：把構件部署到一組物理節點上，表示軟件到硬件的映射和分布結構
- 用例視圖：是最基本的需求分析模型
用例視圖：是最基本的需求分析模型
架構分析
SAAM
是最早廣泛應用的架構分析方法
SAAM輸入是問題描述、需求說明和架構描述
分析過程：場景開發、架構描述、單個場景評估、場景交互和總體評估
軟件策略
- 心跳：增加計算機資源、減少計算機開銷、引入並發機制、采用資源高度等。
- 可用性：心跳、Ping/Echo、主動冗余、被動冗余 、選舉等架構策略實現該屬性
- 安全性：入侵檢測、用戶認證、用戶授權、追蹤審計
野生知識
機器人
使用規划系統架構風格
IDL
介紹
是一種接口定義語言
主要元素
接口描述、模塊定義、類型定義、常量定義、異常、值類型
核心
接口描述是ILD文件中最核心的內容
ILD只是一種接口定義語言，最終還是要落地與語言對接，所以IDL的數據類型要與實現語言進行映射
逆向工程
分析已有的程序，尋求比源代碼更高級的抽象表現形式
系統移植
階段
1. 計划階段
在計划階段，要進行現有系統的調查整理，從移植技術、系統內容(是否進行系統提煉等)、系統運行三個方面，探討如何轉換成新系統，決定移植方法，確立移植工作體制及移植日程
2. 准備階段
在准備階段要進行移植方面的研究，准備轉換所需的資料。該階段的作業質量將對以后的生產效率產生很大的影響
3. 轉換階段
這一階段是將程序設計和數據轉換成新機器能根據需要工作的階段。提高轉換工作的精度，減輕下一階段的測試負擔是提高移植工作效率的基本內容
4. 測試階段
這一階段是進行程序單元、工作單元測試的階段。在本階段要核實程序能否在新系統中准確地工作。所以，當有不能准確工作的程序時，就要回到轉換階段重新工作
5. 驗證階段
這是測試完的程序使新系統工作，最后核實系統，准備正式運行的階段