顺序图和通信图（均是交互图）是UML中用于对系统的动态方面进行建模的5种图中的两种。交互图表现的是一个交互，由一组对象和它们之间的关系组成，包括它们之间可能传递的消息。顺序图是强调消息时间顺序的交互图，通信图是强调接受和发送消息的对象的结构组织的交互图。
交互图用于对系统的动态方面的建模。在多数情况下，它包括对类、接口、构件和结点的具体的或原型化的实例以及它们之间传递的消息进行建模，所有这些都在一个阐明行为的脚本的语境中。交互图可以独立的可视化、详述、构造和文档化一个特定的对象群体的动态方面，也可以用来对用况的特定的控制流进行建模。
交互图不仅对一个系统的动态方面建模很重要，而且对通过正向和逆向工程构造可执行的系统也是很重要的。
- 入门
当我们观看电影时，放映过程中看到的并不是像真实生活中那样连续的运动，而是一系列静态图片，只是放映速度足够快，造成不间断的运动错觉。
当导演和演员策划一部电影时，使用同样的技术。通过对关键画面制作故事板，他们为每一场景建立一个模型，其详细程度足以向制作组中的所有人员传达意图。事实上，创建这个故事板是制作过程中的一项主要活动，它可以帮助小组可视化、详述、构造和文档化电影的一个模型，这包括从开始、构造到最后的实施。
在对软件密集型系统建模时，存在类似问题：如何对它的动态方面建模？怎样才能可视化一个运行的系统？如果有一个附在这个系统上的交互式调试器，你可能看到一段内存，并能观察它的内容是如何随着时间变化的。更进一步，甚至可以监视一些感兴趣的对象。随着时间的推移，将看到一些对象的创建，其属性值的改变，以及其中的一些对象的撤销。
对系统的动态方面建模的较好方法是建立脚本的故事板，其中包括某些感兴趣的对象之间的交互以及在这些对象之间传递的消息。
可以用UML的交互图对这些故事板建模。建立这些故事板有两种方式：
一种方式强调消息的时间顺序，另一种方式则强调进行交互的对象之间的结构组织。用两种方式建立的图具有等价的语义，并且可以从一个图转换到另一图而不丢失信息。
2. 术语和概念
交互图显示一个交互，由一组对象和他们之间的关系构成，其中包括在对象之间传递消息。顺序图强调消息的时间顺序的交互图。在图形上，顺序图是一个表，其中显示的对象沿着X轴排列，而消息沿着Y轴排序。通信图是强调发送和接收消息的对象的结构组织的交互图。在图形上，通信图是顶点和弧的集合。
交互图只是一种特殊的图，它具有与所有其他图相同的公共特征--即一个名称以及投影到一个模型上的图形内容。交互图有别于所有其他图的是它的特殊内容。
交互图一般包括：
- 角色和对象
- 通信或链
- 消息
交互图基本上是在交互中所能见到的元素的投影。交互的语境、对象与角色、链与连接件、消息以及顺序等概念的语义都将应用于交互图。
像所有其他图一样，交互图也可以包括注解和约束。
3. 顺序图
顺序图强调消息的时间顺序。如图所示，形成顺序图时，首先，把参加交互的对象或角色放在图的上方，沿着水平轴方向排列。通常把发起交互的对象或角色放在左边，较下级对象或角色依次放在右边。然后，把这些对象发送和接收的消息沿垂直轴方向按时间顺序从上到下放置。
顺序图有两个不同于通信图的特征。第一，顺序图有对象生命线。对象生命线是一条垂直的虚线，表示一个对象在一段时间内存在。在交互图中出现的大多数对象存在于整个交互过程中，所以这些对象全都排列在图的顶部，其生命线从图的顶部画到图的底部。
也可以在交互的过程中创建对象，他们的生命线从接受到create消息时开始。也可以在交互的过程中撤销对象，他们的生命线在接受到destroy消息时处结束（并且给出一个大×的标记表明对象生命的结束）。
如果交互表示特定的个体对象的历史，就把名字带下划线的对象符号放在生命线的顶部。然而，通常要展示的是原型化的交互。此时生命线表示的不是特定的对象，而是原型化的角色，他们代表交互的实例中的不同对象。在这种正规的情况下，无需为它们的名字加下划线，因为它们不是特定的对象。
第二，顺序图有控制焦点。控制焦点是一个瘦高的矩形，表示对象执行一个动作所经历的时间段，既可以直接执行，也可以是通过下级过程执行。矩形的顶部表示动作的开始，底部表示动作的结束。矩形的顶部表示动作的开始，底部表示动作的结束（可以由一个返回消息来标志）。还可以通过将一个控制焦点放在它的父控制焦点的右边来表示（由循环、自身操作调用或从另一个对象的回调所引起的） 控制焦点的嵌套（嵌套深度可以任意）。如果想特别精确地表示控制焦点在哪里，也可以在对象被实际执行（并且控制还没有传给另一个对象）期间，将那段矩形区域阴影化，但过于注重细节了。
顺序图的主要内容是消息。把消息表示为从一条生命线到另一条生命线的箭线，箭线指向接收者。如果消息是异步的，则箭线带有一个枝状箭头；如果消息是同步的（调用），则箭线带有实心三角箭头。用带有枝状箭头的虚箭线表示同步消息的回复。因为每个调用之后都隐含一个返回，所以可以省略返回消息。但要展示返回值，使用返回消息还是有用的。
同一条生命线上的时序是重要的。通常精确地时距并不重要，生命线只表示相对时序，所以生命线不是一个时间标尺。通常不同生命线上的消息位置并不意味着他们的顺序关系，所以这些消息可以以任意顺序发生。各个生命线上的消息集合形成一个偏序关系。然而，一系列的消息建立一个因果链，这样，任何位于链的末端的另一条生命线上的一点总是跟随这位于链开始处的源生命线上的一点。
4.顺序图中的结构化控制
序列性的消息能很好地说明单一的线性的序列，但是通常需要展示条件和循环。有时候想要展示多个序列的并发执行。在顺序图中用结构化控制操作符能展示这种高层控制。
把控制操作符表示为顺序图上的一个矩形区域，其左上角有一个写在小五边形内的文字标签，用来表明控制操作符的类型。操作符作用于穿过它的生命线，这是操作符的主体。如果一条生命线并不在某个控制操作符的覆盖范围内，那么这条生命线可能在操作符的顶部中断，然后在其底部重新开始。最常见的控制类型有如下几种：
1）可选执行
标签是opt。如果进入操作符的时候监护条件成立，那么该控制操作符的主体就会得到执行。监护条件是一个用方括号括起来的布尔表达式，它可能出现在主体内部任何一条生命线的顶端，它可以引用该对象的属性。
2）条件执行
标签是alt。控制操作符的主体用水平虚线分割成几个分区。每个分区表示一个条件分支并有一个监护条件。如果一个分区的监护条件为真，就执行这个分区。但是，最多只能执行一个分区，如果有多于一个监护条件为真，那么选择哪个分区是不确定的，而且每次执行的选择可能不同。如果所有的监护条件都不为真，那么控制将跨过这个控制符而继续执行。其中一个分区可以用特殊的监护条件【else】，如果其他所有区域的监护条件都为假就执行该分区。
3）并行执行
标签是par。用水平虚线把控制操作符的主体分割为几个分区，每个分区表示一个并行计算。通常情况下，不同分区覆盖不同的生命线。当进入控制操作符时并发地执行所有的分区。每个分区的消息是顺序执行的，但是并行分区之中的消息的相对次序则是任意的。如果不同的计算之间有交互存在，那么就不能用这种操作符。然而，现实世界中大量存在这种可分解为独立、并行活动的情况，因此这是一个很有用的操作符。
4）循环执行
标签是loop。在主体内的某个生命线的顶端给出一个监护条件。只要在每次迭代前监护条件成立，那么循环的主体就会重复执行。一旦在主体顶部中的监护条件为假，控制就会跳过该控制操作符。
为了清晰的指出顺序图的边界，通常可以把顺序图用一个封闭的矩形包围起来，并在矩形的左上角放一个标签。标签为sd，后面可以跟着给出图的名字。
如上图，并行操作符有两个分区：一个让用户输入账号，另一个让用户输入金额。因为这两个分区是并行的，所以没有规定应该按照什么次序输入这两者，按照什么次序输入都可以。并发并不总是意味着物理上的同时执行。并发其实是说两个动作没有协作关系，而且可按任意次序发生。如果他们确实是独立的动作，那么它们可以重叠；而如果它们是顺序的动作，那么它们可以按任意的次序发生。
5.嵌套活动图
太大的活动图可能难以理解。可以把活动的结构片段组织为子活动，特别是当子活动在主活动内出现多次时更该如此。把主活动与子活动分别绘制在不同的图中。在主活动图内，通过用一个左上角带ref标签的矩形表示对子活动的引用，子行为的名字放到矩形内。描述子行为不限于使用活动图，也可以使用状态机、顺序图或者其他行为规约。 上图可以用嵌套活动图重画如下，
6. 通信图
通信图强调参加交互的对象的组织。构造通信图的第一步就是将参加交互的对象作为图的顶点。然后，把连接这些对象的链接表示为图的弧，链上可能有标识这些对象的角色名。最后，用对象发送和接收消息来修饰这些链。
与顺序图不同，通信图中不能显式地展示对象的生命线，尽管可以展示create和destroy消息。另外，在通信图中不能显式地展示控制焦点，尽管各消息的序号能够表示嵌套。
通信图有两个不同顺序图的特征。
第一，通信图有路径。可以根据关联画一个路径，也可以根据本地变量、参数、全局变量和自访问呈现路径。路径表示一个对象的知识源。
第二，通信图中有序号。为表示消息的时间顺序，可以给消息加一个数字前缀（从1号开始），在控制流中，每个新消息的序号单调增加（如2,3等）。为了显示嵌套可以用杜威十进分类号（1表示第一个消息，1.1表示嵌套在消息1中的第一个消息，1.2表示嵌套在消息1中的第二个消息，等等）。嵌套可以为任意深度。还要注意的是，沿着同一个链，可以显示许多消息，并且每个消息都各有唯一的序号。
顺序图中不显式地表示对象之间的链。顺序图中也不显式地表示消息的序号：其序号隐含在从图的顶点到底部的消息的物理次序中。然而，可以用顺序图的控制结构表示迭代和分支。
7. 语义等价与一般用法
因为顺序图和通信图都来自UML的元模型中相同的信息，所以二者在语义上是等价的。因此，它们可以从一种形式转换为另一种形式，而不丢失任何信息，这可以从前面的两个插图可以看出，它们在语义上是等价的。然而，这并不意味着两种图能够显示的可视化同样的信息。
比如：通信图显示对象之间是如何链接的，而相应的顺序图则不显示这些；同样，顺序图显示消息的返回而相应的通信图则不显示这些。在两种情况下，两种图都共享相同的基本模型，但每种图都可以表示另一种图没有表示的某些东西。然而以一种格式输入的模型可能缺少另一种格式所显示的某些信息。所以，尽管基本模型可以包含两种信息，这两种图却可能导致不同的模型。
交互图用于对系统的动态方面建模。这些动态方面可能涉及系统的体系结构的任意视图中的任何种类的实例的交互，包括类（含主动类）、接口、构件和结点的实例的交互。
当使用交互图对系统的某些动态方面建模时，是在整个系统，一个子系统，一个操作或一个类的语境中进行建模。也可以把交互图附在用况（对一个脚本建模）和协作（对一个对象群体的动态方面建模）上。
当对系统的动态方面建模时，通常以两种方式使用交互图。
1）按时间顺序对控制流建模
此时使用顺序图。按时间顺序对控制流建模。强调按时间展开的消息可传送，这对于在一个用况脚本的语境中对动态行为可视化尤其有用。顺序图对简单的迭代和分支的可视化要比通信图好。
2）按组织对控制流建模
此时通信图更适合。按组织对控制流建模，强调交互中实例之间的结构关系，沿着这些关系可以传送消息。
8. 按时间顺序对控制流建模
考虑存在于系统、子系统、操作或者类的语境中的对象。也要考虑参加一个用况或协作的对象和角色。对贯穿这些对象和角色额控制流建模时，使用交互图；当强调按时间展开消息的传送时，使用交互图的一种，即顺序图。
按时间顺序对对控制流建模，要遵循如下策略：
- 设置交互的语境，不管他是系统、子系统、操作、类还是用况或协作的脚本
- 通过识别有哪些对象在交互中扮演了角色而设置交互的场景。将它们从左到右放在顺序图的上方，比较重要的对象放在左边，它们邻近的对象放在右边。
- 为每个对象设置生命线。在多数情况下，对象存在于整个交互过程中。对于那些在交互期间创建和撤销的对象，在适当的时刻设置它们的生命线，用适当的衍型化消息显式的指明它们的创建和撤销。
- 从引发这个交互的消息开始，在生命线之间画出从顶到底依次展开的消息，显示每个消息的特性（如它的参量）。如果需要，解释交互的语义。
- 如果需要可视化消息的嵌套，或可视化实际计算发生时的时间点，则用控制焦点修饰每个对象的生命线。
- 如果需要说明时间或空间的约束，则用时间标志修饰每个消息，并附上合适的时间和空间约束。
- 如果需要更形式化地说明这个控制流，则为每个消息附上前置条件和后置条件。
下图描述了一个双方打电话的简单的控制流。
9. 按组织对控制流建模
考虑存在于系统、子系统、操作或者类的语境中的对象，也要考虑参加一个用况或协作的对象和角色。对贯穿这些对象和角色的控制流建模时，使用交互图；当强调它们在结构的语境中的消息的传送时，使用交互图中的一种，即通信图。
按组织对控制流建模，遵循如下策略：
- 设置交互的语境，不管它是一个系统、子系统、操作、类，还是用况或协作的脚本。
- 通过识别有哪些对象在交互中扮演了角色而设置交互的场景。将它们作为图的顶点放在通信图中，较重要的对象放在图的中央，它们邻近的对象向外放置。
- 描述这些对象之间可能有消息沿着它传递的链：
- 首先安排关联的链。这些链是最主要的，因为它们代表结构的连接。
- 然后安排其他的链。用合适的路径注释修饰它们，显式地说明这些对象是如何相互联系的。从引发这个交互的消息开始，然后将随后的每个消息附到适当的链上，恰当地设置其序号。用带小数点的编号来显式嵌套。
- 如果需要说明时间或空间约束，则用时间标记修饰每个消息，并附上合适的时间和空间约束。
- 如果需要更形式化的说明这个控制流，则为每个消息附上前置条件和后置条件。
下面的通信图描述了学校里登记一个新生的控制流。
10.提示和技巧
在用UML创建交互图时，要记住顺序图和通信图都是一个系统的动态方面在同一模型上的投影。没有一个单独的交互图能捕捉与系统的动态方面有关的所有事情。相反，要使用许多交互图来对整个系统以及它的子系统、操作、类、用况和协作的动态特性建模。
一个结构良好的交互图，应满足如下的要求：
- 关注与系统动态特性的一个方面的交流
- 只包含那些对于理解这个方面必不可少的元素。
- 提供与它的抽象层次相一致的细节，只加入必不可少的修饰。
- 不应该过分简化信息，以致使误解重要的语义。
绘制交互图，应遵循如下策略：
- 给出一个能表达其用途的名称
- 如果想强调消息的顺序，则使用顺序图；如果想强调参加交互的对象的组织，则使用通信图
- 其元素的摆放尽量减少线的交叉。
- 用注解和颜色作为可视化提示，以突出图中重要的特征。
- 少使用分支，用活动图来表示复杂的分支要好得多。