UML就這麼悄悄死掉了嗎？ (Ernesto）

由Rational Software開發並於1997年被Object Management Group（OMG）用作標準的統一建模語言（UML）旨在標準化軟體工程領域中的幾種不同的圖形符號。

我與UML的戀情始於近十年後，當時我開始宣傳UML作為一種彌合IT與業務社群之間鴻溝的語言。我從來沒有完全相信過UML作為建模具體軟體工件的一種符號的價值。我的目標是使用UML來描述設計中的給定系統所期望的所需結構和行為特性。

對我來說，我無法忍受非正式的Visio流程圖，因為會受到含糊不清的困擾。例如，從方框中出現的兩個箭頭是否表示對流的選擇或將流分成兩個平行的軌道？同樣，指向單個框的兩個箭頭是否意味著活動在第一個流程到達框後立即開始？是OR，XOR還是AND？你明白我的意思。UML通過引入清晰明確的語義來解決此問題。

我投入UML經歷：

• 我主要在2004年至2015年之間使用UML為七個不同的僱主和客戶繪製了自己的解決方案的大多數圖表。
• 我為兩個大客戶執行了UML新手訓練營（面向業務分析師）。
• 作為碩士論文，我確定了離散數學的關鍵集合，這些集合是大多數結構和行為UML模型的基礎。我什至用Haskell和GraphViz編寫了一個工具，將所說的數學視覺化回到圖形UML。

幾年後，大概在2015年左右，我意識到我已經停止使用UML，其餘的同行以及我最近諮詢過的幾乎所有《財富》 500強客戶也是如此。發生了什麼？

UML並沒有因為其複雜性或嚴謹性而被商業界所殺。與此相反， 商務人士喜歡使用少數幾個新的約定符號來進行清晰而明確的溝通的能力。是IT人員將UML帶到商務人士桌面上的（就像我以前所做的那樣），並在一夜之間把它撤走了。

但並不是UML本身就被殺死了。公平地說，UML只是附帶被損害的。真正變革涉及整個需求工程領域，包括業務分析和設計。敏捷是變革者，使用者故事是敏捷射出的致命有毒的箭頭（雙關語意）。

在將使用者故事倒入香腸機並在其末尾獲得演示的模型（或在DevOps商店中釋出功能性產品！），不再需要針對性地進行結構化問題分析了。

在當今勇敢的新世界中，理解直接形成為可用於生產的程式碼。甚至整個業務實體建模都被敏捷的姊妹學科：領域驅動設計（DDD）所殺死。有界上下文封裝了（複雜的）複雜性，因此企業可以通過新增兩個披薩團隊來進行擴充套件。僱用BDD並要求其業務團隊直接編寫Cucumber規範的測試在這裡佔據上風，但是很少有企業這樣做。

今天的範例是，我們無論如何都無法理解這個問題。數字化轉型專家告訴我們，我們應該將其部署到生產中，並讓使用者告訴我們業務需求是什麼，而不是自己先提出需求。我們可以多次進行shot直到正確為止。是的，失敗很快，而且經常失敗。

所以現在您明白了。它與UML的缺點無關。我們只是放棄了業務分析和正式規範，而將其帶到下一個問題：如果不用UML，我們將使用什麼？

儘管有些人採用了諸如C4之類的輕量級建模技術，但我現在所使用的大多數圖（有時是貶義的）都是masala（馬薩拉）圖。別難過，我這樣稱呼自己的圖表。為什麼要馬薩拉？因為他們是非正式的；它們一次覆蓋多個維度，可能既是結構上的又是行為上的，邏輯上的和物理上的。它們通常是4 + 1建築模型檢視的雜亂無章。

數以百萬計的系統是您生活和財務賴以生存的系統，完全是在上述masala圖的背面設計、資助和執行的，通常也不會比一堆史詩和使用者故事帶來更多附加值。

可能你會說：我的銀行抵押系統尚未使用您描述的這些可怕的masala模型之一進行設計。

如果您的銀行沒有執行CICS，並且該解決方案是在去年出售的，則很有可能完全是使用我在談論的那種masala圖完全構思了該解決方案。

Masala圖雖然起作用。如果您以它們的本質來接受它們，那麼它們可以是美麗的東西。瞧，它們不是規格。他們的目的是喚起情感。根據Marie Kondo的原則，Masala圖在每個圖的目標利益相關者的心中激發歡樂時，就很有價值。

儘管我不同意敏捷陣營中的朋友，但我對人類的幸福視而不見。我的客戶和同行不僅不斷要求提供更多的masala圖，而且還堅持要求我使它們變得更加masala（我將它們合併到更多的建築尺寸中！）那麼，為什麼要這麼固執？

UML仍然存在於我的心中，我仍然使用多個維度來構造解決方案，但是今天，我以純資料/表格方式進行操作。當需要圖片展示的時候，我就為可愛的顧客製作了令人愉快的masala圖。

黑客新聞網友討論

我們停止使用UML和其他前期繁重的計劃方法的原因是，我們計劃的總是錯誤的。過去，軟體專案通常會大大超出預算，交付時間很晚，而且通常還是不能滿足客戶的需求。事實證明，客戶不知道他們想要什麼，或者至少不能正確地向業務分析員明確說明。通過儘早交付，我們不僅可以儘早為客戶釋放價值，而且還可以得到反饋，使我們和客戶能夠了解他們的需求。而且，事實證明，工程團隊比架構師更瞭解如何開發軟體。我們通過將專案分解為（如他所說的）“比薩餅團隊”大小的元件來解決複雜性問題，並著重於定義這些元件之間的介面，而不是深入瞭解資訊在程式碼中如何流動。當然，這會導致其他複雜性，但是它們不會帶來大型，整體式設計所具有的同類交付問題。

總而言之，從設計繁瑣的方法轉向改變了交付方式，為我們的客戶創造了價值，並使員工的工作效率更高。

您永遠不會像您想象的那樣瞭解自己的問題領域。我總是嘗試啟動一個新專案，假設一切都會改變。奇怪的是，這種做法往往會產生相同的最終結果是假設什麼會改變。如果您不知道需求將如何隨著時間變化，那麼就沒有任何猜測。只需編寫第一批需求所需的程式碼，別無其他。當有新的需求時，將一個抽象層新增到一個簡單的系統要容易得多，而當您最終意識到不需要它時，則在以後刪除一個抽象層要容易得多。

我認為UML及其類似物在開發人員和團隊之間仍然具有巨大的價值，以一種易於理解的方式傳達複雜的流程，並促進了共同的理解。

UML的精度過於精細。沒人關心語言的大多數特定規則和語法，因為輸出被設計為通常由外行聽眾閱讀。與其把時間花費UML製作上，不如重建良好的通用圖上的時間更好。

我一直將UML視為進入域的視窗，而不是將其視為程式碼的先驅。僅使用幾個用例圖，一些類圖，甚至可能是一些序列圖，您就可以傳達最終系統應該做什麼以及人們將如何與之互動。如何實現的細節將從所使用的體系結構中得出。我總是發現即使是很少細節的基本圖表（沒有欄位的類）也非常有用，但是人們不想“浪費時間”而錯過了它們。

我曾經在一個軟體工程課程中將建模/規範技術分為三類：非形式，偽形式和形式。非形式規範只是釋出著一些圖表。它們非常有用，生產起來也不耗費大量勞動，因此它們的用途顯而易見，但缺乏精確性。形式規範使用某種形式主義來精確定義程式的行為（通常以某些數學啟發的符號，例如Z）來定義程式的行為。如果有的話，它非常有用，但是需要大量勞動來生產，沒有太多的人可以舒適地閱讀或編寫這些內容，並且很難滿足不斷變化的需求。

我認為像UML這樣的偽形式表示法的賣點是，它將是“兩全其美”的地方，您將從中獲得形式規範的大部分好處，而工作量則與非正式規範更相似。相反，我的理想是兩全其美。額外的工作不如形式規範那麼高，但是您從額外工作中獲得一點收益：規範的精確性仍然比非形式規範更接近形式規範。

UML的詞彙表提供了有用的共同基礎（例如，將元模型和類圖與物件圖區分開），但是超出最基本的圖的花哨的UML功能不僅會很耗時，也不是白板上討論的重點，且過於繁瑣和繁瑣。對於詳細設計和模型驅動的程式碼生成的預期用途，從根本上講是非形式的，而標準化則提供嚴格的負面價值。

我認為是肯特·貝克（Kent Beck）提出了舌頭的銀河標記語言（GML）作為他的首選。它具有非常清晰的語義：一個盒子是一個盒子，一個箭頭是一個箭頭。我個人總是發現，形式主義較少的圖表可以更好地進行溝通，因為您可以專注於為思想提供基本框架，而不是淹沒僅在某些情況下才有意義的細節。

我會使用從真實程式碼，資料庫模型等生成的圖表作為UML替代。

UML的一個問題是，它是為UML工具供應商（IBM狂想曲，Enterprise Architect等）開發的，而在UML 2中更為嚴重。就像我們有一個編譯器供應商設計並推廣一種通用程式語言一樣，將其宣告為一種行業標準，它取代了所有替代方法，並且出於他們的利益而鎖定所有程式設計師。

幾年前，我學習了UML，但發現PowerPoint可以很好地解釋需要完成的工作。使用PPT繪製草圖甚至比Visio都容易得多。

UML之所以死是因為現代軟體開發不像設計飛機那樣，而是設計一種新型飛機的研究計劃。對於程式設計師而言，他們將要建立的平原是如此之大和複雜，以至於程式設計師的行為還不完全清楚。因此，要設計一個特定的應用程式，程式設計師必須在平臺上執行一系列實驗，以確定將其用於支援應用程式目標的方式。當這些實驗完成後，程式設計師可以花一些時間進行設計，但是在大多數情況下，程式設計類似於進行研究，然後進行一些設計。對於大型系統，必須有人設計，但是進行這種設計的最佳方法是通過白皮書，以及大規模實驗以及可能的模擬和分析。除了為圖表建立通用詞彙表之外，UML並不是特別有用，該任務可以更簡單，更非形式地完成。

我曾經開發過下一代高階OO CASE工具，並且非常擅長於系統分析/設計/等，視覺思維和交流等，我仍將使用專用的UML工具進行最熟悉的靜態物件建模。而且，如果該工具很好地支援它們，那麼我還將用於狀態建模，事件跟蹤，Jacobson用例建模以及其他一些UML（例如，活動圖，尤其是物件流，而不僅僅是流程圖控制）。

我最喜歡的UML：

-序列圖：非常適合理解分散式工作流程

-狀態圖：狀態機是很棒的工具。

序列圖可能是最有用的UML圖。我不知道一種更簡單的方法來指定和記錄工作流程，無論規模如何（從功能到整個系統）

21億美元-這是IBM在2003年收購Rational軟體的價格。“三個朋友”（Grady Booch，James Rumbaugh和Ivar Jacobson）使用了不同的建模方法，因此決定“統一”。UML的大肆宣傳是為了獲得採用和進入市場。其他人也陷入了炒作之中，也賺了一些錢，例如馬丁·福勒（Martin Fowler），他撰寫了UML提要，然後從事敏捷和Thoughtworks的開發。特別要提到現在不知名的Alistair Cockburn，他寫了一本書，並圍繞用例的混亂做了很多諮詢。用今天的語言，Rational Rose將成為“企業建模的Uber”，而UML和RUP將成為護城河。為什麼我們不再使用UML？答案是：這三個朋友退出了市場；但是為什麼沒有什麼東西可以代替UML？答案是：不需要。

我認為，隨著PlantUML的普及，UML在2010年代重生。PlantUML比大多數早期的UML相關軟體更適合用於網路建模。雖然原始UML標準不是專門為表示網路而設計的，但是PlantUML具有內建的網路圖型別。而且，PlantUML的可擴充套件性還可以覆蓋許多用例。我以為只要應用一定的強度，就可以為“ masala圖”建立PlantUML庫。另外，“敏捷”陣營通常會喜歡這種工具。

UML與物件導向的程式設計緊密相關。在2000年代，OO程式設計風靡一時，擁有“設計模式”的精巧筆記本被認為是真正的軟體工程師的標誌。從那時起，OO失去了很多光彩，與之最相關的語言（如Java和C ++）被認為有些笨拙和不酷。即使在實踐中，大多數流行的程式語言借用了命令性，OO和功能性特徵的組合，函數語言程式設計也成為了討論的“智慧”正規化。在您可以建立SQL資料庫並使用它的時代，UML也很流行。更多資料庫品種的引入使事情變得複雜。除了OO，UML還與非程式設計師進行的“可視”程式設計緊密相關。這種正規化註定要每三年更新一次，並將其作為下一個大事件推向永恆，直到永恆，我們目前是以最新的無程式碼趨勢看到這一點，但在2000年代與UML相關聯。最終，與語言無關的資料格式（如JSON，Thrift和protobufs）開始流行。當我可以製作實際的資料結構然後立即將其作為二進位制格式時，為什麼還要製作UML圖呢？在一定程度上，UML意味著“資料建模”。

在我看來，UML的最大問題之一是它醜陋且不是很直觀。有一陣子，我跳上了UML潮流，並開發了許多各種型別的圖。事實證明，即使是非常有經驗的開發人員也不瞭解他們，更不用說技術含量較低的人員了。現在，我只用箭頭畫幾個盒子，通常就能傳達出資訊。UML作為程式碼生成器也可以用於真正的演示，但實際上，複雜系統的圖表比程式碼更難閱讀。

UML只是另一個糟糕的主意，它想降低業務邏輯部分的複雜性，但實際上它是：

• -在業務邏輯上增加了UML的複雜性
• -在“樂高樂園”（UML規範需要執行的程式碼塊）上增加了過多的過度設計和複雜性
• -在編碼部分增加了巨大的複雜性（開發人員突然不再看到整個流程，不僅犯了愚蠢的錯誤，而且無法優化可以優化的東西。）

沒有銀彈。沒有銀彈。沒有銀彈。正如艾倫·凱（Alan Kay）所說，程式設計是一種“流行文化”，對最新的流行技術更感興趣。我們擁有如此眾多的程式語言（其中許多是相對較新的語言）這一事實證明了我們並不真正瞭解我們在做什麼。

UML很爛，因為它要花很長時間，如果您的軟體發生更改，則必須更改UML。在計劃階段，我只使用Draw.io，但是一旦系統實際存在，它總是會過時且無關緊要。

UML之所以死亡，是因為大多數程式碼是由不在乎官僚機構或只關心編寫程式碼的人編寫的。UML承擔了一種語言來指定設計，以便其他人可以實現它，或者至少這就是我所看到的用法。但這在大多數情況下是沒有意義的。我們已經知道，編寫軟體的更有效方法是由一個人同時設計和實施該設計。這意味著UML已被降級為僅用作文件。

我用Archimate代替了UML，我討厭UML的發展方向，以及討厭從原始碼中刪除程式碼/逆向工程的概念-這個想法足夠新穎，但絕對是花架子。架構很重要，這可以通過Archimate imo很好地實現。對我有效的方法可能對您不起作用。我仍然使用UML中的某些元素，但通常在白板上用作用例，簡單的序列圖或狀態圖。該程式碼是自我記錄。

在某種程度上，UML確實取得了成功：這是描述類圖，狀態機等的事實上的方法。這不能被低估。

UML與J2EE的思路相同，這是我25年以上職業中遇到的最糟糕的事情。J2EE承擔了軟體的複雜性，使其不僅更加複雜，而且還帶來了災難性的乏味。然後，“專家”不再是軟體開發人員，而是官僚。這是銷燬Java和企業軟體的完美方法。UML是零基礎的企業軟體中最糟糕的部分的遺物，我很高興它完全死了。

我認為UML的最大希望是程式碼生成，所以UML-> code，但是問題是，當需要對生成的程式碼進行手動微調時，沒有code-> uml的執行過程。

OOP之所以在軟體業務中如此受歡迎的部分原因是因為它消除了業務功能與其生產的軟體之間的阻抗不匹配。從這種觀點來看，UML是業務計劃和軟體計劃之間的一種中間位元組碼。

說到uml，在我的大學裡有一個通用的“軟體工程”課程，並且有一個關於UML圖表的部分。我記得建立這些看起來像蜘蛛網的絕對野獸UML圖。這很有趣，但是在現實世界中絕對沒有用。

多年前，我嘗試了UML，但收效甚微。我最近開始使用BPMN 2並取得了一些成功-泳道對於大多數人來說很容易解釋並且很有意義。ERD仍然是我最喜歡的符號，並且確實經受了時間的考驗！

我從來沒有遇到過UML，但是可以為SysML說幾句好話，它是建立在UML之上的。在嵌入式軟體/硬體專案上工作，我發現SysML對於系統設計和文件編制非常有用。主要是BDD，IBD，序列和狀態機圖。在某些時候，引數圖也可能會派上用場。SysML使用者傾向於不太活躍的行業，尤其​​是那些使用許多前期設計來製造昂貴昂貴的硬體的行業。國防，航空，醫療等。我希望我們會繼續使用它，直到出現更好的情況為止。

UML發生了三件事：

1. 1圖驅動的程式碼並沒有像倡導者所希望的那樣成功（並且在一定程度上有用，UML並不是一門偉大的語言； BPMN卻不錯。）
2. 建模和分析貶值，對建模語言產生不利影響
3.  OMG也最終成為BPMN的所有者（這也受到前兩個因素的影響），而BPMN在功能上與UML有很大的重疊。因此，通過減少視覺化建模語言的作用，您可以在同一組織中獲得該領域中兩個相互競爭的標準，而這兩個標準都不能真正適應當前的使用模式。

在大學時代，我的教授告訴了我很多東西。ORM會殺死RDB，UML是最爛的東西，敏捷是所有軟體工程的未來等等。但是現在我幾乎看不到這些事情發生。

我親自採用了序列圖，向非程式設計領域的專家解釋了過程，並取得了巨大的成功。但是，無法想象在日常編碼實踐中使用UML。

UML的問題在於它是框線式的。線框的麻煩之處在於，它們可以很好地解決小問題，而對於複雜的情況卻毫無用處地重疊在一起。

敏捷殺死了UML。極限程式設計引入了以周為單位的Sprint概念，以及在每個Sprint末尾都有工作程式碼的概念。後來，scrum，看板和其他敏捷方法學至少複製了該過程的那些部分。無論您採用哪種敏捷風格，兩個星期都不會留出很多空間來維護不會隨程式碼一起發展的就像UML圖一樣的工件。您繪製了一個不錯的圖，然後編碼了一個星期左右，然後您的圖就過時了。您可以通過花一些時間來解決它。但是您需要每兩週這樣做一次。極限程式設計之所以極端，是因為它有意地跳過了需求規範和設計文件，因為它們意識到需求是錯誤的和過時的結合，這是由於您在專案中學到的東西所致。因此，設計也是錯誤的。您需要做一些需求，並設計每個sprint。這就是所謂的計劃和評估會議。需求現在稱為使用者故事。而且，由於兩週之內對軟體系統能做的事情很多，因此不需要太多的UML文件來描述要進行的更改。除了極限程式設計外，還提供了諸如白板，照相手機和Wiki之類的工具。您通常使用它們用一些簡單的圖表來進行白板會議，將白板的照片拍下來，然後將其放在Wiki上，沒人再看。如果您要進行兩個星期的衝刺，那就足夠好了。這種會議目的是：共享和交流想法並達成共識。這就是UML死亡的原因：不再需要。建立成本太高，更新成本更高，一旦擁有它就價值有限，一旦停止維護它，保質期就非常有限。

banq注：DDD設計使用UML類圖和序列圖的實現線上視訊：https://www.bilibili.com/video/BV1Yo4y1f7rz/