用例图用例建模作业
图书管理系统用例建模报告（用例图、类图、时序图）
软件系统分析与设计实验报告学院：计算机科学与技术学院专业：软件工程学号：*********姓名：***实验名称：图书管理系统用例建模时间：一、实验内容与要求本实验要求学生对学校的图书馆管理系统进行需求分析，对系统功能进行用例建模，画出用例图，类图以及相应的时序图。
在使用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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
UML用例模型和类图练习
UML用例模型和类图练习
1.
一个小型网络水果超市，负责给用户网上订购苹果、芒果、桃子、荔枝。
用户可以注册成为会员，预约、订购、查询、取消等常规动作。
请设计用例模型.
1）参与者
2）用例图
3）一个重要的用例进行描述
2. 画出类图
一家公司有许多部门，通过部门名唯一的确定一个部门，每个部门有一名经理主管，也有的经理不管理任何一个部门；
每个部门生产多种产品，每种产品仅有一个部门生产。
该公司有许多员工为之工作，员工又进一步划分为经理与工人两类。
每名工人可以参加多个项目，每个项目需要多名工人；
每位经理可以主持多个项目，每个项目仅有一人主持。
作业2-用例图
1. 对于一个电子商务网站而言，以下哪些不是合适的用例，指出并说明理由。
输入支付信息将商品放入购物车结账预订商品用户登录邮寄商品查看商品详情输入支付信息：太小邮件商品：系统功能之外查看商品详情：太小2. 为了满足物业中介行业的信息化要求，甲公司基于详尽的需求调研与分析，准备研发一套符合市场需要的、实用的信息管理系统。
主要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功能。
该公司小王，通过多次的与潜在客户的交流与沟通，完成了最初的用例模型的开发，下图是一个物业管理系统用例模型的局部：修改房源信息（1）但小李认为该模型不符合“用例建模”的思想，存在明显的错误。
请用200字以内说明错误所在，并说明应该如何修改。
1.主要错误：用例的分解太细，并没有遵从每个用例为用户传递一个有价值的结果的原则。
在原设计中“打开房源信息页面”、“录入房源信息”、“确认提交信息”都只是一个操作步骤，因此不适合作为用例。
2.修改方法：将“打开房源信息页面”、“录入房源信息”、“确认提交信息”合并为“新增房源信息”。
（2）在上图中构造型“《include》”表示的是什么意思，它与“《extend》”之间的区别是什么？在用例模型中，构造型“《include》”是用来表示包含关系。
它通常用来表示被包含用例是被多包含用例使用的一个可复用模块，而《extent》且通常用来表示对用例的扩展。
3．找出下面过程中的参与者和用例，画出用例图；找出用例中合适的实体类。
（in English）某五星级饭店的总经理注意到该饭店采购部存在以下问题：(1)没有更新的库存注册信息(2)没有仓库中可用货物的订单(3)不能及时提供库存。
这些问题导致了客户的不满，因此他决定用计算机管理采购部。
采购部的具体工作如下：每当有货物要求时，仓库保管员把所需货物的通知单和它们的数量发送给采购部。
作业提交与批改系统用例图
作业提交与批改系统用例图通过用例分析法得知，本系统的使用者有：老师、学生。
其中：老师使用系统老师发布作业、老师批改作业、老师检查作业完成情况、老师检查重批；学生使用系统学生提交作业、学生互评作业、学生联系互评。
具体的用例建模结果如下图3-1、3-2所示：图3-1改进的作业提交与批改系统用例图图3-2改进的作业提交与批改系统用例图1.“老师发布作业”用例图3-3“老师发布作业”用例的活动图描述2.“学生提交作业”用例图3-4“学生提交作业”用例的活动图描述3.“老师批改作业”用例图3-5“老师批改作业”用例的活动图描述4.“老师检查作业完成情况”用例图3-6“老师检查作业完成情况”用例的活动图描述5.“学生联系重批”用例图3-7“学生联系重批”用例的活动图描述（二）作业对象的状态分析对于学生提交作业的状态：A.时间截止之前1）未提交：作业截止时间未到，作业未完成也未提交，没有任何记录，作业需完成2）已保存：作业截止时间未到，作业已经完成了一部分，但是没有提交，有之前完成部分的记录，等待提交3）已提交：作业截止时间未到，作业已经完成并且提交到系统，等待批阅B.时间截止之后1）未提交：作业截止时间已到，作业未完成未提交，并且无法提交2）已提交：作业截止时间已到，作业已经完成并提交，等待批阅作业对象的状态图如图3-8所示：图3-8作业对象的状态图对于教师批改作业的状态：1）未批改：等待教师的批改与反馈2）已批改：教师已经批改并返回到了学生端作业对象的状态图如图3-9所示：图3-9作业对象的状态图对于申请重批的作业状态：1）已审核未通过：申请已经被审核，但是未通过，可以重新申请或者查找自己的问题2）已审核已通过：申请已被通过，等待反馈3）待审核：申请还未审核，等待教师的回馈作业对象的状态图如图3-10所示：图3-10作业对象的状态图业务过程：1.学生提交作业，等待教师批阅2.教师批阅已提交作业3.学生得到批改结果（三）数据需求1.学号、姓名、班级。
UML用例图练习题及参考答案
试画出帐号管理系统的用例图。
用例有：创建新账户；设置账户；设置账户基本信息；设置账 户权限；删除帐户；查询账户。参与者有系统管理员。
一台自动饮料售货机共有6种不同饮料，售货机上有6个按钮，分 别对应6种饮料，顾客可以通过按钮来选择所要的饮料。每个按 钮旁有一个指示灯，用来表示该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽，用来收钱和找钱，假设一位顾客 购买矿泉水，不用找零，请给出描述上述场景的用例图。
UML用例图练习题及参考答案
练习题：
试画出学院班级管理系统的用例图。
用例有：登录；找回密码；查看、修改、删除、录入班级基本 信息，参与者有管理员与系院领导。
试画出学生成绩管理的用例图。
用例有：登录；找回密码；录入、修改、保存、查询、删除成 绩，参与者有教师与学生。
试画出网上选课系统的用例图。
学生
查询课程信息 选择课程
按课程编号查询 按课程名查询
删除已选课程 <<extend >>
登录
找回密码
维护课程信息
系统管理员
帐号管理系统的用例图
系统管理员
创建新帐号
设置帐号 查询帐号 删除帐号
设置帐号基本信息 设置帐号权限
饮料自动售货机顾客购买矿泉水的用例图
显示是否有饮料 选择饮料
自动售ቤተ መጻሕፍቲ ባይዱ机
付款 找钱 提供饮料
收钱
顾客
谢谢观赏！
2020/11/5
8
谢谢！
学院班级管理系统的用例图
登录
<<extend >> 找回密码
实验七 用例建模
实验六用例建模
[实验目的]
1、了解用例建模的方法；
2、掌握Rose的使用方法。
[实验内容]
按如下叙述建立用例模型：
某计算机厂商准备开发一个“网上计算机销售系统”以方便客户通过Internet 网络购买计算机。
客户可以通过Web页面登陆进入该系统，通过Web页面查看、选择、购买标准配置的计算机。
客户也可以选择计算机的配置或在线建立自己希望的配置。
可配置的构件（如内存）显示在一个可供选择的表中。
根据用户选择的每个配置，系统可以算出计算机的价格。
客户可选择在线购买计算机，也可以要求销售员在发出订单之前与自己联系，解释订单的细节，协商价格等。
客户在准备发出订单时，必须在线填写关于运送和发票地址以及付款细节（支票和信用卡）表格，一旦订单被输入，系统向客户发送一份确认邮件，并附上订单细节。
在等待计算机送到的时候，客户可以在线查询订单的状态。
后端订单的处理步骤是：验证客户的信用和付款方式、向仓库请求所购的计算机，打印发表并请求仓库将计算机运送给客户。
在客户订单输入到系统后，销售员发送邮件请求给仓库，附上所定的配置细节。
仓库从销售员那里获得发票，并给客户运送计算机。
[实验要求]
1、画出用例图；
2、说明建模过程。
[实验报告]
1. 报告要求用专门的实验报告纸书写，字迹清晰，格式规范；
2. 报告中写清姓名、学号、实验日期、实验题目、实验目的、实验要求；
3. 按要求完成实验；
4. 报告最后包含实验总结和体会。
chapter06用例图用例建模作业
用例的名称 用例描述：一句完整的话 用例间的关系 用例与参与者的关系
事件流的详细程度 事件流之间的流转
30
用例规格描述常见错误
用例描述中没有主参与者。 用例描述中只有参与者动作，没有系统动作。 事件流中的动作没有主语。 描述中有过多的用户操作细节，如按钮等界面元 素的具体实现。 描述过低的目标级别。
12
无效的参与者泛化
参与者泛化：特殊参与者会继承泛化参与者所有的要素！ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则 这样的方法没有任何意义 在系统中如果两个参与者涉及相同的用例，则合并 13
2 识别用例
关键词：价值 定义
用例实例是系统执行的一系列动作，这些动作将生 成特定参与者可观测的结果值 一个用例定义一组用例实例
登录 预定房间
<<include>>
计算总费用
<<include>>
顾客
客户
取消预定
退还定金
查询房间信息
服务员
管理价格
时间
打印预定情况
21
用例关系
<<extend>>
Extend Include Generalization
<<include>>
22
4. 用例关系-1：明显的错误
依赖关系：include, extend都是依赖关系 (dependency)的构造 型(stereotype)，带箭 头的虚线表示 “extend”关系的方 向，子用例对主用例的 扩展
只有当扩展用例与被扩展用例完全分离（即它本身是一个独 立的具体用例或者是其他用例需要的一个小片段）时，才使 用扩展关系 基用例自身必须是完整的，它的正确执行不需要扩展。否则， 就应该用可选路径来描述附加行为
实验1 用例图建模
实验一用例图建模一、实验目的1．熟悉用例图的基本功能和使用方法。
2．掌握如何使用建模工具绘制用例图方法。
二、预备知识Rational Rose 简介Rose模型（包括所有框图、对象和其他模型元素）都保存在一个扩展名为.mdl的文件中。
1. 环境简介1.1 Rational Rose可视化环境组成Rose界面的五大部分是浏览器、文档工具、工具栏、框图窗口和日志。
见图1-1。
图1-1：Rose界面●浏览器：用于在模型中迅速漫游。
●文档工具：用于查看或更新模型元素的文档。
●工具栏：用于迅速访问常用命令。
●框图窗口：用于显示和编辑一个或几个UML框图。
●日志：用于查看错误信息和报告各个命令的结果。
1.2浏览器和视图浏览器是层次结构，用于在Rose模型中迅速漫游。
在浏览器中显示了模型中增加的一切，如参与者、用例、类、组件等等。
Rose浏览器见图1-2。
浏览器中包含四个视图：Use Case视图、Logical视图、Component视图和Deployment视图。
点击每个视图的右键，选择new就可以看到这个视图所包含的一些模型元素。
图1-2：Rose浏览器1. 3框图窗口在图1-3所示的框图窗口中，我们可以浏览模型中的一个或几个UML框图。
改变框图中的元素时，Rose自动更新浏览器。
同样用浏览器改变元素时，Rose 自动更新相应框图。
这样，Rose就可以保证模型的一致性。
图1-3：框图窗口2. UML各类框图的建立2. 1建立用例图use case diagram从用例图中我们可以看到系统干什么，与谁交互。
用例是系统提供的功能，参与者是系统与谁交互，参与者可以是人、系统或其他实体。
一个系统可以创建一个或多个用例图。
●创建用例图（图2-1-1）在浏览器内的Use Case视图中，双击Main，让新的用例图显示在框图窗口中。
也可以新建一个包（右击Use Case视图，选择new→package，并命名），然后右击这个新建包的，选择new→use case diagram。
UML与软件建模：第一次作业（用例图绘制）
UML与软件建模：第⼀次作业（⽤例图绘制）⼀、⼩结⽤例图是UML⽤于描述软件功能的图形。
⽤例图包括⽤例、参与者及其关系，⽤例图也可以包括注释和结束。
⽤例图的要素：(1)参与者，即与⽤例存在交互关系的系统外部实体;(2)⽤例，⽤来描述个相对独⽴的软件功能 ;(3)关系，包含参与者与⽤例的关系，参与者相互之间的关系，以及⽤例相互之间的关系等。
参与者(actor)也称为活动者，是与系统发⽣交互的外部实体。
“⼩⼈”图标可以表⽰与系统进⾏交互的参与者。
参与者类型有四种类型：⼈、设备、其他系统、时间；参与者之间的关系有泛化关系和通信关系。
⽤例也被称为⽤况、⽤案。
⽤例表⽰系统执⾏的⼀组动作，它会给系统或者参与者产⽣⼀组可观测的结果，⽤例描述系统的⼀个功能。
它的含义是在⼀个应⽤场景下⾯，系统为⽤户提供⼀个完整的服务，这个服务的完成需要⽤户与系统直接发⽣⼀次完整的⼈机交互过程。
⽤例的表⽰：UML规定⽤椭圆来表⽰⼀个⽤例，⽤例的名字放在椭圆⾥⾯或者下⽅。
因为⽤例⽤来描述系统的功能,因此⽤例的名字应该⽤动词或动词短语。
参与者与⽤例之间的关系：启动⽤例，获取⽤例提供的服务，为⽤例提供服务，给系统提供信息。
⽤例之间存在泛化关系、包含关系、扩展关系。
⽤例图的作⽤：1.描述软件功能2.建⽴软件分析模型的依据3.软件测试的依据⽤法：⽤例：⽤圆括号（），或者使⽤关键字来定义⽤例；⾓⾊：⽤两个冒号包裹来表⽰，或者通过关键字actor来定义⾓⾊；⽤箭头-->连接⾓⾊和⽤例。
⽤例描述：⽤双引号来定义多⾏的⽤例描述，--，==为分隔符，并且可以在分隔符中间放置标题。
连接：⽤箭头连接⾓⾊和⽤例，横杠越多箭头越长，可以在箭头定义的后⾯加⼀个冒号来添加标签；继承：如果⼀个⾓⾊或者⽤例继承于另⼀个，⽤<|--符号表⽰。
注释：⽤note left of , note right of , note top of , note bottom of等关键字给⼀个对象添加注释。
chapter06用例图用例建模作业
35
34
用例规约：预定房间
…… 涉及的用例：计算总费用 前置条件：用户成功登录 正常事件流： 1.用户选择预定房间后启动该用例 2.系统显示用户可以预定的房间列表 3.用户选择某一个房间 4.系统启动“计算总费用”用例，来计算该房间的费用 5.用户确认本次预定业务 6.用户选择支付方式，以便预付定金 ……
31
较为合理的用例图(二)
<<include>> <<include>> 预订房间 计算总费用 酒店前台 <<extend>> 取消预订 退还定金 查找房间
管理人员
调整价格
争论： 使用包含还 是扩展？
32
时间
打印预订清单
较为合理的用例规格说明1
用例名称：预定房间 涉及的参与者：酒店前台 描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间， 预定的同时旅客按规定须提交10%定金。 前置条件：前台工作人员必须已经登录到这个系统 后置条件：预定信息正确的记录到系统中 主事件流： 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。 3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定，工作完成。 备选事件流： 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束 33 5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。
3
问题用例图1
领导的角色没有价值； 旅店房间预订系统用例没有意义
4
问题用例图2
用例图不描述 业务流程 图中箭头不代 表前后顺序
- 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
用例规约
用例规约用来描述用例的，不是用例图 用例规约该写什么？ 用例规约需要与用例图相对应