面向对象分析与设计课程学习之用况图
用况（USE CASE）图
一、用况图的历史
1.1987年，I.Jacobson首先提出
2.得到了许多方法学的采纳
3.90年代末被UML采纳并标准化
二、系统边界
1.黑盒：系统对外部的客观世界发挥什么作用,提供什么业务功能来展现系统。
2.白盒:系统如何提供业务功能的。
3.问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？ 如何规范地定义用户需求？
4.考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述它外部可见的行为。
5.系统边界与参与者
a) 系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。
b) 系统：是由“用户”使用的软件，以及所有与其相关的硬件。指被开发的计算机软硬件系统， 不是指现实世界的系统。
c) 系统成分：在OOA和OOD中定义，在编程时加以实现的系统元素——对象系统边界与参与者。
d) 参与者：在系统边界以外，与系统进行交互的事物——人员、设备、外系统。
6.注意问题
a) 系统是指被开发的计算机软硬系统自身。
b) 问题域中的某些事物将作为参与者处理。
c) 原来已经存在的系统，看作是一个外系统。
d) 子系统彼此之间都可以互为外系统。
7.现实世界中的事物与系统的关系包括如下几种情况：
a) 某些事物位于系统边界内，作为系统成分。
b) 某些事物位于系统边界外，作为参与者。
c) 某些事物可能既作为参与者，又作为系统成分。
d) 某些事物既不作为参与者，又不作为系统成分。
三、参与者
1.简言之，参与者是在系统之外的与系统进行交互的任何事物。
2.定义：参与者模型系统之外的实体，当外部实体与系统交互时，它就扮演某一特定参与者的角色。
3.参与者可以发出对系统服务的请求。
4.按系统的要求提供服务。
5.通过参与者和系统之间服务请求的复杂对话与系统交互。
6.所有参与者的请求/响应的完全集构成了可以觉察到的系统的问题域边界。
7.一个参与者的一个实例代表以一特定的方式与系统进行的单独的交互。
8.尽管在模型中使用参与者，单参与者实际上并不是系统的一部分。它们存在于系统之外。
9.参与者之间的泛华关系
a) 一些参与者可能具有共同的对系统调用的请求。
i. 一种做法是显式地将这样同的每一个请求与每一个参与者相关联。（不推荐）
b） 如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，它们再从中继承，把这种关系称为参与者之间的泛化关系。
c） 定义：从参与者A到参与者B之间的泛化关系是指。A的实例能与和B实例进行通讯的用况实例进行通信。
10.识别参与者
a) 首先将精力集中于启动系统行为的参与者。
b) 从用户、外部系统和设备三个方面发现参与者。
c) 通过识别一般的或较特殊的角色来组织参与者。
11.用户、外部系统与设备
a) 用户
i. 从直接使用系统的人员中发现参与者。
ii. 这里强调的是直接使用，而不是间接的。
iii. 特定的人，在系统中可扮演不同的角色。
iv. 是用户角色的类别
b） 外部系统
i. 所以与系统交互的外部应用系统都是参与者。（外部应用系统可以是其他子系统、上级系统或任何与它进行协作的系统）
c） 设备
i. 识别所有与系统交互的设备。
l 与系统相连的设备
l 向系统提供外界信息或系统的控制下运行。
l 通常，不包括监视器、键盘、鼠标和其他的标准的用户接口类型设备
l 考虑外部传感器（输入信息）和受控马达（输出信息）
12.外部事件
a) 当我们构造实时和异步交互的系统时，将外部事件识别为潜在的参与者就变得更加重要了。
四、用况
1.定义：用况是对参与者使用系统的一项功能时所进行的交互过程的描述。
2.使用用况的原因：
a) 用况是对用户需求（主要是功能需求）的规范化的描述。
b) 为领域专家、最终用户和开发者提供一种相互交流的手段。
c) 为开发者提供一种认识和理解系统的方法。
d) 用况是开发期间随着演化而测试每个元素的基础。
3.用况的中文译法
4.用况的实例——场景
5.用况与参与者之间的关系
a) 定义：关联是参与者在用况中的参与（也就是参与者实例与用况实例之间的相互通信）。
b) 若没有进行特殊的说明，任何一方都可发送和接受消息。
c) 这是参与者和用况之间的唯一关系。交互是双向的，参与者能够产生对系统的请求，或系统要求参与者采取某些动作。
d) 把参与者和用况之间的关联表示成参与者和用况之间的一条实线。
e) 一个用况可能同多个参与者交互
i. 参与者之间通过系统实时交互
ii. 参与者之间在系统处于同一控制流
6.用况之间的关系——扩展关系
a) 定义：从用况A到用况B的扩展关系是指，用况B的实例是可以被用况A指定的行为扩充（服从于在扩展中指定的特定条件）。行为被插入到由B中的扩展点定义的位置。
b) 通过敞开的虚线箭头表示用况之间的扩展关系，该箭头从提供扩展的用况指向基用况。这个箭头用关键字<
c) 扩展点是用况中的一个位置，在该位置上，可以插入，另外一些用况的动作序列。
d) 可以把扩展点列在用况中的一个题头为“扩展点”的分栏中。以一种适当的方式给出扩展点的位置描述，通常采用普通的文本。
7.用况之间的关系——包含关系
a) 定义：从用况A到用况B的包含关系表明，用况A的一个实例也包含了用况B所指定的行为。在用况A中定义的位置包含该行为。
b) 通过一个敞开的虚线箭头表示用况之间的包含关系，该箭头从基用况指向被包含的用况。这个箭头用关键字<
c) 包含关系使得我们在一个用况中局部化多个用况中共同的活动序列。这样，可以避免多次描述同一事件流；当这个共同的序列发生变化时，这样就显现出优势，即只需要在一个地方进行改动。
8.包含关系与扩展关系的区别
a) 相同点
i. 都是不完整的
ii. 都离不开基本用况
iii. 都可实现为子程序
b) 不同点
i. 方向不同
ii. 1对多选包含关系（1个子用况，多个主用况）
iii. 多对1选扩展（多个子用况，1个主用况）
iv. 包含处理一般的情况
v. 扩展处理特殊的情况
9.用况之间的关系
a) 泛化关系
i. 子用况继承父用况的行为和含义。
ii. 子用况还可以增加或覆盖父用况的行为。
iii. 子用况可以出现在父用况出现的任何位置。
iv. 用一个指向父用况的带有封闭的空心箭头的实线来表示用况之间的泛化关系。
10.用况分类
a) 高层用况和底层用况
i. 高层用况描述对有价值的功能所提供的要素做了总的简要的描述，并不考虑这些有价值的功能是怎样获得的。
ii. 底层用况描述提供了表示活动、任务或变化的确切顺序的业务细节。
b) 本质用况和具体用况
i. 本质用况是独立于实现的（硬件的和软件的）业务
ii. 具体用况是依赖设计的。
c) 主要用况和次要用况
i. 主要用况捕获系统的主要业务功能。
ii. 次要用况处理不常见的和例外的情况。可选用况表示可以处理也可以不处理的用况。
11.用况是对场景的概括
12.捕获用况的策略
a) 首先写下两个或三个最常见的简单场景（用况）。
b) 当有两个或三个场景看上去很相似的时候，就试着产生更“抽象”的场景（用况）。
c) 应谨慎选择用于不常见事件的附加用况，并保持在可管理的数量上。
d) 以增量的方式进行分析。
i. 首先开发主要的、高层的用况模型。
ii. 然后使用该模型开发主要的、本质的用况模型。
iii. 进一步地，使用所得到的模型指导开发次要的、本质的用况。
iv. 最后，使用该模型开发次要的、具体的用况。
13.用况文档模板
a) 用况名
b) 描述：对该用况的一局或两句的描述。
c) 参与者：识别参与用况的参与者。
d) 包含：识别该用况所包含的用况。
e) 扩展：识别该用况可以扩展的用况。
f) 泛化：若该用况是子用况，则要说明它的父用况。
g) 前置条件：启动此用况所必须具备的条件。
h) 细节：识别该用况的细节。
i) 后置条件：识别在该用况结束时确保成立的条件。
j) 例外：识别在该用况的执行的过程中可能引起的例外。
k) 限制：识别在应用中可能出现的任何限制。
l) 注释：提供可能对该用况是最重要的任何附加信息。
14.用况详细描述
a) 用况详细描述的三种方式
15.详细描述用况的问题
a) 没有系统
b) 没有参与者
c) 过多的用户界面细节
d) 过低的目标级别
16.用况图在软件生命周期中的运用
a) 主要用来明确需求
b) 用来辅助分析
c) 用来辅助设计，特别是用户界面的设计
d) 用来测试
17.用况分组
a) 当许多用况具有同样的功能或者以同样的方式相互联系，就将他们归在一起。UML的包表示了用况的聚类。
b) 分组的依据
i. 同样的参与者
ii. 共同的实体
iii. 特定的工作流
18.审查
a) 参与者
i. 确定系统环境中的所有角色，并都归入了相应的参与者。
ii. 每个参与者都至少和一个用况关联。
iii. 若一个参与者是另一个参与者的一部分，把它们合并。
iv. 若两个参与者相对系统而言，扮演了类似的角色，应该在它们之间使用泛化关系。
b) 用况
i. 每个用况都至少和一个参与者关联。
ii. 若两个用况有相同或相似的序列，可能需要合并它们，或抽取一个新用况，在它们之间使用包含、扩展或泛化关系。
iii. 若用况过于复杂，为了易于理解，考虑进行分解；若一个用况有完全不同的事件流，最好把它分解成不同的用况。
19.用况建模的注意事项
a) 应确保不仅领域专家而且程序员都能够理解每一种用况所描述的系统使用的重要意义。
b) 定义用况文本时，应准确和一致地使用名词和动词。
c) 区分出在用况之间\参与者之间的关系。
d) 大量的用况应该组织为包
20.用况图的研究
a) 用况驱动的软件开发
i. 积极意义
l 有助于分析模型、设计模型的建立
l 有助于改进分析、设计以及实现与测试
ii. 问题
l 对用况依赖过高
l 导致功能分解的老路
21.与微软过程与XP中的类似物的比较
a) Usecase图与XP 使用者故事（user stories）
i. User Story(用户故事)：描述对软件（或系统）用户或客户有价值的功能,只是需求描述，而不是详细的需求规范。
ii. “As a DBA, I want to be able to compress a table so that I can reduce my storage consumption”
iii. Usecase有全局观，有图，可直接用与测试，细致
iv. User story 一句话，简单，无图，概略
b) Scenarios vs. user stories
i. user stories= Scenarios的目标
ii. user stories 用户在身边做详细解释