[轉]對軟件架構設計的一些總結和理解

時間 2019-11-10

標籤軟件架構設計一些總結理解欄目系統架構简体版

原文原文鏈接

本文轉自：http://blog.csdn.net/cooldragon/article/details/48241965前端

1. 軟件架構設計的What & Why

● 啥是軟件架構（Software Architecture）？數據庫

軟件架構是指在必定的設計原則基礎上，從不一樣角度對組成系統的各部分進行搭配和安排，造成系統的多個結構而組成架構，它包括該系統的各個組件，組件的外部可見屬性及組件之間的相互關係。組件的外部可見屬性是指其餘組件對該組件所作的假設。後端

軟件架構設計就是從宏觀上說明一套軟件系統的組成與特性。瀏覽器

軟件架構設計是一系列有層次的決策，好比：功能與展示的決策；技術架構的決策；自主研發仍是合做；商業軟件仍是開源軟件。安全

● 爲啥要進行軟件架構設計？網絡

業務需求層出不窮；軟件系統愈來愈複雜；參與的人愈來愈多；共性和特殊性的問題愈來愈多；技術發展日異月新；……架構

2. 軟件架構師

2.1. 軟件架構師是幹什麼的

介於需求與開發的中間人	良好的溝通能力
可以統領全局的大牛	良好的大局觀
可以將需求轉換爲技術	洞悉前沿與市場嗅覺
可以爲軟件研發提供指導	見多識廣的大牛
須要全面思考軟件系統方方面面的問題	縝密地思考問題
可以攻關和搞定重要技術難題	公司可信賴的支柱

2.2. 架構師的素質

全局思惟併發	從業務、市場，到技術實現；框架從軟件的過去、如今，到未來；異步從外部客戶，到內部研發；從軟件研發，到硬件部署；從功能實現，到運行效率
戰略思惟	在所在行業的發展戰略；在業務領域的發展戰略；在技術方向的發展戰略；在潛在市場的發展戰略。
前瞻思惟	市場趨勢的發展動向；前沿技術的發展動向；競爭對手的發展動向；合做夥伴的發展動向。
抽象思惟	各項業務需求：抽象成功能模塊；各項功能的實現：抽象成軟件架構。
逆向思惟	假如不實現會怎樣？假如沒搞定會怎樣？假如沒有它會怎樣？假如被延期會怎樣？

2.3. 架構師的分類

隨着行業和社會的發展，架構師的定義和分類愈來愈普遍和細分，普遍和細分其實並不矛盾，若是「普遍」是x軸，「細分」是y軸，則二維座標系x和y軸中間的任一點就是一種架構師類別。但整體來講，或目前來講，集合業界的大體認知，總結以下：

No.	分類	描述
1	解決方案架構師	與客戶探討業務需求，將業務、市場，與技術、產品結合起來，爲客戶提供解決他們需求的方案。
2	系統架構師	也稱應用架構師。最終確認和評估系統需求，並將業務轉換爲技術，爲研發人員制訂核心框架與技術規範爲研發工做澄清技術細節並掃清技術障礙。
3	平臺架構師	這裏的平臺其實包括兩個平臺，一個是系統平臺，也就是負責搭建多個系統整合的系統應用平臺；另一個實際上是基礎平臺，是專門負責搭建基礎技術平臺；二者其實區別蠻大，也常常容易被從業人員混亂。舉個簡單例子，金蝶有平臺架構師一職，可是金蝶BOSS應用和金蝶中間件二者招聘的對象和技術要求是大相徑庭的。
4	業務架構師	業務架構其實已經開始脫離技術層面了，可是它要求架構師有跨越多系統的大局觀，去整合和組織不一樣系統的技術平臺與交互模式。其實這個職位的將來也就是CIO了。
5	網絡架構師	過去，咱們可能聽的最多的是網絡工程師。不錯，一個優秀的網絡架構師必須有足夠的網絡技術基底，而且它的關注點也是系統的基礎架構。好比說若是搭建並優化集羣環境，若是構建基於雲計算的系統應用與部署等等。它對於像淘寶、騰訊這樣的互聯網公司是極其重要的。
6	移動架構師	移動互聯網的迅猛發展橫向和縱向都細分出了不少新的職責和崗位，移動架構師的職責和做用日益重要，既要總體和全局考慮整個先後端的軟件系統架構，又要重點深刻移動客戶端的架構設計的方方面面，既要有跨平臺思惟，又要拿捏好原生和混合開發的尺度，另外移動應用的特色，致使移動架構師必需要比傳統系統架構師更加註重非功能性的質量屬性。
7	前端架構師	這也是移動互聯網的迅猛發展而細分出來的新的職責和崗位，這裏的前端特指網站開發中的前端，主要考慮前端呈現層的設計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設計等等。
8	...	...

3. 軟件需求

軟件架構設計中常說需求驅動架構設計，可見需求在整個架構設計中起到了關鍵指引和方向的做用，若是以目標導向爲原則，則需求的知足和實現就是架構設計的終極目標。 OK，在進行架構設計以前，咱們先看下軟件需求。

3.1. 軟件需求怎麼來的（軟件需求的過程）

階段	需求階段	說明	什麼人作什麼事		可能產生的文檔
階段	需求階段	說明	客戶方	實施方	客戶方	實施方
1	業務需求	來自客戶的原始需求，背景描述，業務訴求和指望目標。	項目負責人或接口人描述需求或提供客戶方需求文檔。	銷售或售前接觸客戶，聽取和記錄需求。	工做說明書（SOW），或邀標書	售前的方案建議書
2	用戶需求	一般是在問題定義的基礎上進行用戶訪談、調查，對用戶使用的場景進行整理，從而創建從用戶角度的需求。	項目負責人或接口人接受訪談和調研。	需求分析師或項目經理等進行需求調研。		調研計劃、用戶需求調研提問庫、調研日誌、用戶需求說明書
3	軟件需求	從系統實現的角度描述的需求。開發人員（設計和分析人員）在業務需求、用戶需求的基礎上造成的。		需求分析師或項目經理、架構師等討論和細化需求，編寫需求文檔		SRS（Software Requirement Specification）軟件需求規格說明書

3.2. 軟件需求的分類：

另外，也有McCall軟件質量模型：

注：在架構設計中，對非功能性需求的重視程度，也會影響架構設計的好與劣；但也要平衡過渡設計和適可而止的關係。

4. 軟件架構的過程

業界軟件架構設計的方法論不少，各有各自的應用場景和特色，下文結合ADMEMS（Architecture Design Method has been Extended to Method System）架構設計方法論說明軟件架構的過程：

架構階段	目標	方式方法	現實工做場景
預架構階段	全面理解需求；需求結構化，摒棄「需求列表」，創建二維需求觀（ADMEMS矩陣）。	使用ADMEMS矩陣方法，捋清需求間關係和發現衍生需求。	一、與人：與項目經理、需求分析師等內部需求人員瞭解需求；與客戶瞭解需求（不建議架構師作需求分析師角色）。二、與物：瞭解《需求規格說明書》等需求文檔。" 三、對需求有什麼問題，反饋給售前或銷售，可能會參與拜訪客戶或電話會議。四、銷售或售前有時會要求提供一個大體的工做量，以便他們初步評估項目可行性。
概念架構	高層組件及其關係	一、初步設計，基於關鍵功能，藉助魯棒圖進行以發現職責爲目的的初步設計（不是必須）。二、高層分割，將複雜系統切分爲多個二級系統或多個子系統。三、考慮非功能需求，採用ADMEMS推薦的目標-場景-決策表。	一、參與內部討論：項目可行性分析、討論，從需求、技術、人力、風險等角度提供建議。二、項目投標準備：參與投標團隊的技術方案編寫，編寫系統架構章節，解決招標書上技術問題的問答。三、參與項目講標：做爲講標團隊成員參與項目講標，負責技術問答環節的應對。
細化架構		5視圖法	在項目概要設計階段，進行架構設計，制定規範和約定，爲詳細設計提供指導。
實現	詳細設計編碼實現	架構設計造成詳細設計文檔	在項目實現階段，對開發人員提供規範指引和技術支持。

注：架構設計的過程和內容的不是固定不變的，現實中，好比售前提供解決方案中，不少時候須要架構師提供細化架構中才會深思的邏輯架構、物理架構等，這時候，架構師就須要有螺旋思惟和跳躍思惟的方式，就像武功中，招式是死的，人是活的，要學會靈活運用。

5. 軟件架構設計的方式方法

5.1. 多視圖法

多視圖方法是業界普遍認同的一種架構設計思路，包括： ● SEI的3視圖法：模塊視圖、組件-鏈接器視圖、分配視圖。 ● 西門子的4視圖法：概念視圖、模塊視圖、代碼視圖、執行視圖。 ● RUP的4+1視圖法：用例視圖、邏輯視圖、開發視圖、進程視圖、物理視圖。 ● 聯邦企業架構框架：技術架構視圖、信息架構視圖、應用架構視圖、業務架構視圖。 ● ……

5.2. 5視圖法

5視圖法分析的意義：

● 全面分析軟件系統方方面面的問題 ● 儘早地發現和排除項目風險與不肯定因素 ● 從不一樣角度去展示要設計的軟件系統 ● 爲項目進行中不一樣的干係人提供指導： -- 邏輯架構描述系統功能，並指導系統測試 -- 開發架構規範軟件的層次及代碼風格 -- 數據架構指導數據庫的設計 -- 運行架構定義了一些關鍵過程的設計 -- 物理架構明確軟件如何部署與實施

5.3. 5視圖法設計步驟

兩種觀念：

觀念	設計步驟
觀念一	順序進行：一、邏輯架構。二、開發架構三、數據架構四、運行架構五、物理架構
觀念二	5個視圖是穿插進行設計的，對複雜系統而言，根本不可能將邏輯視圖設計完了後再考慮其它視圖。
筆者觀念	觀念一和觀念二的狀況在現實情況中均可能存在，要根據具體狀況具體分析，但整體而言，5視圖穿插進行思考更有利於思考的全局性和完整性。

5.4. 如何進行5視圖法的設計

如下5視圖表格中的工具和方法每一個架構師或略有差別，如下僅爲參考。

5.4.1. 邏輯架構

邏輯架構的重點是考慮軟件功能性需求。

No.	考慮的方面	產出物	工具	說明
1	系統功能劃分爲幾個子系統與功能模塊？	系統功能樹	樹型結構圖
2	向什麼用戶提供什麼樣的功能？	用例模型	UML用例圖	體現用戶和行爲
3	每一個功能都是怎樣的操做流程與分支？	用例描述	用例描述表	含輸入輸出、事件流分析；不要有界面描述
3	每一個功能都是怎樣的操做流程與分支？	用例描述	UML活動圖	進行業務流程分析，包括泳道圖
4	如何經過界面與用戶交互？怎樣交互？	魯棒分析	魯棒圖	經過對「用例描述表」進行原文分析法揀出名詞和動詞
5	應當設計哪些類與界面？怎樣設計？	領域模型	UML類圖
6	與哪些外部系統接口？怎樣接口？	接口描述	UML類圖

5.4.2. 開發架構

開發架構重點關注的是開發編碼實現方面的問題。

No.	考慮的方面	產出物	工具	說明
1	分層結構設計	分層架構圖（開發架構圖）	各類繪圖工具	好的分層結構支持自動化測試
2	開發技術選項	開發語言開發框架開發工具		考慮商用產品、開源框架、自研框架
3	模塊劃分	源碼工程；Project目錄結構；分包(分庫)
4	開發規範	開發/編碼規範文檔；
5	軟件質量屬性	分析和決策結果		考慮運行期和開發期軟件質量屬性，並權衡利弊進行決策。

5.4.3. 數據架構

數據架構不只僅要考慮開發中涉及到的數據庫，實體模型，也要考慮物理架構中數據存儲的設計。

No.	考慮的方面	產出物	工具	說明
1	數據是集中仍是分佈存儲的？如何考慮分佈式存儲？	數據架構圖
2	領域模型到數據庫表的轉換？表結構關係的設計？	邏輯模型物理模型 ER圖	Power Designer Visio
3	實體如何設計？充血模型和貧血模型？	UML類圖
4	使用什麼數據庫？關係型仍是非關係型？	選型結果

關係型數據庫

非關係型數據庫（NoSQL）

Oracle（首次發行：1980年）

MySQL（首次發行：1995）

MS SQL Server（首次發行：1989）

PostgreSQL（首次發行：1989）

IBM DB2（首次發行：1983）

Microsoft Access（首次發行：1992）

Sybase ASE（首次發行：1987）

SQLite（首次發行：2000）

……

MongoDB（首次發行：2009）

Cassandra（首次發行：2008）

Apache CouchDB

Hbase

Redis

db4o

BaseX

……

5.4.4. 運行架構

運行架構關注的再也不是全局而是局部，着重關注那些關鍵點與難點，經常須要技術攻關與預研。主要考慮控制流、通信機制、資源爭用、鎖機制、同步異步、併發、串行，同時也要考慮質量屬性。

No.	考慮的方面	產出物	工具	說明
1	運行：同步vs.異步；併發vs.串行	考慮開發架構中代碼的實現。
2	交互：對象間交互；狀態轉換	考慮開發架構的合理性，到類、到接口、到代碼。
3	質量：安全；可靠；可伸縮	考慮開發架構的合理性
4	性能：響應時間；吞吐量	估算：在線人數、併發人數；每秒事務量；響應時間。

5.4.5. 物理架構

物理架構主要考慮硬件選擇和拓撲結構，軟件到硬件的映射，軟硬件的相互影響。

	考慮的方面	產出物	工具	說明
1	網絡方面：網絡拓撲；網絡設備；安全機制	拓撲圖安全規範
2	性能方面：可靠性、可伸縮性	須要什麼樣設備性能
3	部署方面：集中式仍是分佈式；組件部署	部署圖

6. 一個思考，誰驅動了架構設計？

需求驅動了架構設計？

質量屬性了驅動了架構設計（ADD）？

領域驅動了架構設計（DDD）？

風險驅動了架構設計？

質疑驅動了架構設計？

……

究竟是誰驅動了架構設計？咱們以船舶設計建造爲例，來看這些問題：

目標和結果 à	問題 à	回答 à	小結
設計和製造一艘遠洋貨輪，能經歷數月海上顛簸和長途跋涉，並保證貨物的安全和完整，最後能順利抵達目標港口。	咱們爲何要設計和製造這樣的大船？	市場有這個需求；獲利很豐厚；解決就業； ……	無論是外部需求仍是內部的需求，都是需求。不正是需求驅動嗎？
	如何保證貨船能長途航行並經受波濤和風雨？	船要造的結實；	魯棒性	這些不正是質量屬性驅動設計嗎？
		引擎設計的強勁；	性能
		船的燃料充足；	持續可用性
		裝備衛星電話、GPS、雷達等設備	互操做性
		貨物和人員要安全	安全性
	船舶設計師怎麼設計這樣的船舶？	如今都會經過計算機進行船舶的CAD和3D模型設計。	是否是佷似領域模型驅動了設計？
	造船必定有不少風險吧？	那是，好比定貨方客戶有時提出改裝船舶的意見（需求變化的風險）；有時某些工藝成品率不穩定（質量風險）；等等。	全部可能的風險點在設計時都要考慮到，作好預案，才能保證架構設計的可行性和靈活性，風險驅動了架構設計。
	上面怎麼提了那麼多問題，其實還有不少問題，好比……	嗯，你如今有很多疑問了。	不斷的質疑架構設計中可能存在各類問題，有質疑纔有思考，纔有解決方案，從而推進架構設計的不斷完善。