活動圖作為可視化系統動態特性的核心。雖然流程圖和狀態機能提供行為上的洞察，但活動圖專注於控制流與資料流。在這一流程的核心是決策節點。理解控制如何在系統中分支，對於準確建模至關重要。本指南探討決策節點的運作機制、分支語法以及守衛條件的細節。
🔍 什麼是決策節點？
決策節點代表活動中控制流分叉的點。它以實心菱形符號視覺化呈現。此符號表示流程必須根據特定條件，從多個可用選項中選擇單一路徑。與合併節點（合併流）不同，決策節點會將流分叉。
每個決策節點至少需要一個流入流和兩個或以上的流出流。選擇哪個流出路徑，取決於評估附著於流出邊上的守衛條件。若未指定條件，則假設為無條件流動，但在複雜建模中這種情況很少見。
- 輸入流： 進入菱形的單一箭頭。
- 輸出流： 從菱形離開的多個箭頭。
- 選擇機制： 邏輯評估條件以選擇一條路徑。
- 並發性： 單一決策節點不會產生平行流；它僅選擇一條路徑。
區分控制流與物件流至關重要。決策節點作用於控制流。它決定活動是否繼續，或下一個應執行的活動是哪一個。它不會直接操作資料物件，儘管資料可能影響決策邏輯。
🛡️ 理解守衛條件
守衛條件是決定選擇哪條路徑的邏輯表達式。它們出現在決策節點的流出邊上。這些條件必須以清晰且無歧義的方式書寫，以便任何審閱圖表的人都能理解。
守衛條件通常以方括號包圍。例如，[status == 'approved'] 表示只有當狀態為核准時，流程才會繼續。若條件評估為假，則不會選擇該路徑。系統會尋找第一個評估為真的條件。
守衛條件的關鍵特徵
- 布林邏輯： 條件通常會產生真或假的結果。
- 排他性： 在標準的決策節點中，每次執行僅選擇一條路徑。
- 完整性： 理想情況下，條件應涵蓋所有可能的場景，以避免死鎖。
- 可讀性： 避免過於複雜的布林邏輯，以免掩蓋意圖。
在建模複雜系統時，守衛條件經常引用物件屬性或系統變數。例如，倉儲流程可能檢查[inventory_level > 10] 確定是否可以發貨。
守衛條件的範例
| 條件語法 | 含義 | 範例情境 |
|---|---|---|
[金額 > 1000] |
金額超過門檻 | 大額交易的核准 |
[使用者角色 == '管理員'] |
使用者具有特定角色 | 存取控制權限 |
[狀態 == '待處理'] |
項目正在等待 | 工作流程路由 |
[!is_null] |
值不為空 | 表單驗證 |
🧭 分支的語法
分支指的是從決策點產生的路徑的結構性排列。標準的UML符號使用決策節點來表示互斥分支。這表示一次只有一條路徑處於活躍狀態。
繪製這些圖表時，必須注意流程的標籤。每條外出的邊都應標有表示條件的標籤。如果條件為假，標籤將被有效跳過。
互斥分支與包含分支
標準的決策節點暗示互斥分支。然而，在某些建模情境中，多個條件可能同時為真。在UML中，這會透過後續的合併節點處理，但決策本身仍為互斥，除非另有指定。要模擬多條路徑同時激活的包含分支，通常會使用分叉節點後接決策節點，或僅確保邏輯能處理並行執行。
為了標準活動圖的目的，除非明確使用分叉節點，否則我們假設為互斥分支。此區別對於維持準確的效能與並行模型至關重要。
- 互斥分支： 僅有一條路徑。
if-else結構。 - 平行流程： 多條路徑同時進行。
分叉結構。 - 組合： 使用決策節點進行路由，然後使用分叉節點進行並行處理。
🔄 決策節點 vs. 合併節點
這兩個節點經常成對使用。決策節點會分割流程，而合併節點則會將其合併。兩者之間的混淆可能導致嚴重的建模錯誤。
- 決策節點（菱形）： 將一個流程拆分成多個。邏輯決定了路徑。
- 合併節點（菱形）： 將多個流程合併為一個。這裡不應用任何邏輯。
合併節點不會評估條件。它僅僅等待任何傳入的流程到達，然後將控制權向前傳遞。邏輯完全位於決策點。
| 功能 | 決策節點 | 合併節點 |
|---|---|---|
| 形狀 | 黑色菱形 | 白色菱形 |
| 輸入流程 | 1（或在複雜情況下更多） | 1個或更多 |
| 輸出流程 | 2個或更多 | 1 |
| 功能 | 根據條件進行路由 | 合併路徑 |
| 邏輯 | 是 | 否 |
📋 常見模式與範例
應用這些概念需要實際範例。以下是決策節點在建模中至關重要的常見情境。
1. 使用者驗證流程
考慮登入流程。輸入憑證後，系統必須進行驗證。判斷節點會檢查使用者名稱和密碼的有效性。
- 輸入： 使用者提交登入表單。
- 判斷：憑證是否有效？
- 路徑 A（正確）：重定向至儀表板。
- 路徑 B（錯誤）：顯示錯誤訊息。
此簡單分支確保使用者在未經正確驗證前無法存取受保護區域。
2. 訂單處理系統
在電子商務情境中，訂單的規模與庫存狀態各不相同。判斷節點會評估訂單細節。
- 判斷：庫存是否可用？
- 分支 1： 是 → 處理付款。
- 分支 2： 否 → 通知客戶。
此外，第二個判斷節點可能檢查付款狀態。若付款失敗，訂單將被取消；若成功，訂單將出貨。此種判斷節點的嵌套結構，能清楚地呈現複雜的商業規則。
3. 異常處理
穩健的系統必須能處理錯誤。判斷節點可在繼續執行前檢查空值或未預期的狀態。
- 檢查：資料是否有效？
- 正確：繼續進行處理。
- 錯誤：記錄錯誤並終止或重試。
在異常路徑中使用判斷節點，可防止系統在遇到未預期資料時當機。
🧠 處理複雜邏輯
隨著系統的擴大，決策節點可能會變得擁擠。當一個節點有太多向外的連接時，可讀性會下降。在這種情況下，建議將邏輯拆分為子活動或嵌套圖表。
複雜分支的策略
- 子活動： 將複雜的決策樹封裝在單一活動框內。
- 層次圖表： 建立高階概覽，並在獨立的圖表中深入探討詳細邏輯。
- 狀態表格： 對於極其複雜的邏輯，狀態表格可能作為圖表的補充，但圖表仍是主要的視覺工具。
將單一決策節點過度複雜化可能導致維護問題。如果菱形有十條向外的路徑，未來的開發人員可能會難以追蹤邏輯。保持分支係數低可提升可維護性。
嵌套決策節點
有時，必須根據先前決策的結果做出決策。這稱為嵌套。
- 步驟 1： 檢查使用者是否已登入。
- 步驟 2： 如果是，檢查使用者是否為管理員。
這種順序檢查確保第二個條件僅在第一個條件為真時才會被評估。這透過避免不必要的檢查來優化流程。
⚠️ 應避免的常見陷阱
即使經驗豐富的建模者也可能犯錯。了解常見錯誤有助於維持圖表的完整性。
1. 遺漏路徑
如果一個決策節點有兩條向外的路徑，但只有一條標記了條件，則另一條被假設為預設（假）。然而，如果條件不完整，流程可能會中止。每種可能的結果都應有明確的路徑。
2. 無限循環
決策節點可能產生循環。如果條件總是評估為真，流程可能會無限循環。確保循環條件有退出路徑。
3. 模糊的標籤
標籤如[OK] 或 [Yes] 太過模糊。應使用具體條件，例如[status == active]。模糊性會導致對系統行為的誤解。
4. 控制流與物件流的混合
不要使用判斷節點來分割物件流。物件流代表資料移動，控制流代表邏輯。將二者混合會混淆圖表語義。
5. 死結
當兩個或更多活動互相等待時，就會發生死結。確保判斷節點不會產生會阻止進展的循環依賴。
✨ 清晰度的最佳實務
清晰的圖表能有效傳達訊息。遵循這些指南，以確保你的活動圖表專業且易於理解。
- 命名一致性：為條件使用標準術語，避免使用口語化表達。
- 視覺層次：安排節點以減少線路交叉。清晰的佈局有助於理解。
- 泳道：使用泳道來標示哪個參與者或組件負責該決策。這能明確邏輯的所有權。
- 文件記錄：為複雜的守護條件添加註解。說明條件中所使用資料的來源。
- 審查：請同儕審查圖表。新鮮的視角能發現創作者可能忽略的邏輯漏洞。
📊 進階情境
進階建模通常涉及將判斷節點與其他 UML 元素整合。
與物件節點的互動
物件節點代表資料。判斷節點可能會檢視一個物件節點以決定路徑。例如，一個節點檢查 orderStatus物件屬性。這使邏輯直接與資料狀態連結。
與物件流的互動
雖然判斷節點控制流程，但通常會作用於物件流。資料在系統中移動，而判斷節點則將資料導向不同的處理步驟。
並行處理的考量
當與判斷節點一起使用分叉（fork）和合併（join）節點時，需謹慎處理同步問題。分叉會產生平行執行緒，而判斷節點只選擇一條路徑。將二者結合時，必須確保控制流符合物件流的預期。
🛠️ 實作考量
將圖表轉譯為程式碼時，判斷節點會轉換為條件陳述式。圖表中的菱形會轉譯為一個 if或 切換軟體中的敘述。
- 保護條件： 變成程式碼中的布林表示式。
- 路徑： 變成程式碼結構中的分支。
- 合併節點： 代表執行過程中分支重新結合的點。
確保程式碼與圖表一致至關重要。設計與實作之間的差異會導致技術負債。定期對程式碼與活動圖進行審核，有助於保持一致。
📝 關鍵概念摘要
活動圖提供了一種強大的方式來建模工作流程。決策節點是引入邏輯與分支的機制。保護條件定義了這些分支的規則。正確使用決策節點與合併節點，可確保模型準確反映系統行為。
透過遵循最佳實務並避免常見陷阱，您可以建立技術上準確且易於理解的圖表。這些圖表可作為開發、溝通與維護的藍圖。
- 決策節點： 根據邏輯分割流程。
- 合併節點： 在無邏輯的情況下合併流程。
- 保護條件： 決定路徑的規則。
- 流程： 控制與資料的移動。
掌握控制流程的表示法對任何系統架構師或分析師都至關重要。這些圖表彌補了抽象需求與具體實作之間的差距。