1、6.1 基于體系結構的軟件設計方法（ABSD）6.2 基于體系結構的軟件開發模型6.3 軟件體系結構的測試與評估為軟件系統設計一個體系結構不是一件容易的事情，軟件需要長期運行并具有自適應性，它必須支持不斷更新的軟件需求變化軟件體系結構設計是軟件設計初期的工作，一旦出現體系結構層面的設計失誤，很難在軟件開發或運行期間進行有效、低耗的改進為了進行高效的軟件體系結構設計，軟件設計師需要遵照嚴格、有效的設計方法，并關注創造性過程，為處理非確定軟件需求提供策略2Architecture Based Software DesignABSD方法可構造出軟件系統的概念體系結構，描述了系統的主要設計元素及其關系

2、，概念體系結構是達到系統質量需求和商業目標的關鍵，為實現軟件功能奠定基礎設計元素：泛指軟件系統、子系統、構件等體系結構設計中需要處理的各類實體；設計元素有一個概念接口，封裝了輸入輸出數據信息；設計元素是可分解的34軟件模板：描述一類設計元素在重要功能和公共服務等方面的注意事項，如：應具備的核心功能點、異常處理、活動日志與備份、為外部診斷提供測試點等，為合理構建設計元素提供參考5ABSD方法與生命周期：1、功能需求的描述，包括對需求可能變化的粗略描述2、重要的用例3、質量需求的描述，如性能、安全性、可靠性等，通常體現為一定的質量場景描述4、可接受的備選體系結構風格5、約束：人財投入、商業目標、遺

3、留系統約束等6設計元素的分解： 系統 子系統 構件設計元素的產生順序：廣度遍歷 or 深度遍歷關注點：領域知識、新技術的融合、個人經驗7ABSD方法本質上是利用一組需求（功能、性能等）和約束開始分解設計元素，并最終獲得經確認后可行的子設計元素集一個設計元素有一組功能，這些功能必須分組。分解的目的是使每個組在體系結構內代表獨立的元素。分解可以進一步細化。功能分解可參照的幾個標準： （1）功能聚合：高內聚、低耦合 （2）數據或計算行為上有類似模式的功能 （3）類似的抽象級別：硬件、支撐軟件、應用軟件等 （4）功能的局部性：獨立功能 vs. 公共服務功能8每個設計元素有一個主要的體系結構風格，這是設

4、計元素如何完成功能的基礎。主要風格并不是唯一風格，為了達到特定目的，可以進行修改在軟件設計過程中，并不總是有現成的體系結構風格可供選擇為主要的體系結構風格，選定的體系結構風格應滿足軟件相關的質量需求為設計元素選擇體系結構風格是一個重要的選擇，這種選擇在很大程度上依賴于 經驗 和 創造性9任一種體系結構風格都對應著該風格要求的一組構件類型，我們必須決定這些構件的數量及其具體功能，這就是分配的目的在功能分解時產生的功能組，應該分配給選擇體系結構風格時產生的構件類型，這包括決定將存在多少個各構件類型的實例，每個實例將完成什么功能。這樣分配后產生的構件將作為設計元素分解的子設計元素每個設計元素的概念接

5、口也必須得到標識，這個接口包含了設計元素所需的數據和控制流10由于角色和分工不同，整個軟件團隊以及客戶等涉眾各自需要掌握的技術或技能存在很大差異，為了完成各自的工作，他們需要了解整套軟件架構決策的不同子集，所以，應當提供不同的軟件架構視圖，以便于交流和傳遞設計思想重要的視圖包括：開發視圖、運行視圖、部署視圖等11功能校驗：可以通過 用例 或 需求變化 來驗證功能分解的正確性，而設計本身就是顯示需求（通過用例）和支持修改（通過變化因素）驗證質量場景：評價體系結構設計時所作出的各種設計決策，看其是否能夠達到質量屬性的要求。如果不能達到，則需重新考慮并改進體系結構的設計驗證約束：驗證所有的約束是否有

6、可能實現，且沒有互相矛盾的地方121314基于體系結構的軟件開發模型（ABSDM）：1、以體系結構的設計、實現為驅動的軟件開發過程2、更好的支持軟件重用3、體現了迭代開發和體系演化的思想15體系結構需求過程主要是獲取用戶需求，標識系統中所要用到的構件1、需求獲取：包括功能需求和非功能需求（軟件質量）2、標識構件：生成系統的初始邏輯結構3、需求評審：是否滿足用戶要求、構件生成的合理性等161、在體系結構建立初期，選擇一個合適的體系結構風格是首要的。在這個風格基礎上，開發人員通過建立體系結構模型描述，深入理解體系結構2、把在體系結構需求過程中已標識的構件映射到體系結構風格中，將產生一個原型結構。通

7、過其后的構件及關聯分析將產生精化并經評審的可用體系結構17文檔為驗證體系結構設計、提煉或修改這些設計（必要時）所預先執行的基礎性工作體系結構文檔化過程的主要輸出結果是體系結構設計規格說明書，內容主要包括：需求描述、風格設計、視圖描述、構件設計、約束等軟件體系結構的文檔要求與軟件開發項目中的其他文檔是類似的：文檔的完整性、一致性、可讀性、可用性等質量要求的滿足程度是體系結構設計成功的關鍵18體系結構設計、文檔化和復審是一個迭代過程。在一個主版本的軟件體系結構分析之后，要安排一次由內部設計人員和外部人員（用戶、領域專家）參加的復審復審的目的是標識潛在的風險，及早發現體系結構設計中的缺陷和錯誤，包括

8、體系結構能否滿足需求、質量需求是否在設計中得到體現、層次是否清晰、構件的劃分是否合理、文檔表達是否明確、構件的設計是否滿足功能與性能的要求等等191、體系結構的實現過程是以復審后的、文檔化的體系結構說明書為基礎的，其中定義了各構件的功能及構件間的關聯關系2、在體系結構層次上，構件接口約束對外唯一地代表了構件，所以可以從構件庫中查找符合接口約束的構件，必要時開發新的滿足要求的構件201、需求變化歸類：使變化的需求與已有構件對應，或者構造新的構件來滿足變化的需求2、對增加、修改的構件需要進行功能測試，在此基礎上，還需要對組裝后的整體系統進行功能和性能測試21對軟件項目開發而言，一個清晰的體系結構是

9、首要的，但在開發初始階段就設計好系統最終結構是不現實的因此，要求軟件體系結構必須是可演化的，這種演化可基于需求的變化、增進了對系統功能的理解、及對系統實現技術的進一步改進：軟件系統以原型方式演化，體系結構本身也以原型方式演化實驗原型階段（系統功能精確化）演化開發階段（構件精確化）22軟件體系結構測試與程序測試有所不同，它是檢查軟件設計的適用性，而不考慮軟件實現代碼的正確性。體系結構關注系統的總體結構和組裝，如果構件間存在沖突和不一致，那么由此組裝、精化和實現的系統一定不能正確工作因此，體系結構測試主要考慮：構件接口行為與連接件約束是否一致、兼容，構件間的數據消息是否一致且可達，體系結構風格是否

10、滿足需求等測試準則：覆蓋所有的構件及各構件的接口、各連接件的接口、構件之間的直接連接和間接連接23軟件體系結構的測試也可分為三種： 單元測試：對構件本身的測試，涉及的消息流是構件內部的消息，一般由構件開發者完成 集成測試：測試構件之間的接口，以保證構件能夠交互，它將構件本身抽象為單元，并關注構件間的消息傳遞 系統測試：測試整個系統能否正常運行2425怎樣才能知道為軟件系統所選用的體現結構是否恰當？如何確保按照所選用的體系結構能順利地開發出成功的軟件產品？要回答這些問題并不容易，因為受很多因素的影響，需要專門的方法對體系結構進行評估體系結構評估過程中，評估人員所關注的是系統的質量屬性是否得到滿足

11、，包括：性能、可靠性、可用性、安全性、可修改性、功能性、可變性、集成性、互操作性等方面26權衡點：影響多個質量屬性的特性，是多個質量屬性的敏感點。例如，改變加密級別可能會對安全性和性能產生非常重要的影響。提高加密級別可以提高安全性，但可能要耗費更多的處理時間，影響系統性能場景：在進行體系結構評估時，首先要精確地給出具體的質量目標，并以之作為判定該體系結構優劣的標準。我們把為得出這些目標而采用的機制叫做場景，一般采用刺激、環境和響應三方面來對場景進行描述27刺激：場景中解釋或描述風險承擔者怎樣引發與系統的交互部分。例如，用戶可能會激發某個功能，維護人員可能會做某個更改，測試人員可能會執行某種測試等，這些都屬于對場景的刺激。環境：描述刺激發生時的情況。例如，當前系統處于什么狀態？有什么特殊的約束條件？系統的負載是否很大？某個網絡通道是否出現了阻塞等。響應：指系統是如何通過體系結構對刺激作出反應的。例如，用戶所要求的功能是否得到滿足？維護人員的修改是否成功？測試人員的測試是否成功等。28基于調查問卷