從系統設計到擼程式碼?我用了這些方法和工具

程序员老猫發表於2024-04-19

大家好,我是老貓。今天和大家分享一下程式設計師日常的繪圖思路,以及一些老貓日常使用的繪圖工具。

為什麼要畫圖?

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

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

軟體工程中的繪圖

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

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

經典4+1

分別解釋一下:

1、場景檢視:主要用於系統參與者和功能之間的關係,老貓理解一般由用例圖組成。

2、邏輯檢視:描述軟體拆解之後的元件關係、元件約束和邊界,反映系統整體組成和系統構建,通常由元件圖和類圖自稱。

3、物理檢視:描述系統軟體到物理硬體的對映關係,主要指軟體的部署架構圖,這裡老貓的理解是可能運維人員更需要關注。

4、處理流程:主要描述軟體元件之間的通訊時序以及輸入輸出,反映系統功能流程和資料流程,這裡咱們可以用時序圖以及流程圖來表示。

5、開發檢視:描述系統的業務模組劃分以及內部的組成設計,反映系統的開發實施過程。

老貓之前寫過一篇文章【新接手一個業務系統,我是這麼熟悉的】。這篇文章的寫作思路,主要也是從上面這些點切入去寫的。

開發人員如何繪製技術評審的圖?

工作這麼多年之後,老貓發現,寫程式碼的時候其實是最安逸的時候,只要事先方案設計得好,流程繪製得精準,模型設計得合理。戴上耳機寫程式碼就是一種享受。因為寫程式碼的時候只要對著設計稿去擼就好了。

那麼咱們在做技術方案設計的時候應該從哪些點去切入進行畫設計圖呢?老貓日常的繪圖思路主要是從整體到區域性,從概要到細節,到最終的模型落地。

例如關於設計支付系統,咱們先把各個系統之間關係以及功能模組梳理清楚,讓參與評審的人能夠對支付系統的架構有個整體的認知。具體如下:

支付整體架構

透過上面的的圖,可以表示清楚系統和系統之間的層級關係,可以讓評審人一目瞭然地知道,你當前所設計的系統在整個架構領域屬於那一塊。另外的話也能夠讓人清晰地感知每個系統的主要的功能是什麼。

接下來的設計就是開始區域性設計。區域性設計的話一般需要理清楚功能點,以及整體的業務流程。我們挑一個下單支付的流程,簡單繪製一下業務流程。具體如下:

下單支付交易流程

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

再細化一些,那就是加上泳道,然後體現出不同的系統的內部流程。如下圖:

泳道流程

當繪製到這裡的時候,其實咱們距離最終的寫程式碼還差一點了,那就是細緻的時序邏輯。還有對應的流程圖中的每個模型的資料庫詳細設計。再細緻一點到實際的喚起收銀臺支付。那麼咱們這邊用時序圖表示出來。這裡主要把支付寶的對接流程展示給大家看一下。

時序流程

到此,基本業務流程差不多已經很清楚了,系統之間的互動時序也比較清晰地表現出來了。那麼接下來的話其實就是模型設計了,那麼日常模型設計的話,當然我們可以把每個模型之間的關係先表示出來。

資料庫設計

當然這裡的話其實欄位上可以寫粗一點,在細節一點的模型完全可以用表格的形式表現出來。可以用word文件中的表,也可以直接用excel直接寫。不過還有一款資料庫設計工具軟體。在下面詳細和大家介紹。

完成上面這些設計,基本就差不多了,頂多的話,可能就是具體的介面設計,包括介面的請求入參以及返回引數的設計,當然還有型別的設計。這裡的話就不展開說了,當然關於介面的設計也有不錯的工具,咱們還是向下繼續看。

日常一些繪圖工具推薦

UML圖繪製工具

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

draw.io

drawio主要如下:

draw.io

這款工具,老貓覺得還是比較輕量的,除了有客戶端之外,還有網頁版,使用起來相當方便,而且用起來也簡單,也沒有什麼學習成本。線上繪製的話,連結地址:https://app.diagrams.net/

大家可以開啟試試。

Draw.io的特點包括:

多種圖形元素:提供豐富的圖形元素庫,包括形狀、符號、箭頭等,使用者可以根據需要自由選擇和組合這些元素。

豐富的模板庫:內建大量模板,涵蓋多個領域的常見圖表和圖形,如組織結構圖、UML圖、網路拓撲圖等,便於使用者快速建立符合自己需求的圖形。

實時協作:支援多人實時協作,允許使用者邀請他人加入繪圖工作,實現實時編輯和交流,提高團隊協作效率。

雲端儲存和同步:檔案可以儲存在雲端,支援與多種雲端儲存服務整合,方便檔案備份和同步。

匯入匯出多種格式:支援匯入和匯出多種檔案格式,方便使用者在不同平臺間使用和分享圖表。

wps

WPS,是金山軟體公司自主研發的一款辦公軟體品牌。相信大家在寫文件的時候都用過。wps十分強大,當然相對於draw.io來說的話也更重。但是裡面內容豐富呀。

wps

wps除了我們日常知道的office軟體之外,其實還有繪圖工具也在裡面,上圖中我們看到還包括流程圖以及思維導圖等等。說到流程圖的話其實和draw.io的差別不是很大,但是有個明顯的優勢是wps內部的流程圖模版非常多。大家可以選擇自己喜歡的風格,然後在模版上畫出自己風格的業務流程圖。如下:

模版

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

資料庫設計工具

關於資料庫建模工具,老貓這裡自己用得是一款開源的設計工具,感覺做的還是相當可以的。叫做pdman。官網地址:http://www.pdman.cn/#/
大家有興趣的話可以瞭解一下,本人還是非常喜歡這款工具的,兩個字“好用”。

具體工作臺的頁面如下:

資料庫設計工具

這款工具強大的點,不但能進行基本的資料庫設計,同時也可以逆向生成SQL,甚至直接建立表。一般把表欄位寫好,對應的SQL也就出來了,非常省事兒。
目前好像支援mysql資料庫以及oracle資料庫生成。

介面設計工具-APIFOX

聊到介面設計的話,大家用得比較多的是什麼呢?當然最基本的很多朋友會用到word文件。寫寫也挺好的。老貓覺得用word其實挺費勁的。比較推薦大家使用:https://apifox.com/

官網是這麼介紹的:

Apifox 是介面管理、開發、測試全流程整合工具,定位 Postman + Swagger + Mock + JMeter。透過一套系統、一份資料,解決多個系統之間的資料同步問題。只要定義好介面文件,介面除錯、資料 Mock、介面測試就可以直接使用,無需再次定義;介面文件和介面開發除錯使用同一個工具,介面除錯完成後即可保證和介面文件定義完全一致。高效、及時、準確!

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

介面設計工具

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

總結

工欲上其事必先利器,以上是老貓日常系統設計過程中的設計思路以及期間使用的相關工具。希望能夠給大家帶來一點幫助。當然,如果大家有更好的設計軟體或者是軟體設計方面的思路,也歡迎大家能夠在評論區留言。

相關文章