UML2.0完美實現改善結構建模性能
在學習UML的過程中，你可能會遇到結構建模的性能問題，這里就向大家介紹一下UML2.0如何規范改善結構建模的性能，主要包括UML超級結構的內容，結構類和狀態框圖的繼承等內容，相信本節的介紹一定會讓你收獲不少。下面讓我們一起看一下本節的具體介紹吧。
UML2.0規范改善了結構建模的性能
UML2.0完全建立在UML1.x基礎之上，大多數的UML1.x模型在UML2.0中都可用。但UML2.0在結構建模方面有一系列重大的改進，包括結構類、精確的接口和端口、拓展性、交互片斷和操作符以及基于時間建模能力的增強。當然還有時序框圖，但如果你不使用這些功能，也就不用擔心這些特性，因為僅使用類框圖、順序框圖和狀態框圖仍可建立非常復雜的實時嵌入式系統。
在UML(統一建模語言)2.0規范中存在4種有關的請求建議(RFP)文件：基礎設施(Infrastructure)、對象約束語言(OCL)、元數據交換(XMI)和超級結構。基礎設施RFP涉及UML的定義基礎以及與OMG的元對象設施(MOF)的對齊。OCLRFP文件涉及對OCL的改善。實際上，除了那些定義UML的人員之外，很少有用戶需要使用OCL。XMIRFP文件定義了一種交換語義模型信息的格式，但它目前沒有指定如何交換框圖表。XMIRFP文件則提出了改善定義交換框圖表的XMI的建議。
雖然這3個RFP文件非常重要，也很有用，但它們主要由元模型構建人員(例如定義UML的人員)和UML工具供應商使用。第4個，也是最后一個RFP――超級結構，是大多數用戶所關注的，這些用戶構建實際模型，并建立現實世界中工作的系統。
UML超級結構的內容
在最高層次上，超級結構RFP要求：1)允許結構模式的建模，例如基于元件的開發以及實時結構規范；2)澄清通用性、依賴性和關聯性的語義；3)在行為建模中支持封裝和拓展性(scalability)，特別是在狀態機和交互作用的情況下；4)去除在活動框圖表建模中由于映射到狀態機而產生的限制。
該RFP繼而建議在UML1.x中接口和結構的概念必須要加強，以支持并簡化對標準元件框架和結構的支持。另外它還規定必須加入數據流建模，并澄清許多關系語義。更為重要的是，RFP提出順序框圖在表現力和語義方面的局限太多，建議應該加強這方面能力。另外，活動框圖在語義上應與狀態機相區別。最后，該RFP給出了去除UML1.x規范中的錯誤和不一致性。簡單地說，超級結構的請求是在結構和規模拓展性方面改進UML的能力和應用。
超級結構包含了UML2.0規范中“用戶可視”部分。拓展性和架構是推動對RFP的需求的兩個力量，它們之間有聯系，但又有明顯不同的概念。特別是，定義一種能在“小系統”中很好應用，并能升級應用到“大系統”的建模概念(元類型)非常重要。我們不希望突然轉換到一套完全不同的概念，因為我們面對的是架構問題，而不是別的小問題。這就需要在工作開始之前有預定的假設，該假設在實踐中可能會有問題。
定義一套可擴展到架構應用的概念，遠勝于一套將架構完全排除在外的概念。這兩種概念是明顯不同的：在UML2.0中，架構改變主要表現在結構(類)模型方面，而拓展性變化在改進的順序框圖中表現最為明顯。
結構類
元件和子系統顯然是架構范疇內的概念，但它們是怎樣與類聯系起來？它們之間又是如何相互聯系的？UML1.x在這些方面是模糊，UML2.0則引進了“結構類”的概念。結構類是一種由外在“嵌套”元件組成的類，目的是對容器分層結構(containmenthierarchy)建模，這些分層結構是由“元件(part)”構成的類。
圖1所示的簡單的Rhapsody(I-Logix公司的UML工具)類解釋了UML2.0中結構類的概念。“ElevatorCar”由一序列的元件組成：按鈕、目的樓層列表(和目的樓層本身)以及和一扇門。類似地，一個樓層類具有一個請求電梯上下的按鈕和一個指示電梯到達層面的指示器。它們都是結構類因為它們都能被分解成更基本的元件對象。Door、ElevatorGnome和shaft類也都是結構類，不過它們在這個模型的其它部分進行分解.
結構建模的另一個新增部分是端口，或者可實例化(instantiable)的連接點。端口可以與結構類一起使用，以允許“元件”(位于結構類之內)輸出特定服務，或者在外圍結構類的邊界上操作。端口的使用是一種設計模式，這樣使用它也會帶來正、反兩方面的影響。但UML2.0將端口提升為第一位概念，盡管對它的使用是可選的。
UML2.0以2種方式擴展了接口的概念。首先，UML1.x接口僅允許指定供應方，這個功能被保留了。UML2.0還允許(可選的)指定請求(客戶)方。接口也用另外的方式進行了增強。在UML1.x中，接口不包含屬性和狀態機，而UML2.0接口可以具有“虛”屬性。在UML2.0中的接口仍然不是可實例化的(instantiable)。
當標準規定了一套屬性，就要求類具備這些屬性。另外，在UML1.x中，接口的局限性之一是沒有指定服務順序的方法。我們都知道，許多系統要求某些服務有順序，例如我會強烈要求我乘坐的飛機在落地前先放下起落架。
在UML2.0中，這些操作請求序列可以通過協議狀態機來指定。協議狀態機除了有一些限制之外，跟正常的狀態機相同。它沒有進入和退出的動作、活動、內部轉換、歷史狀態等特性。它的目的是指定接口一系列的可能操作服務。元件是一種結構類型，因此它可以選擇具有端口和接口。
元件的記號與UML1.x中規定的有所不同。UML2.0規范規定在邊角處有一個元件框圖標或老套的“元件”字樣。元件與子系統的關系在UML2.0中也得到了澄清。子系統通常比元件“大”，并且可以包含元件。如果愿意，你可以在元件盒(componentbox，)的“artifacts”段指定元件或子系統，例如包含執行代碼的文件。
狀態框圖的繼承
對于“reactive”或“stateful”類(也就是具有狀態框圖的類)，人們自然希望該類的子類也能體現父輩的特征。UML1.x對此定義不清楚，但在UML2.0中，I-LOGIX采用的方法定義了“狀態框圖繼承”。
事繼承很有用的是“替代性”的概念。也就是說，一個子類的實例可以由超級類(superclass)來代替，而系統仍然有效并能正常工作。這里需要考慮對子類的繼承狀態框圖的操作準則。我們可以通過添加“加入新狀態”、“子狀態”、“與狀態(and-states)”、“轉換(transition)”和“動作(action)”進行擴展，并通過利用多形態方法重定位轉換和修改動作列表。但不能刪除轉換和狀態，或者重新指定狀態的父輩(增加擁有這個狀態的新的復合狀態)。
UML2.0完全建立在UML1.x基礎之上，大多數的UML1.x模型在UML2.0中都可用。但UML2.0在結構建模方面有一系列重大的改進，包括結構類、精確的接口和端口、拓展性、交互片斷和操作符以及基于時間建模能力的增強。當然還有時序框圖，但如果你不使用這些功能，也就不用擔心這些特性，因為僅使用類框圖、順序框圖和狀態框圖仍可建立非常復雜的實時嵌入式系統。
【編輯推薦】
