一个顺序图的消息流开始于左上方，消息乙的位置比消息甲低，这意味着消息乙的顺序比消息乙要迟。因为西方的阅读习惯是从左到右，你应该尽量按照和描述消息流一样的方式，从左至右排列分类器（角色、类、对象，和用例）。 在图１中你可以看到分类器已经按照这种方式排列好了，如果Seminar对象在controller的左边，那排列方式就不是标准的了。 注意有时候消息流从左到右的排列是不可能的，例如一对对象彼此调用操作的情形。
将分类器分层
分层是一个通用的面向对象设计的方法，系统通常来说，总是组织成user interface、process/controller、business、persistence、和system层( Ambler 2001)。 当系统是以这种方式设计的时候，通常会加强同属于一层的分类器合作，而降低不同层的分类器的耦合度。 因此按类似的方式对你的顺序图进行分层是有意义的。 就这个使用情境的例子来说，一种分层的方法就是先注明人类角色，然后是表示情境的逻辑的controller类，然后是user interface类，接着是business类，最后是相关的技术类，它封装了对数据库和系统资源的访问。 以这种方式对你的顺序图分层，会使得顺序图更容易阅读，也更容易发现分层的逻辑问题。 图１就采取这种方法。
图⒈一次学生的注册。
用和你的用例图一致的名称命名角色。
当你在对一个使用情境建模时，你的顺序图一般会涉及一个或多个角色。 为了保持一致性，显示在顺序图中的角色的名称应该和用例图上的相同。
用和你的类图一致的名称命名类。
顺序图中的类和类图中的类是相同的，因此它们应该有相同的名称。
一个角色的名称可以和类的名称相同。
在图１你可以看到一个命名为学生的角色和一个命名为学生的类。 这样做是合理的，因为这两个分类器表示两个不同的概念，角色表示在现实中的学生，而类则表示你正在构建的商业应用程序中的学生。
包含一个逻辑的叙述性描述。
图１可以很难理解－－特别是对于不熟悉阅读顺序图人来说－－因为它是很接近于实际的源程序。 在你模型中包含一个业务逻辑的描述是很常见的，特别当该顺序图描述一个使用情境时，就像在在图⒉的左边看到的，这可以增加图的可理解性，并且Rosenberg和Scott（1999）指出，这也为跟踪用例和顺序图间的信息提供了重要的信息。
文章来源于领测软件测试网 https://www.ltesting.net/
