UML死了，但是形式方法能成功嗎？ •Buttondown

上週二的文章“為什麼UML“真的”死了”風靡一時。我很高興人們喜歡它，我也很高興使用所有休閒研究它，但是有些事情困擾著我。人們並沒有從UML切換到其他東西。他們完全擺脫了思維定勢。UML並沒有滿足程式設計師的有意義的用例，因此，當它不起作用時，他們就不會尋找替代方案。

排除所有環境上的優勢，例如“它具有文字格式”和“複雜程度大大降低”，然後考慮必要的附加值。UML的“重點”是藍圖。

人們可以在實施軟體專案之前對其進行設計。這也是形式方法的重點。

人們不尋求UML替代品的事實應該讓我感到擔憂。這可能意味著建模對軟體工程師沒有用，考慮到這太可怕了，所以我轉而採取更加樂觀的態度：建模雖然有用，但是UML卻不值得。

使用UML實際上能為您帶來什麼？夢想是UML與程式碼之間的來回程式碼同步，以進行模型驅動的開發，但是這個夢想從未實現。

在整個生命週期中，UML的價值一直在於擁有UML圖。它應該可以幫助您與團隊進行精確的溝通，並可以作為編寫實際程式碼的參考。

但是，這些還不足以使其有用，即使捍衛UML的人也僅使用了少數圖表，並且將其作為草繪符號，而不是藍圖符號。而且，如果也有任何東西可以代替它，那麼從原則上講，設計沒有任何用處。

...

網友評論： 

在我的職業生涯中，我發現在很少專案中能有效使用了形式化方法。的確，我認為UML在v 2.0的道路上走下坡路的主要原因是努力使其更加形式化。

UML最初被設計為一種用於視覺化和推理系統的語言。它從來沒有打算成為一種視覺化程式語言，而正是通過引入相當大的複雜性來削減了它被使用的原因。

UML的重點不是“讓我們視覺化程式語言可以實現的一切”，而是“讓我們提供一種我們可以用來協作，交流和進行設計推理的媒介”。

UML之所以死亡，是因為人們對它的要求超出了預期。它被認為是一種設計工具，可以捕獲，視覺化設計並進行討論。但是全世界都堅持認為它也是一種編碼方法，其結果對兩者都沒有好處。

我確實相信，敏捷及其相關的文化轉變對UML衰落的影響比其他任何因素都大得多。可以肯定的是，UML似乎太詳細，太複雜，工具很爛等等。

“我們是敏捷的”，“這是敏捷中不會期望的”，“我們不想告訴開發人員該怎麼做”，“您會被視為過時的”，這是團隊放棄UML的原因型別。知名的敏捷傳教士實際上是在告訴人們他們不需要UML；引入敏捷宣言後，還有一個很大的“我們不需要架構師”運動，進一步將前端設計，文件，UML等推後。我曾與大型組織的架構師進行過多次對話，他們告訴我在這段時間他們感到非常被敏捷運動排斥在外。眾所周知，團隊部門仍然需要這些架構技能。沒有它們，就不可能是“全棧式”的。我聽過所有這些故事...團隊內部/外部沒有標準的交流方法，重複/浪費的工作，難以招募新員工，程式碼庫亂七八糟，因為開發人員對它的工作方式有不同的看法，等等。

banq：實際上事件風暴替代了UML序列圖和狀態圖，而DDD聚合非常適合使用UML類圖表達。這些都是不同的新舊形式化方法，也是一種非正式的形式化，形式化方法越是規範嚴格，雖然邏輯更嚴謹，更能直接生成程式碼，但是使用人員掌握起來就複雜，不如直接學習程式設計，兩者之間是一種矛盾，但是通過一種快速方法能夠對需求實現摸著石頭快速過河是永遠需要的，不管敏捷還是UML或低程式碼或BPMN或快速可視乎開發都是試圖實現這點。