UML建模風格之順序圖
LinuxAid.com.cn axing譯
2002-06-20
和合作圖、活動圖一樣，UML順序圖(
Rumbaugh、Jacobson、和booch, 1999)是一種動態建模方法。 UML順序圖一般用于：
確認和豐富一個使用情境的邏輯。
一個使用情境就是系統潛在的使用方式的描述，也就是它的名稱所要描述的。
一個使用情境的邏輯可能是一個用例的一部分，或是一條備選線路；一個貫穿單個用例的完整流程，例如動作基本過程的邏輯描述，或是動作的基本過程的一部分再加上一個或多個的備用情境的邏輯描述�；蚴前趲讉�用例中的流程，例如一個學生注冊入學之后，立即就要在三個班級注冊。
研究你的設計，因為它們為你提供了一種方式，你可以使用這種方式來可視化的調用類定義的操作。
檢測面向對象的設計中的瓶頸。
通過觀察什么消息被發送給一個對象，以及通過概略的觀察運行被調用的方法需要花費多長時間，你很快就能了解那里的設計需要變化，以達到在系統內部平衡負荷的目的。
實際上某些CASE工具甚至能夠讓你模擬軟件這些特征。
使你能夠感覺到你的應用程序的那個類將會變得復雜的，這是個信號，意味著你需要為那些類畫狀態圖了。
指南∶
通用準則
盡力保持消息的順序從左到右排列。
將分類器分層
用和你的用例圖一致的名稱命名角色。
用和你的類圖一致的名稱命名類。
一個角色的名稱可以和類的名稱相同。
包含一個邏輯的敘述性描述。
在圖的最左邊放置初始的角色。
在圖的最左邊放置人和組織角色。
在圖的最右邊放置系統角色。
只在合適的時候才建模對象的Destruction。
類的原則
當你在消息上引用對象時要命名他們。
當存在部分相同的類型時需要命名對象。
一致地應用文本版型。
少量地應用可視化的版型。
集中在關鍵的交互。
消息的原則
把消息名放在箭頭旁邊。
直接創建對象
為軟件消息使用操作符號。
為涉及人和組織角色的消息使用敘述性文字。
推薦使用參數名稱，而不是參數類型
為參數占位符注明類型
類的消息實現為靜態操作
為用例調用使用<<include>>版型
返回值的原則
當返回值非常明顯時就不要對返回值建模。
只有當你需要在別處引用返回值時才對返回值建模。
在箭頭旁邊調整返回值。
返回值建模為方法調用的一部分。
為返回值占位符注明類型
明確的為簡單值標明實際值
通用準則
盡力保持消息的順序是從左到右排列的。
一個順序圖的消息流開始于左上方，消息乙的位置比消息甲低，這意味著消息乙的順序比消息乙要遲。因為西方的閱讀習慣是從左到右，你應該盡量按照和描述消息流一樣的方式，從左至右排列分類器（角色、類、對象，和用例）。
在圖１中你可以看到分類器已經按照這種方式排列好了，如果Seminar對象在controller的左邊，那排列方式就不是標準的了。
注意有時候消息流從左到右的排列是不可能的，例如一對對象彼此調用操作的情形。
將分類器分層
分層是一個通用的面向對象設計的方法，系統通常來說，總是組織成user
interface、process/controller、business、persistence、和system層(
Ambler 2001)。
當系統是以這種方式設計的時候，通常會加強同屬于一層的分類器合作，而降低不同層的分類器的耦合度。
因此按類似的方式對你的順序圖進行分層是有意義的。
就這個使用情境的例子來說，一種分層的方法就是先注明人類角色，然后是表示情境的邏輯的controller類，然后是user
interface類，接著是business類，最后是相關的技術類，它封裝了對數據庫和系統資源的訪問。
以這種方式對你的順序圖分層，會使得順序圖更容易閱讀，也更容易發現分層的邏輯問題。
圖１就采取這種方法。
圖⒈一次學生的注冊。
用和你的用例圖一致的名稱命名角色。
當你在對一個使用情境建模時，你的順序圖一般會涉及一個或多個角色。 為了保持一致性，顯示在順序圖中的角色的名稱應該和用例圖上的相同。
用和你的類圖一致的名稱命名類。
順序圖中的類和類圖中的類是相同的，因此它們應該有相同的名稱。
一個角色的名稱可以和類的名稱相同。
在圖１你可以看到一個命名為學生的角色和一個命名為學生的類。 這樣做是合理的，因為這兩個分類器表示兩個不同的概念，角色表示在現實中的學生，而類則表示你正在構建的商業應用程序中的學生。
包含一個邏輯的敘述性描述。
圖１可以很難理解－－特別是對于不熟悉閱讀順序圖人來說－－因為它是很接近于實際的源程序。 在你模型中包含一個業務邏輯的描述是很常見的，特別當該順序圖描述一個使用情境時，就像在在圖⒉的左邊看到的，這可以增加圖的可理解性，并且Rosenberg和Scott（1999）指出，這也為跟蹤用例和順序圖間的信息提供了重要的信息。
圖⒉在線定單付款。
在圖的最左邊放置人和組織角色。
對業務應用軟件來說，在大多數的中，主要的角色是一個人或一個組織。這些角色經常是該情境的發起人，同時也是順序圖的閱讀焦點，因此它們應該放在模型的"可看見的開始之處"。
在圖的最右邊放置反應系統角色。
反應系統角色是那些你與之交互的系統，應該放在圖的最右邊。因為在許多的業務應用軟件中，這些角色經常被當做" backend entities "，也就是那些你的系統通過存取技術交互的系統，例如C APIs、CORBA IDL、消息隊列、或web service。 換句話說，把后端的系統放在圖最后的位置。
在圖的最左邊放置系統角色。
先導系統角色是那些與你的系統交互的系統，根據力爭從左到右排列消息和分類器層的原則，應該放在圖的最左邊。
避免建模對象Destruction
雖然內存管理是很重要的的問題，特別是對象在適當的時候的銷毀，許多建模者不愿意在順序圖上建模對象的銷毀操作，而是在activation條（就是表示對象生命周期的那個豎條）的底部使用一個"Ｘ"符號，或使用一個帶<<destroy>>版型的消息。 比較圖１和圖２，注意圖1中引入了對象的銷毀，沒帶來明顯的好處，卻弄亂了圖的布局。而圖２則沒有注明對象銷毀。 記住遵循敏捷建模( AM)的實踐簡單的描述模型。
這項指南的意義在于兩個理由∶ 首先，很多種語言都擁有稱作垃圾收集的技術，實現自動的內存管理，例如Java和Smalltalk。 其次，在那些你需要明確的管理內存的語言中，例如C++，你的程序員一般地都能夠了解該怎么做，并不需要模型中的這些附加信息。
注意在實時系統中，內存管理通常是一個關鍵性問題，你可能需要建模對象的銷毀操作。
分類器的原則
注意∶分類器命名規則的在別處描述。 其中，類和接口的命名規則在UML類圖的風格指南中描述，用例的命名規則在UML用例圖的風格指南中描述，而組件的命名規則在UML組件圖的風格指南中描述。
當你在消息上引用對象時要命名他們。
順序圖上的對象應使用標準的UML格式" name: ClassName "來標記，其中" name "可選的（擁有一個名稱的對象稱作已命名的對象，而那些沒有名稱的對象則被稱作匿名對象）。在圖１中，Student的實例以theStudent來命名，因為它是一條消息已引用返回值，然而SecurityLogon類的實例則不需要名稱，因為圖的其它地方并沒有應用它，因此它可以使匿名的。
當存在部分相同的類型時需要命名對象。
當一個順序圖包含幾個同樣類型的對象時，例如圖３存在兩個Account類的實例，你應該為該類型的所有對象命名，以避免圖的意義含糊不清。
圖⒊在賬戶間轉帳。
一致地應用文本版型。
表1總結了一些通用版型，你可以在順序圖的分類器上應用它們。 不要花過多的時間來爭論應該使用哪個版型，例如<<JSP>>和<<Java Server Page>>都是不錯的版型，只要隨便選擇一個并保證一致性就好了。
表⒈通用的版型．
版型 用法
<<ASP>> 在設計期間表示微軟的Active Server Page。
<<component>> 在設計期間用于注明一個組件。
<<controller>> 用來注明一個控制器類，實現了和使用情境有關的業務邏輯，或包括幾個業務類的邏輯。
<<GUI>> 設計期間表示一個圖形用戶界面屏幕。
<<HTML>> 設計期間表示一個超文本頁。
<<interface>> 設計期間表示一個Java接口
<<JSP>> 設計期間表示一個Java Server Page。
<<report>> 設計期間表示一個打印的或電子的報告。
<<system>> 表示系統角色。
<<user interface>> 一個一般的用戶界面類。 一般使用在分析級的圖上，此時你尚未決定使用何種的實現平臺。
少量地應用可視化的版型。
在你的順序圖上應用可視化的版型時完全正確的，就如同你在圖２和圖３所見的，但它并非一個十分通用的慣例，因此它可能會減少圖的可理解性。 在圖２中，顧客是一個角色（使用與用例圖相同的符號），OrderCheckout是一個控制器類，CheckoutPage是一個用戶界面類，而Order是一個業務實體類。
注意，那些需要開發穩定性較高的圖的團隊會使用可視化的版型Rosenberg & Scott 1999; Ambler 2002)，就像在圖２描繪的可視化的版型一樣，因此對項目中的所有人都必須熟悉這些符號。
集中在關鍵的交互。
AM的實踐－－創建簡單內容建議，當創建一個模型時，你應當集中于系統的關鍵性特征，而不要包含無關的細節。 因此，如果順序圖是探究業務邏輯的，你就不要包含對象和數據庫的具體交互，諸如save ()和delete ()的操作就已經足夠了，你可以簡單地假定持久性已經能夠處理，而不需要去理會細節。 例如，在圖２中，你看不到從數據庫或對象緩存中讀取orders和order items的任何邏輯，只是他們會在適當點發生而已。 你也看不到CreditCardPayment類連接到payment處理器的邏輯，但這個邏輯是必定會發生的。 只把注意力集中在和你正在建模的東西相關的關鍵性交互上，你可以在盡可能的保持圖的簡單的同時達到目的，不但提高了建模者的生產力，也增加了圖的可讀性。
消息的原則
注意∶操作符號的命名規則，和消息、參數、返回值的命名有關的原則都在UML類圖的風格指南中描述。
把消息名放在箭頭旁邊。
大多數的建模者都會調整消息名，例如圖２中的calculateTotal ()，因此消息名總是靠近箭頭的。 一般我們認為消息的接受者將會實現相應的操作，因此把消息名放在離分類器接近的位置是有意義的。
注意，圖３并沒有遵循這些原則，所有的消息名都排列在接近發送者的地方。 這種方法的優點在于它很容易看出欲建模的情境的邏輯，而且，如果你使用了清楚的消息和參數名稱，那你也許可以不用遵循包含邏輯的敘述性描述的原則。而這種方法的缺點是很難判斷哪個操作是被圖右方的分類器所調用的。 象往常一樣，選擇一種方法并一致的應用它。
直接創建對象
在一個順序圖上注明對象的創建通常有兩種方法。 首先，你可以用<<create>>版型來發送一個消息，如同圖２如...中所示OrderCheckout所示的那樣。 其次，你可以通過把圖中分類器位置下移，在其側面調用一個消息的方式直接的顯示創建，如你在圖１所見的theStudent和圖⒉的CreditCardPayment。直接方法的最主要的好處是它可以形象的表示出對象從無到有的邏輯。
為軟件消息使用操作符號。
當一個消息被發給一個軟件實現的分類器時，例如類、接口、或組件。通用的準則是使用實現語言的語法來描述消息名。 例如，在圖３中，消息commit ( transactionID)被發送給source account對象，它使用了類似于Java、C++、和C_#語言的語法。
為涉及人和組織角色的消息使用敘述性文字。
當一條消息的來源或目標人或組織的角色時，需要使用簡短的敘述性文字來描述傳達的信息、來標記消息。 例如，在圖１中，被student角色發送出的消息是provides name和provides student number，它們描述了這個人在做什么。
推薦使用參數名稱，而不是參數類型
注意在圖３中，大多數的消息都使用參數名稱來注明參數，而不是使用類型。唯一的例外是start ()消息中傳遞的UserID參數。 這可以使你正確地判定該消息傳遞了什么值，有時候類型信息是不夠的。 例如，消息addDeposit ( amount, target, transactionID)傳達的信息要比addDeposit ( Currency, Account, int)多。
為參數占位符注明類型
有時參數傳遞的信息和你正在建模的信息并沒有什么關系，雖然這些信息對你而言非常的重要。 在這種情況下就需要注明參數的類型，如圖３中的start ( UserID)。
類的消息實現為靜態操作
當一條消息被發給一個類時（類使用ClassName的格式標記），我們需要在類的定義中增加一條相應的靜態操作。 例如，圖１描述了被發送給Seminar類的消息getAvailableSeminars ()，因此該類的定義中應該有一條靜態操作。 如果這條消息被發給Seminar一個實例，那就應該有一個相應的實例操作。 這是順序圖和類圖間的一項非常重要的一致性檢驗，某些CASE工具可以自動化實現。
為用例調用使用<<include>>版型
圖３顯示了一個用例在順序圖中是如何經由一個用<<include>>版型標記的消息被調用的，當你在建模一個包含一個被直接調用的用例的使用情境時，就可以使用這個小技巧。
返回值的原則
當返回值非常明顯時就不要對返回值建模。
返回值的顯示是使用帶返回值標記的虛線箭頭，返回值是可選的。 例如，圖１中返回值theStudent表示了對SecurityLogon類調用的消息的返回值，然而圖２中對order發送getTotal ()消息就沒有返回值。 在第一個例子中，創建一個security logon對象會產生一個student對象，這是不明顯的，然而向order要求一個小計的返回值是很明顯的。
只有當你需要在別處引用返回值時才對返回值建模。
如果你需要在順序圖的另一處（一般是作為參數傳遞給另一個消息）引用返回值，那就需要在圖中著名返回值，這樣就能清楚的表明它的出處。
在箭頭旁邊調整返回值。
大多數的建模者都會把返回值放在靠近箭頭地方，例如圖２中的theStudent。 一般我們認為返回值的接受者將會使用返回值，因此把返回值放在靠近分類器的位置是有意義的。
返回值建模為方法調用的一部分。
不要使用虛線來弄亂順序圖，考慮在消息名上注明返回值來替代虛線。使用符號message ( parameters) : returnValue，圖２就使用了這種符號：reserve () : AuthorizationCode。用這個方法，你只會有單條消息路線，而不會有一條消息路線和一條返回值路線。
為返回值占位符注明類型
有時返回值傳遞的信息和你的模型并沒有什么關系，盡管這些信息對你而言非常的重要。 在這種情況下就需要注明參數的類型，如圖2中的reserve () : AuthorizationCode。
明確的為簡單值標明實際值
圖１中isValid () message返回了值yes，這就清楚的表明了該學生的名稱和編號是合法的。如果返回值命名為Boolean，就只是注明回應的類型，如果命名為eligibilityIndicator，就只是注明了返回值的名稱，這樣就不夠明確了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
版權所有(C) 2003－2010 TestAge（領測軟件測試網）|領測國際科技（北京）有限公司|軟件測試工程師培訓網 All Rights Reserved
北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
技術支持和業務聯系：info@testage.com.cn 電話：010-51297073
老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月