專家解析 UML順序圖如何使用
本節(jié)繼續(xù)向大家介紹UML順序圖，這里主要包括分類器的原則，消息的原則，對(duì)象以及參數(shù)等內(nèi)容，希望本節(jié)的學(xué)習(xí)能讓你對(duì)UML順序圖有深入的了解。下面是有關(guān)UML順序圖的具體介紹。
分類器的原則
注意∶分類器命名規(guī)則的在別處描述。其中，類和接口的命名規(guī)則在UML類圖的風(fēng)格指南中描述，用例的命名規(guī)則在UML用例圖的風(fēng)格指南中描述，而組件的命名規(guī)則在UML組件圖的風(fēng)格指南中描述。
當(dāng)你在消息上引用對(duì)象時(shí)要命名他們。
UML順序圖上的對(duì)象應(yīng)使用標(biāo)準(zhǔn)的UML格式"name:ClassName"來標(biāo)記，其中"name"可選的（擁有一個(gè)名稱的對(duì)象稱作已命名的對(duì)象，而那些沒有名稱的對(duì)象則被稱作匿名對(duì)象）。在圖１中，Student的實(shí)例以theStudent來命名，因?yàn)樗且粭l消息已引用返回值，然而SecurityLogon類的實(shí)例則不需要名稱，因?yàn)閳D的其它地方并沒有應(yīng)用它，因此它可以使匿名的。
當(dāng)存在部分相同的類型時(shí)需要命名對(duì)象。
當(dāng)一個(gè)UML順序圖包含幾個(gè)同樣類型的對(duì)象時(shí)，例如圖３存在兩個(gè)Account類的實(shí)例，你應(yīng)該為該類型的所有對(duì)象命名，以避免圖的意義含糊不清。
圖⒊在賬戶間轉(zhuǎn)帳。
一致地應(yīng)用文本版型。
表1總結(jié)了一些通用版型，你可以在UML順序圖的分類器上應(yīng)用它們。不要花過多的時(shí)間來爭論應(yīng)該使用哪個(gè)版型，例如<>和<>都是不錯(cuò)的版型，只要隨便選擇一個(gè)并保證一致性就好了。
表⒈通用的版型．
版型用法
<>在設(shè)計(jì)期間表示微軟的ActiveServerPage。
<>在設(shè)計(jì)期間用于注明一個(gè)組件。
<>用來注明一個(gè)控制器類，實(shí)現(xiàn)了和使用情境有關(guān)的業(yè)務(wù)邏輯，或包括幾個(gè)業(yè)務(wù)類的邏輯。
<>設(shè)計(jì)期間表示一個(gè)圖形用戶界面屏幕。
<>設(shè)計(jì)期間表示一個(gè)超文本頁。
<>設(shè)計(jì)期間表示一個(gè)Java接口
<>設(shè)計(jì)期間表示一個(gè)JavaServerPage。
<>設(shè)計(jì)期間表示一個(gè)打印的或電子的報(bào)告。
<>表示系統(tǒng)角色。
<>一個(gè)一般的用戶界面類。一般使用在分析級(jí)的圖上，此時(shí)你尚未決定使用何種的實(shí)現(xiàn)平臺(tái)。
少量地應(yīng)用可視化的版型。
在你的UML順序圖上應(yīng)用可視化的版型時(shí)完全正確的，就如同你在圖２和圖３所見的，但它并非一個(gè)十分通用的慣例，因此它可能會(huì)減少圖的可理解性。在圖２中，顧客是一個(gè)角色（使用與用例圖相同的符號(hào)），OrderCheckout是一個(gè)控制器類，CheckoutPage是一個(gè)用戶界面類，而Order是一個(gè)業(yè)務(wù)實(shí)體類。
注意，那些需要開發(fā)穩(wěn)定性較高的圖的團(tuán)隊(duì)會(huì)使用可視化的版型Rosenberg&Scott1999;Ambler2002)，就像在圖２描繪的可視化的版型一樣，因此對(duì)項(xiàng)目中的所有人都必須熟悉這些符號(hào)。
集中在關(guān)鍵的交互。
AM的實(shí)踐－－創(chuàng)建簡單內(nèi)容建議，當(dāng)創(chuàng)建一個(gè)模型時(shí)，你應(yīng)當(dāng)集中于系統(tǒng)的關(guān)鍵性特征，而不要包含無關(guān)的細(xì)節(jié)。因此，如果順序圖是探究業(yè)務(wù)邏輯的，你就不要包含對(duì)象和數(shù)據(jù)庫的具體交互，諸如save()和delete()的操作就已經(jīng)足夠了，你可以簡單地假定持久性已經(jīng)能夠處理，而不需要去理會(huì)細(xì)節(jié)。例如，在圖２中，你看不到從數(shù)據(jù)庫或?qū)ο缶彺嬷凶x取orders和orderitems的任何邏輯，只是他們會(huì)在適當(dāng)點(diǎn)發(fā)生而已。你也看不到CreditCardPayment類連接到payment處理器的邏輯，但這個(gè)邏輯是必定會(huì)發(fā)生的。只把注意力集中在和你正在建模的東西相關(guān)的關(guān)鍵性交互上，你可以在盡可能的保持圖的簡單的同時(shí)達(dá)到目的，不但提高了建模者的生產(chǎn)力，也增加了圖的可讀性。
消息的原則
注意∶操作符號(hào)的命名規(guī)則，和消息、參數(shù)、返回值的命名有關(guān)的原則都在UML類圖的風(fēng)格指南中描述。
把消息名放在箭頭旁邊。
大多數(shù)的建模者都會(huì)調(diào)整消息名，例如圖２中的calculateTotal()，因此消息名總是靠近箭頭的。一般我們認(rèn)為消息的接受者將會(huì)實(shí)現(xiàn)相應(yīng)的操作，因此把消息名放在離分類器接近的位置是有意義的。
注意，圖３并沒有遵循這些原則，所有的消息名都排列在接近發(fā)送者的地方。這種方法的優(yōu)點(diǎn)在于它很容易看出欲建模的情境的邏輯，而且，如果你使用了清楚的消息和參數(shù)名稱，那你也許可以不用遵循包含邏輯的敘述性描述的原則。而這種方法的缺點(diǎn)是很難判斷哪個(gè)操作是被圖右方的分類器所調(diào)用的。象往常一樣，選擇一種方法并一致的應(yīng)用它。
直接創(chuàng)建對(duì)象
在一個(gè)UML順序圖上注明對(duì)象的創(chuàng)建通常有兩種方法。首先，你可以用<>版型來發(fā)送一個(gè)消息，如同圖２如...中所示OrderCheckout所示的那樣。其次，你可以通過把圖中分類器位置下移，在其側(cè)面調(diào)用一個(gè)消息的方式直接的顯示創(chuàng)建，如你在圖１所見的theStudent和圖⒉的CreditCardPayment。直接方法的最主要的好處是它可以形象的表示出對(duì)象從無到有的邏輯。
為軟件消息使用操作符號(hào)。
當(dāng)一個(gè)消息被發(fā)給一個(gè)軟件實(shí)現(xiàn)的分類器時(shí)，例如類、接口、或組件。通用的準(zhǔn)則是使用實(shí)現(xiàn)語言的語法來描述消息名。例如，在圖３中，消息commit(transactionID)被發(fā)送給sourceaccount對(duì)象，它使用了類似于Java、C++、和C_#語言的語法。
為涉及人和組織角色的消息使用敘述性文字。
當(dāng)一條消息的來源或目標(biāo)人或組織的角色時(shí)，需要使用簡短的敘述性文字來描述傳達(dá)的信息、來標(biāo)記消息。例如，在圖１中，被student角色發(fā)送出的消息是providesname和providesstudentnumber，它們描述了這個(gè)人在做什么。
推薦使用參數(shù)名稱，而不是參數(shù)類型
注意在圖３中，大多數(shù)的消息都使用參數(shù)名稱來注明參數(shù)，而不是使用類型。唯一的例外是start()消息中傳遞的UserID參數(shù)。這可以使你正確地判定該消息傳遞了什么值，有時(shí)候類型信息是不夠的。例如，消息addDeposit(amount,target,transactionID)傳達(dá)的信息要比addDeposit(Currency,Account,int)多。
為參數(shù)占位符注明類型
有時(shí)參數(shù)傳遞的信息和你正在建模的信息并沒有什么關(guān)系，雖然這些信息對(duì)你而言非常的重要。在這種情況下就需要注明參數(shù)的類型，如圖３中的start(UserID)。
類的消息實(shí)現(xiàn)為靜態(tài)操作
當(dāng)一條消息被發(fā)給一個(gè)類時(shí)（類使用ClassName的格式標(biāo)記），我們需要在類的定義中增加一條相應(yīng)的靜態(tài)操作。例如，圖１描述了被發(fā)送給Seminar類的消息getAvailableSeminars()，因此該類的定義中應(yīng)該有一條靜態(tài)操作。如果這條消息被發(fā)給Seminar一個(gè)實(shí)例，那就應(yīng)該有一個(gè)相應(yīng)的實(shí)例操作。這是順序圖和類圖間的一項(xiàng)非常重要的一致性檢驗(yàn)，某些CASE工具可以自動(dòng)化實(shí)現(xiàn)。
為用例調(diào)用使用<>版型
圖３顯示了一個(gè)用例在UML順序圖中是如何經(jīng)由一個(gè)用<>版型標(biāo)記的消息被調(diào)用的，當(dāng)你在建模一個(gè)包含一個(gè)被直接調(diào)用的用例的使用情境時(shí)，就可以使用這個(gè)小技巧。
返回值的原則
當(dāng)返回值非常明顯時(shí)就不要對(duì)返回值建模。
返回值的顯示是使用帶返回值標(biāo)記的虛線箭頭，返回值是可選的。例如，圖１中返回值theStudent表示了對(duì)SecurityLogon類調(diào)用的消息的返回值，然而圖２中對(duì)order發(fā)送getTotal()消息就沒有返回值。在第一個(gè)例子中，創(chuàng)建一個(gè)securitylogon對(duì)象會(huì)產(chǎn)生一個(gè)student對(duì)象，這是不明顯的，然而向order要求一個(gè)小計(jì)的返回值是很明顯的。
只有當(dāng)你需要在別處引用返回值時(shí)才對(duì)返回值建模。
如果你需要在順序圖的另一處（一般是作為參數(shù)傳遞給另一個(gè)消息）引用返回值，那就需要在圖中著名返回值，這樣就能清楚的表明它的出處。
在箭頭旁邊調(diào)整返回值。
大多數(shù)的建模者都會(huì)把返回值放在靠近箭頭地方，例如圖２中的theStudent。一般我們認(rèn)為返回值的接受者將會(huì)使用返回值，因此把返回值放在靠近分類器的位置是有意義的。
返回值建模為方法調(diào)用的一部分。
不要使用虛線來弄亂UML順序圖，考慮在消息名上注明返回值來替代虛線。使用符號(hào)message(parameters):returnValue，圖２就使用了這種符號(hào)：reserve():AuthorizationCode。用這個(gè)方法，你只會(huì)有單條消息路線，而不會(huì)有一條消息路線和一條返回值路線。
為返回值占位符注明類型
有時(shí)返回值傳遞的信息和你的模型并沒有什么關(guān)系，盡管這些信息對(duì)你而言非常的重要。在這種情況下就需要注明參數(shù)的類型，如圖2中的reserve():AuthorizationCode。
明確的為簡單值標(biāo)明實(shí)際值
圖１中isValid()message返回了值yes，這就清楚的表明了該學(xué)生的名稱和編號(hào)是合法的。如果返回值命名為Boolean，就只是注明回應(yīng)的類型，如果命名為eligibilityIndicator，就只是注明了返回值的名稱，這樣就不夠明確了。
【編輯推薦】
