[答疑更新]如何評價類似ZenUML這樣的工具

• 2019 年 10 月 6 日
• 筆記

zhoujing 2019-8-29 13:20

潘老師，最近有人推薦zen UML，貌似很強大，能從程式碼生成UML，這是一種畫UML的新趨勢嗎？

UMLChina潘加宇:

20190901補：

有同學問怎樣用比較好的問題——重點用在業務建模、需求和分析工作流就好。

群里前兩天有同學發消息並貼了圖，像這樣用就挺好（雖然圖不太對，應該沒有那麼多Business Actor，消息不應該是虛線……）

原答：

先說結論：

新趨勢談不上，而且用處不大。不過如果這樣的工具能夠流行起來，讓程式設計師擁有一些建模的意識，然後在此基礎上再去了解更有用的建模技能，那是很好的。不過，也要警惕變成"偷懶庇護所"。

從字元生成UML圖形，這個能力很多UML工具都有——把已有程式碼逆向工程為類圖、序列圖。

下面兩個圖就是用EA和UModel逆向工程某個項目的程式碼得到的序列圖

圖1 使用EA在某個項目程式碼運行時錄製的序列圖

圖2 使用UModel將某個項目源程式碼逆向生成序列圖

類似ZenUML這樣的工具的新意是，在一側輸入字元的同時，另一側立刻就出現UML圖形，畢竟圖形比文本要漂亮，給人一種"我在建模耶"的高大上感覺。

類似的工具有不少，參見UMLChina整理的UML工具大全>>。

ZenUML只支援序列圖，最流行的PlantUML支援很多圖，不過ZenUML採用的語法更像主流程式語言的語法。

但是！

******************************

以下內容和ZenUML無直接關係，屬於本問題回答的擴展。

就像上面說的，這樣的工具給人一種"我在建模耶"的高大上感覺，很容易成為偷懶的庇護所，用來掩蓋開發人員的懶惰和無能。

（1）沒有增加（或減少）任何資訊

可以比較一下問題所給的圖的左右兩側，右側比起左側只是形式上的變化，並沒有增加（或減少）什麼資訊，而且更佔用空間。

軟體開發中，增加的每一個字元，每一張圖都應該凝結了新的思考結晶，否則就是廢的，所以《軟體方法》第1章推薦的工作流步驟中，不推薦畫設計工作流的UML圖形，UML圖形用到分析模型為止，設計模型直接用源程式碼來表達，即"設計就是程式碼"。

關於增加（或減少）資訊

增加資訊舉例：例如根據分析模型（只包含核心域知識），再選擇好非核心域（即所謂"技術棧"，例如HTML+…..+ Spring MVC+…..+MySQL）以及相關配置，就能得到各個非核心域的"源程式碼"。當然，目前各種選擇和搭配花樣繁多，工具直接完全生成還不現實，現實的是分析模型+典型用例實現樣例+人肉訓練。

減少資訊舉例：從各種混合了核心域和非核心域知識的"源程式碼"中，提煉出僅包含核心域知識的分析模型。

（2）有可能掩蓋了思維顛倒的膿包

關於思維顛倒，《軟體方法》第1章有講：

圖3 《軟體方法》第1章截屏

就怕有的開發人員根本沒有能力做業務建模、需求、分析工作流的思考，乾脆拍腦袋寫了程式碼，程式碼當場轉UML模型，然後就說我有圖了，建模了，萬事大吉了。

問題在於，你怎麼知道這樣的類、這樣的責任分配就是合理的呢？有的人說不出理由的，經常用"我覺得"、"我打算"這樣的詞語來遮掩。

不只有新人是這樣，有的掛著"資深架構師"頭銜的開發人員也是如此。最近兩年"領域驅動設計"重新成為時髦詞語，我也沾光接了一些任務，聽到「架構師」張嘴就是"我打算把**作為聚合根"……只能一聲嘆息。

圖4 《軟體方法》第1章截屏

什麼時候能把"我打算"改成"我應該"就進步了。