術(shù)語(yǔ)匯編 UML順序圖簡(jiǎn)介
本節(jié)向大家介紹一下UML順序圖，和合作圖、活動(dòng)圖一樣，UML順序圖是一種動(dòng)態(tài)建模方法，那么它有什么特別之處呢，通過(guò)本節(jié)的介紹你就會(huì)知曉，下面讓我們一起來(lái)看一下有關(guān)UML順序圖的詳細(xì)介紹吧。
UML建模風(fēng)格之UML順序圖
和合作圖、活動(dòng)圖一樣，UML順序圖(Rumbaugh、Jacobson、和booch,1999)是一種動(dòng)態(tài)建模方法。UML順序圖一般用于：確認(rèn)和豐富一個(gè)使用情境的邏輯。一個(gè)使用情境就是系統(tǒng)潛在的使用方式的描述，也就是它的名稱(chēng)所要描述的。一個(gè)使用情境的邏輯可能是一個(gè)用例的一部分，或是一條備選線路；一個(gè)貫穿單個(gè)用例的完整流程，例如動(dòng)作基本過(guò)程的邏輯描述，或是動(dòng)作的基本過(guò)程的一部分再加上一個(gè)或多個(gè)的備用情境的邏輯描述。或是包含在幾個(gè)用例中的流程，例如一個(gè)學(xué)生注冊(cè)入學(xué)之后，立即就要在三個(gè)班級(jí)注冊(cè)。
研究你的設(shè)計(jì)，因?yàn)樗鼈優(yōu)槟闾峁┝艘环N方式，你可以使用這種方式來(lái)可視化的調(diào)用類(lèi)定義的操作。檢測(cè)面向?qū)ο蟮脑O(shè)計(jì)中的瓶頸。通過(guò)觀察什么消息被發(fā)送給一個(gè)對(duì)象，以及通過(guò)概略的觀察運(yùn)行被調(diào)用的方法需要花費(fèi)多長(zhǎng)時(shí)間，你很快就能了解那里的設(shè)計(jì)需要變化，以達(dá)到在系統(tǒng)內(nèi)部平衡負(fù)荷的目的。實(shí)際上某些CASE工具甚至能夠讓你模擬軟件這些特征。
使你能夠感覺(jué)到你的應(yīng)用程序的那個(gè)類(lèi)將會(huì)變得復(fù)雜的，這是個(gè)信號(hào)，意味著你需要為那些類(lèi)畫(huà)狀態(tài)圖了。
通用準(zhǔn)則
盡力保持消息的順序是從左到右排列的。
一個(gè)UML順序圖的消息流開(kāi)始于左上方，消息乙的位置比消息甲低，這意味著消息乙的順序比消息乙要遲。因?yàn)槲鞣降拈喿x習(xí)慣是從左到右，你應(yīng)該盡量按照和描述消息流一樣的方式，從左至右排列分類(lèi)器（角色、類(lèi)、對(duì)象，和用例）。在圖１中你可以看到分類(lèi)器已經(jīng)按照這種方式排列好了，如果Seminar對(duì)象在controller的左邊，那排列方式就不是標(biāo)準(zhǔn)的了。注意有時(shí)候消息流從左到右的排列是不可能的，例如一對(duì)對(duì)象彼此調(diào)用操作的情形。
將分類(lèi)器分層
分層是一個(gè)通用的面向?qū)ο笤O(shè)計(jì)的方法，系統(tǒng)通常來(lái)說(shuō)，總是組織成userinterface、process/controller、business、persistence、和system層(Ambler2001)。當(dāng)系統(tǒng)是以這種方式設(shè)計(jì)的時(shí)候，通常會(huì)加強(qiáng)同屬于一層的分類(lèi)器合作，而降低不同層的分類(lèi)器的耦合度。因此按類(lèi)似的方式對(duì)你的順序圖進(jìn)行分層是有意義的。就這個(gè)使用情境的例子來(lái)說(shuō)，一種分層的方法就是先注明人類(lèi)角色，然后是表示情境的邏輯的controller類(lèi)，然后是userinterface類(lèi)，接著是business類(lèi)，***是相關(guān)的技術(shù)類(lèi)，它封裝了對(duì)數(shù)據(jù)庫(kù)和系統(tǒng)資源的訪問(wèn)。以這種方式對(duì)你的順序圖分層，會(huì)使得順序圖更容易閱讀，也更容易發(fā)現(xiàn)分層的邏輯問(wèn)題。圖１就采取這種方法。
圖⒈一次學(xué)生的注冊(cè)。
用和你的用例圖一致的名稱(chēng)命名角色。
當(dāng)你在對(duì)一個(gè)使用情境建模時(shí)，你的順序圖一般會(huì)涉及一個(gè)或多個(gè)角色。為了保持一致性，顯示在順序圖中的角色的名稱(chēng)應(yīng)該和用例圖上的相同。
用和你的類(lèi)圖一致的名稱(chēng)命名類(lèi)。UML順序圖中的類(lèi)和類(lèi)圖中的類(lèi)是相同的，因此它們應(yīng)該有相同的名稱(chēng)。
一個(gè)角色的名稱(chēng)可以和類(lèi)的名稱(chēng)相同。
在圖１你可以看到一個(gè)命名為學(xué)生的角色和一個(gè)命名為學(xué)生的類(lèi)。這樣做是合理的，因?yàn)檫@兩個(gè)分類(lèi)器表示兩個(gè)不同的概念，角色表示在現(xiàn)實(shí)中的學(xué)生，而類(lèi)則表示你正在構(gòu)建的商業(yè)應(yīng)用程序中的學(xué)生。
包含一個(gè)邏輯的敘述性描述。
圖１可以很難理解－－特別是對(duì)于不熟悉閱讀UML順序圖人來(lái)說(shuō)－－因?yàn)樗呛芙咏趯?shí)際的源程序。在你模型中包含一個(gè)業(yè)務(wù)邏輯的描述是很常見(jiàn)的，特別當(dāng)該順序圖描述一個(gè)使用情境時(shí)，就像在在圖⒉的左邊看到的，這可以增加圖的可理解性，并且Rosenberg和Scott（1999）指出，這也為跟蹤用例和順序圖間的信息提供了重要的信息。
圖⒉在線定單付款。
在圖的最左邊放置人和組織角色。
對(duì)業(yè)務(wù)應(yīng)用軟件來(lái)說(shuō)，在大多數(shù)的中，主要的角色是一個(gè)人或一個(gè)組織。這些角色經(jīng)常是該情境的發(fā)起人，同時(shí)也是UML順序圖的閱讀焦點(diǎn)，因此它們應(yīng)該放在模型的"可看見(jiàn)的開(kāi)始之處"。
在圖的最右邊放置反應(yīng)系統(tǒng)角色。
反應(yīng)系統(tǒng)角色是那些你與之交互的系統(tǒng)，應(yīng)該放在圖的最右邊。因?yàn)樵谠S多的業(yè)務(wù)應(yīng)用軟件中，這些角色經(jīng)常被當(dāng)做"backendentities"，也就是那些你的系統(tǒng)通過(guò)存取技術(shù)交互的系統(tǒng)，例如CAPIs、CORBAIDL、消息隊(duì)列、或webservice。換句話說(shuō)，把后端的系統(tǒng)放在圖***的位置。
在圖的最左邊放置系統(tǒng)角色。
先導(dǎo)系統(tǒng)角色是那些與你的系統(tǒng)交互的系統(tǒng)，根據(jù)力爭(zhēng)從左到右排列消息和分類(lèi)器層的原則，應(yīng)該放在圖的最左邊。
避免建模對(duì)象Destruction
雖然內(nèi)存管理是很重要的的問(wèn)題，特別是對(duì)象在適當(dāng)?shù)臅r(shí)候的銷(xiāo)毀，許多建模者不愿意在UML順序圖上建模對(duì)象的銷(xiāo)毀操作，而是在activation條（就是表示對(duì)象生命周期的那個(gè)豎條）的底部使用一個(gè)"Ｘ"符號(hào)，或使用一個(gè)帶<>版型的消息。比較圖１和圖２，注意圖1中引入了對(duì)象的銷(xiāo)毀，沒(méi)帶來(lái)明顯的好處，卻弄亂了圖的布局。而圖２則沒(méi)有注明對(duì)象銷(xiāo)毀。記住遵循敏捷建模(AM)的實(shí)踐簡(jiǎn)單的描述模型。
這項(xiàng)指南的意義在于兩個(gè)理由∶首先，很多種語(yǔ)言都擁有稱(chēng)作垃圾收集的技術(shù)，實(shí)現(xiàn)自動(dòng)的內(nèi)存管理，例如Java和Smalltalk。其次，在那些你需要明確的管理內(nèi)存的語(yǔ)言中，例如C++，你的程序員一般地都能夠了解該怎么做，并不需要模型中的這些附加信息。注意在實(shí)時(shí)系統(tǒng)中，內(nèi)存管理通常是一個(gè)關(guān)鍵性問(wèn)題，你可能需要建模對(duì)象的銷(xiāo)毀操作。請(qǐng)期待下節(jié)有關(guān)UML順序圖的介紹。
【編輯推薦】
