一個順序圖的消息流開始于左上方，消息乙的位置比消息甲低，這意味著消息乙的順序比消息乙要遲。因為西方的閱讀習慣是從左到右，你應該盡量按照和描述消息流一樣的方式，從左至右排列分類器（角色、類、對象，和用例）。 在圖１中你可以看到分類器已經按照這種方式排列好了，如果Seminar對象在controller的左邊，那排列方式就不是標準的了。 注意有時候消息流從左到右的排列是不可能的，例如一對對象彼此調用操作的情形。
將分類器分層
分層是一個通用的面向對象設計的方法，系統通常來說，總是組織成user interface、process/controller、business、persistence、和system層( Ambler 2001)。 當系統是以這種方式設計的時候，通常會加強同屬于一層的分類器合作，而降低不同層的分類器的耦合度。 因此按類似的方式對你的順序圖進行分層是有意義的。 就這個使用情境的例子來說，一種分層的方法就是先注明人類角色，然后是表示情境的邏輯的controller類，然后是user interface類，接著是business類，最后是相關的技術類，它封裝了對數據庫和系統資源的訪問。 以這種方式對你的順序圖分層，會使得順序圖更容易閱讀，也更容易發現分層的邏輯問題。 圖１就采取這種方法。
圖⒈一次學生的注冊。
用和你的用例圖一致的名稱命名角色。
當你在對一個使用情境建模時，你的順序圖一般會涉及一個或多個角色。 為了保持一致性，顯示在順序圖中的角色的名稱應該和用例圖上的相同。
用和你的類圖一致的名稱命名類。
順序圖中的類和類圖中的類是相同的，因此它們應該有相同的名稱。
一個角色的名稱可以和類的名稱相同。
在圖１你可以看到一個命名為學生的角色和一個命名為學生的類。 這樣做是合理的，因為這兩個分類器表示兩個不同的概念，角色表示在現實中的學生，而類則表示你正在構建的商業應用程序中的學生。
包含一個邏輯的敘述性描述。
圖１可以很難理解－－特別是對于不熟悉閱讀順序圖人來說－－因為它是很接近于實際的源程序。 在你模型中包含一個業務邏輯的描述是很常見的，特別當該順序圖描述一個使用情境時，就像在在圖⒉的左邊看到的，這可以增加圖的可理解性，并且Rosenberg和Scott（1999）指出，這也為跟蹤用例和順序圖間的信息提供了重要的信息。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
