软件体系结构
目錄
- 前言
- 概述
- 軟件重用
- 可重用的元素
- 構件
- 構件模型（規(guī)模——越大越好？越小越好？）
- 構件獲取
- 可重用技術和領域之間的關系
- 構件管理
- 軟件體系結構
- 軟件體系結構的反作用
- 軟件體系結構的商業(yè)周期
- 軟件體系結構建模
- 4+1模型視圖
- 邏輯視圖（靜態(tài)）
- 開發(fā)視圖（靜態(tài)）
- 進程視圖（動態(tài)）
- 物理視圖（動態(tài)）
- 場景
- 軟件體系結構的生命周期
- 軟件體系結構設計核心模型
- 構件
- 構件之間的關系
- 連接件
- 配置
- 軟件體系結構
- 軟件體系結構風格
- 管道過濾器風格
- 數(shù)據(jù)抽象和面向對象組織
- 事件驅動風格
- 分層系統(tǒng)
- 倉庫系統(tǒng)及知識庫
- 黑板系統(tǒng)
- C2（層次網(wǎng)絡+消息驅動）
- 全局軟件體系結構
- C/S結構
- 三層C/S結構
- CORBA（公共對象請求代理）
- 正交體系結構
- 層次消息總線（HMB）
- 接口
- 消息總線
- 構件靜態(tài)結構
- 構件的動態(tài)行為
- 異構結構風格
- 內(nèi)外有別
- 查改有別
- 互聯(lián)系統(tǒng)構成的系統(tǒng)
- 軟件體系結構評估
- 軟件體系結構的質(zhì)量屬性
- 性能（*）
- 可靠性（*）
- 可用性（*）
- 安全性（*）
- 可修改性（*）
- 功能性
- 可變性
- 集成性
- 互操作性
- 基本概念
- 基于場景的評估方式（ATAM）
- 描述ATAM方法
- 描述業(yè)務動機
- 描述體系結構
- 確定體系結構方法
- 生成質(zhì)量屬性效用樹
- 分析體系結構描述方法
- 討論和分級場景
- 分析體系結構方法
- 描述評估結果
- 基于度量的評估方式（SAAM）
- 形成場景
- 描述體系結構
- 對場景進行分類和確定優(yōu)先級
- 對間接場景的單個評估
- 評估場景的相互作用
- 形成總體評估
- 基于體系結構的軟件設計方法（ABSD）
- ABSD方法定義的設計元素
- 設計元素的產(chǎn)生順序
- 設計元素的活動
- 基于體系結構的軟件開發(fā)模型
- 體系結構需求
- 體系結構設計
- 體系結構文檔化
- 體系結構復審
- 體系結構實現(xiàn)
- 體系結構演化
前言
按照慣例，在這里寫下我對軟件體系結構的一點理解和認識
軟件工程是一門研究利用工程化的方法，構建維護有效的實用的高質(zhì)量的軟件的學科，東北林業(yè)大學軟件工程專業(yè)核心課，就是按照軟件生命周期的課來安排的，將每一個生命周期中的過程都抽象成一門課來給學生講解，軟件體系結構這門課是繼需求分析和系統(tǒng)分析之后的一門課
需求分析教會了我們?nèi)绾芜M行需求獲取、需求分析和需求驗證，最后形成需求規(guī)格說明書，系統(tǒng)分析教會了我們?nèi)绾纬橄蟪龊侠淼念悎D，而軟件體系結構講的是如何把類抽象成構件以及如何合理的安排這些構件（或者類）
概述
軟件重用
在兩次或多次開發(fā)的過程中，重復使用相同或相近的元素的過程
可重用的元素
- 代碼
- 設計文檔
- 測試用例
- 需求分析文檔
- 框架
- 設計過程
- 領域知識
構件
- 語義完整、語法正確、有可重用價值的單位軟件
- 是軟件重用過程中可明確辨識的系統(tǒng)
- 結構上是語義描述、通信接口和實現(xiàn)代碼的復合體
構件模型（規(guī)?！酱笤胶?#xff1f;越小越好？）
青鳥模型：外部接口+內(nèi)部接口
構件獲取
- 開發(fā)新的構件
- 購買
- 從歷史遺留工程中提取
- 去構件庫中查找需要的構件
- 由現(xiàn)有構件做適應性修改
可重用技術和領域之間的關系
領域具有內(nèi)聚性和穩(wěn)定性——前提
可重用信息具有領域特定性——約束
構件管理
對大量的構件進行有效的管理，方便構建的存儲、檢索和提取
構件的描述；名稱、功能、參考函數(shù)、版本號等
關鍵詞法
優(yōu)點：簡單易行
缺點：不便于查詢
刻面法
優(yōu)點：方便查找相似構件
缺點：查詢程序太難做
超文本法
優(yōu)點：操作人性化
缺點：容易差跑題了
軟件體系結構
軟件體系結構為軟件系統(tǒng)提供了一個結構、行為和屬性的高級抽象，由構成系統(tǒng)的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。
軟件體系結構不僅指定了系統(tǒng)的組織結構和拓撲結構，并且顯示了系統(tǒng)需求和構成系統(tǒng)的元素之間的對應關系，提供了一些設計決策的基本原理。
軟件體系結構的反作用
- 影響開發(fā)組織結構
- 影響開發(fā)組織目標
- 影響客戶對下一個系統(tǒng)的要求
- 構建過程中豐富團隊經(jīng)驗，影響后續(xù)設計
- 改變行業(yè)人員學習和實踐的技術環(huán)境
軟件體系結構的商業(yè)周期
軟件體系結構建模
軟件體系結構的建立應位于需求分析之后，軟件設計之前，在建立軟件體系結構時，設計師主要從結構的角度對整個系統(tǒng)進行分析，選擇恰當?shù)臉嫾嫾g的相互作用以及他們的約束，最后形成一個系統(tǒng)框架以滿足用戶的需求，為軟件設計奠定基礎。
4+1模型視圖
每個視圖只關心系統(tǒng)的一個側面，結合在一起才能反映系統(tǒng)的軟件體系結構的全部內(nèi)容
在每個視圖上均獨立地應Perry & Wolf 的公式，即定義一個所使用的元素集合（構件、容器、連接件）
邏輯視圖（靜態(tài)）
主要是整個系統(tǒng)的抽象結構表述
關注系統(tǒng)提供最終用戶的功能
不涉及具體的編譯即輸出和部署
通常用BOOCH標記法，或在UML中用類圖表示
開發(fā)視圖（靜態(tài)）
主要側重軟件模塊的組織和管理，為編程人員服務
軟件可以通過程序庫或子程序進行組織，從而可以由不同的人員進行開發(fā)
主要考慮軟件內(nèi)部需求，要充分考慮軟件開發(fā)的容易程度，重用性，軟件的通用性，充分考慮由于具體開發(fā)工具不同而帶來的局限性。
- 常用層次風格
- 采用4-6層子系統(tǒng)
- 僅進行相鄰交互
- 層次越低，通用性應越強
進程視圖（動態(tài)）
側重系統(tǒng)的運行特性
關注非功能需求（性能、可用性、并發(fā)性）
定義邏輯視圖中的各個類的操作是在哪一個線程中被執(zhí)行
可以描述成多層抽象
每個級別分別關注不同的方面
最高層抽象中：進程結構＝構成一個執(zhí)行單元的一組任務 | 獨立、分布 | 通過邏輯網(wǎng)絡相互通信
物理視圖（動態(tài)）
如何把軟件映射到硬件上
關注系統(tǒng)性能、規(guī)模、可靠性等
場景
重要系統(tǒng)活動的抽象
最重要的需求抽象
聯(lián)系4個視圖
軟件體系結構的生命周期
需求分析階段
體系結構需求包括需求獲取、生成類圖、對類分組、將類打包成構件和需求評審等過程。
建立軟件體系結構階段
選擇合適的體系結構風格，把體系結構需求階段已確認的構件映射到體系結構中，產(chǎn)生一個中間結構，分析構件之間的相互作用和關系，對中間結構進行細化。
設計階段
主要是對系統(tǒng)進行模塊化并決定描述各個構件間的詳細接口、算法和數(shù)據(jù)類型的選定，對上支持建立體系結構階段形成的框架，對下提供實現(xiàn)基礎。
實現(xiàn)階段
設計階段設計的算法及數(shù)據(jù)類型進行程序語言表示，滿足設計體系結構和需求分析的要求，從而得到滿足設計需求的目標系統(tǒng)。
軟件體系結構設計核心模型
構件
構件定義：構件是一個數(shù)據(jù)單元或一個計算單元，它由構件的對象的集合、屬性的集合、動作的集合和端口的集合組成。
抽象表示為C = （O,A,X,P），
O 是構件的所有對象的集合；
A 是構件屬性的集合；
X 是構件動作的集合；
P 是構件端口的集合。
構件是具有某種功能的可重用的軟件模版單元
從其內(nèi)容角度看，表現(xiàn)為：計算元素、數(shù)據(jù)存儲
從其形式角度看，表現(xiàn)為：原子構件、復合構件
構件的接口：一組端口
構件之間的關系
順序結構（順序運算）
選擇結構（選擇運算）
循環(huán)結構
順序運算定理：
連接件
構件間的交互依據(jù)內(nèi)容分類：
表現(xiàn)為：管道、過程調(diào)用、事件廣播……
連接件的接口：一組角色
連接件是構件運算的實現(xiàn)，它是一個6元組
<ID,Role,Beha,Msgs,Cons,Non-Func>
其中，Role為連接件和構件的交互點的集合，它由一個四元組定義
Role=<Id,Action,Event,LConstrains>
配置
拓撲邏輯和約束
軟件體系結構
定義：設論域為U，
(1)構件是一個軟件體系結構
(2)連接件是一個軟件體系結構
(3)構件經(jīng)有限次連接（運算）后是軟件體系結構。
軟件體系結構記為A=<C,O>,其中C表示組成體系結構的構件集合，O表示構件運算的集合
性質(zhì)：
- 封閉性：即構件與構件、構件與體系結構、體系結構與體系結構連接后仍是一個體系結構。
- 層次性：即體系結構可由構件連接而成，而體系結構又可以再經(jīng)過連接組成新的更大的體系結構。
- 可擴充性：即一個滿足條件的新構件可以通過連接加入到結構中。
軟件體系結構風格
什么決定了軟件體系結構風格？控制原則、質(zhì)量屬性
管道過濾器風格
優(yōu)點：
構件間耦合關系降低，易于分解問題，實現(xiàn)重用
易于維護和擴展
為系統(tǒng)的運行分析提供便捷條件
支持并發(fā)計算
缺點：
不適合處理交互頻繁的應用
數(shù)據(jù)解析、合成麻煩
擴展形式：管線、有界管道、批處理
數(shù)據(jù)抽象和面向對象組織
優(yōu)點：
封裝性、便于重用
可實現(xiàn)交互
缺點：
調(diào)用使得修改被傳播
事件驅動風格
事件：監(jiān)聽事件、聲明事件
構成：事件消費者、事件生產(chǎn)者、事件管理器
基本結構：
事件監(jiān)聽接口和事件監(jiān)聽器
事件監(jiān)聽的注冊和注銷
特征：
是面向對象風格的變體
事件接觸者不知道哪些構件會被這些事件影響
無法預知和假定構件的處理順序
優(yōu)點：
為重用提供支持
為系統(tǒng)改進提供方便
缺點：
弱化了對系統(tǒng)計算的控制能力
有數(shù)據(jù)共享的負擔
系統(tǒng)邏輯關系復雜
分層系統(tǒng)
每個層次為上一層提供服務
它同時作為用戶調(diào)用下層的功能
嚴格的分層
半透明的分層
優(yōu)點：
支持基于抽象程度遞增的系統(tǒng)設計
良好的擴展性
支持重用
缺點：
層次劃分困難
適用性受限
倉庫系統(tǒng)及知識庫
要素：
兩類構件：中央數(shù)據(jù)單元+外部構件
控制策略：兩類構件間的交互方式
分類：
傳統(tǒng)數(shù)據(jù)庫型（被動）
黑板系統(tǒng)（主動）
黑板系統(tǒng)
中央數(shù)據(jù)單元是系統(tǒng)的核心，存儲數(shù)據(jù)和系統(tǒng)狀態(tài)數(shù)據(jù)
知識源是相互獨立的，通過黑板系統(tǒng)完成交互
控制單元是非獨立單元
優(yōu)點：
易于增加數(shù)據(jù)的生產(chǎn)者和消費者
良好的知識庫擴展性
易于保證數(shù)據(jù)的同步、一致性
C2（層次網(wǎng)絡+消息驅動）
組織規(guī)則：
頂、底
構件不能直接相連
連接件之間自由連接
連接件的直接相連是有序的
工作方式：請求＋通知
特點：
基底獨立性
構件只見交互只能通過消息傳遞實現(xiàn)
多線程
全局軟件體系結構
C/S結構
服務器任務：
保證數(shù)據(jù)庫安全性
控制數(shù)據(jù)庫并發(fā)訪問
確保數(shù)據(jù)的一致性
數(shù)據(jù)備份與恢復
客戶端任務：
提供交互界面
提交請求，接收信息
對客戶端數(shù)據(jù)執(zhí)行應用邏輯要求
三層C/S結構
兩層C/S的弊端：
軟硬件的組合和集成能力有限，難以擴展至大型項目中
軟硬件的組合及集成能力有限
客戶機負荷過重
數(shù)據(jù)安全性不好
表示層（用戶接口部分）：
用戶與應用間的對話
檢查用戶的輸入和顯示數(shù)據(jù)（只檢查形式和取值范圍）
功能層（應用本體）：
處理業(yè)務邏輯
數(shù)據(jù)層：
數(shù)據(jù)庫的讀寫
優(yōu)點：
在邏輯上保持相對獨立性，能提高系統(tǒng)和軟件的可維護性和可擴展性
允許更靈活有效地選用相應的平臺和硬件系統(tǒng)，在處理負荷能力上與處理特性上分別適應于結構清晰的三層
應用的各層可以并行開發(fā)，可以選擇各自最適合的開發(fā)語言
利用功能層有效地隔離開表示層與數(shù)據(jù)層，未授權的用戶難以繞過功能層而利用數(shù)據(jù)庫工具或黑客手段去非法地訪問數(shù)據(jù)層
關鍵問題：
三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，其作為整體來說也達不到所要求的性能
設計時必須慎重考慮三層間的通信方法、通信頻度及數(shù)據(jù)量
CORBA（公共對象請求代理）
CORBA體系結構是對象管理組織（OMG）為解決分布式處理環(huán)境(DCE)中，硬件和軟件系統(tǒng)的互連而提出的一種解決方案
ORB：carba展開工作的核心，是關鍵的通信機制，處理對象間的消息分布，是一種透明機制
主要任務：對象定位、對象激活、對象通訊
接口定義語言：統(tǒng)一的描述服務器對象接口，不涉及對象的具體實現(xiàn)，面向對象語言
接口池：分布式計算環(huán)境中所有可用服務器對象的接口表示
使得動態(tài)搜索接口和動態(tài)構造請求即參數(shù)成為可能
動態(tài)調(diào)用接口：提供標準函數(shù)供用戶動態(tài)創(chuàng)建請求動態(tài)構造請求參數(shù)
對象適配器：屏蔽內(nèi)部實現(xiàn)細節(jié)，為服務器提供抽象接口
特點：
引入中間件作為事務代理，完成客戶機向服務對象方提出的業(yè)務請求
實現(xiàn)客戶與服務對象的完全分開，客戶不需要了解服務對象的實現(xiàn)過程以及具體位置
提供軟總線機制，使得在任何環(huán)境下、采用任何語言開發(fā)的軟件只要符合接口規(guī)范的定義，均能夠集成到分布式系統(tǒng)中
CORBA規(guī)范軟件系統(tǒng)采用面向對象的軟件實現(xiàn)方法開發(fā)應用系統(tǒng)，實現(xiàn)對象內(nèi)部細節(jié)的完整封裝，保留對象方法的對外接口定義
正交體系結構
組成原則：
1 線索可看成是子系統(tǒng)，它由完成不同層次功能的構件組成，同一線索上的構件相互間是一種調(diào)用關系，每一條線索完成整個系統(tǒng)中相對獨立的一部分功能
2 層是具有相同抽象級別的構件構成的
3 每一條線索的實現(xiàn)與其他線索的實現(xiàn)無關或關聯(lián)很少，在同一層中的構件之間是不存在相互調(diào)用的
4 如果線索是相互獨立的，即不同線索中的構件之間沒有相互調(diào)用，那么這個結構就是完全正交的
三層線索 五層結構
優(yōu)點：
結構清晰，易于理解
易修改，可維護性強
可移植性強，重用粒度大
層次消息總線（HMB）
HMB風格基于層次消息總線、支持構件的分布和并發(fā)，構件之間通過消息總線進行通信
消息總線是系統(tǒng)的連接件，負責消息的分派、傳遞、過濾及處理結果的返回
各個構件掛接在消息總線上，向總線登記感興趣的消息類型；構件發(fā)送的消息由總線傳送到其他構件，處理結果也由總線返回
不要求各個構件具有相同的地址空間或局限在同一臺機器上，可較好地刻畫分布式并發(fā)系統(tǒng)
在對系統(tǒng)持續(xù)可用性要求較高時，需要在不必對軟件進行重新編譯和加載的前提下，為最終用戶提供系統(tǒng)定制和擴展的能力
動態(tài)刪除和增加構件：
系統(tǒng)功能需要擴充時，增加新的構件，只需登記消息響應
系統(tǒng)功能裁減或某構件出現(xiàn)問題時，刪除構件，需阻塞一些消息
用增強功能或改正錯誤的新構件替換舊構件
動態(tài)改變構件響應的消息類型：
構件可以動態(tài)地改變對外提供的服務
消息過濾：
通過消息過濾機制，解決某些構件集成的不匹配問題
HMB風格的構件模型包括接口、靜態(tài)結構和動態(tài)行為
接口
HMB風格的構件接口是一種基于消息的互聯(lián)接口，可以較好地支持體系結構設計。構件之間通過消息進行通訊，接口定義了構件發(fā)出和接收的消息集合
HMB有兩個顯著的特點：
一是降低構件之間的耦合：構件只對消息本身感興趣，不關心消息如何產(chǎn)生；切斷構件之間的直接聯(lián)系
二是構件對外來消息進行響應后，可能導致狀態(tài)的變遷；同一構件在不同狀態(tài)下收到同樣消息可能作出不同的響應
當某個事件發(fā)生后，系統(tǒng)或構件發(fā)出相應的消息，消息總線負責把該消息傳遞到此消息感興趣的構件
按照響應方式的不同，消息可分為同步消息和異步消息
互補端口（通過消息總線進行通信）：除消息進出構件的方向不同外，消息的名稱、參數(shù)、返回結果類型完全相同的兩個端口
消息總線
消息登記：構件需要向總線登記響應的消息集合
消息分派和傳遞：總線負責消息的分派、傳遞，并負責處理結果的返回；總線是邏輯上整體，物理上可跨越多個機器(位置透明)
消息過濾：總線提供消息的轉換和阻塞
構件靜態(tài)結構
HMB風格支持自頂向下的層次化分解，復合構件由簡單子構件構成；
子構件通過復合構件內(nèi)部的消息總線連接，各層次的消息總線在邏輯功能上一致；
子構件還可進一步再分，整個系統(tǒng)用統(tǒng)一的方式描述。
構件的動態(tài)行為
構件的行為就由外來消息的類型唯一確定，即一個消息和構件的某個操作之間存在著固定的對應關系
更通常的情況是，構件的行為同時受外來消息類型和自身當前所處狀態(tài)的影響
可用有限狀態(tài)自動機來描述
異構結構風格
不同結構有不同的處理能力的優(yōu)點和缺點，系統(tǒng)應根據(jù)實際需要來選擇，以解決實際問題
內(nèi)外有別
優(yōu)點：外部用戶不直接訪問數(shù)據(jù)庫服務器，能保證企業(yè)數(shù)據(jù)庫的相對安全。企業(yè)內(nèi)部用戶的交互性較強，數(shù)據(jù)查詢和修改的響應速度較快
缺點：企業(yè)外部用戶修改和維護數(shù)據(jù)時，速度較慢，較煩瑣，數(shù)據(jù)的動態(tài)交互性不強
查改有別
凡是維護和修改都是c/s結構，凡是查詢都是b/s結構
體現(xiàn)了B/S體系結構和C/S體系結構的共同優(yōu)點。但因為外部用戶能直接通過Internet連接到數(shù)據(jù)庫服務器，企業(yè)數(shù)據(jù)容易暴露給外部用戶，給數(shù)據(jù)安全造成了一定的威脅
互聯(lián)系統(tǒng)構成的系統(tǒng)
系統(tǒng)是總分結構，可分成若干部分，每個部分作為單獨的系統(tǒng)開發(fā)；整個系統(tǒng)通過一組互連系統(tǒng)實現(xiàn)，互連系統(tǒng)之間相互通信，履行
上級系統(tǒng)(superordinate system)：體現(xiàn)整體性能
從屬系統(tǒng)(subordinate system)：子系統(tǒng)，上級系統(tǒng)模型中所指定內(nèi)容的一個實現(xiàn)
關鍵點
上級系統(tǒng)獨立于其從屬系統(tǒng)，每個從屬系統(tǒng)僅僅是上級系統(tǒng)模型中所指定內(nèi)容的一個實現(xiàn)，并不屬于上級系統(tǒng)功能約束的一部分
軟件體系結構評估
軟件體系結構的質(zhì)量屬性
性能（*）
系統(tǒng)的響應能力
可靠性（*）
容錯性：發(fā)成錯誤行為時進行內(nèi)部修復
健壯性：保護程序不受錯誤輸入和錯誤使用的影響
可用性（*）
系統(tǒng)能夠正常運行的時間的比例
安全性（*）
系統(tǒng)在向合法用戶提供服務的同時能夠阻止非授權用戶使用的企圖和拒絕服務的能力
可修改性（*）
能夠快速地以較高的性能價格比對系統(tǒng)進行變更的能力
可維護性：在錯誤發(fā)生后“修復”軟件系統(tǒng)，對其他構件的負面影響最小化
可擴展性：使用新特性擴展軟件系統(tǒng)，使用改進版本替換構件并刪除不需要或不必要的特性和構件
結構重組：重新組織軟件系統(tǒng)的構件及構件間的關系
可移植性：使軟件系統(tǒng)適用于多種硬件平臺、用戶界面、操作系統(tǒng)、編程語言或編譯器
功能性
系統(tǒng)所能完成所期望的工作的能力
可變性
體系結構經(jīng)擴充或變更而成為新體系結構的能力
集成性
系統(tǒng)能與其他系統(tǒng)協(xié)作的程度
互操作性
作為系統(tǒng)組成部分的軟件不是獨立存在的，經(jīng)常與其他系統(tǒng)或自身環(huán)境相互作用
基本概念
敏感點：體系結構決策采用不同的性能屬性,同時這些屬性在風險評估中是一些關鍵性的因素,當進行評價時,它們是體系結構的敏感點，一個或多個構件，或構件之間的關系的特性
權衡點：(加密級別-安全性、性能)是影響多個質(zhì)量屬性的特性，是多個質(zhì)量屬性的敏感點
風險承擔者：
在項目管理領域中指“項目干系人”或“涉眾”
場景：
要進行體系結構評估時，一般首先要精確地得出具體的質(zhì)量目標，并以之作為判定該體系結構優(yōu)劣的標準。為得出這些目標而采用的機制叫做“場景”
場景用刺激、環(huán)境和響應進行描述
刺激：場景中解釋或描述風險承擔者怎樣姻法與系統(tǒng)的交互部分
環(huán)境：描述刺激發(fā)生時的情況
響應：系統(tǒng)如何通過體系結構對刺激做出反應
基于場景的評估方式（ATAM）
ATAM不但揭示了體系結構如何滿足特定的質(zhì)量目標，而且提供了這些質(zhì)量目標如何交互，即他們之間是如何權衡的
6個步驟不是瀑布過程，中途可以跳轉迭代
描述ATAM方法
向風險承擔者介紹評估方法
介紹ATAM方法步驟簡介
介紹獲取分析技術
介紹評估結果
描述業(yè)務動機
產(chǎn)品經(jīng)理要使參會人員理解待評估系統(tǒng)
包括系統(tǒng)的功能需求、約束條件、目標環(huán)境和體系結構的驅動因素
描述體系結構
設計師對體系結構進行相對應的描述
內(nèi)容包括技術約束、與本系統(tǒng)交互的其他系統(tǒng)、用以滿足質(zhì)量要求的軟件結構方法
確定體系結構方法
設計師通過理解體系結構方法來確定體系結構
生成質(zhì)量屬性效用樹
分析體系結構描述方法
通過效用樹對體系結構的方法進行考察
討論和分級場景
集體討論用例場景和改變場景（成長場景、考察場景）
成長場景：體系結構中短期的改變
考察場景：體系結構根本性改變
分析體系結構方法
每人30%場景數(shù)量的票數(shù)進行投票
對比得票數(shù)最高的場景和效用樹中優(yōu)先級最高的節(jié)點、對存在的差異進行調(diào)整和解釋
得到對每個場景影響最大的質(zhì)量屬性
描述評估結果
文檔化的體系結構方法
場景及其優(yōu)先級
基于屬性的問題
效用樹
風險決策
文檔化的無風險決策
敏感點和權衡點
基于度量的評估方式（SAAM）
形成場景
描述體系結構
對場景進行分類和確定優(yōu)先級
直接場景：體系結構可直接支持該場景，不需要修改
間接場景：必須對體系結構進行一些修改，如：增加構件、刪除構件、修改接口等
確定優(yōu)先級還是投票，可參考ATAM的投票方式
對間接場景的單個評估
對于直接場景，體系結構設計師需要講清所評估的體系結構如何執(zhí)行這些場景
對于間接場景，體系結構設計師應說明需要對體系結構進行什么修改
對于間接場景，預估修改、涉及到的構件數(shù)量和工作量
評估場景的相互作用
當兩個或多個間接場景要求更改體系結構的一個構件的時候，就稱這些場景在一組構件上相互作用
場景的相互作用暴露了功能分配
語義上不相關的場景相互作用可能說明是功能分離的不夠好
形成總體評估
將場景和業(yè)務目標聯(lián)系起來，評價是否達到標準
基于體系結構的軟件設計方法（ABSD）
設計元素
ABSD是一個遞歸的方法，體系結構通過該方法得到細化直到產(chǎn)生構件和類
視角和視圖
考慮體系結構時，重要的是從不同的視角來檢查，促使設計師考慮體系結構不同的屬性
視圖與4+1模型視圖類似
用例和質(zhì)量屬性
在使用用例捕獲動能需求的同時，通過特定場景來捕獲質(zhì)量需求，這些場景稱為質(zhì)量場景
質(zhì)量場景必須包括預期的刺激和非預期的刺激
ABSD的生命周期
ABSD方法的輸入：
抽象功能需求，包括變化的需求和通用的需求
用例
質(zhì)量因素
約束
ABSD方法定義的設計元素
按照下圖進行分解，一個實際構件反映了一個軟件元素（類）
設計元素的產(chǎn)生順序
廣度遍歷
深度遍歷
設計元素的活動
邏輯視圖、并發(fā)視圖、配置視圖都可以開始
注意：
注重領域知識
新技術的融合
個人經(jīng)驗
反饋環(huán)用于保證各種視圖都在考慮的范圍之內(nèi)
邏輯視圖
創(chuàng)建并發(fā)視圖
創(chuàng)建配置視圖
基于體系結構的軟件開發(fā)模型
體系結構需求
體系結構設計
體系結構文檔化
體系結構需求規(guī)格說明
測試體系結構需求的質(zhì)量設計說明書
體系結構復審
外部人員參加復審（沒參與設計的）
識別潛在風險，發(fā)現(xiàn)設計的錯誤
體系結構實現(xiàn)
體系結構演化
總結
- 上一篇： 软件体系结构基础
- 下一篇： 软件质量管理体系-ISO 9000