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

核心提示： 参与者可以同时扮演多个角色，参与者可能是人或机器，Java 建模: UML 工作簿，第 4 部分(3)，其身份可以是匿名的，或者是已知的，任何级别的标识 ― 哪怕只是一个属性 ― 就能把一个参与者变成已知的参与者，而且，如果参与者是匿名的，则它的身份对系统没有任何影响

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

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

从需求到实现

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

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

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