“CASE 工具為什么會失敗”與“UML 為什么會掛”在很大程度上是一回事。

不久前，Ernesto Garbarino 發表了一篇《UML 是否就這樣悄悄地消亡了？》的文章。Garbarino 在使用了 9 年的 UML 后發現，不只自己，同行及其咨詢過的《財富》500 強公司都不再使用 UML 了。他認為敏捷化給了 UML 致命地打擊，是導致 UML“死亡”的真正元兇。

我知道很多軟件項目都在市場競爭中被淘汰，但 UML 不是。它沒有因太復雜、嚴謹而被公司高層所嫌棄，相反，他們很喜歡用少數幾種新的約定符號完成高效清晰的溝通。IT 人士將 UML 擺上臺面，商務人士則欣然接受。

所以問題的答案是，死掉的并不是 UML 本身——它只是連帶受害者。這場“大屠殺”波及到整個需求工程領域，包括業務分析與設計等等。下殺手的是“敏捷化”，正是它抹殺掉了 UML 以及關于它的一切。

Garbarino 認為，錯不在 UML，人們只是放棄了業務分析與正式規范的僵化束縛：

數字化轉型專家建議我們直接將方案部署在生產環境中，由客戶用行動向我們展示實際需求，而非預先做出假設。在這樣一套流程下，我們通過反復試錯來找到正確答案。這就是所謂快速失敗、快速迭代的新方法。

但現實世界很復雜，答案往往沒那么簡單粗暴。我在幾年前曾想寫篇關于 UML 誕生、快速發展到退出公眾視野的文章。為此，我采訪了不少 UML 知名人士，包括 Grady Booch、Bertrand Meyer 和 Ed Seidewitz 等等。但遺憾的是，UML 項目最終走向了消亡，所有的準備都打了水漂。但我仍記得種種細節，所以我可以負責任地說：事情絕不只是“死于敏捷化”那么簡單。當然，這已經過去四年了，有些細節我可能確實記錯了，歡迎大家邊看邊監督。

史前階段

UML 的誕生，源于兩大重要趨勢。

首先是“方法大戰”。在 Smalltalk 與 C++ 成為主流面向對象程序設計（OOP）后，人們開始大肆宣傳一種用于設計軟件系統的終極流程。但語言統一的過程無疑是混亂且“血腥”，一直有不同的設計方法涌現。Eiffel 語言和按契約設計（Design by Contract）思想發明者 Bertrand Meyer 在他寫的《Business Object Notation》一書中列出了 26 種競爭方法，我忘了是在哪里甚至還看到過“50 多種”競爭方法的結論。

幾乎在同一時期，人們還開發出第一款計算機輔助軟件工程（CASE）工具。如今，CASE 只是個“小角色”，但當初它是有潛力拓展出巨大產業的，甚至有人認為其規模將遠超 CAD 或者 IDE。

CASE 工具與方法論結合，不僅為開發者，也為測試人員、項目經理乃至客戶提供了一種整體性的軟件創建方法。然而，CASE 工具的制作成本極高，而且必須針對特定設計方案進行定制，因此隨著時間的推移，CASE 供應商只能從以下三種方式中選擇其中一個：

• Grady Booch 的 Object-Oriented Analysis and Design（碸對象分析與設計，OOAD）
• Ivar Jacobson 的 Object-Oriented Software Engineering（面向對象軟件工程，OOSE）
• James Rumbaugh 的 Object Modeling Technique（對象建模技術，OMT）

Rational 公司有不少的 CASE 產品組合，而且大部分收入來自 Ada 相關工具。Grady Booch 是 Rational 公司的員工，Booch 與 Rumbaugh 是好朋友，所以兩個人的思路在充分交流之后逐漸趨于一致。所以，兩人也開始嘗試明確協作，將 CASE 供應商需要支持的方法從三種縮減成兩種。之后，隨著其中一種方法優于另外兩種，他們買下了 Jacobson 的咨詢公司，逐步放棄了面向對象軟件工程（OOSE）。

OOSE、OOAD 與 OMT 都是代表了整體方法，涵蓋到符號表示和過程。由于消除符號差異要比處理差異更容易，所以 Rational 將聯合體拆分成了兩個部分。

統一建模語言（UML）于 1996 年問世，并被移交給對象管理小組（OMG），Rational Unified Process 則在一年之后誕生。UML 在接下來的十年中大受歡迎，并從 2004 年開始受到人們的普遍關注。但時間飛逝，轉眼就來到“UML 已死”的時代——這中間到底發生了什么？

理解問題本身

必須承認的是，UML 怎么“掛掉”這個問題是有歧義的。

首先，我們說的“掛掉”究竟指什么。程序員們常用這個詞來代表某種事物的“相對市場份額下降”，而非“絕對市場份額下降”。如今，仍有不少意見領袖抱怨開發者不夠了解底層系統，但與 30 年前相比，參與內核開發的開發者數量已經大幅增加。接觸內核開發的群體在全體開發者中確實比例很低。同理可知，UML 也許正經歷類似的“既增長、又消亡”過程，具體要看大家選擇衡量的標準。所以，我們不妨假設 UML 處于“快掛了”的狀態，再進一步展開討論。

另一個分歧是，我們說的 UML 究竟是什么。首先，UML 包含十幾種不同的圖類型，目前仍有不少人在使用順序圖。其次，人們使用 UML 圖的方式也是多種多樣。UML 與敏捷世界中的杰出人物 Martin Fowler 同樣確定出三種基本用例：草圖、藍圖與編程。

這兩點很容易解釋。UML 的編程用例在早期發展階段就已經消亡 ，大多數 UML 支持者自己也認為這東西沒什么用。UML 草圖的命運也不容樂觀，而且人們發現草圖符號與 UML 標準很難保持同步，逐漸演變出多種相互間難以理解的“方言”。所以，除非有人刻意保持統一，否則兩者基本毫不相干。

剩下的 UML 藍圖則是最復雜的用例。據我的了解，它應該也是 Rational 公司最重視的成果。

UML 藍圖與 UML 草圖之間有兩個差異。首先，UML 的本意是先讓設計人員寫藍圖，再由程序員實現藍圖，但二者對應了不同的技能與工具。其次，UML 藍圖集成有多種不同的圖類型，我們不僅需要編寫類圖與需求圖，還需要用實現需求圖編寫的工具，即需要在藍圖設計當中使用 CASE 工具。因此，UML 的人氣往往與 CASE 工具的流行度密切相關。也正因為如此，我覺得“CASE 工具為什么會失敗”與“UML 為什么會‘掛’”在很大程度上是一回事。

下面咱們開始探究 UML 悲慘命運的根源。我得強調，我只能根據自己僅有的記憶做出還原和推測，所以給出的理由也許不那么準確，僅供大家參考。

消亡原因

傳統的約束

在方法大戰爆發、CASE 工具興起之后，UML 可以說是應運而生。市場上已經出現大量基于 OOAD、OOSA 以及 OMT 的 CASE 工具，而 UML 必須與這三類工具保持向后兼容，這也在起步階段就埋下了隱患。如果能夠果斷放棄這些，UML 也許可以更簡單地實現概念統一。

規范化缺失

UML 的規范太過松散，在圖的交互方式及關鍵字實際含義等方面都模糊不清。比如，UML 1.3 在類圖中給出了“泛化”箭頭示例，其中 Sailboat 是 WindPoweredVehicle 與 WaterVehicle 的專業化表達，而后兩者又是 Vehicle 的專業化表達。但從設計角度來看這些的意義是什么呢？我們有必要用專門的方式來實現嗎？這種細化關系有什么特別？總之，在具體操作中，一直存在著用戶決定關系含義、CASE 供應商決定實現功能，但兩者長期存在倒錯的問題。

看到這里，很多朋友可能想到了 C 語言。沒錯，當初的 C89 之所以要包含大量未定義及用戶定義行為，完全是為了容納大量彼此沖突的編譯器。OMG（UML 1.0 后版本的維護者）也面臨著類似的困境。他們無法對 UML 標準做出任何更新，否則很可能破壞現有供應商的決策，這自然拖慢了 UML 的發展速度，也大大增加了各個版本的修訂復雜性。

我有一個從朋友那里聽來的“八卦”。當時，雖然 OMG 被束縛住了手腳，但還有一定為“更大利益”做出改變的空間。我個人懷疑作為 UML 的原始開發商以及規模最大的 CASE 工具供應商之一，Rational 其實很想對舊版軟件做出更新。但是，IBM 隨后在 2003 年收購了 Rational，并很快停用了 Rational 的 UML 工具，轉而銷售專有 CASE 工具 Rational Software Architect。由于不打算繼續在 Rational 遺留項目上投入精力，IBM 開始阻止一切可能對 UML 兼容性造成影響的更新，最終導致項目徹底停滯。

而 2003 年也正是 UML 市場戰勝率開始下降的開端，我覺得這應該不是純粹的巧合。現在，我們要探討 UML 的具體問題了。

UML 中包含了非常多種不同的圖和規則，導致產品太過復雜。這對任何人都沒有好處，因為 UML 變得越來越難學，配套開發工具的設計也陷入困境。

雖然看似會畫幾張圖就能上手，但背后的規范體系并不簡單，所有工具都必須全面完整。所以，除了“泛化圖”外，其他稍稍復雜一點的內容都需要龐大的團隊和充裕的資金才有可能實現，這就限制了生態系統的增長速度。最終，開源社區也拿不出豐富的 CASE 工具，用戶實際使用的工具就更少了。

更關鍵的是，就連商業 CASE 工具也啃不下這塊硬骨頭。表示方法越復雜，開發工具的難度就越大，沒有了令人振奮的強大 CASE 工具支撐，UML 自然陷入孤掌難鳴的境地。

沒有文本格式

這是工具體系方面的另一重大缺失。沒有文本格式導致我們無法在自己熟悉的文本編輯器中編輯 UML 圖、無法執行 grep 編寫、也無法編寫自己的定制化解析器。

也有人曾嘗試為 UML 提供文本表示形式，例如 PlantUML 或者 Mermaid 等，但它們全都面臨著兩大難題。首先，這種表示是單向的，我們無法將現有圖轉換為文本形式；第二個就是所謂的圖形化問題，文本格式在表現視覺布局方面效果極差。這個問題可以具體分為三個方面：1）系統非常笨拙，不如直接使用圖形編輯器；2）必須調整設置才能讓布局引擎更為流暢；3）需要編寫 TikZ。

根本沒有數據格式

這個問題看似與“沒有文本格式”類似，但本質上截然不同：UML 只有視覺表示這唯一的格式，令 UML 的導入與導出幾乎無法實現。一旦開始使用具體工具，結果就會被限制在此種工具之內，這明顯又制約了生態系統的發展：無法制作獨立的 UML 工具、驗證品節，也無法開發出任何 CASE 工具擴展。

OMG 方面也曾嘗試通過 XMI（一種用于 UML 的 XML 格式）糾正這個問題，但據說效果一直不好，而且各個 XMI 與 UML 版本都不具備向后兼容能力，工作根本推進不下去。

無法逆向

一部分工具可能會采用某些 UML 規范并生成代碼，也有一些工具可以根據某些代碼對圖進行逆向操作，但這兩種用例的效果都不太好。因此，與藍圖類似，UML 與代碼終將不可避免地陷入無法同步的狀況。

在采訪 UML 用戶時，我最常聽到的抱怨就是“UML 太爛了，根本沒法用。”

文化變革

最后的這一點，我開始跟開頭文章作者的觀念趨于相同。文化變革確實給了 UML 沉重一擊，但我認為其中的原因不是那么簡單。

CASE 工具的作用僅限于大型軟件項目，這是因為只有大型軟件項目才有很多人長時間從事相同的工作。這類項目的“官僚化”程度也更高。雖然我們如今都認同敏捷化正全面取代以往占主導地位的瀑布式開發方式，但那個時候大多數開發者都在遵循“事來忙一陣、亡羊再補牢”的工作思路。因此，CASE 工具最初是由企業在內部強制要求使用的。文章作者也提到，真正喜歡 UML 的其實是企業高管、而非程序員自己。

上世紀九十年代，程序員們主要在傳統企業工作，因此當時的技術趨勢也主要反映傳統企業管理層的喜好。雖然也正是他們的決策讓 UML 有了一時的輝煌，但近二十年過去了，軟件文化逐漸向大型科技企業與初創公司傾斜，從歷史上看這兩者都不屬于 CASE 供應商的預設目標受眾。這樣的變化，也讓 CASE 在市場上的地位一降再降。

UML 之后

在開頭提到的文章中，作者 Garbarino 提出了一個問題：如果 UML 沒有了，我們將使用什么?

雖然有些人使用 C4 之類的輕量級建模技術，但目前主流的應該還是 masala 圖。為什么要用 masala？Garbarino 認為是因為它靈活多變、能夠一次性涵蓋多個維度、既涉及結構又涉及行為、既體現邏輯層面又貫通物理層面，很像是 4+1 架構模型視圖的大雜燴產物。

現在生活和財務所依賴的數百萬個系統，完全是在 masala 圖表的背后設計、資助和執行的，通常除了一堆史詩和用戶故事之外沒有更多的附屬品。不過在特別嚴謹的業務系統，如銀行抵押系統并不會使用潦草的馬薩拉圖。

不過，在 Garbarino 看來，馬薩拉圖也有作用。masala 圖本質上并不是規范，更多的是一種情感共鳴的載體。根據 Marie Kondo 提出的原則，masala 圖的核心目標，是在利益相關者心中激起認同與積極情緒。能做到這一點的，就是好 masala 圖。