Java 建模: UML 工作簿:第 2 部分
Java 建模: UML 工作簿:第 2 部分 | ||||
Granville Miller (rmiller@togethersoft.com) Granville 继续讨论“统一建模语言”和序列图的绘制。他仔细研究了序列图绘制过程中条件逻辑的角色,并讨论了为什么要在图中包含或排除条件和循环。Granville 还描述了序列图的两种形态 -- 常规和实例 -- 并说明了它们在开发周期中各自的应用。 我在介绍性专栏中曾经解释过,序列图用于描述系统随时间而产生的内部行为。因为系统行为是对象相互之间发送消息的结果,因此序列图绘制了那些消息在对象之间移动时的路线。归根结底,序列图就是交互图。在前一部分中,尽管我们描述了无数交互,但只创建了一个相当简单的图。这次,我们将做进一步的研究,看看 UML 指定的序列图的两种形态。这两种形态是常规和实例。让我们从每种形态的正确应用开始。 序列图的两种类型 常规形态的序列图描述初始刺激因素所产生的类交互。常规形态则记述了初始刺激因素能够产生的一切交互。成功和失败条件与循环、条件和分支一样,都是这种图的组成部分。 常规序列图在水平轴方向上的每个框中只包含一个类名,如图 1 所示。它的含义是,交互背后的对象是匿名的,该类的任何对象都可以参与到交互中。因此,必须为所有路径明确建模。在常规序列图中,对象 A 必须向对象 B 发送模型中的一条消息。 图 1. 常规序列图 序列图的第二种形态是实例形态。实例序列图描述了两个实例之间可能发生的单一消息交换。这样的图将在水平轴方向的框中包含一个变量名及其类类型,如图 2 所示。这种形态不包括常规形态中常见的循环、条件和分支。在系统中实际的控制流程中,在交互过程中所进行的某些断言可能为假。如果发现断言为假,实例序列图中的所有消息都为空,这种情形将不出现。实例序列图描述了可能发生也可能不发生的单一情形。 图 2. 实例序列图 实例序列图最适合于在软件开发生命周期的分析阶段对个别方案建模。常规序列图可以为包含多个方案的整个用例建模。其它一些类型的活动 -- 例如为子系统或框架与其各个部分之间使用的协议建模 -- 可以使用任何一种形态,这取决于组件在软件开发生命周期中所处的位置。与实例形态相比,常规形态更接近于在最终产品中出现的实际代码。 我们在前一专栏中使用的是常规形态,并将在此继续研究这种形态。这一次,我们将探究条件逻辑在常规序列图中所扮演的角色,通过它来让您了解有关 UML 表示的更多知识。 序列图绘制中的条件逻辑 无论处于开发周期中的哪个阶段,随着条件表达式图的绘制,序列图与如 Java 语言这样的面向对象语言之间那种自然的一致性就愈发清楚了。例如,请考虑一个允许出纳员接受存款的银行业务应用。除了其它一些事项以外,还规定了系统必须防止出纳员把负的金额记入帐户贷方,因为这会导致从帐户中扣除。因此系统必须有一种检查键入的所有金额均为正数的机制。清单 1 显示了确保存款为正数的条件表达式。
在分析阶段,您不是很关心细节,因此图只需要表明存款为正数。在常规序列图中,条件作为带有消息名的保护机制出现,位于水平调用箭头上方。这些保护条件用方括号括起,放在消息名的左侧,如图 3 所示。 上述方法和序列图之间的关系在图 4 中显现得更为清楚,我们在图 4 中看到了在设计阶段可能用到的更明确的图。当然没有显示全部方法:缺少了 else 子句。不过,图中消息箭头的语义规定只能在条件有效时发送消息。 可以通过在 绘制
在序列图中,迭代是通过水平箭头上消息名之前的星号 (*) 来表示的。如果迭代的次数已知并且固定 -- 这种情况非常少见 -- 这个数字出现在星号后面的方括号中。因为大多数 绘制
我们的 结束语 在阅读这些文章时,您应该把精力集中在发展模型语义的直观理解上。随着看到越来越多的序列图并开始创建自己的序列图,您会发现许多序列图依赖于条件逻辑和图表上下文来说明图所表示的是 必须还是可能的系统视图。随着我们深入到更加复杂的图表绘制技术,及早学习如何识别和使用这种差别将对您今后有所帮助。 除了探讨序列图绘制中必须和可能行为的重要性以外,我还向您介绍了如何在图中表示条件和迭代。既然您已经知道如何绘制
|