針對張逸觀點的一些評點

2019 年 10 月 6 日
筆記

我看到張逸老師在最近的一些文章中喜歡提「老」字，例如：

「我充分借鑒了事件風暴這種新方法，卻又未完全拋棄UML這種老方法」

「若有可能，我還希望再加上一個ICONIX方法，雖然它已經垂垂老矣，但該方法蘊含的一些設計思想仍有值得借鑒之處」

張逸老師的關注點從編碼拓展到軟件開發的全部工作流，值得稱讚。不過每個工作流有各自的技能需要學習，是自己的感悟還罷了，如果要傳授技藝給他人，更需要高標準嚴要求才對。

所以，我就用建模思維剖析張逸老師近期發表的一些內容，供大家參考。

就先從張逸老師上面這兩句話開始吧。

一、不是什麼都叫「方法」

上面這兩句話，張逸老師對各種概念一律以「方法」稱呼之。其實UML是「Unified Modeling Language」，是「語言」，或者「表示法」（Notation）。

ICONIX則是Doug Rosenberg等人提出的一種使用UML的建模過程（Process）。我們先來看2001年的著作：

圖1 摘自Rosenberg, D., Scott,K., Applying Use Case Driven Object Modeling with UML: An Annotated e-CommerceExample. Addison Wesley (2001)

再來看2007年的著作：

圖2 摘自Rosenberg, D., Stephens,M., Use Case Driven Object Modeling with UML: Theory and Practice. Apress (2007)

關於方法、過程和工具的定義，可以參照被廣泛使用的教材「Software Engineering: A Practitioner's Approach」，2014出了第8版。

圖3 摘自Pressman R.,Maxim B., Software Engineering: A Practitioner's Approach 8th Edition. SEM(2014)

我於2008年寫的《四十年軟件工程故事》（http://www.umlchina.com/book/se40.htm）也可以參考。

為什麼對這些不當用詞如此重視，我在《為什麼要對術語"吹毛求疵"》一文（http://www.umlchina.com/qa/Content/906.htm）中闡述了我的觀點：

我們聽到有人像上面的姨媽表哥一樣說話時，我們心裏知道，這可不是什麼習慣用語不同，而是說話的人是外行。因為我們是內行，我們比姨媽表哥們更知道一些概念之間的區別。

同理，如果我們真的弄懂了軟件開發中的一些重要概念，當有人在我們面前說"功能模塊"、"用戶需求"、"設計階段"等術語時，我們心裏就知道了，這不是什麼習慣問題，而是這個人在某些方面是個外行。

二、關於「老」

人們對事物的認識會不斷深入，所以，已有的知識有的會被繼承，有的會被淘汰。但是要注意，之所以某些知識會被淘汰，是因為人們針對這方面的知識有了更深刻的認識，而不是因為法律規定這個知識只有「**年**權」，到時間就要強行作廢。幾百年前的數學、物理知識，大部分我們今天不還在繼續學習和使用嗎？

圖4 摘自《中華人民共和國城鎮國有土地使用權出讓和轉讓暫行條例》

既然張逸老師說「UML」、「ICONIX」老、垂垂老矣，那我請問張逸老師，能否具體說說看UML、ICONIX到底有哪些缺點，看看能不能說到位？但願不是為了強調自己的「新」而隨口一說。

我不認為UML這個建模語言是完美的，也不認為ICONIX這個過程的做法有多好。我甚至認為經過將近20年的積累，對於建模和UML的下一步改進，我的認識也許比起很多國外的人士更深刻。我還相信我在《軟件方法》中提倡的過程比ICONIX（以及其他一些類似過程）要更高效實用。

不過，絕大多數軟件開發人員基本上是「赤手空拳」，根本沒有達到被UML的不完美和ICONIX的不足絆倒的地步。事實上，就算有人不使用UML里的圖，能熟練使用數據流圖和實體關係圖建模，或者把能把ICONIX那幾招用熟，我覺得他就已經高出周圍的人一大截了。

NBA的格林可能清楚詹姆斯有啥缺點，但這對業餘球員來說有多少參考價值？

癌症的化療、放療有局限性和副作用，是需要有更好的治療手段，但方嚮應該是更精細的免疫治療，而不是拿幾味中藥湊一湊得出來的「癌必靈」。

三、「痛點」離「問題域」還有多遠

圖5 摘自張逸文章《領域驅動戰略設計暨微服務設計工作坊》

「域」是一個面積或範圍較大的概念，「點」是面積或範圍很小或近似於零的概念，兩者不能等同。

也許張逸老師要表述的意思是：通過痛點來判斷哪一塊領域需要建模。就像在人體按下痛點來判斷哪一塊區域需要深入研究。這樣的表述更容易理解一些。

即使換了表述，也還是不準確，因為從「痛點」到領域模型，還有一段距離。「頭痛」的問題未必在頭。

先列舉一些建模知識點，更詳細內容請參見《軟件方法》。

★序列圖消息的含義：A指向B，意思是「A請求B做某事」。例如圖6中，患者請求門診收費挂號員辦理挂號。如果發消息的是人，接收消息的是非人智能系統，意思符合「A用B來做某事」也可以。★業務工人（Business Worker）：組織內的人員，即人腦智能系統。★業務實體（Business Entity）：組織內的非人智能系統。★業務流程信息化改進模式一：物流變信息流模式二：改善信息流轉模式三：封裝領域邏輯

通過下面例子來說明問題。某醫院現在有個「痛點」：輸液反應的投訴比往年多了。

這個「痛點」和需要改進的範圍不是一一對應的。

【可能原因一】

有人組團碰瓷。

【改進方案】

1.1 引進一批記憶力好的高級保安（業務工人）盯牢每一個患者，發現可疑人員報警，如圖6。