目录
1、概述
2、顺序图
2.1、两个不同于通信图的特征：
2.1.1、顺序图有对象生命线
2.1.2、顺序图有控制焦点
2.2、结构化控制
2.2.1、可选执行opt
2.2.2、条件执行alt
2.2.3、并行执行par
2.2.4、循环迭代执行loop
2.3、嵌套活动图
3、通信图
3.1、两个不同于顺序图的特征
3.1.1、通信图有路径
3.1.2、通信图中有序号
4、语义等价
5、一般用法
6、设计过程
6.1、顺序图
6.2、通信图
顺序图和通信图（两者均被称为交互图）是UML中用于对系统的动态方面进行建模的5种图中的两种。
交互图表现的是一个交互，由一组对象和它们之间的关系组成，包括它们之间可能传递的消息。
顺序图是强调消息时间顺序的交互图，
通信图则是强调接收和发送消息的对象的结构组织的交互图。
UML中用于对系统的动态方面建模的其他3种图是活动图、状态图和用况图。
对系统的动态方面建模的较好方法是建立脚本的故事板，其中包括某些感兴趣的对象之间的交互以及在这些对象之间传递的消息。
建立故事板有两种方式：
1）一种方式强调消息的时间顺序，
2）另一种方式则强调进行交互的对象之间的结构组织。
用两种方式建立的图具有等价的语义，并且可以从一个图转换为另一个图而不丢失信息。
1、概述
交互图（interaction diagram）显示一个交互，由一组对象和它们之间的关系构成，其中包括在对象之间传递的消息。
1）顺序图 （sequence diagram）是强调消息的时间顺序的交互图。在图形上，顺序图是一个表，其中显示的对象沿 X 轴排列，而消息则沿 Y 轴按时间顺序排序。
2）通信图（communication diagram）是强调发送和接收消息的对象的结构组织的交互图。在图形上，通信图是顶点和弧的集合。
2、顺序图
顺序图强调消息的时间顺序。
形成顺序图时，首先把参加交互的对象或角色放在图的上方，沿水平轴方向排列。
通常把发起交互的对象或角色放在左边，较下级对象或角色依次放在右边。
然后，把这些对象发送和接收的消息沿垂直轴方向按时间顺序从上到下放置。
这样，就向读者提供了控制流随时间推移的清晰的可视化轨迹。
2.1、两个不同于通信图的特征：
2.1.1、顺序图有对象生命线
对象生命线是一条垂直的虚线，表示一个对象在一段时间内存在。在交互图中出现的大多数对象存在于整个交互过程中，所以这些对象全都排列在图的顶部，其生命线从图的顶部画到图的底部。
也可以在交互的过程中创建对象，它们的生命线从接收到create 消息时开始（画到生命线顶部的盒子上）。也可以在交互的过程中撤销对象，它们的生命线在接收到 destroy 消息时处结束（并且给出一个大X的标记表明对象生命的结束）。
如果交互表示特定的个体对象的历史，就把名字带下划线的对象符号放在生命线的顶部。然而，通常要展示的是原型化的交互。此时生命线表示的不是特定的对象，而是原型化的角色，它们代表交互的每个实例中的不同对象。在这种正规的情况下，无需为它们的名字加下划线，因为它们不是特定的对象。
特定的对象使用下划线
原型化的角色：不需要下划线
如果一个对象改变它的属性值、状态或角色，则可以在它的生命线上发生变化的那一点放置这个对象图标的一个拷贝，用来显示那些修改。
2.1.2、顺序图有控制焦点
控制焦点是一个瘦高的矩形，表示对象执行一个动作所经历的时间段，既可以是直接执行，也可以是通过下级过程执行。
矩形的顶部表示动作的开始，底部表示动作的结束（可以由一个返回消息来标记）。还可以通过将一个控制焦点放在它的父控制焦点的右边来表示（由循环、自身操作调用或从另一个对象的回调所引起的）控制焦点的嵌套（其嵌套深度可以任意）。如果想特别精确地表示控制焦点在哪里，也可以在对象的方法被实际执行（并且控制还没传给另一个对象）期间，将那段矩形区域阴影化，但这也过于注重细节了。
顺序图的主要内容是消息。把消息表示为从一条生命线到另一条生命线的箭线，箭线指向接收者
异步消息send：则箭线带有一个枝状箭头；
同步（调用）call：则箭线带有实心三角箭头。
调用返回消息：用带有枝状箭头的虚箭线表示对同步消息的回复（调用返回）。因为每个调用之后都隐含一个返回，所以可以省略返回消息。但要展示返回值，使用返回消息还是有用的。
2.2、结构化控制
把控制操作符表示为顺序图上的一个矩形区域，
其左上角有一个写在小五边形内的文字标签，用来表明控制操作符的类型。
操作符作用于穿过它的生命线，这是操作符的主体。
如果一条生命线并不在某个控制操作符的覆盖范围之内，那么这条生命线可能在操作符的顶部中断，然后在其底部重新开始。
2.2.1、可选执行opt
标签是opt。如果进入操作符的时候监护条件成立，那么该控制操作符的主体就会得到执行。监护条件是一个用方括号括起来的布尔表达式，它可能出现在主体内部任何一条生命线的顶端，它可以引用该对象的属性。
2.2.2、条件执行alt
标签是 alt。控制操作符的主体用水平虚线分割成几个分区。
每个分区表示一个条件分支并有一个监护条件。如果一个分区的监护条件为真，就执行这个分区。但是，最多只能执行一个分区，如果有多于一个监护条件为真，那么选择哪个分区是不确定的，而且每次执行的选择可能不同。如果所有的监护条件都不为真，那么控制将跨过这个控制操作符而继续执行。其中的一个分区可以用特殊的监护条件[else]，如果其他所有区域的监护条件都为假，那么执行该分区。
2.2.3、并行执行par
标签是par。用水平虚线把控制操作符的主体分割为几个分区，每个分区表示一个并行（并发）计算。通常情况下，不同分区覆盖不同的生命线。当进入控制操作符时并发地执行所有的分区。每个分区内的消息是顺序执行的，但是并行分区之中的消息的相对次序则是任意的。如果不同的计算之间有交互存在，那么就不能用这种操作符。然而，现实世界中大量存在这种可分解为独立、并行活动的情况，因此这是一个很有用的操作符。
2.2.4、循环迭代执行loop
标签是loop。在主体内的某个生命线的顶端给出一个监护条件。只要在每次迭代之前监护条件成立，那么循环的主体就会重复地执行。一旦在主体顶部中的监护条件为假，控制就会跳过该控制操作符。
还有其他的一些控制操作符类型，但是上文介绍的这些是最有用的
为了清晰地指出顺序图的边界，通常可以把顺序图用一个封闭的矩形包围起来，并在矩形的左上角放一个标签。标签为sd，后面可以跟着给出图的名字。
第一个是循环操作符，圆括号内的数字(1,3)表示循环主体应当执行的最少次数和最多次数。
为最少是一次，所以在检测条件之前主体至少执行一次。在循环内，用户输入密码，系统验证它。只要密码不正确，那么该循环就会继续。但是，如果超过了三次，那么无论如何循环都会结束。
下一个操作符是可选操作符。如果密码是正确的，那么就执行这个操作符的主体，否则就跳过该顺序图后面的部分。这个可选操作符的主体内还包括了一个并行操作符。正如图中所表明的，操作符可以嵌套。
并行操作符有两个分区：一个让用户输入账号，另一个让用户输入数额。因为这两个分区是并行的，所以没有规定应该按照什么次序输入这两者，按照什么次序输入都可以。需要强调的是，并发并不总是意味着物理上的同时执行。并发其实是说两个动作没有协作关系，而且可按任意次序发生。如果它们确实是独立的动作，那么它们就可以交叠；而如果它们是顺序的动作，那么它们可以按任意的次序发生。
一旦并行操作符的两个动作都被执行过，那么该并行操作符也就执行完毕。在可选操作符中的下一个动作是银行向给用户交付现金。至此，顺序图执行完毕。
2.3、嵌套活动图
把活动的结构片段组织为子活动，特别是当子活动在主活动内出现多次时更应该如此。把主活动与子活动分别绘制在不同的图中。
在主活动图内，一个左上角带 ref 标签的矩形表示对子活动的引用，子行为的名字放到矩形内。
描述子行为不限于使用活动图，也可以使用状态机、顺序图或者其他行为规约。
下图是对2.2中的图的重新组织，把两个片段分别放到两个独立的活动图中，然后在主图中引用它们
3、通信图
通信图强调参加交互的对象的组织。
如下图所示，构造通信图的第一步就是将参加交互的对象作为图的顶点。
然后，把连接这些对象的链表示为图的弧，链上可能有标识这些对象的角色名。
最后，用对象发送和接收的消息来修饰这些链。这就向读者提供了在协作对象的结构组织语境中观察控制流的一个清晰的可视化轨迹。
与顺序图不同，通信图中不能显式地展示对象的生命线，尽管可以展示create和destroy消息。另外，在通信图中不能显式地展示控制焦点，尽管各消息的序号能够表示嵌套。
3.1、两个不同于顺序图的特征
3.1.1、通信图有路径
可以根据关联画一个路径，也可以根据本地变量、参数、全局变量和自访问呈现路径。路径表示一个对象的知识源。
3.1.2、通信图中有序号
为表示消息的时间顺序，可以给消息加一个数字前缀（从1号消息开始），在控制流中，每个新消息的序号单调增加（如2、3等）。为了显示嵌套，可使用杜威十进分类号（1表示第一个消息，1.1表示嵌套在消息1中的第一个消息，1.2表示嵌套在消息1中的第二个消息，等等）。嵌套可为任意深度。还要注意的是，沿同一个链，可以显示许多消息（可能发自不同的方向），并且每个消息都各有唯一的序号。
顺序图中不显式地表示对象之间的链。
顺序图中也不显式地表示消息的序号：其序号隐含在从图的顶部到底部的消息的物理次序中。然而，可以用顺序图的控制结构表示迭代和分支。
迭代表示消息的重复序列。为了对迭代建模，在消息的序号前加一个迭代表达式，如*[i : =1..n]（如果仅想表明迭代，并不想说明它的细节，则只加*号）。
迭代表示该消息（以及任何嵌套消息）将按照给定的表达式重复。类似地，条件表示消息执行与否取决于一个布尔表达式的值。
对条件建模时，在消息序号前面加一个条件子句，如[x>0]。一个分支点上的多个可选择的路径采用相同的序号，但每个路径必须由不重叠的条件唯一区分。
4、语义等价
通信图显示对象之间是如何被链接的（注意{local}和{global}注释），而相应的顺序图则不显示这些；
同样，顺序图显示消息的返回（标注返回值 committed），而相应的通信图则不显示这些。
在两种情况下，两种图都共享相同的基本模型，但每种图都可以表示另一种图没有表示的某些东西。然而以一种格式输入的模型可能缺少另一种格式所显示的某些信息。所以，尽管基本模型可以包含两种信息，这两种图却可能导致不同的模型。
5、一般用法
交互图用于对系统的动态方面建模。这些动态方面可能涉及系统的体系结构的任意视图中的任何种类的实例的交互，包括类（含主动类）、接口、构件和结点的实例的交互。
当使用交互图对系统的某些动态方面建模时，是在整个系统、一个子系统、一个操作或一个类的语境中进行建模。也可以把交互图附在用况（对一个脚本建模）和协作（对一个对象群体的动态方面建模）上。
（1）按时间顺序对控制流建模：此时使用顺序图。按时间
顺序对控制流建模，强调按时间展开的消息的传送，这对于在一个用况脚本的语境中对动态行为可视化尤其有用。顺序图对简单的迭代和分支的可视化要比通信图好。
（2）按组织对控制流建模：此时使用通信图。按组织对控制流建模，强调交互中实例之间的结构关系，沿着这些关系可以传送消息。
6、设计过程
6.1、顺序图
设置交互的语境，不管它是系统、子系统、操作、类，还是用况或协作的脚本。
通过识别有哪些对象在交互中扮演了角色而设置交互的场景。将它们从左到右放在顺序图的上方比较重要的对象放在左边，它们邻近的对象放在右边。
为每个对象设置生命线。在多数情况下，对象存在于整个交互过程中。对于那些在交互期间创建和撤销的对象，在适当的时刻设置它们的生命线，用适当的衍型化消息显式地指明它们的创建和撤销。
从引发这个交互的消息开始，在生命线之间画出从顶到底依次展开的消息，显示每个消息的特性（如它的参量）。如果需要，解释交互的语义。
如果需要可视化消息的嵌套，或可视化实际计算发生时的时间点，则用控制焦点修饰每个对象的生命线。
如果需要说明时间或空间的约束，则用时间标记修饰每个消息，并附上合适的时间和空间约束。
如果需要更形式化地说明这个控制流，则为每个消息附上前置条件和后置条件。
一个单独的顺序图只能显示一个控制流（尽管可以用结构控制成分表示结构上的并发）。一般来说，将会有多个交互图，其中一些是主要的，另一些显示的是可选择的路径或例外条件。可以使用包来组织这些顺序图的集合，并给每个图起一个合适的名称，以便与其他图相区别。
上图描述了一个双方打电话的简单的控制流。在这个抽象层次上涉及四个对象：两个通话者Caller（s和r），一个未命名的电话交换机Switch，还有一个是c，它是两个通话者之间的交谈（Conversation）的具体化。
这个序列从Caller（s）发送一个信号（liftReceiver）给对象Switch开始。接下去，Switch给Caller发送setDialTone，而Caller迭代地执行消息dialDigit。注意，就像约束所说明的那样，这个序列不能超过30秒。这张图并不表示如果超出这个时间约束会发生什么。
如果想表示就需要包含一个分支或一个完全独立的顺序图。对象Switch接下去调用它自己以执行routeCall操作，然后创建一个Conversation对象（c），把剩余的工作分配给它。尽管这个交互中没有显示，但c还应在电话付账系统（应在另一个交互图中表示）中负有更多的职责。Conversation 对象（c）发振铃信息 ring()给 Caller（r），后者异步地发送消息liftReceiver。然后Conversation对象告诉Switch去接通（connect）电话，并告诉两个Caller对象进行connect，在这之后他们就可以通话了，如附加的注解所示。
6.2、通信图
设置交互的语境，不管它是一个系统、子系统、操作、类，还是用况或协作的脚本。
通过识别有哪些对象在交互中扮演了角色而设置交互的场景。将它们作为图的顶点放在通信图中，较重要的对象放在图的中央，它们邻近的对象向外放置。
描述这些对象之间可能有消息沿着它传递的链。
首先安排关联的链。这些链是最主要的，因为它们代表结构的连接。
然后安排其他的链，用合适的路径注释（如 global 和 local）修饰它们，显式地说明这些对象是如何互相联系的。
从引发这个交互的消息开始，然后将随后的每个消息附到适当的链上，恰当地设置其序号。用带小数点的编号来显示嵌套。
如果需要说明时间或空间约束，则用时间标记修饰每个消息，并附上合适的时间和空间约束。
如果需要更形式化地说明这个控制流，则为每个消息附上前置条件和后置条件。
上图描述了学校里登记一个新生的控制流，它强调这些对象间的结构关系。可以看到有4个角色：一个登记代理RegistrarAgent（r），一个学生Student（s），一个课程Course（c），和一个未命名的学校角色School。控制流被显式地编号。活动从RegistrarAgent创建一个Student对象开始，并把学生加入到学校中（用addStudent消息），然后告诉Student对象自己去登记。Student对象调用自己的getSchedule，得到一个必须注册的Course对象集合。然后，Student对象把自己加入到每个Course对象中。
