💡 主要重點
- 核心功能：活動圖可視化系統內的控制流與物件流，類似於流程圖，但具有UML語義。
- 並發性：它們獨特地支援使用分叉與合併節點來建模並行處理，以表示同時發生的動作。
- 泳道：將活動劃分到泳道中，可清楚地釐清責任與主權，無需額外使用序列圖。
- 整合：這些圖表透過詳細說明特定用例背後的內部邏輯，來補充用例圖。
理解活動圖的目的 🎯
活動圖是統一建模語言（UML）的基本組成部分。它們提供了系統行為的高階視圖，專注於動作的順序以及這些動作發生的條件。與描述結構的靜態圖不同，活動圖描述的是動態行為。在建模業務流程、複雜演算法或單一用例的內部邏輯時，它們尤其有用。
主要目標是清晰。一個構建良好的圖表，讓利害關係人能夠理解工作流程，而不會迷失在程式碼層級的細節中。它彌補了業務需求與技術實現之間的差距。透過視覺化地映射邏輯，團隊可以在撰寫任何程式碼之前，識別瓶頸、重複步驟或潛在錯誤。
核心元件與符號 🔍
要建立活動圖，必須理解標準符號。圖表由節點和邊組成。節點代表狀態或動作，而邊則代表節點之間的控制流或資料流。
初始節點與終止節點
每個活動圖都從一個初始節點開始，通常以實心黑圓圈表示。這標示了流程開始的入口點。相反地，流程在終止節點結束，顯示為內部帶有十字的圓圈（或雙環圓圈）。可以有多個終止節點，根據成功或失敗條件來代表不同的結束點。
活動狀態
活動以圓角矩形表示。這些代表需要時間完成的動作。它可以是原子的（單一步驟）或複合的（可進一步分解的子流程）。活動狀態內的標籤描述具體動作，例如「驗證使用者輸入」或「計算總額」。
控制流邊
控制流邊是帶箭頭的實線。它們表示活動執行的順序。除非受到決策節點或分叉節點的指引，否則流程會從一個節點移動到下一個節點。
管理邏輯與決策 🔄
現實世界的工作流程很少是線性的。它們涉及選擇、迴圈和複雜條件。活動圖透過特定節點來處理這些情況。
決策節點與合併節點
決策節點以菱形表示，允許流程分支。根據守衛條件，僅有一條輸出路徑被採用。例如，如果付款失敗，流程可能轉向「重試」路徑；如果成功，則轉向「確認訂單」。
合併節點也以菱形表示，將多個輸入路徑合併為單一輸出路徑。當不同邏輯分支重新匯聚到同一個流程步驟時，這非常有用。
守衛條件
守衛條件寫在決策節點離開的控制流邊旁的方括號中。它們定義了 traversing 該特定邊所需的條件。例如，[餘額 > 0] 確保在進行交易前資金可用。
使用分叉與合併的並發性 ⚡
活動圖最強大的功能之一是能夠模擬並發性。在許多系統中，多個動作會同時發生。順序建模在此失效；而活動圖則能成功應對。
分叉節點
分叉節點會將單一的輸入流程拆分成多個並行流程。它以一條粗的水平或垂直條形表示。當流程到達分叉點時，所有輸出路徑會同時啟動。這對於模擬同時發送電子郵件通知和更新資料庫日誌等流程至關重要。
合併節點
合併節點會等待所有輸入的並行流程完成後，才允許流程繼續。它同樣以粗條表示。這確保了同步性。例如，系統可能需要等待付款驗證和庫存檢查都完成後，才會生成發票。
使用泳道進行區分 🏊
當工作流程涉及多個參與者、部門或系統組件時，密集的線條網絡會導致清晰度下降。泳道解決了這個問題。它們將圖表劃分為不同的區域，每個區域代表特定的責任。
泳道的類型
- 參與者泳道： 按人類角色劃分活動，例如「客戶」、「管理員」或「支援人員」。
- 系統泳道： 按系統模組劃分活動，例如「前端」、「後端」或「資料庫」。
- 部門泳道： 按組織單位劃分活動，例如「銷售」和「財務」。
泳道內的活動由該實體負責。跨越泳道邊界的控制流邊線代表實體之間的互動。這種視覺上的區分能立即顯示出每個步驟的負責人。
物件流與資料傳輸 📦
雖然控制流管理邏輯，物件流則管理資料。物件以左上角帶有一個小矩形的矩形表示。物件流邊線連接一個產生物件的活動與一個消耗該物件的活動。
這種區別至關重要。控制流邊線表示第一個活動必須完成後，第二個活動才能開始。物件流邊線表示第一個活動產生了第二個活動所需的資料。一個活動可以有多个輸入和輸出物件，從而建立清晰的資料來源脈絡。
有效建模的最佳實務 🛠️
繪製圖表是一回事；繪製出有用的圖表是另一回事。遵循最佳實務可確保圖表保持清晰易讀且具有價值。
保持可讀性
不要試圖在單一圖表中模擬整個系統。將複雜流程拆分成子活動或獨立圖表。涵蓋整個系統生命週期的圖表通常過於複雜，難以理解。使用層次化建模，即高階圖表引用詳細的子流程。
命名一致
為所有節點和邊線使用清晰且一致的標籤。除非是標準的產業術語，否則避免使用縮寫。標籤為「Proc」的活動不如「Process Order」明確。一致性有助於利益相關者快速瀏覽圖表。
限制分支
過多的決策節點會造成迷宮般的結構。如果一個流程包含許多條件，可考慮將其分組，或使用表格獨立定義邏輯。圖表應突出主要流程與例外情況，而非每一個細微的邊際案例。
應避免的常見陷阱 ⚠️
即使經驗豐富的建模者也可能陷入會降低圖表價值的陷阱。
混用控制流與物件流
不要將控制流與物件流混淆。使用物件流來表示一連串動作是錯誤的。物件流僅用於資料移動。若用來表示控制流，會造成歧義，讓人無法判斷活動是正在等待資料，還是僅僅繼續進行。
過度劃分
雖然泳道很有用，但過多的泳道會使圖表混亂。若圖表中超過五或六個泳道，所需的水平空間會讓檢視變得困難。建議將圖表拆分成多個視圖。
忽略終止
確保圖表中的每條路徑都導向終結節點。死路會造成混淆，暗示邏輯不完整。若某條路徑代表錯誤，仍應終止，也許是導向特定的錯誤處理終結節點。
與其他 UML 圖表整合 🔗
活動圖並非孤立存在。它們與其他 UML 圖表整合，以提供系統的完整視圖。
用例圖
用例圖識別參與者與高階互動。活動圖則詳細說明特定用例的內部步驟。例如，「下訂單」用例可能對應一個活動圖，顯示從購物車驗證到付款處理的各個步驟。
順序圖
順序圖專注於物件之間隨時間的互動。活動圖則專注於演算法或工作流程。它們互為補充。使用順序圖來描述詳細的物件互動，而使用活動圖來呈現整體流程。
類圖
類圖定義靜態結構。活動圖定義動態行為。活動圖中流動的物件對應於類圖中定義的類別。這確保了系統結構與行為之間的一致性。
結論 🏁
活動圖是映射工作流程與邏輯的強大工具。它們能清楚地以視覺化方式呈現複雜流程，使技術與非技術相關人員都能理解。透過掌握核心元件、有效管理並發性，並遵循最佳實務，團隊可建立可靠的開發藍圖。投入建模的精力將帶來更少的歧義、較少的錯誤，以及對系統行為的共同理解。