Java与UML交互图 前面我们主要讨论的是UML类图，下面我们要讨论的是另一种UML图——交互图（Interaction Diagram）。交互图描述的是一组对象之间的交互过程，或者说，这里我们实际上要回答这样一个问题：“方法调用过程在UML中怎样表示？”
本文将通过一个非常简单的交易系统来说明UML交互图。这个系统包含六个Java类。从前面几篇文章中，我们已经知道UML类图是分析Java程序结构的有效方法，图一显示了这个交易和支付系统的类图。为了更清楚地说明各个类的职能和角色，图一利用了前面介绍过的彩色类原型表示法。
如果我们跟踪任意一个Java程序的执行过程，就会发现，这个过程包含了一个或者多个对类和对象的方法调用。我们通过调用对象的方法来寻求特定问题的答案或执行一个特定的动作。很多时候，被调用的方法还会调用其他方法——或者是同一对象的方法，或者是同一类的其他对象的方法，或者是其他类的对象的方法。类似地，这些被调用的方法又会继续调用其他方法，直至问题得到了明确的答案或动作全部执行完毕（或者出现异常，这时问题将没有答案或动作不能完成）。
UML交互图以图形的形式表示出方法调用过程，它有两种形式：序列图（Sequence Diagram）和协作图（Collaboration Diagram）。
要达到某个特定的目标，必然要执行一系列的方法调用。UML序列图的典型用途就是显示出方法调用过程。图二显示了一个交易事务中计算累计金额的序列图，调用从Sale类的calcTotal()方法开始，相关的代码片断在序列图之后给出。
术语说明：UML把操作（Operation）定义为方法的特征（Signature）。“方法”（Method）这一术语被保留给实现操作的代码。但在Java环境中，“方法”这一术语的应用范围更广泛一些。在UML序列图中，调用一个操作就叫做发送一个消息（Message）。序列图实际上阐述了操作的具体实现，所以下面我们会较多地用到“方法”这个术语（偶尔也会用到“消息”这个术语）。
| /** 属于Sale类： * 从lineItem的单项金额计算交易总金额 * @return 交易总额 */ public double calcTotal() { total = 0.0; Iterator i = lineItems.iterator(); while (i.hasNext()) total += ((LineItem)i.next()).calcTotal(); return total; } /** 属于LineItem类： * 计算当前项目的交易金额 * @return 交易金额 */ public double calcTotal() { total = product.calcTotal(this); return total; } /** 属于Product类： * 计算指定数量的产品价值多少 * @return 金额 */ public double calcTotal(LineItem li) { return amount * li.getQuantity(); } |
为了便于把握序列图的总体情况，图一只显示了方法的名称。详细的序列图可以显示出方法的参数和返回值。在序列图中，对象以常规的UML符号显示，即使用与对象所属的类一样的形状或符号（默认是矩形），再注明对象的名称，加上一个冒号，再加上相应的类名称。然后再为整个名字加上下划线（例如，图二中的aProduct:Product）。可以省略对象的名字（例如图二中的:Sale），也可以省略类的名字（例如图二的Sender），但两者都省略显然是不允许的。如果省略了类的名字，冒号必须保留。
时间的流逝方向是从上到下的垂直方向。每一个对象有一条顺着页面垂直向下的生命线（Lifeline），紧接着表示对象的矩形。方法调用的表示方式是，画一根从发出调用的对象的生命线指向被调用对象生命线的箭头。只要对象的任意方法处于执行状态，对象的生命线加宽。加宽之后的生命线称为“活动条”（Activation Bar），活动条可以嵌套，表示在前一方法的执行过程中，又有同一对象的另一个方法被调用，图二的getQuantity()方法示范了活动条嵌套的一个例子。
方法的返回值可以通过虚线开叉箭头的形式表示，但这是可选的，例如图二中从:Sale指向Sender的箭头。
如果要在一个对象的集合上进行迭代操作，则在方法的名字前面加上一个星号（再在方括号里面说明循环条件，可选）。在图二中，Sale类对LineItem类对象的调用给出了迭代操作的一个例子。
就象UML类图一样，原本需要查看多个源代码文件才能了解的信息，通过一个UML序列图就可以表示出来。对已有的代码实施反向工程获得对应的序列图，可以帮助不熟悉代码的开发者快速了解程序的工作流程。
图三显示了Sale类complete()方法的序列图，它对调用次序（消息）进行了编号。complete()方法调用了Sale类的另外两个方法，即calcTotal()和calcPayments()。图三用环形的回调符号表示一个对象正在调用它自身的方法。
如果序列图很大，可能出现一个屏幕无法显示出来的情况。在图三中，通过设置建模工具Together ControlCenter的选项面板，类的名称不再和对象名称并列显示，而是显示在对象名称的下方，减少了显示对象所需的水平空间。如果类的名称很长，用这种显示方式可以有效地缩减图形宽度，一般能够改善图形的可读性。然而，如果要严格遵从最新的UML规范，类的名称必须和对象名称并列放置，中间用冒号分隔，如图二所示。
complete()方法调用了calcTotal()方法，图二显示的calcTotal()序列是图三complete()序列的结果。如果要简化图三，我们可以省略图三的Product对象以及它与LineItem对象的交互，让读者在查看这部分内容时参考图二。和类图中面临的细节处理问题一样，到底是否要省略（或者说，详细到哪种程度），也必须根据用户的需要而定。例如，一些序列图的读者可能希望注明各种标准的Java类，例如迭代器、封装器、集合类等。虽然序列图可以显示出要用到的循环和分支结构，但通常而言，这一层次的细节最好让读者在序列图的指导下通过阅读Java源代码获得。
图四是利用Together ControlCenter对Sale类的complete()实施反向工程，并要求它给出所有细节信息所得到的序列图。对于大多数人来说，这里的细节信息可能太多了一点。但是，图四也说明了一个问题，正如exception对象所显示的：在序列执行期间创建的对象画在它被创建的位置，而不是序列图的顶端。
就象我们在讨论类图时遇到的情况一样，UML规范为序列图也提供了大量有细微差别的符号，不过本文说明的符号已经足以让你入门了。
UML交互图的另一种形式是协作图（Collaboration Diagram）。协作图和序列图在语义上相同，但协作图排列对象的方式比较自由，完全由绘图者的喜好决定。在协作图中，交互动作的次序由消息的编号决定。一些人偏爱这种绘图方式，许多功能比较完善的UML工具允许用户将一个图在协作图符号和序列图符号之间来回转换。一些开发者建议，用协作图来显示组件之间的交互过程，用序列图来显示组件内部各个类的交互过程。图五显示的协作图等价于图二显示的序列图，图六的协作图和图四的序列图一样。
结束语：在实践中，许多必需的交互序列可以隐含在类图之中，特别是类图用类原型和Stereotype来表示特定的行为和交互模式之时。UML交互图把原本隐含的交互过程明确地表达出来，同时也明确地说明了原本在类图中不明确的交互过程。换句话说，UML交互图是对倾向于描述静态特征的类图的补充，使得对象的动态交互过程明确化。
