用例与业务用例的区别

　　RUP里有两个重要的概念，用例和业务用例。初识RUP人常常会问，到底什么是用例，用例和业务用例的区别是什么。以下简要说明一下用例以及用例与业务用例之间的区别。
　　用例又叫系统用例，是一种软件需求定义的方法或形式。基于用例的需求定义方法与其他需求定义方法相比，有如下一些特点：
　　一、用例更加从用户（actor）的角度定义需求、强调用户目标，因此很容易为用户所理解。
　　传统以特性或功能的方式定义需求常常表现为系统必须这样或系统应该那样。如在描述一个在线书店的系统时，基于特性的方法会描述为：
　　1、系统应该提供搜索功能；
　　2、系统必须具备分类浏览的功能；
　　3、系统必须具有按折扣计算终价格的能力等。
　　系统需求以一条条孤立的特性的方式表现出来，如果系统相对复杂，用户可能会发出如下的疑问：“系统到底能帮我做什么，怎么帮我做的？”。用例正好回答了这个问题。以用例的方式定义需求处处关心用户到底想用系统做什么，如何做。例如，上例中网上书店系统，用户到底用它做什么呢？购书！嗯，购书是其中的一个用例。接着，在购书这个用例中会具体描述用户怎样和系统交互并终完成购书过程。基本事件流示意如下：
　　1、用户准备在网上书店购书，用例开始。
　　2、用户浏览图书分类，查找图书。系统显示分类、子分类以及子分类下的图书。
　　3、用户选择准备购买的图书，并加入购物车。系统记录已加入购物车的图书并计算价格。
　　4、用户准备结账，系统提示确认购物清单，并提示输入银行账号、送货地址等关键信息。
　　5、用户输入以上信息，并确认。系统完成交易，并显示交易信息。用例结束。
　　二、用例不是功能也不是特性，用例不能被逐层分解为更小的用例。
　　用例的价值在于展现系统终能帮用户做什么以及如何做到的。如果我们试图分解用例，那么谁去承担这个责任呢？终结果与以特性方式定义需求相比又能有什么优越性呢。
　　在FDD方法中，提倡将基于特性的需求描述方式改进为以特性集的方式来描述需求，即将任务相关性强的特性组织在一起。在XP中，需求以用户故事的方式来描述，即以相对随意的方式描述用户怎么使用系统完成任务。可见关注用户任务的整体性并不是用例特有的。只是用例方法更为形式化一些。
　　三、用例主要以事件流的方式定义需求，但不是的方式，用例形式化程度很高。
　　用例的主体是事件流，事件流分为基本流和备选流。基本流是用户使用系统时，常用路径，一般不包括异常和分支。备选流则相反，一般是分支或异常等。不论是基本流还是备选流，都是以用户与系统的交互方式定义的，即用户如何使用系统，系统如何响应，但描述中不应夹杂UI设计信息。
　　除了主事件流之外，参与者描述了谁会使用这个用例。前置条件描述了必须具备什么样的条件或状态才能执行该用例。后置条件描述用户成功执行后应处于什么样的状态。特殊需求则会以特性的方式描述与用例相关的其他功能或非功能性需求，一般以非功能性需求居多。与XP、FDD等敏捷方法相比，用例更加形式化，定义需求更为严谨，当然花费的时间也会相对较多。