(完整版)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,图表,Rose)
5.6 构件图.......................................................................................................... 17 5.7 部署图.......................................................................................................... 17
5.2 时序图.......................................................................................................... 10 5.2.1 顾客订购时序图.............................................................................. 10 5.2.2 顾客删除订单时序图...................................................................... 11 5.2.3 管理员处理订单时序图.................................................................. 12
2.系统总体的功能需求 .......................3
2.1 用户接口模块................................................................................................ 3 2.2 管理员接口模块............................................................................................ 3 2.3 数据服务模块................................................................................................ 3
UML用例图实例解析
UML⽤例图实例解析⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⽤例图所包含的元素如下： 1. 参与者(Actor) 表⽰与您的应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case) ⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem) ⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
4. 关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
【箭头指向】：指向分解出来的功能⽤例 d. 扩展(Extend) 扩展关系是指⽤例功能的延伸，相当于为基础⽤例提供⼀个附加功能。
【箭头指向】：指向基础⽤例 e. 依赖(Dependency) 以上4种关系，是UML定义的标准关系。
但VS2010的⽤例模型图中，添加了依赖关系，⽤带箭头的虚线表⽰，表⽰源⽤例依赖于⽬标⽤例。
【箭头指向】：指向被依赖项 5. 项⽬(Artifact) ⽤例图虽然是⽤来帮助⼈们形象地理解功能需求，但却没多少⼈能够通看懂它。
很多时候跟⽤户交流甚⾄⽤Excel都⽐⽤例图强，VS2010中引⼊了“项⽬”这样⼀个元素，以便让开发⼈员能够在⽤例图中链接⼀个普通⽂档。
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章需求分析............................................................................. 错误!未定义书签。
1.1 客户子系统的需求分析 (4)1.2 银行管理员系统的需求分析 (4)第2章系统用例模型 (8)2.1 管理员的用例模型 (8)2.2 客户的用例模型 (12)第3章系统静态模型 (16)3.1 系统中的类 (16)3.2 系统中类与类的关系 (17)第4章系统动态模型 (19)4.1银行管理员创建账户 (19)4.2银行管理员修改账户 (20)4.3银行管理员删除账户 (22)4.4 客户取款 (24)4.5 客户存款 (25)4.5 客户转账 (25)4.6 银行管理系统中的状态图................................................................ 错误!未定义书签。
4.7 银行管理系统中的活动图................................................................ 错误!未定义书签。
第5章系统部署模型 (33)5.1 银行管理系统的构件图 (33)5.2客户操作构件图 (34)5.3 银行管理员构件图 (34)5.5 银行管理系统部署图 (33)第6章总结与展望 (36)6.1 总结 (36)6.2 展望 (36)参考文献............................................................................................ 错误!未定义书签。
随着社会的不断发展，计算机越来越普及。
我们正处在一个信息时代，计算机无处不在，它进入各行各业，改变着人们的生活。
UML完整例子
• “计算机类”、“非计算机类”是该系统中图书
的两大分类，因此应该对其建模，并改名为“计 算机类书籍”和“非计算机类书籍”，以减少歧
义；、
火龙果 整理
筛选备选类
• “外借情况”则是用来表示一次借阅行为， 应该成为一个候选类，多个外借情况将组 成“外借情况列表”，而外借情况中一个 很重要的角色是“朋友”—借阅主体。 • 虽然到本系统中并不需要建立“朋友”的 资料库，但考虑到可能会需要列出某个朋 友的借阅情况，因此还是将其列为候选类。 为了能够更好地表述，将“外借情况”改 名为“借阅记录”，而将“外借情况列表” 改名为“借阅记录列表”；
火龙果 整理
需求描述
• 在使用该系统录入新书籍时系统会自动按 规则生成书号，可以修改信息，但一经创 建就不允许删除。 • 该系统还应该能够对书籍的外借情况进行 记录，可对外借情况列表打印。 • 另外，还希望能够对书籍的购买金额、册 数按特定时间周期进行统计
火龙果 整理
火龙果 整理
4.绘制交互图
• 首先根据自己的喜好和实际的表现需要来 • 不过由于它们在语义上是等价的，因此可
以绘制出一种，再通过建模工具来自动转 换成另一种图 。 选择顺序图或通信图。
火龙果 整理
（1）准备工作
• 分析模型中的交互图彻重于分析类的职责分配
•
一本书只有一册，因此只能够被借一次，因此对于一本 Book而言只能有一个RecordId与其对应
火龙果 整理
限 定 • 分 析
火龙果 整理
3.绘制用例图
• 用例图的绘制流程
（1）记录需求—特性表
编号 说明
火龙果 整理
火龙果 整理
UML完整例子
- 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需求分析相关内容介绍到这里。