標準 UML 有多標準？

（摘自馬丁·福勒的專欄，最初發表於 1999 年春季的《分散式運算》）

幾年前，我諮詢生涯中最令人厭煩的方面之一就是方法論之爭：關於使用哪種表示法的激烈爭論。這些爭吵總是引起很多爭執，而且幾乎每次都是毫無意義的——我們選擇哪一種都不重要。感謝 UML，這些爭論大多已經煙消雲散。我們現在有一個標準表示法。但正如人們發現的那樣，這個標準並不能解決所有問題。

現在出現的問題往往更為詳細：如何在 UML 模型中表示某個特定事物，或者某個 UML 結構對我們的實作環境意味著什麼。讓許多人感到驚訝的是，對於這些問題中的許多問題，並沒有明確的答案。

這是為什麼？很大一部分原因是傳統。建模方法，無論是 OO 還是其他，從來都不是非常正式的事務。定義留給直覺，而且有很多空白。具有形式化方法背景的人因此批評這些方法。他們認為，缺乏嚴謹性意味著模型中存在太多歧義。但現實情況是，許多人發現，儘管缺乏形式化，但非正式方法通常比正式方法更有用。在實務中，非正式性似乎是一種優勢。

UML 中有形式元素。這些元素的核心是元模型：一個描述 UML 結構的 UML 模型。但即使是元模型也留下了許多空白。它可以將屬性定義為類型為分類器的結構特徵的一種，但當我編寫程式時，這實際上是什麼意思？在 Java 中，它表示一個欄位、一對取得和設定作業，還是作業的參數？如果你詢問十位 UML 專家這個問題的答案，你唯一可能得到的共識是，答案中包含「視情況而定」這幾個字。元模型的主要目的是定義一個格式良好的模型，以便 CASE 工具有一天可以進行通訊。這距離真正嚴謹的方法還很遙遠。
 

處理多重詮釋

這對你來說是什麼意思？首先，這表示你會看到 UML 的許多詮釋。這些詮釋會出現在書籍、訓練課程和專案文件中。你需要知道這一點。與過去方法之間的差異相比，差異性已經減少許多，但還是會有差異。在一個團隊中，你必須對這些問題提出更標準的共識詮釋，因為它們會不斷出現。在你這麼做的時候，要小心那些對某個詮釋是對還是錯抱持極大肯定的人。有些事情相當明確，但許多事情並非如此。

你如何選擇詮釋？最重要的原則是了解你使用 UML 的目的。如果你使用 CASE 工具來產生程式碼，那麼要使用的詮釋必然是 CASE 工具的程式碼產生器的詮釋。如果不是，那麼最重要的目的就是溝通。因此，你想要選擇最能與其他人溝通的詮釋。這是標準中一個重要的重點，它鼓勵對我們的圖表進行共同詮釋。

在這裡，我認為詮釋的問題將與自然語言（例如英語）平行，而不是定義語言（例如 ANSI C）。不會有一個單一機構對 UML 詮釋做出宣告。如果這樣的機構存在，那就是 OMG：透過其分析和設計工作小組。它掌握 UML 標準的關鍵。但他們永遠不會對所有問題做出宣告。即使他們真的做出宣告，常見做法也可能與官方路線不同。這類似於法語學院的角色，它禁止使用「faire du shopping」等片語，但無法阻止它們進入日常用語。

因此，就像英語一樣，引導常見用法的其中一個重要部分將來自 UML 專家，這些人會對正確且有品味的 UML 提出評論。在這張圖片中，三個朋友將是特別重要的專家。他們的著作將具有很大的份量，但未必是絕對的。

除了詮釋的差異之外，我們還會發現完全不同的符號。許多人會察覺到 UML 中的重要差距，並提出一些新的延伸功能來解決問題。其中一些將透過 UML 延伸功能（例如立體型和類似功能）順利融入，其他將會完全偏離 OMG 文件。同樣地，這些功能的興衰將取決於其他人是否採用它們。

選擇詮釋

將 UML 視為自然語言的觀點也說明了它如何演變。自然語言是透過人們將語言推向各個方向而演變的。有用的語言會進入慣例，然後逐漸變得更標準，而沒有用的語言則會逐漸消失。我想我們會看到在未來幾年內，UML 的邊緣會受到相當大的推動。這是一件好事，因為它將使 UML 保持活力並允許它發展。這種邊緣推動發生在 UML 前期方法中，許多想法都進入了 UML。變異具有共同基礎的事實將使這個過程更容易，甚至可能加速 UML。因此，不要期望它保持靜態，並預期官方標準會落後最佳用法幾個步驟。
對 CASE 工具的影響

在這個標準世界中，CASE 工具具有特殊的角色，它們的決策將影響你使用 UML 的方式。基本上，CASE 工具必須選擇它們將如何玩 UML 遊戲。UML 對 CASE 產業最大的優點是它讓它們不必支援多種方法。現在，它們可以專注於使用 UML 做一些有用的事情。

為了支援 UML，它們必須支援 UML 元模型，但所有詮釋問題仍然適用。舉例來說，我們將看到使用程式碼產生器的不同決策。它們不僅會產生不同的程式碼，還會對它們產生的程式碼的意圖做出不同的決策。因此，你會發現一個 CASE 工具中的 UML 與另一個 CASE 工具中的 UML 意義不同。

CASE 工具談論它們檢查你的圖表的能力，以防止你犯錯。他們將其視為一項功能，但我不是很確定。我知道我要做什麼，當 CASE 工具不讓我做我需要做的事情時，我發現這非常令人惱火。人們將其視為經驗較少的開發人員的一項好處，但我認為良好的審查流程比機械檢查更有價值。工具錯失了溝通的微妙之處。因此，不要讓 CASE 工具成為你繪製內容的仲裁者。你的大腦每天都可以擊敗 CASE 工具。