UML已死？其實是敏捷惹的禍？

banq發表於2019-01-03
敏捷
從Google趨勢來看UML沒有增長，是否意味著已經死亡，UML（以及RUP，AOSD和Essence）的建立者之一Ivar Jacobson回答了這個問題：

(認為UML已死)這不完全正確，毫無疑問，這是早期的敏捷方法拋棄了架構，導致了對UML興趣大幅下降。
而現代規模敏捷方法包括作為目標的架構路線圖，這是多個團隊的努力目標。團隊學習的東西越來越多。而改變一個sprint接著一個sprint地改變，架構只能以某種方式表達了，這樣，輕量的UML被採用，這樣的UML被由多種工具支援。
我同意20年前使用UML方式沒有這麼聰明，太多無用的圖表，在軟體開發領域任何時尚的事情都會發生，但是，如果以更聰明方式使用UML，真的有助於團隊瞭解他們的開發方向。
關於UML死亡的謠言都是假的。

其他人的觀點收集：

UML是一種記錄軟體的方式。不是唯一或最好的。它在過去非常有用，TODAY用於教授OOP和DB。您不需要正式的大學UML。只有上下文理解的基本知識。

確實，UML被那些沒有程式設計的“老闆”所喜愛，但它並不一定是壞事。PD。當UML的建立者討論你時，它會讓你思考你的觀點有多遠。

敏捷拋棄架構和UML完全是胡說八道。我從1998年開始使用eXtreme程式設計，因為@ martinfowler的影響而閱讀UML Distilled 。我們在白板上進行了大量的架構和設計討論，當然我們使用的是UML。

我確實認為，目前缺乏架構思維，前期設計，文件，UML，建模等，直接歸因於敏捷宣言的廣泛誤解和誤用。

設計和架構討論絕不意味著使用UML。房間裡的每個人都能理解的任何視覺方法都很好。

UML在很大程度上由於與慢速方法的關聯而被廢棄。但它在專案中非常有用。

我完全贊同Ivar。它不是關於工具或標準，而是關於我們可以給予它們的用途。UML仍然是那些瞭解其使用，優點和缺點並知道如何使用它們進行有效溝通的人手中的有用替代品。

UML不會死，文件對於專案很重要，另一件事是開發人員在沒有任何規劃，分析和設計的情況下編寫程式碼，您可以在其中找到專案的缺陷或優勢

UML可以說是我們每天使用的原始語言，甚至是潛意識裡的。

如果沒有UML，許多人可能更難理解軟體架構的基本概念。UML並非無用。但是，你需要整容。敏捷方法在開發的某些部分需要更堅實的基礎。UML必須作為支援

框架仍然使用POO中的許多設計和架構模式，用UML解釋。我認為這種語言存在的部分原因歸功於上述內容。用UML描述設計模式的部分對我來說似乎很重要。

在考慮架構時，我會考慮業務流程。Uml和bpmn或archimate模型非常有用。

這句話對我來說沒有意義，因為UML是一種語言，而不是一種方法。它可以很好地用於臨時討論。XP中的任何內容都不會阻止您保留和維護生成的圖表，如果它們對將來的參考有用的話。

我1996年才從大學畢業。我當然也看到了許多重要的前期設計。我要說的是，許多團隊非常明確地告訴我他們不做*任何*前期設計......“因為敏捷”。

@ martinfowler : 設計死了嗎？描述了敏捷和前期規劃之間對設計（架構）的不同態度，我認為它仍然具有相關性。

我當時加入的團隊既沒有聽說過XP，也沒有聽說過UML或者前期設計。混亂的大泥球是常態。無論哪種方式，它都不是放棄架構的敏捷方法，而是懶惰/未受過教育的開發人員。

一些團隊明確地告訴我他們做*沒有*正面設計。最近一個團隊說，“當我們得到要求時，我們才開始編碼，因為我們正在關注極限程式設計”。

架構和設計被視為不必要的開銷。管理層認為，開發人員可以輕鬆替補​​架構師並跳入直接編碼是有效的。

“缺乏前期設計”是XP中的故意。如果做得恰當，TDD / BDD會隨著時間的推移而改進設計。同樣，缺乏外部技術文件，UML，建模等，在XP中是有意的，而且最敏捷。它不是良好的設計或架構所必需的。

敏捷宣言說，“在綜合文件上執行軟體”和“也就是說，雖然基於文件的專案有價值，但我們更重視執行的專案。”

敏捷宣言說，“綜合文件”是有價值的。不是“你不需要寫任何文件”或“你永遠不應該寫任何外部技術文件。” （並且它表示在編寫和交付工作軟體方面有*更多*。）

UML通常會在軟體團隊中觸發VOM。SCRUM也是如此。

其他：

關於UML已死的謠言都是假的

從文字描述生成UML圖

相關文章