敏捷“殺死”統(tǒng)一建模語言？
不久前，Ernesto Garbarino 發(fā)表了一篇《UML 是否就這樣悄悄地消亡了？》的文章。Garbarino 在使用了 9 年的 UML 后發(fā)現(xiàn)，不只自己，同行及其咨詢過的《財富》500 強公司都不再使用 UML 了。他認為敏捷化給了 UML 致命地打擊，是導致 UML“死亡”的真正元兇。
我知道很多軟件項目都在市場競爭中被淘汰，但 UML 不是。它沒有因太復雜、嚴謹而被公司高層所嫌棄，相反，他們很喜歡用少數(shù)幾種新的約定符號完成高效清晰的溝通。IT 人士將 UML 擺上臺面，商務人士則欣然接受。
所以問題的答案是，死掉的并不是 UML 本身——它只是連帶受害者。這場“大屠殺”波及到整個需求工程領域，包括業(yè)務分析與設計等等。下殺手的是“敏捷化”，正是它抹殺掉了 UML 以及關于它的一切。
Garbarino 認為，錯不在 UML，人們只是放棄了業(yè)務分析與正式規(guī)范的僵化束縛：
數(shù)字化轉(zhuǎn)型專家建議我們直接將方案部署在生產(chǎn)環(huán)境中，由客戶用行動向我們展示實際需求，而非預先做出假設。在這樣一套流程下，我們通過反復試錯來找到正確答案。這就是所謂快速失敗、快速迭代的新方法。
但現(xiàn)實世界很復雜，答案往往沒那么簡單粗暴。我在幾年前曾想寫篇關于 UML 誕生、快速發(fā)展到退出公眾視野的文章。為此，我采訪了不少 UML 知名人士，包括 Grady Booch、Bertrand Meyer 和 Ed Seidewitz 等等。但遺憾的是，UML 項目最終走向了消亡，所有的準備都打了水漂。但我仍記得種種細節(jié)，所以我可以負責任地說：事情絕不只是“死于敏捷化”那么簡單。當然，這已經(jīng)過去四年了，有些細節(jié)我可能確實記錯了，歡迎大家邊看邊監(jiān)督。
UML 的誕生，源于兩大重要趨勢。
首先是“方法大戰(zhàn)”。在 Smalltalk 與 C++ 成為主流面向?qū)ο蟪绦蛟O計（OOP）后，人們開始大肆宣傳一種用于設計軟件系統(tǒng)的終極流程。但語言統(tǒng)一的過程無疑是混亂且“血腥”，一直有不同的設計方法涌現(xiàn)。Eiffel 語言和按契約設計（Design by Contract）思想發(fā)明者 Bertrand Meyer 在他寫的《Business Object Notation》一書中列出了 26 種競爭方法，我忘了是在哪里甚至還看到過“50 多種”競爭方法的結(jié)論。
幾乎在同一時期，人們還開發(fā)出第一款計算機輔助軟件工程（CASE）工具。如今，CASE 只是個“小角色”，但當初它是有潛力拓展出巨大產(chǎn)業(yè)的，甚至有人認為其規(guī)模將遠超 CAD 或者 IDE。
CASE 工具與方法論結(jié)合，不僅為開發(fā)者，也為測試人員、項目經(jīng)理乃至客戶提供了一種整體性的軟件創(chuàng)建方法。然而，CASE 工具的制作成本極高，而且必須針對特定設計方案進行定制，因此隨著時間的推移，CASE 供應商只能從以下三種方式中選擇其中一個：
Grady Booch 的 Object-Oriented Analysis and Design（面向?qū)ο蠓治雠c設計，OOAD）
Ivar Jacobson 的 Object-Oriented Software Engineering（面向?qū)ο筌浖こ蹋琌OSE）
James Rumbaugh 的 Object Modeling Technique（對象建模技術，OMT）
Rational 公司有不少的 CASE 產(chǎn)品組合，而且大部分收入來自 Ada 相關工具。Grady Booch 是 Rational 公司的員工，Booch 與 Rumbaugh 是好朋友，所以兩個人的思路在充分交流之后逐漸趨于一致。所以，兩人也開始嘗試明確協(xié)作，將 CASE 供應商需要支持的方法從三種縮減成兩種。之后，隨著其中一種方法優(yōu)于另外兩種，他們買下了 Jacobson 的咨詢公司，逐步放棄了面向?qū)ο筌浖こ蹋∣OSE）。
OOSE、OOAD 與 OMT 都是代表了整體方法，涵蓋到符號表示和過程。由于消除符號差異要比處理差異更容易，所以 Rational 將聯(lián)合體拆分成了兩個部分。
統(tǒng)一建模語言（UML）于 1996 年問世，并被移交給對象管理小組（OMG），Rational Unified Process 則在一年之后誕生。UML 在接下來的十年中大受歡迎，并從 2004 年開始受到人們的普遍關注。但時間飛逝，轉(zhuǎn)眼就來到“UML 已死”的時代——這中間到底發(fā)生了什么？
必須承認的是，UML 怎么“掛掉”這個問題是有歧義的。
首先，我們說的“掛掉”究竟指什么。程序員們常用這個詞來代表某種事物的“相對市場份額下降”，而非“絕對市場份額下降”。如今，仍有不少意見領袖抱怨開發(fā)者不夠了解底層系統(tǒng)，但與 30 年前相比，參與內(nèi)核開發(fā)的開發(fā)者數(shù)量已經(jīng)大幅增加。接觸內(nèi)核開發(fā)的群體在全體開發(fā)者中確實比例很低。同理可知，UML 也許正經(jīng)歷類似的“既增長、又消亡”過程，具體要看大家選擇衡量的標準。所以，我們不妨假設 UML 處于“快掛了”的狀態(tài)，再進一步展開討論。
另一個分歧是，我們說的 UML 究竟是什么。首先，UML 包含十幾種不同的圖類型，目前仍有不少人在使用順序圖。其次，人們使用 UML 圖的方式也是多種多樣。UML 與敏捷世界中的杰出人物 Martin Fowler 同樣確定出三種基本用例：草圖、藍圖與編程。
這兩點很容易解釋。UML 的編程用例在早期發(fā)展階段就已經(jīng)消亡 ，大多數(shù) UML 支持者自己也認為這東西沒什么用。UML 草圖的命運也不容樂觀，而且人們發(fā)現(xiàn)草圖符號與 UML 標準很難保持同步，逐漸演變出多種相互間難以理解的“方言”。所以，除非有人刻意保持統(tǒng)一，否則兩者基本毫不相干。
剩下的 UML 藍圖則是最復雜的用例。據(jù)我的了解，它應該也是 Rational 公司最重視的成果。
UML 藍圖與 UML 草圖之間有兩個差異。首先，UML 的本意是先讓設計人員寫藍圖，再由程序員實現(xiàn)藍圖，但二者對應了不同的技能與工具。其次，UML 藍圖集成有多種不同的圖類型，我們不僅需要編寫類圖與需求圖，還需要用實現(xiàn)需求圖編寫的工具，即需要在藍圖設計當中使用 CASE 工具。因此，UML 的人氣往往與 CASE 工具的流行度密切相關。也正因為如此，我覺得“CASE 工具為什么會失敗”與“UML 為什么會‘掛’”在很大程度上是一回事。
下面咱們開始探究 UML 悲慘命運的根源。我得強調(diào)，我只能根據(jù)自己僅有的記憶做出還原和推測，所以給出的理由也許不那么準確，僅供大家參考。
在方法大戰(zhàn)爆發(fā)、CASE 工具興起之后，UML 可以說是應運而生。市場上已經(jīng)出現(xiàn)大量基于 OOAD、OOSA 以及 OMT 的 CASE 工具，而 UML 必須與這三類工具保持向后兼容，這也在起步階段就埋下了隱患。如果能夠果斷放棄這些，UML 也許可以更簡單地實現(xiàn)概念統(tǒng)一。
UML 的規(guī)范太過松散，在圖的交互方式及關鍵字實際含義等方面都模糊不清。比如，UML 1.3 在類圖中給出了“泛化”箭頭示例，其中 Sailboat 是 WindPoweredVehicle 與 WaterVehicle 的專業(yè)化表達，而后兩者又是 Vehicle 的專業(yè)化表達。但從設計角度來看這些的意義是什么呢？我們有必要用專門的方式來實現(xiàn)嗎？這種細化關系有什么特別？總之，在具體操作中，一直存在著用戶決定關系含義、CASE 供應商決定實現(xiàn)功能，但兩者長期存在倒錯的問題。
看到這里，很多朋友可能想到了 C 語言。沒錯，當初的 C89 之所以要包含大量未定義及用戶定義行為，完全是為了容納大量彼此沖突的編譯器。OMG（UML 1.0 后版本的維護者）也面臨著類似的困境。他們無法對 UML 標準做出任何更新，否則很可能破壞現(xiàn)有供應商的決策，這自然拖慢了 UML 的發(fā)展速度，也大大增加了各個版本的修訂復雜性。
我有一個從朋友那里聽來的“八卦”。當時，雖然 OMG 被束縛住了手腳，但還有一定為“更大利益”做出改變的空間。我個人懷疑作為 UML 的原始開發(fā)商以及規(guī)模最大的 CASE 工具供應商之一，Rational 其實很想對舊版軟件做出更新。但是，IBM 隨后在 2003 年收購了 Rational，并很快停用了 Rational 的 UML 工具，轉(zhuǎn)而銷售專有 CASE 工具 Rational Software Architect。由于不打算繼續(xù)在 Rational 遺留項目上投入精力，IBM 開始阻止一切可能對 UML 兼容性造成影響的更新，最終導致項目徹底停滯。
而 2003 年也正是 UML 市場戰(zhàn)勝率開始下降的開端，我覺得這應該不是純粹的巧合。現(xiàn)在，我們要探討 UML 的具體問題了。
UML 中包含了非常多種不同的圖和規(guī)則，導致產(chǎn)品太過復雜。這對任何人都沒有好處，因為 UML 變得越來越難學，配套開發(fā)工具的設計也陷入困境。
雖然看似會畫幾張圖就能上手，但背后的規(guī)范體系并不簡單，所有工具都必須全面完整。所以，除了“泛化圖”外，其他稍稍復雜一點的內(nèi)容都需要龐大的團隊和充裕的資金才有可能實現(xiàn)，這就限制了生態(tài)系統(tǒng)的增長速度。最終，開源社區(qū)也拿不出豐富的 CASE 工具，用戶實際使用的工具就更少了。
更關鍵的是，就連商業(yè) CASE 工具也啃不下這塊硬骨頭。表示方法越復雜，開發(fā)工具的難度就越大，沒有了令人振奮的強大 CASE 工具支撐，UML 自然陷入孤掌難鳴的境地。
這是工具體系方面的另一重大缺失。沒有文本格式導致我們無法在自己熟悉的文本編輯器中編輯 UML 圖、無法執(zhí)行 grep 編寫、也無法編寫自己的定制化解析器。
也有人曾嘗試為 UML 提供文本表示形式，例如 PlantUML 或者 Mermaid 等，但它們?nèi)济媾R著兩大難題。首先，這種表示是單向的，我們無法將現(xiàn)有圖轉(zhuǎn)換為文本形式；第二個就是所謂的圖形化問題，文本格式在表現(xiàn)視覺布局方面效果極差。這個問題可以具體分為三個方面：1）系統(tǒng)非常笨拙，不如直接使用圖形編輯器；2）必須調(diào)整設置才能讓布局引擎更為流暢；3）需要編寫 TikZ。
這個問題看似與“沒有文本格式”類似，但本質(zhì)上截然不同：UML 只有視覺表示這唯一的格式，令 UML 的導入與導出幾乎無法實現(xiàn)。一旦開始使用具體工具，結(jié)果就會被限制在此種工具之內(nèi)，這明顯又制約了生態(tài)系統(tǒng)的發(fā)展：無法制作獨立的 UML 工具、驗證品節(jié)，也無法開發(fā)出任何 CASE 工具擴展。
OMG 方面也曾嘗試通過 XMI（一種用于 UML 的 XML 格式）糾正這個問題，但據(jù)說效果一直不好，而且各個 XMI 與 UML 版本都不具備向后兼容能力，工作根本推進不下去。
一部分工具可能會采用某些 UML 規(guī)范并生成代碼，也有一些工具可以根據(jù)某些代碼對圖進行逆向操作，但這兩種用例的效果都不太好。因此，與藍圖類似，UML 與代碼終將不可避免地陷入無法同步的狀況。
在采訪 UML 用戶時，我最常聽到的抱怨就是“UML 太爛了，根本沒法用。”
最后的這一點，我開始跟開頭文章作者的觀念趨于相同。文化變革確實給了 UML 沉重一擊，但我認為其中的原因不是那么簡單。
CASE 工具的作用僅限于大型軟件項目，這是因為只有大型軟件項目才有很多人長時間從事相同的工作。這類項目的“官僚化”程度也更高。雖然我們?nèi)缃穸颊J同敏捷化正全面取代以往占主導地位的瀑布式開發(fā)方式，但那個時候大多數(shù)開發(fā)者都在遵循“事來忙一陣、亡羊再補牢”的工作思路。因此，CASE 工具最初是由企業(yè)在內(nèi)部強制要求使用的。文章作者也提到，真正喜歡 UML 的其實是企業(yè)高管、而非程序員自己。
上世紀九十年代，程序員們主要在傳統(tǒng)企業(yè)工作，因此當時的技術趨勢也主要反映傳統(tǒng)企業(yè)管理層的喜好。雖然也正是他們的決策讓 UML 有了一時的輝煌，但近二十年過去了，軟件文化逐漸向大型科技企業(yè)與初創(chuàng)公司傾斜，從歷史上看這兩者都不屬于 CASE 供應商的預設目標受眾。這樣的變化，也讓 CASE 在市場上的地位一降再降。
在開頭提到的文章中，作者 Garbarino 提出了一個問題：如果 UML 沒有了，我們將使用什么?
雖然有些人使用 C4 之類的輕量級建模技術，但目前主流的應該還是 masala 圖。為什么要用 masala？Garbarino 認為是因為它靈活多變、能夠一次性涵蓋多個維度、既涉及結(jié)構(gòu)又涉及行為、既體現(xiàn)邏輯層面又貫通物理層面，很像是 4+1 架構(gòu)模型視圖的大雜燴產(chǎn)物。
Masala 圖示例，來源: Red Hat
現(xiàn)在生活和財務所依賴的數(shù)百萬個系統(tǒng)，完全是在 masala 圖表的背后設計、資助和執(zhí)行的，通常除了一堆史詩和用戶故事之外沒有更多的附屬品。不過在特別嚴謹?shù)臉I(yè)務系統(tǒng)，如銀行抵押系統(tǒng)并不會使用潦草的馬薩拉圖。
不過，在 Garbarino 看來，馬薩拉圖也有作用。masala 圖本質(zhì)上并不是規(guī)范，更多的是一種情感共鳴的載體。根據(jù) Marie Kondo 提出的原則，masala 圖的核心目標，是在利益相關者心中激起認同與積極情緒。能做到這一點的，就是好 masala 圖。
延伸閱讀：
https://buttondown.email/hillelwayne/archive/why-uml-really-died/
https://garba.org/posts/2021/uml/