转自网络http://hi.baidu.com/xpup/blog/item/e023a5090027eecb3bc76359.html
RUP里有两个重要的概念，用例和业务用例。初识RUP人常常会问，到底什么是用例，用例和业务用例的区别是什么。以下简要说明一下用例以及用例与业务用例之间的区别。
用例又叫系统用例，是一种软件需求定义的方法或形式。基于用例的需求定义方法与其他需求定义方法相比，有如下一些特点：
一、用例更加从用户（actor）的角度定义需求、强调用户目标，因此很容易为用户所理解。
传统以特性或功能的方式定义需求常常表现为系统必须这样或系统应该那样。如在描述一个在线书店的系统时，基于特性的方法会描述为：
1.系统应该提供搜索功能；
2.系统必须具备分类浏览的功能；
3.系统必须具有按折扣计算最终价格的能力等。
系统需求以一条条孤立的特性的方式表现出来，如果系统相对复杂，用户可能就会发出如下的疑问：“系统到底能帮我做什么，怎么帮我做的？”。用例正好回答了这个问题。以用例的方式定义需求处处关心用户到底想用系统做什么，如何做。例如，上例中网上书店系统，用户到底用它做什么呢？购书！嗯，购书就是其中的一个用例。接着，在购书这个用例中就会具体描述用户怎样和系统交互并最终完成购书过程。基本事件流示意如下：
1.用户准备在网上书店购书，用例开始。
2.用户浏览图书分类，查找图书。系统显示分类、子分类以及子分类下的图书。
3.用户选择准备购买的图书，并加入购物车。系统记录已加入购物车的图书并计算价格。
4.用户准备结账，系统提示确认购物清单，并提示输入银行账号、送货地址等关键信息。
5.用户输入以上信息，并确认。系统完成交易，并显示交易信息。用例结束。
二、用例不是功能也不是特性，用例不能被逐层分解为更小的用例。
用例的价值在于展现系统最终能帮用户做什么以及如何做到的。如果我们试图分解用例，那么谁去承担这个责任呢？最终结果与以特性方式定义需求相比又能有什么优越性呢。
在FDD方法中，提倡将基于特性的需求描述方式改进为以特性集的方式来描述需求，即将任务相关性强的特性组织在一起。在XP中，需求以用户故事的方式来描述，即以相对随意的方式描述用户怎么使用系统完成任务。可见关注用户任务的整体性并不是用例特有的。只是用例方法更为形式化一些。
三、用例主要以事件流的方式定义需求，但不是唯一的方式，用例形式化程度很高。
用例的主体是事件流，事件流分为基本流和备选流。基本流是用户使用系统时，最常用路径，一般不包括异常和分支。备选流则相反，一般是分支或异常等。不论是基本流还是备选流，都是以用户与系统的交互方式定义的，即用户如何使用系统，系统如何响应，但描述中不应夹杂UI设计信息。
除了主事件流之外，参与者描述了谁会使用这个用例。前置条件描述了必须具备什么样的条件或状态才能执行该用例。后置条件描述用户成功执行后应处于什么样的状态。特殊需求则会以特性的方式描述与用例相关的其他功能或非功能性需求，一般以非功能性需求居多。与XP、FDD等敏捷方法相比，用例更加形式化，定义需求更为严谨，当然花费的时间也会相对较多。
四、用例在同一时间只能有一个主要参与者（actor）。
用例充分关注用户使用系统到底做什么，但它只关注特定参与者与特定系统的交互而不包括参与者之间如何交互。如果在同一时间有两个主参与者在执行用例，就意味着你描述的不只是系统需求还包括系统所处环境中参与者之间的协作关系。例如，如果你的用例中包括类似如下的描述：
1.学生准备申请助学金，系统提示学生输入学习成绩、家庭条件等信息。
2.学生提交以上信息等待审批。
3.助学金审批人员审查学生助学金申请，决定批准，系统提示输入核准意见。
4.助学金审批人员输入理由并确认。
那么，你的用例就包括两个参与者，你的用例就不是真正的用例。同一时间，用例之所以只能有一个参与者，是因为用例只定位在描述系统的需求上，而不是定位在描述参与者之间如何协作上。如果将让用例同时描述参与者间协作，那用例将不只是定义需求还将定义业务流程，用例的复杂性增加、针对性降低、实用性减弱。
那参与者之间协作在哪描述呢，我们也确实需要它。实际上那是业务用例实现的职责。
五、用例不是需求的唯一定义形式，用例需要和其他需求定义形式一起定义完整的需求。
用例较其他需求方法具有优越性，但只使用用例是无法有效地定义完整的需求。用例主要定义的是功能性和行为性的需求，系统还有大量的非功能性需求需要定义，如易用性、性能、可支持性等等。这些需求以用例的方式定义都是不可行的，而定义他们最好的形式还应该是特性。
另外对于一些功能性需求，可能也不适合使用用例来定义，如系统对外提供的服务接口等。而对于一些不与参与者交互的中间件产品中的大量需求尤其不适合使用用例定义。其需求定义的方式使用特性更为合适。
以上大致描述的什么是用例，用例有什么特点。实践中总是有人分不清用例和业务用例。业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许就是一个业务参与者（如果你准备作住房公积金贷款）。那么办理住房公积金贷款就是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：
1.职工准备相关资料去住房公积金中心办理货款。业务用例开始。
2.职工向中心提交准备贷款的相关资料，中心工作人员对资料进行初审。
3.若审核通过，职工准备办理抵押合同，中心工作人员委托担保公司与职工签订抵押合同。
4.担保办理完成后，职工与中心签订理借款合同，中心工作人员要求职工办理银行卡并提供卡号。
5.借款合同签订后，中心工作人员要求贷款合同必须办理公证，职工与中心一道办理公证。
6.职工办理完公证后，中心发放贷款。业务用例结束。
可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。
