Java 建模: UML 工作簿，第 4 部分

核心提示： 图 1是一张 UML 图，显示了一些表示 TCP/IP 服务的类，Java 建模: UML 工作簿，第 4 部分(2)，这些服务是针对 Java 联网类的， 这里重要的是要理解上图所示的类 表示了操作系统所提供的服务，最后，当某个参与者代表系统中的另一个参与者执行操作时，它们并不是服务本身，我们

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

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

识别外部交互

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

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

图 2. 贷款处理用例模型

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

参与者的角色

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