本节继续向大家介绍UML顺序图，这里主要包括分类器的原则，消息的原则，对象以及参数等内容，希望本节的学习能让你对UML顺序图有深入的了解。下面是有关UML顺序图的具体介绍。
分类器的原则
注意∶分类器命名规则的在别处描述。其中，类和接口的命名规则在UML类图的风格指南中描述，用例的命名规则在UML用例图的风格指南中描述，而组件的命名规则在UML组件图的风格指南中描述。
当你在消息上引用对象时要命名他们。
UML顺序图上的对象应使用标准的UML格式"name:ClassName"来标记，其中"name"可选的（拥有一个名称的对象称作已命名的对象，而那些没有名称的对象则被称作匿名对象）。在图１中，Student的实例以theStudent来命名，因为它是一条消息已引用返回值，然而SecurityLogon类的实例则不需要名称，因为图的其它地方并没有应用它，因此它可以使匿名的。
当存在部分相同的类型时需要命名对象。
当一个UML顺序图包含几个同样类型的对象时，例如图３存在两个Account类的实例，你应该为该类型的所有对象命名，以避免图的意义含糊不清。
图⒊在账户间转帐。
一致地应用文本版型。
表1总结了一些通用版型，你可以在UML顺序图的分类器上应用它们。不要花过多的时间来争论应该使用哪个版型，例如<>和<>都是不错的版型，只要随便选择一个并保证一致性就好了。
表⒈通用的版型．
版型用法
<>在设计期间表示微软的ActiveServerPage。
<>在设计期间用于注明一个组件。
<>用来注明一个控制器类，实现了和使用情境有关的业务逻辑，或包括几个业务类的逻辑。
<>设计期间表示一个图形用户界面屏幕。
<>设计期间表示一个超文本页。
<>设计期间表示一个Java接口
<>设计期间表示一个JavaServerPage。
<>设计期间表示一个打印的或电子的报告。
<>表示系统角色。
<>一个一般的用户界面类。一般使用在分析级的图上，此时你尚未决定使用何种的实现平台。
少量地应用可视化的版型。
在你的UML顺序图上应用可视化的版型时完全正确的，就如同你在图２和图３所见的，但它并非一个十分通用的惯例，因此它可能会减少图的可理解性。在图２中，顾客是一个角色（使用与用例图相同的符号），OrderCheckout是一个控制器类，CheckoutPage是一个用户界面类，而Order是一个业务实体类。
注意，那些需要开发稳定性较高的图的团队会使用可视化的版型Rosenberg&Scott1999;Ambler2002)，就像在图２描绘的可视化的版型一样，因此对项目中的所有人都必须熟悉这些符号。
集中在关键的交互。
AM的实践－－创建简单内容建议，当创建一个模型时，你应当集中于系统的关键性特征，而不要包含无关的细节。因此，如果顺序图是探究业务逻辑的，你就不要包含对象和数据库的具体交互，诸如save()和delete()的操作就已经足够了，你可以简单地假定持久性已经能够处理，而不需要去理会细节。例如，在图２中，你看不到从数据库或对象缓存中读取orders和orderitems的任何逻辑，只是他们会在适当点发生而已。你也看不到CreditCardPayment类连接到payment处理器的逻辑，但这个逻辑是必定会发生的。只把注意力集中在和你正在建模的东西相关的关键性交互上，你可以在尽可能的保持图的简单的同时达到目的，不但提高了建模者的生产力，也增加了图的可读性。
消息的原则
注意∶操作符号的命名规则，和消息、参数、返回值的命名有关的原则都在UML类图的风格指南中描述。
把消息名放在箭头旁边。
大多数的建模者都会调整消息名，例如图２中的calculateTotal()，因此消息名总是靠近箭头的。一般我们认为消息的接受者将会实现相应的操作，因此把消息名放在离分类器接近的位置是有意义的。
注意，图３并没有遵循这些原则，所有的消息名都排列在接近发送者的地方。这种方法的优点在于它很容易看出欲建模的情境的逻辑，而且，如果你使用了清楚的消息和参数名称，那你也许可以不用遵循包含逻辑的叙述性描述的原则。而这种方法的缺点是很难判断哪个操作是被图右方的分类器所调用的。象往常一样，选择一种方法并一致的应用它。
直接创建对象
在一个UML顺序图上注明对象的创建通常有两种方法。首先，你可以用<>版型来发送一个消息，如同图２如...中所示OrderCheckout所示的那样。其次，你可以通过把图中分类器位置下移，在其侧面调用一个消息的方式直接的显示创建，如你在图１所见的theStudent和图⒉的CreditCardPayment。直接方法的最主要的好处是它可以形象的表示出对象从无到有的逻辑。
为软件消息使用操作符号。
当一个消息被发给一个软件实现的分类器时，例如类、接口、或组件。通用的准则是使用实现语言的语法来描述消息名。例如，在图３中，消息commit(transactionID)被发送给sourceaccount对象，它使用了类似于Java、C++、和C_#语言的语法。
为涉及人和组织角色的消息使用叙述性文字。
当一条消息的来源或目标人或组织的角色时，需要使用简短的叙述性文字来描述传达的信息、来标记消息。例如，在图１中，被student角色发送出的消息是providesname和providesstudentnumber，它们描述了这个人在做什么。
推荐使用参数名称，而不是参数类型
注意在图３中，大多数的消息都使用参数名称来注明参数，而不是使用类型。唯一的例外是start()消息中传递的UserID参数。这可以使你正确地判定该消息传递了什么值，有时候类型信息是不够的。例如，消息addDeposit(amount,target,transactionID)传达的信息要比addDeposit(Currency,Account,int)多。
为参数占位符注明类型
有时参数传递的信息和你正在建模的信息并没有什么关系，虽然这些信息对你而言非常的重要。在这种情况下就需要注明参数的类型，如图３中的start(UserID)。
类的消息实现为静态操作
当一条消息被发给一个类时（类使用ClassName的格式标记），我们需要在类的定义中增加一条相应的静态操作。例如，图１描述了被发送给Seminar类的消息getAvailableSeminars()，因此该类的定义中应该有一条静态操作。如果这条消息被发给Seminar一个实例，那就应该有一个相应的实例操作。这是顺序图和类图间的一项非常重要的一致性检验，某些CASE工具可以自动化实现。
为用例调用使用<>版型
图３显示了一个用例在UML顺序图中是如何经由一个用<>版型标记的消息被调用的，当你在建模一个包含一个被直接调用的用例的使用情境时，就可以使用这个小技巧。
返回值的原则
当返回值非常明显时就不要对返回值建模。
返回值的显示是使用带返回值标记的虚线箭头，返回值是可选的。例如，图１中返回值theStudent表示了对SecurityLogon类调用的消息的返回值，然而图２中对order发送getTotal()消息就没有返回值。在第一个例子中，创建一个securitylogon对象会产生一个student对象，这是不明显的，然而向order要求一个小计的返回值是很明显的。
只有当你需要在别处引用返回值时才对返回值建模。
如果你需要在顺序图的另一处（一般是作为参数传递给另一个消息）引用返回值，那就需要在图中著名返回值，这样就能清楚的表明它的出处。
在箭头旁边调整返回值。
大多数的建模者都会把返回值放在靠近箭头地方，例如图２中的theStudent。一般我们认为返回值的接受者将会使用返回值，因此把返回值放在靠近分类器的位置是有意义的。
返回值建模为方法调用的一部分。
不要使用虚线来弄乱UML顺序图，考虑在消息名上注明返回值来替代虚线。使用符号message(parameters):returnValue，图２就使用了这种符号：reserve():AuthorizationCode。用这个方法，你只会有单条消息路线，而不会有一条消息路线和一条返回值路线。
为返回值占位符注明类型
有时返回值传递的信息和你的模型并没有什么关系，尽管这些信息对你而言非常的重要。在这种情况下就需要注明参数的类型，如图2中的reserve():AuthorizationCode。
明确的为简单值标明实际值
图１中isValid()message返回了值yes，这就清楚的表明了该学生的名称和编号是合法的。如果返回值命名为Boolean，就只是注明回应的类型，如果命名为eligibilityIndicator，就只是注明了返回值的名称，这样就不够明确了。
【编辑推荐】
