用例的概念

用例方法可以帮助我们：
1、capture system requirements
捕获系统的需求
2、communicate with the end users and domain experts
便于和最终用户、领域专家交流
3、test the system
测试系统
为什么用例方法可以在这些方 面帮助我们
概要级用例
概要级用例包含多个用户目标，主要有 以下作用： 1. 显示用户目标级用例运行的语境 2. 为低层用例提供一个目录表
子功能级用例
子功能级用例一般是在做用例分解和系 统分析的时候引入的。常见情况： 1. 在用户目标级用例中需要依赖的用例， 而这部分功能相对用户的目标而言，没 有什么直接的关系 2. 或者是多个用户目标级用例中需要使用 到的子功能
用例的类别
业务用例与系统用例
业务人员编写业务用例来描述业务操作 软硬件开发人员编写系统用例来描述系
统的需求
设计人员可以编写另外的系统用例来记
录设计结果，或用于分解子系统的需求
黑盒用例与白盒用例
黑盒用例：完全不关心系统内部如何实 现。如用于获取需求的用例 白盒用例：涉及到系统内部的实现，需 要描述系统中构件的行为。如说明系统 设计的用例。业务用例中描述部门和个 人之间的相互作用。
• Association：两个用例之间有交互
Use和Include
UML中没有预定义Use用例关系。但在很 多文章中看到使用
个人理解：以前一直使用Include。因为 Use和Include的关系一般是在用例分解的 时候引入的上层用例和下层用例的关系。 但后来，对于子功能级，且必须被包含 在某个用户目标级（或更低级）用例中 使用的用例，使用Use关系；其他的用例 分解使用Include关系。Use常用于系统设 计。Include可以用于需求中也可以用于 设计中
Generization
当一个目标可以有多种方式实现的时候， 经常会出现特化关系
用例编写提示——一
1. 每个用例都是一篇散文。采用单调的写作方 式，却要有完美的表达能力
2. 使用例易于阅读。使用主动语态，要有主语， 只写真正是需求的东西，不要提及和需求无 关的东西
3. 仅用一种句型 4. 包含（或使用）子用例 5. 正确地得到目标层。目标级别不能太低。一
般一个用例的主成功场景中有3-9个步骤 6. 不考虑GUI细节 7. 用例需要考虑失败场景
用例编写提示——二
1. 需要考虑相关人员的利益 2. 用例可以逐步分解 3. 正确认识文本和图形的作用，case工具
的限制
推荐材料
《用例分析技术》 《编写有效用例》（强力推荐！） ROSE的帮助 UMLCHINA网站有一些可以参考的资料。
用例的概念
In its simplest form, a use case can be described as a specific way of using the system from a user’s (actor’s) perspective. 简单的说，用例就是从用户的角度（系 统的外部）观察到的系统的行为（使用 系统的过程或和系统交互的过程）。
内部执行者和白盒用例
有时我们以用例的形式描述系统中各部分 是如何协作完成一个行为，我们将系统视 为一个白盒，这里的用例称为白盒用例。 系统中的构件相对于白盒用例就是执行者。 白盒用例一般不用于描述系统的需求。而 是用于系统的设计。如子系统的分解。 在UML中，可以用序列图或协作图来描 述白盒用例
用例的层次
项目的相关人员和执行者
项目相关人员
项目相关人员（stakeholder）：对用例项目相关人员是使用系统的人员。 但有些则可能与系统没有直接交互，但 却有权利关心系统的行为。如系统的拥 有者。比如运营商。当考虑计费模型中 运营商的利益，组会话的终止判断条件 可能就得有会话发起者退出会话。
用例之间的关系
依赖： 一个用例的实现依赖于另外一个用 例的实现
1. Use：一个用例使用另外一个用例的功能 2. Include：一个用例的一个或多个步骤中包
含另外一个用例的名称
3. Extend：一个用例（扩展用例）的功能可 以插入到另外一个用例（基用例）中使用。
• Generization：一个用例是另外一个用例的 特殊情况
查询短消息——黑盒用例
用户输入查询条件，提交查询请求 系统将查询到的短消息显示出来 为避免在系统返回结果前，用户执行其 他操作，造成返回结果显示混乱。在用 户提交请求后系统返回结果前这段时间， 系统需要锁住用户界面，使用户无法操 作。等系统将结果返回后再解锁界面
查询短消息——白盒用例
当用户提交查询时，查询终端向查询服务器发送 查询请求 查询服务器接受到请求后，先在索引数据库中查 询符合条件的短消息的标识记录 查询服务器然后根据每一个短消息标识找到该短 消息所属的sc，向对应的sc发送查询短消息详细 信息的请求 查询服务器接收到sc返回的短消息详细信息后， 将短消息的详细信息返回给查询终端。然后查询 服务器根据下一个短消息标识继续向sc发送查询 短消息详细信息的请求，直到所有符合查询条件 的短消息的详细信息都返回给了查询终端。
主叫端
Alice从poc终端上查看自己的联系列表， 选择其中的一个组。该组的名称叫 “WorkTeam”。组没有呈现信息。但组 成员的呈现信息需要被显示在终端上。 Alice按下并一直按住“poc”按钮，指示 系统她要发起一次会话。 系统尽量将Alice的呼叫传送到每一个组 成员。
主叫端
当有一个组成员接受邀请时，系统将该 成员加入会话，并通知Alice可以发言。 当其他的组成员接受邀请时，系统会将 他们加入会话。并将该事件通知会话参 与者。
概要目标级用例：经过多次处理才能达到的 目标。如需求规范上的用例X。 用户目标级用例：一次处理就能完成的目标 子功能级用例：用户目标的一部分
用户目标级用例
用例是需要分解的。用例分解的粒度选 取标准一般为：在一个场景中不会出现 较大的分支。也就是一次处理就能达到 目标。这样分解得到的用例就是用户目 标级用例。 用户目标级用例是关注的重点。我们在 分解用例的时候清晰系统的设计范围， 找出用例的执行者和触发者
场景描述和用例的格式项
主成功场景：用例的一个典型场景。在该场景 中，主执行者完成目标，所有相关人员利益均 得到满足。
扩展：用例的其他成功场景和错误处理在扩展 中进行描述。
格式项：用例的格式项一般包含：用例名称、 使用语境（目标的简要描述）、范围、层次级 别、主执行者、项目相关人员及其利益、前置 条件、后置条件、触发事件、主成功场景、扩 展、附加信息。
系统给用户的终端发一个指示消息说明有一个未接的组会话上述例子的图示图中用例描述不全大家可以试着添加用例买东西大家可以试着为下面的用例文本描述画出用例图请求者发起一个请求批准者检查预算中的资金检查货物价格完成提交请求购买者检查仓库存货找出最好的供应商认证者验证批准者的签名购买者完成定购请求向供应商发出订单供应商把货物发送给接收者得到发货收据这一点超出系统设计范围接收者记录发货情况向请求者发送货物请求者设置请求已被满足标识用例的类别业务用例与系统用例业务人员编写业务用例来描述业务操作软硬件开发人员编写系统用例来描述系统的需求设计人员可以编写另外的系统用例来记录设计结果或用于分解子系统的需求黑盒用例
可选路径（扩展路径）
会话终止条件：出于计费的考虑，系统 可以在当会话的发起者退出会话的时候， 终止会话 未接来话指示：当用户在参与另一个组 会话的时候，无法接受Alice的呼叫邀请。 系统给用户的终端发一个指示消息，说 明有一个未接的组会话
……
上述例子的图示
图中用例描述不全，大家可以 试着添加用例
用例的描述是最关键的
用例方法本质上是一种文本描述方法。 在场景描述中采用陈述式的描述。一般 来说，在描述的过程中，需要明确指定 主语和谓语。这样更容易帮助我们确认 执行者需要做什么，需要对系统执行什 么操作，系统需要做什么，系统需要给 用户返回什么样的结果。
User_Defined Group Session
Extend
基用例对扩展用例可以一无所知 扩展用例一般代表一个可选功能 基用例对扩展用例而言是只读的。 区别扩展与包含：
如果触发事件包含了基用例应该负责的事件， 即基用例知道什么时候该调用第二个用例，则 基用例应该包含第二个用例
如果触发事件只包括第二个用例应该负责的事 件，第二个用例知道它应该什么时候开始。则 第二个用例应该扩展基用例
买东西
大家可以试着为下面的用例文 本描述画出用例图
请求者发起一个请求
批准者检查预算中的资金，检查货物价格， 完成提交请求 购买者检查仓库存货，找出最好的供应商 认证者验证批准者的签名 购买者完成定购请求，向供应商发出订单
供应商把货物发送给接收者，得到发货收 据（这一点超出系统设计范围） 接收者记录发货情况，向请求者发送货物 请求者设置请求已被满足标识
被叫端
如果组成员在线（Bob、Charlie），那么 他们的终端在接收到呼叫请求的时候， 会发出指示音，并显示呼叫者的ID，呼 叫类型和组ID。 组成员在接受到呼叫后，可以拒绝或接 受邀请。
系统
组成员不能同时参与两个或以上的组会 话 当会话只剩一个参与者的时候，系统终 止会话。或者 当一段时间内，系统没有检测到会话的 活动，系统终止会话
执行者-目标列表
执行者－目标列表列举了系统支持的所 有用户目标，以及这些用户目标的主执 行者 在UML图中，我们通过用例图来实现执 行者－目标列表的功能
设计范围
设计范围指的是开发人员负责设计和讨 论的系统的集合。包括软件系统和硬件 系统。 设计范围是每一个用例都关注的主题。 在UML图中，我们通过用例图来标识系 统的设计范围，配以序列图说明
系统的范围
范围一词用来描述项目开发人员负责的 设计工作的边界，以便与应由别人负责 的设计工作或已经完成的设计工作相区 别
功能范围
功能范围指的是系统要提供的服务，它 应该被用例捕获。我的理解是，通过对 系统一种或多种功能的使用，能提供给 用户的服务。简单的理解，就是系统的 功能集。 项目开始时我们难以确切地了解系统地 功能范围。我们在识别用例的同时也在 确定系统的功能范围。二者密不可分。
具体说来：
1、a pattern of behavior the system exhibits 一种展示系统行为的方法 2、a sequence of related transactions performed by an actor and the system （在使用系统的过程中的）一系列相关的处 理，这些处理由执行者和系统执行。 3、delivering something of value to the actor 给执行者返回某种结果
执行者
执行者是任何与系统有交互的人或物 主执行者：请求系统提供一项服务的项目相关 人员。主执行者经常但并非一定是触发用例的 执行者。 触发者：触发用例执行的人或物。当触发者并 不是操作人员时，其主执行者为这种情况下关 心系统行为的项目相关人员。如时间、网络异 常。个人认为，这种用例是出于对项目相关人 员利益的考虑。
Use cases are best discovered by examining the actors and defining what the actor will be able to do with the system. 用例方法通过描述执行者如何通过使用 系统来达到特定目的（场景描述） 。描 述执行者使用系统的过程时，可以帮助 确认执行者及其对系统的输入和系统相 应的响应。
谢谢！