【新東網(wǎng)技術(shù)大咖帶您走進(jìn)軟件架構設計】軟件架構設計那點(diǎn)事兒

發(fā)布時(shí)間： 2016-11-18 12:04:02  

分享到：

文/鄭實(shí) 通信研發(fā)部

計算系統的軟件構架是指該系統的一個(gè)或多個(gè)結構，它由軟件組件、組件的外部可見(jiàn)特性以及這些組件之間的關(guān)系組成。

系統架構設計一般分為三個(gè)階段

本階段是架構實(shí)踐中最常見(jiàn)的短板，這一階段的目的是分析業(yè)務(wù)需求和約束背后的衍生需求、發(fā)現遺漏需求、確定關(guān)鍵功能、確定關(guān)鍵質(zhì)量、權衡質(zhì)量屬性之間的矛盾關(guān)系。

系統架構設計失敗的原因，最常見(jiàn)的有以下幾個(gè)：

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

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

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

4. 不能驗證架構并作出調整（失敗率約40%）；

這些導致業(yè)主方得不到真正滿(mǎn)足他們需求的系統，因此我們在架構準備階段要確定系統關(guān)鍵質(zhì)量和關(guān)鍵功能。

確定關(guān)鍵質(zhì)量有以下五大原則：

1. 考慮多方涉眾

業(yè)主方不僅關(guān)注功能，同時(shí)也需要質(zhì)量。業(yè)主方關(guān)注的質(zhì)量可能包括易用性、性能、持續可用性、穩定性和健壯性等。業(yè)主方不一定是最終用戶(hù)，比如電信網(wǎng)上營(yíng)業(yè)廳系統的客戶(hù)是電信公司，但最終用戶(hù)可能是終端用戶(hù)或系統配置員，他們所關(guān)注的質(zhì)量屬性可能并不一致。

2. 檢查性思維

隨時(shí)檢查各個(gè)質(zhì)量屬性，判定每一項是否確實(shí)算得上“關(guān)鍵質(zhì)量”，從而防止遺漏關(guān)鍵需求。

3. 識別矛盾+劃定優(yōu)先級；

4. 嚴格程度符合領(lǐng)域與規模特點(diǎn)；

5. 關(guān)鍵質(zhì)量屬性個(gè)數根據項目、產(chǎn)品、平臺不同而不同。

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

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

概要架構可分為3個(gè)步驟：

1. 基于關(guān)鍵功能（而不是對所有功能）、借助魯棒圖（而不是序列圖）進(jìn)行初步設計；

2. 綜合初步設計確定高層分割；

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

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

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

在細化架構中，接口占據非常核心的地位，而概念架構并不關(guān)心明確的接口定義（只有抽象的組件和抽象的交互機制）。

細化架構重視通過(guò)子系統和模塊來(lái)分割整個(gè)系統，并且子系統往往有明確的接口；而概念架構中只有抽象的組件，這些組件沒(méi)有接口。

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

細化架構包括邏輯架構、物理架構、運行架構、開(kāi)發(fā)架構、數據架構。

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