用例图
02-用例和用例图
3.4.4 几种关系的比较
关系类型
说明
表示符号
关联
actor与use case之间
泛化
actor之间或use case之间
包含
use case之间
扩展
use case之间
用例图
用例图(use case diagram)是显示一组用例、角色以及它 们之间的关系的图.
在UML中, 一个用例模型若干个用例图描述.
角色
由于Actor实际上是一个特殊类, 因此它们之间可以 存在一定的关系,如：
脚本/场景
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况.
其它译名: 情景、情节、剧本.
每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
实例分析：语音邮箱系统----用例脚本
用例3: 登录系统 1. 邮箱用户完成邮箱号输入操作. 2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 3. 语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语.
实例分析：语音邮箱系统----用例脚本
用例4: 接收信息 1. 邮箱用户完成登录操作. 2. 邮箱用户选择 “接收信息”菜单选项. 3. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 4. 邮箱用户选择“收听当前信息”菜单选项. 5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 6. 语音邮件系统播放信息菜单. 7. 用户选择”删除当前信息”,则信息被永久删除. 8. 继续执行第3步.
第3章 用例图
为了保证系统正常运行，谁将对系统进行维护管理
（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
第5章 用例图
用例与事件流
• 用例分析处于系统的需求分析阶段，这个
阶段应该尽量避免考虑系统实现的细节问 题，这些细节问题写在事件流文件中。事 件流文件即用例的逻辑流程文档包括：
• 1. 简要说明：描述用例的作用； • 2. 前提条件：用例之前必须满足的条件；例：用户是否有运行权限 • 3. 事件流（主事件流、其他事件流、错误流 ）：描述参与者执行用
习题：
• 2、一台饮料自动售货机能提供6种不同的 、一台饮料自动售货机能提供6
饮料。售货机上有6 饮料。售货机上有6个按钮，分别对应于这 6中饮料，顾客可以通过按钮来选择所要的 饮料。每个按钮旁边有一个指示灯，用来 表明该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽，用来收钱 和找钱。
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
3. 系统管理员进行系统维护的用例
① 查询借阅者信息 ② 查询书籍信息 ③ 增加书目 ④ 删除或更新书目 ⑤ 增加书籍 ⑥ 删除书籍 ⑦ 添加借阅者帐户 ⑧ 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 使用Rational Rose绘制用例图 的步骤
扩展关系
• 扩展用例被定义为基础用例的增量扩展，这称作
扩展关系。
用例间的扩展关系
扩展关系例子
扩展关系指的是基础用例执行的情况下可选择是否执行提供者用例。
泛化关系
• 父用例也可以被特别列举为一个或多个子用例。 • 子用例从父用例处继承行为和属性，还可以添加
行为或覆盖、改变继承的行为。
用例间的泛化关系 泛化关系例子
例的具体步骤； • 4. 事后条件：用例执行完毕后必须为真的条件。例：用例完成之后 设置一个标志，这种信息就是事后条件。
第6章 用例图
3、构建用例模型
采 购 员 用 例 图
采购员能够通过该系统进行订货管理活动。采购员首先根据经营情 况统计所缺的生产资料，根据需要制定出订单。
UML统一建模语言
五、使用Rose创建用例图的步骤说明
3、构建用例模型
会 计 用 例 图
会计负责产品的统计分析 管理，它能够通过该系统 进行如下活动： （1）查询基本信息。会计 能够查询产品的基本信息， 根据产品的基本信息，制 定出相应的方案。 （2）查询销售信息。会计 根据销售情况汇总后交销 售部制定合理的销售方案。 （3）查询供应商信息。会 计能够查询供应商信息。 （4）查询缺货信息。会计 能够查询缺货信息。 （5）查询报损信息。会计 能够查询报损信息。
1、需求分析
“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息 统计订货的，并制作产品订单。最后根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、 处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产 品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及 时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进 行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、 查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使 用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定 价计算出产品的总价，客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、 供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登 录到各自的管理系统中。
用例图
用例图百科名片用例图就是由主角、用例以及它们之间的关系构成的图。
该图说明了用例模型中的关系。
简介用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。
用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
ps: 提取出“名词”，画用例图构成用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
参与者参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
用例及用例图案例
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？
用例图
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。
用例图-包含、扩展、泛化
⽤例图-包含、扩展、泛化
⽤例图=参与者+⽤例
参与者在图中表⽰为⽕柴⼈⼀样,⼈、物、系统都能分为参与者
⽤例通常使⽤圆形来表⽰.
参与者去使⽤⽤例这个功能
⽤例和⽤例之间的关系有⼏种情况:
包含:⼀个⽤例有时会包含另⼀个⽤例,在图中使⽤虚线和箭头来表⽰
就像是借书->查书,想要借书,就必定要进⾏查书,所以说借书⽤例包含查书
扩展关系:分俩种情况:⼀种是可选,⼀种是特殊.
扩展关系有时候就像if⼀样,当发⽣⼀些情况的时候,或者你想额外做什么的时候,从原实例扩展出⼀个新的实例应对特殊情况或者额外可选操作,则说新 实例是扩展于原实例的.
特殊:扩展关系是被扩展⽤例的⼀种特殊情况,就⽐如扩展⽤例是有时候会发⽣的特殊情况,如迟到和上课,迟到就是由上课扩展的⽤例.
可选:可选的操作,是由原来的实例扩展出来可选的操作,就⽐如取票和打印凭证,
可以说必定发⽣⽤<<include>>(包含),可能发⽣使⽤<<extend>>(扩展)
泛化关系<<generalization>>,⼀般使⽤实现+空三⾓形来表⽰.
泛化⼀般指的就是⼀般和特殊的关系,就像是⽗类和⼦类的关系,如同er图的超类,⼦类是⼀种特殊的⽗类类型
就⽐如缴费⽤例和线上缴费、线下缴费之间,线上缴费和线下缴费就是缴费⽤例的⼦类,由⼦类指向⽗类的<<generalization>>关系. 泛化关系就是描述⽤例的⼀般和特殊关系.。
用例图(User Case)
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
UML功能模型（用例图）
UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。
下⾯就说⼀说功能模型——⽤例图。
⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。
⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。
⽤例图展⽰了⽤例之间以及⽤例与参与者之间是怎样相互联系的。
⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。
参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。
参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。
注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。
⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。
⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。
⽤例粒度（规模⼤⼩）。
关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。
调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。
2.设计模式常用的UML图分析（用例图、类图与时序图）
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
第2章用例和用例图
成绩管理
UML用例图组成( UML用例图组成(续) 用例图组成
饮料销售机
UML用例图组成( UML用例图组成(续) 用例图组成
用例与用例的扩展关联用来表示通过对已有用例增加步 用例与用例的扩展关联用来表示通过对已有用例增加步 扩展关联用来表示 骤创建一个新的用例,即对原有的用例进行了扩展。 骤创建一个新的用例 即对原有的用例进行了扩展。扩展只能 即对原有的用例进行了扩展 发生在基用例的序列中的某个具体指定点上。这个点叫做扩 发生在基用例的序列中的某个具体指定点上。 展点.在UML图中，使用带虚线箭头表示，并在线上标有构造 展点 在UML图中，使用带虚线箭头表示， 图中 带虚线箭头表示 如下图所示： 型<<extend>> 。如下图所示：
UML用例图组成( UML用例图组成(续) 用例图组成
包含关联与扩展关联的区别： 包含关联与扩展关联的区别：
存在包含关联的两个用例,在执行基本用例时 一定会执 存在包含关联的两个用例 在执行基本用例时,一定会执 在执行基本用例时 行包含用例；存在扩展关联的两个用例,在执行基本用例时 在执行基本用例时, 行包含用例；存在扩展关联的两个用例 在执行基本用例时 可以执行,也可以不执行扩展部分 可以执行 也可以不执行扩展部分. 也可以不执行扩展部分
UML用例图的作用( UML用例图的作用(续) 用例图的作用
• 用例图的主要作用： 用例图的主要作用：
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础，驱动各阶段的开发工作 作为开发过程的基础， – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步. 画好用例图是由软件需求到最终实现的第一步.
UML用例图的建模( UML用例图的建模(续) 用例图的建模
用例和用例图
技巧 实地观察
访谈
描述
• 直接观察个人工作旳情况，以发觉现存旳实践方式和
问题
• 从个人处搜集特定信息
特定群体 调查
对一组人员进行调查，以便了解工作态度和共同看法
• 问卷调查 搜集详细数据和统计意义上比较主要旳数据
• • 顾客指 导
让最终顾客告诉你，他们是怎样操作系统旳
• 原型制作 模拟一种无法直接测试旳系统
人、外部系统、外部因素等
12
3.2.2 辨认参加者：参加者要点
• 参加者指在系统中所扮演旳角色。即在拟定参加者时，
应主要考虑他旳角色，而不是这个角色旳实例。
• 某些组织中可能有诸多营销人员，但他们均起着同
一种作用，扮演着相同旳角色。
• 一种顾客也能够扮演多…种角色：一种高级营销人员
既能够是贸易经理，也能够是一般旳营销人员。
小一点旳蓝色大理石
5
3.2.1 获取原始需求：如此脆弱
客户/顾客旳要 求/想法/期望
验收
分析和设计
没价值旳 软件需求
补文档
软件产品 编码和测试
软件设计
6
3.2.1 获取原始需求：也需要开发
客户/顾客旳要 求/想法/期望
软件产品
开发
验收
编码和测试
有价值旳 软件需求
分析和设计
软件设计
7
3.2.1 获取原始需求：技巧
第三章 用例和用例图
1
3.1 概述
• 用例图着重从系统外部执行者旳角度来描述系统需要提
供哪些功能，执行者能够是人或外部系统。
2
3.1 概述
用例图旳构成元素
• 图中旳元素涉及：参加者、用例、某些表达关系旳连接
用例图(User Case)
用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。
按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
银行用例及用例图
4.4 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能, 通过一组用例可以描述软件系统能够给用户提 供的功能.
用例图可以作为整个系统开发过程中的开发依 据,指导和驱动其他模型.
2. 用例图的形式
取款用例描述实例
● 用例：取款 ●参与者：储户 ●操作流：
① 通过读卡机,储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号. ③ 储户键入密码,系统检验密码. ④储户按确认键,输入取款金额. ⑤ATM把帐号和取款金额传递给银行系统,取回确认信息 和帐户余额. ⑥ ATM输出现金,并显示帐户余额. ⑦ATM记录事务到日志文件.
① 管理员选择进入管理界面,用例开始. ② 系统提示输入管理员密码. ③ 管理员输入密码. ④ 系统检验密码.
A1：密码出错. ⑤ 进入管理界面,系统显示当前所建立的全部课程信息. ⑥ 管理员选择增加课程,管理员输入新课程信息. ⑦系统验证是否与已有课程冲突.
Ａ２：有冲突. ⑧系统填写新课程,并提示填写成功. ⑨系统回到管理主界面,显示所有课程,用例结束.
用例及用例图
张鲲
用例及用例图
4.1 用例 4.2 参与者 4.3 用例之间的关系 4.4 用例图 4.5 发现用例
4.1 用例
1. 用例的概念 用例use case: 表示参与者与系统的一次交互过程.
2.用例的表示 用例用椭圆表示
3. 用例的特点 ① 用例用于描述系统的功能,这个功能是外部
使用者看到的系统功能,不反映功能的实现方式.
● ⑥ 编制用例说明.
● 用例：退房结帐 ●参与者：柜台工作人员 ●说明：
① 工作人员启动退房结帐功能. ② 输入旅客标志信息. ③ 系统显示旅客入住信息. ④ 显示入住天数,费用. ⑤ 接收费用. ⑥ 打印发票. ⑦ 入住登记结束.
第2章 用例图
构建用例图的过程
步骤 2. 确定参与者及其目标
寻呼台系统。用户如果预订了天气预报，系统每天 定时给他发送天气消息；如果当天气温高于35度， 还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor？用户？气温？ 还是时间？ 回答：时间，或者是一个外部消息发送系统；时间 启动该用例功能，温度是启动之后的一个条件， 所以温度不应算为一个参与者。
用例的必要性
有助于理解系统需求 有助于正确设计系统功能 有助于正确建立需求与功能间的关系
构建用例图
问题详述
系统边界框
用例
用例
参与者
开发典型用例
用例之间的关系
用例之间的关系是可以结构化的。以下是三 种常见的用例关系 包含关系 扩展关系 泛化关系 对于简单的应用，独立用例就足够了。但是， 对于大型应用，组织用例的结构是会有帮助的。 复杂的用例可以用包含、扩展和泛化关系自小 型用例的基础之上构建起来。
修改历史记录* 关于用例的修改时间、原因和修改人信息等
问题*
决策* 频率*
与此用例开发相关的问题列表
关键决策列表 参与者访问该用例的频率
构建用例图的过程
步骤 1. 识别系统边界 步骤 2. 确定参与者及其目标 步骤 3. 确定用例 步骤 4. 确定参与者和用例之间的关系 用例模型的一些准则，书P108 每个用例必须给用户提供价值 用例的描述是非形式化的，但用例的关系 可以形式化
用例图的元素
参与者
一个参与者也可以由多个人来担任
这是错的
这是对的
用例图的元素
参与者
•我们建立的是
系统模型，而非 业务模型，所以 要站在系统的角 度对业务对象进 行有效的分类
02 UML用例图基础知识
表示符号
表示参与者与用例之间的通信，任何一方都可发送 或接收消息。
uc 继承关系，子用例将继承基用例 的所有行为、关系和通信关系，也就是说在任何使 用基用例的地方都可以用子用例来代替。
泛化关系在用例图中使用空心的箭头表示，箭头方 向从子用例指向基用例。 uc Use Case Model
参与者总是处在正在建模的系统的外部，不是系统
的组成部分，是与系统、子系统或类发生交互的外 部用户、进程或其他系统。
参与者有3大类，即系统用户、与本系统交互的其 他系统和一些可以运行的进程。
名称
说明
人
即用户，是最常用的参与者。例如，汽车租赁公司的汽车租赁者，即客
户。
其他的系统
在当前的项目范围外，建立与其他系统的接口。该类位于程序边界之外
注：任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的
用例。
2）用例图形表示
在UML中，用例使用一个椭圆来表示，用例的名称写在椭圆里，如 下图所示：
3）用例命名
用例是从用户的角度来描绘系统的功能，是根据所执行的实例来命名 的，通常情况下，用例名是一个短语，例如浏览帐户、登陆系统等。 命名的基本原则有以下几种：
一、什么是用例图（Use Case Diagram） 二、用例图的组成 三、用例建模技术
用例图也称为用户模型图，是由软件需求分析到最终实现的第1步， 它是从用户的角度来描述系统功能，描述人们希望如何使用一个系统。 用例图显示谁将是相关的用户、用户希望系统提供什么服务，以及用 户需要为系统提供的服务。
线上标注<u<c Usee CaxsetMoedenl d>>)，箭头从子用例指向基用
例。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一个关于人事管理的详细用例，希望大家多提意见，多多交流！人事系统用例用例：设置部门（Set Department）角色：人事管理员（Personnel Manager）概述：设置部门用例用于建立维护组织结构，包括建立新部门、删除部门、编辑部门项目相关人员及其兴趣：λ人事管理员：希望能够快捷准确录入、修改、查询λ公司：希望系统能够形象、直观地显示公司部门组织结构，以利于管理和决策前置条件：无后置条件：系统对人事管理员对部门所作修改进行存储成功场景：1. 人事管理员发出“设置部门”请求2. 系统在屏幕上显示组织结构3. 人事管理员使用建立新部门、编辑部门、删除部门对组织结构进行修改4. 重复步骤3、4直到建立起人事管理员预期的组织结构可选场景：1. 建立新部门a. 人事管理员录入部门信息（上级部门、部门编号、部门名称、部门主管、备注）b. 人事管理员提交录入结果c. 系统记录新部门信息扩展场景：b.1人事管理员放弃提交，用例完成。
c.1 部门信息重复c.1.1 系统提示错误，用例完成2. 编辑部门前提条件：部门数据存在a. 人事管理员输入所需编辑的部门标识b. 系统定位并显示部门信息c. 人事管理员编辑部门信息d. 人事管理员提交编辑结果e. 系统更新部门信息扩展场景：b.1 待编辑部门不存在b.1.1 系统提示错误，用例取消d.1人事管理员放弃提交，用例完成e.1 部门信息重复e.1.1 系统提示错误，用例完成3. 删除部门前提条件：部门数据存在a. 人事管理员输入所需删除的部门标识b. 系统定位到相应部门c. 人事管理员删除部门d. 系统删除该部门记录扩展场景：b.1 删除部门不存在b.1.1 系统提示错误信息，用例取消d.1待删除部门拥有下级部门d.1.1 系统提示错误，取消删除操作特殊需求：1. 部门信息不能重复2. 拥有下级部门的部门不能删除3. 可按多种方式显示部门结构（如树形、图表形）用例：设置职位（Set Position）角色：人事管理员（Personnel Manager）概述：设置职位用例用于管理部门职位，包括增加职位、编辑职位、删除职位项目相关人员及其兴趣：λ人事管理员：希望能够快捷准确录入、修改、查询职位信息λ公司：希望系统能够形象、直观地显示公司职位，以利于管理和决策前置条件：部门信息已经设置后置条件：系统记录人事管理员对职位进行的修改成功场景：1. 人事管理员发出“设置职位”请求2. 系统显示职位表3. 人事管理员使用增加职位、编辑职位、删除职位对职位表进行修改4. 重复步骤3、4直到建立起人事管理员预期的组织结构可选场景：1. 增加职位a.人事管理员录入职位信息（职位编号、部门编号、职位名称、备注）b.人事管理员提交录入结果c.系统记录新职位信息扩展场景：b.1人事管理员放弃提交，用例完成。
c.1 职位信息重复c.1.1 系统提示错误，用例完成2. 编辑职位前提条件：待编辑职位数据存在a. 人事管理员输入所需编辑的职位标识b. 系统定位并显示职位信息c. 人事管理员编辑职位信息d. 人事管理员提交编辑结果e. 系统更新职位信息扩展场景：d.1人事管理员放弃提交，用例完成e.1 职位信息重复e.1.1 系统提示错误，用例完成3. 删除职位前提条件：职位数据存在a. 人事管理员输入所需删除的职位标识b. 系统定位到相应职位c. 人事管理员删除职位d. 系统删除该职位记录扩展场景：d.1待删除职位已经使用d.1.1 系统提示错误，取消删除操作特殊需求：1. 职位信息不能重复2. 已经使用的不能删除用例：管理人员（Manage Personnel）角色：人事管理员（Personnel Manager）概述：管理人员用例用于对公司员工信息进行维护及调动员工职位，包括增加人员、编辑人员信息、删除人员、查询人员信息和调动职位、制作人事报表项目相关人员及其兴趣：λ人事管理员：希望通过系统准确，快捷地完成人员信息的维护；系统能提供指定格式报表λ公司：希望系统保证人员信息的准确性；从多视角展示人员信息，为合理分配人力资源提供信息λ员工：希望系统保证自身信息的准确性；能方便维护，更新自身信息前置条件：部门信息、职位信息设置完成后置条件：成功场景：1．人事管理员发出管理人员信息请求2．系统在屏幕上显示人员信息3．人事管理员使用增加人员、删除人员、编辑人员信息对人员信息进行修改4．重复步骤3、4直到人事管理员预期的维护操作结束5．在2以后任何时候都可以调用查询人员信息、制作人事报表（可选场景）。
扩展场景：特殊需求：1. 人员信息不能重复2. 人员信息包括照片信息3. 增加、编辑人员信息时必须符合相应信息规则（名字不能为空）用例：增加人员（Add Personnel）角色：人事管理员（Personnel Manager）概述：增加新人员的信息项目相关人员及其兴趣：λ人事管理员：希望通过系统能快捷、准确地录入新人员信息公司：希望能准确记录人员信息λλ员工：希望能准确记录自身信息前置条件：后置条件：增加人员信息成功场景：1. 人事管理员发出“增加人员”请求2. 人事管理员录入人员信息3. 人事管理员提交人员信息4. 系统保存人员信息扩展场景：3.1 人事管理员放弃提交4.1 人员信息重复4.1.1 系统提示错误，放弃保存特殊需求：1. 人员信息不能重复用例：删除人员（Delete Personnel）角色：人事管理员（Personnel Manager）概述：删除人员信息项目相关人员及其兴趣：λ人事管理员：希望系统能准确快速的定位待删除人员信息，能提示以防止误操作公司：希望避免误删除λλ员工：希望避免误删除前置条件：员工信息必须存在后置条件：成功删除员工信息成功场景：1.人事管理人员输入待删除人员标识2.系统定位到待删除人员3.人事管理员确认删除4.系统删除人员信息扩展场景：2.1没有找到待删除人员2.1.1系统提示错误信息，用例结束3.1取消删除操作特殊需求：1.待删除人员与其他信息有特殊关联的不能删除（欠款、计划未完成等）用例：编辑人员信息（Delete Personnel Information）角色：人事管理员（Personnel Manager）概述：维护人员信息项目相关人员及其兴趣：λ人事管理员：希望系统能准确快速的定位和编辑待编辑人员信息；公司：希望人员信息准确λλ员工：希望人员信息准确前置条件：存在员工信息后置条件：正确维护人员信息成功场景：1．人事管理员输入待编辑人员标识2．系统定位到待编辑人员3．人事管理员编辑人员信息4．人事管理员提交编辑结果5．系统保存编辑记录扩展场景：3.1 待编辑人员信息不存在2.1.1系统提示错误，用例结束4.1 人事管理员取消提交特殊需求：1．一些特殊项目信息限制修改（工资，奖金）？用例：查询人员信息（Query Personnel Information）角色：人事管理员（Personnel Manager）、员工（Personnel）概述：根据相关条件查找人员信息项目相关人员及其兴趣：λ人事管理员，员工：希望系统快速、准确的查找出符合条件的人员信息前置条件：存在员工信息后置条件：查找出符合条件的人员信息成功场景：1．系统使用者输入查询条件2．系统查找并显示符合条件的人员信息扩展场景：特殊需求：1．输入查询条件合法2．当无符合条件人员时，系统给出提示用例：生成人员报表（Create Personnel Report）角色：人事管理员（Personnel Manager）概述：根据要求生成出指定内容、格式的报表项目相关人员及其兴趣：λ人事管理员，其他报表需求者：希望系统能按指定格式、内容，准确、快捷地制作出报表前置条件：存在人员信息；人员报表模板列表不为空后置条件：生成出指定内容、格式的报表成功场景：1. 人事管理员发出“生成人员报表”请求2. 系统显示人员报表模板列表3. 人事管理员选择报表模板4. 系统提示相应查询条件5. 人事管理员输入查询条件并请求系统查询6. 系统生成并显示指定格式、内容的报表“可选”场景：7.1人事管理员请求保存报表7.2人事管理员请求打印报表特殊需求：用例：调动职位(Redeploy Position)角色：人事管理员(Personnel Manager)概述：调动职位用于对人员职位进行调整。
项目相关人员及其兴趣：λ人事管理员：希望系统能快速准确时进行调动职位公司：希望系统能对调动操作进行记录λλ员工：希望系统能准确调动职位前置条件：人员信息、职位信息存在后置条件：将修改的员工职位存储，并记录调动记录成功场景：1. 人事管理员录入待调动职位人员标识2. 系统查找定位并显示人员职位信息3. 人事管理员录入员工新职位4. 系统对人员进行更新职位，并记录调动记录5. 在2以后，可以进行“分配职位”、“撤销职位”可选场景可选场景：1. 分配职位前置条件：待分配职位人员没有设置职位a.人事管理员录入人员新职位b.系统对人员进行分配职位，并记录调动记录2. 撤销职位前置条件：待分配职位人员已经设置职位a.系统撤销人员职位，职位设置为空，并记录调动记录扩展场景：2.1 没有找到人员2.1.1 系统提示错误，用例取消特殊需求：用例的用途是在不揭示系统内部构造的情况下定义联贯的行为。
用例描述了系统具有的行为，但是没有规定怎样实现这些行为，它是从用户的角度来看系统的特定方式。
…账户登陆‟是操作包的其中一个用例。
因其属于网络游戏最基本的功能，所以选取它来说明开发过程。
步骤1：描述用例及其事件流用例描述：注册用户在官方网站帐户登陆页面上输入ID和密码登陆管理个人帐户。
主事件流：1．用户点击主页上的登陆按钮，开始用例。
2．系统显示登陆页面。
3．用户输入ID和密码，然后点击登陆。
4．系统验证登陆信息和数据库一致，然后回到主页。
5．用例结束。
其他事件流A1：如果用户点击登陆页面上的提示词按钮，系统在一个单独的对话框里显示为用户储存的提示词，用户点击确定按钮，系统页面回到登陆页。
其他事件流A2：如果用户输入了一个系统无法识别的ID，系统显示错误信息并提示用户输入一个不同的ID。
其他事件流A3：如果用户输入了一个不正确的密码，系统显示错误信息并提示用户输入正确的密码。
其他事件流A4：如果用户连续3次输入错误的密码，系统显示消息告诉用户无法再连接服务器，并且冻结登陆页。
步骤2：建立对象交互图交互图描述了系统的动态行为。
绘制对象交互图，首先是确定该用例所涉及的对象。
从用例说明中可以分析出包括Player、主页、登陆页、提示对话框、帐户记录这几个对象，对象之间通过发送消息进行交互。
下面就是“登陆帐户”的顺序图，它其实是一张表，X轴上排列着对象，Y轴上按时间顺序排列着对象之间发送的消息，最左边标明了消息所属的事件流。