统一建模语言(UML) 版本 2.0
原文：?http://www.ibm.com/developerworks/cn/rational/321_uml/
簡介
參考 UML 基礎系列的其他文章和教程
- UML基礎: 統一建模語言簡介
- UML 基礎: 類圖
- UML 基礎: 序列圖
- UML 基礎: 組件圖
- 繪制整潔的 UML 圖
- 用例建模技巧
- UML 序列圖簡介
- 養成良好的繪制 UML 序列圖的習慣
- 利用 UML 進行實體關系建模
?
| 訂閱 UML 相關文章和教程的 RSS 提要 | |||
?
可以看到1990年的早期版本已經對對象模式和相關技術有著濃厚的興趣。基于這個模式的新的編程語言（比如Smalltalk, Eiffel, C++, 和Java）已經被設計并投入使用。伴隨著這些語言出現的還有令人驚嘆和難以理解的面向對象（object-oriented（OO））軟件設計方法和建模符號。因而在徹底的縱覽了有關OO分析和設計方法后（包含800頁以上），Graham列舉了50種以上的有相當大影響力的方法（Graham01）。考慮到對象模式包含了基本概念的相對較小的子集（包括封裝、繼承和多態），很明顯，在這些方法中存在非常多的重疊和概念上的結合--大多數情況下是由于符號性的和其他并不重要的差異而使其變得很模糊不好理解。這樣就導致了令人難以理解以及不必要的市場分歧—反過來也阻礙了有實用價值的新模式的采用。軟件開發者很難在這些相互矛盾的語言，工具，方法和供應商中做出選擇。
由于這個原因，當Rational 軟件隨后提出了統一建模語言（UML）的初始版時--在Grady Booch，Ivar Jacobson和Jim Rumbaugh的領導下--得到了快速和積極的反響。其目的并不是為了提出任何新的內容，而是—--通過高級領域思想領導者們的協作—--把各種各樣的OO方法的最好特性添加到一個單獨的和與供應商無關的模型化語言和注釋中。正因為如此，UML很快地成為了一個廣泛的實踐標準。隨著1996年對象管理組織（Object Management Group）對它的采用，UML成為了一個廣泛被接受的工業標準[OMG03a] [OMG04] [RJB05]。
從那以后，UML:
- 被絕大多數的模型工具開發商所采用和支持
- 成為全世界大學和各種各樣的專業培訓項目中計算機科學和工程課程中必不可少的一部分。
- 開始被學術和其他研究者所使用，并作為很便利的公共語言。
在處理復雜軟件時，UML同樣能夠幫助增強對模建模價值的普遍的認識。盡管這種非常實用的技術幾乎和軟件本身一樣歷史悠久—――像很早以前的例子那樣它們都帶有數據流圖（flowcharts）和有限狀態機—――大多數開發人員慢慢地才接受它，如同接受其他工具一樣，而不是像接受一個有用的小工具那樣迅速。客觀的說，這種對新事物的態度仍舊是一個占有主導性地位的，這就是為什么模型驅動方法在這一領域中受到很大的阻力的原因。
之所以會存在上述情形是有一些原因的（當然也有些不是那么有根據的原因，比如：通常人們并不相信創新）。主要原因是軟件模式經常會導致不可預知的嚴重性錯誤：我們都清楚，任何一個模式的實際價值與它的正確性直接成比例。如果一個模式不能把它所表示的軟件系統向你準確的表現出來，那么還不如不用模式，因為它可能會導致錯誤的結論。那么提高軟件價值的關鍵在于縮小這些模式和它們所模式化的系統之間的差距。然而，正如這篇文章后面所論述的，在軟件中減小這種差距比在其他任何的工程學科中要容易的多。
某些錯誤的軟件模式歸咎于當前編程語言的過多的細節和敏感的本質。一些較小的失誤和幾乎不被發覺的編碼錯誤――比如指針偏差或者變量未初始化――可能會帶來嚴重的后果。舉一個實例來說，在一個有相關文檔記錄的案例中記載，由于一個嵌套的switch語句中的某個case中少了一個break，結果導致美國的大部分地區失去了長途電話服務，以致帶來了巨大的經濟損失【lee92】。如果這些看似微小的細節會帶來如此可怕的后果，那么我們又如何相信模式的正確性（因為從定義上來看，模式應該用來隱藏或是去掉這些細節）？
回頁首
模型驅動開發
解決這一難題的方法是通過一個或多個自動的模型轉換器將一個模型與它相應的軟件實現從形式上連接起來。也許這方面最好和最成功的例子就是編譯器，它能夠將一個高級語言程序解釋成一個與之相當的機器語言的執行程序。這種情況下，模式就是這個高級語言程序，它就像所有有用的模式那樣，隱藏了潛在的計算技術特性上的相關細節（比如內存字符大小，累加器的個數，索引寄存器，ALU算術邏輯單元類型等等）。
有趣的是，幾乎沒有任何其他的工程媒介能夠為一個模型和它相應的工程工具提供如此緊密的連接。這是因為你所模式化的工具是軟件而不是硬件。任何一種物理工具的模式（比如：一輛汽車，一座建筑物，一架橋等等）不可避免地包含了一些步驟，它會將物理特性抽象成一個相應的模型（就像數學或幾何模型一樣）。同樣，使用物理原料實現一個抽象的模型包含了從抽象到具體的非正式轉換。這一非正式步驟的本質會導致一些錯誤，正如上面所提到的，會導致模型效率低下或是甚至達不到預期目的。然而，對軟件來說，原則上，這種轉換可以從各個角度的形式上的執行。
在抽象性和自動化抽象性與自動化操作強有力的結合后,所產生的潛能已經導致新的建模技術和相關發展方法的出現,正如所提及的模型驅動開發MDD) [Brown04] [Booch04]。MDD的定義特征是,此模型已經成為軟件設計的主要工具,它把許多注意力從相關的程序代碼上轉移開。它們為不同的自動化和半自動化的方法提供服務,這種方法源于代碼和相關的模型。與傳統的編碼相比較，目前在MDD中使用自動化操作的程度不同于從簡單框架代碼到完全自動的產生代碼。很明顯地，自動化程度越高，模型越精確，MDD的優越性就更突出。
軟件發展的模型驅動方法不是一種獨特地新式方法，在過去就已經被使用并獲得了不同程度地成功。他們之所以愈來愈受重視的原因是，其支持性技術已經愈來愈成熟，成熟點在于比起過去的情況來看在實踐上更加自動化。這不僅僅在效率方面，而且在可測量性方面，同樣這種工具所具有的能力是與繼承性工具和方法相結合的。這種成熟技術所反應的MDD標準的出現，使得使用相關的工具時更加便利舒適，給使用者帶來顯而易見的好處。其標準之一是統一建模語言的修訂版。
回頁首
修訂UML 1后的基本原理
UML 2.0是UML標準最主要的修訂本，以下的是一系列次要的修訂本[OMG04] [RJB05]。為什么修訂UML是必要的呢？
修訂這種語言最初的動機源于更好的支持MDD工具和方法的要求。在過去的十年中，許多供應商已經發展了基于UML的工具，值得注意的是這些工具所支持的自動化標準比傳統的CASE（計算機輔助軟件工程）工具標準更高。
為了支持這些更高標準的自動化形式，需要用一個比原始標準規定更加準確的方式來定義UML。（從與時俱進的角度來看，最初地原始UML標準設計是作為一種輔助工具來服務的，即為非正式的捕捉和設計意圖的傳達提供服務）。不幸地是，這些定義因商家的不同而不同，它的危險性導致了一些分歧的產生，而這些分歧是應該從舊版本的標準中被排除掉的。一個新版本的標準可以修正它。
另外，在近十年的使用UML的實踐經驗之后――同樣在此期間重要的新技術也隨之產生了（例如基于web的應用軟件和基于服務的體系結構），新的建模性能得到了肯定。事實上，當這些新技術通過現有UML概念的適當結合表現出來時，將它們作為優秀的內嵌語言特性引入是有明顯益處的。
最終，在同樣漫長的時間內，業界已經學會了許多有關如何使用的適當方法來構建和定義模型語言。例如，目前將要出現的外部模型和模型轉換的理論，它強制性要求一個模型語言如何來定義。由于與當前程序設計語言理論相比，我們一直缺乏一個統一的、系統的建模語言設計理論，因此我們需要把這些理論以及類似的發展合并在UML中，這樣才能確保其效用和持久性。
回頁首
UML 2.0 特性的亮點
UML 2.0的新改進可分為以下五個主要方面，按重要性順序列出：
- 在語言定義方面精確程度有了相當的提高: 這就是支持自動化高標準需要的結果，此標準是MDD所必須的。自動化意味著模型（以及后來的模型語言）的不明確和不精密的消除，所以計算機程序能轉換并熟練地操縱模型。
- 一個改良的語言組織: 其特性是由模塊化決定的，模塊化的特點在于它不僅使得語言更加容易的被新用戶所采用，而且促進了工具之間的相互作用。
- 重點改進大規模的軟件系統模型性能: 一些流行的應用軟件表現出將現有的獨立應用程序集成到更加復雜的系統中去。這是一種趨勢，它將可能會繼續導致更加復雜的系統。為了支持這種趨勢，將更加靈活和新的分等級的性能添加到語言中去，用以支持軟件模型在任意復雜的級別中使用。
- 對特定領域的改進的支持: 使用 UML 的實踐經驗證明了其所謂的“擴展”機制的價值。這些機制被統一化，精煉化后，使得基礎語言更加簡化，更加準確精煉。
- 全面的合并，合理化，清晰化各種不同的模型概念: 從而導致一種單一化，更加統一化語言的產生。它包含了合并和――在一些案例中――消除多余的概念，精練各種各樣的定義，添加文字性的解釋和例子。
現在我們來更詳細地研究一下上述的每個方面。
精確程度
大多數的早期軟件建模語言被非正式地定義，并很少注重它的精確性。時常，建模概念被解釋成使用不嚴密的自然語言。由于大多數的建模語言在文件中或在Martin Fowler所提及的設計草圖[Fowler04]中所使用，在那個時期，此模型概念得到了充分信任。這種思想傳達了一種設計的本質特性，而把細節留給實現階段去處理。
然而，由于模型在這種語言中很可能――并且通常是――被不同的商家解釋成不同的含義，因此經常導致概念混淆。此外，除非模型解釋的問題事先已被明確地討論過，否則像這樣的分歧還不能被人所發覺，而只是在發展的較后階段才能被發現（即當問題的結果已明顯顯現時候）。
為了把不明確的概念減少到最少――并和多數現代的其它模型語言形成對比―― 第一個標準化的UML定義是用元模型來指定的。這是一個定義每一種UML 建模概念特性和這些特性與其他相關概念直接的關系的模型。使用UML的基本子集來定義這個元模型，并且通過一系列在對象約束語言中（OCL）正式的強制進行補充。
注釋:: 這種UML子集，主要是由定義在UML上的類圖上的概念所組成的，它被稱為元對象工具（MOF）。選擇這個子集后，它可以用來定義其它的建模語言。
這種結合所描述的是，UML抽象語法的一種正式的規范。正式的規范。之所以被稱作是正式的，其原因是它與實際的符號或用于描繪模型的具體語法具體語法（也就是說，文本和圖表）無關。換句話說就是，它所定義的規則集可以用來確定一個特定的模型是否已經很好的成形很好的成形。例如，這種規則將允許我們去測定通過一個狀態機轉換來連接兩個UML類是不正確的。
然而，在這個初始的UML 元模型中所使用的精確程度證實，在MDD（例如在[Stevens02]中討論所見到的）后，對整個潛能的支持是遠遠不夠的。特別是，UML建模概念的語義（或含義）的規范，對這些作為自動代碼生成或正式確認的基于MDD的活動仍舊是不適當的。
因此，值得注意的是在UML 2.0中定義所使用的精確程度已經增強了。它是通過以下方法完成的：
- 一種元模型架構的主要重建: UML 2.0架構是由一組低層次的建模概念和模式所組成的，它們在大多數的案例中要么過于初級，要么太抽象，以至于不能直接地在建模軟件應用程序中使用。然而，它們相對的簡單性使得它們在其語義和形成的規則上更加精確。這些優化后的概念，以不同的方法結合產生了更加復雜的用戶級別的建模概念。例如，在UML 1中，在所有權角度上（即，元素包含另外一些元素），命名空間的概念（也叫唯一命名的元素集合）與分類器的概念（元素是能根據它們的屬性進行分類的）上，都與單個的復雜語義概念綁定在一起。（注意這同樣意味著如果沒有包含另外兩個而使用其中的任意一個的話，那是不可能的。）在新的UML 2.0架構中，這些概念被分離開，并且它們的語法和語義也被單獨的定義。
- 可擴展的和更加精確的語義描述:UML 1模型概念語義的定義在許多方法都存在問題。它所描述的層次有些地方具有某些廣泛的和詳細的描述（例如，狀態機），但是非常不平均，而其它的一些地方幾乎沒有解釋。UML 2.0規范主要強調了語義，尤其是在基本行為動態的關鍵領域中（如下所述）。對于一個更加詳細的UML 2.0語義的討論，請參考資源部分中的[Selic04]。
- 一種清晰定義的動態語義框架: UML 2.0規范澄清了一些在老版本中的嚴重語義缺陷。圖一描述了這個框架，至于更多的細節在資源中有所描述。[Selic04]。此外，下面的問題將通過這個框架詳細的描述出來：
- 在運行期間的鏈接和實例的結構化語義
- 結構和行為之間的關聯
- 語義的基礎或因果關系模型通過所有當前在UML中的高級行為形式（即狀態機，活動，交互）所共享。這同樣也確保了那些通過不同的形式表達行為的對象可以相互的交互。
圖 1. UML2.0語義框架
?
新的語言架構
UML 2.0 在精確度方面的提升所造成的最直接的結果之一，就是即使不算它所新增的建模能力部分，這種語言的定義也變得更大了。特別是對于最初的UML，曾被批評過于龐大（以至于學習和使用起來太麻煩），對于現在更加龐大的定義，這點通常又將被關注。
這樣的批評典型地忽略了一個事實，那就是UML原本就是用來表述一些現在最復雜的軟件問題，這樣的問題當然需要功能充分強大的工具。（成功的科技——如同汽車和電子學，從來沒有變得簡單；對機器持續不斷的要求是人類的本性之一，這就造成了最終越來越復雜的工具。例如，沒有人會企圖用基本的手工建造現代的摩天大廈。）
不過，由于有了這些顧慮，UML2.0 在某種程度上進行了模塊化，允許有選擇性的使用一些語言模塊，以便解決語言復雜度的問題。這種結構的通常形式如圖2所示。一些像類和關聯這樣的共享概念組成了它的基礎部分，頂部是垂直的子語言或語言單元的一個集合，集合中的每個單元都很適合用來對某個具體的方面進行建模（Table 1）。這些垂直的語言單元一般都是相互獨立的，因此你可以單獨地使用它們。（注意：這在UML1中是不行的，在UML1中，活動的形式完全是基于狀態機的形式。）
圖 2. UML 2.0的語言架構
?
此外，垂直語言單元按級別組織成三層，通過在那些可用的層上增加建模能力可以形成相互連續的更高層。這就對模塊性提供了更多的空間，即使對一個已給定的語言單元，你也有可能只使用某些特定的子集。
這樣的架構意味著，你可以學習和使用UML那些最適合你的部分。你不再需要為了有效地使用UML去熟悉它所有的內容，就如同你不必為了說好英語而去學習英語里所有的內容一樣，從這點來說，它可能比學英語更簡單。隨著你經驗的增長，如果有必要你可以逐漸引入更強大的建模概念。
表1 UML 2.0的語言單元
| 語言單元 | 目的 |
| 動作 | (基礎) 細粒度動作的建模 |
| 活動 | 數據和控制流行為建模 |
| 類 | (基礎) 基本結構的建模 |
| 組件 | 組件技術的復雜結構建模 |
| 部署 | 部署建模 |
| 通用行為 | (基礎)公共行為語義基礎和時間建模 |
| 信息流 | 抽象數據流建模 |
| 交互 | 內部對象行為建模 |
| 建模 | 模型組織 |
| Profiles | 語言定制化 |
| 狀態機 | 事件驅動行為建模 |
| 結構 | 復雜的結構建模 |
| 模板 | 模式建模 |
| 用例 | 非正式的行為需求建模 |
作為相同架構下重組的一部分，在UML2.0中，語言的定義和結構的靈活性被顯著地簡化了。在UML1中，規范性的基本單元是由元模型的包定義的，包含了差不多成百個可能的組合。（事實上，因為UML 1 為一個特定的適應性給出了規范化的但又不完全的靈活定義 ，也就是說這些性能可以有很多種不同的組合）這就意味著，幾乎不可能找到兩個或更多的建模工具能相互之間進行模型交換，因為每一種工具可能只支持包的一種不同的組合。
在UML 2.0中，只定義了三個規范性層次，那些對應于分級語言單元的層已經在0層中就被提及并描述了。它們是這樣被定義的，層（n）的模型服從于任何比它更高的層（如n＋1）所定義的模型。換句話說，一個符合給定層規范的工具可以從那些符合任一相同或低于它所在層規范的工具中導入模型――在沒有丟失信息的情況下。
注釋: 形式上，UML 2 也定義了第四層（層 0），但這只是一個內部層，主要用來供工具的實現者使用。
四種規范標準類型的定義
- 抽象句法規范標準
- 混合句法規范標準（也就是UML符號）
- 抽象句法和混合句法規范標準
- 抽象句法和混合句法規范，和圖之間相互交換的標準
這就意味著最多有12種不同規范標準組合，并且它們之間有著清晰的從屬關系。（比如，抽象和具體的語法標準與僅僅是具體的或僅僅是抽象的語法標準保持一致）。從而使得在UML2.0中不同廠商的工具之間的模型交換成為可能，而不僅僅只停留在理論上。
大規模系統建模能力
在UML2.0中,新增的特性相對來說不是很多。這是特意為了避免已經聲名狼藉的“次要系統”效應[Brooks95],因為一門語言沒有必要由于非常多變的分用戶群的提出新的需求而過度的膨脹。實際上，新的建模能力的主要實質是對已存在的特征進行簡單地擴充，以便用于大規模的軟件系統的建模。
此外，這些擴展都是通過使用相同的基本方法達到的：即在不同的抽象層面上遞歸地應用那些相同的基本概念集。這就意味著，你可以把一個給定類型的模型元素合并到單元里，依次類推，你可以用這種方式在下個抽象層面上進行合并，并把這些合并后的單元作為一個模塊進行使用。這跟編程語言中的過程類似，它能根據你想要的深度進行嵌套的調用。
特別是，以下建模能力通過這樣的方式被擴展了：
- 復雜結構
- 活動
- 交互
- 狀態機
上述的前三項占到了UML2.0的新特性中的90％以上
復雜結構
這一系列特征的依據來自于對不同架構描述語言（如UML-RT [SR98], Acme [GMW97], 和 SDL [ITU02]）長期使用的經驗。這些語言的特點在于，它們通過相對簡單的像圖這樣的概念被描述：基本的結構性節點，也就是所謂的部件，他們可以有一個或多個端口，它們之間可以由被稱作連接器的通信通道進行連接（如圖3所示）。這些集合體可以被封裝成更高層的單元，依次類推，這些新封裝成的單元也可以有自己的端口以便于與其他更高層的單元合并成更高層的單元
圖 3. 復雜結構建模概念
?
從某種程度上來說，這些概念在UML 1 中對于協作的定義里可以找到，只可惜它們不能用于遞歸。為了允許遞歸，協作結構被嵌套到類的規范中。這就是說這個類的所有實例都將有一個由類定義的內部結構。例如，在圖3中，部件（part）/a:A 和/b:B 都被嵌套在部件（part）/c:C中，從而表現了這個復雜結構類C的一個實例。而這個類的其他實例都會有相同的結構模式（包括所有的端口，部件以及連接器）
這就證明了，你可以通過這三個簡單的概念，以及它們的遞歸應用，對任何復雜的軟件架構建模。
活動
在UML中，活動被用來對不同種類的流程建模：信號流或數據流，也有算法流或過程流。不用說，對于眾多的領域及應用而言，基于流的描述是最自然的表現方式了。對于業務過程建模者和那些想主要通過信號處理器瀏覽整個系統的系統工程師，這種形式更是特別受歡迎。不幸的是，在UML 1中，行為建模在流的類型方面有大量嚴格的限制，這些限制被提出了異議。這其中的很多限制都是由于在基本的狀態機的頂部行為被覆蓋了，所以，它們受限于狀態機的語義。
UML 2.0中用一個消除了這些限制的更泛化的語義基礎替代了狀態機的底層。此外，這些語義基礎也從很多行業標準和業務過程形式中得到靈感，其中包括BPEL4WS [BPEL03]——在基礎的形式上增加了一系列非常豐富并且非常精確的建模特征。這包括以下一些能力：
- 中斷的活動流
- 復雜形式的并發控制
- 多樣的緩沖配置
這就形成了一個豐富的建模工具集，能廣泛地表示不同的流類型。
由于其復雜的結構，你可以對活動遞歸地進行分組并對流進行連接以形成更高的層，這種層次清晰地定義了輸入和輸出。你可以一次把這些活動與其他活動合并形成更復雜的活動，一直到最高的系統層。
交互
在UML1 中，交互性是由協作圖中序列消息的注釋或單獨的序列圖來表現的。不幸的是，這樣導致失去了兩個基本能力：
幸運的是，關于復雜的交互性問題在電信領域得到了廣泛地研究。在多年定義通信協議的時間過程中，形成了一個標準。這個標準被作為主要依據用在UML2.0的交互性描述上。
關鍵的創新就是把交互性作為單獨命名的建模單元進行引入。這樣的交互性表現在內部對象間任意復雜的通信。它甚至可以被參數化以用來描述上下文獨立的交互模式。
你也可以從更高層遞歸地調用這些打包了的交互活動，類似于宏調用（圖4）。就像你所希望的那樣，你可以在任意程度上去進行嵌套。此外，交互活動還能在諸如循環和選擇這樣的復雜控制的構造中提供操作數（例如，某個給定的交互活動可能需要重復某個具體的次數）。UML 2.0 定義了大量的這種類型的建模構造體，給你在分解后的任何層面上進行復雜的端對端建模，提供了非常大的便利。
圖4. 一個復雜交互模型的例子
?
圖4舉例說明了一個擴展的交互模型。在這個例子中，交互活動ATM的訪問首先調用另一個低層的叫CheckPIN的處理過程（整個交互活動的內容沒有在圖中顯示），注意到后一個交互活動有一個參數（這個例子中也就是，在處理被取消前，一個無效PIN能被輸入的次數）。之后，客戶端發送一個同步的消息說明需要哪種交互活動，基于這個具體的值——DispenseCash活動或PayBill活動，將被執行。
在UML 2.0中，交互性不僅由序列圖來呈現（如同上面的例子所展示），也通過其他類型的圖（包括在UML1中定義的基于協作的形式）來表現。甚至還有通過非圖形化的表格來體現。
狀態機
添加到UML2.0中的主要新特性與之前的案例非常相似。基本思想是它可以創建一個復合狀態的完整模塊，它具有清晰的轉換入口點和出口點。反過來，你也可以通過一個離散的和可重復使用的狀態機的規范來分別地定義上述的復合狀態的內在分解。也就是說，在這個狀態機或某些其它的狀態機中，相同的規范可以在多處重復使用。這樣使得在不同上下文中的共享行為模式的規范更加簡單化。
在UML2.0中另一個著名的狀態機創新是在一個類與它的子類中繼承的狀態機的分類。
語言特殊化能力
UML1的實踐表明了應用UML的一個相當通用的方式是，首先為一個特定的問題或領域定義一個UML Profile ，然后用這個 Profile 代替普通的UML。實質上，這些 Profile 就是一種生成像特定領域語言?(DSL)的方法。
使用UML Profile 的一種可選擇的辦法是使用MOF標準和工具定義一種新的自定義模型化語言。后者的方法顯然有很大的優勢，它具有語言定義功能，這種定義可以以最佳的方式解決手頭的問題。乍看上去，這種方式似乎是DSL定義的首選方式，但是進一步的觀察會發現這種方法存在嚴重的缺陷。
如簡介中所提到的，過多的差異會導致分裂性問題的出現，而設計UML的目的正是要消除這類問題的。
幸運的是，Profile 機制在這里為許多實際的案例提供了一個便利的解決方案。這是因為在不同的DSL之間存在相當多典型的公共部分。例如，實際上任何一個面向對象的建模語言都需要定義類，屬性，關聯，相互作用等概念。UML，作為一種多用途的建模語言，正好提供了這個便利和有用概念集合的謹慎定義。對多數可能的DSL來說這正是一個好的起點。
但是在這里不僅僅只是概念上的復用，因為從定義的角度，一個UML Profile 必須與標準UML保持一致。換句話說，一個UML Profile限定了標準UML的概念。這種限定是通過定義上的限制來限制那些給它們提供一種唯一的特殊領域解釋的概念。例如，一個限制可能不允許多重繼承，或者是它可能需要一個類必須具備一個特殊的屬性類型。這就意味著：
- 任何一種支持標準UML的工具可以基于上述的 Profile 來操縱模型。
- 任何有關標準UML的知識和實際經驗都可以之間應用。
因此，大多數的防止差異上的分裂問題可以完全地減輕或是甚至避免。這種推理方式帶來了國際化標準，是形成SDL【ITU02】的原因――這個SDL廣泛地在電信上使用――從而重新將SDL定義為一個UML Profile 。【ITU00】【ITU03】。
這并不是說任何一個DSL都能并需要被實現成一個UML Profile ；確實存在很多的案例說明UML可能缺少必備的可以被轉換到相應DSL概念中的基礎性概念。盡管如此，UML通用性可能比許多人所想象的更廣泛。
基于上述考慮，在UML2.0中的 profiling 機制已經被合理化并且它的性能也已經被擴展了。在原型和UML概念之間的連接已經被擴展了。事實上，一個UML2.0原型被定義成好像它僅僅只是一個現有UML元類的子集，并帶有關聯的屬性（代表加有標簽的值的標簽），操作和限制。這個機制使用比如像OCL這樣的語言描述那些限制，它已經被充分的說明了。
除了限制個別的建模概念以外，一個UML2.0框架同樣可以明確的隱藏UML概念，從而使得在一個給定的DSL中沒有任何意義和必要
最后，UML2.0 profiling 機制同時也可以用作一種機制，它可以從多種不同的域中觀察到一個復雜的UML模型――從特定的角度――通常不一定具有DSL。也就是說，任何一個profile 都可以有選擇性的以任何方式被應用或是不被應用，只要不影響基礎的UML模型。例如，一個性能工程師可能會選擇在模型之上通過將多種與性能相關的方法與模型元素連接，來應用一種性能模型化解釋。然后可以通過一個自動化技術性能分析工具來決定。
一般性的合并
這一項特性適用于很多的領域，包括重復概念的消除和多數編輯上的修改（比如：給模糊的描述和標準化的術語以及特殊的格式添加相應的說明）
消除了重復和對缺乏定義的概念的說明也是UML2.0另一個重要的需求。受這個需求影響的主要有下面三個主要領域：
- 動作和活動
- 模板
- 基于組件的設計概念
在UML1.5中介紹過動作。動作的概念上的模型被特意的普通化，從而提供數據流和控制流計算模型。這就導致了與活動模型在概念上非常相似。UML2.0利用了這種相似，它為動作和活動提供了一個通用的在語法上和語義上的基礎。從你的角度來看，在不同層次上的抽象顯得有些過于的形式主義，因為它很典型模擬了不同層次的之間存在的現象。盡管如此，共享概念上的基礎使得它完全的簡單化和更加的清晰。
在UML 1中，定義模板是非常普遍的：任何的UML 概念都可能產生一個模板。不幸的是，這種普遍性是它應用上的一種阻礙，因為允許存在潛在的無意義的模板類型和可代替的模板。在UML 2.0中的模板機制受到一些容易理解的案例的限制如：分類器，操作，和包。前兩種是在流行的程序語言創建模板機制后被模式化的。
基于組件的設計領域中，UML1 有很多使人混淆的概念。你可以使用類，組件，或子系統。這些概念除了在不同方法中有一些微妙的差別外，它們都有著許多共同點。關于在任意的特定情況下來使用，這里沒有清楚的描繪。一個子系統僅僅是一個“較大的”組件嗎？假如這樣的話，毫無疑問的是它在成為一個子系統以前，一個組件要多大呢？類提供了封裝和接口的實現，組件和子系統也可以做到。
在UML 2.0中，所有的這些概念都被結合在一起，所以組件被作為一個特殊的例子簡單地定義了，即一個結構化類的更加全面的概念；同樣地，子系統也僅僅是組件概念的一個特殊例子。兩者之間從性質上的不同有清楚的定義，因此，當你使用基于客觀的標準概念時，你便能果斷地作出決定。
在編輯方面，規范的格式已經統一化了，使用了語法與簡單參考資料相結合的模型概念符號規范。每一個元類規范被擴大化了，它明確地確定了語義的不同點，符號的選擇權，以及它與UML 1規范的關系。最終，專業術語得到了統一，因此一個特定的條件（例如，類型，實例，規范，或事件）在它出現過的所有上下文中有著相同的全面含義。
回頁首
總結
UML 2.0對驅動模型方法做了初步的介紹。那些喜歡將它作為一種繪圖工具（正如在文章中先前所描述的那樣）的使用者同樣也可以像UML 1一樣以非正式的方式使用它。此外，盡管新的建模性能是非插入式的，但是在大多數的案例中，這樣的使用者將在語言的視覺和感覺上看不到任何變化。
然而，現在MDD階段性進步的機會在標準化的方法中是可得到的。UML 2.0包含必要的精確性的增強，并且如果你希望你可以使用它的新特性的話――所有的方法都可以完全自動的產生代碼。
語言的結構被謹慎的重新編制后允許采用一個模型和漸變的方法：你僅僅需要學習你所感興趣的那部分語言，其余的你可以完全的忽視。隨著經驗和知識的增加，你能選擇性地添加新的能力。隨著重組帶來了規范標準定義的極大的簡化，它將促進了工具之間的互用性，同時也將促進來自不同商家之間的工具的互用性。
僅有少量新特性被添加里面（用來避免語言冗余），實際上所有這些都遵循相同的遞規法則設計原則，從而使你能夠模型化既大又復雜的系統。尤其是，這些擴展被添加以促進更加直接地建模軟件體系結構，復雜的系統交互，和基于流程的建模，使它在例如商業過程建模和系統工程中被理想化的應用，。
語言擴展機制將被結構重組和簡化，以給你提供一種更加直接地方法基于UML來定義特定領域語言（DSL），這些語言在直接的利用豐富的UML工具和專門技術上有著獨特的優勢。
所有這些導致了第二代建模語言的產生，這種語言將使你更快更可靠的開發成熟的軟件系統――同時允許你繼續使用相同類型的經驗和知識，也是每個軟件開發人員所要掌握的技能。
?
參考資料
- 您可以參閱本文在 developerWorks 全球站點上的?英文原文。
- 參考?“UML 基礎”系列?的其他文章。
- UML基礎: 統一建模語言簡介
- UML 基礎: 類圖
- UML 基礎: 序列圖
- UML 基礎: 組件圖
- 繪制整潔的 UML 圖
- 用例建模技巧
- UML 序列圖簡介
- 養成良好的繪制 UML 序列圖的習慣
- 利用 UML 進行實體關系建模
- [BPEL03] BEA, et al.,?Web Services業務處理執行語言?(版本 1.1), 5 May 2003, 2003
- [Brooks95]?Brooks Jr., F.,?人月神化?(1995 edition), Addison-Wesley, 1995.
- [Brown04] Brown, A.,?模型驅動架構入門?, IBM developerWorks, 2004.
- [Fowler04] Fowler, M.,?UML精解?(第三版), Addison-Wesley, 2004.
- [GMW97] Garlan, D., Monroe, R., and Wile, D.,?Acme: 一個描述交互語言的架構, in?協作調查高級研究中心會議1997年會議錄, 計算機協會 (ACM), 1997.
- [Graham01]?Graham, I.,?面向對象方法: 原則和實踐?(3rd edition), Addison-Wesley, 2001
- [ITU00]?國際電信組織,?ITU Recommendation Z.109:?SDL與UML相結合, ITU-T, 2000.
- [ITU02]?國際電信組織,?ITU Recommendation Z.100:?規范化描述語言 (SDL), (08/02), ITU-T, 2002.
- [ITU04]?國際電信組織,?ITU Recommendation Z.120:?消息序列圖 (MSC), (04/04), ITU-T, 2004.
- [ITU05]?國際電信組織,?Study Group 17: Question 13/17 -- 系統設計語言框架和統一建模語言, ITU-T Study Group 17, 2003.
- [Lee92]?Lee, L.?The Day the Phones Stopped Ringing, Plume 出版, 1992.
- [Booch04] Booch, G., et al.,?MDA聲明, in Frankel, D., and Parodi, J. (eds.),?MDA 雜志, Meghan-Kiffer 出版, 2004.
- [OMG03a]?Object Management Group,?統一建模語言(UML)?,1.5版本, OMG 文件形式/03-03-01, 2003.
- [OMG03b]?對象管理組織,?UML 2.0 圖形交互?, 最終采用規范, OMG 文件ptc/03-09-01, 2004.
- [OMG04]?對象管理組織,?UML 2.0 上層架構?, 可用規范, OMG 文件ptc/04-10-02, 2004.
- [RJB05] Rumbaugh, J., Jacobson, I., and Booch, G.,?統一建模語言參考手冊（第二版）, Addison-Wesley, 2005.
- [Stevens02]?Stevens, P.,?有關統一建模語言中的二元關系的介紹,?軟件和系統建模期刊, vol.1, no.1, Springer-Verlag, September 2002.
- [Selic04]?Selic, B.,?標準UML 2.0語義基礎, in Bernardo, M., and Corradini, F. (eds.),?實時系統設計的規范方法, 計算機科學講稿 vol. 3185, Springer-Verlag, 2004.
- [SR98] Selic, B. and Rumbaugh, J.?Using UML for Modeling Complex Real-Time Systems?. 白皮書, Apr. 4, 1998,?
- 得到Rational Application Developer,?Rational Software Architect的評估版和其它IBM Rational支持UML 2.0的產品，請訪問?試用版或測試版網頁。
- IBM 軟件交付平臺專題?提供整個 IBM 軟件交付平臺 的詳細信息, 如: IRAD, IRSA, IRSM, 和 其他基于UML 2.0產品等部分產品
- 有關Rational產品技術的資源，訪問。你將找到技術性的文件，指導性的文章，教學，相關下載和產品信息，等等。developerWorks 中國網站 Rational專區。你將找到技術性的文件，指導性的文章，教學，相關下載和產品信息，等等。
- 通過訪問IBM Rational 軟件?的網頁，能夠找到更多相關的信息 。
- 通過加入developerWorks blogs，你可以參與開發者社區。
- 在Rational Software Architect, Software Modeler, Application Developer 和 Web Developer forum網頁上，你可以詢問有關Rational Application Developer 和 Rational Software Architect。
- 在IBM Rational開發者書店中使用折扣價購買IBM Rational書籍。
關于作者
Bran Selic 是 IBM 的杰出工程師，在加拿大IBM Rational 軟件工作。他在特定的軟件產業設計和大規模實時系統的開發方面有著將近三十年的工作經驗。一九七二年他在南斯拉夫貝爾格萊德大學獲得了機電工程學士學位并于一九七四年獲得了系統理論碩士學位。從一九七七年開始他就一直生活并工作在加拿大。
轉載于:https://www.cnblogs.com/AloneSword/p/3373795.html
總結
以上是生活随笔為你收集整理的统一建模语言(UML) 版本 2.0的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： eclipse中folder、sourc
- 下一篇： Android笔记之调用其他软件