軟件架構設計方法理論TYYGROUPsystemofficeroom【TYYUA16H-TYY-TYYYUA8Q8-軟件架構概述什么是軟件架構◎軟件架構的概念很混亂。如果你問五個不同的人，可能會得到五種不同的答案。◎軟件架構概念主要分為兩大流派：組成派：軟件架構=組件+交互。決策派：軟件架構=重要決策集。◎組成派和決策派的概念相輔相成。軟件架構和子系統、框架之間的關系◎復雜性是層次化的。◎好的架構設計必須把變化點錯落有致地封裝到軟件系統的不同部分(即關注點分離)。通過關注點分離，達到“系統中的一部分發生了變化，不會影響其他部分”的目標。◎軟件單元的粒度：*粒度最小的單元通常是“類”。*幾個類緊密協作形成“模塊”。*完成相對獨立的功能的多個模塊構成了“子系統”。*多個子系統相互配合才能滿足一個完整應用的需求，從而構成了軟件“系統”。*一個大型企業往往使用多套系統，多套系統通過互操作形成“集成系統”。◎軟件單元的粒度是相對的。同一個軟件單元，在不同場景下我們會以不同的粒度看待它。◎架構(Architecture)不等于框架(Framework)。框架只是一種特殊的軟件，框架也有架構。◎可以通過架構框架化達到“架構重用”的目的，如很多人都在用Spring框架提供的控制反轉和依賴注入來構建自己的架構。軟件架構的作用◎如果一個項目的系統架構(包括理論基礎)尚未確定，就不應該進行此系統的全面開發。一BarryBoehm,《EngineeringContext》◎一個缺陷充斥的系統，將始終是一個缺陷充斥的系統。一TimothyC.Lethbridge,《面向對象軟件工程》◎軟件架構設計為什么這么難？因為它是跨越現實世界與計算機世界之間鴻溝的一座橋。軟件架構設計要完成從面向業務到面向技術的轉換，在鴻溝上架起一座橋梁。需求->架構設計->軟件架構->系統開發->軟件系統◎軟件架構對新產品開發的作用：*上承業務目標。*下接技術決策。*控制復雜性。先進行架構設計，后進行詳細設計和編碼實現，符合“基于問題深度分而治之”的理念。*組織開發。軟件架構方案在小組中間扮演了“橋梁”和“合作契約”的作用。*利于迭代開發和增量交付。以架構為中心進行開發，為增量交付提供了良好的基礎。在架構經過驗證之后，可以專注于功能的增量提交。*提高質量。◎軟件架構對軟件產品線開發的作用:*固化核心知識；*提供可重用資產；*縮短推出產品的周期；*降低開發和維護成本；*提高產品質量；*支持批量定制。◎軟件產品線：指具有一組可管理的、公共特性的、軟件密集性系統的集合，這些系統滿足特定的市場需求或任務需求，并且按照預定義方式從一個公共的核心資產集開發得到。軟件產品線架構：針對一個公司或組織內的一系列產品而設計的通用架構。軟件架構設計方法軟件架構為誰而設計◎架構師應當為項目相關的不同角色而設計：*架構師要為客戶負責，滿足他們的業務目標和約束條件。*架構師要為用戶負責，滿足他們關心的功能需求和運行期質量屬性。*架構師必須顧及處于協作分工“下游”的開發人員。*架構師必須考慮“周邊”的管理人員，為他們進行分工管理、協調控制和評估監控等工作提供清晰的基礎。五視圖法◎什么是軟件架構視圖？軟件架構視圖是對于從某一視角看到的系統所作的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了與此無關的其他方面。◎軟件架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力范圍，因此宜采用“分而治之”的辦法。即通過不同的視圖來描述架構。◎軟件架構的五視圖法：*邏輯架構邏輯架構關注功能。其設計著重考慮功能需求。開發架構開發架構關注程序包。其設計著重考慮開發期質量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。運行架構運行架構關注進程、線程、對象等運行時概念，以及相關的并發、同步、通信等問題。其設計著重考慮運行期質量屬性，例如性能、可伸縮性、持續可用性和安全性等。*物理架構物理架構關注軟件系統最終如何安裝或部署到物理機器。其設計著重考慮“安裝和部署需求”。*數據架構數據架構關注持久化數據的存儲方案。其設計著重考慮“數據需求”。從概念性架構到實際架構◎少就是多(Lessismore.)。一密斯?凡德羅◎概念性架構是對系統設計的最初構想。◎一般來說，實際的軟件架構設計過程是，先進行概念性架構的設計，把最關鍵的設計要素和交互機制確定下來，然后再考慮具體技術的運用，設計出實際架構。架構設計中的關鍵要素及解決策略

◎策略是制勝的關鍵。--張明正，《擋不住的趨勢》◎最好的軟件開發人員都知道一個秘密：美的東西比丑的東西創建起來更廉價，也更快捷。一RobertC.Martin,《軟件之美》◎時間就是系統架構的生命。一PhilippeKruchten◎方法產生于恐懼。◎面對時間緊迫的壓力，我們有理由質疑那種不顧時間花銷、一味追求軟件架構高質量的做法。軟件架構是軟件系統質量的核心，必須足夠重視，但在不適當的時候“用時間換完美”會毀掉整個項目。◎架構設計并非“好的就是成功的”，而是“適合的才是成功的”。◎軟件架構設計中的關鍵要素及解決策略：關鍵要素策略全面認識需求。關鍵需求決定架構。多視圖探尋架構。及早驗證架構。全面認識需求。關鍵需求決定架構。多視圖探尋架構。及早驗證架構。能否馴服數量巨大且頻繁變化的需求?能否從容地設計軟件架構的不同方面?是否及早驗證架構方案并作出了調整?軟件架構要設計到什么程度◎軟件系統的架構涵蓋了整個系統，盡管架構的有些部分可能只有“一寸深”。--IvarJacobson,《統一軟件開發過程之路》◎軟件架構是團隊開發的基礎。◎軟件架構要設計到什么程度？*由于項目的不同、開發團隊情況的不同，軟件架構的設計程度會有不同。*軟件架構應當為開發人員提供足夠的指導和限制。◎高來高去式架構設計的癥狀：*缺失重要架構視圖。遺漏了某些重要視圖，從而遺漏了對團隊某些角色的指導。*淺嘗輒止、不夠深入。將重大技術風險遺留到后續開發中。*名不副實的分層架構。對各層之間交互接口和交互機制的設計嚴重不足。軟件架構設計過程軟件架構設計過程總覽◎一般的軟件過程：概念化階段->分析階段->架構設計階段->并行開發與測試階段->驗收與交付階段1111111111愿景需求架構可執行系統交付的系統◎軟件架構設計過程：需求分析->領域建模->確定關鍵需求->概念性架構設計->細化架構->驗證架構II概念性架構實際架構分析階段架構設計階段需求分析3.2.1幾個概念◎需求捕獲vs需求分析vs系統分析*需求捕獲是獲取知識的過程，知識從無到有。*需求分析是挖掘和整理知識的過程，它在巳掌握知識的基礎上進行。*系統分析？如果說需求分析致力于“做什么”，那么系統分析則涉及“怎么做”。3.2.2架構師必須掌握的需求知識◎軟件架構師不必是需求捕獲專家，也不必是編寫《軟件需求規格說明書》的專家。但他一定應在需求分類、需求折衷和需求變更的研究方面是專家，否則他和其他軟件架構師相比，就輸在了“起跑線”上。◎軟件需求的類型廠功能需求廠運行期質量屬性軟件需求T廠質量屬性TL非功能需求TL開發期質量屬性L約束◎軟件質量屬性分類方式運行期質量屬性性能(Performance)安全性(Security)易用性(Usability)*持續可用性(Availability)可伸縮性(Scalability)互操作性(Interoperability)可靠性(Reliability)魯棒性(Robustness)開發期質量屬性易理解性(Understandability)可擴展性(Extensibility)可重用性(Reusability)可測試行(Testability)可維護性(Maintainability)可移植性(Portability)領域建模◎就像《高效能人士的七個習慣》提到的“有內而外全面造就自己”的觀點一樣，對待軟件開發，要具備“有內而外造就軟件”的理念。◎想讓軟件系統隨需應變嗎？請給軟件一個支持變化的“心”。◎什么是領域模型？領域模型是對實際問題領域的抽象表示，它專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系。◎領域建模和需求分析活動是相互伴隨、互相支持、交疊演進的。◎領域模型對軟件架構乃至整個軟件系統開發工作的作用：*探索復雜問題、固化領域知識；*決定功能范圍、影響可擴展性；*提供交流基礎、促進有效溝通。確定關鍵需求◎功能、質量和商業需求的某個集合“塑造”了架構。--LenBass,《軟件架構實踐（第2版）》◎關鍵需求決定架構，其余需求驗證架構。◎什么是對軟件架構關鍵的需求？*關鍵的功能需求。*關鍵的質量屬性需求。*關鍵的商業需求。◎如何確定關鍵需求？廠〉確定關鍵功能需求r?-＞全面整理需求-〉分析約束性需求T卜〉?L＞確定關鍵質量屬性需求」概念性架構設計◎概念性架構設計的步驟（這三個步驟以迭代方式進行）:魯棒性分析；引入架構模式；質量屬性分析。3.5.1魯棒性分析◎所謂魯棒性分析是這樣一種方法：通過分析用例規約中的事件流，識別出實現用例規定的功能所需的主要對象及其職責，形成以職責模型為主的初步設計。◎魯棒性分析是從功能需求向設計方案過度的第一步，所獲得的初步設計是一種理想化的職責模型，它的重點是識別組成軟件系統的高級職責塊、規劃它們之間的關系。◎魯棒性分析填補了分析和設計之間的鴻溝。◎魯棒圖包含三種元素：邊界對象、控制對象和實體對象。（見書P196）引入架構模式◎較為經典的幾種架構模式：分層、MVC、微內核、基于元模型的架構、管道-過濾器。◎關于架構模式的幾點說明：分層避免名不副實的分層架構，即對各層之間交互接口和交互機制的設計嚴重不足。微內核缺點：設計和實現的復雜性；性能較低。優點：擴展性強，可移植性強，軟件系統的生命周期長。質量屬性分析◎“屬性-場景-決策”表方法。舉例如下：111屬性1場景11111決策111111可擴展性1數據庫類型可替換1L111建立數據庫存取層1_|1II允許加載第三方模塊I采用插件機制II...細化架構設計◎架構細化工作主要體現在基于五視圖方法進行架構細化:約束I領域模型->I基于五視圖方法I關鍵需求->II->架構方案概念架構->I進行架構細化If經驗◎架構細化設計的工作內容:1I架構設計視圖111I設計任務I111I邏輯架構III111I細化功能單元；II發現通用機制；II細化領域模型；II確定子系統接口和交互機制。I111I開發架構II111I確定要開發或直接利用的程序包之間的依賴關系；II確定采用的技術；II確定采用的框架等。I111I數據架構I111I持久化數據存儲方案；II數據傳遞、數據復制、數據同步等策略(可選)。I111I運行架構III111I確定引入哪些進程與線程；II確定主動對象、被動對象，以及控制關系；II處理進程線程的創建、銷毀、通信機制、資源爭用等；II協議設計。I111I物理架構I111I確定物理配置方案；II確定如何將目標程序映射到物理節點。I11◎邏輯架構設計中，“發現通用機制”是應被特別強調的。機制(Mechanism)是模式的實例。機制是特定上下文中重復出現的問題的特定解決方案。具有良好架構的系統具備概念完整性。它通過對系統架構建立一種清晰的認識來發現通用的抽象和機制。利用這種共性使最終產生的系統結構更為簡單。實現并驗證軟件架構◎好的策略必須是一再求證、測試、發現瑕疵漏洞，另想途徑或方法來彌補策略不足，有時甚至得全盤放棄，重新策劃。--張明正，《擋不住的趨勢》◎架構原型對功能性需求的實現