交互与交互图

交互的概念

一次交互就是指在特定语境中，为了实现某一个目标，而在一组对象之间进行交换的一组消息所表示的行为

消息

UML中的4种交互图

顺序图：顺序图是一种强调消息时间顺序的交互图，为读者提供了控制流随着时间推移的清晰的可视化轨迹

通信图：UML 2.0中的通信图实际上就是UML 1中的协作图，它强调的是参加交互的对象的组织，为读者提供了在协作对象结构组织的语境中观察控制流的一个清晰的可视化轨迹

定时图：采用了一种带数字刻度的时间轴来精确地描述消息的顺序

交互概述图：是交互图和活动图的混合物

如何阅读交互图

阅读顺序图

顺序图的主要元素

对象与角色：最顶上一排矩形框。在交互图中，参与交互的对象既可以是具体的事物，又可以是原型化的事物。作为具体的事物，一个对象代表现实世界中的某个东西。例如，aOrder作为类Order的一个实例，可以代表一个特定的订单；而如果作为一个原型化的事件，则aOrder可以代表类Order的任何一个实例。

生命线与控制焦点：每个对象都有自己的生命线，对象生命线是一条垂直的虚线，用来表示一个对象在一段时间内存在

消息：用来描述对象之间所进行的通信的，该信息带有对将要发生的活动的期望。当传送一个消息时，它所引起的动作是用一个通过对计算过程的抽象而得到的可执行语句（就是方法头）。

调用：表示调用某个对象一个操作

顺序编号（第几步的编号）：整个消息的传递过程就形成了一个完整的序列，因此通过在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。除了顺序编号之外，还可以采用嵌套方案：

读图小结

第1步 在dispatchForm（分发窗体）中，对于某个已支付的Order进行分发时，就会调用该订单（一个Order类的实例对象aOrder）的dispatch()方法。

1.1 dispatch()方法将逐个调用 [for each orderitem] 该Order对应的所有OrderItem对象的getPeddleryId()方法获取供应商ID 1.2（PeddleryId），1.1.1 而OrderItem对象则是通过其所对应的Product对象来的getPeddleryId()方法来获取供应商ID 。

1.2当Order的实例对象aOrder得到返回的PeddleryId后，根据该值判断是否已经有相对应的DeliverOrder对象【if PeddeleryId Not Exist】，如果没有就创建它（调用 1.3 create(PeddleryId)），然后再将对应的Product添加到这个DeliverOrder对象中。[else ] 1.4否则就直接添加到相应的DeliverOrder对象中。

嵌套，由左向右，由上向下

循环与分支

交互片断操作符

片段就是指上面的框，

   左上角是片段操作符

assert（断言）

   一定会发生

交互片断操作符assert是用来表示内容所描述的行为是执行过程中那个时刻唯一的有效行为。如果执行到这个片断的前面，则说明该片断就一定会发生。它通常和ignore或consider一起使用，以断言某种特定种类的消息行为

break

条件复合跳出?交互片断操作符break和循环语句的break有点类似，通常break用来定义一个含有监护条件的子片断。

如果监护条件为“真”则执行子片断，而且不执行包含子片断的图中其它交互将不会执行，也就是跳出去；

如果监护条件为“假”，那么执行将正常地继续进行

critical

连续性的事物性的操作

表示该子片断是“临界区域”，在临界区域中生命线上的事件序列不能够和其它区域中的任何其他事件交错。通常用来表示一个原子性的连续操作，例如事务性操作

par

同时执行

用来表示“并行”的，也就是用来表示两个或多个并发执行的子片断，并行子片断中单个元素的执行次序可以以任何可能的顺序相互操作

ref

引用另一个片段到此处

在一个交互图中，我们可以引用其它的交互图，其表示的方法是用一个矩形，加上ref操作符，并写明引用的交互图名称即可

阅读通信图

通信图就是把顺序图竖起来去看，关注了访问关系。

通信图主要元素

链：连接器，是用来表示对象之间的语义连接，一般而言，链是关联的一个实例（包括《association》、《self》、《global》、《local》等）。不过在UML 2中已经开始弱化它们的使用，因此除非必要，无需过多地考虑它们

消息编号：消息的编号有两种，一种是无层次编号，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系（类似，1.3.2 ）

迭代标记：用*号表示，表示循环，通常还有迭代表达式，用来说明循环规则

监护条件：通常是用来表示分支的，也就是表示“如果条件为true，才发送消息”

在通信图中使用监护条件一定要有所限制，通常应只列出主要的监护条件，否则会影响其阅读。如果需要，尽可能还是通过顺序图来表示

如何绘制交互图

准备工作

首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成另一种图

分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制

先确定参与交互的对象、对象之间的关系（通信图），然后确定对象间的消息交互流程（用同步调用、异步消息、返回消息表示），并利用交互片断（顺序图）或迭代标记及监护条件来表示循环和分支结构

鲁棒分析

鲁棒图可以很多的解决需求分析和架构设计之间的差别。更详细的说明请看最后的解释。

Robustness分析不是UML模型的一部分，它是一个强大的草图工具，是介于分析和设计之间的一种有效工具

在Robustness分析中，将应用边界类、控制类和实体类，分别对应MVC 架构的3个层

从一个用例中抽取三类对象的方法

鲁棒分析—从事件流开始

下面是用例描述

鲁棒分析—寻找边界对象

图书管理员向系统发出“新增书籍信息”请求——主窗口、“新增书籍信息”按钮

系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类——书籍类别列表框。

图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号——“新书信息录入”窗口及辅助的“提交”按钮

鲁棒分析—寻找控制对象和实体对象

新添两个逻辑：

一 是基本事件流中的步骤2、3要求根据用户选择的类别，自动获得书号；

二 是当书名重复性检查没有通过（有重名），则应返回要求其重输

构建交互模型

转换成通信图

走到这里，我们已经能够知道，MDA的建模顺序，是先用例图，用例描述，鲁棒图，鲁棒顺序图（通信图），类图，数据库设计图

交互图应用说明

交互模型的类型与演变

分析阶段的交互模型

工作方法：针对用例图中的每个用例，并结合领域模型中的类，寻找分析类，并通过Robustness分析来理清业务逻辑流程，再用交互模型将其确定下来

注意：主要关注于区分出边界对象、实体对象和控制对象，暂时不要考虑其具体的实现类

说明：对于较复杂的用例，可以按上述的流程逐渐地进行分析、设计、实施；但对于比较简单的用例而言，也是可以直接从用例描述中导出设计阶段交互模型

分析阶段的交互模型之后

引入基础类：包括基础框架、程序库等

质量评审：

-- 低耦合：耦合性是指两个类之间的连接强度

-- 高内聚：内聚性是指一个类的属性与方法高度集成

-- 效率：解决方案的执行效率是否满足系统的需求

-- 完整性：是指在任何环境下都可以重复使用

-- 简单性：类越简单，出错的可能性越小，系统的灵活性和可维护性也越好

优化类设计：阅读 《设计模式与重构》

设计阶段的交互模型 & 交互建模要点

在分析模型的基础上引入基础类、优化类设计之后，必然会获得新的类模型（类图）（设计模型），因此就可能需要基于新引入的“设计类”来更新交互模型，以获得与实际代码相吻合的模型

给出一个能表达其目的的名称；通过修改元素的布局，尽量避免交叉线的存在；可以通过注解和颜色作为可视化提示，以突出图形中的重要特性；尽量少用分支，对于分支很多的场景，可以考虑用活动图来补充

定时图（时序图）

定时图与顺序图的区别

坐标轴交换了位置，改为从左到右来表示时间的推移（生命线颠倒）

用生命线的“凹下凸起”来表示状态的变化，每个水平位置代表一种不同的状态，状态的顺序可以有意义、也可以没有意义

生命线可以跟在一根线后面，在这根线上显示些不同的状态值

可显示一个度量时间值的标尺，用刻度表示时间间隔

本章小结

首先介绍了交互的概念，并延伸出UML中的4种交互图

以为“从订单生成送货单”场景绘制的顺序图为例，介绍了对象与角色、生命线与控制焦点、消息、顺序编号、循环与分支、交互片断操作符等基本概念

以等价的通信图为例，介绍了通信图的基本概念

演示了如何采用Robustness分析法，从一个用例的事件流描述中导出相应的交互模型

讨论了交互模型的实际应用

介绍了定时图的基本特点