当前位置：文档之家 › 用例图-用例分层和用例文档

用例图-用例分层和用例文档

  • 格式：ppt
  • 大小：690.50 KB
  • 文档页数：12

下载文档原格式

  / 12

合集下载

用例文档及活动图

用例文档及活动图

活动图
定义活动图
活动图的符号
一个活动图必然有一个开始状态
至少有一个结束状态
转移用来表示活动或状态间的控 制流
有分支时要在分支路径中注明分 支条件
分岔用来开始并行处理 联结用于把并行处理转换为
单个处理
活动图
定义活动图
ATM机“登录”用例的活动图
事件流
事件流描述参与者在完成用例的过程中发生的一系列的交 互行为。
“增加预约”示例
➢ 示例一：“掌上校园” ➢ 示例二：“网络教学平台”
重构用例
如果你对以下问题都回答“是”的话，那么这个用 例就是集中的。否则，这个用例需要拆分为几个小 的
这个用例是否能够带来一个独立的好处？ 你是否可以利用２０个字来描述这个好处，且不用“和”，“与” 参与者是否能够仅通过在一次会话就完成这个用例 你能否想象在一个连贯的测试计划中，这个用例将是一个测试用例
前置条件 参与者启动这个用例之前必须完成的所有用例。
后置条件 包括这个用例对系统所做的所有改变。
部署约束 描述访问这个用例的所有约束
事件流
事件流描述参与者在完成用例的过程中发生的一系列的交 互行为。
一个事件流仅描述用例中的一条路径，不包括其他的分支。
在用例中有三种事件流：
正常事件流：通过描述一切都按部就班时的情况来捕捉用 例的目标。
绩 3. 在记录学生成绩之前，系统需要验证这些成绩是否有效。首先，根据学生信息文件来确认
管
该学生是否选修这门课程，若没有，那么这些成绩是无效的;如果他的确选修了这门课程，再
理
根据课程信息文件和课程单元信息文件来验证平时成绩是否与这门课程所包含的单元相对应， 如果是，那么这些成绩是有效的，否则无效。

用例例子

用例例子

应用举例 例2—医院病房监护系统 一、问题描述
为了对危重病人进行实时监护 随时了解病人病情， 实时监护， 为了对危重病人进行实时监护，随时了解病人病情，及时 进行处理，建立病房监护系统。 进行处理，建立病房监护系统。 病症监视器安置在每个病床， 病症监视器安置在每个病床，通过网络将病人的病症信号 组合）实时传送到中央监护系统进行分析处理。 （组合）实时传送到中央监护系统进行分析处理。 在中心值班室里， 在中心值班室里，值班护士使用中央监护系统对病员的情 况进行监控， 况进行监控，监护系统实时地将病人的病症信号与标准的病诊 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 信号进行比较分析，当病症出现异常时，系统会立即自动报警， 并打印病情报告和更新病历。 并打印病情报告和更新病历。 系统根据医生的要求随时打印病人的病情报告， 系统根据医生的要求随时打印病人的病情报告，系统定期 自动更新病历。 自动更新病历。
采样频率 改变 信号数据组合 <<include>> 模数转化 信号采集 病人
分解信号 <<include>>
<< include>> 生成病历
<<include>>
更新病历
用例“中央监护” 用例“中央监护”描述模板
用例名： 用例名： 中央监视 执行者： 值班护士、 执行者： 值班护士、医生 目标： 目标： 对病人的病症信号进行监测、处理，超过极限报警。 功能描述： 功能描述： 1.分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的 信号。 2.比较信号：将病人的病症信号与标准信号比较 。 3.报警：如果病症信号发生异常（即高于峰值），发出报警信号。 4.数据格式化：将处理后的数据格式化以便写入病历库 。 其他非功能需求: 高可靠性、实时性 其他非功能需求 高可靠性、 主要步骤： 主要步骤： 1.按设定频率连续接收来自各病人的病症信号，并进行分解。 2.将病人的病症信号与专家系统（标准病症信号库）中的标准信号进行比较判 断是否超过极限值。 3.若超过极限值，进行报警，并及时更新病历和打印病情报告。 相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。 相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。 相关信息： 优先级 性能、 执行率 ： 优先级、 相关信息：(优先级、性能、频执行率)： 优先级：报警处理具有最高优先级3,一般病历管理为1,其他2. 优先级：报警处理具有最高 性能：实时性、 性能：实时性、高可靠性 执行率 根据病情严重程度 12-30次/小时 频执行率：根据病情

产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

产品需求文档的写作(五) –用例文档(UML用例图、流程图)在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。

在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。

用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。

用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。

用例文档中有两个关联文件，分别是用例图和流程图。

用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。

流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。

写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。

一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下：1、修改记录：每次修改的备注记录，同PRD文档。

2、角色介绍：描述参与系统中的各个角色3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。

用例及用例图案例

用例及用例图案例
第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) 什么叫事件流,作用是什么？

uml综合案例：员工考勤系统

uml综合案例：员工考勤系统

《UML2面向对象分析与设计》综合案例：员工考勤系统作业评分实施细则一、第四章作业（用例图和用例文档）1. 评分档次用例图和用例文档分别按照满分10分计算，以此作为评分标准，基本的评分准则如下：●一档（10分）：图形（文本）条理清楚，无任何明显错误●二档（8-9分）：图形/文本清楚，存在个别错误●三档（6-7分）：图形/文本一般，存在一定的错误●四档（5分）：图形/文本条理不清，存在致命错误或错误数过多一般情况下按错别个数扣分，每个错误按严重程度扣0.5、1、2分，最终成绩向上取整；同类错误不重复扣分。

2. 参考答案作业答案部分仅供参考，学生的作业可能会多种多样，具体按照第三部分的典型错误扣分，用例图：用例文档：员工（含小时工和普通员工）相关用例无前置条件员工已正确登录到该系统后置条件无（将在下次迭代中确定）涉众利益员工：准确地维护自己的考勤信息公司：要求员工的信息准确基本路径1—添加新的考勤1.1、用例起始于用户需要记录新的考勤信息1.2、系统显示当前日期和时间，并提醒用户该时间即为用户的上班时间1.3、用户确认该信息1.4、系统记录当前日期和时间，并将其作为用户考勤信息的上班时间2—提交考勤信息2.1、任何时刻用户都可以提交自己的考勤信息2.2、系统查询用户上班时的考勤记录（E-1）2.3、系统记录当前的日期和时间，作为用户考勤信息的下班时间2.4、系统显示用户今天完整的考勤信息2.5、用户确认提交考勤信息2.6、系统保存考勤信息，并将考勤信息的状态改为“已提交”（D-1）备选路径E-1 如果系统没有找到用户上班时的考勤信息，则用例终止；用户可以通过项目经理为其添加上班的考勤信息数据需求A-1 考勤信息主要包括：用户名、日期、上班时间、下班时间、状态D-1 考勤信息的状态有：“新考勤”（只有上班时间，没有下班时间的考勤信息）、“已提交”（有完整的上下班时间，但还没有进行工资结算的考勤）、“已完成”（已结算工资的考勤）业务规则B-1 作为用户考勤信息的上下班时间由系统自动获取，不允许用户编辑B-2 状态为“已提交”的考勤信息不允许普通用户进行任何操作；非功能需求无设计约束无待解决问题无参与者时间、项目管理数据库（外部系统）相关用例无前置条件无后置条件无（将在下次迭代中确定）涉众利益员工：…（包括临时工、普通员工、销售人员）公司：…基本路径—计算普通员工和销售人员工资1.用例起始于系统时间到达每月末晚上，需要计算普通员工和销售人员工资(E-1)；2.系统查询所有的普通员工和销售人员的个人信息（D-1）；3.对于每一个员工（普通员工、销售人员）：3.1.根据员工的类别获得其考勤信息或订单信息（E-2）；3.1.1.如果是普通员工，则获得本月的考勤信息（D-2）；3.1.2.如果是销售人员，则获得本月的销售信息（D-3）；3.2.系统从项目管理数据库中获得员工的工资级别信息（E-3）；3.3.系统根据员工的考勤信息（或销售信息）和工资级别信息计算该员工的工资，保存；4.计算完成后，系统产生一个提醒信息，以便于项目经理确认备选路径E-1—计算临时工工资1. 用例起始于系统时间达到每个周末的晚上，需要计算临时工工资2. 系统查询所有临时工的个人信息3. 对于每一个临时工：3.1. 获得员工的考勤信息3.2 从项目管理数据库中获得员工的工资级别信息；3.3 系统根据员工的考勤信息和工资级别信息计算该员工的工资，保存；4. 计算完成后，系统产生一个提醒信息，以便于项目经理确认E-2 如果找不到该员工的考勤信息或订单信息，则记录相关日志，并转回3计算下一个员工E-3 如果无法获得员工工资级别信息，则记录相关日志，并转回3计算下一个员工数据需求D-1. 员工信息=员工编号+员工姓名D-2 考勤信息参见“登记考勤”用例D-3 订单信息参见“登记订单”用例业务规则暂不明确非功能需求暂不明确设计约束3. 典型错误情况3.1 用例图部分3.1.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用

第三章 用例图


扩展机制
对UML图示符号的扩展。包括构造型（Stereotype），标注值（Tagged value）， 约束（Constraint）。
UML
- 28 -
UML
- 10 -
情况二：假如机票购买者通过呼叫中心，由人工座席操作订票 系统购买机票，那么谁是参与者？
UML
- 11 -
情况三：如果机票购买者通过呼叫中心的自动语音预定机票而 不是通过人工座席，那么谁是参与者？
UML
- 12 -
情况四：如果扩大系统边界，让呼叫中心成为机票预定系统 的一个子系统，并且假设机票购买者将可以自主选择是通过人工 座席还是自动语音登录网站预订机票，那么谁是参与者？
?用例的粒度可大可小一般一个系统控制在20个左右但没有严格规定?用例是系统级的抽象的描述不是细化的考虑的是做什么what而不是怎样做how?对复杂的系统可以划分为若干子系统处理uml24?实际上用例粒度的划分依据最标准的方法是一个用例的粒度是否合适是以该用例是否完成了参与者的某个目的为依据的
第三章 用例图
UML
- 17 -
什么是用例？
用例是一种需求方法学 把用例解释为某个参与者(actor)要做的一件事，这样的 一件事有以下几个特征：
1、这件事是相对独立的；
2、这件事的执行结果对参与者来说是可观测的和有意义的； 3、这件事必须由一个参与者发起 ；不存在没有参与者的用例 ，用例不应该自动启动。用例总是由一个参与者发起，并且满 足特征二； 4、这件事必然是以动宾短语形式出现的 。
UML - 23 -
实际上，用例粒度的划分依据最标准的方法是一个用例 的粒度是否合适，是以该用例是否完成了参与者的某个 目的为依据的。
UML

2.用例图

2.用例图
概述
用例图（Use Case Diagram）展示了用例之间以及同用例参与者之间是怎样相互联系的。
用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
主要作用：在“需求分析”阶段，描述系统提供什么功能，，给什么用户使用。
组成
包含6大元素：
参与者(actor)、用例(user case)、关联关系(association)、包含关系(include)、扩展关系(extend)以及泛化关系(generalization)。
还有，包（package）、系统边界（System boundary)、
以StarUM系统或类发生交互的外部用户、进程或其他系统。参与者可以是人、另一个计算机系统或一些可运行的进程。
用例(user case)
是参与者想要系统做的事情。
关系
关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
关联关系（Association）
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
学习网址：
/oobject/Oobject-usecase.asp
描述：租书(用例)包含计算租金(用例)，也可理解为"HAS A"的关系。
扩展关系（Extend）
扩展关系是把新的行为插入到已有用例中的方法。
同一个基础用例可以有几个扩展点，每个扩展点也可以出现多次。但是一般情况下，基础用例的执行不会涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。扩展关系为处理异常或构建灵活的系统框架提供了一种方法。

用例和用例图分解


4.1.1 用例
• 怎样识别用例 – 参与者需要从系统中获得什么功能？参与者需要做什 么？ – 参与者读取、产生、删除、修改或存储系统的哪些信 息？ – 需要将系统的哪个事件告诉参与者？ – 需要将外界的哪些信息提供给系统？（输入、输出信 息） – 采用什么实现方法满足特殊要求？
图书管理系统的用例图
• 用例是代表系统中各个项目相关人员之间根据系统的行为 所达成的契约。用例描述了在不同条件下，针对某一项目 相关人员的请求，系统对其作出的响应。也就是说用例指 的是对一组动作的描述，系统通过执行这些动作将对用例 的参与者产生可以看到的结果。用来描述参与者可以感受 到的系统服务或功能。
4.1.1 用例
• 关联（accociation）
– 每个用例都有活动者启动（每个用例必须和一 个活动者关联，有一个活动者来参与），除包 含和扩展用例
– 无论用例和活动者是否存在双向数据交流（无 论是参与者提供信息给系统，还是从系统获取 信息），关联总是由活动者指向用例，只用单 向箭头。
4.2.2 包含关系
• 包含（include） （是一种依赖关系，加了版型<<include>>）
置正文的字体为宋体
借
书
还
书
图4.5 用例
4.1.1 用例
• 怎样确定用例的粒度？（用例规模的大小）
– 用例的粒度可大可小，一般一个系统控制在20 个左右，但没有严格规定
– 用例是系统级的、抽象的描述，不是细化的 （考虑的是“做什么what”，而不是“怎样做 how”）
– 对复杂的系统可以划分为若干子系统处理
– 包含关系指的是两个用例之间的关系，其中一个用例 （称为基本用例）的行为包含了另一个用例（称为包含 用例）的行为。也就是说基本用例会用到包含用例。

用例分析与用例图ppt课件


前言之一
软件开发过程中常见的场景
这个做还不错，不过 好像不是我想要的。
我们这很混乱，你这 个系统应该把我们的 所有问题全部解决掉
！
你这做的是什么 东西！
“弱弱”地问：“您 到底想要什么？”
前言之二
需求分析与管理—软件开发过程中的“永远 的痛”
基于用例的分析与设计
以用例为中心组织需求
性能 可用性
√
会员
检索零件
系统执行：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
参与者观测：用户观点而非系统观点
旅客
订票 查看今日航班
用户观点
旅客
处理订票 显示今日航班
系统观点
用例粒度
• 用例要有路径，路径要有步骤；而 这一切都是可观测的
• 最常犯错误：粒度过细，陷入功能 分解
–过细的粒度，一般都会导致技术语 言的描述，而不再是业务语言
• 所有业务最终会成为CRUD？ • CRUD能为Actor提供价值？ • CRUD掩盖业务，锐变成关系数据库的建模：
– “系统就是数据的增删改查” – 关心数据的存储和维护，反而忽略了用户的目的
用例粒度-4
• 如果确实是CRUD？
– 如果CRUD不涉及复杂的交互，一个 用例“管理××”即可
– 不管是C、R、U、D，都是为了完成
– 关键词：边界 – 参与者：在系统之外，透过
系统边界与系统进行有意义 交互的任何事物
边界---Boundary
• 也叫系统边界，用于界定系统功能范围
用一个带名称的矩形框，把描述系统功能的用 例都置于其中，而描述的与系统交互的角色都 置于其外
系统----完整系统或子系统 一个系统包括一个或多个用例
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

对每个一级用例细化 1. 用户管理：注册， 登录，退出，密码找 回，信息查看，信息 修改，用户验证，用 户查询
ห้องสมุดไป่ตู้
2. 查询：时刻表，余票 ，联程规划，晚点
3. 订单：下单，取消订 单，修改订 单，订单查 询，预订
4. 票务：订票，取票， 改签，退票，车票查 询
5. 资金：付款，退款 ，查询到帐， 银行对账
6. 票池：入票，出票 ，查询票池， 修改票池
7. 维护：参数设置，词 典维护，拓扑管理，日 志查询，备份，恢复
用例文档
用例文档有多种形式，但共同目的都是为 了更详细的描述用例。 以下介绍比较典型的两种

见附件1，2
用例图 用例分层和用例文档
用例图分层
当系统需求相对比较复杂时，我们通常考 虑使用分层的方法来描述用例 所谓分层法也是在其他领域经常用到的一 种方法，是在复杂的问题难以一次性解决 的时候，常采用的一种逐步细化，简化问 题的办法。


我们以火车票订票系统为例：
顶层用例图，零级用例

对零级用例进行细化，该层为一级用例