<<user interface>> 一個一般的用戶界面類。 一般使用在分析級的圖上，此時你尚未決定使用何種的實現平臺。
少量地應用可視化的版型。
在你的順序圖上應用可視化的版型時完全正確的，就如同你在圖２和圖３所見的，但它并非一個十分通用的慣例，因此它可能會減少圖的可理解性。 在圖２中，顧客是一個角色（使用與用例圖相同的符號），OrderCheckout是一個控制器類，CheckoutPage是一個用戶界面類，而Order是一個業務實體類。
注意，那些需要開發穩定性較高的圖的團隊會使用可視化的版型Rosenberg & Scott 1999; Ambler 2002)，就像在圖２描繪的可視化的版型一樣，因此對項目中的所有人都必須熟悉這些符號。
集中在關鍵的交互。
AM的實踐－－創建簡單內容建議，當創建一個模型時，你應當集中于系統的關鍵性特征，而不要包含無關的細節。 因此，如果順序圖是探究業務邏輯的，你就不要包含對象和數據庫的具體交互，諸如save ()和delete ()的操作就已經足夠了，你可以簡單地假定持久性已經能夠處理，而不需要去理會細節。 例如，在圖２中，你看不到從數據庫或對象緩存中讀取orders和order items的任何邏輯，只是他們會在適當點發生而已。 你也看不到CreditCardPayment類連接到payment處理器的邏輯，但這個邏輯是必定會發生的。 只把注意力集中在和你正在建模的東西相關的關鍵性交互上，你可以在盡可能的保持圖的簡單的同時達到目的，不但提高了建模者的生產力，也增加了圖的可讀性。
消息的原則
注意∶操作符號的命名規則，和消息、參數、返回值的命名有關的原則都在UML類圖的風格指南中描述。
把消息名放在箭頭旁邊。
大多數的建模者都會調整消息名，例如圖２中的calculateTotal ()，因此消息名總是靠近箭頭的。 一般我們認為消息的接受者將會實現相應的操作，因此把消息名放在離分類器接近的位置是有意義的。
注意，圖３并沒有遵循這些原則，所有的消息名都排列在接近發送者的地方。 這種方法的優點在于它很容易看出欲建模的情境的邏輯，而且，如果你使用了清楚的消息和參數名稱，那你也許可以不用遵循包含邏輯的敘述性描述的原則。而這種方法的缺點是很難判斷哪個操作是被圖右方的分類器所調用的。 象往常一樣，選擇一種方法并一致的應用它。
直接創建對象
在一個順序圖上注明對象的創建通常有兩種方法。 首先，你可以用<<create>>版型來發送一個消息，如同圖２如...中所示OrderCheckout所示的那樣。 其次，你可以通過把圖中分類器位置下移，在其側面調用一個消息的方式直接的顯示創建，如你在圖１所見的theStudent和圖⒉的CreditCardPayment。直接方法的最主要的好處是它可以形象的表示出對象從無到有的邏輯。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
