圖⒉在線定單付款。
在圖的最左邊放置人和組織角色。
對業務應用軟件來說，在大多數的中，主要的角色是一個人或一個組織。這些角色經常是該情境的發起人，同時也是順序圖的閱讀焦點，因此它們應該放在模型的"可看見的開始之處"。
在圖的最右邊放置反應系統角色。
反應系統角色是那些你與之交互的系統，應該放在圖的最右邊。因為在許多的業務應用軟件中，這些角色經常被當做" backend entities "，也就是那些你的系統通過存取技術交互的系統，例如C APIs、CORBA IDL、消息隊列、或web service。 換句話說，把后端的系統放在圖最后的位置。
在圖的最左邊放置系統角色。
先導系統角色是那些與你的系統交互的系統，根據力爭從左到右排列消息和分類器層的原則，應該放在圖的最左邊。
避免建模對象Destruction
雖然內存管理是很重要的的問題，特別是對象在適當的時候的銷毀，許多建模者不愿意在順序圖上建模對象的銷毀操作，而是在activation條（就是表示對象生命周期的那個豎條）的底部使用一個"Ｘ"符號，或使用一個帶<<destroy>>版型的消息。 比較圖１和圖２，注意圖1中引入了對象的銷毀，沒帶來明顯的好處，卻弄亂了圖的布局。而圖２則沒有注明對象銷毀。 記住遵循敏捷建模( AM)的實踐簡單的描述模型。
這項指南的意義在于兩個理由∶ 首先，很多種語言都擁有稱作垃圾收集的技術，實現自動的內存管理，例如Java和Smalltalk。 其次，在那些你需要明確的管理內存的語言中，例如C++，你的程序員一般地都能夠了解該怎么做，并不需要模型中的這些附加信息。
注意在實時系統中，內存管理通常是一個關鍵性問題，你可能需要建模對象的銷毀操作。
分類器的原則
注意∶分類器命名規則的在別處描述。 其中，類和接口的命名規則在UML類圖的風格指南中描述，用例的命名規則在UML用例圖的風格指南中描述，而組件的命名規則在UML組件圖的風格指南中描述。
當你在消息上引用對象時要命名他們。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
