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

UML本身太複雜了。
毫無疑問，在討論軟體架構時，UML包含許多非常有用的圖表。例如用例，類和序列圖。然後使用UML設計時，各種必要元素和非必需元素混合在一起，2010年，我寫了一篇論文“UML的前進之路”  其中提出了重組規範的問題。標準。它不會改變語言，但會改變它的呈現方式。 
該文建議我們應該確定一個必要元素的小核心，然後應該在核心之上新增更高階的元素作為單獨的關注點。因此，我們將使用與我們已經應用於軟體開發方法相同的想法，並且已經產生了用於軟體工程的不必要元素。必要元素是OMG採用的新標準。

UML在大多陣列織中都被嚴重濫用。 
UML用於描述所有內容，而不僅僅是必需品 - 架構。開發人員首先使用UML設計他們的用例，然後使用他們生成的類圖資料表作為編碼的輸入。工具供應商提供了從這些圖中生成程式碼的工具，但由於圖表是由不瞭解實現的人組成的，因此它們可能是無用的。那些不得不編碼的人感到沮喪，只好扔掉了設計並重新編寫了所需的程式碼。嗯，說實話，很多組織都做得比這更好，但是公平地說，UML使用得太多而且太多了。畢竟UML是一種建模語言，而不是像C ++，Java或任何更現代的語言，如Python，Haskell，Erlang這樣的實現語言。(banq注：使用UML構建DDD的戰略模式是很好的)

但是，如果以智慧方式使用UML，則它非常實用並且會產生具有更高價值的產品。UML是一種建立架構的好語言。它對敏捷團隊非常有效。在早期的衝刺中，您可以建立體系結構路線圖。該路線圖使用了非常簡單的UML版本，它可以識別最關鍵的子系統，它們的互動，使用者故事或類似內容，以及您認為至關重要的任何其他內容。在以後的衝刺中，您可以隨時改進路線圖。關鍵在於您透過架構思維引領的每個衝刺。 

UML被濫用是在軟體開發領域變得時尚的一切。但是，如果以智慧方式使用UML，它確實有助於團隊瞭解他們前進的方向。


很明顯，UML的興趣在敏捷的早期大幅下降，但我認為在向大型組織擴充套件敏捷時使用量會增加。從我的視野看，UML甚至沒有接近死亡，但我認為它需要更好地反映它的使用方式。如果它能夠生存下去，它就像其他一切一樣需要跟上它的環境。UML是20年前開發的，當時大多數人都遵循一種令人窒息的開發方法，而忽略了軟體開發的人性方面。我想看一個更好地反映我們今天所處位置的UML n.0。如果這種情況沒有發生，恐怕我們會看到新一代的建模語言，UML至少會成為靈感的源泉。