本文和大家重点讨论一下UMLUML序列图中的消息和约束，UMLUML序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。
消息
为了可读性，UML序列图的***个消息总是从顶端开始，并且一般位于图的左边。然后继发的消息加入图中，稍微比前面的消息低些。
为了显示一个对象（例如，生命线）传递一个消息给另外一个对象，你画一条线指向接收对象，包括一个实心箭头（如果是一个同步调用操作）或一个棍形箭头（如果是一个异步讯号）。消息/方法名字放置在带箭头的线上面。正在被传递给接收对象的消息，表示接收对象的类实现的一个操作/方法。在图4的例子中，analyst对象调用ReportingSystem类的一个实例的系统对象。analyst对象在调用系统对象的getAvailableReports方法。系统对象然后调用secSystem对象上的、包括参数userId的getSecurityClearance方法，secSystem的类的类型是SecuritySystem。2
图4：一个在对象之间传递消息的实例
除了仅仅显示UML序列图上的消息调用外，图4中的图还包括返回消息。这些返回消息是可选择的；一个返回消息画作一个带开放箭头的虚线，向后指向来源的生命线，在这条虚线上面，你放置操作的返回值。在图4中，当getSecurityClearance方法被调用时，secSystem对象返回userClearance给系统对象。当getAvailableReports方法被调用时，系统对象返回availableReports。
此外，返回消息是UML序列图的一个可选择部分。返回消息的使用依赖建模的具体/抽象程度。如果需要较好的具体化，返回消息是有用的；否则，主动消息就足够了。我个人喜欢，无论什么时候返回一个值，都包括一个返回消息，因为我发现额外的细节使一个UML序列图变得更容易阅读。
当UML序列图建模时，有时候，一个对象将会需要传递一个消息给它本身。一个对象何时称它本身？一个纯化论者会争辩一个对象应该永不传递一个消息给它本身。然而，为传递一个消息给它本身的对象建模，在一些情境中可能是有用的。举例来说，图5是图4的一个改良版本。图5版本显示调用它的determineAvailableReports方法的系统对象。通过表示系统传递消息“determineAvailableReports”给它本身，模型把注意力集中到过程的事实上，而不是系统对象。
为了要画一个调用本身的对象，如你平时所作的，画一条消息，但是不是连接它到另外的一个对象，而是你把消息连接回对象本身。
图5：系统对象调用它的determineAvailableReports方法
图5中的消息实例显示同步消息；然而，在UML序列图中，你也能为异步消息建模。一个异步消息和一个同步的画法类似，但是消息画的线带一个棍形矛头，如图6所示。
图6：表示传递到实体2的异步消息的UML序列图片段
约束
当为对象的交互建模时，有时候，必须满足一个条件，消息才会传递给对象。约束在UML图各处中，用于控制流。在这里，我将会讨论UML1.x及UML2.0两者的约束。在UML1.x中，一个约束只可能被分配到一个单一消息。UML1.x中，为了在一个UML序列图上画一个约束，你把约束元件放在约束的消息线上，消息名字之前。图7显示UML序列图的一个片段，消息addStudent方法上有一个约束。
图7：UML1.xUML序列图的一个片段，其中addStudent消息有一个约束
在图7中，约束是文本“[pastDueBalance=0]”。通过这个消息上的约束，如果应收帐系统返回一个零点的逾期平衡，addStudent消息才将会被传递。约束的符号很简单；格式是:
[BooleanTest]
举例来说，
[pastDueBalance=0]
组合碎片(变体方案，选择项，和循环)
然而，在大多数的UML序列图中，UML1.x“in-line”约束不足以处理一个建模序列的必需逻辑。这个功能缺失是UML1.x的一个问题。UML2已经通过去掉“in-line”约束，增加一个叫做组合碎片的符号元件，解决了这一个问题。一个组合碎片用来把一套消息组合在一起，在一个UML序列图中显示条件分支。UML2规范指明了组合碎片的11种交互类型。十一种中的三种将会在“基础”段落中介绍，另外两种类型将会在“超越基础”中介绍，而那剩余的六种我将会留在另一篇文章中介绍。（嗨，这是一篇文章而不是一本书。我希望你在一天中看完这部分！）
【编辑推荐】
