UML參考手冊 第二部分 基 本 概 念 第12章 UML 環境

UML參考手冊

第二部分 基 本 概 念

第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的工具的職責,也是處於進展中的沒有語義的工作模型的一部分。