大家在擼代碼之前會進行業(yè)務系統(tǒng)流程設計么？你們在設計的時候又用到了哪些工具呢？

大家好，我是老貓。今天和大家分享一下程序員日常的繪圖思路，以及一些老貓日常使用的繪圖工具。

為什么要畫圖？

我們在進行系統(tǒng)設計的時候，為了更加具象地呈現(xiàn)系統(tǒng)的輪廓以及各個組件或者系統(tǒng)之間的關系和邊界以及工作流程。我們就會畫邏輯架構圖，模塊圖、流程圖、時序圖等等。

在日常開發(fā)中，軟件設計圖是一種非常好的表達方式，尤其在技術評審的時候，一副好的設計圖可能比干巴巴的文字更能說明問題。正所謂“一圖勝千言”。

軟件工程中的繪圖

不知道大家有沒有聽說過“4+1”模型。其實在很早的時候，大概1995年的時候，Philippe Kruchten在IEEE Software上就發(fā)表了“The 4+1 View Model of Architecture”的論文。這篇論文引起了極大的關注，最終被RUP采納。

“4+1”咱們來看一下下圖。

分別解釋一下：

1、場景視圖：主要用于系統(tǒng)參與者和功能之間的關系，老貓理解一般由用例圖組成。

2、邏輯視圖：描述軟件拆解之后的組件關系、組件約束和邊界，反映系統(tǒng)整體組成和系統(tǒng)構建，通常由組件圖和類圖自稱。

3、物理視圖：描述系統(tǒng)軟件到物理硬件的映射關系，主要指軟件的部署架構圖，這里老貓的理解是可能運維人員更需要關注。

4、處理流程：主要描述軟件組件之間的通信時序以及輸入輸出，反映系統(tǒng)功能流程和數(shù)據(jù)流程，這里咱們可以用時序圖以及流程圖來表示。

5、開發(fā)視圖：描述系統(tǒng)的業(yè)務模塊劃分以及內(nèi)部的組成設計，反映系統(tǒng)的開發(fā)實施過程。

老貓之前寫過一篇文章【新接手一個業(yè)務系統(tǒng)，我是這么熟悉的】。這篇文章的寫作思路，主要也是從上面這些點切入去寫的。

開發(fā)人員如何繪制技術評審的圖？

工作這么多年之后，老貓發(fā)現(xiàn)，寫代碼的時候其實是最安逸的時候，只要事先方案設計得好，流程繪制得精準，模型設計得合理。戴上耳機寫代碼就是一種享受。因為寫代碼的時候只要對著設計稿去擼就好了。

那么咱們在做技術方案設計的時候應該從哪些點去切入進行畫設計圖呢？老貓日常的繪圖思路主要是從整體到局部，從概要到細節(jié)，到最終的模型落地。

例如關于設計支付系統(tǒng)，咱們先把各個系統(tǒng)之間關系以及功能模塊梳理清楚，讓參與評審的人能夠對支付系統(tǒng)的架構有個整體的認知。具體如下：

通過上面的的圖，可以表示清楚系統(tǒng)和系統(tǒng)之間的層級關系，可以讓評審人一目了然地知道，你當前所設計的系統(tǒng)在整個架構領域屬于那一塊。另外的話也能夠讓人清晰地感知每個系統(tǒng)的主要的功能是什么。

接下來的設計就是開始局部設計。局部設計的話一般需要理清楚功能點，以及整體的業(yè)務流程。我們挑一個下單支付的流程，簡單繪制一下業(yè)務流程。具體如下：

當然上面的電商下單支付交易流程還是比較粗的，看起來還是不夠細，另外的也沒有達到對著流程圖就能進行開發(fā)的地步。當然上述的流程圖可能并沒有涉及到相關的泳道，老貓只是粗略地展現(xiàn)一下大概的意思。關于實際的場景中，大家還是需要根據(jù)自己的業(yè)務邏輯進行梳理繪制。

再細化一些，那就是加上泳道，然后體現(xiàn)出不同的系統(tǒng)的內(nèi)部流程。如下圖：

當繪制到這里的時候，其實咱們距離最終的寫代碼還差一點了，那就是細致的時序邏輯。還有對應的流程圖中的每個模型的數(shù)據(jù)庫詳細設計。再細致一點到實際的喚起收銀臺支付。那么咱們這邊用時序圖表示出來。這里主要把支付寶的對接流程展示給大家看一下。

到此，基本業(yè)務流程差不多已經(jīng)很清楚了，系統(tǒng)之間的交互時序也比較清晰地表現(xiàn)出來了。那么接下來的話其實就是模型設計了，那么日常模型設計的話，當然我們可以把每個模型之間的關系先表示出來。

當然這里的話其實字段上可以寫粗一點，在細節(jié)一點的模型完全可以用表格的形式表現(xiàn)出來?？梢杂脀ord文檔中的表，也可以直接用excel直接寫。不過還有一款數(shù)據(jù)庫設計工具軟件。在下面詳細和大家介紹。

完成上面這些設計，基本就差不多了，頂多的話，可能就是具體的接口設計，包括接口的請求入?yún)⒁约胺祷貐?shù)的設計，當然還有類型的設計。這里的話就不展開說了，當然關于接口的設計也有不錯的工具，咱們還是向下繼續(xù)看。

日常一些繪圖工具推薦

UML圖繪制工具

日常工作中，繪制流程圖，老貓主要用兩個工具，一款是draw.io，另外一款是wps。下面咱們分別來介紹一下。

draw.io

drawio主要如下：

這款工具，老貓覺得還是比較輕量的，除了有客戶端之外，還有網(wǎng)頁版，使用起來相當方便，而且用起來也簡單，也沒有什么學習成本。在線繪制的話，鏈接地址：https://app.diagrams.net/

大家可以打開試試。

Draw.io的特點包括：

多種圖形元素：提供豐富的圖形元素庫，包括形狀、符號、箭頭等，用戶可以根據(jù)需要自由選擇和組合這些元素。

豐富的模板庫：內(nèi)置大量模板，涵蓋多個領域的常見圖表和圖形，如組織結構圖、UML圖、網(wǎng)絡拓撲圖等，便于用戶快速創(chuàng)建符合自己需求的圖形。

實時協(xié)作：支持多人實時協(xié)作，允許用戶邀請他人加入繪圖工作，實現(xiàn)實時編輯和交流，提高團隊協(xié)作效率。

云端存儲和同步：文件可以保存在云端，支持與多種云存儲服務集成，方便文件備份和同步。

導入導出多種格式：支持導入和導出多種文件格式，方便用戶在不同平臺間使用和分享圖表。

wps

WPS，是金山軟件公司自主研發(fā)的一款辦公軟件品牌。相信大家在寫文檔的時候都用過。wps十分強大，當然相對于draw.io來說的話也更重。但是里面內(nèi)容豐富呀。

wps除了我們?nèi)粘Ｖ赖膐ffice軟件之外，其實還有繪圖工具也在里面，上圖中我們看到還包括流程圖以及思維導圖等等。說到流程圖的話其實和draw.io的差別不是很大，但是有個明顯的優(yōu)勢是wps內(nèi)部的流程圖模版非常多。大家可以選擇自己喜歡的風格，然后在模版上畫出自己風格的業(yè)務流程圖。如下：

如果想用內(nèi)部精美的模版當然是要開通會員的。

數(shù)據(jù)庫設計工具

關于數(shù)據(jù)庫建模工具，老貓這里自己用得是一款開源的設計工具，感覺做的還是相當可以的。叫做pdman。官網(wǎng)地址：http://www.pdman.cn/#/
大家有興趣的話可以了解一下，本人還是非常喜歡這款工具的，兩個字“好用”。

具體工作臺的頁面如下：

這款工具強大的點，不但能進行基本的數(shù)據(jù)庫設計，同時也可以逆向生成SQL，甚至直接創(chuàng)建表。一般把表字段寫好，對應的SQL也就出來了，非常省事兒。
目前好像支持mysql數(shù)據(jù)庫以及oracle數(shù)據(jù)庫生成。

接口設計工具-APIFOX

聊到接口設計的話，大家用得比較多的是什么呢？當然最基本的很多朋友會用到word文檔。寫寫也挺好的。老貓覺得用word其實挺費勁的。比較推薦大家使用：https://apifox.com/

官網(wǎng)是這么介紹的：

Apifox 是接口管理、開發(fā)、測試全流程集成工具，定位 Postman + Swagger + Mock + JMeter。通過一套系統(tǒng)、一份數(shù)據(jù)，解決多個系統(tǒng)之間的數(shù)據(jù)同步問題。只要定義好接口文檔，接口調(diào)試、數(shù)據(jù) Mock、接口測試就可以直接使用，無需再次定義；接口文檔和接口開發(fā)調(diào)試使用同一個工具，接口調(diào)試完成后即可保證和接口文檔定義完全一致。高效、及時、準確！

大家可以感受一下這款工具的強大：

關于怎么用的，老貓在此不多做贅述，推薦大家去試試。老貓在怎么說其功能強大，可能大家也感受不到，所以最好的方式還是自己去試試。

總結

工欲上其事必先利器，以上是老貓日常系統(tǒng)設計過程中的設計思路以及期間使用的相關工具。希望能夠給大家?guī)硪稽c幫助。當然，如果大家有更好的設計軟件或者是軟件設計方面的思路，也歡迎大家能夠在評論區(qū)留言。