【IT168 技术文章】

         为外部交互建模

　　谈到为我们的系统和外部元素(如其它系统)之间的交互建模，通常的做法是，创建一些类，它们表示这些元素和我们的系统之间的交互方式。把外部实体表示为类，这样一种设计模式称为 镜像映象(Mirror Image)模式。当我们援用镜像映象模式时，我们基本上是先分析某一外部实体的的行为特征，然后在我们自己的系统中创建它的相似体。这个相似体通常很简单，因为它只是想抽象出我们需要的服务(对于单次使用这一情况)或系统提供的服务(对于诸如 Java 联网类类库这一情况)。它并不试图以任何方式实现这些服务。

　　我们通过研究 TCP/IP 在 Java SDK(包 java.net )中的工作原理加以说明。TCP/IP 是大多数操作系统的基本功能。TCP/IP 是一个服务，它驻留在操作系统上，使流量得以跨网络流动。假如我们打算用 Java 代码写一个文件传输程序，我们可能要用到 Java 类库中的 TCP/IP 类，用它们来访问针对这个协议的操作系统服务。这些类将成为我们应用程序的一部分，但它们最终将驻留在操作系统中，而不是在应用程序中。

　　图 1是一张 UML 图，显示了一些表示 TCP/IP 服务的类，这些服务是针对 Java 联网类的。

　　这里重要的是要理解上图所示的类 表示了操作系统所提供的服务。它们并不是服务本身。我们之所以将这些表示纳入到我们的应用程序设计中，是因为它们使我们可以更容易地与操作系统交互。我们与这些表示交互，就 好像是在与服务本身交互一样。这些表示确保了交互被正确地传送至另一个系统，而且交互的任何结果都将按我们期望的方式返回。这就是 TCP/IP 类在 Java 类库中的角色。

　　识别外部交互

　　识别与外部实体的交互在构建用例模型的需求收集阶段进行。在前面的专栏文章中，我们构建了一个用例模型， 参与者在其中表示与系统交互的外部实体。在 UML 工作簿系列的前一个专栏中，我们设计了一个既能与参与人(贷款申请人)又能与外部系统参与者(征信所)交互的系统。

　　图 2 显示了贷款处理系统最初的用例模型。

　　图 2. 贷款处理用例模型

　　在我们最初概念化一个系统的时候，识别将影响系统的参与者是很重要的。理解了需求和服务在系统与其参与者之间的相互作用，我们就可以相应地分配系统资源。参与者在系统中的 角色决定了它对系统有多大程度的影响。

　　参与者的角色

　　我们在 前文中中讨论了参与者可以扮演的各种角色。您或许能回想起来，参与者在用例中可能扮演四种角色：启动器(initiator)、服务器(server)、接收器(receiver)以及代理(facilitator)。如果某个参与者的作用是启动用例，则它的角色就是 启动器。如果参与者提供实现用例目标所需的一个或多个服务，那它充当的就是 服务器。当某个参与者的作用是接收来自系统的信息时，我们就称它为 接收器，数据仓库就是系统接收器的一个例子。最后，当某个参与者代表系统中的另一个参与者执行操作时，我们就称它为 代理。

　　参与者可以同时扮演多个角色。参与者可能是人或机器，其身份可以是匿名的，或者是已知的。如果参与者是匿名的，则它的身份对系统没有任何影响。最终用户在未曾标识的情况下可能会扮演多种角色;同样，不管是哪位最终用户扮演了某种角色 ― Tom、Mike 或是 Judy ― 他或她将经历完全相同的功能。机器也可能扮演匿名参与者，尤其是在 Web 服务领域中。

　　相比而言，为了处理诸如安全或服务质量之类的事情，系统就需要标识信息了。在这样的情况下，参与者必须是已知的。任何时候当系统要求关于某个参与者的信息时 ― 不管这个信息是确切的标识还是只鳞片爪的个别信息 ― 这个参与者就被认为是一个已知的实体。