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

核心提示： 这个转变可能就像创建一个类来表示参与者那样简单，如图 4 所示，Java 建模: UML 工作簿，第 4 部分(4)，系统还可以将我们的参与者“看作”是更复杂的元素，在这个例子中，例如，我们可能会添加想与模型分离开来的用户接口逻辑，将会得到几种抽象，镜像映象模式的用武之地

这个转变可能就像创建一个类来表示参与者那样简单，如图 4 所示。系统还可以将我们的参与者“看作”是更复杂的元素。在这个例子中，将会得到几种抽象。镜像映象模式的用武之地是后一种情况。镜像映象模式取得外部实体，然后将它转变成系统的一部分。

在我们的贷款申请示例中，通过将已知的参与者转换成类而得到的类有两个。申请人和征信所都必须有标识性的特征。（如果我们的系统不要求这两个实体的标识性特征，那将为诈骗行为大开方便之门。）

图 4. 一个利用了镜像映象模式的类图

图片看不清楚？请点击这里查看原图（大图）。

在我们简单的模型中，存在一个参与者与所添加的类之间的一一映射。然而，参与者通常表示“更深层的”交互，可能产生多个类和更复杂的交互。一个参与者可能需要添加许多类，而其中没有一个类使用了原始参与者的名称。

类图除表示已知的参与者之外，还常常表示服务器角色和接收器角色。这些角色可以是已知的或未知的，但为了系统能够使用由它们提供的服务，必须有一个或多个类来表示所提供的服务。通过 TCP/IP 示例，我们看到了这一点。

匿名参与者

诸如启动器或代理这样的匿名参与者也会使一些类被添加进来。但这种添加与设计而不是分析有关。我们注入这些类是由于与实际的系统实现有关的一些原因，而不是要反映业务约束。例如，我们可能会添加想与模型分离开来的用户接口逻辑，或者我们可能会出于性能方面的原因而添加某些类。