Java建模: UML工作簿, 第2部分――序列图中的条件逻辑 - 编程入门网

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

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

序列图的两种类型

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

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

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

图 1. 常规序列图

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

图 2. 实例序列图

实例序列图最适合于在软件开发生命周期的分析阶段对个别方案建模。常规序列图可以为包含多个方案的整个用例建模。其它一些类型的活动 -- 例如为子系统或框架与其各个部分之间使用的协议建模 -- 可以使用任何一种形态，这取决于组件在软件开发生命周期中所处的位置。与实例形态相比，常规形态更接近于在最终产品中出现的实际代码。

我们在前一专栏中使用的是常规形态，并将在此继续研究这种形态。这一次，我们将探究条件逻辑在常规序列图中所扮演的角色，通过它来让您了解有关 UML 表示的更多知识。

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

序列图绘制中的条件逻辑

常规序列图利用了条件逻辑，这对于描述交互过程中事件的可选流程来说很有用处。根据软件开发生命周期中所处的不同阶段，可以绘制详略度不同的图。在分析阶段，您可能愿意将详细信息排除在条件表达式以外，而在设计阶段，您却可能希望将最终产品中要使用的代码的片段包括在条件表达式中。

无论处于开发周期中的哪个阶段，随着条件表达式图的绘制，序列图与如 Java 语言这样的面向对象语言之间那种自然的一致性就愈发清楚了。例如，请考虑一个允许出纳员接受存款的银行业务应用。除了其它一些事项以外，还规定了系统必须防止出纳员把负的金额记入帐户贷方，因为这会导致从帐户中扣除。因此系统必须有一种检查键入的所有金额均为正数的机制。清单 1 显示了确保存款为正数的条件表达式。

清单 1. 带有条件表达式的方法

\**　This　is　a　method　in　a　Teller　class　**\ public　void　receiveDeposit(Account　account,　BigDecimal　deposit) throws　ImproperDepositException　{ 　　　

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!