从用例到代码：用例分析(3)

　　例子：补充“预约汽车”用例

　　假设我们的系统是一个网站程序。当客户需要的时候，我们会为他们提供私人在线预约汽车服务。我们要为这个实现的具体情况来细化我们的用例，不过不要过多的涉及到设计阶段的工作。

　　这是预约汽车用例的更详细的描述，还是侧重于做什么，而不是侧重于怎么做：

　　用例：预约汽车(补充)

　　这个用例从顾客进入我们的预约汽车网站开始。

　　系统提示顾客输入希望的租借和归还汽车的时间、地点，顾客输入以上信息。 系统还提供给顾客一个选项，来选择汽车的种类，如微型汽车、SUV、标准汽车，等等。顾客可以限定在一个或多个种类中搜索汽车。默认值是搜索所有种类的汽车。如果顾客参加了我们的有奖租赁汽车活动，他可以在网页上一个单独的地方输入他的有奖活动的编号。如果他填写了这个编号，系统会访问顾客的档案， 来预先获取相关的信息。

　　如果顾客要继续进行预约，系统在下一个网页上，列出从数据库中找到的所有符合条件(时间地点)的汽车，提供每辆汽车的基本费率，根据顾客的租用历史情况还可以打一点折扣。如果顾客需要汽车的更详细的信息，系统从数据库中查找该信息，并将其显示给顾客。

　　如果顾客选定了一辆要预约的汽车，系统在一个新的网页中让顾客填写个人信息(姓名、电话、用于确认的电子邮件、信用卡发行商，等等)。如果系统中已经有该顾客的档案，则调出系统中的相应信息显示在页面上。有些信息是必填项，另外一些则是选填项(如电子邮件)。用户需要填写所有的必填项。系统还提供各种保护产品的信息(如汽车损伤保险、乘客险等)和单日的价格，并询问顾客是否购买，顾客做选择。

　　如果顾客表示“接受这个预约”，系统在网页上显示这次预约的概要信息(汽车型号、日期、时间、选用的保护产品及其费用、费用总额等等)，让顾客确认。如果顾客填写了电子邮件，系统会发送一封确认信到顾客的电子邮件地址。

　　当确认信息出现在顾客面前时，这个用例就结束了。

　　在这个经过补充的用例描述中，我们清晰的描述了一个基于浏览器的程序的行为，描述了很多对顾客来说不可见的行为。但是并没有提供设计级别的信息。

　　我们需要为每个用例提供类似的详细信息吗?

　　不需要。但是请记住，补充细节，并不是指实现的具体细节。我们的目标是为了能够有足够的信息来理解系统中的分析类，并与你的顾客或分析人员就所有用例的业务流程达成一致。 如果你觉得补充一些细节对于找出系统中的分析类有所帮助，那么就加上它。

　　注意：把握这个细节的尺度会比较困难。需要时间和一些练习。多上手练习，向别人多询问，还要记住当你无法决定的时候，应该稍微偏向抽象一点的描述。增加一些没有写上去的内容比较容易做到，但是要从很多杂乱的描述中找到有用的信息可就难的多了。

　　为什么还要先写出比较抽象的用例呢?为什么不直接把用例补充的比较详细?

　　这是因为抽象的用例是系统行为的最通用的描述(不过多的描述系统内部行为)。如果你还要开发一套客户端/服务器版本的预约汽车的用例会怎么样呢?如果你从详细的用例(基于浏览器的系统用例)，每次改变你的实现平台的时候，你都得重写整个用例。这个通用的描述与技术无关，特别是当你还没有、或是无法确定系统的具体环境的时候，它的价值就得到了体现。另外，通用描述用例能够让你的业务分析人员能够只看到系统如何工作的内容，而不是看到包含很多他们难以理解的技术细节的内容。

　　用例分析第三步：为用例行为找出分析类

　　根据RUP过程，这一步的目的是找出分析类的候选范围，这些类合作起来，可以完成用例的所有行为。因为我们还没有任何类，所以我们的主要目标就是找出在汽车租借系统中的所有分析类。

　　这就引出了一个有趣而又重要的问题：什么是分析类?有两种答案。首先，一个业务级别的分析类是业务领域中的一个要素，与实现技术无关。例如，银行系统中的银行顾客、帐户、帐号交易等等。而且它与系统的实现无关，不管是一个新的电子商务系统，或是一个从19世纪80年代就开始使用的借贷系统。

　　其次，RUP过程把这个定义扩展出三种不同的分析类：实体类、控制类和边界类。RUP过程中的实体类大致上相当于前面提到的，业务级别的分析类。控制类与业务过程相关，它们控制整个业务的流程和执行次序。它通常控制一个用例中业务过程的执行。边界类在系统与外界之间，为它们交换各种信息与事件。边界类处理软件系统的输入与输出。

原文转自：http://www.uml.org.cn/Test/200904165.asp