第12章 UML 環境

12.1 概述
　　UML 模型被用在環境中使用。多數人使用建模技術爲了達到一個目的，即爲了開發性能優良的系統，而不是爲了使用模型本身。模型的目的和對模型的解釋也受環境之外的因素影響。在廣闊的外部環境中，另一些工具包括：跨越多種語言的元模型、模型編輯工具、程序設計語言、操作系統和主系統構件以及那些使用系統的商業和工程背景。確定模型的意義和使用目的取決於所有這些工具，其中也包括UML語言。
　　模型在不同的具體層次中出現。UML 是一種通用建模語言，包括語義和表示法，適用於不同的工具和實現語言。應用中的每個層次需要使用不同層次的UML建模思路。
12.2 語義職責
　　元模型是對模型的一種描述。建模語言描述模型，因此，它可以用元模型描述。元模型試圖通過定義語義使語言精確，但是爲適應新情況它必須允許擴展。元模型的實際形式對於用工具實現模型和模型的互換很重要，但多數用戶並不關心它。因此，我們在本書中未涉及到它。對此有興趣的讀者可以參閱配套光盤上的原始標準文獻[UML-98]。
　　元模型和語言必須能夠覆蓋多大的背景信息並具有很強的解釋力。現存系統有不同的執行和存儲模型，從中選擇一種作爲正確的解釋是不可能的。實際上，甚至考慮這樣的選擇都可能產生誤導。我們可以將執行模型的不同解釋作爲語義變更點。語義變更點是一個隨執行的具體語義而不同的點，但它與系統的其他方面無關。例如，一個環境可以選擇或不選擇支持動態類元，即對象具有在運行時改變所屬類的能力。現在，許多程序設計語言不允許這麼做，主要是因爲程序設計語言的實現方面的原因，但有些語言實現了這一功能。在靜態語義中這種區別是不能辨認的。選擇靜態分類還是動態分類可以用一個具有兩個選項（靜態分類或動態分類）的語義變更點來標明。當這些選擇存在時，人們經常辯論哪一種是正確的解釋。相反，如果明確了這僅僅只是一種選擇，並給選項起一個名字，這樣任何一種選擇都可以使用。
　　元模型描述一個結構良好的模型的內容，正如一種程序設計語言描述一個結構良好的程序一樣。只有結構良好的模型纔有意義和恰當的語義；詢問一個結構糟糕的模型的意義是沒有意義的。然而，多數開發中的模型的結構是不完善的。它們不完整並有可能相互矛盾。但是模型編輯工具必須支持不完整的模型，而不僅只支持完整的模型。UML元模型描述正確的、結構完善的模型。分離的元模型能描述可能的模型片段。我們讓工具開發者決定在哪裏劃定支持模型片段的界限和支持結構不完善的模型用哪種語義。
　　UML包含一些內置的擴展機制以適應特殊領域的應用。這些機制包括定義構造型和標記值的能力。通過定義一組構造型和標記值並採用相應的使用約定，這些機制可以用於裁製UML的變體。例如，可以開發出以不同程序設計語言的執行語義爲核心的UML變體語言。使用擴展機制會很有效，但也會帶來潛在的危險。因爲這些語義不是在UML中定義的，UML不支持它們的含義，這種解釋取決於建模者。此外，如果你不注意，某些含義可能是二義性的甚至是矛盾的。建模工具能夠自動支持由工具定義的構造型和標記值，但不支持用戶自定義的擴展。不論是否支持擴展，任何擴展的使用都會使用戶偏離語言標準所提供標準定義，並損害模型的互換性和易理解性。當然，使用特殊的類庫也會偏離所謂的最完美的互換性，所以不用擔心這些。當擴展有幫助時就使用，但當擴展不必要時則避免使用它。
12.3 表示法職責
　　表示法並不是給模型增加含義，而是幫助用戶理解模型的含義。表示法沒有語義，但它經常爲用戶加入一些內在涵義，如在一張圖中基於相近意義的兩個概念的密切聯繫。
　　UML文檔[UML-98]和本書定義了一套規範的UML 表示法，可以稱作模型的格式出版。這和許多程序設計語言類似，把期刊文章中的程序印刷成有吸引力的格式，包括仔細的規劃、用黑體保留字表示的，且每個過程用不同的圖形來說明。而實際的編譯者不得不接受較爲凌亂的輸入。我們期望編輯工具能把表示法擴展成屏幕格式，包括諸如使用不同的字體和顏色加亮條目，簡單地刪除和過濾不需要使用的條目的能力，放大圖像以展示圖中的嵌套元素的能力，通過超文本熱鏈轉入其他模型和視圖的能力，以及動畫功能。試圖將所有這些可能的項目都標準化是不可能的，也是愚蠢的，因爲沒有這個必要，而且這樣還會限制有益的創新。這種表示法的擴展能力是工具製造者的工作。在交互式工具中，產生二義性的危險不大，因爲用戶總能找到一個明確的解釋。這也許比堅持一種粗看上去沒有任何二義性的表示法更有用。這個觀點是說：當需要時，一個工具必須能生成規範化的表示法，特別是在印刷格式中，但在使用交互式工具中也應該採用合理的擴展。
　　我們仍期望工具能讓用戶有限制但又有效地擴展表示法。我們已經規定構型型可以有自己的圖標。對其他的表示法的擴展也是允許的，但用戶要謹慎使用這些擴展機制。
注意，表示法不僅僅是圖片，它還包括基於文本格式的信息和元素中間不可見的超鏈接。
12.4 程序語言職責
　　UML 必須在沒有與不同的實現語言明確地合併時與它們共同使用。我們認爲 UML應該允許任何程序設計語言（至少是多數）的使用，包括規格說明和目標代碼生成。問題是每種程序設計語言都存在許多我們不想吸收到UML中的語義，因爲它們作爲程序設計語言來說很好控制，而在執行語義中有相當大的變化。例如，併發的語義在不同的語言中存在不同的處理方法（如果能夠處理這些語義）。
　　UML中沒有詳細地描述簡單數據類型，這麼做是經過深思熟慮的，因爲我們不想把我們偏愛的一種程序設計語言的語義合併到其他所有語言中。對於多數的建模目的，這不是一個問題。應使用適合於你的目標語言的語義模型。這是語義變更點的一個例子。
　　詳盡的語言實現特性的表示使得在不把實現特性的語義內置到UML的情況下，帶來了捕獲其信息的問題。我們的方法是通過構造型和標記值捕獲超越了UML內置能力的語言特性，這些可以由工具或代碼生成器分配給語言給性和代碼生成選項。一般的編輯器不需要理解它們。事實上，用戶可以用一個不支持目標語言的工具創建一個模型，然後把最終模型轉換到適用於最終處理的工具。當然，如果工具不能理解構造型和標記值，那麼它不能對它們進行一致性檢查。但這並不比用文本編輯器和編譯器差。如果必要，可以創建一個工具來使用UML語言的一組特定的擴展。
　　在可預知的未來，代碼生成和逆向轉換不僅需要UML模型，還需要設計者的輸入信息。代碼生成器需要的指導和提示可以由標記值和構造型提供。例如，建模者可以指定哪種包容器類用於實現一個關聯。當然，這種工具中的代碼生成設置方法也許是矛盾的，但目前沒有一種標準化的實際設置方法。目前不同的工具均使用對自己有競爭優勢的代碼生成器，但最終將會出現缺省設置並發展爲成熟的標準。
12.5 使用建模工具建模
　　在實際的系統中模型需要工具支持，工具提供了觀察和編輯模型的交互方式。工具提供了一層超出UML自身作用域的組織，可以幫助用戶理解並獲得信息。通過搜索和過濾已經存在的資料，工具有助於在大型模型中查找信息。
12.5.1 工具問題
　　工具處理模型的物理組織和存儲。它必須支持一個項目的若干工作組同時工作，以及支持跨越多個項目的重用。以下幾點問題超出了規範的UML 的作用域，但在運用實際工具中必須予以考慮。
＊　二義性和未詳盡說明的信息 在初期階段，許多事物不能用語言表達。工具必須能夠調整模型的精確性並且不能強迫每個值都要進行詳細說明。可參看以下兩小節。
＊　表示選項 用戶不想在任何時候都看到所有的信息。工具必須能夠過濾和隱藏那些某一時間不需要的信息。工具還要通過顯示器硬件的功能提供交替的可視化支持。這一點已經在12.3節講過了。
＊　模型管理 模型單元的配置控制、訪問控制和版本超出了UML的作用域，但是它們對於軟件工程過程十分重要，並且位於元模型的上層。
＊　與其他工具的接口 模型需要由代碼生成器、規格計算機、報表書寫器、執行引擎和其他後臺工具處理。其他工具所需要的信息要包含到模型中，但這不是UML信息。標記值適合保存這些信息。
12.5.2 工作進展過程中產生的不一致模型
　　建模的最終目標是生成一定細化層次的系統描述。最後的模型必須滿足不同的有效性約束纔有意義。但是，正如許多創造性的過程一樣，結果不必以線性方式產生，中間產品不必每一步都滿足所有的有效性約束。實際上，一個工具不僅要處理語義上滿足有效性約束的模型，還要處理在句法上有效的模型，這些模型滿足一定的構造規則但可能會違背一些有效性約束。語義上無效的模型不能直接使用。相反，它們可以看作是通向最終目標的進展中的工作。
12.5.3 空值和未詳細說明的值
　　一個完整的模型包含了它的所有元素的所有屬性值。在許多情況下空值（無值）是一種可能出現的值，一個值是否可能爲空是屬性類型描述的一部分。例如，空值對集合大小的上 限沒有意義。有的集合有固定的大小，有的則沒有固定的上限值，在這種情況下，集合的大小是無限的，所以具有空值與否實際上取決於一種數據類型的可能值的範圍。
　　另一方面，在設計的早期，開發者也許沒有注意到特殊特性的值。在特定的階段，這個值可能沒有意義，如建立領域模型時的可視性。或者，這個值有含義但建模者還未詳細說明它，開發者應當記住它仍然需要細化。這種情況下，這個值是沒有詳盡說明的，這表示一個值最終是需要的但目前還沒有被詳細說明。它和空值不同，空值在最終模型裏是合法值。許多情況下，特別是字符串中，空值是表示一個未被詳盡說明的值的好方法，但並非全是這樣。未被詳細說明的值在結構完善的模型中是無意義的，UML定義不處理沒有詳細說明的值。這是支持UML的工具的