2 设计用例图的案例
确定用例：
学生信息管理的用例 班级信息管理的用例
成绩管理的用例
网上选课的用例 账号管理的用例
注意：《include》应用的两 种场合：
1、多个用例都用到某个同 样的功能，将这个功能抽取 出来，单独编写，供其他用 例调用。
好处：避免了重复编写相同 的功能。
2、当某个功能包含若干个子功能时，使用《include》展 示子功能。 需要注意的是要区别是使用《include》合适还是使用“泛 化”合适。
使用Rose画图并不画系统边界，采用 Visio画图，用方框表示系统边界。 系统边界不一样，它的参与者就会发 生很大变化。搞清系统边界才能更好 地确定系统的参与者和用例。
系统 参与者 用例
用例图—用例
用例和参与者之间也有关系，这种关系属于关联关
系，是双向的一对一关系，表明了哪个参与者与用 例通信。
系统开发出来后，使用系统主要功能的是谁？ 谁需要借助系统来完成日常工作？ 系统需要从哪些人或其他系统中获取数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统交互？ 系统是由谁来维护和管理的，以保证系统处于工作状 态？ 系统控制的硬件设备有哪些？ 谁对本系统产生的结果感兴趣？
同一个系统由于用例的粒度不同，不同人会产生不同 的用例模型。
用例图—用例
用例的识别
参与者希望系统提供什Fra bibliotek功能？参与者是否会读取、创建、修改、删除、存储系统的 某种信息？如果是，参与者又是如何完成这些操作的？
参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 是否存在影响系统的外部事件？
注意：
在用例图中，只能展示系统大的功能模块，对功能
的细节部分无法展示，如“每个学生可以选择不超 过4门课程，同时指定2门候选课程以备主选课程未 选上。每门课程最多不能超过10人，最少不能低于 3人，低于3人选课的课程将被取消”这样的细节可 以在用例图中为某个用例添加上“注释”。
建立用例模型案例2
参与者是用户相对系统而言所扮演的角色。 每个参与者可以参与一个或多个用例，每个用例也
可以有一个或多个参与者。
参与者不仅可以由人承担，还可以是其他系统、硬
件设备，甚至是时钟。
参与者虽然可以代表人或事物，但参与者不是指人或 事物本身，而是表示人或事物当时所扮演的角色。
用例图—参与者
参与者的确定：
确定用例：
与教师有关的用例
选择课程--选择所教的课程，并获得学生名册
登记成绩--在学期结束时，提交学生的课程成绩。
与学生有关的用例
注册课程--在学期开始进行选课注册，允许在一段时间内 更改或删除，课程目录系统提供当前学期的所有可选课程 列表
查看成绩单--学生可以查看以前学期的电子成绩单。
8. 打印存折，用例结束 后臵条件：在账户库中增加一个新账户，得到一张新存折
作 业
教材230页第10题。
作 业
教材230页第10题。
仓库管理员通过放在仓库
中的终端把零件入库/出 库事务报告给订货系统， 系统接收到事务信息后应 该处理事务；
采购员需要使用订货系统
提供的产生报表功能，以 获取订货报表。
者，箭头所指方 参与者——与系统交互的人或物。是向系统输入或系
统输出的对象。用一个小人图形表示。 是对话的被动接 受者。 用例——系统的一个功能。用椭圆表示。 用例和参与者之间的关系——用带箭头的线段来描述。
用例图—参与者
参与者（Actor）是指存在于系统外部并直接与系
统进行交互的实体。
与注册管理员有关的用例
维护课程信息--在系统中增加、修改和删除课程信息；
维护学生信息--在系统中增加、修改和删除学生信息； 维护教师信息--在系统中增加、修改和删除教师信息。
关闭注册--删除少于3人的课程，并由付费系统通知学生缴费。
与安全性要求有关的用例
登录--使用此系统的人员需要进行登录，以验证其身份和权限。
注意寻找参与者时不要只考虑使用计算机的人！
用例图—参与者
参与者间的关系
用例图—系统边界
系统边界是指系统与系统之间的界限。
系统与环境之间存在边界，子系统与
其他子系统之间存在边界，子系统与 整体系统之间也存在边界。 用例图中的系统边界用来表示正在建 模系统的边界，边界内表示系统的组 成部分，边界外表示系统的外部。
建立用例模型：银行账户管理系统需求陈述如下：
用例名称：开户 一个客户可以在多个银行中开设账户，一个客户也 参与者：银行职员（客户代理）、客户
前臵条件：一个合法的银行职员（客户代理）已登录到该系统 可在同一银行中开设多个不同的账户。客户可以通 事件流： 过银行职员进行开户、存款、取款、转账、注销账 1. 当选择开户功能时用例开始 2. 输入客户信息（姓名、地址、身份证号等） 户等活动。其中转账指客户将自己的某个账户上的 3. 从账户管理系统获取新的账号 钱转入同一银行的不同账户（称为银行内转账）或 4. 请客户输入密码 5. 请客户再次输入密码 转入不同银行的账户（称为银行间转账）。系统管 6. 如果两次密码不一致则回到第4步，否则继续 理员负责系统的账户管理及业务报表的生成。 7. 在账户库中添加新账户
用例图
用例图源于Jacobson的OOSE方法，它通过用例来 捕获系统的需求，再结合参与者进行系统功能需求 的分析和设计。
用例图由参与者、用例、系统边界和关联组成。
用例和参与者之间的对应关系称为通信关联 箭头表示在这一 （Communication Association）。 关系中哪一方是 使用用例图来描述系统，主要弄清楚三方面内容: 对话的主动发起
建立用例模型两种思路
1、找到每个Actor在系统中的功能，然后将所有 Actor的功能合并为一张用例图。 ——见案例1 2、将一个大系统划分为几个子系统，为每个子系 统分别建立用例图。 ——见案例2
建立用例模型案例1
详细用例建模过程举例：学生注册管理系统
识别参与者：
教师、学生、注册管理员、收费系统
软件工程导论
孙旭光
灾害信息工程系
功能模型
在面向对象方法学中，可以使用UML提供的用例 图进行需求分析和建立功能模型。
也把用用例图建立起来的系统模型称为用例模型。
使用用例模型代替传统的功能说明，能更好地获取
用户需求，它所回答的问题是“系统应该为每个用
户做什么”。
用例模型描述的是外部行为者所理解的系统功能。
总结
根据系统陈述建立模型过程中，很重要的一点 是要分析陈述中哪些是无用的信息，哪些是有用 的信息，哪些是可以合并的信息。
建立用例模型
练习：银行账户管理系统需求陈述如下：
一个客户可以在多个银行中开设账户，一个客户也
可在同一银行中开设多个不同的账户。客户可以通 过银行职员进行开户、存款、取款、转账、注销账 户等活动。其中转账指客户将自己的某个账户上的 钱转入同一银行的不同账户（称为银行内转账）或 转入不同银行的账户（称为银行间转账）。系统管 理员负责系统的账户管理及业务报表的生成。
详细用例建模过程举例：学生信息管理系统
识别参与者：
学生、教师、校领导、系统管理员
登录 登录 查询学生基本信息 找回密码登录 登录 录入学生基本信息 录入成绩 找回密码 找回密码 修改学生基本信息 创建新账号 修改成绩 查询课程信息 查看班级基本信息 删除学生基本信息 设臵账号 保存成绩 按课程编号查看 录入班级基本信息 找回密码 设臵账号基本信息 查询成绩 按课程名查看 修改班级基本信息 设臵账号权限 删除成绩 选择课程 删除班级基本信息 删除账号 删除已选课程 查看账号 维护课程信息
uml综合案例：医院预约挂号系统
表 2. 医院预约挂号系统用例说明
描述 完成在系统的注册业务 查询医院、相关科室、各科室的医生等各类信 息 登录系统 注册用户可通过该用例完成预约挂号业务 打印出已经预约挂号的预约单 打印出已经预约挂号并支付费用的挂号单
备选事件流
A-* 用户在提交该预约前，随时都可能中止本次预约 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。
A-1 当用户已经有成功预约且还没看病的预约记录时 1. 系统显示用户已有的预约记录； 针对每个预约记录，系统提供三个扩展点：打印预约单、打印挂号费、支付挂号费
A-2 无法查询到所要的出诊信息 1. 系统显示没有可用的出诊信息； 2. 注册用户可以重新输入查询条件进行查询，也可以结束该用例。
2. 参考答案
作业答案部分仅供参考，学生的作业可能会多种多样，具体按照第三部分的典型错误扣 分，用例图：
1
未注册用户 注册用户
实名注册
生成出诊信息
时间
打印预约单
查询医院信<<息extend>>
处理逾期未取消的预约
<<extend>> 打印挂号单
<<extend>>
预约挂号
支付挂号费
支付系统
取消预约
系统管理员
登录 审核注册信息
挂号处 核查预约单
<<include>>
两个案例背后的分析与思考——利用用例图表达架构观点之六
件事：架构并非是 虚无飘渺、无所适从 的。例如进 （ 订购 ） （ ，销 销货 出货 ） ，存 或者 Ｘ ｏ ．它们都有机会来使用 Ｃ Ｕ Ｂｘ Ｐ。
的虚像。 一流的软件架构师． 很能懂得如 （ 库存） 系统．一般小型的套件（ ｃａｅ Ｐ ｋｇ ） ａ
这些都是显而易见的道理 ．从以上
某主板设计师时 ， 我会 研究 Ｃ Ｕ Ｐ 的规格 ．
再举个例 子 ．当你是 主板 开发厂商 知道该如何与之沟通 ． 但却不会打开 ． 事 时． 你会不会 “ 打开 ＣＵ 研究其 内部 实上也无从知道 Ｃ Ｕ的内部结构。不需 Ｐ Ｐ
仍有一致性与调和 的观点 。对架构要能 的结构 呢 绝 大部分设计 师会 回答说 不 要打开 ．就会 ” 封装 Ｃ Ｕ．因为封装 ． Ｐ 所 以只能通过 “ 口” 接 沟通 “ 有所不 为“ 就表示因为 “ 封装—了Ｃ Ｕ． 以我没有 Ｐ 所
住整体 ．才能 了解系统设计与开发 时的 站在Ｃ Ｕ Ｐ 设计者的角度 ， 我只要提供 ” 接 向与其假 设前提。
７４ 瑶 序 员
维普资讯
进销存系统需要几个数据库？
以用例 图在说 明架构设计 时 ．每一
个 用套件 所界定范围的系统系指软件 应
类型产品的比较就会偏重 在系统的外观 解你 自己的角色 ．或者知 道你现 在是用
所 以． 到底什么是 ” 架构”呢７其实 方面：系统所提供功能的多寡 、 完整性与 什 么角度在 看待系统 的设计 。当我 是某
架构。 ．非常之难解释 若真要一言 使用者的图形 接 Ｅ （Ｕ）等。 ＿词 ｌ ＧＩ 以蔽之 ． 那么可 以说 ．“ 构 架 是一种 整 体观 ．需要 保持从 各 角度 看待架 构时 ．
用系统 但用例 图却几乎不会 涉及 到数
用例及用例图案例
用例及用例图-案例
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综合案例：员工考勤系统
《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 参与者本系统中包含的参与者有：小时工、普通员工、销售人员、项目经理、项目管理数据库、时间，其中由于小时工和普通员工有关考勤的处理细节完全相同，因此为了便于简化和复用，可将他们统一合并为员工（不合并也可以，不算错误），但不能和销售人员合并，因为销售人员没有考勤信息，而是登记订单信息，需要明确区分。
用例图, 类图
Get Upload Files
Receive Data
Manage Log
Breake Connection
Time
18/336
1.用例图 (19/29)
•
20/336
21/336
22/336
1.用例图 (22/29)
23/336
24/336
1.用例图 (25/29)
智能电梯系统
25/336
1.用例图 (26/29)
Deal with Auditing Data
Auditing break connection
break connection
Server 17/336
1.用例图 (18/29)
• 学生课程注册系统例子
– 每个学生都可以增删改查自己的课程注册表 – 每个教师都可以查询课程花名册 – 学校管理人员可以维护全部课程，可以登记
Dat aObjec t
38/336
2.顺序图 (8/19)
40/336
2.顺序图 (9/19) 2.顺序图 (11/19)
41/336
: Actor
FormObject
1: Open form
ControlObject
DataObject
2: Enter information
3: Save informat ion
is displayed
4. Select a file
12/336
1.用例图 (12/29)
• 例子: 远程通讯
– 背景 – 任务
• 远程审核 • 远程客户端
Client
13/336
logon Request Data Receive Data
第二讲用例图.ppt
通过回答以下的几个问题识别用例：
特定参与者希望系统提供什么功能。 系统是否存储和检索信息，如果是，由哪个参与者触
发。 当系统发生改变时，是否通知参与者。 是否存在影响系统的外部事件。
哪个参与者通知系统这些事件。
还有两个针对整个系统的问题:(1)系统需要何种输入输 出？输入从何处来？输出到何处去？(2)当前运行系统 的主要问题一？个用这例两至个少问要题与一并个不参意与味者着关联没！有参与者也可以 有用例，只是获取用例时还不知道参与者是什么。
(2)为系统的功能提供清晰一致的描述，以便为后续的开 发工作打下良好的交流基础，方便开发人员传递需求的 功能。
(3)为系统验证工作打下基础。通过验证最终实现的系 统能够执行的功能是否与最初需求的功能相一致，保证 系统的实用性。
(4)从需求的功能（用例）出发，提供跟踪进入系统中 具体实现的类和方法，检查其是否正确的能力。
S-1：添加所选课程
系统提示含有课程名和课程代码的域，学生输入希望选修的 课程名和课程代码(E-3)，系统显示信息表示该课程可以选 修(E-4)，并建立该课程与该学生的连接(E-5)。用例重新 开始。
S-2：删除所选课程
系统提示含有课程名和课程代码的域，学生输入希望取消的 课程名和课程代码，系统删除该课程与该学生的连接(E-6)。 用例重新开始。
4.用例
（1）用例的概念
UML中的用例图实践案例
UML中的用例图实践案例UML（统一建模语言）是一种用于软件开发的标准化建模语言，它提供了一套丰富的图形符号和概念，用于描述和设计软件系统的各个方面。
其中，用例图是UML中最为常用和重要的一种图形表示方法，它用于描述系统的功能需求和用户与系统之间的交互关系。
本文将通过一个实践案例，介绍用例图在软件开发中的具体应用。
假设我们要开发一个在线购物系统，该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。
首先，我们需要明确系统的角色和用例。
在这个案例中，系统的角色包括用户、管理员和支付网关。
用户可以注册账号、浏览商品、添加购物车、下单和支付；管理员可以管理商品信息；支付网关负责处理支付请求。
接下来，我们可以使用用例图来表示这些角色和用例之间的关系。
首先，我们可以在用例图中用椭圆形表示各个用例。
在本案例中，我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。
然后，我们可以用矩形表示各个角色，即用户、管理员和支付网关。
接着，我们可以使用实线箭头来表示角色与用例之间的关系。
例如，用户可以注册账号，我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。
除了角色和用例之间的关系，用例图还可以表示用例之间的关系。
在本案例中，用户可以浏览商品、添加购物车、下单和支付，这些用例之间存在一定的先后顺序。
我们可以使用虚线箭头来表示这种顺序关系。
例如，用户可以先浏览商品，然后将商品添加到购物车，最后下单和支付。
我们可以在浏览商品和添加购物车之间画一条虚线箭头，表示用户在浏览商品后可以将商品添加到购物车。
此外，用例图还可以表示用例之间的包含和扩展关系。
在本案例中，用户下单时可能需要选择配送地址，我们可以将选择配送地址作为一个包含关系，用一个带有加号的实线箭头表示。
另外，用户下单时还可以选择使用优惠券，这可以作为一个扩展关系，用一个带有箭头和加号的虚线箭头表示。
通过用例图，我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。
(完整word版)UML综合案例
ＵＭＬ在ＡＴＭ自动取款机中的应用(一)Uml 基础知识Uml 概述UML （Unified Modeling Language)是软件界第一个统一的建模语言，该方法结合了Booch ， OMT ，和OOSE 方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术.它是一种标准的表示,已成为国际软件界广泛承认的标准。
是一种基于面向对象的可视化的通用（General ）建模语言。
为不同领域的用户提供了统一的交流标准 — UML 图。
UML 应用领域很广泛,可用于软件开发建模的各个阶段，商业建模（Business Modeling ）, 也可用于其它类型的系统。
UML 是一种定义良好,易于表达，功能强大且普遍实用的建模语言，不是一种方法，它独立于过程。
利用它建模时，可遵循任何类型的建模过程。
建模过程：UML 的主要构成向对象分析与设计的一种UML 是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示.由：● 视图（views ）, ● 图(Diagrams ）,● 模型元素（Model elements ） ● 通用机制（general mechanism ）等几个部分构成。
视图(views）一个系统应从不同的角度进行描述，从一个角度观察到的系统称为一个视图（view）。
视图由多个图（Diagrams）构成，它不是一个图表(Graph）,而是在某一个抽象层上，对系统的抽象表示。
如果要为系统建立一个完整的模型图，需定义一定数量的视图,每个视图表示系统的一个特殊的方面。
另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。
图(Diagrams）UML语言定义了五种类型9种不同的图，把它们有机结合起来就可以描述系统的所有视图。
用例图(Use case diagram）从用户角度描述系统功能，并指出各功能的操作者。
静态图（Static diagram)，表示系统的静态结构.包括类图、对象图、包图。
用例图说明实例
业务规则
4.至少选择一本,至多选择三本
涉及的业务实体
Be_费用记录 Be_图书 Be_借书篮 Be_借阅定单 Be_借阅证
上表是用例规约内容。过程描述中的章节号标明每一个可能的活动。例如,4 代表“用户可 单选或多选书本，并确认借阅。计算机显示确认借阅图书清单”这个活动，而 4.1.1 代表第 4 步的第一个可选分枝的第一步，4.1.2.1.1 代表第 4 步的第一个可选分枝的第二步中的第 一个可选分分枝的第一步。
用例名称
bu_借阅图书
用例描述
借阅人通过此用例向系统查询并提交借书请求
执行者
借阅人
前置条件 后置条件 主过程描述
分支过程描述
异常过程描述
1. 借阅人借阅证件在有效期内 2. 借阅人没有逾期未归还的图书 1. 创建借书定单 2. 更新借阅人借阅记录 1 用户用借阅证提供的帐号登录系统，计算机显示我的图书馆 界面 2.用户选择查询图书，计算机显示查询界面 3.用户按书名、作者、出版社查询，计算机显示查询结果 4.用户可单选或多选书本，并 确认借阅。计算 机显示确认借阅 图书清单。 5.用户选择确认借阅，计算机显示借阅定单及费用 6 用户选择提交定单，计算机显示提交结果和定单号 7.计算机执行后置条件。用例结束 2.1.1 用户选择查看原有定单，计算机执行 4; 4.1.1 用户可单选或多选书本，放入借书篮，计算机显示借书 篮现有内容 4.1.2.1.1 用户选择继续借书，计算机执行 2； 4.1.2.2.1 用户选择提交借书篮，计算机执行 4 4.2.1 用户选择放弃，计算机执行 2； 6.1.1 用户选择保存定单，计算机保存并执行 1； 6.2.1 用户选择放弃，计算机执行 1； 1.1.1 借阅证已过期，拒绝登录，用例结束 1.2.1 借阅人有逾期未归还书本，启动 bu_归还图书用例 5.1.1 用户余额不足，计算机显示余额和所需金额 5.1.2.1.1 用户选择续费，启动 bu_交纳借阅费用例 5.1.2.2.1 用户选择放弃，计算机执行 1
案例二：网上购物系统UML课程设计RationalRose建模(综合)
后置条件：
如果用例成功，客户将收到发票。
用例：
Inform Warehouse about Order
简述：
在客户定单输入到系统之后，销售人员发送电子请求给仓库，附上所订购的配置的细节。
参与者：
Salesman Warehouse
前提条件：
验证和接收客户付款成功。
Salesman选择系统提供的订购清单中该客户的订购信息，并点击Refer（或相似命名的）功能键来将订购信息提交给Warehouse时，该用例开始。
3.客户可以选择在线订购计算机，或者也可以要求销售人员在定单真正发出之前与自己联系，解释定单的细节、协商价格等。
4.要发出定单，客户必须填写在线表格关于运送和发票地址以及付款细节（信用卡或支票）。
5.在客户定单输入到系统之后，销售人员发送电子请求给仓库，附上所订购的配置的细节。
6.事务的细节，包括定单号和客户账号，要e-mail给客户，使得客户可以在线查看定单的状态。
参与者：
Customer
前提条件：
Customer点击一个因特网浏览器进入计算机制造厂商的定单输入Web页面，该页面显示已配置计算机及其价格的详细情况。
当Customer在定单信息已经显示在屏幕上时选择Continue（或相似命名的）功能键来确定订购所配置的计算机时，该用例开始。
主流：
系统请求Customer输入购买细节，包括销售人员的名字（如果知道的话）、运送信息（客户的名字和地址）、发票细节（如果与运送地址不同的话）、付款方法（信用卡或支票）以及任何其他注释。
SelfConfigurationWindow类调用此方
法从Component类中得到计算机自选部件的
详细信息。