在學習UML的過程中，你可能會遇到結(jié)構(gòu)建模的性能問題，這里就向大家介紹一下UML2.0如何規(guī)范改善結(jié)構(gòu)建模的性能，主要包括UML超級結(jié)構(gòu)的內(nèi)容，結(jié)構(gòu)類和狀態(tài)框圖的繼承等內(nèi)容，相信本節(jié)的介紹一定會讓你收獲不少。下面讓我們一起看一下本節(jié)的具體介紹吧。

UML2.0規(guī)范改善了結(jié)構(gòu)建模的性能

UML2.0完全建立在UML1.x基礎(chǔ)之上，大多數(shù)的UML1.x模型在UML2.0中都可用。但UML2.0在結(jié)構(gòu)建模方面有一系列重大的改進，包括結(jié)構(gòu)類、精確的接口和端口、拓展性、交互片斷和操作符以及基于時間建模能力的增強。當然還有時序框圖，但如果你不使用這些功能，也就不用擔心這些特性，因為僅使用類框圖、順序框圖和狀態(tài)框圖仍可建立非常復雜的實時嵌入式系統(tǒng)。

在UML(統(tǒng)一建模語言)2.0規(guī)范中存在4種有關(guān)的請求建議(RFP)文件：基礎(chǔ)設(shè)施(Infrastructure)、對象約束語言(OCL)、元數(shù)據(jù)交換(XMI)和超級結(jié)構(gòu)。基礎(chǔ)設(shè)施RFP涉及UML的定義基礎(chǔ)以及與OMG的元對象設(shè)施(MOF)的對齊。OCLRFP文件涉及對OCL的改善。實際上，除了那些定義UML的人員之外，很少有用戶需要使用OCL。XMIRFP文件定義了一種交換語義模型信息的格式，但它目前沒有指定如何交換框圖表。XMIRFP文件則提出了改善定義交換框圖表的XMI的建議。

雖然這3個RFP文件非常重要，也很有用，但它們主要由元模型構(gòu)建人員(例如定義UML的人員)和UML工具供應商使用。第4個，也是最后一個RFP――超級結(jié)構(gòu)，是大多數(shù)用戶所關(guān)注的，這些用戶構(gòu)建實際模型，并建立現(xiàn)實世界中工作的系統(tǒng)。

UML超級結(jié)構(gòu)的內(nèi)容

在最高層次上，超級結(jié)構(gòu)RFP要求：1)允許結(jié)構(gòu)模式的建模，例如基于元件的開發(fā)以及實時結(jié)構(gòu)規(guī)范；2)澄清通用性、依賴性和關(guān)聯(lián)性的語義；3)在行為建模中支持封裝和拓展性(scalability)，特別是在狀態(tài)機和交互作用的情況下；4)去除在活動框圖表建模中由于映射到狀態(tài)機而產(chǎn)生的限制。

該RFP繼而建議在UML1.x中接口和結(jié)構(gòu)的概念必須要加強，以支持并簡化對標準元件框架和結(jié)構(gòu)的支持。另外它還規(guī)定必須加入數(shù)據(jù)流建模，并澄清許多關(guān)系語義。更為重要的是，RFP提出順序框圖在表現(xiàn)力和語義方面的局限太多，建議應該加強這方面能力。另外，活動框圖在語義上應與狀態(tài)機相區(qū)別。最后，該RFP給出了去除UML1.x規(guī)范中的錯誤和不一致性。簡單地說，超級結(jié)構(gòu)的請求是在結(jié)構(gòu)和規(guī)模拓展性方面改進UML的能力和應用。

超級結(jié)構(gòu)包含了UML2.0規(guī)范中“用戶可視”部分。拓展性和架構(gòu)是推動對RFP的需求的兩個力量，它們之間有聯(lián)系，但又有明顯不同的概念。特別是，定義一種能在“小系統(tǒng)”中很好應用，并能升級應用到“大系統(tǒng)”的建模概念(元類型)非常重要。我們不希望突然轉(zhuǎn)換到一套完全不同的概念，因為我們面對的是架構(gòu)問題，而不是別的小問題。這就需要在工作開始之前有預定的假設(shè)，該假設(shè)在實踐中可能會有問題。

定義一套可擴展到架構(gòu)應用的概念，遠勝于一套將架構(gòu)完全排除在外的概念。這兩種概念是明顯不同的：在UML2.0中，架構(gòu)改變主要表現(xiàn)在結(jié)構(gòu)(類)模型方面，而拓展性變化在改進的順序框圖中表現(xiàn)最為明顯。

結(jié)構(gòu)類

元件和子系統(tǒng)顯然是架構(gòu)范疇內(nèi)的概念，但它們是怎樣與類聯(lián)系起來？它們之間又是如何相互聯(lián)系的？UML1.x在這些方面是模糊，UML2.0則引進了“結(jié)構(gòu)類”的概念。結(jié)構(gòu)類是一種由外在“嵌套”元件組成的類，目的是對容器分層結(jié)構(gòu)(containmenthierarchy)建模，這些分層結(jié)構(gòu)是由“元件(part)”構(gòu)成的類。

圖1所示的簡單的Rhapsody(I-Logix公司的UML工具)類解釋了UML2.0中結(jié)構(gòu)類的概念。“ElevatorCar”由一序列的元件組成：按鈕、目的樓層列表(和目的樓層本身)以及和一扇門。類似地，一個樓層類具有一個請求電梯上下的按鈕和一個指示電梯到達層面的指示器。它們都是結(jié)構(gòu)類因為它們都能被分解成更基本的元件對象。Door、ElevatorGnome和shaft類也都是結(jié)構(gòu)類，不過它們在這個模型的其它部分進行分解.

結(jié)構(gòu)建模的另一個新增部分是端口，或者可實例化(instantiable)的連接點。端口可以與結(jié)構(gòu)類一起使用，以允許“元件”(位于結(jié)構(gòu)類之內(nèi))輸出特定服務，或者在外圍結(jié)構(gòu)類的邊界上操作。端口的使用是一種設(shè)計模式，這樣使用它也會帶來正、反兩方面的影響。但UML2.0將端口提升為第一位概念，盡管對它的使用是可選的。

UML2.0以2種方式擴展了接口的概念。首先，UML1.x接口僅允許指定供應方，這個功能被保留了。UML2.0還允許(可選的)指定請求(客戶)方。接口也用另外的方式進行了增強。在UML1.x中，接口不包含屬性和狀態(tài)機，而UML2.0接口可以具有“虛”屬性。在UML2.0中的接口仍然不是可實例化的(instantiable)。

當標準規(guī)定了一套屬性，就要求類具備這些屬性。另外，在UML1.x中，接口的局限性之一是沒有指定服務順序的方法。我們都知道，許多系統(tǒng)要求某些服務有順序，例如我會強烈要求我乘坐的飛機在落地前先放下起落架。

在UML2.0中，這些操作請求序列可以通過協(xié)議狀態(tài)機來指定。協(xié)議狀態(tài)機除了有一些限制之外，跟正常的狀態(tài)機相同。它沒有進入和退出的動作、活動、內(nèi)部轉(zhuǎn)換、歷史狀態(tài)等特性。它的目的是指定接口一系列的可能操作服務。元件是一種結(jié)構(gòu)類型，因此它可以選擇具有端口和接口。

元件的記號與UML1.x中規(guī)定的有所不同。UML2.0規(guī)范規(guī)定在邊角處有一個元件框圖標或老套的“元件”字樣。元件與子系統(tǒng)的關(guān)系在UML2.0中也得到了澄清。子系統(tǒng)通常比元件“大”，并且可以包含元件。如果愿意，你可以在元件盒(componentbox，)的“artifacts”段指定元件或子系統(tǒng)，例如包含執(zhí)行代碼的文件。

狀態(tài)框圖的繼承

對于“reactive”或“stateful”類(也就是具有狀態(tài)框圖的類)，人們自然希望該類的子類也能體現(xiàn)父輩的特征。UML1.x對此定義不清楚，但在UML2.0中，I-LOGIX采用的方法定義了“狀態(tài)框圖繼承”。

事繼承很有用的是“替代性”的概念。也就是說，一個子類的實例可以由超級類(superclass)來代替，而系統(tǒng)仍然有效并能正常工作。這里需要考慮對子類的繼承狀態(tài)框圖的操作準則。我們可以通過添加“加入新狀態(tài)”、“子狀態(tài)”、“與狀態(tài)(and-states)”、“轉(zhuǎn)換(transition)”和“動作(action)”進行擴展，并通過利用多形態(tài)方法重定位轉(zhuǎn)換和修改動作列表。但不能刪除轉(zhuǎn)換和狀態(tài)，或者重新指定狀態(tài)的父輩(增加擁有這個狀態(tài)的新的復合狀態(tài))。

UML2.0完全建立在UML1.x基礎(chǔ)之上，大多數(shù)的UML1.x模型在UML2.0中都可用。但UML2.0在結(jié)構(gòu)建模方面有一系列重大的改進，包括結(jié)構(gòu)類、精確的接口和端口、拓展性、交互片斷和操作符以及基于時間建模能力的增強。當然還有時序框圖，但如果你不使用這些功能，也就不用擔心這些特性，因為僅使用類框圖、順序框圖和狀態(tài)框圖仍可建立非常復雜的實時嵌入式系統(tǒng)。

【編輯推薦】

1. UML2.0如何規(guī)范改善結(jié)構(gòu)建模的性能
2. UML2.0與UML1.x的異同
3. 如何繪制UML用例圖
4. UML2.0使模型驅(qū)動的開發(fā)更加容易
5. UML之父稱UML2.0版將簡化大型開發(fā)