軟體開發中會遇到的幾種實用圖例

一、背景

大家應該在從事軟體開發領域工作時間有一段時間之後，就開始有畫圖的意識，不管是懵懂的學別人還是想更好的讓其它人理解自己的一個觀點。所謂“一圖勝千言”，我們身處於軟體開發這個水很深且要求精確的複雜領域裡，要想把事情做好，最基本的是要把事情想明白，其次還要讓相關的人能夠明白你要說的東西，進行協作。

特別對於一位架構師來說，能否畫得一手好圖尤其重要，因為相關的干係人數較多，要讓不同領域的人能夠達成一個統一的認識，是一件不太容易但也是必須要做好的事情。

二、圖為了解決什麼問題

軟體開發涉及的流程是：需求 --> 開發 --> 測試 --> 釋出上線。

作圖本身是個設計的工作，是個前期工作。那麼從軟體開發的整個生命週期來說，用到的圖的地方是在前期的需求、開發階段較多。在軟體開發這個非常抽象的領域，只要涉及到多人協作，那麼透過文字來進行交流敘述是非常晦澀難懂的，需要溝通好幾遍才能理解達成一致也是比較常見的情況。那麼我們畫圖，就是為了把不適合用言語表述的內容透過作圖的方式呈現出來，讓相關協作者有一個共同的具象的參照物。這個參照物可以有它的額外價值，是對軟體長期價值的延伸，一份一致、清晰的設計圖，可以給後續的軟體迭代提供非常有幫助的決策依據。當然保證設計圖與系統的一致本身也是件費精力的事情。

三、不同流程中適合運用的圖

1. 用例圖

用例圖是UML互動圖中的一種，是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的檢視。用例圖（User Case）是外部使用者（被稱為參與者，一般為軟體的面向使用者）所能觀察到的系統功能的模型圖。

適用場景：當新做一個產品或者功能的時候，首先需要明確核心方向，用例圖就是整理這個核心方向的工具。它用來說明的是誰要使用系統，以及他們使用該系統可以做些什麼。可以理解為是MVP思想的寫照，去除畫龍點睛的功能，這些就是基礎、核心。

缺點：僅僅描述的是提供什麼功能，不能表達非功能需求，如可靠性、效能等非功能需求。

2. 魯棒圖（Robustness Diagram）

可能英文名Robustness Diagram更為常見一些，用於銜接用例圖之後的設計，識別出系統在用例圖中的各種職責，對後續的細節設計提供基礎。算是對用例圖的一種延伸。

適用場景：在確立使用者場景之後，如果需要將關鍵功能設計出來，那麼就需要它了。作圖過程中最關鍵的2個點，發現職責，和梳理各個職責之間的關係。

缺點：和用例圖是一樣缺點，唯一的變化是，其有了粗粒度的實現層面的內容。

3. 思維導圖

思維導圖是一個很厲害的發明，他將我們的思考過程具象化了，完美展示了由點到面不斷髮散的過程。但是它最大的價值，反而不是最終呈現出來的這個圖，而是促進了思考的過程。並且需要注意的是，一定要把一條分支走到盡頭，再回過頭來走其它的分支，把思想榨乾。 

適用場景：在一個事情剛開始的萌芽期，不知如何下手；或者陷入一個困境的時候。利用思維導圖來活躍大腦，進行發散思維。這時候如果結合頭腦風暴，效果更佳。

缺點：它是一種樹狀的資訊分層視覺化展視，結構比較固定，不適合分支間互相互動比較複雜的資訊展示。

4. DFD（Data Flow Diagram）圖

DFD圖是從資料傳遞和加工角度，以圖形方式來表達系統的邏輯功能、資料在系統內部的邏輯流向和邏輯變換過程，是結構化系統分析方法的主要表達工具及用於表示軟體模型的一種圖示方法。

適用場景：在將思維導圖得出的東西進行整合、梳理形成一個粗粒度的流程。這個其實類似與DDD中的上下文對映圖，是在需求分析過程中做宏觀設計的一種方式。

缺點：反映系統“做什麼”，不反映“如何做”，粒度算是中等，需要其它更細粒度的圖來對細節做支撐。

5. 流程圖

上面貼了2張圖都是流程圖，流程圖有時也稱作輸入-輸出圖。該圖直觀地描述一個工作過程的具體步驟，各種操作一目瞭然，不會產生“歧義性”，便於理解，演算法出錯時容易發現。流程圖對準確瞭解事情是如何進行的，以及決定應如何改進過程極有幫助。大到系統級別、小到某個操作背後的運轉邏輯都可以使用流程圖來畫，我個人認為這應該是被最多人認識的圖，沒有之一。

適用場景：正如上面所說這個適用場景比較廣，日常工作中小到演算法邏輯，大到戰略層面的執行落地都需要它。主要用它來將背後的流程視覺化，輔助做決策去（如改進等）。

缺點：所佔篇幅較大，由於允許使用流程線，過於靈活，不受約束，使用者可使流程任意轉向，從而造成程式閱讀和修改上的困難，不利於結構化程式的設計。

6. UML類圖

UML類圖是UML互動圖中的一種，也是我們較常見的一種。類圖是描述系統中的類，以及各個類之間的關係的靜態檢視。它不但是設計人員關心的核心，更是實現人員關注的核心。

適用場景：一般作為編碼前做的最後一步，將設計轉為相應的模型。也可以使用Code First的方式直接在專案中建模，現在的VS也支援直接從程式碼中生成UML類圖。

缺點：缺點就是畫起來太費時間了，但反過來其表達的粒度更細緻，是程式碼實現級別的內容。由於現在有比較多的工具可以從程式碼生成UML類圖，甚至在大部分提倡使用Code First的場景下，我們畫UML類圖的機會是越來越少了。

7. 狀態圖

狀態圖是對類圖的補充。描述類的物件所有可能的狀態，以及事件發生時狀態的轉移條件。可以捕獲物件、子系統和系統的生命週期。他們可以告知一個物件可以擁有的狀態，並且事件(如訊息的接收、時間的流逝、錯誤、條件變為真等)會怎麼隨著時間的推移來影響這些狀態。一個狀態圖應該連線到所有具有清晰的可標識狀態和複雜行為的類；該圖可以確定類的行為，以及該行為如何根據當前的狀態變化，也可以展示哪些事件將會改變類的物件的狀態。

適用場景：當有一個物件擁有多個狀態的時候，想要表達清楚狀態之間的演變關係（也就是這個物件的生命週期）。比如透過什麼條件觸發狀態變動的，到達某個狀態之後會做什麼動作等。這也是基於事件驅動設計的良好視覺化圖。

缺點：僅能表達行為/事件與狀態之間的演變關係，不適用於其它領域。

8. E-R圖

E-R圖提供了表示實體型(Entity)、屬性(Attribute)和聯絡(Relationship)的方法。其中最核心的還屬聯絡(Relationship)的表示。

適用場景：雖然在UML類圖中，也可以體現出聚合、依賴等關係。但是如果相關聯的模型數量巨大的話，你會發現看起來特別費勁，要縮的很小才能看清全貌。這時候你需要E-R圖出場了。

缺點：相對類圖來說，E-R圖無法定義類/實體的行為。它更面向資料庫而不是程式碼。

9.UML時序圖

時序圖也是UML互動圖中的一種，是描述物件是如何互動的，並且將重點放在訊息序列上。也就是說，描述訊息是如何在物件間傳送和接收的。時序圖有兩個座標軸：縱座標軸顯示時間，橫座標軸顯示物件。

適用場景：一般當我們想反映一個包含順序的互動流程，比如http請求的生命週期、頁面上某個按鈕背後流轉細節等情況時，就需要它了。

缺點：一個時序圖僅能面向一個Case，同時畫起來比較費時間。

四、實際的運用

其實上一節中圖的順序就是按照由層次從高到底，粒度從粗到細規劃的。我們可以用用例圖來確定使用者核心需求，再用Robustness Diagram定義好關鍵功能，隨後在關鍵功能的實現上透過思維導圖進行發散，然後用DFD圖把粗粒度的內容串起來，至此大體的設計工作算是完成了。

然後再透過流程圖、UML類圖、狀態圖、E-R圖、時序圖在不同的場景確定細節實現。最終就是Coding的事情了。

至於每個圖繪畫的規範網上資料比較多，這裡就不贅述了。如果大家有什麼疑問繼續交流。

五、結語

其實最好的圖是手稿，不但畫起來快，還能讓你的思維專注到構思上，用什麼顏色 之類的問題不會對你產生干擾。另外我們不要為了畫圖而畫圖，結合實際的情況把握好尺度，一般情況下，時間上不太會允許我們把圖畫的面面俱到，能覆蓋到核心甚至80%就很好了。

載自：windy

力軟敏捷開發框架