一個 UML 類別圖描述 結構：它所建模的事物、這些事物的屬性以及它們之間的關係。對於資料建模而言，它可以在您決定使用資料表或應用程式程式碼之前，捕捉領域概念與限制。
PlantUML使圖表可重複產生：您撰寫文字、將其渲染、在版本控制中檢視變更，並隨著模型的演進進行更新。它補充而非取代資料庫結構、遷移腳本與詳細的業務規則。
1. 選擇建模層級
一個實用的資料建模圖表通常一次專注於一個層級：
-
概念層：業務概念與關係，技術細節極少。範例：
客戶下訂訂單. -
邏輯層：屬性、識別子、多重性與規則，且不將模型綁定至特定資料庫。
-
實體層：實作細節，例如 SQL 欄位類型、索引與資料庫特定限制。
下方的範例是一個 邏輯領域模型。像 UUID, Money，以及 DateTime僅供說明；在選擇技術時，請決定其具體表示方式。
2. PlantUML 基礎
類別具有名稱，並可列出屬性與操作：
@startuml
class Customer {
-id: UUID
+name: String
+email: String
+changeEmail(newEmail: String): void
}
@enduml
可見性標記是可選的建模提示：
-
+public -
-private -
#protected -
~套件可見性
對於領域圖或資料圖，屬性最為重要。僅在操作能釐清重要行為時才納入；避免將圖表轉為完整的程式碼清單。
3. 關聯性與多重性
資料建模中最實用的關聯性表示法如下：
| 關聯性 | PlantUML | 意義 |
|---|---|---|
| 關聯 | A -- B |
A 與 B 之間存在關聯 |
| 有向關聯 | A --> B |
可導航或有方向的關聯 |
| 聚合 | A o-- B |
A 擁有一個部分，但該部分可以獨立存在 |
| 組合 | A *-- B |
A 擁有一個其生命週期依賴於它的部分 |
| 泛化 | `Child — | > Parent` |
| 介面實現 | `Class .. | > Interface` |
多重性標籤位於關聯端附近：
-
1— 恰好一個 -
0..1— 可選，最多一個 -
*或0..*— 零個或多個 -
1..*— 一個或多個 -
2..5— 有界範圍
例如：
仔細閱讀兩端的標籤：一位客戶可以下達零筆或多筆訂單；每筆訂單僅與一位客戶關聯。這些標籤描述的是關係，而不一定是特定資料庫的外鍵實作方式。
4. 實作範例：線上商店
此模型包含客戶、訂單、明細項目、商品與付款記錄。它展示了識別子、值類型、列舉型別、組合關係與多重性。
@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false
hide methods
class Customer {
+customerId: UUID
+email: EmailAddress
+displayName: String
}
class Order {
+orderId: UUID
+placedAt: DateTime
+status: OrderStatus
+total: Money
}
class OrderLine {
+lineNumber: Integer
+quantity: PositiveInteger
+unitPrice: Money
}
class Product {
+productId: UUID
+sku: SKU
+name: String
+currentPrice: Money
}
class Payment {
+paymentId: UUID
+amount: Money
+status: PaymentStatus
+paidAt: DateTime [0..1]
}
class Money <<value object>> {
+amount: Decimal
+currency: CurrencyCode
}
enum OrderStatus {
DRAFT
PLACED
PAID
FULFILLED
CANCELLED
}
enum PaymentStatus {
PENDING
AUTHORIZED
CAPTURED
FAILED
REFUNDED
}
Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount
note right of OrderLine
quantity must be greater than zero
unitPrice is the price captured
when the order is placed
end note
note right of Product
Product.currentPrice may change.
It does not replace OrderLine.unitPrice.
end note
@enduml
為何要建模OrderLine明確地？訂單與商品之間的關係擁有自己的資料——數量與購買時的價格。這使其成為一個領域概念，而不僅僅是一條單純的連結。
為何從Order到OrderLine?此範例假設訂單明細屬於單一訂單，且本身不具獨立意義。僅當您的領域中確實存在此種所有權與生命週期規則時，才使用組合關係；UML 記號本身並不會在資料庫中強制執行此規則。
為何要區分當前價格與歷史價格？商品的價格可能在訂單下達後發生變動。在訂單明細中保留購買時的價格，即可保留歷史金額。
5. 重要的建模決策
識別子：一致地標記識別子，例如customerId或orderId. UML 並未定義單一通用的主鍵表示法，因此請選擇一種規範並加以記錄。可以使用標記或註解使其明確：
class Customer {
+customerId: UUID <<PK>>
+email: EmailAddress
}
可選值： 使用 [0..1] 表示可選屬性，前提是這對讀者而言已很清楚，或註明該規則。例如，付款可能暫無 paidAt 時間戳記，直到付款成功為止。
值物件： 某類型，例如 Money 或 EmailAddress 可代表具有自身驗證或語義的概念。請根據受眾與詳細程度，決定其應呈現為獨立類別、屬性類型或資料庫結構。
列舉值與受控值： 當允許的集合較小且相對穩定時，請使用列舉值。若值需要獨立的描述、生命週期或管理，則應將其建模為類別。
正規化與實作： 類別圖用於傳達概念與規則；它並未解決所有關聯細節。例如，Money 應實作為兩欄、獨立資料表或資料庫特定類型，屬於實作決策。
保持圖表可讀性： 將大型領域拆分為專注的圖表，例如訂單、庫存與身分識別，並使用套件來歸類相關類別。僅顯示與該圖表旨在回答的問題相關的屬性。
6. 根據需求建立模型
-
擷取候選概念從領域語言中：名詞通常暗示類別；動詞通常暗示關係或行為。
-
釐清規則搭配具體問題：訂單能否在沒有客戶的情況下存在？能否包含零行？付款能否重試？
-
選擇建模層級並將技術性資料庫決策排除在概念圖之外。
-
新增屬性與識別符僅在有助於解釋模型時才加入。
-
設定多重性從業務規則中推導，並檢查每個關係的兩端。
-
檢視邊界案例：刪除、歷史記錄、可選欄位、重複嘗試以及值變更。
-
渲染並檢視與領域專家及實作人員共同檢視圖表。將其視為待驗證的模型，而非僅供批准的圖片。
7. 使用 VPasCode 與 Visual Paradigm
VPasCode是一款基於瀏覽器的文字轉圖表編輯器，支援 PlantUML並提供即時預覽。其功能描述亦列出圖表程式碼的 AI 產生與修改，以及語法輔助。一個實用的工作流程如下：
-
開啟 VPasCode 並選擇或輸入 PlantUML。
-
貼上上述範例並檢視渲染後的圖表。
-
對 PlantUML 原始碼進行迭代；保留文字作為可版本化的產出物。
-
若工作區中可用，請使用 AI 助理來撰寫或修訂第一版草稿。
-
親自驗證每個產生的類別、關係、多重性與業務規則。
Visual Paradigm 的 AI 輔助圖表工具可根據自然語言描述產生可編輯的圖表。其公開的工作流程描述如何從提示產生類別圖，再細化其元素與關係。將 AI 產出視為草稿：它可能推斷出錯誤的擁有權、遺漏的約束或不合理的類別。模型的正確性仍取決於將其與需求進行驗證。
例如，向 AI 助理提出以下提示：
為線上商店建立邏輯 UML 類別圖。客戶下訂單。每個訂單包含一或多個訂單行。每個訂單行指向一個產品，並儲存數量與購買時的單價。訂單可有多次付款嘗試。包含識別符、多重性，以及訂單狀態與付款狀態的列舉。僅輸出 PlantUML。
然後在接受前將產出與需求進行比對。為獲得更佳結果，請明確指定假設——例如，訂單是否可以為無行的草稿，以及付款是否可以退還。
Visual Paradigm 描述VPasCode作為一個 支援 PlantUML 的編輯器具備即時渲染與 AI 輔助生成或修改。工具與可用性可能因產品版本或工作區而有所不同。
8. 簡潔的審查清單
在分享或實作類別圖之前，請檢查：
-
每個類別是否代表有意義的領域概念？
-
識別符號與重要屬性是否清晰？
-
關聯標籤與多重性在 兩端是否正確？
-
組合是否反映真實的生命週期依賴關係？
-
在當前值可能變更的地方，是否保留了歷史事實？
-
可選值與業務約束是否可見？
-
該圖表是否針對其受眾足夠聚焦？
-
已生成的內容是否已與實際需求進行比對檢查？
最佳的圖表即程式碼工作流程是 使用 AI 生成初始草稿，使用 PlantUML 進行精確編輯與版本記錄，並由人類審查以確保領域正確性.