Java建模: UML工作簿,第4部份[Java编程]

本日绝大大都计算机系统都处在某种网络之中.大大都系统除了为内部的用户群体服务,还要为该群体以外的实体供应某种代价或服务.作为回报,大大都系统也用了别的系统（比方,客户机端操作系统、Web 浏览器、外部数据库和第三方服务供应者）供应的服务.随着 Web 服务的到来,我们很快就会发现,我们开辟的系统要为越来越遍及的利用程序供应服务.

在 UML 工作簿系列的这一部份中,我们将来谈谈参与者在复杂系统的计划中的角色.为了便于谈论,我将介绍开辟复杂系统经常常利用的两种计划情势,通过它们向您展示系统模子在从需求汇集促进到解析和计划这个历程中的改变.这一部份通篇都将利用我们在 UML 工作簿系列的前几部份中开辟的贷款申请用例.

为外部交互建模

谈到为我们的系统和外部元素（如别的系统）之间的交互建模,普通的做法是,成立一些类,它们表示这些元素和我们的系统之间的交互方法.把外部实体表示为类,这样一种计划情势称为 镜像映象（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. 贷款处理用例模子

在我们最初概念化一个系统的时刻,辨认将影响系统的参与者是很重要的.理解了需求和服务在系统与其参与者之间的彼此作用,我们便可以呼应地分配系统资源.参与者在系统中的 角色决意了它对系统有多大程度的影响.

参与者的角色

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

参与者可以同时扮演多个角色.参与者大概是人或机械,其身份可以是匿名的,大概是已知的.假如参与者是匿名的,则它的身份对系统没有任何影响.终究用户在未曾标识的情形下大概会扮演多种角色;一样,不管是哪位终究用户扮演了某种角色 ― Tom、Mike 或是 Judy ― 他或她将阅历完好相同的功效.机械也大概扮演匿名参与者,特别是在 Web 服务范畴中.

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

　　以上是“Java建模: UML工作簿,第4部份[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：