軟件開(kāi)發(fā)中會(huì)用到的幾張圖
本文長(zhǎng)度為3237字，預(yù)計(jì)讀完需918.42KB流量，建議閱讀10分鐘。來(lái)源：跨界架構(gòu)師
一、背景
大家應(yīng)該在從事軟件開(kāi)發(fā)領(lǐng)域工作時(shí)間有一段時(shí)間之后，就開(kāi)始有畫圖的意識(shí)，不管是懵懂的學(xué)別人還是想更好的讓其它人理解自己的一個(gè)觀點(diǎn)。所謂“一圖勝千言”，我們身處于軟件開(kāi)發(fā)這個(gè)水很深且要求精確的復(fù)雜領(lǐng)域里，要想把事情做好，最基本的是要把事情想明白，其次還要讓相關(guān)的人能夠明白你要說(shuō)的東西，進(jìn)行協(xié)作。
特別對(duì)于一位架構(gòu)師來(lái)說(shuō)，能否畫得一手好圖尤其重要，因?yàn)橄嚓P(guān)的干系人數(shù)較多，要讓不同領(lǐng)域的人能夠達(dá)成一個(gè)統(tǒng)一的認(rèn)識(shí)，是一件不太容易但也是必須要做好的事情。
二、圖為了解決什么問(wèn)題
軟件開(kāi)發(fā)涉及的流程是：需求 --> 開(kāi)發(fā) --> 測(cè)試 --> 發(fā)布上線。作圖本身是個(gè)設(shè)計(jì)的工作，是個(gè)前期工作。那么從軟件開(kāi)發(fā)的整個(gè)生命周期來(lái)說(shuō)，用到的圖的地方是在前期的需求、開(kāi)發(fā)階段較多。在軟件開(kāi)發(fā)這個(gè)非常抽象的領(lǐng)域，只要涉及到多人協(xié)作，那么通過(guò)文字來(lái)進(jìn)行交流敘述是非?；逎y懂的，需要溝通好幾遍才能理解達(dá)成一致也是比較常見(jiàn)的情況。那么我們畫圖，就是為了把不適合用言語(yǔ)表述的內(nèi)容通過(guò)作圖的方式呈現(xiàn)出來(lái)，讓相關(guān)協(xié)作者有一個(gè)共同的具象的參照物。這個(gè)參照物可以有它的額外價(jià)值，是對(duì)軟件長(zhǎng)期價(jià)值的延伸，一份一致、清晰的設(shè)計(jì)圖，可以給后續(xù)的軟件迭代提供非常有幫助的決策依據(jù)。當(dāng)然保證設(shè)計(jì)圖與系統(tǒng)的一致本身也是件費(fèi)精力的事情。
三、不同流程中適合運(yùn)用的圖
1.用例圖
用例圖是UML交互圖中的一種，是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的視圖。用例圖（User Case）是外部用戶（被稱為參與者，一般為軟件的面向用戶）所能觀察到的系統(tǒng)功能的模型圖。
適用場(chǎng)景：當(dāng)新做一個(gè)產(chǎn)品或者功能的時(shí)候，首先需要明確核心方向，用例圖就是整理這個(gè)核心方向的工具。它用來(lái)說(shuō)明的是誰(shuí)要使用系統(tǒng)，以及他們使用該系統(tǒng)可以做些什么?？梢岳斫鉃槭荕VP思想的寫照，去除畫龍點(diǎn)睛的功能，這些就是基礎(chǔ)、核心。
缺點(diǎn)：僅僅描述的是提供什么功能，不能表達(dá)非功能需求，如可靠性、性能等非功能需求。
2.魯棒圖（Robustness Diagram）
可能英文名Robustness Diagram更為常見(jiàn)一些，用于銜接用例圖之后的設(shè)計(jì)，識(shí)別出系統(tǒng)在用例圖中的各種職責(zé)，對(duì)后續(xù)的細(xì)節(jié)設(shè)計(jì)提供基礎(chǔ)。算是對(duì)用例圖的一種延伸。
適用場(chǎng)景：在確立用戶場(chǎng)景之后，如果需要將關(guān)鍵功能設(shè)計(jì)出來(lái)，那么就需要它了。作圖過(guò)程中最關(guān)鍵的2個(gè)點(diǎn)，發(fā)現(xiàn)職責(zé)，和梳理各個(gè)職責(zé)之間的關(guān)系。
缺點(diǎn)：和用例圖是一樣缺點(diǎn)，唯一的變化是，其有了粗粒度的實(shí)現(xiàn)層面的內(nèi)容。
?
3.思維導(dǎo)圖
思維導(dǎo)圖是一個(gè)很厲害的發(fā)明，他將我們的思考過(guò)程具象化了，完美展示了由點(diǎn)到面不斷發(fā)散的過(guò)程。但是它最大的價(jià)值，反而不是最終呈現(xiàn)出來(lái)的這個(gè)圖，而是促進(jìn)了思考的過(guò)程。并且需要注意的是，一定要把一條分支走到盡頭，再回過(guò)頭來(lái)走其它的分支，把思想榨干。?
適用場(chǎng)景：在一個(gè)事情剛開(kāi)始的萌芽期，不知如何下手；或者陷入一個(gè)困境的時(shí)候。利用思維導(dǎo)圖來(lái)活躍大腦，進(jìn)行發(fā)散思維。這時(shí)候如果結(jié)合頭腦風(fēng)暴，效果更佳。
缺點(diǎn)：它是一種樹(shù)狀的信息分層可視化展視，結(jié)構(gòu)比較固定，不適合分支間互相交互比較復(fù)雜的信息展示。
4.DFD（Data Flow Diagram）圖
DFD圖是從數(shù)據(jù)傳遞和加工角度，以圖形方式來(lái)表達(dá)系統(tǒng)的邏輯功能、數(shù)據(jù)在系統(tǒng)內(nèi)部的邏輯流向和邏輯變換過(guò)程，是結(jié)構(gòu)化系統(tǒng)分析方法的主要表達(dá)工具及用于表示軟件模型的一種圖示方法。
適用場(chǎng)景：在將思維導(dǎo)圖得出的東西進(jìn)行整合、梳理形成一個(gè)粗粒度的流程。這個(gè)其實(shí)類似與DDD中的上下文映射圖，是在需求分析過(guò)程中做宏觀設(shè)計(jì)的一種方式。
缺點(diǎn)：反映系統(tǒng)“做什么”，不反映“如何做”，粒度算是中等，需要其它更細(xì)粒度的圖來(lái)對(duì)細(xì)節(jié)做支撐。
?
5.流程圖
?
上面貼了2張圖都是流程圖，流程圖有時(shí)也稱作輸入-輸出圖。該圖直觀地描述一個(gè)工作過(guò)程的具體步驟，各種操作一目了然，不會(huì)產(chǎn)生“歧義性”，便于理解，算法出錯(cuò)時(shí)容易發(fā)現(xiàn)。流程圖對(duì)準(zhǔn)確了解事情是如何進(jìn)行的，以及決定應(yīng)如何改進(jìn)過(guò)程極有幫助。大到系統(tǒng)級(jí)別、小到某個(gè)操作背后的運(yùn)轉(zhuǎn)邏輯都可以使用流程圖來(lái)畫，我個(gè)人認(rèn)為這應(yīng)該是被最多人認(rèn)識(shí)的圖，沒(méi)有之一。
適用場(chǎng)景：正如上面所說(shuō)這個(gè)適用場(chǎng)景比較廣，日常工作中小到算法邏輯，大到戰(zhàn)略層面的執(zhí)行落地都需要它。主要用它來(lái)將背后的流程可視化，輔助做決策去（如改進(jìn)等）。
缺點(diǎn)：所占篇幅較大，由于允許使用流程線，過(guò)于靈活，不受約束，使用者可使流程任意轉(zhuǎn)向，從而造成程序閱讀和修改上的困難，不利于結(jié)構(gòu)化程序的設(shè)計(jì)?！ ?/p>
?
6.UML類圖
UML類圖是UML交互圖中的一種，也是我們較常見(jiàn)的一種。類圖是描述系統(tǒng)中的類，以及各個(gè)類之間的關(guān)系的靜態(tài)視圖。它不但是設(shè)計(jì)人員關(guān)心的核心，更是實(shí)現(xiàn)人員關(guān)注的核心。
適用場(chǎng)景：一般作為編碼前做的最后一步，將設(shè)計(jì)轉(zhuǎn)為相應(yīng)的模型。也可以使用Code First的方式直接在項(xiàng)目中建模，現(xiàn)在的VS也支持直接從代碼中生成UML類圖。
缺點(diǎn)：缺點(diǎn)就是畫起來(lái)太費(fèi)時(shí)間了，但反過(guò)來(lái)其表達(dá)的粒度更細(xì)致，是代碼實(shí)現(xiàn)級(jí)別的內(nèi)容。由于現(xiàn)在有比較多的工具可以從代碼生成UML類圖，甚至在大部分提倡使用Code First的場(chǎng)景下，我們畫UML類圖的機(jī)會(huì)是越來(lái)越少了。
?
7.狀態(tài)圖
狀態(tài)圖是對(duì)類圖的補(bǔ)充。描述類的對(duì)象所有可能的狀態(tài)，以及事件發(fā)生時(shí)狀態(tài)的轉(zhuǎn)移條件?？梢圆东@對(duì)象、子系統(tǒng)和系統(tǒng)的生命周期。他們可以告知一個(gè)對(duì)象可以擁有的狀態(tài)，并且事件(如消息的接收、時(shí)間的流逝、錯(cuò)誤、條件變?yōu)檎娴?會(huì)怎么隨著時(shí)間的推移來(lái)影響這些狀態(tài)。一個(gè)狀態(tài)圖應(yīng)該連接到所有具有清晰的可標(biāo)識(shí)狀態(tài)和復(fù)雜行為的類；該圖可以確定類的行為，以及該行為如何根據(jù)當(dāng)前的狀態(tài)變化，也可以展示哪些事件將會(huì)改變類的對(duì)象的狀態(tài)。
適用場(chǎng)景：當(dāng)有一個(gè)對(duì)象擁有多個(gè)狀態(tài)的時(shí)候，想要表達(dá)清楚狀態(tài)之間的演變關(guān)系（也就是這個(gè)對(duì)象的生命周期）。比如通過(guò)什么條件觸發(fā)狀態(tài)變動(dòng)的，到達(dá)某個(gè)狀態(tài)之后會(huì)做什么動(dòng)作等。這也是基于事件驅(qū)動(dòng)設(shè)計(jì)的良好可視化圖。
缺點(diǎn)：僅能表達(dá)行為/事件與狀態(tài)之間的演變關(guān)系，不適用于其它領(lǐng)域。
?
8.E-R圖
E-R圖提供了表示實(shí)體型(Entity)、屬性(Attribute)和聯(lián)系(Relationship)的方法。其中最核心的還屬聯(lián)系(Relationship)的表示。
適用場(chǎng)景：雖然在UML類圖中，也可以體現(xiàn)出聚合、依賴等關(guān)系。但是如果相關(guān)聯(lián)的模型數(shù)量巨大的話，你會(huì)發(fā)現(xiàn)看起來(lái)特別費(fèi)勁，要縮的很小才能看清全貌。這時(shí)候你需要E-R圖出場(chǎng)了。
缺點(diǎn)：相對(duì)類圖來(lái)說(shuō)，E-R圖無(wú)法定義類/實(shí)體的行為。它更面向數(shù)據(jù)庫(kù)而不是代碼。
?
9.UML時(shí)序圖
時(shí)序圖也是UML交互圖中的一種，是描述對(duì)象是如何交互的，并且將重點(diǎn)放在消息序列上。也就是說(shuō)，描述消息是如何在對(duì)象間發(fā)送和接收的。時(shí)序圖有兩個(gè)坐標(biāo)軸：縱坐標(biāo)軸顯示時(shí)間，橫坐標(biāo)軸顯示對(duì)象。
適用場(chǎng)景：一般當(dāng)我們想反映一個(gè)包含順序的交互流程，比如http請(qǐng)求的生命周期、頁(yè)面上某個(gè)按鈕背后流轉(zhuǎn)細(xì)節(jié)等情況時(shí)，就需要它了。
缺點(diǎn)：一個(gè)時(shí)序圖僅能面向一個(gè)Case，同時(shí)畫起來(lái)比較費(fèi)時(shí)間。
四、實(shí)際的運(yùn)用
其實(shí)上一節(jié)中圖的順序就是按照由層次從高到底，粒度從粗到細(xì)規(guī)劃的。我們可以用用例圖來(lái)確定用戶核心需求，再用Robustness Diagram定義好關(guān)鍵功能，隨后在關(guān)鍵功能的實(shí)現(xiàn)上通過(guò)思維導(dǎo)圖進(jìn)行發(fā)散，然后用DFD圖把粗粒度的內(nèi)容串起來(lái)，至此大體的設(shè)計(jì)工作算是完成了。
然后再通過(guò)流程圖、UML類圖、狀態(tài)圖、E-R圖、時(shí)序圖在不同的場(chǎng)景確定細(xì)節(jié)實(shí)現(xiàn)。最終就是Coding的事情了。
至于每個(gè)圖繪畫的規(guī)范網(wǎng)上資料比較多，這里就不贅述了。如果大家有什么疑問(wèn)繼續(xù)交流。
五、結(jié)語(yǔ)
其實(shí)最好的圖是手稿，不但畫起來(lái)快，還能讓你的思維專注到構(gòu)思上，用什么顏色之類的問(wèn)題不會(huì)對(duì)你產(chǎn)生干擾。另外我們不要為了畫圖而畫圖，結(jié)合實(shí)際的情況把握好尺度，一般情況下，時(shí)間上不太會(huì)允許我們把圖畫的面面俱到，能覆蓋到核心甚至80%就很好了。
?
本文中部分內(nèi)容引用自如下地址，感謝分享：
????1.https://www.zhihu.com/question/22253854??匿名用戶
????2.https://www.zhihu.com/question/31998535/answer/54270159??張恂老師
????3.http://blog.csdn.net/t131452n/article/details/41381393??
優(yōu)質(zhì)文章，推薦閱讀：
