对象与角色：最顶上一排矩形框。在交互图中，参与交互的对象既可以是具体的事物，又可以是原型化的事物。作为具体的事物，一个对象代表现实世界中的某个东西。例如，aOrder作为类Order的一个实例，可以代表一个特定的订单；而如果作为一个原型化的事件，则aOrder可以代表类Order的任何一个实例。
消息：用来描述对象之间所进行的通信的，该信息带有对将要发生的活动的期望。当传送一个消息时，它所引起的动作是用一个通过对计算过程的抽象而得到的可执行语句（就是方法头）。
顺序编号（第几步的编号）：整个消息的传递过程就形成了一个完整的序列，因此通过在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。除了顺序编号之外，还可以采用嵌套方案：
读图小结
第1步在dispatchForm（分发窗体）中，对于某个已支付的Order进行分发时，就会调用该订单（一个Order类的实例对象aOrder）的dispatch()方法。
1.1dispatch()方法将逐个调用[foreachorderitem]该Order对应的所有OrderItem对象的getPeddleryId()方法获取供应商ID1.2（PeddleryId），1.1.1而OrderItem对象则是通过其所对应的Product对象来的getPeddleryId()方法来获取供应商ID。
1.2当Order的实例对象aOrder得到返回的PeddleryId后，根据该值判断是否已经有相对应的DeliverOrder对象【ifPeddeleryIdNotExist】，如果没有就创建它（调用1.3create(PeddleryId)），然后再将对应的Product添加到这个DeliverOrder对象中。[else]1.4否则就直接添加到相应的DeliverOrder对象中。
嵌套，由左向右，由上向下
循环与分支
break
critical
par
ref
阅读通信图
通信图主要元素
链：连接器，是用来表示对象之间的语义连接，一般而言，链是关联的一个实例（包括《association》、《self》、《global》、《local》等）。不过在UML2中已经开始弱化它们的使用，因此除非必要，无需过多地考虑它们
消息编号：消息的编号有两种，一种是无层次编号，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系（类似，1.3.2）
迭代标记：用*号表示，表示循环，通常还有迭代表达式，用来说明循环规则
监护条件：通常是用来表示分支的，也就是表示“如果条件为true，才发送消息”
在通信图中使用监护条件一定要有所限制，通常应只列出主要的监护条件，否则会影响其阅读。如果需要，尽可能还是通过顺序图来表示
如何绘制交互图
准备工作
首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成另一种图
分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制
先确定参与交互的对象、对象之间的关系（通信图），然后确定对象间的消息交互流程（用同步调用、异步消息、返回消息表示），并利用交互片断（顺序图）或迭代标记及监护条件来表示循环和分支结构
鲁棒分析
鲁棒图可以很多的解决需求分析和架构设计之间的差别。更详细的说明请看最后的解释。
Robustness分析不是UML模型的一部分，它是一个强大的草图工具，是介于分析和设计之间的一种有效工具
在Robustness分析中，将应用边界类、控制类和实体类，分别对应MVC架构的3个层
从一个用例中抽取三类对象的方法
鲁棒分析—从事件流开始
下面是用例描述
鲁棒分析—寻找边界对象
图书管理员向系统发出“新增书籍信息”请求——主窗口、“新增书籍信息”按钮
系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类——书籍类别列表框。
图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号——“新书信息录入”窗口及辅助的“提交”按钮
鲁棒分析—寻找控制对象和实体对象
新添两个逻辑：
一是基本事件流中的步骤2、3要求根据用户选择的类别，自动获得书号；
二是当书名重复性检查没有通过（有重名），则应返回要求其重输
构建交互模型
转换成通信图
走到这里，我们已经能够知道，MDA的建模顺序，是先用例图，用例描述，鲁棒图，鲁棒顺序图（通信图），类图，数据库设计图
交互图应用说明
交互模型的类型与演变
分析阶段的交互模型
工作方法：针对用例图中的每个用例，并结合领域模型中的类，寻找分析类，并通过Robustness分析来理清业务逻辑流程，再用交互模型将其确定下来
说明：对于较复杂的用例，可以按上述的流程逐渐地进行分析、设计、实施；但对于比较简单的用例而言，也是可以直接从用例描述中导出设计阶段交互模型
分析阶段的交互模型之后
引入基础类：包括基础框架、程序库等
质量评审：
--低耦合：耦合性是指两个类之间的连接强度
--高内聚：内聚性是指一个类的属性与方法高度集成
--效率：解决方案的执行效率是否满足系统的需求
--完整性：是指在任何环境下都可以重复使用
--简单性：类越简单，出错的可能性越小，系统的灵活性和可维护性也越好
优化类设计：阅读《设计模式与重构》
设计阶段的交互模型&交互建模要点
在分析模型的基础上引入基础类、优化类设计之后，必然会获得新的类模型（类图）（设计模型），因此就可能需要基于新引入的“设计类”来更新交互模型，以获得与实际代码相吻合的模型
给出一个能表达其目的的名称；通过修改元素的布局，尽量避免交叉线的存在；可以通过注解和颜色作为可视化提示，以突出图形中的重要特性；尽量少用分支，对于分支很多的场景，可以考虑用活动图来补充
定时图（时序图）
定时图与顺序图的区别
用生命线的“凹下凸起”来表示状态的变化，每个水平位置代表一种不同的状态，状态的顺序可以有意义、也可以没有意义
生命线可以跟在一根线后面，在这根线上显示些不同的状态值
本章小结
首先介绍了交互的概念，并延伸出UML中的4种交互图
以为“从订单生成送货单”场景绘制的顺序图为例，介绍了对象与角色、生命线与控制焦点、消息、顺序编号、循环与分支、交互片断操作符等基本概念
以等价的通信图为例，介绍了通信图的基本概念
演示了如何采用Robustness分析法，从一个用例的事件流描述中导出相应的交互模型