UML真的悄悄地消失了？

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

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

我知道很多軟件項(xiàng)目都在市場(chǎng)競(jìng)爭中被淘汰，但 UML 不是。它沒有因太復(fù)雜、嚴(yán)謹(jǐn)而被公司高層所嫌棄，相反，他們很喜歡用少數(shù)幾種新的約定符號(hào)完成高效清晰的溝通。IT 人士將 UML 擺上臺(tái)面，商務(wù)人士則欣然接受。

所以問題的答案是，死掉的并不是 UML 本身——它只是連帶受害者。這場(chǎng)“大屠殺”波及到整個(gè)需求工程領(lǐng)域，包括業(yè)務(wù)分析與設(shè)計(jì)等等。下殺手的是“敏捷化”，正是它抹殺掉了 UML 以及關(guān)于它的一切。

Garbarino 認(rèn)為，錯(cuò)不在 UML，人們只是放棄了業(yè)務(wù)分析與正式規(guī)范的僵化束縛：

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

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

史前階段

UML 的誕生，源于兩大重要趨勢(shì)。

首先是“方法大戰(zhàn)”。在 Smalltalk 與 C++ 成為主流面向?qū)ο蟪绦蛟O(shè)計(jì)（OOP）后，人們開始大肆宣傳一種用于設(shè)計(jì)軟件系統(tǒng)的終極流程。但語言統(tǒng)一的過程無疑是混亂且“血腥”，一直有不同的設(shè)計(jì)方法涌現(xiàn)。Eiffel 語言和按契約設(shè)計(jì)（Design by Contract）思想發(fā)明者 Bertrand Meyer 在他寫的《Business Object Notation》一書中列出了 26 種競(jìng)爭方法，我忘了是在哪里甚至還看到過“50 多種”競(jìng)爭方法的結(jié)論。

幾乎在同一時(shí)期，人們還開發(fā)出第一款計(jì)算機(jī)輔助軟件工程（CASE）工具。如今，CASE 只是個(gè)“小角色”，但當(dāng)初它是有潛力拓展出巨大產(chǎn)業(yè)的，甚至有人認(rèn)為其規(guī)模將遠(yuǎn)超 CAD 或者 IDE。

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

• Grady Booch 的 Object-Oriented Analysis and Design（碸對(duì)象分析與設(shè)計(jì)，OOAD）
• Ivar Jacobson 的 Object-Oriented Software Engineering（面向?qū)ο筌浖こ?，OOSE）
• James Rumbaugh 的 Object Modeling Technique（對(duì)象建模技術(shù)，OMT）

Rational 公司有不少的 CASE 產(chǎn)品組合，而且大部分收入來自 Ada 相關(guān)工具。Grady Booch 是 Rational 公司的員工，Booch 與 Rumbaugh 是好朋友，所以兩個(gè)人的思路在充分交流之后逐漸趨于一致。所以，兩人也開始嘗試明確協(xié)作，將 CASE 供應(yīng)商需要支持的方法從三種縮減成兩種。之后，隨著其中一種方法優(yōu)于另外兩種，他們買下了 Jacobson 的咨詢公司，逐步放棄了面向?qū)ο筌浖こ蹋∣OSE）。

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

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

理解問題本身

必須承認(rèn)的是，UML 怎么“掛掉”這個(gè)問題是有歧義的。

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

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

這兩點(diǎn)很容易解釋。UML 的編程用例在早期發(fā)展階段就已經(jīng)消亡 ，大多數(shù) UML 支持者自己也認(rèn)為這東西沒什么用。UML 草圖的命運(yùn)也不容樂觀，而且人們發(fā)現(xiàn)草圖符號(hào)與 UML 標(biāo)準(zhǔn)很難保持同步，逐漸演變出多種相互間難以理解的“方言”。所以，除非有人刻意保持統(tǒng)一，否則兩者基本毫不相干。

剩下的 UML 藍(lán)圖則是最復(fù)雜的用例。據(jù)我的了解，它應(yīng)該也是 Rational 公司最重視的成果。

UML 藍(lán)圖與 UML 草圖之間有兩個(gè)差異。首先，UML 的本意是先讓設(shè)計(jì)人員寫藍(lán)圖，再由程序員實(shí)現(xiàn)藍(lán)圖，但二者對(duì)應(yīng)了不同的技能與工具。其次，UML 藍(lán)圖集成有多種不同的圖類型，我們不僅需要編寫類圖與需求圖，還需要用實(shí)現(xiàn)需求圖編寫的工具，即需要在藍(lán)圖設(shè)計(jì)當(dāng)中使用 CASE 工具。因此，UML 的人氣往往與 CASE 工具的流行度密切相關(guān)。也正因?yàn)槿绱?，我覺得“CASE 工具為什么會(huì)失敗”與“UML 為什么會(huì)‘掛’”在很大程度上是一回事。

下面咱們開始探究 UML 悲慘命運(yùn)的根源。我得強(qiáng)調(diào)，我只能根據(jù)自己僅有的記憶做出還原和推測(cè)，所以給出的理由也許不那么準(zhǔn)確，僅供大家參考。

消亡原因

傳統(tǒng)的約束

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

規(guī)范化缺失

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

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

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

而 2003 年也正是 UML 市場(chǎng)戰(zhàn)勝率開始下降的開端，我覺得這應(yīng)該不是純粹的巧合?，F(xiàn)在，我們要探討 UML 的具體問題了。

UML 中包含了非常多種不同的圖和規(guī)則，導(dǎo)致產(chǎn)品太過復(fù)雜。這對(duì)任何人都沒有好處，因?yàn)?UML 變得越來越難學(xué)，配套開發(fā)工具的設(shè)計(jì)也陷入困境。

雖然看似會(huì)畫幾張圖就能上手，但背后的規(guī)范體系并不簡單，所有工具都必須全面完整。所以，除了“泛化圖”外，其他稍稍復(fù)雜一點(diǎn)的內(nèi)容都需要龐大的團(tuán)隊(duì)和充裕的資金才有可能實(shí)現(xiàn)，這就限制了生態(tài)系統(tǒng)的增長速度。最終，開源社區(qū)也拿不出豐富的 CASE 工具，用戶實(shí)際使用的工具就更少了。

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

沒有文本格式

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

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

根本沒有數(shù)據(jù)格式

這個(gè)問題看似與“沒有文本格式”類似，但本質(zhì)上截然不同：UML 只有視覺表示這唯一的格式，令 UML 的導(dǎo)入與導(dǎo)出幾乎無法實(shí)現(xiàn)。一旦開始使用具體工具，結(jié)果就會(huì)被限制在此種工具之內(nèi)，這明顯又制約了生態(tài)系統(tǒng)的發(fā)展：無法制作獨(dú)立的 UML 工具、驗(yàn)證品節(jié)，也無法開發(fā)出任何 CASE 工具擴(kuò)展。

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

無法逆向

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

在采訪 UML 用戶時(shí)，我最常聽到的抱怨就是“UML 太爛了，根本沒法用?！?/p>

文化變革

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

CASE 工具的作用僅限于大型軟件項(xiàng)目，這是因?yàn)橹挥写笮蛙浖?xiàng)目才有很多人長時(shí)間從事相同的工作。這類項(xiàng)目的“官僚化”程度也更高。雖然我們?nèi)缃穸颊J(rèn)同敏捷化正全面取代以往占主導(dǎo)地位的瀑布式開發(fā)方式，但那個(gè)時(shí)候大多數(shù)開發(fā)者都在遵循“事來忙一陣、亡羊再補(bǔ)牢”的工作思路。因此，CASE 工具最初是由企業(yè)在內(nèi)部強(qiáng)制要求使用的。文章作者也提到，真正喜歡 UML 的其實(shí)是企業(yè)高管、而非程序員自己。

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

UML 之后

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

雖然有些人使用 C4 之類的輕量級(jí)建模技術(shù)，但目前主流的應(yīng)該還是 masala 圖。為什么要用 masala？Garbarino 認(rèn)為是因?yàn)樗`活多變、能夠一次性涵蓋多個(gè)維度、既涉及結(jié)構(gòu)又涉及行為、既體現(xiàn)邏輯層面又貫通物理層面，很像是 4+1 架構(gòu)模型視圖的大雜燴產(chǎn)物。

現(xiàn)在生活和財(cái)務(wù)所依賴的數(shù)百萬個(gè)系統(tǒng)，完全是在 masala 圖表的背后設(shè)計(jì)、資助和執(zhí)行的，通常除了一堆史詩和用戶故事之外沒有更多的附屬品。不過在特別嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)系統(tǒng)，如銀行抵押系統(tǒng)并不會(huì)使用潦草的馬薩拉圖。

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