第三章 用例图
目录
m1.理解需求
m2.基于用例的需求描述
m3.用例的获取
m4.用例图
2.1 理解需求
需求就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件
m1.需求涉及到谁？
Ø客户（Client）-为开发付钱的人，将来是产品的拥有者。
Ø顾客（Customer）-买商品化软件的人，或者将来有发言权确定产品是否可以接受。可能与客户是同样的人。
Ø涉众（stakeholder）-任何对系统需求有直接或间接影响的人。
m2.需求的分类
Ø功能需求：系统必须提供服务的描述，系统应该如何响应特定的输入，系统在特定的情景下的行为
例：用户能够搜索所有的数据集合或者从中选择一部分进行搜索
Ø非功能需求：对系统提供服务或者功能的约束，如时间约束，开发过程的约束，标准等；
许多需求是非功能性的，只能够描述系统的属性或者系统环境的属性。 例：系统能够在1分钟内处理100次交易。
m3.FURPS+需求模型
缩写FURPS 描述了需求的主要类别：
ØFunctionality（功能性）
ØUsability
（可用性）
ØReliability
（可靠性）
ØPerformance
（性能）
ØSupportability（可支持性）
Ø功能性
•特性集（featuresets)
•功能（capabilities）
•安全性（security）
Ø可用性
•人性化因素(RelatedConcepts: User-Centered Design)
•美学特性(aesthetics)
•用户接口的一致性（consistencyin the user interface）
•在线和上下文相关的帮助（onlineand context-sensitive help）
•智能助手（wizardsand agents）
•用户文档（userdocumentation）
•训练材料（trainingmaterials）
Ø可靠性
•失效频率和严重性（frequencyand severity of failure）
•可恢复性（recoverability）
•可预测性（predictability）
•精度（accuracy）
•平均失效时间（meantime between failure (MTBF)）
Ø性能
•速度（speed） 效率（efficiency）
•可用性（availability） 精度（accuracy）
•吞吐量（throughput） 响应时间（response time）
•恢复时间（recoverytime）
•资源利用率（resourceusage）
Ø可支持性
•可测试性（testability）
•可扩展性（extensibility）
•适应性（adaptability）
•可维护性（maintainability）
•匹配性（compatibility）
•可配置性（configurability）
•可服务性（serviceability）
•可安装性（installability）
•本地化，国际化(localizability,internationalization)
mFURPS+中的“+”号意味着还有一些其他的约束，如:
Ø设计约束（design constraints）
Ø实现需求implementation requirements
Ø接口需求interface requirements
Ø物理需求physical requirements
Ø包装Packaging
Ø授权等等Legal-licensing and so forth
2.2 基于用例的需求描述
m1.参与者、场景、用例
Ø参与者（actor）：是某些具有行为的事物，可以是人（由角色标识）、计算机系统或是组织。
Ø 场景（scenario）：是参与者和系统之间特定的活动和交互，也称为用例实例（use
case instance）。场景是使用系统的一个特定情节或用例的一条执行路径。
什么是用例
Ø“一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值”
Ø 描述了从参与者角度看系统（黑盒子）做了什么
Ø 用例模型本身不是面向对象建模技术
m2.用例的好处
Ø从用户的角度获取操作性需求
Ø 对系统的功能进行清晰而一致的描述
Ø 系统测试的基础
Ø 提供了从功能需求跟踪到系统中真正的类和操作的能力
m3.理解用例
Ø 用例是需求，而且主要是功能需求。
Ø 用例是需求，而不是功能或者特征列表。
Ø 用例是文档，而不是图，用例建模主要是写文字，而
不是画图。
Ø 用例Use Case:一组相关的成功和失败场景集合，用
来描述参与者如何使用系统实现其目标
m4.用例的表示法
Ø摘要：简介描述用例，通常只给出主成功场景。
Ø 非正式：用若干非正式段落来描述用例，通常给出多个不同场景。
Ø 详述：详细描述用例，通常给出所有的步骤及场景，并给出前置和后置条件等细节。
m绪言
Ø范围：系统用例，业务用例
Ø级别：用户目标级别，子功能级别（可被许多用例重复使用的）
Ø主要角色
Ø涉众
Ø前置条件和后置条件
m主成功场景和步骤（或基本流程）
m扩展（或替代流程）
m特殊需求：非功能性需求，质量属性或约束
m技术和数据变元表：用户对如何实现系统的要求
m范围：业务用例
m级别：用户目标
m主要参与者：学生
m涉众及其关注点：
Ø—学生：希望能网上选课，并可以准确获知待选课程和待修学分，并快速完成选课。
Ø—教务管理员：希望准确记录每个学生的选课情况，并能自动筛选统计选修每门课程人数，方便进行课程班的设立和授课教师的安排。有较强的容错能力。
Ø—教师：希望方便准确查询选课学生的名单。
m前置条件：教务管理员已经设立好待选课程，并开发网上选课。
m后置条件：记录学生的选课信息，更新选课数据库。
m主成功场景(基本流程)：
Ø1.学生输入学生证号以及个人密码；
Ø2.系统识别学生身份的有效性；
Ø3.系统对学生进行注册识别；
Ø4.系统显示学生本学期的待选课程
Ø5.学生自己要上的课程并确认；
Ø6.退出时，系统给出所选课程列表及相应学分合计。
m扩展（替代流程）：
Ø2a.学生身份检查失败，提示重新输入（3次机会）。
Ø3a.注册识别失败，提示没有注册（尚未交学费）的学生不能选课。
Ø5b.选择课程确认失败，所选几门课程中在上课时间上发生冲突时，系统提示重选。
m特殊要求：
Ø1.能同时允许2000以上人同时进行选课；
Ø2.系统应具备较强的数据恢复能力；
Ø3.选课期间每个2小时数据备份一次
m技术和数据变元表：
Ø1.支持网上选课。
Ø2.能自动进行上课时间是否冲突以及选课学分是否满足要求的判断。
m发生频率：
Ø每学期末发生频率高约20000人次，其他时间不选课。
m5.用例的作用
Ø可作为计划的基础。可以估算实现每个用例所需的时间和资源
Ø可用来捕获功能需求。它们是分析、设计和实现的基础
Ø可作为软件测试的基础。测试人员可将那些在用例中描述的消息序列以及动作序列作为测试脚本来验证系统的功能
Ø可作为文档的基础
2.3 用例的获取
m1.主要过程
Ø（1）选择系统边界
Ø（2）寻找参与者
Ø（3）确定每个参与者的目标
Ø（4）定义用例
m2.确定系统边界
可能的系统：
Ø整个组织：如一个企业；
Ø一个组织的某个部门：如企业的财务处；
Ø计算机系统的硬件/软件边界：如企业的进、销、存计算机管理系统。
系统边界作用：
Ø定义系统问题域的目标、任务、规模及系统提供的功能。
Ø系统中所有元素与系统外事物的分界线
m3.寻找参与者
参与者是与系统交换数据的实体。参与者可以是用户，外部的硬件或者另外一个系统。
m1）参与者的识别。可通过以下问题进行寻找：
Ø系统的主要客户是谁？
Ø谁从该系统中获取信息？
Ø谁向系统中提供信息？
Ø谁来安装系统？
Ø谁来操作系统？
Ø谁来关闭系统？
Ø在预定的时刻，是否有事件自动发生？
Ø谁使用或者删除系统中的信息？
Ø系统从何处获得信息？
m2）参与者的分类
Ø主要参与者：从系统获取信息的用户，是执行系统主要功能的参与者。（何种服务、业务需求、时间、性能及接口等）
Ø次要参与者：仅仅给用例提供某种服务。（何种服务、时间、性能、接口等）
m3）参与者的职责
Ø启动者：何种事件、时间因素、接口
Ø服务者：何种服务、接口、时间、数据量等
Ø接收者：何种信息、接口
Ø辅助者：何种服务、接口
m4）参与者和系统边界的关系
m5）参与者的规约模板
m4. 定义用例
一般而言，为每一个用户目标定义用例
Ø用例名称以动词开头
Ø将CRUD (create, retrieve, update, delete)这些分散的目标合并成一个CRUD用例：管理
<X>
m1）定义用例的粒度
Ø大的用例，如：我们的企业需要拓宽销售渠道；
整个系统就只有一个用例!!!
Ø小的用例，如：输入口令；
系统中可能有成百上千个用例!!!
m2）用例的经验方法
Ø老板测试
•老板是付钱的人
•老板必须看到可量化的价值
ØEBP（elementary business processes）用例
•定义：一个人于某时刻在一个地点所执行的任务，用以响应业务事件。该任务能够增加可量化的业务价值，并且以持久状态留下数据。例如批准信用卡额度。
•关注于基本业务过程层面上用例
Ø规模测试
•用例通常应该包括多个步骤
•在详细描述的情形下，应该需要3-10页文本
m3）用例的分类
根据用例产生的阶段，可把用例分为业务用例和系统用例。
Ø业务用例
•系统提供的业务功能与执行者的交互，描述问题域中各实体之间的联系和业务往来。
Ø系统用例
•系统用例是指执行者与系统的交互，它描述系统的功能需求和动态行为。对于建立的每一项业务用例，都需要一组系统用例来辅助和支持。系统用例可通过分析系统的业务流和控制流来确定。
2.4 用例图
用例图是表达用例和参与者及其之间关系的载体。
由主题（subject）、
参与者、用例、
关系组成。
m1. 参与者与用例之间的关系
参与者类和用例类之间的关系是关联关系，它指明了参与者类和包含用例类的系统之间的通信关系
m2.用例之间的关系
1)包含关系(include)
一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。
m2)扩展关系(extend)
扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。以下情况，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为；
b.表明只在特定条件（如例外条件）下才执行的分支流；
c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
3)泛化关系(Generalization)
一个用例也可以被特别列举为一个或多个子用例，这种关系称作泛化关系：
n父用例能够被使用时，任何子用例也可以被使用
n子用例可以存取和修改由父用例定义的属性
n子用例行为序列中必须包含其父用例的行为序列
n子用例可以在继承自父用例的行为序列中插入其它与父用例无关的步骤
m3. 参与者之间的关系
参与者之间可以存在泛化关系。
m4.建模技术
Ø对系统语境建模
给定一个系统，会有一些事物存在与它的内部，一些存在与外部。存在于系统内部的事物的职责是完成系统外部事物期望系统提供的行为。
所有存在与系统外部并于系统进行交互的事物构成了该系统的语境（context）。语境定义了系统存在的环境。
对系统语境建模，所强调的是围绕在系统周围的参与者。
语境建模策略
u决定哪些行为是系统的一部分以及哪些行为是外部实体所执行的，以此识别系统的边界。这也同时定义了主题。
u考虑以下几组事物来识别系统周围的参与者：
u需要从系统中得到帮助以完成其任务的组
u执行系统的功能时所需要的组
u与外部硬件或其它软件系统进行交互的组
u为了管理和维护而执行某些功能的组
u将彼此类似的参与者组织成一般/特殊层次结构
u在需要加深理解的地方，为每个参与者提供一个构造型。
Ø对系统需求建模
需求是系统的设计特征、特性或行为。陈述系统的需求，相当于陈述系统外部的事物与系统之间建立的一份合约，该合约声明了希望系统做什么事。大多数情况下，并不关心系统怎么做。
需求建模策略
u通过识别系统周围的参与者来建立系统的语境。
u对于每个参与者，考虑它期望的或需要系统提供的行为。
u把这些公共行为命名为用例。
u分解公共行为，放入新的用例中以供其他用例使用；分解异常行为，放入新的用例中以延伸较为主要的控制流。
u在用例图中对这些用例、参与者以及他们的关系进行建模
u用陈述非功能需求的注解或约束来修饰这些用例。
m提示语技巧
一个结构良好的用例图，应满足一下要求：
Ø关注与系统的静态用例视图的一个方面的通信
Ø只包含那些对于理解这个方面必不可少的用例和参与者。
Ø提供与它的抽象层次相一致的详细标示，只能加入那些对于理解问题必不可少的修饰（比如扩展点）
Ø没有简化到使读者误解其重要的语义的程度。
绘制用例图的策略
Ø给出一个表达其用途的名称。
Ø摆放元素时，尽量减少线的交叉。
Ø从空间上组织元素，使得在语义上接近的行为和角色在物理位置上也接近。
Ø用注解和颜色作为可视化提示，以突出图的重要的特征。
Ø尝试不显示太多的关系种类。
小结
m用户模型视图从用户角度来描述系统所应具有的功能，其基本成分是系统、参与者和用例
m参与者是与系统发生交互作用的外部用户、进程或其它系统的理想化概念。一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者。每个参与者可以参与一个或多个用例
m参与者之间可以存在泛化关系，参与者和用例存在之间存在通信关系，用例之间则可以存在包含、扩展和泛化三种关系