UML需求分析步骤实例解析
UML系统需求分析建模实例(包括业务建模)
系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用 务执行者】和业务角色【业务工人】与 例进行交互。 业务用例进行交互。
做专业的企业，做专业的事情，让自 己专业 起来。2 020年1 2月上 午12时3 5分20. 12.200: 35Dece mber 2, 2020
时间是人类发展的空间。2020年12月2 日星期 三12时 35分4 秒00:35: 042 December 2020
科学，你是国力的灵魂；同时又是社 会发展 的标志 。上午1 2时35 分4秒上 午12时 35分00 :35:042 0.12.2
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
基于UML的外卖订餐系统需求分析
面向对象的分析和设计说明书( 2018 -- 2019 学年第二学期)题目：基于UML的外卖订餐系统需求分析日期：2019 年5 月3日1. 系统概述2．系统分析建模外卖订单系统是服务于餐馆外卖活动的一个简单的信息系统，开发该系统主要希望实现扩大本餐馆宣传、缩短顾客订餐时间、减少订餐错误、便于订单统计分析等，最终达到扩大餐馆影响力、提高餐馆外卖业务效率、实现一定程度的决策支持的目的。
该系统按照功能主要分为三类角色，分别是顾客，商家，送餐员。
顾客角色主要可执行的操作有顾客用户操作（包括登录和注册），检索操作（包括检索餐品或商家等），订单操作（包括编辑订单和提交订单），评价操作（包括评价餐品和餐厅）。
商家角色主要可执行的操作有商家用户操作（包括登录和注册），餐厅管理（包括菜单编辑、编辑餐厅信息等），订单管理（包括查看和更新订单），评论管理（包括查看评论和回复评论）。
送餐员角色主要可执行的操作有送餐员用户操作（包括登录和注册），订单操作（包括配送订单、订单查询、确认接单等），通知操作（通知顾客或商家）。
2.1用例图【三类顾客顶层用例图】图1三类顾客顶层用例图本系统预计实现的核心功能有：（1）顾客角色——顾客操作查询餐品：按照餐品种类或名称查询后选择某一餐厅查询餐厅：按照餐厅名查询后选择某一餐厅餐厅列表：餐厅列表包括了该餐厅的基本信息，包括餐厅名称、餐厅位置、餐厅距离、餐厅销量、人均消费。
订单管理：记录顾客当前正在进行的订单以及历史订单。
顾客可以删除历史订单，也能及时查看当前正在进行订单的状态和信息。
购物车界面：相当于临时订单界面，用于显示当前订单中已选餐品的信息（包括餐品的名称、数量、总价）和订单支付状态。
确认购物车信息无误后，顾客提交订单并支付。
提交订单后，购物车中不再显示该订单的信息。
（2）商家角色——商家操作确认接单功能：商家在收到用户提交的订单后，确认接单并通知该订单的顾客已接单。
商家确认接单后，将当前订单信息发送给附近区域的送餐员，等待送餐员接单。
UML案例--银行系统
（2）银行职员将相关信息输入后提 交，系统判断账户是否存在且有效，账 户中的金额是否大于转账金额。
（3）如果账户有效并存在同时金额 足够，建立交易记录，同时修改账户金 额，保存交易记录。
（4）判断转入账户是否属于同一银 行。如是同一银行，系统先确认转入账 户是否存在并有效。如有效更新账户相 关信息，建立转账记录，保存转账记录。 （5）如果转入和转出账户不是同一银
（1）系统提示输入用户的相关 信息和取款金额。
（2）银行职员将相关信息输入 后提交，系统判断账户是否存在且 有效，账户中的余额是否大于取款 金额。
（3）如果账户有效并存在同时 金额足够，建立交易记录，同时修 改账户金额，保存交易记录。
UML统一建模语言
三、创建系统动态模型 13、客户转账活动图
客户转账活动图创建二个泳道，分 别是银行职员对象和系统对象，具体的 活动过程描述如下：
UML统一建模语言
二、创建系统用例模型
银行职员用例能够通过 该系统进行如下活动：
（1）登录银行系统。银 行职员在登录系统时，必须 通过系统的身份验证才能进 入银行系统主界面进行下一 步的操作。
（2）对客户的账户进行 管理，包括为客户创建新的 账户、修改账户信息和删除 账户。
UML统一建模语言
二、创建系统用例模型
UML统一建模语言
三、创建系统动态模型
4、客户本行转账序列图和交互图
客户进行本行转账的工作流程如下： （1）客户向银行职员提出本行转账的 要求。 （2）银行职员在系统主界面请求转账 操作，系统创建转账界面。 （3）银行职员添加转账款信息后，提 交至账户类（转出）。 （4）账户类确认是否存在该账户，并 确认账户中的金额是否足够支付转账款项， 如可足够支付则计算新的账户余额，更新 数据库中该账户的信息，发送消息给转账 类，创建转账交易记录，保存转账交易记 录。 （5）转账界面将转账信息传递给账户 （转入），查询该账户是否存在。如存在 计算账户余额，然后更新数据库的数据。 发送消息给转账类，创建转账交易记录， 保存转账交易记录。
uml图例讲解
9
A
UML图例讲解
(10)当手机开机时，它处于空闲状态，当用户使用电话呼叫某 人时，收集进入拨号状态。如果呼叫成功，即电话接通，手机 就处于通话状态；如果呼叫不成功，如对方线路有问题或关机， 则拒绝接听。这时手机停止呼叫，重新进入空闲状态，手机进 入空闲状态下被呼叫，手机进入响铃状态(ringing)；如果用户 接听电话(pick)，手机处于通话状态；如果用户未做出任何反 应，可能他没有听见铃声，手机一直处于响铃状态，如果用户 拒绝来电，手机回到空闲状态。
教务管理人员：
①登录系统；
②教师、学生名单管理；
③学期教学计划管理；
④成绩管理；
⑤课程分配，每次课程分配时都必须打印任课通知书。
学生：
①登录系统；
②选课。
教师：
①登录系统；
②成绩管理，并且可以选择是否生成成绩单。
请根据以上信息画出该系统的用例图。
1
A
UML图例讲解
(2)某银行储蓄系统需求说明如下。
“上课登记”用例的主要事件流如下： 学生从系统菜单中选择“上课登记”； 系统显示指纹识别界面； 学生将手指放置于界面上； 系统捕获并识别学生的指纹，向学生返回识别的身份信息； 学生选择“确认”按钮； 系统生成一个关于该登记学生及当前日期、时间的新记录，并将该记录 保存到数据库中。 请根据以上描述绘制“上课登记”用例的顺序图。
2
A
UML图例讲解
(3)一个公司可以雇佣多个人，某个人在同一时刻只能为一家 公司服务。每个公司只有一个总经理，总经理下有多个部门经 理管理公司的雇员，公司的雇员只归一个经理管理。请为上面 描述的关系建立类模型，注意捕捉类之间的关联并标明类之间 的多重性。
UML实例UML案例(完整建模)(汽车租赁系统)
theWorkRecord : WorkRecord
系统的状态图
系统的活动图
customer request Employee check the request no new request store the request have new request handle new request
Manager Interface
Skill Worker
系统功能需求
① ② ③ ④ 满足上述需求的系统主要包括以下模块： 基本数据维护模块 基本业务模块 数据库管理模块 信息查询模块
基本数据维护模块
① ② ③ ④ 基本数据维护模块包括的主要功能模块： 添加车辆信息 修改车辆信息 添加员工信息 修改员工数据
基本业务模块
① ② ③ ④ 基本业务模块包含的功能： 用户填写预定申请 工作人员处理预定请求 技术人员填写服务记录 工作人员处理还车
建立UML模型框架
选择J2EE模式
系统的用例图
① ② 创建用例图之前首先需要确定参与者。 系统中的参与者主要有两类： 客户 公司职员
系统的用例图
1. 客户参与的用例图 2. 公司职员参与的用例图
客户参与的用例图
公司职员参与的用例图
系统的时序图
1. 2. 3. 4. 管理人员开展工作的时序图 客户预订车辆的时序图 客户取车的时序图 客户还车的时序图
数据库模块
① ② ③ ④ 数据库模块的功能： 客户信息管理 车辆信息管理 租赁信息管理 职员信息管理
信息查询模块
① ② ③ ④
信息查询模块是查询数据库中的相关信息， 包括： 查询客户信息 查询职员信息 查询车辆信息 查询客户记录
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
基于UML的外卖订餐系统需求分析
基于UML的外卖订餐系统需求分析目录1. 系统概况 (3)2. 系统需求 (4)2.1. 功能性需求 (4)2.2. 非功能性需求 (4)3. 系统开发时间管理 (5)4. 系统开发可行性分析 (5)4.1. 技术的可行性： (6)4.2. 经济的可行性： (6)4.3. 操作的可行性： (6)5. 系统开发项目人员安排 (6)6. 基于UML的系统分析 (7)6.1. 用户用例图 (7)6.2. 系统主要用例 (11)7 总结 (29)图表目录表格 1 项目人员安排表 (7)表格 2 顾客管理账户用例描述 (11)表格 3 找回密码用例描述 (12)表格 4 顾客订餐用例描述 (15)表格 5 送货员送餐用例描述 (16)表格 6 顾客查看历史订单用例描述 (16)表格 7 主管查看历史订单用例描述 (17)表格 8 菜品评论与主管查看用例描述 (21)表格 9 主管管理菜品描述 (24)表格 10 系统管理员用例描述 (26)图 1 外卖订餐系统结构图1 3图 2 外卖订餐系统结构图2 4 图 3 系统开发甘特图 5 图 4 外卖订餐系统用户用例图8 图 5 顾客用例图9 图 6 主管用例图10 图 7 送餐员用例图10 图 8 系统员用例图11 图 9 账户管理活动图13 图 10 顾客注册顺序图14 图 11 顾客登录管理账户顺序14 图 12 顾客订餐活动图18 图 13 送餐员送餐活动图19 图 14 主管查看历史订单活动图20 图 15 顾客订餐顺序图20 图 16 送餐员送餐顺序图21 图 17 顾客评论活动图22 图 18 主管查看评论活动图23 图 19 顾客评论顺序图23 图 20 主管管理菜品活动图25 图 21 主管管理菜品顺序图26 图 22 系统管理员活动图28 图 23 系统管理员顺序图291.系统概况外卖订单系统是服务于餐馆外卖活动的一个简单的信息系统，开发该系统主要希望实现扩大本餐馆宣传、缩短顾客订餐时间、减少订餐错误、便于订单统计分析等，最终达到扩大餐馆影响力、提高餐馆外卖业务效率、实现一定程度的决策支持的目的。
UML完整例子
• “计算机类”、“非计算机类”是该系统中图书
的两大分类，因此应该对其建模，并改名为“计 算机类书籍”和“非计算机类书籍”，以减少歧
义；、
火龙果 整理
筛选备选类
• “外借情况”则是用来表示一次借阅行为， 应该成为一个候选类，多个外借情况将组 成“外借情况列表”，而外借情况中一个 很重要的角色是“朋友”—借阅主体。 • 虽然到本系统中并不需要建立“朋友”的 资料库，但考虑到可能会需要列出某个朋 友的借阅情况，因此还是将其列为候选类。 为了能够更好地表述，将“外借情况”改 名为“借阅记录”，而将“外借情况列表” 改名为“借阅记录列表”；
火龙果 整理
需求描述
• 在使用该系统录入新书籍时系统会自动按 规则生成书号，可以修改信息，但一经创 建就不允许删除。 • 该系统还应该能够对书籍的外借情况进行 记录，可对外借情况列表打印。 • 另外，还希望能够对书籍的购买金额、册 数按特定时间周期进行统计
火龙果 整理
火龙果 整理
4.绘制交互图
• 首先根据自己的喜好和实际的表现需要来 • 不过由于它们在语义上是等价的，因此可
以绘制出一种，再通过建模工具来自动转 换成另一种图 。 选择顺序图或通信图。
火龙果 整理
（1）准备工作
• 分析模型中的交互图彻重于分析类的职责分配
•
一本书只有一册，因此只能够被借一次，因此对于一本 Book而言只能有一个RecordId与其对应
火龙果 整理
限 定 • 分 析
火龙果 整理
3.绘制用例图
• 用例图的绘制流程
（1）记录需求—特性表
编号 说明
火龙果 整理
火龙果 整理
UML完整例子
(完整版)UML需求分析步骤实例解析
•UML需求分析步骤实例解析在UML使用过程中，经常会遇到UML需求分析问题，这里就向大家介绍一下UML的需求分析大致步骤，为了便于大家理解以实例向大家介绍，希望通过本文的介绍你对UML需求分析步骤有所了解。
本节向大家介绍一下UML需求分析的一般步骤，本节用实例向大家介绍，相信通过本节的介绍你对UML需求分析有一定的认识。
下面让我们一起来学习具体介绍吧。
基于UML需求分析在初步的业务需求描述已经形成的前提下，基于UML需求分析大致可分为以下步骤：（1）利用用例及用例图表示需求。
从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象；形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。
（2）利用包图及类图表示目标软件系统的总体框架结构。
根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。
上述两个步骤并没有时序关系，它们可以并行展开，如图5-3-1所示。
图5-3-1 UML需求分析过程本节将依次介绍上述步骤中涉及的UML语言机制，并结合“家庭保安系统”实例说明每步骤中基于UML需求分析方法。
开发场景场景是指从单个执行者的角度观察目标软件系统的功能和外部行为。
这种功能通过系统与用户之间的交互来表征。
因此也可以说，场景是用户与系统之间进行交互的一组具体的动作。
相对于用例而言，场景是用例的实例，而用例是某类场景的共同抽象。
对场景的完整描述应包含场景名称、执行者实例，前置条件、事件流和后置条件。
例如，“家庭保安系统”的初步需求描述：“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。
配置操作包括：（1）指定每一传感器的种类和编号；（2）设置开、关机密码；（3）指定报警电话电码；（4）指定报警延迟和电话重拨延迟时间（以秒为单位）；当软件系统收到传感器发出的数据后，判别是否出现异常事件。
UML用例图在需求分析中的应用指南
UML用例图在需求分析中的应用指南需求分析是软件开发过程中的重要环节，它的目标是明确系统的功能需求和用户需求，为后续的设计和开发工作提供基础。
在需求分析过程中，UML（统一建模语言）用例图是一种常用的工具，它可以帮助分析师和开发人员更好地理解系统的功能和用户行为。
本文将介绍UML用例图在需求分析中的应用指南，帮助读者更好地掌握这一工具。
1. 什么是UML用例图UML用例图是一种用于描述系统功能和用户行为的图形化工具。
它通过用例（Use Case）和参与者（Actor）之间的关系来展示系统的功能和用户与系统的交互。
用例图可以帮助分析师和开发人员更好地理解系统的需求，从而更好地设计和开发系统。
2. 用例图的基本元素用例图包含用例、参与者和关系三个基本元素。
用例表示系统的功能或者用户的行为，可以理解为一个功能模块或者一个用户操作。
参与者表示系统的用户，可以是人、其他系统或者外部设备。
关系表示用例和参与者之间的关系，常见的关系有关联关系、包含关系和扩展关系等。
3. 用例图的绘制步骤绘制用例图的步骤如下：（1）确定系统的功能和用户行为，将其抽象为用例。
（2）确定系统的参与者，包括人、其他系统和外部设备。
（3）绘制用例图的框架，将用例和参与者放置在合适的位置。
（4）使用关系连接用例和参与者，表示它们之间的关系。
（5）完善用例图，添加必要的细节和注释。
4. 用例图的应用场景用例图在需求分析中有广泛的应用场景，下面列举几个常见的应用场景：（1）明确系统的功能需求：用例图可以帮助分析师和开发人员明确系统的功能需求，从而更好地设计和开发系统。
（2）识别用户需求：用例图可以帮助分析师和开发人员更好地理解用户的需求，从而更好地满足用户的期望。
（3）辅助系统设计：用例图可以作为系统设计的基础，帮助设计人员更好地理解系统的功能和用户行为，从而更好地设计系统的架构和模块。
（4）沟通和交流：用例图可以作为沟通和交流的工具，帮助团队成员之间更好地理解系统需求和设计思路。
1.需求分析--类图
需求分析的几大要素
目的 范围 问题 人 物 事情
类图关注与人和物，以及他们的关系。 类图关注与人和物，以及他们的关系。
什么是类图？（用于需求分析时） 什么是类图？（用于需求分析时） ？（用于需求分析时
主要是用来描述人和物（ 主要是用来描述人和物（类）以及他们之间关系的图 用类图获取需求的大致步骤
类之间的关系3 类之间的关系
关系三： 关系三：泛化 扩展
关系
班主任和讲师有什么共性？ 班主任和讲师有什么共性？
班主任 部门 性别 工龄 管理经验 教员 部门 性别 工龄 讲课经验 表达能力 知识水平
班主任
教员
类之间的关系4 类之间的关系
关系四： 关系四：依赖 依赖关系，我有你的电话，你没有我的电话；我没有你 依赖关系，我有你的电话，你没有我的电话； 不能活；用虚线箭头表示。 不能活；用虚线箭头表示。 例如：鸟和水、 例如：鸟和水、空气之间关系 class 鸟 { public 鸟（水 W，空气 O） ， ） { } }
类之间的关系汇总
练习1 练习
请用类图描述你和你另外一半的关系
你和你另外一半关系
练习2 练习
请用类图描述公司、 请用类图描述公司、雇员的关系
公司、 公司、雇员的关系
练习3 练习
请用类图描述香蕉、苹果、 请用类图描述香蕉、苹果、梨子的关系
香蕉、苹果、 香蕉、苹果、梨子的关系
练习4 练习
请用类图描述公司的组织架构
识别出类 识别出类的主要属性 描绘出类之间的关系 对各类进行分析、抽象、 对各类进行分析、抽象、整理
测试你的OOA能力！ 能力！ 测试你的 能力
请从培训的角度来分析： 请从培训的角度来分析：
课室中有哪些人？ 课室中有哪些人？ 这些人有什么关键属性？ 这些人有什么关键属性？
UML中的业务用例图的绘制方法和实例分析
UML中的业务用例图的绘制方法和实例分析UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规则，用于描述系统的结构、行为和交互。
其中，业务用例图是UML中的一种图示工具，用于描述系统的功能需求和用户与系统之间的交互。
本文将介绍业务用例图的绘制方法，并通过一个实例分析来说明其应用。
一、业务用例图的绘制方法业务用例图主要由参与者（Actor）和用例（Use Case）两个元素组成。
参与者是系统外部的角色，可以是人、其他系统或外部设备等，用例则是描述系统功能的场景。
下面是绘制业务用例图的步骤：1. 确定参与者：首先要明确系统与外部世界的交互角色，这些角色可以是系统的用户、其他系统或外部设备等。
2. 确定用例：根据系统的功能需求，确定系统需要提供的各个功能场景，每个场景都可以作为一个用例。
3. 绘制参与者和用例：使用UML中的图形符号，将参与者和用例绘制在图中。
参与者通常用人的图标表示，用例则用椭圆形表示。
4. 连接参与者和用例：使用关联线将参与者与用例连接起来，表示参与者与用例之间的交互关系。
一般来说，参与者可以触发用例的执行，也可以接收用例的输出。
5. 添加关系：根据实际情况，可以添加其他关系，如扩展关系、包含关系等，以更准确地描述系统的功能和交互。
二、实例分析为了更好地理解业务用例图的应用，下面以一个在线购物系统为例进行分析。
在这个系统中，主要涉及的参与者有顾客和管理员。
顾客可以进行商品浏览、商品搜索、添加商品到购物车、结算购物车等操作，管理员则可以进行商品管理、订单管理等操作。
根据上述分析，我们可以绘制如下的业务用例图：（图示：一个包含顾客、管理员和相关用例的业务用例图）从图中可以看出，顾客和管理员是系统的两个主要参与者，它们与系统之间存在着不同的交互。
顾客可以通过浏览商品和搜索商品来获取所需的商品信息，然后将商品添加到购物车，并最终结算购物车。
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用例图PPT课件
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
uml课程设计需求分析文档
需求分析说明书第一部分引言1.1背景ATM自动柜员机（automatic teller machine）是银行在不同地点设置的一种小型机器，利用一张信用卡大小的胶卡上的磁带〔或芯片卡上的芯片〕记录客户的基本户口资料（通常就是银行卡，或称金融卡，或称提款卡），让客户可以透过机器进行提款、存款、转帐等银行柜台服务，大多数客户都把这种自助机器称为提款机。
中国大陆在1980年代末期才开始在深圳出现提款机，现在扩展至全国。
并且多数柜员机都已加入银联网络，只要是有银联标志的银行卡都可以通用，但收费与否则和发卡行的规定有关。
没有银联标志的卡只能在本行网络的柜员机上使用。
目前，国内已有大量自动柜员机，遍布于银行营业大厅、超市、商业机构、机场、车站、码头和闹市区。
因为ATM技术的高安全性和高速度，所以在我国的发展十分迅速，尤其在银行领域。
我国宽带网已初具规模，已建立成完整的电子商务安全认证体系。
几乎所有的银行都是采用ATM技术，主要用于各地区之间交换数据和ATM终端。
1.2文档概述ATM自动柜员机系统是由计算机控制的银行自动出纳系统，主要服务于活期储蓄，实现客户自助服务的电子化设备。
统一建模语言UML（Unified Modeling Language）是面向对象技术的一个重要应用，也是软件工程环境中对象分析和设计的重要工具。
通过UML对ATM自动取款机建模，实现查询余额，取款，转账，更改密码等业务，对各功能进行具体的分析和建模。
1.3参考资料UML基础与应用李磊等著网络资源第二部分任务概述2.1目标实现用户使用ATM 机的进行查询余额，取款，转账，更改密码的业务的基本功能。
2.2用户的特点ATM机面向的群体是很广泛的，无论是老人，小孩，成人都会用到ATM机。
因此它的操作性一定要做到简单，实用，而且还要保证系统的安全性。
第三部分需求规定3.1对功能的规定3.1.1系统用例关系图查看事务历史记录3.1.2系统功能概述客户插入卡，输入正确的密码进入系统，选择事务的类型即可进行相关的操作。
银行系统-UML需求分析图
电子科技大学软件学院标准实验报告（实验）课程名称UML电子科技大学教务处制表电子科技大学实验报告学生姓名：黄斌学号：2823102006学生姓名：马少龙学号：2823102008学生姓名：袁孝涛学号：2823102007学生姓名：文志伟学号：2823102009学生姓名：杨超学号：2823102010指导老师：訾德义实验地点：教学楼A105 实验时间：10,12,05一、实验室名称：软件实验室二、实验项目名称：可存取款ATM系统三、实验学时：16四、实验原理：（是不是把银行系统都改成ATMXXX？）五、实验目的：随着经济建设的发展，人民生活水平得到了质的飞跃，手头的多余资金越来越多，在倡导消费理念的同时，人们也热衷于理财，银行管理系统为广大用户提供了方便，快捷的资金管理通道。
银行系统分为ATM机，用户，后台服务器。
用户向ATM提交数据，ATM机向服务器提出申请，服务器向ATM发送数据，ATM机将数据反馈给用户。
银行系统主要功能用：取款，存款，账户设置，转账汇款，查询账户。
六、实验内容：一个功能完善的银行管理系统，必须包括以下的几个模块。
●用户登陆由用户登陆、用户注销、退出系统3个部分组成。
●取款客户从银行合法账户取出一定资金。
●查询账户客户接受银行合法账户余额。
●转账用户把一个合法账户的款项存到另一个合法账户。
●账户设置主要对用户的账户相关信息的设置与修改。
七、实验器材（设备、元器件）：a.试验环境Rose 2003b.操作系统window XP八、实验步骤：步骤1：需求分析步骤1.1：用户登陆用户登陆所包括的功能模块如下图：用户进入本银行管理系统的入口，没有得到身份验证的用户只能拥有最低的使用权限，即只能选择退出系统或是用户登陆。
这是一个稳定、安全的系统所必须具备的。
步骤1.2：账户管理账户管理系统是整个银行系统的核心，用户在此选项可以对合法账户的资金进行一定的操作，满足客户日常需要。
并且对自己账户的密码，个人信息等进行安全方面的设置。
应用面向对象技术与UML方法分析图书管理系统( 需求)
3.找谁
二、 UML静态模型—类图回顾 1.类图概念 类图描述了系统中的类及其相互之间 的各种关系，其本质反映了系统中包 含的各种对象的类型以及对象间的各 种静态关系（关联，子类型）。
一、UML静态模型—类图回顾
类图图符表示：
类名
WashingMachine
简单名 路径名 公有（+） 私有（-） 受保护（#）
1.“借阅者查找图书”用例描述
基本工作流程如下： ① 借阅者希望通过系统查询图书的信息。 ② 借阅者通过自助系统的用户界面SearchBookWindow录入图书的 ISBN/ISSN号，请求查找图书信息。 ③ 用户界面SearchBookWindow根据图书的ISBN/ISSN号将Book类实例 化，并请求图书信息。 ④ Book类实例化对象根据图书的ISBN/ISSN号加载图书信息，并提供 给用户界面SearchBookWindow。 ⑤ 用户界面SearchBookWindow向读者提示该图书信息。
第二步：分析需求
OOA分析过程
分析 用户 需求
系统分析员应 该深入地理解 用户需求，抽 象出目标系统 的本质属性， 并用模型准确 表示来 ；另 外要向领域专 家学习。
识别 类与 对象
确定问 题域中 的类和 对象
确定对 象的内 部特征
确定对 象的属 性的操 作
识别对 象之间 的关系
分类关系(一般 /特殊)、组成 关系(整体/部 分)，还有反映 对象属性之间 联系的实例连 接、反映对象 行为之间依赖 关系的消息等
借阅者进行的活动
用例
查找图书 登陆系统 查询个人信息 预定图书 借阅图书 归还书籍
可以通过图书名称或ISBN/ISSN号查找图书的详 细信息 能够根据图书证编号和相关密码登陆自助机器， 查询图书信息、个人信息和进行图书预定。 每个借阅者都可以通过自主机器在登陆后查询自 己的信息，但是不允许在未授权的情况下查询其 他人的信息。 登陆自助机器后，借阅者可与预定相关书籍。 可以通过图书管理员借阅相关书籍。 通过图书管理员归还书籍，如果没按时归还或书 籍损坏，需要缴纳罚金。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
•UML需求分析步骤实例解析
在UML使用过程中，经常会遇到UML需求分析问题，这里就向大家介绍一下UML的需求分析大致步骤，为了便于大家理解以实例向大家介绍，希望通过本文的介绍你对UML需求分析步骤有所了解。
本节向大家介绍一下UML需求分析的一般步骤，本节用实例向大家介绍，相信通过本节的介绍你对UML需求分析有一定的认识。
下面让我们一起来学习具体介绍吧。
基于UML需求分析
在初步的业务需求描述已经形成的前提下，基于UML需求分析大致可分为以下步骤：
（1）利用用例及用例图表示需求。
从业务需求描述出发获取执行者和场
景；对场景进行汇总、分类、抽象；形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。
（2）利用包图及类图表示目标软件系统的总体框架结构。
根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。
上述两个步骤并没有时序关系，它们可以并行展开，如图5-3-1所示。
图5-3-1 UML需求分析过程
本节将依次介绍上述步骤中涉及的UML语言机制，并结合“家庭保安系统”实例说明每步骤中基于UML需求分析方法。
开发场景
场景是指从单个执行者的角度观察目标软件系统的功能和外部行为。
这种功能通过系统与用户之间的交互来表征。
因此也可以说，场景是用户与系统之间进行交互的一组具体的动作。
相对于用例而言，场景是用例的实例，而用例是某类场景的共同抽象。
对场景的完整描述应包含场景名称、执行者实例，前置条件、事件流和后置条件。
例如，“家庭保安系统”的初步需求描述：“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。
配置操作包括：
（1）指定每一传感器的种类和编号；
（2）设置开、关机密码；
（3）指定报警电话电码；
（4）指定报警延迟和电话重拨延迟时间（以秒为单位）；
当软件系统收到传感器发出的数据后，判别是否出现异常事件。
如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。
然后软件系统负责报告时间、地点和异常事件的性质。
开机后，软件系统负责显示当前工作状态，接收并处理用户指令。
根据以上描述，该系统具有“系统配置”、“开机”、“关机”、“门窗监测”、“烟雾监测”和“复位”等场景。
其中，门窗监测场景的具体描述如下：
场景名称：门窗监测。
参与执行者实例：警报器、报警电话、显示器和门窗监视器。
前置条件：系统已开机。
事件流：
（1）门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。
（2）软件系统启动警报器并拨报警电话号码。
（3）报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质（门窗异动）。
（4）系统在控制面板的显示器上显示报警时间及当前状态（报警：门窗异动）。
后置条件：系统处于“报警”状态。
UML需求分析过程中根据场景作用的不同，可以将其划分为以下类型：
（1）实际场景。
对实际的业务处理流程或其优化流程的描述。
实际场景是用户需求的重要组成部分。
（2）设想场景。
分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。
这种场景可视为一种纸面原型，主要用于帮助分析人员挖掘潜在的用户需求。
（3）评价场景。
以确认需求或提出改进建议为主要目的的业务流程描述。
评价场景可以在用例生成后用例进行实例化而形成，以便用户对用例进行评价或改进。
（4）培训场景。
面向开发人员及用户解释系统的功能和外部行为的业务流程描述。
对以下问题的回答有助于分析人员进行UML需求分析获取场景：
（1）目标软件系统有哪些执行者？
（2）执行者希望系统执行哪些任务？
（3）执行者希望获得哪些信息？这些信息由谁生成？由谁修改？
（4）执行者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？
（5）系统将通告执行者哪些事件？
总之，确定执行者和场景的关键在于理解业务领域和初步需求描述文档。
场景将促成开发人员和用户对业务处理流程和目标软件系统的功能范围的共同理解。
在场景确定之后，通过对场景的汇总、分类归并和抽象即可形成用例。
本节关于UML需求分析相关内容介绍到这里。