三、用例分析技术简介

    用例分析技术是Rational三友之一Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。Ivar先生在加盟Rational之后，与三友合作提出了UML、完善了RUP，用例分析技术也因此被人广泛了解和关注。

    用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。

    许多人是在学习UML的时候接触到Use case，所以许多人都误解其为一种图表，把用例图当作用例分析的全部，其实这是错误的，用例描述才是用例分析技术的核心。下面是一个简单的例子：

    3.1 参与者，Actor

    参与者，定义了用户在系统交互过程中扮演的角色，其可以是一个人，也可以是另一个相关的系统。

    3.2 用例，Use case

    用例实例（场景）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例（场景）。

    一个用例应为参与者提供（实现）一个价值。

    3.3 事件流

    就像类对应于对象一样，一个用例的实例就是使用场景，用例就是对使用场景进行抽象的总结：

    1）前置条件：指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的；

    2）后置条件：用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的；

    3）基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为Happy day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；

    4）扩展事件流：主要是对一些异常情况、选择分支进行描述。

    建议大家在编写事件流时，注意以下几点：

    1）使用简单的语法：主语明确，语义易于理解；

    2）明确写出"谁控制球"：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；

    3）从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是第三者的角度；

    4）显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键做为一个事件就是不合适的）；

    5）显示参与者的意图而非动作（光有动作，让人不容易直接从事件流中理解用例）；

    6）包括"合理的活动集"（带数据的请求、系统确认、更改内部、返回结果）；

    7）用"确认"而非"检查是否"：（如系统确认用户密码正确，而非系统检查用户密码是否正确）；

    8）可选择地提及时间限制；

    9）采用"用户让系统A与系统B交互"的习惯用语；

    10）采用"循环执行步骤x到y，直到条件满足"的习惯用语。