(完整版)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完整例子
UML用例图在需求分析中的应用指南
UML用例图在需求分析中的应用指南需求分析是软件开发过程中的重要环节，它的目标是明确系统的功能需求和用户需求，为后续的设计和开发工作提供基础。
在需求分析过程中，UML（统一建模语言）用例图是一种常用的工具，它可以帮助分析师和开发人员更好地理解系统的功能和用户行为。
本文将介绍UML用例图在需求分析中的应用指南，帮助读者更好地掌握这一工具。
1. 什么是UML用例图UML用例图是一种用于描述系统功能和用户行为的图形化工具。
它通过用例（Use Case）和参与者（Actor）之间的关系来展示系统的功能和用户与系统的交互。
用例图可以帮助分析师和开发人员更好地理解系统的需求，从而更好地设计和开发系统。
2. 用例图的基本元素用例图包含用例、参与者和关系三个基本元素。
用例表示系统的功能或者用户的行为，可以理解为一个功能模块或者一个用户操作。
参与者表示系统的用户，可以是人、其他系统或者外部设备。
关系表示用例和参与者之间的关系，常见的关系有关联关系、包含关系和扩展关系等。
3. 用例图的绘制步骤绘制用例图的步骤如下：（1）确定系统的功能和用户行为，将其抽象为用例。
（2）确定系统的参与者，包括人、其他系统和外部设备。
（3）绘制用例图的框架，将用例和参与者放置在合适的位置。
（4）使用关系连接用例和参与者，表示它们之间的关系。
（5）完善用例图，添加必要的细节和注释。
4. 用例图的应用场景用例图在需求分析中有广泛的应用场景，下面列举几个常见的应用场景：（1）明确系统的功能需求：用例图可以帮助分析师和开发人员明确系统的功能需求，从而更好地设计和开发系统。
（2）识别用户需求：用例图可以帮助分析师和开发人员更好地理解用户的需求，从而更好地满足用户的期望。
（3）辅助系统设计：用例图可以作为系统设计的基础，帮助设计人员更好地理解系统的功能和用户行为，从而更好地设计系统的架构和模块。
（4）沟通和交流：用例图可以作为沟通和交流的工具，帮助团队成员之间更好地理解系统需求和设计思路。
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建模工具StarUML(第3部分)——创建需求分析中的UML用例图的创建示例
1.1跟我学UML建模工具StarUML（第3部分）——创建需求分析中的UML用例图的创建示例1.1.1UML中的用例及用例图1、用例模型的基本组成部件为参与者、用例和系统删除成员2、用例模型的基本组成部件中的参与者（1）参与者（Actor）参与者表示系统用户能扮演的角色(role)，这些参与者可能有三大类：系统用户、与所建系统交互的其他系统、时间。
1)软件系统用户：使用本软件系统的人；2)其他系统：可能是其他的计算机或者一些硬件或者甚至是其它软件系统；3)时间：时间作为参与者时，经过一定时间触发系统的某个事件。
例如，ATM机可能每天午夜运行一些协调处理。
由于事件不在本系统的控制之内，因此也是本软件系统的参与者。
（2）某个“网上书店”和“在线网校”项目中的各个参与者示例说明在“网上书店”项目中的参与者主要有用户和系统统管理员，而管理员使用控制面板对系统和用户管理，也就是进行系统设置，管理用户、用户组、权限，查看系统访问日志及用户使用情况等的统计信息。
在“在线网校”项目中的学校课程管理子系统中则有三个参与者在不同的应用中互动。
这三个参与者分别是学生，讲师以及系统管理者。
而学生参与者使用了系统中浏览课程以及注册课程的功能，而系统管理者参与者则是负责管理注册的学员，编排课程以及确认课程。
讲师则是主导课程的参与者，他可以浏览，开办以及移除课程（当然，必须是这个讲师自己的课程）。
（3）在UML中参与者的图示（4）参与者之间的关系——泛化（特化或者继承）关系由于参与者是类，所以它拥有与类相同的继承关系描述（请见后面的类的关系说明），其UML的图示是用带空心三角形（箭头）的直线表示。
在特殊的参与者中还需要给出其特殊的成员定义。
（5）所要注意的问题1)参与者主要是指角色而非具体的个人2)用户与参与者之间的关系一个用户可以抽象为多个参与者，如：张三即可以是网上书店的读者，也可以是管理员；一个参与者可以包含多个用户，如：网上书店的读者可以是张三和李四。
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方法分析图书管理系统( 需求)
3.找谁
二、 UML静态模型—类图回顾 1.类图概念 类图描述了系统中的类及其相互之间 的各种关系，其本质反映了系统中包 含的各种对象的类型以及对象间的各 种静态关系（关联，子类型）。
一、UML静态模型—类图回顾
类图图符表示：
类名
WashingMachine
简单名 路径名 公有（+） 私有（-） 受保护（#）
1.“借阅者查找图书”用例描述
基本工作流程如下： ① 借阅者希望通过系统查询图书的信息。 ② 借阅者通过自助系统的用户界面SearchBookWindow录入图书的 ISBN/ISSN号，请求查找图书信息。 ③ 用户界面SearchBookWindow根据图书的ISBN/ISSN号将Book类实例 化，并请求图书信息。 ④ Book类实例化对象根据图书的ISBN/ISSN号加载图书信息，并提供 给用户界面SearchBookWindow。 ⑤ 用户界面SearchBookWindow向读者提示该图书信息。
第二步：分析需求
OOA分析过程
分析 用户 需求
系统分析员应 该深入地理解 用户需求，抽 象出目标系统 的本质属性， 并用模型准确 表示来 ；另 外要向领域专 家学习。
识别 类与 对象
确定问 题域中 的类和 对象
确定对 象的内 部特征
确定对 象的属 性的操 作
识别对 象之间 的关系
分类关系(一般 /特殊)、组成 关系(整体/部 分)，还有反映 对象属性之间 联系的实例连 接、反映对象 行为之间依赖 关系的消息等
借阅者进行的活动
用例
查找图书 登陆系统 查询个人信息 预定图书 借阅图书 归还书籍
可以通过图书名称或ISBN/ISSN号查找图书的详 细信息 能够根据图书证编号和相关密码登陆自助机器， 查询图书信息、个人信息和进行图书预定。 每个借阅者都可以通过自主机器在登陆后查询自 己的信息，但是不允许在未授权的情况下查询其 他人的信息。 登陆自助机器后，借阅者可与预定相关书籍。 可以通过图书管理员借阅相关书籍。 通过图书管理员归还书籍，如果没按时归还或书 籍损坏，需要缴纳罚金。
火龙果软件-UML详解及实例分析
UML的特点
火龙果整理
(1) 统一标准 UML统一了Booch、OMT和OOSE等方法中的基本概念， 已成为OMG的正式标准，提供了标准的面向对象的模型元素 的定义和表示。 (2) 面向对象 UML还吸取了面向对象技术领域中其他流派的长处。 UML符号表示考虑了各种方法的图形表示,删掉了大量易引起 混乱的、多余的和极少使用的符号,也添加了一些新符号。 (3) 可视化、表示能力强 系统的逻辑模型或实现模型都能用 UML模型清晰的表示， 可用于复杂软件系统的建模。 (4) 独立于过程 UML是系统建模语言，独立于开发过程。 (5) 易掌握、易用 由于UML的概念明确，建模表示法简洁明了，图形结构 清晰，易于掌握使用。
用于表示其他信息，比如注释，模型元素的语 义等。另外，为了适应用户的需求，它还提供了扩 展 机 制 (Extensibility mechanisms) ， 包 括 构 造 型 (Stereotype) 、 标 记 值 (Tagged value) 和 约 束 (Constraint).使用UML语言能够适应一个特殊的方 法（或过程），或扩充至一个组织或用户。
通用模型元素
火龙果整理
模型元素是 UML 构造系统的各种元素，是 UML 构建 模型的基本单位。模型元素代表面向对象中的类，对象， 关系和消息等概念，是构成图的最基本的常用的概念。分 为以下两类： 1、基元素 是已由 UML 定义的模型元素。如：类、结点、构件、 注释、关联、依赖和泛化等。 2、构造型元素 在基元素的基础上构造的新的模型元素，是由基元素 增加了新的定义而构成的，如扩展基元素的语义（不能扩 展语法结构） ,也允许用户自定义。构造型用括在双尖括 号《》中的字符串表示。 目前 UML 提供了 40 多个预定义的构造型元素。如使 用《Use》、扩展《 Extend 》。
- 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需求分析相关内容介绍到这里。