用例和用例图分析
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.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) 什么叫事件流,作用是什么？
实验报告1--用例和用例图
中北大学软件学院实验报告
专业：软件工程
方向：软件开发与测试
课程名称： UML
班级：
学号：
姓名：
辅导教师：井超
2017年3月制
4.用例图如下所示
1).系统参与者
系统角色
2).图书管理
图书管理用例图3).图书借阅和还书用例图
图书的借阅和归还用例4).图书管理系统的整体用例图
图书管理系统的整体用例图
5.实验结论及心得
通过本次实验，我掌握了在课堂上学习的用例图等。
加深了对书本知识的认识和记忆。
在实验中我学会了去如何操作ro se工具图。
通过ro se工具图，可以去清晰的去展示一个关系等。
使用非常方便。
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
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用例图的建模(续) 用例图的建模
餐馆系统用例及用例图
•记录预约(Recork booking)事件路径：1接待员输入要预约的日期2系统显示该日的预约3有一张合适的餐桌可以使用：接待员输入顾客的姓名、电话、预约的时间、用餐人数和餐桌号4系统记录并显示新预约。
可选或例外的事件路径3a 没有可用的餐桌:1 没有合适的餐桌可以使用，用例终止3b 餐桌过小1 接待员输入顾客的姓名电话预约时间，用餐人数和餐桌号2 用餐人数多于餐桌容纳的人数，系统询问是否继续预约3 如果回答“否”, 用例将不进行预约而终止4 如果回答“是”, 预约将被输入，并附有一个警告标志。
•记录到达：(Record arrival)基本事件路径１领班输入当前日期２系统显示当天的预约３领班确认一个选定的预约已经到达４系统对此进行记录并更新显示器，将顾客标记为已经到达。
可选或例外的事件路径3a 没有提前预订：1 系统中没有记录该顾客的预约，领班输入预约时间、人数和餐桌号，创建一个未预约登记；2 系统记录并显示新预约//将红字的部分，独立为一个用例，用例描述如下：●记录未预约顾客(Record walk_in)基本事件路径1 侍者领班执行“显示预约”用例2 侍者领班输入时间、用餐人数和分配给顾客的餐桌3 系统记录并显示新预约●取消预约(Cancel booking)基本事件路径1 侍者领班执行“显示预约”用例2 接待员选择要求的预约3 接待员取消该预约4 系统询问接待员确认取消5 接待员回答“是”，系统记录取消并更新显示可选或例外的事件路径4a 预约的时间是在该现时间之前1 系统显示，预约的时间是在该查询时间之前，2 系统显示不能取消过去某段时间的预约4b 已经记录了顾客到来的预约1 系统显示不能取消该预约 调换餐桌（Table transfer）基本事件路径1 侍者领班选择需要的预约2 侍者领班改变该预约的餐桌分配3 系统记录改变并更新显示•显示预约（Display Bookings）:1用户输入一个日期2系统显示当日的预约。
用例和用例图分解
4.1.1 用例
• 怎样识别用例 – 参与者需要从系统中获得什么功能？参与者需要做什 么？ – 参与者读取、产生、删除、修改或存储系统的哪些信 息？ – 需要将系统的哪个事件告诉参与者？ – 需要将外界的哪些信息提供给系统？（输入、输出信 息） – 采用什么实现方法满足特殊要求？
图书管理系统的用例图
• 用例是代表系统中各个项目相关人员之间根据系统的行为 所达成的契约。用例描述了在不同条件下，针对某一项目 相关人员的请求，系统对其作出的响应。也就是说用例指 的是对一组动作的描述，系统通过执行这些动作将对用例 的参与者产生可以看到的结果。用来描述参与者可以感受 到的系统服务或功能。
4.1.1 用例
• 关联（accociation）
– 每个用例都有活动者启动（每个用例必须和一 个活动者关联，有一个活动者来参与），除包 含和扩展用例
– 无论用例和活动者是否存在双向数据交流（无 论是参与者提供信息给系统，还是从系统获取 信息），关联总是由活动者指向用例，只用单 向箭头。
4.2.2 包含关系
• 包含（include） （是一种依赖关系，加了版型<<include>>）
置正文的字体为宋体
借
书
还
书
图4.5 用例
4.1.1 用例
• 怎样确定用例的粒度？（用例规模的大小）
– 用例的粒度可大可小，一般一个系统控制在20 个左右，但没有严格规定
– 用例是系统级的、抽象的描述，不是细化的 （考虑的是“做什么what”，而不是“怎样做 how”）
– 对复杂的系统可以划分为若干子系统处理
– 包含关系指的是两个用例之间的关系，其中一个用例 （称为基本用例）的行为包含了另一个用例（称为包含 用例）的行为。也就是说基本用例会用到包含用例。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
关联关系：参与者与用例之间的关系
用例图中，关联关系描述参与者与用例之间的关系，表示 参与者和用例之间的通信。
如果参与者启动了用例，箭头指向用例；如果参与者利用 了用例提供的服务，箭头指向参与者；如果二者是互动的， 则是直线。
“系统边界” 用来定义系统的界限，系统用例都置于其 中，参与者置于边界外。
储数据？如果是，如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？
泛化关系
包含关系（Include）
一个用例（基用例，基本用例）可以包含其他用例（包含 用例）具有的行为，并把它所包含的用例行为作为自身用 例的一部分，这被称为包含关系。
用例是一个事件流的集合，当某个事件流片段在多个用例 中出现时，可以将这个事件流片段抽取出来，放在一个单 独的包含用例中，简化基用例的描述。
扩展关系（Extend）
扩展关系表示基本用例（扩展用例）的行为。
基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
参与者之间的关系
参与者实际上是版型化的类，因此多个参与者之间 可以具有与类之间相同的关系。用例图中，使用泛化关 系来描述多个参与者之间的公共行为。
参与者的泛化
订餐系统参与者泛化
定义 用例定义了一组用例实例，其中每个实例都是系 统执行的一系列动作，这些动作可以对参与者产生有一 定价值的可观察到的结果。
部对该功能的具体实现。 3、用例描述了用户提出的一些可见需求，对应一个具
体的用户目标，即用例的执行结果对参与者有意义。 4、用例是对系统行为的动态描述，属于动态建模部分
此外，用例不是全部的系统需求，只是功能性的需求。
发现用例 用例的来源是参与者对系统的期望，所以识别用例
最好的方法是从客户的需求入手。识别用例过程中，以 下的问题可以帮助发现用例： 参与者为什么要使用该系统？ 参与者打算在这个系统里做些什么事情？ 参与者是否会在系统中创建、修改、删除、访问、存
第4章
用例和用例图
4.1 概述 4.2 建模参与者 4.3 用例 4.4 用例间的关系 4.5 边界 4.6 事件流与用例描述 4.7 用例图建模要点 4.8 用例图建模实例
用例模型是表达系统外部事物与系统之间交互的可视化 工具。当用例模型在外部事物面前出现时，它捕获到系 统、子系统或类的行为，将 系统功能划分成对系统用户 有用的需求。交互部分或功 能被表示成用例。
2、用例描述
用例描述模板
用例编号 [用例唯一标识符，通常格式为UCxx，在文档别处可以用标识符来引用该用例]
用例名称 [表明用户意图或用例的目标，一般是动词短语]
用例描述 参与者
前置条件 后置条件
[对用例目标的一个概要性的描述] [列出该用例的参与者，尤其是主要参与者] [即启动该用例所应该满足的条件。] [即该用例完成之后，将执行什么动作。]
系统实际运作中，一个实际用户可能对应系统的多个参与 者。如，一个人可以既是一个商店的售货员又是顾客
actor1
Icon形式
<<Actor>>
actor2
Label 形式
actor3
Decoration形式
寻找和确定参与者 获取用例前，首先要确定系统的参与者。询问以下
问题帮助确定参与者： 谁使用系统的主要功能？ 谁改变系统的数据？ 谁从系统获取数据？ 谁需要系统的支持以完成日程工作任务？ 谁负责支持和维护系统？ 系统需要控制哪些外部资源或硬件设备？ 系统需要和哪些外部系统交互？ 谁对系统运行结果感兴趣？
边界决定了抽象的层次。
用例描述的是一个系统做什么的信息，并不说明怎么 做。用例是对使用场景进行抽象的总结，形成一组事件流。 1、事件流
前置条件：用例执行前系统和参与者应处于做什么状态。 后置条件：用例结束后系统处于什么状态。 基本事件流：对用例中常规、预期路径的描述，是大部分
的时间所遇到的场景。 扩展事件流：对一些异常情况、选择分支进行描述。
主要流程 (基本事件流)
步骤 1 2
活动 [在这里写出触发事件到目标完成以及清除的步骤。] ……(其中可以包含子事件流，以子事件流编号来表示)
替代流程 (扩展事件流)
[表示是对1的扩展，其中应说明条件和活动] 1b ……(其中可以包含子事件流，以子事件流编号来表示)
子事件流 [对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。]
采用用例进行需求分析的特点： 1、用例由一组用例实例组成。用例实例也称为场景，
是参与者和系统之间一系列特定的活动和交互。场景是 使用系统的一个特定情节或用例的一条执行路径。
例 商场购物“付款”的用例 场景一：使用现金成功付款 场景二：银行卡付款被拒绝，付款失败。
采用用例进行需求分析的特点： 2、用例站在系统外部察看系统功能，而不考虑系统内
用例图展示了系统边界、 参与者（系统外部事物）、 用例以及它们之间的关系， 描述了参与者与系统交互的 情况以及系统的功能。
参与者（actor）：在系统外部与系统交互的人或事物， 它以某种方式参与系统内用例的执行。
位于系统（边界）之外
表示的是人或事物与系统交互时所担任扮演的角色
参与者不仅可以由人承担，还可以是其他的外部系统， 甚至是时间等。
规则与约束 [对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]
2、用例描述 常见用例描述错误：
只描述系统的行为，没有描述参与者的行为 只描述参与者的行为，没有描述系统的行为 在用例描述中就设定对用户界面的设计要求 描述过于冗长
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制；
从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例