UML基本概念——动态视图

内容来源：《Thinking in UML》第二版。仅供交流学习，若涉及版权，会立即删除。

4.2 动态视图

故名思义，动态视图是描述事物动态行为的。需要注意的是，动态视图不能够独立存在，它必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为。本节讲述的动态视图包括活动图、状态图、时序图和协作图。

4.2.1 活动图

活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。在正式介绍活动图之前，让我们先来讨论一下有关活动图的一些争议。活动图被引入UML中是有争议的，因为活动图实际上描述的是业务流程，是一种过程化的分析方法，很多人担心面向过程的活动图引入会导致面向对象的类职责的混乱，这种担心是有道理的。在1.1.3面向对象方法一节中我们讲过，在面向对象的眼中是没有业务流程这种东西的，所谓流程只不过是在某个外部力量推动下对象之间相互交流的一个过程，它只是“瞬时”的。如果从活动图的观点来描述业务，实际上是不能直接看到对象是如何发挥作用的。这样在观念上很容易导致对象独立性被破坏，例如有的设计者可能会试图得到一个从头到尾参与了整个业务流程的“对象”。

但是，在UML中引入活动图可能也是无奈之举，因为在1.1.4面向对象的困难一节中我们提到过从现实世界映射到对象世界有着诸多困难。面向对象要求对象越独立、封装度越高越好，可是面向对象越纯粹，我们越难以理解这些对象将会干什么。正所谓上帝什么都能做，但其实他什么也没有做；纯粹的对象结构也许能做无数的事情，但实际上我们只需要明确其中的一件。我们面临着这样一个矛盾，既要保持面向对象观点中对象的独立性，又要保持现实世界中业务目标的过程化描述。活动图的引入解决了业务目标过程化描述，但也给对象分析造成了混乱。虽然如此，活动图在描述用例场景时仍然是十分有效的工具，关键还是建模者自己要避免被过程化的观点所困扰，而不必忌讳使用活动图。

笔者要提示读者，在使用活动图时，要随时保持清醒的头脑，活动图只是我们用来描述业务目标的达成过程并借此来发现对象的工具，它不是我们的分析目标，也不是编程的依据，它只是对象的应用场景之一。我们使用活动图来描述用例场景，帮助我们认识问题领域，从问题领域中发现关键的对象，然后就应该把活动图中的流程忘掉，而专心研究关键对象的特性。最后，再来验证一下这些关键对象的某个交互结果是否的确能够达到用例场景所描述的业务目标。

4.2.1.1 用例活动图

4.2.1.2 对象活动图

4.2.1.3 泳道

4.2.1.4 业务场景建模

4.2.1.5 用例场景建模

4.2.2 状态图

4.2.3 时序图

时序图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。时序图描述了在参与交互的对象中所发生的事件（从激活的角度来说明），以及这些对象如何通过相互发送消息进行通信。可以为用例事件流的各种不同形式制作时序图。以上是官方文档对时序图的定义。通常我们使用时序图来描述用例实现，通过贡献于该用例实现的对象之间的交互来说明用例是如何被对象实现的。使用时序图来描述用例实现是一种从现实世界到对象世界的映射方法，它对我们确定对象职责和接口有着显著的作用。而对象的核心就是职责和接口。时序图与协作图是可以互相转换的，与协作图不同的是，时序图强调消息事件的发生顺序，更方便于阐述事件流的过程；但是时序图却难以表达对象之间的关系。在4.1.2类图一节中我们提到过类有三个层次的观点：概念层、说明层和实现层，它们分别对应于业务建模阶段、概念建模阶段和设计建模阶段。相应的，也可以在这三个层次上分别对业务实体对象、分析类对象和设计类对象绘制时序图。

下面就结合4.1.2类图一节中三个层次的静态类图来看看时序图如何应用于这三个层次，并且实现网上购物这一业务目标。相应的，三个层次的时序图是业务模型时序图、概念模型时序图和设计模型时序图。

4.2.3.1 业务模型时序图

业务模型时序图用于为领域模型中的业务实体交互建模，其目标是实现业务用例。在绘制业务实体时序图之前，你应当已经绘制了业务用例实现过程的活动图。在4.2.1.5用例场景建模一节中提到，活动图可以帮助我们发现业务实体，实际上，如果之前已经有了活动图再来绘制业务实体时序图时，你会发现有迹可循，非常容易。图4.18展示了图4.7所示业务实体如何实现网上购物过程的时序图。这个时序图对这些业务实体对象如何参与业务提供了非常直观的描述，从图中我们可以非常容易地分辨出对象的职责、生命周期和会话过程。对业务模型时序图的理解将有助于我们了解业务架构。

 ■ 对象表示参与交互的对象。

每个对象都带有一条生命周期线，对象被激活（创建或者被引用）时，生命周期线上会出现一个长条（会话），表示对象的存在。

■ 生命周期线

生命周期线表示对象的存在，当对象被激活（创建或者被引用）时，生命周期线上出现会话，表示对象参与了这个会话。

■ 消息

消息由一个对象的生命周期线指向另一个对象的生命周期线。如果消息指到空白的生命周期线，将创建一个新的会话；如果消息指到已有的会话，表示该对象延续已有会话。与实际的编程环境相似，消息有许多不同的类型。[插图]为简单消息。简单消息适用于大多数情况。它不强调消息的类型，仅表示一个交互。一般情况下使用简单消息就足够了，除非在设计模型的类交互时需要强调消息类型时才使用其他消息类型。

为返回消息。返回消息为源消息的返回体，而非新的消息。一般来说不需要为每个源消息都绘制返回消息，一方面因为默认情况下源消息都有返回，另一方面太多的返回消息会使图变得更复杂。

为同步消息。同步消息表示发出消息的对象将停止所有后续动作一直等到接收消息方响应。同步消息将阻塞源消息对象的所有行为。同步消息最为常用，通常程序之间的方法调用都是同步消息。

为限时消息。限时消息是同步消息的一种特殊情况。源消息对象发出消息后将等待响应一段时间，在限定时间内还没有响应时，源消息对象将取消阻塞状态而执行后续操作。限时消息也很常用，例如访问一个网站，在限定时间内没有响应时浏览器会显示“找不到指定网址”的信息。

为异步消息。异步消息表示源消息对象发出消息后不等待响应，而可以继续执行其他操作。异步消息一般需要消息中间件的支持，如JMS、MQ等。Rose里还定义了其他一些类型的消息，但这里介绍的这些消息类型已经足够了。笔者建议，在建模过程尤其是业务和概念模型中没有必要花费时间在研究消息类型上。图形简洁才能更有表达力，太多的细节只会复杂化，相反不利于理解。

■ 会话

会话表示一次交互，在会话过程中所有对象共享一个上下文环境。例如事务上下文、安全上下文等。

■ 销毁

销毁绘制在生命周期线上，表示对象生命周期的终止。虽然示例图中绘制了，但销毁也没有必要强调。最后，绘制业务模型时序图时要注意：第一，时序图以达成业务目标为准则；第二，这个阶段处于业务阶段，使用的描述语言应当采用业务术语；第三，时序图表达的内容会对将来的分析设计带来帮助，但是相对于编码实现来讲由于太粗略而不能够作为依据。

4.2.3.2 概念模型时序图

概念阶段的时序图采用分析类来绘制，目标同样是实现业务用例。但是，由于分析类本身代表了系统原型，所以这个阶段的时序图已经带有计算机理解。概念用例时序图通常是依据业务模型场景图来绘制的，它将业务模型场景用分析类重新绘制一遍，这样，既保留了实际业务需求，又得到了计算机实现的基本理念。图4.19展示了图4.8所示的说明层类图的一个时序图片段，描述了分析类实现查询商品的过程。

        请注意对比图4.8，我们看到其中的计算机实现理念的引入。这时的时序图依稀已经有了实现的影子。实际上，分析类所展示出来的已经是系统实现的原型，在设计模型阶段要做的工作就是选择适合的实现方式来实现这个蓝图。

4.2.3.3 设计模型时序图

设计模型时序图使用设计类作为对象绘制。目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。显然，在实际工作中我们很难为所有的交互都绘制时序图，那将是一个巨大的工作量。好在统一方法是讲究架构驱动的，并且近几年来不使用现成软件框架的软件项目已经很少了，所以笔者建议在设计模型阶段，只需要用框架中的关键类描述典型的交互场景即可，不需要为每一个交互都绘制时序图。例如我们只需要绘制通过框架来进行增删改查的事件流，具体的查询都遵循同样的编程模型，因此参考框架事件流即可，不需要一一绘制。

为了保证软件实现满足需求，省略了大量设计模型时序图的同时，要求有更多的概念模型时序图，这样才能保留足够的信息来说明需求与实现之间的过渡。当然，与设计模型时序图相比，概念模型时序图需要处理的信息量要少得多，工作量自然也就少得多。图4.20展示了图4.9所示的实现层类图在J2EE架构下实现查询商品过程的片断。在这个例子中，所有的类和方法都与实际编程无异，已经可以看作是伪代码了。

小结：时序图的三种应用场合是在建模过程中经常使用的动态视图。除了这些场合，在任何时候需要表达对象间的交互时，或者想分析对象的职责和接口时都可以使用时序图。特别的，在建立软件架构时，为了说明架构中的关键对象交互场景，或者为了说明应用程序如何使用架构的编程模型，也可以使用时序图来说明。这些时序图可以作为架构文档的一部分，也可用作编程规范和指南使用。甚至，在非正式建模工作中，例如一时不能确定如何设计接口，或者不能确定设计是否合理时都可以用时序图帮助分析。时序图是十分有用的工具，掌握并随时使用它是很好的分析设计习惯。接下来，我们将学习最后一种动态视图：协作图。

4.2.4 协作图

协作图描述了对象间交互的一种模式；它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象。协作图中可以有对象和主角实例，以及描述它们之间关系和交互的连接和消息。通过说明对象间如何通过互相发送消息来实现通信，协作图描述了参与对象中发生的情况。可以为用例事件流的每一个变化形式制作一个协作图。与时序图的作用相似，协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为，协作图的建模结果用于获取对象的职责和接口。与时序图不同的是，协作图因为展示了对象间的关系，使得它更适用于获得对对象结构的理解，而时序图则更适于获得对于调用过程的理解。不过在本质上，它们是可以互换的。

同样的，通常我们也使用协作图来描述用例实现，通过贡献于该用例实现的对象之间的交互来说明用例是如何被对象实现的。也同样可以针对概念层、说明层和实现层分别对业务实体对象、分析类对象和设计类对象绘制协作图。如果你更在意对象间的结构关系，请选择使用协作图；如果你更在意对象交互的执行顺序，则请选择使用时序图。下面将使用与时序图相同的例子来描述协作图如何绘制。

4.2.4.1 业务模型协作图

业务模型协作图同样采用业务实体来绘制，目标也是实现用例场景。不过有时候协作图并不要求实现完整的场景，只需要将影响对象的关键消息绘制出来即可。因为协作图更在意的是对象的结构及其相互的影响。协作图（图4.21）展示了与时序图（图4.18）同样的信息，请读者体会它们之间在表达上不同的视觉感受和蕴含的侧面意义。

协作图与时序图相比，对象间的结构一目了然，并且很容易就能知道哪些消息影响了对象（或者说对象需要提供哪些接口）。不过虽然用数字标明了消息的顺序，从图中我们还是很难看出执行的顺序，更无法了解一次完整的会话过程。协作图和时序图展示着对象不同的方面。 

■ 对象表示参与协作的对象。对象可以指定它的类，也可以直接用空对象表示，在将来再指定它的类。

■ 对象关联连接两个对象，表示两者的关联。与类关系不同，协作图中的对象关联是临时关联，即只在本次交互中存在；而类关系是永久关联，例如继承关系不论在什么情况下都是存在的。Rose中还定义了对象关联的可见属性，它们是：[插图]：域（Field）可见。表示关联的对象在交互域内是一直可见的。这有些类似于Java中的包内可见的性质。[插图]：参数（Parameters）可见。表示关联的对象仅在交互过程中可见，它们是通过参数传递产生关联的。[插图]：本地（Local）可见。表示关联的对象在本地可见。本地的概念类似于指对象在同一个JVM（Java虚拟机）或者同一个Server中，或者同一个进程中是可见的。[插图]：全局（Global）可见。表示关联的对象是全局可见的。全局的概念类似于指对象在整个分布式应用程序中，或者一个服务器群集中，或者整个万维网中是可见的。

■ 消息协作图中的消息与时序图中的消息定义完全一样。请参看4.2.3.1业务模型时序图一节中关于消息的解释部分。不过在Rose中并不能展示不同消息类型的不同符号，消息类型在打开消息属性对话框时才能看到。

■ 消息序号其实消息序号也是消息的一部分，这里分开讲只是为了强调。序号表明消息传递的先后顺序。在Rose中这个序号是由Rose自动维护的，并且不能够手工调整。正因为如此，如果要在已经完成的图中插入一条消息，基本上需要把整个图重画一遍来重新调整顺序。遇到这种情况时，“必杀技”就派上用场了，我们可以将协作图转化成时序图，在时序图中插入消息，再转换回协作图。

4.2.4.2 概念模型协作图与时序图相同，

概念阶段的协作图采用分析类来绘制，目标是实现业务用例。同样这个阶段的协作图已经带有计算机理解。图4.22展示了与时序图（图4.19）表达内容完全相同的协作图。读者可参照理解，这里就不再赘述了。

 4.2.4.3 设计模型协作图与时序图相同，

设计模型协作图使用设计类为对象来绘制。目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。协作图（图4.23）展示了与时序图（图4.20）完全相同的信息，读者可参照理解，不再赘述。

 小结：到此为止UML核心视图中的动态视图就学习完了。在动态视图中，我们学习了活动图、状态图、时序图和协作图，这些视图各有其适用的场合。笔者在本章的学习过程中按适用场合进行了一些讲解，不过肯定不能覆盖所有可能的情况。我们知道静态视图表达事物的结构性观点，而动态视图则表达事物的行为性观点。一个好的建模，结构性和行为性缺一不可，而且要相得益彰。既要说明该事物长得像什么样子，还要说明该事物应该怎么用。不论是静态视图还是动态视图都是建模的重要工具，熟练掌握它们除了学习基本概念之外，诀窍就是多用。这些视图不但可以用在软件建模过程中，也可以用在分析现实生活中的一些事例。只要愿意，总可以从生活中找到非常多的例子来练习。相对于掌握工具，理解其背后的本质才是更重要的。而这些理解是只可意会不能言传的，尽管作者作了以上的努力，仍然不能保证读者能深刻理解。希望大家多学多用，达到手中无剑心中有剑的层次。下一章，我们将开始学习UML的核心模型。预习：简单的理解，其实一个模型就是一堆有意义的静态图和动态图组合在一起，表达了一个有意义的中心思想。因此，学习模型最重要的不是死记硬背一个模型需要做什么，而是需要理解模型的中心思想。