作者 | Knut Sveidqvist
譯者 | 劉雅夢
策劃 | 丁曉昀
本文首先簡要介紹了 UML 的歷史，這可以幫助我們理解時序圖是如何以及為什麼在大多數 UML 圖被扔進軟體歷史垃圾箱的情況下仍然能夠存活下來。然後展示了時序圖仍然很有價值的原因，以及我們應該如何充分地利用它們。
當你需要文檔化系統的不同部分以及這些部分之間的交互方式時，時序圖確實很有用。
時序圖描述了系統內的操作，並與發送消息的內容和時間進行了映射。
在其最簡單的形式中，時序圖可以在用戶登錄銀行應用程式時模擬用戶與銀行之間的消息和流程。在更複雜的形式中，時序圖可以包括替代方案、選項和循環，以模擬條件流和分支流，例如，在登錄過程還可以包括安全、驗證和其他用戶操作。
如果你沒有廣泛地使用過它們，那麼你可能會在如下兩種情況中聽說過它們：一種是單獨的，作為一種有用的圖類型，在編寫文檔時需要考慮，另一種是作為統一建模語言 (UML) 的一個構件，UML 始於 20 世紀 90 年代末，現在已經很少使用它了。
在本文中，我將簡要地挖掘 UML 的歷史，這樣我們就可以理解，時序圖是如何以及為什麼會在 UML 中的大多數圖被扔進軟體歷史垃圾箱的情況下仍然能夠存活下來。然後，我將展示為什麼時序圖仍然還有價值，以及我們應該如何充分地利用它們。
我的興趣來自兩個方面：我認為時序圖被低估了且並未被充分利用，我認為時序圖是 MermaidChart 的理想用例，因為它使用戶能夠選擇非正式的簡單性，而不必使用像 IBM 的 Rational Rose 這樣的舊工具所產生的剛性複雜性。
UML 的興衰
UML 最初出現在 1997 年，正如 Martin Fowler 在前幾年所寫的那樣，其主要目的是「消除籠罩在面向對象世界上空的圖形建模語言的混亂」。一個基本問題（一個在軟體歷史上反覆出現過很多次的問題）是存在著混亂和困惑，人們真的希望引入一個能夠提供清晰的標準。
Rational 軟體公司於 1994 年開始開發 UML；對象管理組織（OMG）於 1997 年將其作為標準接受；國際標準化組織（ISO）於 2005 年將其作為公認標準。
UML 的興起帶來了興奮和批評，即使它已成為了一種標準（至少在書面上是）。許多人喜歡它，但更多的人認為它有問題，任務無論是 UML 本身，還是人們改如何使用它都存在問題。2004 年，波音公司軟體架構師的一篇文章《UML 狂熱之死》抓住了其中的一些抱怨。
在文章中，作者寫道：「沒有其他技術能像 UML 那樣迅速而深入地滲透到軟體工程的生命周期中」，並認為 UML 已經成為沒有軟體經驗的人設計和控制軟體開發過程的工具。
在此後的幾年裡，更是出現了一些訃告，包括 Ivar Jacobson 在 2018 年的一篇文章（在 UML 成為標準時，他已是 Rational Software 的副總裁）；Hillel Wayne 在 2021 年的一篇文章（他採訪了當時的一些主要人物，如 Grady Booch 和 Bertrand Meyer），以及 Laurence Tratt 在 2022 年的一篇文章（他直接參與了 UML 的標準化）。
這些文章都值得一讀，但它們都有一個在本質上相似的解釋：UML 變得太複雜了（例如，UML 2.2 文檔長達 1000 多頁，UML 變得與繁重且經常浪費時間的前期工作聯繫在了一起。）
UML 超越死亡的生命力
在這一點上，我們談論的是一種已經有近 30 年歷史的方法論，一種支持者和批評者都認為它基本上已經死了的方法論。
然而，正如 2014 年的一項研究所表明的那樣——與研究人員自己的期望相反——他們所服務的大多數開發人員和軟體架構師都在創建「至少包含一些 UML 元素」的草圖和圖表。研究人員指出，「其中大多數都是非正式的」，但這仍然是一種令人驚訝的超越死亡的強大生命力。
偶爾，這個話題也會直接出現，我們可以看看人們是如何談論現代 UML 的。例如，在這個 HackerNews 線程中，一個用戶詢問學習 UML 是否值得他們花時間，雖然大多數用戶都認為 UML 本身是無用的，但也有用戶建議學習一些 UML 技術（其中最主要的是時序圖）。
一位用戶甚至寫道，「清晰的時序圖所帶來的回報，抵得上在大學裡學習所有其他東西所帶來的痛苦和無聊」，這是我見過的一個相當強烈的建議了。Mark Watson 提出了一個更強烈的建議，他與人合著了一本關於 UML 的書，但現在他說「時序圖是我現在仍在使用的唯一類型的圖了。」
我們可以把時序圖的生存能力追溯到 UML 的起源。在 UML 的全盛時期，Martin Fowler 為 UML 確定了三個用例：草圖（sketching）、藍圖（blueprinting）和編程（programming）。
按照 Hillell Wayne 的說法，編程用例的消亡是因為「即使是 UML 的大多數支持者也認為這是一個糟糕的想法。」藍圖用例實際上是看起來最強大的一個，但也消亡了，是因為該用例與 Rational Software 和 CASE 工具捆綁在了一起——這兩個工具都消亡了，也就帶走了 UML。
第一個用例——草圖——倖存了下來，但 Wayne 說，它「漂移到了多種相互難以理解的方言中」。Tratt 對此表示贊同，他寫道，事後看來，UML 在 2000 年「作為軟體草圖的媒介」達到了頂峰。
繪製草圖的媒介是一個比 UML 支持者所想像的還要謙遜得多的願景，但我們不應該低估剩下的東西——尤其是當涉及到時序圖時。
從灰燼中走出來的時序圖
時序圖之所以能夠倖存下來，不僅僅是因為它們是一堆爛圖中的佼佼者，還因為它們真的很有用。正如我在上面所寫的那樣，時序圖的要點是，你可以使用它們來輕鬆地映射和可視化系統中的動態消息流。
消息流可能會變得非常複雜，但時序圖提供了兩個主要組件來創建圖的主幹：
- 生命線（Lifelines），表示對象及對象之間的處理過程。
- 消息（Messages），表示隨著時間推移而交換的信息。
基本組件必須要簡單，因為時序圖旨在表示一個運行中的系統，這意味著所表示的組件將同時、按順序且並行地運行。一個好的時序圖顯示了流、對象之間交換的信息以及在生命線「死亡」之前所執行的功能。
時序圖的主要用例有：
- 在構建系統之前，先繪製和設計系統應該運行方式。
- 記錄新系統的需求。
- 分解並理解現有的（通常是遺留的）系統。
時序圖不能（也不應該）捕獲整個系統，因此在這些用例中，最好的方法是使用它們來可視化系統的使用方式，繪製特定流程的邏輯流程圖，或繪製服務的功能圖。
當你需要文檔化系統的不同部分以及這些部分之間的各種交互方式時，時序圖確實很有用。例如，當你試圖在特定系統中為算法建模時，時序圖就不那麼好用了。如果你做得太精細，太詳細，時序圖就會變得過於麻煩而不值得。但是，當你用它們來繪製不同的「黑盒子」，並展示它們是如何相互交互的話，它們就會非常有用。
但和其他圖一樣，時序圖的成功取決於你的製作水平。然而，它們的質量並不取決於純粹的努力，而是需要一種謹慎、深思熟慮的方法，這種方法從核心流程開始，向外擴展到邊緣案例。
由內而外設計時序圖
你想要製作時序圖的原因可能有很多，但無論靈感是什麼，製作時序圖並解決原始問題的最佳方法是由內而外，找出解決問題的方法。
從合適的路徑開始，努力解決邊緣問題
當你坐下來創建時序圖時，可能很容易從邊緣案例開始，因為邊緣案例通常是最複雜、最需要澄清的。
通常，激發你創建時序設計的可能就是一個邊緣案例（如果你正在創建時序圖來支持架構設計），或者是一個已經存在的、已經很麻煩的邊緣案例（如果你正在創建一個時序圖來更好地理解遺留軟體）。但是，即使你的主要目標是澄清這些邊緣案例，如果你首先從合適的路徑開始，你也會創建一個更好的時序圖。
在你開始時，確定一條合適的路徑——這是信息從頭到尾流動的理想方式。一旦繪製了這個核心時序，就可以向外擴展到其他路由和一些更不頻繁的消息流。
例如，在使用銀行應用程式登錄的示例中，最好從合適的路徑開始——客戶請求訪問權限，銀行授予訪問權限。從這個核心流程開始，可以確保當你仔細思考並記錄不同的流程和邊緣案例時，該合適的路徑仍然是你的錨點。
在此基礎上，你可以為幸福之路增添更多的複雜性。在下面的示例中，我們添加了更多的組件，包括身份驗證服務和資料庫，但該核心的合適路徑仍然是中心。
從合適的路徑開始可以提供清晰性，確保當你轉移到邊緣情況時，你知道時序應該如何運行，並且知道為什麼用戶可能會遇到邊緣情況。構建和退出合適路徑也是避免最終的圖過於複雜的最佳方法。
可理解性>全面性
時序圖最常見的失效模式是過於複雜。（這也是大多數圖表的失效模式，正如我在一篇關於流程圖的文章中所寫的那樣）。
這裡最值得提到的一個人是是 Martin Fowler，他（大約 20 年前）曾寫道，繪製圖表的主要價值在於溝通。「有效的溝通，」Fowler 寫道，「意味著選擇重要的事情而忽略不太重要的事情。」
忽略是最困難的部分。因為製圖的目的是為了交流，因此有必要去掉一些信息以澄清其他信息。Fowler 提醒我們，「代碼是全面信息的最佳來源」，因此圖在本質上不應該是全面的（這正是代碼的作用所在）。Fowler 說得很好，他寫道「全面性是可理解性的敵人。」
你可以在下面的時序圖中看到這一點，一位開發人員在 PR 中引用了該時序圖，要求團隊「考慮從圖中提取出不太重要的信息，以便閱讀的開發人員能夠專注於重要的想法。」
Thomas Beale 在他關於 UML 之死的文章中寫道，UML 變得過於複雜的主要原因是創建者試圖「定義一個單一的元模型」，該模型可以提供十幾種圖表類型所需的所有元素。Beale 認為，「事實上，每種類型的圖表都代表了一個特定的概念空間，它需要自己的特定模型。」
UML 本身已經消亡了，部分原因是它增加了複雜性，而不是提供了清晰性。今天記住這一點很有用，因為就像 UML 的消亡一樣，如果任何給定的時序圖變得過於複雜的話，它也會失敗。
大圖>細節
如果說前一個問題是過於全面和過於寬泛的結果，那麼下一個問題則是過於詳細和過於狹隘的結果。
在 Alex Bell 關於 UML 狂熱的文章中，他描述的眾多「毒株」之一是「Gnat’s eyebrow fever」，這是最有可能困擾時序圖的問題之一。他將這種狂熱描述為「非常強烈地想要創建極其詳細的 UML 圖」，並認為這種狂熱源於這樣一種信念，即繪製細粒度的細節圖「為生成的代碼增加了更加正確的可能性」
然而，實現是關鍵所在，因此，如果你正在構建一個時序圖，以便更好地告知設計需求，那麼在這個過程中，停止繪製圖並開始編碼才是更有效的。
也就是說，這個原則擴展到了用例之外。例如，如果你正在構建一個時序圖來傳達文檔中的流程，那麼對讀者來說，可視化的全局大圖比深入挖掘細節更有用。這並不是說細節不重要，而是太多的細節會削弱看全局時序的能力（這是時序圖的主要目標）。
同樣的原理也適用於分析和記錄遺留代碼——細節在於代碼本身，因此時序圖只有在你使用它來可視化全局時才有用。
採用時序圖來擁抱架構思維
本文的重點並不是純粹出於對歷史的好奇才來研究時序圖的。時序圖不僅是 UML 的產物，而且是強調嚴格設計和規劃的軟體設計思維的產物。
Fowler 解釋說，圖表和「重量級」流程之間的關聯是圖表繪製不好的結果，而不是圖表製作本身的結果。本文中的建議旨在幫助大家創建更好的時序圖，但在這個過程中，希望能幫助大家更好地了解在設計和文檔庫中擁有繪圖技能所帶來的可能性。
最好的工作來自於設計和編碼之間的循環——創建一個前期設計，基於設計進行編碼，並將從編碼工作中所學到的東西反饋到設計中。如果一個圖表能幫助你理解一個時序，那麼正如 Fowler 所寫道的那樣，把它扔掉是「完全合理的」。（然而，「扔掉它」並不一定意味著永遠地刪除它；如果你想仔細回顧以前的工作，把它放在一邊通常是有幫助的，這樣你之後就可以再召回它）。
Jacobson 在他關於 UML 之死的文章中強調，「重點是，每一次 sprint 都要以架構思維為先導。」特別是使用時序圖時，你可以更好地理解手頭上的流程，從而使構建或改進組件變得更加容易。
原文連結：
https://www.mermaidchart.com/blog/posts/sequence-diagrams-the-good-thing-uml-brought-to-software-development
Python吞噬世界，GPT吞噬Python！ChatGPT 上線最強應用：分析數據、生成代碼都精通
LLM對程式設計師的衝擊和影響
阿里轉崗先離職：清空司齡裁員不給錢？馬斯克作死推特，對手小扎社交平台喜獲3000萬用戶；美國或限制中國用戶使用美雲服務｜Q資訊