UML建模风格之顺序图

和合作图、活动图一样，UML顺序图( Rumbaugh、Jacobson、和booch, 1999)是一种动态建模方法。 UML顺序图一般用于：确认和丰富一个使用情境的逻辑。一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。或是包含在几个用例中的流程，例如一个学生注册入学之后，立即就要在三个班级注册。

研究你的设计，因为它们为你提供了一种方式，你可以使用这种方式来可视化的调用类定义的操作。检测面向对象的设计中的瓶颈。 通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，你很快就能了解那里的设计需要变化，以达到在系统内部平衡负荷的目的。 实际上某些CASE工具甚至能够让你模拟软件这些特征。
使你能够感觉到你的应用程序的那个类将会变得复杂的，这是个信号，意味着你需要为那些类画状态图了。
通用准则
尽力保持消息的顺序是从左到右排列的。
一个顺序图的消息流开始于左上方，消息乙的位置比消息甲低，这意味着消息乙的顺序比消息乙要迟。因为西方的阅读习惯是从左到右，你应该尽量按照和描述消息流一样的方式，从左至右排列分类器（角色、类、对象，和用例）。 在图１中你可以看到分类器已经按照这种方式排列好了，如果Seminar对象在controller的左边，那排列方式就不是标准的了。 注意有时候消息流从左到右的排列是不可能的，例如一对对象彼此调用操作的情形。
将分类器分层
分层是一个通用的面向对象设计的方法，系统通常来说，总是组织成user interface、process/controller、business、persistence、和system层( Ambler 2001)。 当系统是以这种方式设计的时候，通常会加强同属于一层的分类器合作，而降低不同层的分类器的耦合度。 因此按类似的方式对你的顺序图进行分层是有意义的。 就这个使用情境的例子来说，一种分层的方法就是先注明人类角色，然后是表示情境的逻辑的controller类，然后是user interface类，接着是business类，最后是相关的技术类，它封装了对数据库和系统资源的访问。 以这种方式对你的顺序图分层，会使得顺序图更容易阅读，也更容易发现分层的逻辑问题。 图１就采取这种方法。

图⒈一次学生的注册。

用和你的用例图一致的名称命名角色。
当你在对一个使用情境建模时，你的顺序图一般会涉及一个或多个角色。 为了保持一致性，显示在顺序图中的角色的名称应该和用例图上的相同。
用和你的类图一致的名称命名类。
顺序图中的类和类图中的类是相同的，因此它们应该有相同的名称。
一个角色的名称可以和类的名称相同。
在图１你可以看到一个命名为学生的角色和一个命名为学生的类。 这样做是合理的，因为这两个分类器表示两个不同的概念，角色表示在现实中的学生，而类则表示你正在构建的商业应用程序中的学生。
包含一个逻辑的叙述性描述。
图１可以很难理解－－特别是对于不熟悉阅读顺序图人来说－－因为它是很接近于实际的源程序。 在你模型中包含一个业务逻辑的描述是很常见的，特别当该顺序图描述一个使用情境时，就像在在图⒉的左边看到的，这可以增加图的可理解性，并且Rosenberg和Scott（1999）指出，这也为跟踪用例和顺序图间的信息提供了重要的信息。

图⒉在线定单付款。

在图的最左边放置人和组织角色。
对业务应用软件来说，在大多数的中，主要的角色是一个人或一个组织。这些角色经常是该情境的发起人，同时也是顺序图的阅读焦点，因此它们应该放在模型的"可看见的开始之处"。
在图的最右边放置反应系统角色。
反应系统角色是那些你与之交互的系统，应该放在图的最右边。因为在许多的业务应用软件中，这些角色经常被当做" backend entities "，也就是那些你的系统通过存取技术交互的系统，例如C APIs、CORBA IDL、消息队列、或web service。 换句话说，把后端的系统放在图最后的位置。
在图的最左边放置系统角色。
先导系统角色是那些与你的系统交互的系统，根据力争从左到右排列消息和分类器层的原则，应该放在图的最左边。
避免建模对象Destruction
虽然内存管理是很重要的的问题，特别是对象在适当的时候的销毁，许多建模者不愿意在顺序图上建模对象的销毁操作，而是在activation条（就是表示对象生命周期的那个竖条）的底部使用一个"Ｘ"符号，或使用一个带<>版型的消息。 比较图１和图２，注意图1中引入了对象的销毁，没带来明显的好处，却弄乱了图的布局。而图２则没有注明对象销毁。 记住遵循敏捷建模( AM)的实践简单的描述模型。
这项指南的意义在于两个理由∶ 首先，很多种语言都拥有称作垃圾收集的技术，实现自动的内存管理，例如Java和Smalltalk。 其次，在那些你需要明确的管理内存的语言中，例如C++，你的程序员一般地都能够了解该怎么做，并不需要模型中的这些附加信息。
注意在实时系统中，内存管理通常是一个关键性问题，你可能需要建模对象的销毁操作。
分类器的原则
注意∶分类器命名规则的在别处描述。 其中，类和接口的命名规则在UML类图的风格指南中描述，用例的命名规则在UML用例图的风格指南中描述，而组件的命名规则在UML组件图的风格指南中描述。
当你在消息上引用对象时要命名他们。
顺序图上的对象应使用标准的UML格式" name: ClassName "来标记，其中" name "可选的（拥有一个名称的对象称作已命名的对象，而那些没有名称的对象则被称作匿名对象）。在图１中，Student的实例以theStudent来命名，因为它是一条消息已引用返回值，然而SecurityLogon类的实例则不需要名称，因为图的其它地方并没有应用它，因此它可以使匿名的。
当存在部分相同的类型时需要命名对象。
当一个顺序图包含几个同样类型的对象时，例如图３存在两个Account类的实例，你应该为该类型的所有对象命名，以避免图的意义含糊不清。

图⒊在账户间转帐。