用例图实例讲解
自动售货机用例图
自动售货机用例图 IMB standardization office【IMB 5AB- IMBK 08- IMB 2C】自动售货机用例图一实验内容：一台饮料自动售货机能提供六种不同的饮料，售货机上有六个按钮，分别对应于这六种饮料，顾客可通过按钮来选择所要的饮料。
每个按钮旁边有一个指示灯，用来表明该售货机中是否还有这种饮料可售。
售货机有一个硬币槽和找零槽，用来收钱和找零。
假设现在有一位顾客投币购买矿泉水，不用找零。
问题：请给出描述上述场景的用例图。
二用例描述：1）该用例的目的是描述自动售货机的用例图，来更好的学习用例建模；2）该用例在当有人想买饮料并到自动售货机钱塞硬币买饮料的时候被参与者即：顾客启动执行3）在用例中指示灯来提示哪种饮料有得买，哪种饮料没有卖；每种饮料有各自的按钮来供顾客选择要买的饮料；行为者：顾客；用例：按钮，指示灯，投币槽，退币槽；按钮是用来供顾客选择要选择的饮料；指示灯是来显示对应的饮料是否可售；投币槽供顾客投币买饮料的；退币槽式用来退剩下的钱币；三自动售货机的对象图：四用例图：指示灯提示饮料是否可售吐饮料五实验小结：1）在本次实验中初次使用Rational Rose来画用例图，在画用例图之间要寻找并确定行为者，以及寻找并确定用例；2）一个用例表示系统中一个与特定行为者相关的完整功能。
用例通过关联与行为者链接，关联指出一个用例与哪些行为者交互，所以在确定了行为者和用例之后，要理清楚各个用例之间的关系，在画用例图时候才能够顺手，才能过完成自动售货机系统中的一系列动作，才能特定行为者一个可观擦到的结果值；。
UML中的用例图和活动图的关联性解析与实例分析
UML中的用例图和活动图的关联性解析与实例分析UML（统一建模语言）是一种广泛应用于软件开发领域的图形化建模语言。
在UML中，用例图和活动图是两种常用的图形表示方法，它们可以相互关联，以提供更全面和准确的系统设计与分析。
本文将对UML中的用例图和活动图的关联性进行解析，并通过实例分析来进一步说明其应用。
用例图是一种用于描述系统功能和用户需求的图形化工具。
它主要由参与者（actors）和用例（use cases）组成。
参与者代表与系统进行交互的外部实体，而用例则代表系统的功能或者用户需求。
用例图通过参与者和用例之间的关系来描述系统的行为和功能，从而帮助开发人员更好地理解系统的需求。
活动图是一种用于描述系统行为和流程的图形化工具。
它主要由活动（activities）、控制流（control flows）和决策节点（decision nodes）等元素组成。
活动图通过活动之间的控制流和决策节点来描述系统的流程和行为，从而帮助开发人员更好地理解系统的运行过程。
用例图和活动图之间存在一定的关联性。
首先，用例图可以作为活动图的基础，用例图中的用例可以被转化为活动图中的活动。
例如，一个用例图中的用例可以被视为一个活动图中的一个顶级活动，而用例图中的参与者可以被转化为活动图中的活动所依赖的资源。
其次，活动图可以进一步细化用例图中的用例。
用例图通常只能描述系统的高级功能和行为，而活动图可以更加详细地描述系统的具体流程和行为。
通过将用例图中的用例转化为活动图中的活动，可以更好地理解系统的运行过程，从而更好地进行系统设计和分析。
为了更好地说明用例图和活动图的关联性，我们以一个在线购物系统为例进行分析。
在该系统中，用户可以浏览商品、添加商品到购物车、下订单、支付等。
首先，我们可以使用用例图来描述系统的功能和用户需求。
用例图中的参与者可以包括用户、管理员等，而用例可以包括浏览商品、添加商品到购物车、下订单等。
用例图可以帮助我们更好地理解系统的功能和用户需求。
用例图设计实例：
实验二：建立动态模型一旦定义了一个工程的用例，就可以用它们来指导对系统的进一步开发。
用例的实现描述了相互影响的对象的集合，这些对象将支持用例所要求的功能。
给出系统用例的实现，是从外部视图转到内部结构的第一步。
在UML中，用例的实现用交互图来指定和说明。
交互图通过显示对象之间的关系和对象之间处理的消息来对系统的动态特性建模。
有两种交互图：序列图和协作图。
1、创建交互图的步骤交互图一步一步地显示用例的实现流程。
它包括流中需要什么对象、对象之间发送什么、什么角色启动流、消息按什么顺序发送等。
系统要求实现的所有不同情形都在交互图中记录。
通过从用例建模得到的用例文档说明、词汇表和用例图来创建交互图。
2、实例本节主要以选课系统中的选课用例（Select Course）为例，来学习序列图的设计与实现。
2.1 分析为了使问题更简单一些，不考虑学生的登陆。
假设学生已经成功登陆系统，选课的事件流如下：（1）学生进入选课主界面。
（2）学生点击选课。
（3）系统显示所有课程信息。
（4）学生选择课程。
（5）系统验证课程是否可选。
A1：课程不可选（6）系统提示课程选择成功，提示学生交费。
（7）用例结束。
A1：课程不可选（1）系统提示课程不可选及原因。
（2）学生重新选课。
（3）重新验证直至成功。
（4）转选课事件流第6步。
首先，查找Select Course用例的对象。
从事件流中发现涉及以下对象：（1）界面。
（2）课程。
（3）对于业务层的操作，也应该有对象进行处理。
（4）事件流中设计的角色有：学生、数据库。
然后，分析对象、角色之间交互的消息。
本用例主要有以下交互：（1）学生通过界面发送选课命令。
（2）界面向控制对象请求课程信息。
（3）控制对象向数据库发送查询数据消息。
（4）控制对象暂存数据库的查询结果。
（5）界面对象从控制对象中取得所有的课程信息。
（6）在界面上显示所有的课程信息。
（7）界面对象发送命令要求控制对象删除课程信息。
用例图
存款
4
3.1.1 用例
怎样确定用例的粒度？
用例的粒度（用例的大小）可大可小，一般一个系 统宜控制在20个用例左右。 用例是系统级的、抽象的描述，不是细化的（是做 什么，非怎样做） 对复杂的系统可以划分为若干子系统处理。
学籍 处理
退学处分
3.1.1 用例
怎样获取用例？
参与者希望系统执行什么任务？ 参与者在系统中访问哪些信息（创建、存储、修 改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？
3.1.3 关系
包含include
一个用例过于复杂，可以分解成小用例，构成包含 依赖（三个被包含的用例合起来实现完整的事件 流，不能单独调用）；
3.1.3 关系
扩展extend
一个用例（在某些扩展点上）扩展另一个用例的功 能 ，构成新用例； 扩展用例依赖于被扩展依赖（基本用例），只是部 分片断组成，不是完整的独立用例，无法单独执 行；
用例图
本章内容
组成 用例图 用例描述 用例分析 业务用例图 实例
2
3.1 组成
用例（Use Case） 参与者（角色，Actor） 关系（Relationship）
3
3.1.1 用例
Use Case:
系统、子系统或类与外部的参与者（actor）交互的 动作序列的说明，包括各种序列及出错序列。 用例分析可以认为是对系统功能的分解。
3.4 用例分析
识别参与者
已有的上下文关系图（表示系统范围）及其他相关模型：它 们描述了系统与外部系统的边界，从这些图中可以寻找出与 系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决 定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档（如会谈备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的参与者 通常是很重要的，因为他们在组织中所代表的角色就是可能 与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册：这些东西中经常会 有潜在参与者。
第二讲用例图.ppt
通过回答以下的几个问题识别用例：
特定参与者希望系统提供什么功能。 系统是否存储和检索信息，如果是，由哪个参与者触
发。 当系统发生改变时，是否通知参与者。 是否存在影响系统的外部事件。
哪个参与者通知系统这些事件。
还有两个针对整个系统的问题:(1)系统需要何种输入输 出？输入从何处来？输出到何处去？(2)当前运行系统 的主要问题一？个用这例两至个少问要题与一并个不参意与味者着关联没！有参与者也可以 有用例，只是获取用例时还不知道参与者是什么。
(2)为系统的功能提供清晰一致的描述，以便为后续的开 发工作打下良好的交流基础，方便开发人员传递需求的 功能。
(3)为系统验证工作打下基础。通过验证最终实现的系 统能够执行的功能是否与最初需求的功能相一致，保证 系统的实用性。
(4)从需求的功能（用例）出发，提供跟踪进入系统中 具体实现的类和方法，检查其是否正确的能力。
S-1：添加所选课程
系统提示含有课程名和课程代码的域，学生输入希望选修的 课程名和课程代码(E-3)，系统显示信息表示该课程可以选 修(E-4)，并建立该课程与该学生的连接(E-5)。用例重新 开始。
S-2：删除所选课程
系统提示含有课程名和课程代码的域，学生输入希望取消的 课程名和课程代码，系统删除该课程与该学生的连接(E-6)。 用例重新开始。
4.用例
（1）用例的概念
第五章 用例图
用例图的构成要素
2. 参与者间的关系
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即 参与者与参与者之间主要是泛化关系（或称为“继承”关系）。
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用 行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊 关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。
识别用例
Email客户端（如： outlook express）， A在北京发邮件给深 圳的B，系统提醒 B”你有新邮件”， B收邮件。
识别用例
一个论坛类的应用 ，用户可以提问， 别人来回答，如果 有自己问题被解答 的话，就给发问者 发一份邮件通知。 注意：发邮件这个用 例可以是单独的用 例，也可以是由回 答用例扩展出来的 用例
信息亭
例(包含关系)。
系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。
管理库存 打印报表
开放帐户 经理登录
货管员 经理
检索会员 检查帐户
时间
用例之间的关系
1. 包含
包含关系指用例可以简单地包含其他用例具有的行为，并把它所 包含的用例行为作为自身行为的一部分。在UML中，包含关系是 通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用 例(Base)指向被包含用例(Inclusion)。
用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales
参与者Clerk参与(或称发起)Buy tickets和
Buy Subscription 两个用例(关联关系)。这 两个用例的事件流都包含Make charges用
2 设计用例图的案例
孙旭光
灾害信息工程系
功能模型
在面向对象方法学中，可以使用UML提供的用例 图进行需求分析和建立功能模型。
也把用用例图建立起来的系统模型称为用例模型。
使用用例模型代替传统的功能说明，能更好地获取
用户需求，它所回答的问题是“系统应该为每个用
户做什么”。
用例模型描述的是外部行为者所理解的系统功能。
建立用例模型：银行账户管理系统需求陈述如下：
用例名称：开户 一个客户可以在多个银行中开设账户，一个客户也 参与者：银行职员（客户代理）、客户
前臵条件：一个合法的银行职员（客户代理）已登录到该系统 可在同一银行中开设多个不同的账户。客户可以通 事件流： 过银行职员进行开户、存款、取款、转账、注销账 1. 当选择开户功能时用例开始 2. 输入客户信息（姓名、地址、身份证号等） 户等活动。其中转账指客户将自己的某个账户上的 3. 从账户管理系统获取新的账号 钱转入同一银行的不同账户（称为银行内转账）或 4. 请客户输入密码 5. 请客户再次输入密码 转入不同银行的账户（称为银行间转账）。系统管 6. 如果两次密码不一致则回到第4步，否则继续 理员负责系统的账户管理及业务报表的生成。 7. 在账户库中添加新账户
注意寻找参与者时不要只考虑使用计算机的人！
用例图—参与者
参与者间的关系
用例图—系统边界
系统边界是指系统与系统之间的界限。
系统与环境之间存在边界，子系统与
其他子系统之间存在边界，子系统与 整体系统之间也存在边界。 用例图中的系统边界用来表示正在建 模系统的边界，边界内表示系统的组 成部分，边界外表示系统的外部。
8. 打印存折，用例结束 后臵条件：在账户库中增加一个新账户，得到一张新存折
用例及用例图案例
用例及用例图-案例
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) 什么叫事件流,作用是什么？
uml银行用例图解析
用例描述：开户用例图中，由管理员发起开户事务，储户提供账户信息、身份信息，管理员验证账户合法性和身份真实性后输入账户信息，储户设置密码，过程中涉及验证合法性（账户号正确、身份真实等）、添加账户信息等。
储户可以打印凭证。
ii. 销户MM用例描述：销户用例图中，主动销户由管理员发起销户事务，储户提供账户信息、身份信息, 输入密码，管理员验证密码正确身份真实性后输入账户信息，并验证账户余额，若有余额则返还给储户完成销户，若无余额直接完成销户。
过程中涉及验证合法性（密码正确、身份真实等）、处理余额、删除账户信息等。
储户可以打印凭证。
被动销户则需要进行销户判断（挂失子系统），若判断可以销户，则处理余额，完成销户。
iii. 冻结«ejdend»'、、O用例描述：冻结用例图中，主动冻结由管理员发起冻结事务，储户提供账户信息、身份信息,管理员验证密码正确身份真实性后输入账户信息，完成冻结。
过程中涉及验证正确性（密码正确、身份真实等）、修改账户状态信息等。
储户可以打印凭证。
被动冻结则需要进行冻结判断，若输 入密码大于三次，账户冻结。
iv. 挂失X用例描述：挂失用例图中，管理员需要用户输入账户信息，可以触发挂失事务，其中挂失事务包括生成挂失信息，获取余额信息以及销户触发判断，判断是否挂失一定时间，自动触发销户。
V.存款用例描述：存款用例图中，管理员需要用户输入账户信息，或者打印存款信息才可以触发存款事务，其中存款事务包括修改余额信息以及生成存款信息两个功能。
vi. 取款用例描述：取款用例图中，管理员需要用户输入账户信息，以及账户密码，经过余额验证才可以触发取款事务，其中取款事务包括修改余额信息以及生成取款信息打印凭证两个功能。
vii. 转账偲改余额用例描述：转账用例图中，由管理员发起转账事务，输入转账信息，其次储户通过验证账户密码可以完成转账，过程中涉及计算手续费、验证合法性（如余额足够、账户号正确等）、修改账户余额、生成转账信息等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对需求建模
① ②
识别系统的外部参与者来建立系统的语境。 考虑每一个参与者期望的行为或需要系统提供的 行为。 把这些公共的行为命名为用例。 确定提供者用例和扩展用例。 对这些用例、参与者和它们之间的关系建模。 用注释修饰用例。
③ ④ ⑤ ⑥
用例
外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。
不是需求或功能的规格说明，但是也展示和体现其所描述 的过程中的需求情况。
用例
① ②
用例的名称： 简单名 路径名
识别用例
识别用例最好的方法就是从分析系统的参与者开始，考虑 每个参与者是如何使用系统的。 如何识别用例。
泛化关系
父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继 承的行为。
用例图建模技术
对语境建模
对需求建模
对语境建模
① ② ③ ④
识别系统外部的参与者。 将类似参与者组织成泛化的结构层次。
在需要加深理解的地方，为每个参与者提供一个构造型。
5.1.4 用例间的关系
1 关联关系
2 包含关系
3 扩展关系 4 泛化关系
关联关系
表示参与者用例之间进行通信。 不同的参与者可以访问相同的用例。
包含关系
客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用 例行为作为自身行为的一部分。
扩展关系
扩展用例被定义为基础用例的增量扩展。 基础用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基础用例的扩展点上。
关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）
参与者
① ② ③
参与者的种类： 系统用户
与所建造的系统交互的其他系统
一些可以运行的进程
参与者间的关系
参与者间的泛化关系示例：
在用例图中，使用泛化关系来描 述多个参与者之间的公共行为。
实例——图书馆管理系统的用例图
1.借阅者 2.管理员处
3.管理系统
1. 借阅者请求服务的用例图
2. 图书馆管理员处理借书、还书的 用例图
3. 系统管理员进行系统维护的用例 图
用例图
用例图的概念 用例图建模技术
实例——图书馆管理系统中的 用例图
概述
用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户 需要为系统提供的服务。 用例图最常用来描述系统以及子系统。
概述
① ② ③ ④ ⑤ ⑥
用例图包含6个元素： 参与者（Actor）
用例（Use Case）