為什麼UML“真的”死了？ • Buttondown

banq發表於2021-04-28

網際網路上有一篇名為“UML就這麼悄悄死掉了嗎？”帖子，文章中Ernesto Garbarino說，UML被降低標準的程式設計師所殺死：“敏捷是刺客，而使用者故事是她致命的、有毒的箭頭。” 如果本新聞稿有一個主題，那就是我們不應該相信簡單的答案。現實世界很複雜。
碰巧的是，幾年前，我正計劃編寫UML的歷史：它來自何處，為何如此流行如此之快，為什麼它死了等等。作為其中的一部分，我採訪了許多UML的知名人士。早期包括Grady Booch，Bertrand Meyer和Ed Seidewitz。現在我仍然記得一點一滴，足以自信地說，這個故事比“敏捷做到這一點”要複雜得多。免責宣告，我的記憶力和四年前我放棄的一個專案的字跡模糊不清，所以我可能弄錯了一些細節。
 

史前史
UML產生了兩個重要的趨勢。首先是“方法大戰”。在Smalltalk和C ++成為主流的OOP之後，人們真正大量宣傳並最終建立用於設計軟體系統的正式統一的流程。這引發了不同設計方法的爆炸式增長。Bertrand Meyer在他的《 Business Object Notation》一書中列出了26種競爭方法。我記得閱讀過列出50多個文件，但似乎無法再次找到它們，因此可能是錯誤的記憶。
大約在同一時間，人們還製作了第一個計算機輔助軟體工程（CASE）工具。現在，CASE只是一個腳註，但在當時是一個巨大的行業，預計將比CAD或IDE大得多。CASE工具與方法整合在一起，不僅為開發人員，而且為測試人員，專案經理和客戶提供了一種整體的軟體建立方法。但是，製作CASE工具非常昂貴，並且必須針對特定的設計方法進行定製。隨著時間的流逝，CASE供應商選擇了以下三個：

  • Grady Booch的物件導向的分析和設計
  • Ivar Jacobson的物件導向軟體工程
  • 詹姆斯·朗博（James Rumbaugh）的物件建模技術

格雷迪·布奇（Grady Booch）為Rational效力，後者也有大量的CASE產品，且他們大部分的收入都來自Ada工具。Booch還和Rumbaugh是私人朋友，隨著時間的流逝，他們的想法趨於一致。在此之後，一致的想法給他們施加了很大的驅動力，要求他們進行明確的協作，以便CASE供應商僅支援兩種方法，而不是三種。然後，由於一種方法優於兩種方法，他們購買了Jacobson的諮詢公司，並逐步淘汰了OOSE。
OOSE，OOAD和OMT是整體方法，涵蓋了表示法和過程。消除符號差異要比處理差異更容易，因此Rational將統一分為兩部分。統一建模語言於1996年問世，並移交給物件管理小組（OMG），而Rational Unified Process則於1997年問世。UML在大約十年中被證明非常受歡迎，並且大約在2004年開始引起人們的廣泛關注，直到今天，也就是我們釋出“ UML死了嗎？”之類的文章時，那麼為什麼UML死了？
 

這意味著什麼？
這個問題有兩個歧義。首先是我們所說的“死”。程式設計師通常使用“死亡”來表示“相對市場份額的下降”，而不是絕對市場份額。許多意見領袖Thought Leaderz抱怨幾乎沒有開發人員會真正瞭解底層系統，但是與30年前相比，核心駭客總數有所增加，但這些駭客數量只是佔用所有程式設計師數量中較低的一部分。
這意味著UML可以同時增長和“消亡”，具體取決於您使用的度量標準。現在，我假設UML無疑是“垂死中”。
另一個歧義是我們所說的UML。首先，UML包含十幾種不同的圖型別。我仍然看到人們經常使用順序圖。其次，人們使用UML圖的方式有很多。UML和敏捷領域的傑出人物Martin Fowler ，確定三種用途：草繪，藍圖和程式設計。
以UML程式設計的方式在嬰兒期就死了，因為即使UML的大多數支持者也認為這是一個可怕的想法。以UML進行需求快速捕捉（速寫）卻沒有死，只是類似一種水上漂流狀態而已。
人們使用非正式草圖符號與UML標準保持同步，因此隨著時間的流逝，它逐漸演變為多種相互難以理解的方言。所以我們不會看到在不同公司中的兩個團隊，一個在加利福尼亞，另一個在紐約，使用相同的符號，除非有人故意使它們保持同步。
這使UML藍圖成為最複雜的情​​況。據我瞭解，它也是Rational最想要的一種。作為藍圖的UML和作為草圖的UML之間有兩個相關的區別。
首先，他們目的是讓設計人員編寫藍圖，並由程式設計師實施藍圖。這意味著不同的技能和不同的工具。其次，UML-as-blueprint整合了不同的圖型別。您不僅要編寫一個類圖和一個需求圖，還要為實現了需求圖的類編寫一個類圖。這意味著使用CASE工具進行藍圖。
因此，UML的下降通常與CASE工具的下降聯絡在一起。 這意味著“為什麼CASE工具會失敗”與為什麼UML藍圖“會死”一樣有趣。
 

UML將死的原因
在方法戰和CASE工具興起之後，UML出現了。市場上已經有大量用於OOAD，OOSA和OMT的CASE工具，而UML必須與這三個工具都向後相容。從一開始就增加了很多摩擦。如果UML不必與傳統供應商打交道，它本來可以更簡單並且在概念上更加統一。

  • 缺乏形式化

UML留下了許多未指定的內容，例如圖表互動的方式以及許多關鍵字的實際含義。UML 1.3在類圖中給出了“generalization”箭頭的示例:

為什麼UML“真的”死了？ • Buttondown
其中Sailboat(帆船)是WindPoweredVehicle（風能驅動運輸工具）和WaterVehicle（水驅動運輸工具）的specializations ，它們都是Vehicle（運輸工具）的specializations 。從設計角度來看，這實際上意味著什麼？我們是否應該使用繼承以特定方式實現它？這與細化關係（efinement relation）有何不同？在實踐中，使用者可以決定這些關係的含義，而CASE供應商可以決定要實現的功能。
這可能使您想起C語言：C89具有如此多的未定義和使用者定義的行為的原因是，它需要容納所有衝突的編譯器。OMG（1.0版後UML的維護者）也有同樣的問題。他們無法對UML標準進行任何更新，以免破壞現有的供應商決策，從而進一步減慢了UML的開發速度，並增加了每個修訂的複雜性。

  • IBM公司

這是我從一位外圍人那裡得到的八卦。當時，雖然OMG受現有供應商差異的約束，但他們仍有一定的餘地來為“更大的利益”做出重大改變。我懷疑Rational作為UML的原始開發者和最大的CASE工具供應商之一，Rational特別願意更新其舊版軟體。但是後來IBM在2003年收購了Rational，他們很快就停產了Rational的UML工具，並開始銷售專有的CASE工具Rational Software Architect。因為他們不想繼續發展傳統的Rational專案，他們封鎖了甚至任何UML變化輕微不相容的，UML作為一個整體停滯不前。
當UML的市場佔有率開始下降時，2003年也差不多。我不認為這兩件事是巧合。
  • 太複雜

現在，我們要探討UML的特定問題。UML包含許多不同的圖和規則，導致最終產品非常複雜。每個人都為此感到難過，這使學習UML變得多麼困難。這也使開發工具變得困難。您只需要瞭解幾張圖就可以逃脫，但是在整個規範中，任何工具都必須是全面的。如果您想構建比“生成圖”更復雜的內容，則需要一個龐大的團隊和大量資金，這限制了您可以實際增長生態系統的數量。開源世界並沒有大量的CASE工具，而您獲得的工具卻很薄弱。
這並不是說商用CASE工具可以創造奇蹟。您的表示法越複雜，為其開發任何工具的難度就越大。 如果CASE工具能夠完成令人興奮的創新工作，那麼UML的使用時間可能會顯著延長，但是事實並非如此。
  • 無文字格式

這是對工具的又一拖累。這意味著您無法在自己喜歡的文字編輯器中編輯UML圖表，也無法對其進行grep編寫，也無法編寫自己的定製解析器等等。
已經嘗試過為UML建立文字表示形式，例如PlantUML或Mermaid，但是這些遇到了兩個問題。首先，它們只是單向的：您不能將現有圖轉換為文字形式。第二個問題是我所說的Graphviz問題：文字格式在表示視覺佈局方面很糟糕。在最好的你已經有了一個繁瑣的系統，該系統比使用一個圖形編輯器顯著惡化。
  • 完全沒有資料格式

這使得匯入和匯出UML基本上是不可能的。一旦開始使用工具，就會被該工具所困擾。在明顯的問題中，這又是生態系統的殺手。您無法制作獨立的UML工具，驗證器或必須作為CASE工具擴充套件執行的任何東西。OMG試圖透過XMI（一種UML的XML格式）來糾正這一問題，但是據信它從來沒有那麼好過。而且它在XMI和UML版本上都向後不相容，這使其異常脆弱。
  • 無法正向逆向

一些工具可能會從UML規範中生成程式碼，但是可能會對某些修改後的程式碼進行逆向工程圖處理。沒有人能做的很好。就像所有藍圖一樣，UML和程式碼將不可避免地不同步。
  • 文化轉變

最後一個高度投機的理由。Garbarino在原始文章中說，UML之所以死是因為敏捷接管了文化。我確實認為文化轉變在UML的下滑中發揮了作用，但這並不是出於他的想法。
CASE工具僅對大型軟體專案有意義，因為在大型軟體專案中，很多人長時間從事相同的工作。它也是高度“官僚”的。雖然我們今天認為敏捷取代了占主導地位的瀑布，但在那時，大多數開發人員都是臨時性地和漸進式地工作的。由於這些原因，CASE工具最初是由強制內部使用的企業採用的，這似乎是合理的。正如Garbarino自己所說的那樣，UML受到了業務人員而不是程式設計師的喜愛。
 
傳統企業在1990年代是軟體的主要僱主，這意味著技術趨勢可能反映了他們的興趣。這將是UML最初興起的一個很好的解釋。但是，在過去的二十年中，軟體文化逐漸向大型技術優先的公司和初創公司轉移。從歷史上看，兩者都不是CASE供應商的目標受眾。隨著時間的流逝，傳統企業開始從技術和初創企業那裡借鑑學習，反之則相反，這導致CASE在現有領域中的地位逐漸下降。
 

相關文章