【新(xīn)東網技(jì )術大咖帶您走進軟件架構設計】軟件架構設計那點事兒

發布時間： 2016-11-18 12:04:02  

分(fēn)享到：

文(wén)/鄭實 通信研發部

計算系統的軟件構架是指該系統的一個或多(duō)個結構，它由軟件組件、組件的外部可(kě)見特性以及這些組件之間的關系組成。

系統架構設計一般分(fēn)為(wèi)三個階段

本階段是架構實踐中(zhōng)最常見的短闆，這一階段的目的是分(fēn)析業務(wù)需求和約束背後的衍生需求、發現遺漏需求、确定關鍵功能(néng)、确定關鍵質(zhì)量、權衡質(zhì)量屬性之間的矛盾關系。

系統架構設計失敗的原因，最常見的有(yǒu)以下幾個：

1. 遺漏至關重要的架構影響因素（失敗率約50%）；

2. 不能(néng)馴服頻繁變化的需求（失敗率約40%）；

3. 不能(néng)覆蓋架構各方面（失敗率約30%）；

4. 不能(néng)驗證架構并作(zuò)出調整（失敗率約40%）；

這些導緻業主方得不到真正滿足他(tā)們需求的系統，因此我們在架構準備階段要确定系統關鍵質(zhì)量和關鍵功能(néng)。

确定關鍵質(zhì)量有(yǒu)以下五大原則：

1. 考慮多(duō)方涉衆

業主方不僅關注功能(néng)，同時也需要質(zhì)量。業主方關注的質(zhì)量可(kě)能(néng)包括易用(yòng)性、性能(néng)、持續可(kě)用(yòng)性、穩定性和健壯性等。業主方不一定是最終用(yòng)戶，比如電(diàn)信網上營業廳系統的客戶是電(diàn)信公(gōng)司，但最終用(yòng)戶可(kě)能(néng)是終端用(yòng)戶或系統配置員，他(tā)們所關注的質(zhì)量屬性可(kě)能(néng)并不一緻。

2. 檢查性思維

随時檢查各個質(zhì)量屬性，判定每一項是否确實算得上“關鍵質(zhì)量”，從而防止遺漏關鍵需求。

3. 識别矛盾+劃定優先級；

4. 嚴格程度符合領域與規模特點；

5. 關鍵質(zhì)量屬性個數根據項目、産(chǎn)品、平台不同而不同。

确定關鍵功能(néng)要區(qū)分(fēn)出核心功能(néng)、必做功能(néng)、高風險功能(néng)、獨特功能(néng)。關鍵功能(néng)子集的确定不存在所謂的标準答(dá)案，關鍵功能(néng)所占比例應靈活确定，大概占20%~30%。

本階段是大型系統成敗關鍵，根據重大需求，确定概要架構。概要架構要滿足“架構=組件+交互”的基本定義，對高層組件的“職責”進行籠統界定，并給出高層組件的相互關系，不應涉及接口細節。實際上，架構設計的驅動力是“功能(néng)+質(zhì)量+約束”，概要架構階段根據重大需求、特殊需求、高風險需求形成穩定的高層架構設計成果。

概要架構可(kě)分(fēn)為(wèi)3個步驟：

1. 基于關鍵功能(néng)（而不是對所有(yǒu)功能(néng)）、借助魯棒圖（而不是序列圖）進行初步設計；

2. 綜合初步設計确定高層分(fēn)割；

3. 考慮非功能(néng)性需求做出相應決策，非功能(néng)性需求包括可(kě)用(yòng)性、安(ān)全性、性能(néng)、易用(yòng)性、可(kě)修改性、可(kě)測試性等，架構設計更應該關注非功能(néng)性需求，考慮非功能(néng)性需求要趁早。

本階段是團隊大規模并行開發基礎階段，要細化架構設計，關注不同視圖。在概念架構階段輸出系統解決方案，但是方案并不等同于架構。方案是“項目+需求+架構”的總覽，方案包含一定的架構内容，但是架構設計的工(gōng)作(zuò)還遠(yuǎn)未完成，還需細化架構。

細化架構與概念架構是存在差異的。

在細化架構中(zhōng)，接口占據非常核心的地位，而概念架構并不關心明确的接口定義（隻有(yǒu)抽象的組件和抽象的交互機制）。

細化架構重視通過子系統和模塊來分(fēn)割整個系統，并且子系統往往有(yǒu)明确的接口；而概念架構中(zhōng)隻有(yǒu)抽象的組件，這些組件沒有(yǒu)接口。

細化架構基于接口編程、消息機制或遠(yuǎn)程方法調用(yòng)進行實在的交互；而概念架構的交互是“概念化”的，如“A層使用(yòng)B層服務(wù)”。

細化架構包括邏輯架構、物(wù)理(lǐ)架構、運行架構、開發架構、數據架構。

最後在架構設計過程中(zhōng)要持續貫穿關注非功能(néng)需求，包括可(kě)用(yòng)性、安(ān)全性、性能(néng)、易用(yòng)性、可(kě)修改性、可(kě)測試性等，架構設計應該關注非功能(néng)性需求，更要提前關注非功能(néng)性需求。它是一個系統是否可(kě)用(yòng)、好用(yòng)的關鍵，也是一個系統架構設計是否成功的關鍵。