用例和用例图分析
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”）
– 对复杂的系统可以划分为若干子系统处理
– 包含关系指的是两个用例之间的关系，其中一个用例 （称为基本用例）的行为包含了另一个用例（称为包含 用例）的行为。也就是说基本用例会用到包含用例。
权限管理用例图及用例分析
管理员提交表单数据格式错误,系统提示错误信息
系统将数据写入数据库时失败,提示错误信息后置条件:无源自注释:无用例图用例描述
用例编号:006
用例名称:权限管理
优先级别：HIGH
参与者:管理员 一般用户
用例描述:
权限管理
前置条件:
1．用户成功登陆系统
基本事件流:
在权限管理的页面上，输入新员工信息
点击提交按钮
员工信息被修改、删除或被导出 个人可以查看自己的信息 登录
系统给出提示
其他事件流:
管理员在执行基本事件流过程中点击”取消”按钮,系统关闭表单页
第3章 信息系统分析与设计 用例及用例图
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
● ② 确定各参与者所期望的系统行为。
第49页，共87页。
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
①.泛化关系 ②.包含关系 ③.扩展关系
第31页，共87页。
1. 泛化关系
参与者与参与者之间，用例与用例之间存在一般与 特殊的泛化关系。
第32页，共87页。
2. 包含关系
两个用例之间，一个用例(基用例)的行为要用到 另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型来 表示。
②.在基用例执行的过程中，被包含的用例一定要被执行；
扩展关系如果条件不为真，扩展用例可以不执行。
③.包含关系中的基用例必须依赖被包含的用例，它不能
独立存在；扩展关系中的基用例可以独立存在。
第37页，共87页。
3.6 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能，通 过一组用例可以描述软件系统能够给用户提供的功 能。
3. 参与者的表示 参与者可以表示为下面三种形式。
第23页，共87页。
4. 参与者之间的关系 参与者之间可以有泛化关系。
第24页，共87页。
5. 参与者的特性 参与者具有以下特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系 ③.参与者与系统之间存在交互接口
第25页，共87页。
3.4 参与者与用例之间的关系
3.5 用例之间的关系 3.6 用例图
用例和用例图
访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架
用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂
事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。
扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
uml用例与用例之间的关系
UML用例与用例之间的关系1. 引言在软件系统开发过程中，需求分析是一个至关重要的环节。
用例是一种常用的需求表示工具，用来描述系统与用户之间的交互过程。
用例图是一种在统一建模语言（UML）中常用的图形化表示工具，它能够清晰地描述不同角色之间的交互以及系统的功能。
在用例图中，用例之间存在着不同的关系，这些关系能够帮助我们更好地理解和分析需求，从而有助于正确地设计系统。
2. 用例与用例之间的关系用例与用例之间的关系主要体现在用例图中的连接关系，以下是用例与用例之间可能存在的几种关系：2.1 包含关系（include）包含关系描述了一个用例（被包含用例）在执行过程中调用了另一个用例（包含用例）的场景。
被包含用例是包含用例的一部分，它们之间有一个可选的包含关系，即被包含用例可以选择是否执行包含用例。
包含关系在用例图中用带箭头的虚线表示。
举例来说，如果一个系统中有一个支付用例和一个生成订单用例，那么支付用例可以调用生成订单用例来创建订单。
但是在某些情况下，比如采用现金支付时，生成订单用例就可以不执行，所以这个关系是可选的。
2.2 扩展关系（extend）扩展关系描述了一个用例（扩展用例）在某个基本场景（基础用例）的执行过程中可以选择性地插入另一个场景（扩展用例）。
扩展关系使得系统的功能可以按需进行扩展，而不会影响基础用例的执行。
扩展关系在用例图中用带箭头的虚线表示。
以在线购物系统为例，基础用例是购物，而扩展用例可以是添加到购物车、查看商品详情等。
这些扩展用例可以根据用户的需求来选择性地应用，从而实现购物功能的扩展。
2.3 泛化关系（generalization）泛化关系描述了一个用例（子用例）继承了另一个用例（父用例）的属性和行为。
子用例可以复用父用例的功能，并在其基础上进行扩展或修改。
泛化关系在用例图中用带空心箭头的实线表示。
例如，一个系统有多种角色，比如管理员和普通用户，它们都可以登录系统，所以可以有一个登录用例作为父用例，而管理员登录和普通用户登录可以作为子用例，从而实现用例的复用。
需求分析工具
需求分析工具需求分析是软件开发过程中至关重要的一个环节，通过对用户需求的深入理解和明确梳理，可以有效地指导系统开发和设计工作。
本文将介绍几种常用的需求分析工具，包括用例图、状态图、数据流图和文本分析，并对其特点和适用场景进行简要分析。
一、用例图用例图是一种图形化的工具，用于描绘系统和用户之间的交互行为。
它主要由参与者（Actor）和用例（Use Case）组成。
参与者表示系统的各种不同角色，比如用户、管理员、系统等；用例表示系统的各种功能和操作。
用例图的主要特点是简洁明了、易于理解，能够直观地展示系统的功能和用户之间的交互方式。
它可以帮助开发团队清晰地了解用户需求，并将其转化为系统的功能模块。
用例图适用于大型系统或复杂的软件开发项目，能够帮助团队成员统一理解和沟通。
二、状态图状态图是一种描述系统在不同状态下的行为和转换的工具。
它通过状态（State）、事件（Event）和转换（Transition）来描述系统的行为和状态的变化。
状态图可以清晰地展示系统的状态转换和事件触发的关系，帮助开发团队更好地理解系统的行为。
状态图的主要特点是可视化、易于理解，能够清晰地表示系统的状态和转换规则。
它适用于需要描述系统状态和行为的需求分析场景，比如订单状态的变化、用户登录状态的转换等。
通过状态图，开发团队可以更好地理解系统的状态流转和状态变化，从而指导系统设计和开发。
三、数据流图数据流图是一种描述系统功能和数据流动的工具。
它通过各种处理过程、数据存储和数据流来描述系统的功能和数据流动。
数据流图可以清晰地展示系统的数据流动和处理过程，帮助开发团队理解系统的功能和数据流动。
数据流图的主要特点是简单明了、易于理解，能够清晰地描述系统的功能和数据流动。
它适用于需要分析系统功能和数据流动的需求分析场景，比如信息系统的输入、处理和输出等。
通过数据流图，开发团队可以更好地理解系统的功能和数据流动，从而指导系统设计和开发。
四、文本分析文本分析是一种通过对系统需求文本进行分析和处理，来理解需求的技术手段。
第三章 用例和用例图
系统边界
… 参与者透过系统边界直接与系统交互，参与者的确定代表
系统边界的确定
有意义交互
任何事物
人、外部系统、外部因素等
武汉大学国际软件学院
12
3.2.2 识别参与者：参与者要点
•
参与者指在系统中所扮演的角色。即在确定参与者时， 应主要考虑他的角色，而不是这个角色的实例。
•
• • •
某些组织中可能有很多营销人员，但他们均起着同 一种作用，扮演着相同的角色。 … 一个用户也可以扮演多种角色：一个高级营销人员
经理
用例C
•
如系统中经理可以参加雇员 的所有用例
武汉大学国际软件学院
21
3.2.2 识别参与者：泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
武汉大学国际软件学院
22
3.2.3 识别用例（use case） 分析典型用例是开发者准确迅速地了解用户要求的最常用 也是最有效的方法，是用户和开发者一起深入剖析系统功 能需求的起点。 “用例”是Ivar Jacobson于20世纪60~70年代在爱立信公 司开发AKE、AXE系列时发明的。
武汉大学国际软件学院
29
用例要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
武汉大学国际软件学院
30
用例 VS. 功能
•呼叫某人
•传输/接收 •电源/基站 •输入输出（显示、键盘） •电话簿管理 •……
•接听电话
•发送短信 •记住电话号码
•…… 用户观点
用例和用例图
如何绘制用例图 1、用例分析技术步骤（不固定，可根据需要调整）：
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ 找出系统外部的参与者和外部系统，确定系统的边界和范围。 确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 编制每一个用例的脚本 绘制用例图 区分基本事件流和异常情况的事件流，如有需要可以把表示异常 情况的事件流作为单独的用例来处理 ⑻ 细化用例图，解决用例间的重复与冲突。
用例之间的关系 4、参与者与用例之间的关系：关联关系Association
关联关系描述参与者与用例之间的关系，在UML中它是 两个或多个类元之间的关系，它描述了类元的实例间的 联系。(类元，一种建模元素，常见类元包括类、参与者 、构件、数据类型、接口、结点、子系统以及用例等， 其中类是最常见的类元) 关联关系表示参与者和用例之间的通信。在UML中，关 联关系用直线或箭头表示。如果参与者启动了用例，箭 头指向用例；如果参与者利用了用例提供的服务,箭头指 向参与者。如果二者是互动的，则是直线。 例：汽车租赁系统用例图(部分)。显示的是“客户”参与者以 及与他交互的3个用例，“预定”、“取车”、“还车” 。
FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示 FEAT02.修改已有的书籍信息 FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中 FEAT11.按人、按书查询外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT13.按特定时间段统计购买金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行
小游戏用例图及用例说明
4.点击“返回”按钮，用例结束。
前置条件：玩家启动系统；想要更换背景音乐或调整音量大小
后置条件：背景音乐被改变或音量被调整
“选择模式”用例
用例编号：06
用例名：选择模式
执行者：玩家
目的：选择游戏的难度模式
事件流：
1.在主界面中点击“模式选择”按钮，进入游戏“模式界面”；
2.在模式界面选择你想玩的模式，例如：点击“初级模式”；
3.点击“关闭”按钮，用例结束
前置条件：玩家启动系统；初次使用或对该系统不了解
后置条件：玩家知道如何使用该系统
“背景设置”用例
用例编号：04
用例名：背景设置
执行者：玩家
目的：更换系统背景图片
事件流：
1.在主界面中点击“游戏设置”按钮，进入游戏“设置界面”；
2.在游戏设置界面中，在“背景设置”模块下，点击“选择背景图片”；
3.点击“返回”按钮，用例结束。
前置条件：玩家启动系统，想要选择模式
后置条件：模式选择，开始玩游戏或选择关卡
“选择关卡”用例
用例编号：07
用例名：选择关卡
执行者：玩家
目的：选择想玩的关卡
事件流：
1.在游戏界面中点击各个关卡按钮；
2.进入游戏，用例结束。
前置条件：玩家启动系统，进入游戏
后置条件：开始玩游戏
执行者：玩家
目的：玩游戏
事件流：
1.玩家启动系统
2.在主界面选择你想玩的模式，例如：点击“初级模式”；
3.进入到游戏级别页面，选择关卡；
4.开始玩游戏。
前置条件：一个想玩游戏的人
后置条件：保存游戏信息，进入下一关
“游戏设置”用例
权限管理用例图及用例分析
其他事件流:
管理员在执行基本事件流过程中点击”取消”按钮,系统关闭表单页
异常事件流:
管理员提交表单数据格式错误,系统提示错误信息
系统将数据写入数据库时失败,提示错误信息
后置条件:
无
注释:无
管理员提交表单数据格式错误系统提示错误信息系统将数据写入数据库时失败提示错误信息后置条件
用例图
用例描述
用例编号:006
用例名称:权限管理
优先级别：HIGH
参与者:管理员 一Biblioteka 用户用例描述:权限管理
前置条件:
1．用户成功登陆系统
基本事件流:
在权限管理的页面上，输入新员工信息
点击提交按钮
员工信息被修改、删除或被导出 个人可以查看自己的信息 登录
用例图和用例模型
用例图和用例模型用例图用来描述用户的需求,它从用户的角度描述系统的功能,并指出各功能的执行者,强调谁在使用系统,系统为执行者完成哪些功能;用例图概述UML用例图是软件产品外部特性描述的视图,它从用户的角度而不是开发者的角度来描述软件产品的需求,分析软件产品所需的功能和行为;用例图主要描述了系统需要实现的功能,而忽略系统是如何实现这些功能的;用例模型由用例图组成,它是系统用例图的集合,是对系统从宏观角度的确定描述;用例模型主要用于需求分析阶段,该模型是系统开发者和系统使用者反复讨论的结果,表明了系统开发者和系统使用者对需求规格达成的共识;首先,用例模型描述了待开发系统的功能需求；其次,用例模型将系统看作黑盒,仅从外部执行者的角度来理解系统；再次,用例模型驱动了需求分析之后各阶段的开发工作,影响到开发工作的各个阶段和UML的各个模型;一、用例图元素用例图主要用于定义系统的功能需求,它描述了系统的参与者与系统提供的用例之间的关系;用例图由以下几种元素组成：执行者、用例、关系、用例描述1执行者执行者Actor是系统的外部用户,它是与系统相关联的人或其它系统,可以是普通用户、外部硬件、其他系统;在进行用例图绘制时,首先要找出系统的执行者;一般可以从以下几个方面来考虑怎样找到系统的执行者：谁使用系统的功能;谁向系统提供必要的信息;谁从系统获取信息;谁维护、管理系统工作;系统需要使用哪些外部资源;需要与系统交互的其它系统有哪些;其他对系统产生的结果感兴趣的人或事物;2用例用例是指系统中的一个功能单元,也可以将用例理解为系统功能的分解;用例的表示方法如下：3关系1关联在用例图中,用例和执行者之间的关系用一条连接二者带箭头的连线表示,如图所示,该连线称为关联;它表示了一个执行者和一个用例之间的关系;在用例图中,关联关系只用在执行者和用例之间,用例和用例之间不会存在关联关系;关联关系采用的是单箭头的连线,表示在该关联中执行者是主动的,是执行者启动的用例;如下图所示;2包含包含是指一个用例作为另一个用例必需的部分被使用,包含关系是依赖关系的一种;包含关系用一条连接二者带箭头的虚线表示,并在虚线的上面标注include,箭头方向由基本用例指向包含用例,如下图所示;包含的使用场合：如果多个用例有大量一致的功能,可以将这个功能分解到一个用例中,其他用例和这个用例建立包含关系;一个用例功能太多,可以使用包含关系建立若干小用例;3扩展扩展是指一个用例扩充了另一个用例的功能,但这个扩充功能不是必需的,扩展关系也是依赖关系的一种;扩展关系用一条连接二者带箭头的虚线表示,但在虚线的上面标注的是extend,箭头方向由扩展用例指向基本用例,如下图所示;扩展关系和包含关系的区别;包含用例是一个完整的用例,它可以独立的存在,也可以单独被执行者所调用; 扩展用例并不是一个完整的用例,它只是由部分扩展功能组成的,它不能独立的存在,必须依赖于基本用例;4泛化用例间的泛化关系是指一个概念较为抽象的用例可以被一般化为一个或多个概念更为具体的用例;其中概念较为抽象的用例被称为父用例,概念更为具体的用例称为子用例;子用例是父用例的特殊形式,子用例从父用例处继承属性和行为,还可以添加、覆盖或改变继承的行为;二、用例描述为了进一步说明用例是如何完成功能的,就需要对用例进行更加详细的描述;用例描述主要用来说明执行者为了实现自己的目标与系统进行交互的过程;在用例描述中,需要对用例的主要属性进行说明;这些属性主要包括：简要说明前置条件后置条件基本事件流其他事件流异常事件流。
- 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、用例描述 常见用例描述错误：
只描述系统的行为，没有描述参与者的行为 只描述参与者的行为，没有描述系统的行为 在用例描述中就设定对用户界面的设计要求 描述过于冗长
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制；
从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例