💡 主要重點
- 統一符號： 在所有圖示中使用一致的形狀和符號，以避免誤解。
- 命名慣例： 對元件採用嚴格的命名規則，以確保模型內的清晰度與可搜尋性。
- 佈局紀律： 保持均勻的間距與對齊，以增強視覺流暢度並降低認知負荷。
- 關係清晰度： 定義明確的線條與箭頭規則，以準確呈現系統連接。
在軟體架構與系統設計領域，圖示扮演著通用語言的角色。它們彌補了抽象概念與具體實作之間的差距。然而，缺乏內部一致性的圖示反而會造成混淆而非清晰。一致性不僅僅是美學上的偏好，更是專業建模的基本要求。當利益相關者、開發人員與架構師檢視模型時，他們依賴既定的模式來快速提取意義。偏離這些模式會帶來摩擦與潛在錯誤。
本指南概述了維持統一模型語言（UML）圖示一致性的基本規則。這些原則適用於任何用來製作視覺圖示的工具。目標是創造出直覺性、可維護且精確的文件。
1. 符號標準 🎨
任何專業圖示的基礎在於遵循建模社群所定義的標準符號。雖然不同工具之間存在微小差異，但類別、介面、參與者與狀態的核心符號始終保持一致。偏離這些符號會造成模糊不清。
類別圖符號
在建立類別圖時，必須嚴格遵守類別使用矩形形狀的規則。方框應分為三個明確的區段：類別名稱、屬性與操作。名稱應始終位於頂部區段，屬性與操作則列於下方，並以水平線分隔。
- 公開成員： 使用加號（+）作為前置符號。
- 私有成員： 使用減號（-）作為前置符號。
- 保護成員： 使用井號（#）作為前置符號。
- 套件範圍： 使用波浪號（~）作為前置符號。
在相同模型中不要混合使用這些慣例。若模型使用 + 符號表示公開屬性，則每個類別都必須遵循此規則。不一致的可見性修飾符會讓一眼判斷存取層級變得困難。
序列圖生命線
在序列圖中，物件與參與者的表示方式必須保持一致。生命線是從圖表頂端延伸的垂直虛線。激活欄應為放置在生命線上的窄矩形，出現在執行期間。確保所有激活欄的寬度相同，以維持視覺節奏。
狀態機圖
狀態應以圓角矩形表示。轉移使用帶有開口箭頭的實線。進入與離開點應以特定符號明確標示（例如，初始狀態使用實心圓，終止狀態使用雙圓）。對同一類型的狀態使用不同形狀會破壞視覺語言的一致性。
2. 命名慣例 🏷️
命名是模型中不一致性的最常見來源。若無嚴格規則，一位架構師可能會將類命名為User，而另一位則使用Person。有人可能會使用saveRecord()，而另一位則偏好persistData()這些差異迫使讀者不斷轉換術語，減緩了理解速度。
類與組件命名
類名應遵循 PascalCase 慣例。這表示每個單詞的首字母都要大寫（例如，CustomerOrder）。縮寫應視為單一單詞（例如，HTTPConnection，而不是HttpConnection）。這確保了類名能輕易與通常使用 camelCase 的變數名區分開來。
屬性和方法命名
屬性和方法應使用 camelCase。名稱的首字母小寫，後續單詞首字母大寫（例如，calculateTotal()）。這種區分有助於文字化地閱讀圖示。
| 元素類型 | 慣例 | 範例 |
|---|---|---|
| 類 | PascalCase | PaymentGateway |
| 屬性 | camelCase | 交易ID |
| 方法 | 駝峰式命名法 | processRefund() |
| 介面 | 以 I 為前綴 | IPaymentProcessor |
命名空間與套件結構
當將模型組織成套件或命名空間時，層次結構應反映系統的邏輯領域。避免超過三層的深度嵌套。套件名稱應使用小寫，以區分於類別。例如，com/company/project 是標準格式，而com.Company.Project 可能會造成混淆，無法判斷該文字是代表套件還是類別。
3. 排版與間距 📏
雜亂的圖表就是失敗的圖表。排版的一致性確保觀看者能有效率地掃描資訊。這包括對齊、間距與分組。
網格對齊
使用隱藏的網格來對齊元素。代表類別或組件的矩形應水平或垂直對齊。除非特別需要以顯示特定關係方向，否則不要將元素放置在任意角度。相關組件通常建議垂直堆疊。
間距規則
保持元素之間的間距一致。如果兩個類別之間的距離在某個區域為 50 像素，其他區域也應類似。這能創造出「視覺呼吸空間」，避免圖表顯得擁擠。一致的間距也有助於識別相關功能的群組。
分組與框架
使用框架來分組相關的圖表或組件。框架應涵蓋屬於特定子系統的所有元素。框架的邊框應為實線，標籤應置於左上角。確保框架不與其指定範圍外的元素重疊。
4. 關係線與箭頭 ➡️
元素之間的連接與元素本身一樣重要。錯誤地表示關係，可能導致對系統行為的錯誤假設。
關聯與聚合
清楚區分關聯與聚合。關聯是一條簡單的線。聚合（「擁有」關係，其中部分可獨立存在）在源端使用空心菱形。組合（「擁有」關係，其中部分無法脫離整體而存在）使用實心菱形。不要將空心與實心菱形互換使用於不同類型的關係。
依賴線
依賴關係應以虛線搭配開放箭頭表示。這表示一個元素依賴於另一個元素。避免使用實線表示依賴，因為這暗示了更強的結構連結。確保箭頭指向被依賴的元素。
多重性
多重性值（例如：1、0..1、*）應放置在靠近其所描述類別的線段末端。若顯示多個多重性，請確保格式一致。在需要時不可省略多重性，也不可在暗示時額外添加。
5. 顏色與層級 🎨
顏色應謹慎使用以傳達意義，而非用於裝飾。過度使用顏色會混淆層次結構。如果每個類別都使用不同的顏色，視覺上將無從聚焦。
標準色彩調色板
採用極簡的調色板。例如：
- 黑色或深灰色： 標準元素。
- 藍色： 接口或抽象類別。
- 綠色： 正在運行或活躍的流程。
- 紅色： 錯誤狀態或嚴重警告。
不要隨意套用顏色。如果一個類別是藍色，它在整個模型中都必須代表接口或抽象概念。如果一個狀態是紅色，它必須一致地表示錯誤狀態。
字型一致性
在整個模型中使用單一無襯線字型。常見選擇包括 Arial、Helvetica 或 Roboto。字型大小應清晰可讀且保持一致。類別名稱應使用粗體，而屬性和方法則使用正常字重。這種視覺區別可讓圖示內容快速掃描。
6. 文件對齊 📝
圖示的價值取決於其附帶的文件。視覺模型與文字描述之間的不一致，是技術債務的主要來源。
版本控制
確保圖示上的版本號與系統文件的版本一致。若程式碼變更，圖示必須同步更新。顯示已被移除功能的圖示具有誤導性。建立規則，將圖示更新納入程式碼審查流程。
上下文註解
使用註解來解釋無法以標準符號表示的複雜邏輯。這些註解應使用虛線連接到特定元素。確保註解文字簡潔。圖示框內的長段落會降低可讀性。若註解超過三行，建議建立獨立的規格文件並加以引用。
7. 審查與維護 🔄
一致性不是一次性的設定，而是一項持續進行的實務。隨著系統演進，定期審查是確保標準持續維持的必要措施。
自動化檢查
在可能的情況下，使用可驗證模型一致性的工具。自動化檢查可確認所有類別是否遵循命名慣例，或所有關係是否具有明確的多重性。這能減少維持品質所需的繁瑣手動工作。
同儕審查
將圖示審查納入開發工作流程。同儕應檢查是否遵守既定規則。這能促進團隊對模型的共同理解。若規則不清晰，應更新風格指南，而非允許例外。
結論 🏁
維持 UML 圖示的一致性需要紀律與明確的規則。透過統一符號、命名、佈局、關係與色彩，團隊可建立可作為可靠文件的模型。這些圖示成為團隊共享的資產，能加速開發並減少錯誤。投入一致性所付出的努力，將在降低溝通成本與提升系統設計品質上獲得回報。
從第一張草圖到最終交付，都應嚴格應用這些規則。專業的圖示，正是專業工程流程的見證。