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

1、背景

你們應該在從事軟件開發領域工做時間有一段時間以後，就開始有畫圖的意識，不論是懵懂的學別人仍是想更好的讓其餘人理解本身的一個觀點。所謂「一圖勝千言」，咱們身處於軟件開發這個水很深且要求精確的複雜領域裏，要想把事情作好，最基本的是要把事情想明白，其次還要讓相關的人可以明白你要說的東西，進行協做。

特別對於一位架構師來講，可否畫得一手好圖尤爲重要，由於相關的干係人數較多，要讓不一樣領域的人可以達成一個統一的認識，是一件不太容易但也是必需要作好的事情。

2、圖爲了解決什麼問題

軟件開發涉及的流程是：需求 --> 開發 --> 測試 --> 發佈上線。

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

3、不一樣流程中適合運用的圖

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，同時畫起來比較費時間。

4、實際的運用

其實上一節中圖的順序就是按照由層次從高到底，粒度從粗到細規劃的。咱們能夠用用例圖來肯定用戶核心需求，再用Robustness Diagram定義好關鍵功能，隨後在關鍵功能的實現上經過思惟導圖進行發散，而後用DFD圖把粗粒度的內容串起來，至此大致的設計工做算是完成了。

而後再經過流程圖、UML類圖、狀態圖、E-R圖、時序圖在不一樣的場景肯定細節實現。最終就是Coding的事情了。

至於每一個圖繪畫的規範網上資料比較多，這裏就不贅述了。若是你們有什麼疑問繼續交流。

5、結語

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

載自：windy