第7章 基于體系結(jié)構(gòu)的軟件開發(fā)

第六章基于體系結(jié)構(gòu)的軟件開發(fā)6.1基于體系結(jié)構(gòu)的軟件設計方法（ABSD）6.2基于體系結(jié)構(gòu)的軟件開發(fā)模型6.3軟件體系結(jié)構(gòu)的測試與評估軟件體系結(jié)構(gòu)設計為軟件系統(tǒng)設計一個體系結(jié)構(gòu)不是一件容易的事情，軟件需要長期運行并具有自適應性，它必須支持不斷更新的軟件需求變化軟件體系結(jié)構(gòu)設計是軟件設計初期的工作，一旦出現(xiàn)體系結(jié)構(gòu)層面的設計失誤，很難在軟件開發(fā)或運行期間進行有效、低耗的改進為了進行高效的軟件體系結(jié)構(gòu)設計，軟件設計師需要遵照嚴格、有效的設計方法，并關注創(chuàng)造性過程，為處理非確定軟件需求提供策略2基于體系結(jié)構(gòu)的軟件設計方法ArchitectureBasedSoftwareDesignABSD方法可構(gòu)造出軟件系統(tǒng)的概念體系結(jié)構(gòu)，描述了系統(tǒng)的主要設計元素及其關系，概念體系結(jié)構(gòu)是達到系統(tǒng)質(zhì)量需求和商業(yè)目標的關鍵，為實現(xiàn)軟件功能奠定基礎設計元素：泛指軟件系統(tǒng)、子系統(tǒng)、構(gòu)件等體系結(jié)構(gòu)設計中需要處理的各類實體；設計元素有一個概念接口，封裝了輸入輸出數(shù)據(jù)信息；設計元素是可分解的3設計元素示例4軟件模板：描述一類設計元素在重要功能和公共服務等方面的注意事項，如：應具備的核心功能點、異常處理、活動日志與備份、為外部診斷提供測試點等，為合理構(gòu)建設計元素提供參考5ABSD方法與生命周期：1、功能需求的描述，包括對需求可能變化的粗略描述2、重要的用例3、質(zhì)量需求的描述，如性能、安全性、可靠性等，通常體現(xiàn)為一定的質(zhì)量場景描述4、可接受的備選體系結(jié)構(gòu)風格5、約束：人財投入、商業(yè)目標、遺留系統(tǒng)約束等輸入輸出ABSD方法的目標6設計元素的分解：

系統(tǒng)→子系統(tǒng)→構(gòu)件設計元素的產(chǎn)生順序：廣度遍歷or深度遍歷關注點：領域知識、新技術的融合、個人經(jīng)驗ABSD方法的步驟7ABSD方法本質(zhì)上是利用一組需求（功能、性能等）和約束開始分解設計元素，并最終獲得經(jīng)確認后可行的子設計元素集ABSD方法

之功能分解一個設計元素有一組功能，這些功能必須分組。分解的目的是使每個組在體系結(jié)構(gòu)內(nèi)代表獨立的元素。分解可以進一步細化。功能分解可參照的幾個標準：（1）功能聚合：高內(nèi)聚、低耦合（2）數(shù)據(jù)或計算行為上有類似模式的功能（3）類似的抽象級別：硬件、支撐軟件、應用軟件等（4）功能的局部性：獨立功能vs.公共服務功能8ABSD方法

之選擇體系結(jié)構(gòu)風格每個設計元素有一個主要的體系結(jié)構(gòu)風格，這是設計元素如何完成功能的基礎。主要風格并不是唯一風格，為了達到特定目的，可以進行修改在軟件設計過程中，并不總是有現(xiàn)成的體系結(jié)構(gòu)風格可供選擇為主要的體系結(jié)構(gòu)風格，選定的體系結(jié)構(gòu)風格應滿足軟件相關的質(zhì)量需求為設計元素選擇體系結(jié)構(gòu)風格是一個重要的選擇，這種選擇在很大程度上依賴于經(jīng)驗和創(chuàng)造性9ABSD方法

之為風格分配功能任一種體系結(jié)構(gòu)風格都對應著該風格要求的一組構(gòu)件類型，我們必須決定這些構(gòu)件的數(shù)量及其具體功能，這就是分配的目的在功能分解時產(chǎn)生的功能組，應該分配給選擇體系結(jié)構(gòu)風格時產(chǎn)生的構(gòu)件類型，這包括決定將存在多少個各構(gòu)件類型的實例，每個實例將完成什么功能。這樣分配后產(chǎn)生的構(gòu)件將作為設計元素分解的子設計元素每個設計元素的概念接口也必須得到標識，這個接口包含了設計元素所需的數(shù)據(jù)和控制流10ABSD方法

之視圖描述由于角色和分工不同，整個軟件團隊以及客戶等涉眾各自需要掌握的技術或技能存在很大差異，為了完成各自的工作，他們需要了解整套軟件架構(gòu)決策的不同子集，所以，應當提供不同的軟件架構(gòu)視圖，以便于交流和傳遞設計思想重要的視圖包括：開發(fā)視圖、運行視圖、部署視圖等11ABSD方法

之設計確認功能校驗：可以通過用例或需求變化來驗證功能分解的正確性，而設計本身就是顯示需求（通過用例）和支持修改（通過變化因素）驗證質(zhì)量場景：評價體系結(jié)構(gòu)設計時所作出的各種設計決策，看其是否能夠達到質(zhì)量屬性的要求。如果不能達到，則需重新考慮并改進體系結(jié)構(gòu)的設計驗證約束：驗證所有的約束是否有可能實現(xiàn)，且沒有互相矛盾的地方12基于體系結(jié)構(gòu)的軟件開發(fā)模型1314基于體系結(jié)構(gòu)的軟件開發(fā)模型（ABSDM）：1、以體系結(jié)構(gòu)的設計、實現(xiàn)為驅(qū)動的軟件開發(fā)過程2、更好的支持軟件重用3、體現(xiàn)了迭代開發(fā)和體系演化的思想體系結(jié)構(gòu)需求分析15體系結(jié)構(gòu)需求過程主要是獲取用戶需求，標識系統(tǒng)中所要用到的構(gòu)件1、需求獲?。喊üδ苄枨蠛头枪δ苄枨螅ㄜ浖|(zhì)量）2、標識構(gòu)件：生成系統(tǒng)的初始邏輯結(jié)構(gòu)3、需求評審：是否滿足用戶要求、構(gòu)件生成的合理性等體系結(jié)構(gòu)設計161、在體系結(jié)構(gòu)建立初期，選擇一個合適的體系結(jié)構(gòu)風格是首要的。在這個風格基礎上，開發(fā)人員通過建立體系結(jié)構(gòu)模型描述，深入理解體系結(jié)構(gòu)2、把在體系結(jié)構(gòu)需求過程中已標識的構(gòu)件映射到體系結(jié)構(gòu)風格中，將產(chǎn)生一個原型結(jié)構(gòu)。通過其后的構(gòu)件及關聯(lián)分析將產(chǎn)生精化并經(jīng)評審的可用體系結(jié)構(gòu)體系結(jié)構(gòu)文檔化17文檔為驗證體系結(jié)構(gòu)設計、提煉或修改這些設計（必要時）所預先執(zhí)行的基礎性工作體系結(jié)構(gòu)文檔化過程的主要輸出結(jié)果是體系結(jié)構(gòu)設計規(guī)格說明書，內(nèi)容主要包括：需求描述、風格設計、視圖描述、構(gòu)件設計、約束等軟件體系結(jié)構(gòu)的文檔要求與軟件開發(fā)項目中的其他文檔是類似的：文檔的完整性、一致性、可讀性、可用性等質(zhì)量要求的滿足程度是體系結(jié)構(gòu)設計成功的關鍵體系結(jié)構(gòu)的復審18體系結(jié)構(gòu)設計、文檔化和復審是一個迭代過程。在一個主版本的軟件體系結(jié)構(gòu)分析之后，要安排一次由內(nèi)部設計人員和外部人員（用戶、領域?qū)＜遥﹨⒓拥膹蛯弿蛯彽哪康氖菢俗R潛在的風險，及早發(fā)現(xiàn)體系結(jié)構(gòu)設計中的缺陷和錯誤，包括體系結(jié)構(gòu)能否滿足需求、質(zhì)量需求是否在設計中得到體現(xiàn)、層次是否清晰、構(gòu)件的劃分是否合理、文檔表達是否明確、構(gòu)件的設計是否滿足功能與性能的要求等等