Java建模: UML工作簿，第4部分 - 编程入门网

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

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

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

从需求到实现

当我们从用例图转入到序列图和类图时，马上就会注意到已知的参与者的影响。我们最初的序列图（在 UML 工作簿以前的部分中开发的）包含了已知的参与者。在这个层次的分析上，我们把系统与它的参与者之间的交互描述为一系列消息。因此，我们不是在处理个别的人或系统；相反地，我们把那些与系统交互的人或系统的细节封装到抽象的实体中，我们称它为参与者。图 3 图示了贷款申请用例的序列图的一部分。想查看完整的序列图，请参阅 UML 工作簿以前的部分。

图 3. 贷款申请用例的序列图的一部分

当我们从序列图转到类图时，我们的系统分析就更精细了。因为在这个层次上，参与者是与需求和行为联系在一起，所以我们不再处理参与者的问题。相反，参与者背后的抽象概念可能将被提出来。在这个层次上出现的大多数“参与者”都将至少由一个属性标识；否则它们就是系统在分析阶段时所不感兴趣的参与者。任何级别的标识 ― 哪怕只是一个属性 ― 就能把一个参与者变成已知的参与者。而且，已知的参与者在类图中已不再是一个参与者；它成为了一个类。

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

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

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

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

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

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

匿名参与者

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

在 EJB 开发中， 会话虚包（Session Facade）模式常被用来使网络流量最小化和确保事务一致性。在 Web 服务的开发中，这一模式也有极重要的作用，该模式还是匿名参与者在系统设计中的用法的典型示例。会话虚包模式用对会话 bean 的单个调用来

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!