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