我在介绍性专栏中曾经解释过，序列图用于描述系统随时间而产生的内部行为。因为系统行为是对象相互之间发送消息的结果，因此序列图绘制了那些消息在对象之间移动时的路线。归根结底，序列图就是交互图。在前一部分中，尽管我们描述了无数交互，但只创建了一个相当简单的图。这次，我们将做进一步的研究，看看 UML 指定的序列图的两种形态。这两种形态是 常规和 实例。让我们从每种形态的正确应用开始。
序列图的两种类型
序列图用于描述对象之间两种不同类型的交互。一种交互类型是 必须 (must) 交互，其中对象 A 必须向对象 B 发送特定消息。另一种交互类型是 可能 (may) 交互，其中对象 A 可能（但不一定）向对象 B 发送特定消息。这两种形态的序列图描述了这两种不同类型的交互。常规形态描述的是 必须交互，而实例形态则描述了 可能交互。
常规形态的序列图描述初始刺激因素所产生的类交互。常规形态则记述了初始刺激因素能够产生的一切交互。成功和失败条件与循环、条件和分支一样，都是这种图的组成部分。
常规序列图在水平轴方向上的每个框中只包含一个类名，如图 1 所示。它的含义是，交互背后的对象是匿名的，该类的任何对象都可以参与到交互中。因此，必须为所有路径明确建模。在常规序列图中，对象 A 必须向对象 B 发送模型中的一条消息。
图 1. 常规序列图
序列图的第二种形态是实例形态。实例序列图描述了两个实例之间可能发生的单一消息交换。这样的图将在水平轴方向的框中包含一个变量名及其类类型，如图 2 所示。这种形态不包括常规形态中常见的循环、条件和分支。在系统中实际的控制流程中，在交互过程中所进行的某些断言可能为假。如果发现断言为假，实例序列图中的所有消息都为空，这种情形将不出现。实例序列图描述了可能发生也可能不发生的单一情形。
图 2. 实例序列图
实例序列图最适合于在软件开发生命周期的分析阶段对个别方案建模。常规序列图可以为包含多个方案的整个用例建模。其它一些类型的活动 -- 例如为子系统或框架与其各个部分之间使用的协议建模 -- 可以使用任何一种形态，这取决于组件在软件开发生命周期中所处的位置。与实例形态相比，常规形态更接近于在最终产品中出现的实际代码。
我们在前一专栏中使用的是常规形态，并将在此继续研究这种形态。这一次，我们将探究条件逻辑在常规序列图中所扮演的角色，通过它来让您了解有关 UML 表示的更多知识。