用例图用例建模作业
图书管理系统用例建模报告（用例图、类图、时序图）
软件系统分析与设计实验报告学院：计算机科学与技术学院专业：软件工程学号：*********姓名：***实验名称：图书管理系统用例建模时间：一、实验内容与要求本实验要求学生对学校的图书馆管理系统进行需求分析，对系统功能进行用例建模，画出用例图，类图以及相应的时序图。
在使用UML对系统建模时，学会使用UML建模工具，熟悉工具中的功能。
二、用例分析1、读者“借书还书系统”用例图(f书书(from Use Cases)1．1、行为者：主要行为者：读者。
1．2、前置条件：读者进入图书管理系统。
1．3、事件流：1.3.1、主要事件流：1.3.1.1：读者检索所需图书信息，并查看；1.3.1.2：读者检索到所需图书，登录系统，开始借书；1.3.1.3：系统查询图书信息，图书数目是否可借；1.3.1.3.1：图书显示可借，借书成功；1.3.1.3.2：图书显示不可借，借书失败；1.3.1.4：进入续借图书界面，续借图书；1.3.1.5：系统查看预约记录，1.3.1.5.1：没有冲突，续借成功；1.3.1.5.2：有冲突，续借失败；1.3.3.1：1.3.1.6：读者归还图书；1.3.1.6.1：归还时间没有逾期，归还成功；1.3.1.5.2：归还时间逾期，逾期处罚，归还成功；1.3.2、备选事件流：1.3.2.1：图书检索信息失败，未检索到图书，重新输入信息检索；1.3.2.2：未曾检索到用户检索的图书，系统显示相关联的信息的图书；1.3.2.3：用户名或密码输入错误，登录系统失败，重新输入用户名或密码登录；1.3.2.4：系统显示图书不可借后，进入图书预约界面，输入信息预约图书；1.3.3、异常事件流：1.3.3.1：读者登录系统失败，未曾注册用户；1.3.3.1.1：返回系统注册用户后，重新登录。
1．4、后置条件：退出系统。
1．5、1．6、扩展点：无。
2、“图书信息管理系统”用例图书书书书书书(f书书书书(from Use Cases)(from Use Cases)2．1、行为者：主要行为者：管理员；2．2、前置条件：管理员打开图书信息管理系统；2．3、事件流：2.3.1：主要事件流：2.3.1.1：图书管理员输入管理员登录信息，登录系统；2.3.1.2：进入图书信息管理界面，查看已有图书信息，是否有需要购入图书；2.3.1.2.1：录入新购进图书信息，并确认；2.3.1.3：进入读者信息管理界面，管理已有用户信息；2.3.1.4：进入信息通知界面，查看已有用户图书借阅、预约情况；2.3.1.4.1：查看读者所预约图书，自动查询图书信息，确认是否已有可借图书，有则通知读者；2.3.1.4.2：查询读者已借图书信息，根据已借时间及归还时间分类；2.3.1.4.2.1：所借图书即将逾期，启动系统提醒功能；2.3.1.4.2.2：所借图书已经逾期，启动逾期及处罚通知功能；2.3.2：备选事件流：2.3.2.1：管理员用户名或登录名错误，重新登录；2.3.2.2：需要购进新图书，存储信息，通知相关人员；2.3.2.3：读者预约图书没有可借图书，不予通知；2.3.2.4：预约通知提醒后，删除该预约记录；2.3.2.5：读者所借图书距离归还时间仍很久，无需通知；2.3.3：异常事件流：2.3.3.1：登录失败超过一定次数后，系统冻结该用户名，一段时间后可以重用；2．4、后置条件：退出系统；2．5、扩展点：无。
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
用例建模习题
用例建模习题1. 家教网上发布系统的用例模型拟建立一个网站，用于发布家教信息，同时建立家教与学生的沟通桥梁。
基本需求如下：(1)家教求职者希望能注册本人信息、修改本人资料、浏览家教信息、搜索家教信息。
(2)学生希望能够注册本人信息、修改本人资料、浏览家教信息、搜索家教信息。
(3)管理员希望能够发布网站公告、处理家教信息。
请根据上述基本需求，建立该系统的用例模型。
2. 考务系统的用例模型某学校教务处的考务系统，专门负责处理学生考试。
其需求如下：(1)考生填写考试报名表，经检查合格后系统登记注册，并发给学生准考证。
(2)考生按照准考证要求进入考场考试。
考试完后将试卷交给阅卷站。
(3)阅卷站阅卷后把成绩表（包括每个考试科目每个考生的分项成绩）交给本系统输入计算机。
(4)考试中心负责管理成绩评定标准，交给阅卷站。
(5)本系统把考试成绩通知考生，把考试成绩的统计结果交给考试中心。
(6)系统给考生提供按准考证号、考生姓名的考生成绩查询，按科目的历年考试成绩统计分析和评分标准提供给考试中心。
(7)考生对考试成绩质疑时，系统根据准考证号、姓名可以查询考生某科目的个分项成绩，必要时调阅阅卷站的试卷。
(8)系统保存并可查询历年每门科目的评分标准。
(9)根据考试成绩统计，系统可以向考试中心提供试题难度分析。
请建立该系统的用例模型。
3. 工资计算系统的用例模型某公司财务部的员工工资计算系统，负责员工的工资计算和发放。
其需求如下：(1)人事部向财务部提交出勤表和业绩表，后勤部则提交水电扣款表。
(2)财务部的工资计算工作如下：①根据出勤表统计出勤、请假及旷工时数得出美味员工的实际出勤时数和请假及旷工时数；②根据出勤时数并按公司奖惩条例计算出勤奖，③根据请假及旷工时数并按公司奖惩条例计算缺勤扣款；④根据业绩表并按公司奖惩条例计算业绩奖；⑤计算出勤奖和业绩奖之和生成奖金发放表；⑥根据工资档案列出的各项基本数据计算员工的基本工资；⑦按基本工资和所得奖金计算员工的应发工资，并生成应发工资表；⑧根据应发工资表计算所得税；⑨计算实发工资生成实发工资表并存入工资清单：实发工资＝应发工资－所得税－水电扣款(3)财务部的工资发放工作如下：①从员工个人工资账号清单中查找员工的银行工资账号；②根据实发工资和银行工资账号生成工资存款清单，并传送给银行。
uml大作业设计
uml大作业设计
UML（统一建模语言）大作业设计通常涉及使用 UML 图表来建模和设计一个软件系统或业务流程。
以下是一个 UML 大作业设计的示例，包括了一些关键的 UML 图表和相关的描述：
1. 系统概述：
对要建模的系统进行概述，包括其主要功能、目标用户、应用场景等。
2. 用例图（Use Case Diagram）：
展示系统的主要用例以及它们之间的关系。
用例图用于描述系统的功能和用户与系统的交互。
3. 类图（Class Diagram）：
定义系统中的类、它们的属性和操作，以及类之间的关系，如继承、关联、聚合等。
4. 顺序图（Sequence Diagram）：
显示用例中各个对象之间的消息交互顺序，以及它们在时间上的顺序。
5. 状态图（State Diagram）：
描述系统中对象的不同状态以及导致状态转换的事件。
6. 活动图（Activity Diagram）：
展示系统中业务流程或操作的步骤和活动。
7. 部署图（Deployment Diagram）：
展示系统的硬件和软件组件的部署结构。
在进行 UML 大作业设计时，需要清晰地定义系统的需求和功能，并使用 UML 图表来表达这些需求和设计决策。
同时，要确保图表之间的一致性和完整性，并进行有效的沟通和协作，以确保设计的质量和可维护性。
以上示例仅提供了一些关键的 UML 图表和描述，具体的大作业设计内容和要求会根据实际情况而有所不同。
你可以根据具体的项目需求和指导教师的要求进行调整和扩展。
实验一 用例图
软件工程试验一：用例图
班级：信121
姓名：黄成运
学号：2108191211112
一、试验目的
通过本次试验使学生掌握UML建模语言的基础知识和rose软件的基本用法，并进一步熟练掌握绘制业务用例框图和用例文档基本步骤和方法。
二、试验要求
根据实验题目内容，完成相应的实验任务。
三、实验内容
1.一个新的音像商店准备采用计算机系统向比较广泛的人群销售或租借录像带和
光碟。
该音像商店将存有大约1000 盘录像带和500 张光碟，所有的录像带和光碟都有一个条码，可以使用条码扫描仪来支持销售和返还，客户会员卡也同时条码化。
客户可以预定录像带并在指定日期来取。
系统必须拥有灵活的搜索机制来回答客户的询问。
根据上述描述，请你给出音像租赁销售系统的业务用例模型和系统用例模型，任选一个系统用例写出用例文档。
2.可以根据本小组自定的系统完成用例图和用例文档。
四、实验结果
客户信息管理业务用例图
该客户信息管理主要实现对客户信息的增加、删除、修改和查询。
系统用例图。
实验二 UML用例图建模参考答案
1. 找出actor和外部系统,确定系统边界.参与者：呼叫者、邮箱用户2. 主要功能分析(参与者期望的系统行为等)(1). 呼叫者保留信息(留言).(2). 邮箱用户管理信息: 收听/存储/删除.(3). 邮箱用户更改问候语.(4). 邮箱用户更改密码.3. 初步找到的用例呼叫者：保留信息邮箱主人：接收信息、更改问候语、更改密码4. 进一步寻找用例邮箱主人：登录邮箱呼叫者、邮箱主人：拨打邮箱号码5. 分析用例之间的关系本例较为简单,只使用“包含关系”即可.6. 绘制初步用例图7. 编写每一个用例的脚本8. 区分脚本中的主事流或异常情况事件流9. 细化用例图,完成用例模型(略)用例1: 拨打邮箱号1. 呼叫者拨打语音邮件系统的主号码.2. 语音邮件系统发出提示音：输入邮箱号码并加#号.3. 呼叫者输入接收者的邮箱号.4. 语音邮件系统发出问候语：已进入XX的邮箱,请留言. 用例2: 保留信息1. 呼叫者完成邮箱号输入操作.2. 呼叫者说出信息.3. 呼叫者挂断电话.4. 语音邮件系统将记录的信息存放在接收者的邮箱中. 用例3: 登录系统1. 邮箱用户完成邮箱号输入操作.2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同)3. 语音邮件系统播放邮箱菜单:按1键接收信息.按2键更改密码.按3键更改问候语.用例4: 接收信息1. 邮箱用户完成登录操作.2. 邮箱用户选择“接收信息”菜单选项.3. 语音邮件系统播放信息菜单:按1收听当前信息; 按2存储当前信息; 按3删除当前信息;按4返回邮箱菜单.4. 邮箱用户选择“收听当前信息”菜单选项.5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信息.(注意: 只播放,不删除)6. 语音邮件系统播放信息菜单.7. 用户选择”删除当前信息”,则信息被永久删除.8. 继续执行第3步.用例4变体#1: 存储一条信息1.1 以第6步作为开始.1.2 用户选择“存储当前信息”.1.3 当前信息从新信息队列中删除并添加到旧信息队列中.1.4 继承执行第3步.用例5: 更改问候语1. 邮箱用户完成登录操作.2. 邮箱用户选择“更改问候语”菜单选项.3. 邮箱用户说出新的问候语.4. 邮箱用户按下#键.5. 邮件系统设置新的问候语.用例5变体#1: 在确认前挂断电话1.1 以第3步作为开始.1.2 邮件用户挂断电话.1.3 邮件系统保留旧的问候语.用例6: 更改密码1. 邮箱用户完成登录操作.2. 邮箱用户选择“更改密码”菜单选项.3. 邮箱用户输入新的密码.4. 邮箱用户按下#键.5. 邮件系统设置新的密码.用例6变体#1: 在确认前挂断电话1.1 以第3步作为开始.1.2 邮件用户挂断电话.1.3 邮件系统保留旧的密码.。
UML中的用例图实践案例
UML中的用例图实践案例UML（统一建模语言）是一种用于软件开发的标准化建模语言，它提供了一套丰富的图形符号和概念，用于描述和设计软件系统的各个方面。
其中，用例图是UML中最为常用和重要的一种图形表示方法，它用于描述系统的功能需求和用户与系统之间的交互关系。
本文将通过一个实践案例，介绍用例图在软件开发中的具体应用。
假设我们要开发一个在线购物系统，该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。
首先，我们需要明确系统的角色和用例。
在这个案例中，系统的角色包括用户、管理员和支付网关。
用户可以注册账号、浏览商品、添加购物车、下单和支付；管理员可以管理商品信息；支付网关负责处理支付请求。
接下来，我们可以使用用例图来表示这些角色和用例之间的关系。
首先，我们可以在用例图中用椭圆形表示各个用例。
在本案例中，我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。
然后，我们可以用矩形表示各个角色，即用户、管理员和支付网关。
接着，我们可以使用实线箭头来表示角色与用例之间的关系。
例如，用户可以注册账号，我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。
除了角色和用例之间的关系，用例图还可以表示用例之间的关系。
在本案例中，用户可以浏览商品、添加购物车、下单和支付，这些用例之间存在一定的先后顺序。
我们可以使用虚线箭头来表示这种顺序关系。
例如，用户可以先浏览商品，然后将商品添加到购物车，最后下单和支付。
我们可以在浏览商品和添加购物车之间画一条虚线箭头，表示用户在浏览商品后可以将商品添加到购物车。
此外，用例图还可以表示用例之间的包含和扩展关系。
在本案例中，用户下单时可能需要选择配送地址，我们可以将选择配送地址作为一个包含关系，用一个带有加号的实线箭头表示。
另外，用户下单时还可以选择使用优惠券，这可以作为一个扩展关系，用一个带有箭头和加号的虚线箭头表示。
通过用例图，我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11
不恰当的“时间”参与者
✓ 时间：参与者，一种习惯用法，用于激活那 些系统定期的、自动执行的用例
✓ “检查是否可以退定金”的时候，时间仅仅 是一个系统内部的判断条件，而不是参与者
12
无效的参与者泛化
✓ 参与者泛化：特殊参与者会继承泛化参与者所有的要素！
✓ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则
3
问题用例图1
✓ 领导的角色没有价值； ✓ 旅店房间预订系统用例没有意义
4
问题用例图2
✓ 用例图不描述 业务流程
✓ 图中箭头不代 表前后顺序
5
问题用例图3
✓ 用例图不描述程序流程 ✓ 不描述控制逻辑
6
基于用例的需求分析过程
1. 获取原始需求 2. 开发一个可以理解的需求
识别参与者 识别用例 构建用例图
登录
顾客
客户 服务员
<<include>>
预定房间
计算总费用
<<include>>
取消预定
退还定金
查询房间信息
管理价格
时间
打印预定情况
21
用例关系
<<extend>> Extend <<include>> Include
Generalization
22
4. 用例关系-1：明显的错误
✓依赖关系：include, extend都是依赖关系 (dependency)的构造 型(stereotype)，带箭 头的虚线表示 ✓“extend”关系的方 向，子用例对主用例的 扩展
系统需要应付（处理）那些硬设备
系统需要和那些外部系统交互
谁（或什么）对系统运行产生的结果（值）感兴趣
时间、气温等内部外部条件
……
时间
10
“时间”参与者的使用
✓时间：参与者，一 种习惯用法，用于激 活那些系统定期的、 自动执行的用例
✓“计算总费用”的 时候，时间仅仅是一 个条件，而不是参与 者，因为此时它是作 为系统的一部分
UML系统分析与设计 UML-System Analysis & Design
李鹏飞 pengfei0302@
第6 章用例建模作业
Use-Case Modeling
旅店管理系统
某公司要开发一个旅店管理系统，该旅店可对外开放10 个双人间和10个单人间，房间费用视情况按季节调整， 但周一到周五半价（周末全价）折扣不变。对于外界请求， 该系统应能根据请求入住时间预定指定档次的房间，记录 旅客姓名、地址、联系电话、有效证件号、房间类型和预 定天数，并计算出总费用。预定的同时旅客按规定须提交 10%定金。六个小时之内旅店允许旅客取消预定，并退 回所有定金，超过六个小时定金不退还。每周一系统自动 打印一周预定情况清单。采用哪种费用支付方式和何种类 型操作界面尚不确定。
参与者透过系统边界直接与系统交互，参与者的确定代表系统 边界的确定
有意义的交互 考虑责任边界，非物理边界
任何事物
人、外系系统的主要功能 谁改变系统的数据
服务员
谁从系统获取信息
顾客
谁需要系统的支持以完成日常工作任务
谁负责日常维护、管理并保证系统正常运行
23
4. 用例关系-2：什么关系？
✓用例是一个完 整的交互，用例 之间没有顺序的 关系
24
4. 用例关系-3
25
扩展关系的使用
使用扩展的一个潜在问题是创建过深的扩展依赖层次
Jacobson博士建议永远不要扩展一个扩展
对于在描述用例的时候，什么时候用扩展，什么时候 用可选路径，Jacobson建议：
这样的方法没有任何意义
✓ 在系统中如果两个参与者涉及相同的用例，则合并
13
2 识别用例
关键词：价值 定义
用例实例是系统执行的一系列动作，这些动作将生 成特定参与者可观测的结果值
一个用例定义一组用例实例
简洁：参与者使用系统达到目标
14
2 识别用例
用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度
只有当扩展用例与被扩展用例完全分离（即它本身是一个独 立的具体用例或者是其他用例需要的一个小片段）时，才使 用扩展关系
基用例自身必须是完整的，它的正确执行不需要扩展。否则， 就应该用可选路径来描述附加行为
26
包含关系的使用
包含关系使用不当容易诱使人们进行功能分解， 从而导致对用例的误用
Jacobson说，“事实上，今天一些人误用了用例， 把它们用来描述功能（注：指功能分解式的分析） 而不是对象，反过来又指责用例概念存在问题”
16
用例干什么？
✓“其他”、“打印清 单”用例和外围没有任 何有意义交互，和其他 用例也没有任何关系， 这样的用例有意义吗？ ✓“其他”用例又代表什 么呢？想说明什么样的 功能需求？
17
用例粒度
✓注意“管理 用例”的使用！
18
用例粒度太小
19
看看这个用例图
✓参与者与用例的定义！
20
3 构建用例图(一)
15
2 识别用例
某公司要开发一个旅店管理系统，该旅店可对外开放10 个双人间和10个单人间，房间费用视情况按季节调整， 但周一到周五半价（周末全价）折扣不变。对于外界请求， 该系统应能根据请求入住时间预定指定档次的房间，记录 旅客姓名、地址、联系电话、有效证件号、房间类型和预 定天数，并计算出总费用。预定的同时旅客按规定须提交 10%定金。六个小时之内旅店允许旅客取消预定，并退 回所有定金，超过六个小时定金不退还。每周一系统自动 打印一周预定情况清单。采用哪种费用支付方式和何种类 型操作界面尚不确定。
3 详细、完整地描述需求
进行用例阐述
4 重构用例模型
识别用例间的关系 对用例进行组织和分包
7
1 识别参与者
参与者，Actor
关键词：边界 参与者：在系统之外，透过系统边界与系统进行有
意义交互的任何事物
8
1 识别参与者
参与者要点 系统外
参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界
27
泛化的危害
一个售货员可以终止任何交易，除了那些需要特殊的售 货员（高级代理）终止的超过了一定限制的交易
普通售货员
终止一个交易
终止一个基本交易
高级代理
普通售货员 终止一个小交易 终止一个大交易
终止一个大交易
高级代理
28
再看一个
29
用例规约
用例规约用来描述用例的，不是用例图 用例规约该写什么？ 用例规约需要与用例图相对应