Java 建模: UML 工作簿, 第 2部分――序列图中的条件逻辑

核心提示：我在 介绍性专栏中曾经解释过，序列图用于描述系统随时间而产生的内部行为，Java 建模: UML 工作簿, 第 2部分――序列图中的条件逻辑，因为系统行为是对象相互之间发送消息的结果，因此序列图绘制了那些消息在对象之间移动时的路线，实例序列图中的所有消息都为空，这种情形将不出现，归根结底，序列图就是交互图

我在 介绍性专栏中曾经解释过，序列图用于描述系统随时间而产生的内部行为。因为系统行为是对象相互之间发送消息的结果，因此序列图绘制了那些消息在对象之间移动时的路线。归根结底，序列图就是交互图。在前一部分中，尽管我们描述了无数交互，但只创建了一个相当简单的图。这次，我们将做进一步的研究，看看 UML 指定的序列图的两种形态。这两种形态是 常规和 实例。让我们从每种形态的正确应用开始。

序列图的两种类型

序列图用于描述对象之间两种不同类型的交互。一种交互类型是 必须 (must) 交互，其中对象 A 必须向对象 B 发送特定消息。另一种交互类型是 可能 (may) 交互，其中对象 A 可能（但不一定）向对象 B 发送特定消息。这两种形态的序列图描述了这两种不同类型的交互。常规形态描述的是 必须交互，而实例形态则描述了 可能交互。

常规形态的序列图描述初始刺激因素所产生的类交互。常规形态则记述了初始刺激因素能够产生的一切交互。成功和失败条件与循环、条件和分支一样，都是这种图的组成部分。

常规序列图在水平轴方向上的每个框中只包含一个类名，如图 1 所示。它的含义是，交互背后的对象是匿名的，该类的任何对象都可以参与到交互中。因此，必须为所有路径明确建模。在常规序列图中，对象 A 必须向对象 B 发送模型中的一条消息。

图 1. 常规序列图

序列图的第二种形态是实例形态。实例序列图描述了两个实例之间可能发生的单一消息交换。这样的图将在水平轴方向的框中包含一个变量名及其类类型，如图 2 所示。这种形态不包括常规形态中常见的循环、条件和分支。在系统中实际的控制流程中，在交互过程中所进行的某些断言可能为假。如果发现断言为假，实例序列图中的所有消息都为空，这种情形将不出现。实例序列图描述了可能发生也可能不发生的单一情形。