《信息系统分析与设计》-用例建模
1 基于用例的需求分析
用例分析是站在最终用户的角度看待系统及其特性，模型简单直接，一经提出便受到软件开发人员的青睐。
用例总是和面向对象方法放在一起讨论，并且在面向对象标准建模语言UML中用例也具有中心地位。但严格意义上讲，用例并不是一个面向对象方法论的产物，不包含面向对象思想，只是因为用例概念最初是和面向对象方法一同提出并得到广泛接受而已。
需求分析基本步骤
1.从系统涉众获取候选需求
2.结合系统业务背景理解候选需求
3.捕获信息系统功能性需求（用例模型）
4.捕获与功能需求相关的非功能性需求或其他技术性要求
用例的概念
用例创始人雅各布森(Ivar Jacobson)认为：
用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（actor）产生可观测的、有价值的结果。
阿里斯代尔·科克伯恩（Alistair Cockburn）认为：
用例（use case）是各种系统受益人之间的一种行为契约。行为包括对象的活动、动作和对象之间的交互等。
每一个用例实际上都代表了一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。
用例和用例模型的意义
1、用例是对系统需求（主要是功能需求）的规范化描述，用例模型是面向对象分析的关键输入
2、用例图及用例的事件流描述集中体现了系统责任
3、通过用例建立交互图。交互图就是用例的具体体现，其实现是以对象和对象间协作为基础的。
参与者(Actor)：参与者是系统之外与系统进行交互的任何事物。
主要参与者（primary actor）：是从系统中直接获得可度量价值的用户，功能最直接最主要的用户。
次要参与者（secondary actor）： 的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用。
2 用例的描述
用例图是对系统中的用例的高度概括和直观的表示，但没有细节。应对每个用例进行文字的详细描述，从而准确定义“做什么”，即需求。
用例规格说明（模板）Use Case Specification
- 用例名称
- 主要参与者/次要参与者
- 简要描述
- 前置条件
- 后置条件
- 主事件流（主要成功场景/基本路径）
- 备选事件流（扩展路径/替代流程/异常事件流）
- 特殊要求/非功能性需求
- 发生频率
用例的前置条件和后置条件
前置条件（pre-condition）：表述在系统允许用例开始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。
如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。
后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。
一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。
某些用例可能没有前置条件或后置条件，比如“查询书目”，因为该用例执行后不会改变系统状态。
用例与事件流（Flow of Activities）
用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。
事件流的描述包括：
- 用例何时开始和结束
- 用例何时与参与者交互（对话过程）
- 参与者与系统之间有什么对象或信息被交换
- 该行为的主事件流和备选事件流
主事件流：主事件流是指能够满足目标的典型的成功路径。
- 不包括条件及分支
- 主成功场景/开心路径/基本路径
备选事件流：备选事件流是指除主事件流之外的各种可能失败情况、分支路径或扩展路径。
3 建立用例的关系
进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。
扩展和包含关系就是用例模型中消除冗余的一种手段。
但忌讳使用结构化的功能分解将用例分解成一些子用例、子子用例。
基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。
包含关系
经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。
包含用例是基本用例存在的必要条件
- 一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。
- 比如“查询书目”用例既可以单独存在，也可以作为“预定图书”的包含用例。
扩展关系
表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例。
- 扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。
- 扩展用例的缺失不影响对基本用例的理解。
泛化关系（不推荐）
如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。
