極客時間《架構(gòu)師訓(xùn)練營》第一章學(xué)習(xí)筆記
什么是軟件架構(gòu)
軟件架構(gòu)是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計(jì) ——維基百科
軟件架構(gòu)包括上圖的系統(tǒng)、架構(gòu)、文檔、相關(guān)方等等元素。任何系統(tǒng)，無論大小皆擁有軟件架構(gòu)，并且需要做專門的軟件設(shè)計(jì)。軟件設(shè)計(jì)真正目的其實(shí)是降低成本，因?yàn)樵O(shè)計(jì)成本一般會低于實(shí)現(xiàn)。當(dāng)然，軟件設(shè)計(jì)的核心并不在于系統(tǒng)或是架構(gòu)本身，而在于利益相關(guān)方（stakeholder）。在軟件設(shè)計(jì)的不同時段，設(shè)計(jì)文檔應(yīng)該根據(jù)評審的參與者（相關(guān)方）的不同，應(yīng)用不同的設(shè)計(jì)圖紙。
架構(gòu)師就是這個軟件設(shè)計(jì)的負(fù)責(zé)人，職責(zé)便是通過架構(gòu)設(shè)計(jì)理清業(yè)務(wù)邏輯：對上交給組織一份宏觀的系統(tǒng)概況；對下幫助開發(fā)人員降低噪音，提高軟件開發(fā)效率和質(zhì)量。
架構(gòu)視圖
軟件架構(gòu)包括：元素、形式、關(guān)系/約束。由于單一的視圖很難完整地表述架構(gòu)，所以需要多種形式的圖紙來表述各個方面的設(shè)計(jì)意圖，因此需要一份完備的視圖集，業(yè)界常采用的方法就是4+1 視圖。
4+1 視圖分別是：
- 邏輯視圖：設(shè)計(jì)的對象模型
- 過程視圖：撲捉設(shè)計(jì)的并發(fā)和同步特征
- 物理視圖：描述軟件到硬件的映射，反映了部署特征
- 開發(fā)視圖：描述開發(fā)環(huán)境中，軟件的靜態(tài)組織結(jié)構(gòu)
- 場景視圖：描述用例的場景
UML 模型
建模是對一個系統(tǒng)的完整抽象；在計(jì)算機(jī)開發(fā)中，實(shí)現(xiàn)從領(lǐng)域問題到計(jì)算機(jī)系統(tǒng)的映射，以便從抽象出更易得的解決方案。UML 就是在面向?qū)ο箝_發(fā)中最常用的建模手段。UML 圖有大約 10 種，其中常用的有 7 種，這些例圖可以映射上文提到的 4+1 視圖。
-
UML 中的通用元素有：類、對象、節(jié)點(diǎn)、包、組件等等：
UML元素 -
元素之間的關(guān)系又有：關(guān)聯(lián)、依賴、泛化、聚合等等：
UML關(guān)系 UML 中的消息：簡單消息、同步消息、異步消息
用例圖
Use Case 是系統(tǒng)分析階段最常用的模式。在宏觀上給出系統(tǒng)的總體輪廓，一般是 PM 來寫。每個 Use Case 的元素不宜過多，總數(shù)控制在十個左右；可以自頂而下逐步細(xì)化。
時序圖
時序圖用以描述對象之間的動態(tài)交互行為，是穿插于開發(fā)各個階段重要的視圖。時序圖有兩個軸：橫軸表示對象；縱軸表示時間。
時序圖有兩種形式，一般格式和實(shí)例格式：
- 一般格式：描述所有情節(jié)，包括分支、條件和循環(huán)，比較復(fù)雜
- 實(shí)例格式：描述一次可能的交互，沒有分支判斷，僅僅顯示特定情節(jié)的交互
泳道圖
泳道圖是活動圖里最常使用的視圖。它用以描述完成活動的對象以及活動；泳道圖的最大特色就是顯示分組機(jī)制，可以描述跨系統(tǒng)的交互互動：
狀態(tài)圖
狀態(tài)圖用來描述特定對象的所有可能態(tài)，是 PM 在需求設(shè)計(jì)階段重要的工具，開發(fā)階段會進(jìn)一步把狀態(tài)圖的內(nèi)容轉(zhuǎn)化為特定的方法和條件判斷：
組件圖 & 部署圖
組件圖和部署圖提供了物理層面的建模，描述子系統(tǒng)間的關(guān)系，是架構(gòu)師最早該寫的一份視圖：
視圖與整體設(shè)計(jì)
開發(fā)的不同階段，我們可以依據(jù)不同的現(xiàn)實(shí)，書寫不同的視圖，下面是各個階段常用到的視圖：
需求分析階段： 用例圖、活動圖、狀態(tài)圖、時序圖
概要設(shè)計(jì)階段（子系統(tǒng)級別）：部署圖（架構(gòu)師第一張圖）、序圖、活動圖、組件圖、時序圖
詳細(xì)設(shè)計(jì)階段（方法和類級別）：類圖、時序圖、狀態(tài)圖、活動圖
當(dāng)然，視圖的意義不在于多，而在于正確的抽象業(yè)務(wù)；以最少的視圖抽象出最完整的現(xiàn)實(shí)，才是一個架構(gòu)師的能力所在。
小結(jié)
第一周的課程除了開場白之外，主要還是集中在怎么寫架構(gòu)設(shè)計(jì)文檔上，其中 UML 建模是課程的重中之重吧。架構(gòu)設(shè)計(jì)文檔是團(tuán)隊(duì)中交流、協(xié)同工作的重要依據(jù)；熟練掌握這些技能，可以極大的改善開發(fā)體驗(yàn)；當(dāng)然也是架構(gòu)師的一項(xiàng)必備技能。
這次課程中，老師提到了一個很有趣的現(xiàn)象：很多中小企業(yè)在開發(fā)階段是完全沒有架構(gòu)設(shè)計(jì)文檔的。一不小心被說中了，我廠就是這種現(xiàn)狀——開發(fā)全靠“口口相傳”；上了一次課，感觸還是挺深刻的。之后的工作中，我也想慢慢嘗試加入 UML 設(shè)計(jì)；人微言輕，自然很難改變一個團(tuán)隊(duì)的氛圍，但至少自己的代碼要為自己負(fù)責(zé)。
