第9章交互图.docVIP

第9章 交互图 一个完整的模型必须描述系统的静态和动态两个方面。静态模型，譬如类和对象图，描述系统中的对象，每个对象包含的数据，以及它们之间存在的链接，但是这些图几乎没有说明这些对象的行为。 在系统运行时，如第2章所阐述的，对象通过传递消息交互。例如，在执行用例或调用类中的操作时发生的交互。发送的这些消息决定了系统的行为，但是它们在静态图，例如在类图中并没有显示。本章描述UML中用于描述交互的图，即协作图和顺序图。这两种图提供了表达几乎相同的信息的两种方式，因而统称为交互图。 9.1 协作 尽管对交互最重要的东西是组成交互的消息，但是不知道交互涉及什么对象以及它们如何发生联系，就不能具体指定这些消息。协作定义了一组对象，它们按照支持给定交互的方式相互联系。交互图由协作以及组成交互本身的消息组成。这些消息将在协作中的对象之间传递。 协作通常只是用一个对象图定义，该对象图显示特定的一组链接对象。然后可以通过向这个对象图中增加消息来表示交互。例如，考虑银行系统中将资金从一个账户转到另一账户的操作。每次调用这个操作，一定数量的资金就从一个账户提出并存入到另一账户。 这个事务可以用图9.1所示的对象图说明。这个图中显示了两个账户对象，以及一个代表银行的对象，它从一个账户中拿出资金并将其存入另一个账户。 图 9.1 两个银行账户之间的转账 尽管像这样的图经常用于说明特定的操作可以如何实现，但图9.1实际上只显示了两个特定的账户“a1”和“a2”之间一次特殊的转账。为什么对象图这样的用法作为一种明确说明交互的一般方法不能令人满意，其中存在很多原因。 首先，“a1”和“a2”不是资金可以在其间转移的仅有的对象。尽管未必任何人都会从图9.1得出这个结论，但是更一般的规格说明应该明确地表达任何账户都能够参与转账，要么作为从中取款的账户，要么作为存款的账户，并且它发送和接收的消息将因情况而不同。 其次，对象图显示了固定数目的对象和它们之间的链接。然而，在调用操作的不同场合，涉及的对象的数目和它们之间的链接模式都可能改变，并且产生的交互也将因此而不同。例如，另一种转账形式可能允许从一个账户提出资金，并在若干其他账户之间分配。这个操作的说明应该以一种一般的方式表明在这些不同情况下会发生什么事情，而不是显示几个例子，而让读者去推断在其他情况下会发生什么。 第三，一些操作在不同的场合可能会展示不同的功能。在这个例子中，当要提款的账户提款的结果会发生透支时，也许就不进行转账。一般而言，这暗示着交互的过程可能受对象中存储的数据的特性影响。不同的可能性可以显示在各个对象图中，但是更可取的是有一个能够在一个对象图中表示其他的可能性的表示法，而不是不得不画一组说明性的例子。 为了达到所需的一般性，UML中的协作通常不是显示各个对象，而是显示这些对象在交互中可以扮演的角色。用于阐明协作的对象图，被称为协作实例集。在协作中使用角色，除了其他，会更清晰地表达在不同时间的交互中可以包含的这些不同对象。 9.2 类元角色（注：在UML2中已经被结构化类元中的角色和连接器所取代） 因此，协作一般地描述的不是交互中的各个对象，而是对象在交互中扮演的角色。每个角色描述对象能够参与交互的一种特殊方式。例如，每次资金转账都包含两个账户对象，但是这两个对象以不同的方式参与了交易，从一个账户中提出资金，而向另一个存入资金。 这可以通过为该交易定义两个角色来说明，可以被称为“借方” 角色和“贷方”角色。于是可以给该交易一个一般描述，即从借方账户提出资金并转入贷方账户。无论何时只要发生资金转账，就为每个角色各指派一个账户对象，一个是借方，一个是贷方。 对象在交互中可以扮演的角色称为类元角色（classifier role）。图9.2显示了一个与图9.1中的对象图对应的协作，用类元角色代替了实际对象。类元角色具有一个名字和一个基类（base class），显示在矩形图标中，用冒号隔开。 图 9.2 有类元角色的协作 类元角色的表示法显然与对象和类使用的表示法有关。可以为类元角色命名，以斜线开始；如果省略了名字，则必须包含冒号以区分角色和类。角色的名字和类不加下划线：这表示类元角色不是实例，而是更一般的概念，可以自己有对象作为实例。 角色和实际参与交互的对象之间的关系有点类似于数学中的变量和数之间的关系。例如，为了用公式E=mc2计算3克物质中包含多少能量，必须用数值3代入变量m。同样地，为了从图9.2中的协作得到图9.1中的对象图，要用实际对象代替协作中的类元角色。当然，在不同的时候，可以用不同的对象代替相同的角色，或者用相同的对象代替不同的角色，取决于只执行的真实转账。 在交互中充当特定角色的对象必须是该角色的基类的实例，或是基类的子孙类之一的实例。然而，在一