使用 Visual Paradigm 和 VPasCode 的 UML 實用指南

UML（統一建模語言）是一種標準化的方法，用於描述系統的結構與行為。它協助團隊討論需求、設計軟體並記錄決策。UML 是一種建模語言，而非程式設計語言：圖表用於傳達模型，但並不能自動確保實作與模型相符。

本指南以線上購物系統作為持續範例。它涵蓋主要的 UML 圖表類型，以及使用「Visual Paradigm進行視覺建模，以及使用「VPasCode進行文字式圖表繪製。」

1. 從您的圖表應回答的問題開始

在繪圖之前，先決定讀者需要理解什麼：

• 使用者能做什麼？使用使用案例圖。

• 在特定情境中會發生什麼事？使用序列圖或活動圖。

• 哪些概念與關係構成了領域？使用類別圖。

• 軟體如何被劃分為可部署或可替換的組件？使用組件圖與部署圖。

• 單一物件如何隨時間變化？使用狀態機圖。

試圖一次回答所有問題的圖表通常會變得難以閱讀。寧可選擇多個專注的圖表，而非一個擁擠的總覽圖。

2. UML 圖表家族

UML 2.x 包含 14 種標準圖表類型，通常分為結構圖與行為圖。互動圖是行為圖的子集。

您很少需要為專案使用全部 14 種圖表。對於許多應用程式設計而言，使用案例、類別、序列、活動、元件與部署圖表已構成強而有力的起始組合。

3. 最實用的圖表，並附上電子商務範例

使用案例圖：目標與系統邊界

使用案例圖描述使用者目標，而非螢幕配置或內部程式碼。對於線上商店，參與者可能包含顧客, 付款服務提供者，以及倉儲服務。使用案例可能包含瀏覽商品, 下訂單, 支付訂單款項，以及追蹤貨運.

使用<<include>>當一個使用案例總是呼叫另一個必要行為時。使用<<extend>>用於可選或條件式行為，以擴充基礎使用案例。請保持系統邊界清晰，讓讀者能區分系統與外部參與者。

活動圖：工作流程與決策

活動圖適用於具有分支或並行工作的流程。結帳流程可能如下：

1. 驗證購物車與地址。

2. 計算運費與稅金。

3. 建立待處理訂單。

4. 請求付款授權。

5. 若付款成功，確認訂單並通知履約單位。

6. 若付款失敗，顯示失敗訊息並保持訂單未確認狀態。

使用決策節點與合併節點處理分支，使用分叉節點與匯集節點處理並行工作，並在顧客、商店與外部提供者之間責任轉移時使用泳道。

序列圖：單一情境隨時間的演變

序列圖顯示參與者及其交換的訊息。它們特別有助於釐清服務邊界、呼叫順序與錯誤情境。請為付款遭拒或庫存不可用等結果添加替代路徑。

@startuml
actor Customer
participant "Storefront" as UI
participant "Order Service" as Orders
participant "Inventory Service" as Inventory
participant "Payment Provider" as Payment

Customer -> UI: submit checkout
UI -> Orders: placeOrder(cart, address)
Orders -> Inventory: reserve(items)

alt items available
    Inventory --> Orders: reservation confirmed
    Orders -> Payment: authorize(total)
    alt payment approved
        Payment --> Orders: approved
        Orders --> UI: order confirmed
        UI --> Customer: show confirmation
    else payment declined
        Payment --> Orders: declined
        Orders -> Inventory: release reservation
        Orders --> UI: payment failed
        UI --> Customer: show payment error
    end
else items unavailable
    Inventory --> Orders: reservation failed
    Orders --> UI: item unavailable
        UI --> Customer: show availability error
end
@enduml

此範例使用 PlantUML 語法。它僅為行為草圖，並非針對每個超時、重試或安全規則的完整規範。當這些細節對設計至關重要時，再將其加入。

類別圖：領域結構

類別圖描述類型及其關係。一個小型訂單模型可能包含：

• 顧客

• 訂單

• 訂單明細

• 商品

• 付款

當有助於說明職責時，請顯示屬性與操作。使用多重性使數量規則明確化：例如，一個訂單包含一個或多個訂單明細物件，而每個訂單明細指向一個產品.

常見關係類型：

• 關聯：一種一般的結構連結。

• 繼承/泛化：一個類別是另一個類別的專門化類型。

• 聚合：一種整體與部分之間的關係，其中部分可以獨立存在；應謹慎使用。

• 組合：一種強烈的整體與部分關係，其中部分的生命週期與整體綁定。

• 依賴：一個元素使用或依賴另一個元素。

對於商業模型，一個訂單行通常被建模為屬於一個訂單，而一個產品獨立於任何特定訂單而存在。請選擇能反映領域實際生命週期與規則的關係。

狀態機圖：生命週期規則

當物件的允許轉換至關重要時，請使用狀態機。訂單可能經歷以下狀態：

待處理 → 等待付款 → 已確認 → 已履行

它也可能轉換為已取消或付款失敗。請以觸發事件或保護條件標註轉換，例如付款已核准或[庫存可用]. 此圖可揭示無效的轉換——例如，已履行的訂單是否可以被取消。

元件圖與部署圖：軟體與執行階段

一個 元件圖顯示軟體的職責與相依性，例如商店前端、訂單服務、庫存服務與支付配接器。它有助於討論模組化與整合邊界。

一個 部署圖顯示軟體的執行位置：例如瀏覽器、應用程式執行階段、資料庫與外部支付提供者。用它來討論執行階段拓撲，而非詳細的網路組態。

4. 良好建模：實用慣例

• 為每個圖表提供清晰的標題與單一目的。

• 一致使用領域語言；避免為同一概念發明不同的名稱。

• 保持圖表大小適中，以便在預設尺寸下可讀。

• 僅包含能回答圖表問題的細節。

• 標註重要的關聯與訊息流程。

• 當數量規則重要時，為關聯添加多重性。

• 使用註解來記錄假設、限制與未決決策。

• 確保名稱與職責在圖表間保持一致。

• 區分已確認的內容與提案中或尚未明確的內容。

• 當重要設計決策或行為發生變更時，更新圖表。

將 UML 視為溝通輔助工具。若圖表的標籤、假設或範圍不清晰，即使語法正確，仍可能產生誤導。

5. 使用 Visual Paradigm

Visual Paradigm 適合圖形建模：在畫布上建立與排列 UML 元素、組織相關圖表，並透過視覺編輯精煉模型。其產品文件將 UML 建模列為其視覺建模能力之一。

一個實用工作流程：

1. 建立專案針對您正在建模的系統或邊界範圍。

2. 從需求與範圍開始。識別使用者、外部系統與關鍵目標。

3. 建立使用案例圖以確立邊界與主要互動。

4. 新增行為圖針對風險或模糊性最高的情境。

5. 建立類別模型以領域概念及其規則為核心。

6. 新增元件與部署視圖若架構或執行時配置需要討論。

7. 與利害關係人進行審查。檢查名稱、範圍、替代流程與基數。

8. 匯出或分享圖表採用適合審查與文件記錄的格式。

9. 維持模型的更新與維護。指定負責人，並在決策變更時更新圖表。

精確的選單名稱與可用功能可能因 Visual Paradigm 的版本與發行版而有所不同，因此請使用該產品當前的介面文件以取得針對特定版本的步驟。

6. 使用 VPasCode

VPasCode 是 Visual Paradigm 提供的瀏覽器型圖表即程式碼編輯器。其產品資訊說明支援基於文字的圖表格式（包括 PlantUML 與 Mermaid），並提供即時預覽；同時亦說明可匯出 SVG 與 PNG 等格式。

簡易工作流程：

1. 開啟 VPasCode 並選擇圖表語言，例如 PlantUML。

2. 撰寫或貼上圖表腳本。

3. 編輯時檢查渲染預覽。

4. 精進名稱、關聯、配置與錯誤路徑。

5. 匯出影像以用於文件或審查。

6. 若希望保留可審查與版本控制的基於文字的記錄，請將原始腳本與專案一併保存。

VPasCode 非常適合快速草稿、文件圖表，以及偏好基於文字編輯的團隊。Visual Paradigm 的圖形化模型則適用於需要以視覺方式操作模型元素，並將圖表組織為更大規模建模專案一部分的情境。這兩種方法可互補，但請勿假設每個圖表或模型都能在兩者之間以完美的雙向保真度轉換；請在您的工作流程中驗證任何轉換。

7. 實用的端到端工作流程

針對結帳功能，輕量級的建模序列可能如下：

1. 使用案例：定義誰可以下單，以及哪些外部系統參與。

2. 活動：繪製結帳流程及其決策點。

3. 序列：詳細說明成功、付款失敗及庫存不足路徑的互動。

4. 類別：定義訂單、明細項目、產品與付款概念及其規則。

5. 狀態機：規範有效的訂單生命週期。

6. 元件：顯示哪些服務負責這些職責。

7. 部署：若基礎設施決策相關，則記錄執行時期的部署位置。

當團隊受益於基於畫布的建模與受控的視覺模型時，請使用 Visual Paradigm；當團隊希望快速撰寫並呈現圖表文字時，請使用 VPasCode。常見做法是先在 VPasCode 中草擬情境，與團隊共同審查並精修，然後以最能配合專案文件與變更流程的格式維護圖表。

8. 常見陷阱

• 試圖一次繪製整個系統的圖表：應按關注點或情境進行拆分。

• 混淆活動圖與序列圖：活動圖強調工作流程；序列圖強調隨時間變化的訊息傳遞。

• 過度填充類別圖：應聚焦於相關的領域概念，而非每個實作細節。

• 使用「包含」與「延伸」作為裝飾：它們用於表達用例之間特定的關係。

• 遺漏替代路徑：失敗與取消情境往往能揭示重要需求。

• 將圖表視為規格書：應明確記錄重要的業務規則、假設與限制。

• 任由圖表過時：過時的圖表可能比沒有圖表更糟，因為讀者可能會信任它。

強大的 UML 圖集並非圖表數量最多的集合，而是能讓預期讀者理解系統、討論決策，並在問題變得昂貴前發現缺漏的最小圖表集合。