<<user interface>> 一个一般的用户界面类。 一般使用在分析级的图上，此时你尚未决定使用何种的实现平台。
少量地应用可视化的版型。
在你的顺序图上应用可视化的版型时完全正确的，就如同你在图２和图３所见的，但它并非一个十分通用的惯例，因此它可能会减少图的可理解性。 在图２中，顾客是一个角色（使用与用例图相同的符号），OrderCheckout是一个控制器类，CheckoutPage是一个用户界面类，而Order是一个业务实体类。
注意，那些需要开发稳定性较高的图的团队会使用可视化的版型Rosenberg & Scott 1999; Ambler 2002)，就像在图２描绘的可视化的版型一样，因此对项目中的所有人都必须熟悉这些符号。
集中在关键的交互。
AM的实践－－创建简单内容建议，当创建一个模型时，你应当集中于系统的关键性特征，而不要包含无关的细节。 因此，如果顺序图是探究业务逻辑的，你就不要包含对象和数据库的具体交互，诸如save ()和delete ()的操作就已经足够了，你可以简单地假定持久性已经能够处理，而不需要去理会细节。 例如，在图２中，你看不到从数据库或对象缓存中读取orders和order items的任何逻辑，只是他们会在适当点发生而已。 你也看不到CreditCardPayment类连接到payment处理器的逻辑，但这个逻辑是必定会发生的。 只把注意力集中在和你正在建模的东西相关的关键性交互上，你可以在尽可能的保持图的简单的同时达到目的，不但提高了建模者的生产力，也增加了图的可读性。
消息的原则
注意∶操作符号的命名规则，和消息、参数、返回值的命名有关的原则都在UML类图的风格指南中描述。
把消息名放在箭头旁边。
大多数的建模者都会调整消息名，例如图２中的calculateTotal ()，因此消息名总是靠近箭头的。 一般我们认为消息的接受者将会实现相应的操作，因此把消息名放在离分类器接近的位置是有意义的。
注意，图３并没有遵循这些原则，所有的消息名都排列在接近发送者的地方。 这种方法的优点在于它很容易看出欲建模的情境的逻辑，而且，如果你使用了清楚的消息和参数名称，那你也许可以不用遵循包含逻辑的叙述性描述的原则。而这种方法的缺点是很难判断哪个操作是被图右方的分类器所调用的。 象往常一样，选择一种方法并一致的应用它。
直接创建对象
在一个顺序图上注明对象的创建通常有两种方法。 首先，你可以用<<create>>版型来发送一个消息，如同图２如...中所示OrderCheckout所示的那样。 其次，你可以通过把图中分类器位置下移，在其侧面调用一个消息的方式直接的显示创建，如你在图１所见的theStudent和图⒉的CreditCardPayment。直接方法的最主要的好处是它可以形象的表示出对象从无到有的逻辑。
文章来源于领测软件测试网 https://www.ltesting.net/
