UML用例图.ppt
UML用例和用例图
h
18
主要内容
基本概念:Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流: • 1、系统显示ID和密码窗口; • 2、顾客键入ID和密码,然后按OK键; • 3、系统验证顾客ID和密码,并显示个人信息窗口; • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码,然
后按OK键; • 5、系统验证用户是否为老顾客; • 6、系统显示可以卖的商品列表; • 7、顾客在准备购买的商品图片上单击,并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则:尽可能写的“充分”,而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮; • 8、系统通过库存系统验证要购买的商品是否有足够库存; • …….(后续描述省略)
问题:对用户界面的描述过于详细,对于需求文档来说, 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case:Buy Something • 参与者:Customer • 主事件流: • 1、顾客使用ID和密码进入系统; • 2、系统验证顾客身份; • 3、顾客提供姓名、地址、电话号码; • 4、系统验证顾客是否为老顾客; • 5、顾客选择要购买的商品和数量; • 6、系统通过库存系统验证要购买的商品是否有足
UML中文课件-用例图类图对象图包图
扩展用例不一定每次都被执行和调用。 扩展用例
-12-
用例间的关系3-泛化关系( generalization)
一个用例和其几种情形的用例间构成泛化; 往往将父用例用抽象用例(abstract)表示(即,父用例
-54-
3 客房预订分析
客房预订涉及到“学生”,“订单”,“宾馆”和“客房” 几个类
假设一个订单可以预订到多个客房。
-55-
4 画出完整类图
-56-
本章目录
2.1 UML结构 2.2 物件 2.3 关系 2.4 公共机制 2.5 构架
2.6 UML图概述 2.7 用例图 2.8 类图 2.9 对象图和包图 2.10 顺序图和通信图 2.11 状态图和活动图 2.12 组件图和部署图
而在OrderItem中有一个stateChange ()方法和 deliverState,不难猜出它就是用于改变其“是否交给 收货人”标志位的。
-29-
先调用Order的dispatch ()方法,它将根据其包含的 OrderItem中产品信息,来按供应商户分拆成若干个 DeliverOrder。商户登录系统后就可以获取其 DeliverOrder,并在执行完成后再调用close ()方法。 此时,就将调用OrderItem的stateChange()方法来改 变其状态。同时再调用Order的close()方法,判断该 Order的所有的OrderItem是否都已经送到了,如果是 就将其真正close()掉。
-37-
-38-
2.8.4 类图的构建步骤
类图的构建步骤 一个关于图书馆图书借阅管理的类图 一个实现旅游宾馆预订的类图
UML用例图-商家
二、角色:商家图表1子系统:我是商家2.1用例名:店铺设置2.1.1用例名:店铺信息设置行为者:商家前置条件:商家进入店铺设置项的店铺信息设置系统界面描述:(1)商家进入系统界面后,点击“店铺信息设置”按钮,页面将会出现系统中所存在的店铺信息设置的基本信息,商家可以选择“新增”按钮,查看店铺填写的信息并进行添加。
(2)若未完成店铺信息添加,可以选择“保存”按钮,下次可接着填写。
(3)对于信息状态为“未提交”的信息,商家可以选择“修改”按钮对暂存的信息进行修改,商家也可选择“删除”按钮,删除暂存的信息。
(4)若完成填写并通过系统校验,商家可以点击“提交”按钮,将店铺信息提交并完成填报。
说明:若对店铺信息的增删改未通过系统检验,无法提交后置条件:商家可完善店铺信息设置并能获取2.1.2用例名:版式设置行为者:商家前置条件:商家进入店铺设置项的版式设置系统界面描述:(1)商家进入系统界面后,点击“版式设置”按钮,页面将会出现系统中所存在的版式设置的基本信息,商家可以选择“更换”按钮,对店铺的模板和主题进行替换。
(2)若商家未进行“保存”设置,无法更改版式和标题(3)若商家点击“保存”按钮,店铺的模板和主题就会更新说明:未进行系统检验的不能替换版式的更新后置条件:商家可修改店铺的版式进行美化,也可以更新店铺的主题2.2用例名:交易管理2.2.1用例名:订单查看行为者:商家前置条件:商家进入交易管理项的订单查看系统界面描述:(1)商家进入系统界面后,点击“订单查看”按钮,页面将会出现系统中所存在的订单。
(2)商家可以点击“买家订单”按钮查看买家付款的订单;(3)商家可点击“售货订单”按钮,查看“发货的订单”和“已发货的订单”;(4)商家点击“交易订单”按钮,查看“已成功的订单”,“未成功的订单”和“退款中的订单”。
(5)商家可以点击“评价”按钮,对发货进行交易评价。
说明:生成的订单若不能打印成信息不能查看后置条件:商家可获得收获的订单对买家要求进行修改2.2.1.1用例名:交易评价行为者:商家—会员前置条件:商家进入交易评价界面描述:(1)商家点击“会员的交易评价或追加评价”按钮,可看到商品的评价信息(2)商家点击“回复交易评价或追加评价”按钮,可对会员进的评价行评价说明:交易评价或追加评价必须建立在商家—会员商品交易成功的基础上后置条件:商家可对评价的商品适当的添加受益的产品2.2.2用例名:发货管理2.2.2.1用例名:物流定制行为者:商家前置条件:商家进行交易管理项转向发货管理中的物流定制界面描述:(1)商家进入系统界面后,点击“物理定制”按钮,页面将会出现系统中所能浏览的库存物品,可点击“查看”按钮,查看客户的物流服务。
用例图
2001年2.0版 2001年2.0版 稳定流行版本
文字上的修改 没有显著的技 术变化
<documents> UML 0.9 <documents> Unified Method 0.8
1997年国际标准 1997年国际标准
1995年提出 1995年提出UML 年提出UML
UML组成元素UML组成元素-视图 (view) view)
函数
父类
用例
↓
调用
↑
继承
↓
条件触发
↓
子函数
↑
子类
↓
扩展用例
包含关系
泛化关系
扩展关系
实验任务1:在visio2003环境中画出
指导书中的用例图;
实验任务2:在visio2003环境中画某
个实际应用系统的用例图;案例1
案例2 案例2 项目与资源管理系统
系统的主要需求:包括项目管理, 系统的主要需求:包括项目管理,资源管理和系 统管理三大功能。 统管理三大功能。 1. 项目管理包括项目的增加、删除、更新。 项目管理包括项目的增加、删除、更新。 2. 资源管理包括资源和技能的添加、删除和更新。 资源管理包括资源和技能的添加、删除和更新。 3. 系统管理包括系统启动和关闭 , 数据的存 储 系统管理包括系统启动和关闭, 数据的存储 (分为添加技能和查找技能 和备份功能 ( 分为备 分为添加技能和查找技能)和备份功能 分为添加技能和查找技能 和备份功能( 份资源数据及备份项目数据) 份资源数据及备份项目数据)等,数据的存储和 备份均需要启动和关闭系统。 备份均需要启动和关闭系统。 技能可指人力资源。 注:技能可指人力资源。
用例图组成
用例图组成:使用者 用例+关系。 用例图组成:使用者+用例+关系。 组成
UML 用例图、关系图、活动图
例如,一个银行系统中,有
一个“验证用户”用例,用 身份认证
于验证用户的合法性,它有
两 个 特 殊 的 子 用 例 , 一 个 是 密码认证
指纹认证
“检查密码”,另一个是
“检查指纹”,它们都有父
用例“验证用户”的行为,
并且可以出现在父用例出现
的任何地方,还可以添加自
己的行为。
用例图实例
• 以前面图书信息管理系统为例,画出用例 图。先找出参与系统地的角色:
• 扩展关系——允许一个用例扩展另一个用
例的功能。例如,在图书信息管理系统中,
读者还书时,系统检查所还图书是否有预
订记录,如果有则执行“通知”用例。在
UML中扩展关系表示为箭头和《extend》形
式。
《extend》
还书
通知
管理员
读者
注意
• 使用关系和扩展关系之间的区别,A使用B 本质上是A一定使用B,同时增加自己的专 属行为;而A被用例B扩展是说明A是一个一 般用例,B是一个特殊用例,A在某些条件 下可能使用B。
(2)取消预订——本用例提供取消预订图书的功能。
(3)还书——完成还书任务,在还书是要检查所还的书是否超 期、是否有其他读者预订,有的话要通知预订者。
(4)借书——提供借阅书功能 。
• 分析这个用例图,发现“还书”用例应该 被扩展,因为在还书时检查所还图书是否 有预订记录,若有,则应该通知预订者前 来借书。
• 一个用例内部的具体处理细节是由其他图形工具描述 的,用例图只是反映系统的总体功能,以及与这些功 能的相关的角色。有些人可能在画“借书”用例时, 情不自禁地就考虑了“输入读者号和书号”,“检查 图书是否在库?”,“图书数量减1”,“添加读者借 书记录”等等,一旦考虑了这些细节,就会发现用例 图画不下去了。因此,读者注意用例图中不要考虑处 理细节。
uml 基础教程 第三章-用例图
• 用例具有3个明显的特征: (1)用例表明的是一个类,而不是某个具体的实例 (2)用例必须由某一个参与者触发激活后才能执行,即
每个用例至少应该涉及一个参与者 (3)用例是一个完整的描述
椭圆来表示用例
“回顾”饮料销售机
• 在前面的分析中,我们获得了系统中有3个用例,分别是 “Buy soda(买饮料)”、“Restock(供货)”、“Collect( 收款)”。
• 假设正在对一台饮料机建模,这台饮料销售机允许顾 客选择买一罐饮料或是买一杯饮料。在这种情况下,“Buy Soda”就是一个父用例,“Buy a can of soda”和“Buy a cup of Soda”就是子用例。用例之间的泛化关系建模与类之间 泛化关系建模方法相同,用一条带空心三角形箭头的实线 从子用例指向父用例。
• 要用在用例图上显示某个用例:
➢使用人形符号绘制一个参与者;
➢绘制一个椭圆表示用例,将用例的名称放在椭 圆的中心或椭圆下面的中间位置;
➢使用带箭头或不带箭头的线段来描述参与者和 用例之间的关系。
举例:饮料销售机
• 假设你现在正着手设计一台饮料销售机。为了获得用户 的观点,你会见了许多可能的用户以了解这些用户将如何 与这台机器交互。
“取钱”用例
• 还有一个“取钱”用例,同样也是因为一段时间的流逝, 收款人发起了这个用例。它的前期工作步骤与”供货“一 样,也是打开销售机前端架子。收款人从机器中取出钱, 然后按照”供货“步骤,放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝,后置条件 是收款人收到了钱。
3.1.1 参与者
• 理想情况下,顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示,销售机应给顾客两种选择:让顾客选择另一种饮 料并且给顾客提供这种饮料(如果这种饮料还有存货的话) 或者让顾客选择退钱。
需求分析——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用例图关系图活动图
取钱
《include》
《include》
查询
验证用户密码
更改密码
《include》
用例之间的关系(续)
? 扩展关系——允许一个用例扩展另一个 用例的功能。例如,在图书信息管理系 统中,读者还书时,系统检查所还图书 是否有预订记录,如果有则执行“通知” 用例。在UML中扩展关系表示为箭头和 《extend还》书 形式《e。xtend 》 通知
用例图练习
? 下面是关于一个公司的人事信息管理系统的需求的 简单描述, 建立其相应的用例模型 : 该人事管理系统 的用户是公司的人事管理干部 . 该系统具有人事档 案库, 保存员工的人事信息 , 包括姓名, 性别, 出生年 月, 健康状况, 文化程度, 学位, 职称, 岗位, 聘任时 间, 任期, 工资, 津贴, 奖罚记录, 业绩, 论著和家庭 情况等, 系统提供的基本服务有 人事信息的管理 , 包 括人事规定的调动与聘任 , 职称评定, 奖罚等, 并且 可以按照限查询人事信息 , 生成与输出统计报表 等. 该人事系统每月向公司的财务系统提供员工的工资 , 津贴等数据 .
外部系统和时间。
? 系统使用者是最重要的角色,例如,在图书信息管理系 统中的系统使用者有读者和图书馆的工作人员,包括采 购、编目和办公室的工作人员。
? 其他外部应用系统。 ? 硬件设备,不同的硬件设备具有不同的特性和不同的处
理方式。 ? 时间作为角色 ,经过一定的时间触发系统中的某个事件。
关系——角色与用例之间的关
管理员
读者
注意
? ?使用关系和扩展关系之间的区别, A使 用B本质上是 A一定使用 B,同时增加自己 的专属行为;而 A被用例B扩展是说明 A是 一个一般用例, B是一个特殊用例, A在 某些条件下可能使用B。
企业综合信息管理系统UML需求建模(用例图+活动图)
2020/11/27
管理课件
5
(4)系统运行的软件、硬件环境 1)系统运行的软件环境 2)系统运行的硬件环境
3.6.2 确定系统范围和系统边界
1.进销存管理子系统的业务范围 2.进销存管理子系统的系统边界
3.6.3 确定执行者
“进销存管理子系统”有5个人执行者和2个系统执行 者,即“采购人员”、“销售人员”、“仓库管理 员”、“客户”、“公司经理”、“生产调度管理子 系统”和“财务管理子系统”。
管理课件
2
(2)采购管理
1)制定原材料(零部件)采购计划 2)与客户签订采购合同 3)检查合同履约率 4)库存管理部门对原材料进行入库验收、存储 5)财务管理部门支付货款
(3)库存管理
1)产品入库管理 2)原材料(零部件)入库管理 3)原材料(零部件)出库管理 4)产品出库管理 5)库存管理 6)采购管理部门组织采购 7)生产调度管理部门安排生产 8)财务管理部门对库存物资进行核算
1.“增加销售合同”用例
用例编号:04010101(共有4层用例图结构,每层用2位数字表 示, 采用8位编号。)
用例名: 增加销售合同 执行者: 人执行者:合同管理员、客户、公司经理。系统执
行者:“财务管理子系统”和Байду номын сангаас生产调度管理子系
统”。
目 的: 合同管理员将与客户签订的销售合同的详细内容录 入管理系统,用于对销售合同进行统计、查询、检查 是否履约等,监控正在履约的合同。
类 型: 端点、主要的、基本的 级 别: 一级
2020/11/27
管理课件
14
过程描述:
(1)合同管理员输入标识码(ID),系统识别标识码的有效
性;
(2)初始化一个新销售合同,设置各种处室标志;
UML 用例图、关系图、活动图
网上 查询 读者 扩展 预定 扩展
查询 图书馆工作 人员 取消 预定
还书
通知
借书
武当山旅游门户网站( ) 分类信息
注意
在画用例图时要特别注意:用例图是系统分析、 设计和实现的一个最基础的图形,在初期是不一 定要考虑太多的处理细节。 一个用例内部的具体处理细节是由其他图形工具 描述的,用例图只是反映系统的总体功能,以及 与这些功能的相关的角色。有些人可能在画“借 书”用例时,情不自禁地就考虑了“输入读者号 和书号”,“检查图书是否在库?”,“图书数 量减1”,“添加读者借书记录”等等,一旦考虑了 这些细节,就会发现用例图画不下去了。因此, 读者注意用例图中不要考虑处理细节。
武当山旅游门户网站( ) 分类信息
注意:
活动图描述多个角色之间的处理非常有 效,一张活动图只能有一个开始状态, 但可以有多个结束状态。 一个活动可以与多个实体对象相关,这 里的相关指的是一种访问操作。在上面 “借书”活动图中,“检查读者有效” 的活动,要访问“读者”对象和“借还 书记录”对象,检查“读者编号”的有 效性和读者借书数量。
状态图中的转移可以由三部分组成: 事件[条件]/动作
武当山旅游门户网站( ) 分类信息
角色
角色是指与系统交互的人或物。 角色可以有四种类型:系统的使用者、硬件设备、 外部系统和时间。
系统使用者是最重要的角色,例如,在图书信息管理系 统中的系统使用者有读者和图书馆的工作人员,包括采 购、编目和办公室的工作人员。 其他外部应用系统。 硬件设备,不同的硬件设备具有不同的特性和不同的处 理方式。 时间作为角色,经过一定的时间触发系统中的某个事件。
认识活动图认识活动图图书馆图书信息管理系统借书活动图图书馆图书信息管理系统借书活动图借书申请检查读者有效性读者信息借书记录读者无效图书无效检查图书有效性检查预订预订记录清除预订记录图书信息借书记录修改图书信息创建借书记录图书信息读者无效借书超期图书无效有预订读者流通组工作人员读者图书编号活动图中的主要图形元素活动图中的主要图形元素泳道
第06章UML用例图ppt课件
基于这些信息的高层用例图。这些用例就构成了该 局域网系统的功能需求。
6.4.4 进一步深化
详细论述这些高层用例中的一个,并建立一个用 例模型。咨询公司中最重要的一项活动是书写提案。 因此检验一下“Create a proposal〞这个用例。
与某个顾问面谈,他就能通知他这个用例中的许 多步骤。首先,用例的发起者是一个顾问。顾问要登 录到局域网,并作为一个有成效户被验证。然后他运 用办公软件套件(包括文字处置软件包、电子表格软 件包以及绘图软件包等)来书写提案。在这个过程中, 顾问能够要重用一部分以前的提案。咨询公司的
上一章“引见用例〞中还给出了用例“Buy soda 〞的一些可选的场景。在详细描画中,可以分别列出 这些场景,或者把它们作为用例根本场景的扩展来思 索。详细怎样做需求根据客户、用户和他对问题的了 解。
要阐明一个场景中的步骤,还可以运用UML活动 图对场景进展描画(这部分内容将在 “活动图〞一章 中讨论)。
6.2.1 包含
上一章中的“Restock〞和“Collect〞用例都从 开锁和拉开销售机的门开场,都以关门和上锁终了。 第1步建立了“Expose the inside(翻开销售机)〞用例, 并且第2步创建了“Unexpose the inside (封锁销售机) 〞用例。“Restock〞和“Collect〞两者都包含了这 两个新用例。
6.1 用例模型的表示法
用例是由参与者发起的,参与者(也许是发起 者,但不是必需的)可以从用例的执行中获得有价 值的事物。用例模型的图形表示法很直观。用例 用一个椭圆形表示,直立人形图标表示参与者。 用例的发起参与者在用例图的左侧,接纳参与者
在用例图的右侧。参与者的名字放在参与者图标的下方, 用例的名字可以放在椭圆形里面也可以放在椭圆形下面。 关联线衔接参与者和用例,并且表示参与者与用例之间有 通讯关系。关联线是实线,和类之间的关联线类似。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
系统
系统是用例图的一个组成部分,它是对真正软件 系统活动范围的一个抽象。系统的边界用来说明 构建用例的应用范围。系统边界框定义系统的边 界或限制,所以,系统的所有功能或过程会被限 制在系统内,即此边界将系统的所有过程/功能与 外界环境分隔。
4
系统
5
案例分析 汽车租赁---任务陈述
商店将汽车的跟踪自动化---使用条码、柜台终端和激光阅读器,这有许多 优点:租赁助手的效率提高了20%,汽车很少失踪,客户群变大。
Use Case图是后续的分析工作的依据,也是系统测试的 依据。Rational统一过程主张采用Use Case驱动的软 件开发方式。
1
二、Use Case图—示例
ATM
存钱
取钱
用例图是由
转帐
参与者、系 统、用例三
客户
者构成的。
查询
2
主要内容
1. 系统 2. 参与者 3. Use Case 4. Use Case 的联系 5. Use Case 图建立
Rational统一过程主张采用Use Case驱动的 软件开发方式。
13
开发典型用例
14
“剧本(场景)”描述
参与者与系统的对话过程可用一系列步骤(也称 “剧本”)来描述, “剧本”的集合就是Use Case,系统全部的Use Case构成了对于系统 外部可见行为的描述。
15
2.2 Use Case示例
可以是带一个构造型《Actor》的对象类图标表 示,也可以用简易的人形图标表示。
《Actor》 参与者名
业务 参与者名
系统 参与者名
8
1.3 参与者的确定
凡是与系统进行信息交互(包括数据信息与控制信息交换)的外部事 物可以确认为参与者。
系统的外部事物包括:人员、设备、外部系统。 人员:直接使用系统的人员,可确认。 设备:与系统相连的设备,直接向系统提供外界信息或在系统控制 下运行,可确认。 外部系统:与系统相连并与系统交互的外部系统,可确认。
管理层认为,Internet会提供进一步提高效率、降低成本的机会---例如, 现在不是打印可用汽车的目录,而是让每个Internet冲浪人员在线浏览这 些目录。对于有特权的客户,可以提供额外的服务,例如,通过鼠标点击预 约。这个领域的目标是每个商店的运营成本降低15%。
在两年内,使用电子商务的所有功能,通过Web浏览器提供所有服务,在 客户家中完成汽车的交付和收回,以达到虚拟租赁公司的最终目标,将未来 的预约业务的运营成本降到最低。
上述任务陈述包含许多信息:公司自动化历史;在线目录和预约、有或无特 权的客户、节约成本的目标、公司的最终目标。
调查分析至少有两个很好的起点: 公司的商店目前提供什么样的服务? 哪些服务适合在Internet上提供?
6
助手:商店一个员工,帮助顾客租用其汽车或预
1.1 参与者
约汽车型号。 顾客:为获得一个标准服务而付费的人。 会员:身份和信用状况已得到验证的顾客,可以
对所有可能的参与者要进行筛选和调整,排除重复定义、错误定义及 不合理定义。
9
谁是参与者?
参与者与系统直接相连——间接相连的对象不是 参与者,不应该被包含而作为系统模型的一部分。 例如维修技师的派遣人员就不应是自动售货机的 参与者
谁是参与者?旅行者、旅行社还是是旅行社的网 上订票系统?
10
谁是参与者?
统与本系统相互作用,交换信息。外部系统可以是软件
系统,也可以是一个硬设备。
参与者以它的外部视图为特征,不关心它的内部结构。 在务处 等理属参性与。者时,重要的是角色,并不关会助心员手、、人非经或会理人员的职
业务参与者:业务需求中出现的参与者。 系统参与者:系统需求中出现的参与者。
系统管理员
7
1.2 参与者—表示方式
二、Use Case图
Use Case是指系统的外部事物(参与者)与系统的交互, 它表达了系统的功能,既系统所提供的服务。
用例开始于一个参与者,之后是业务或系统,最后返回参 与者。
Use Case 图是一种描述Use Case的可视化工具,用 简单的图形
访问特定服务。
参与债者务(部门A:c处t理o未r)付费:用是的用非户会作员:用身于份未业得务到验或证系的顾统客的,预一约个必须角交色押 (R部o门le)。参与者有自己的目金标,租,用通汽车过必与须提业供务一份或驾系照副统本的。 交互法 车达律 的到部 事门 故目: 部的处 门理。涉及租用汽
参与者可以是人,也可以是部门或外部系统,该外部系
上述Use Case 包含两个剧本(场景),“购买商品”和“信用卡
检查失败”。
16
2.3 Use Case图标
Use Case名
购买商品
17
2.4 Use Case类型
业务Use Case:指领域提供的业务(Business)功能与用户(参 与者)的交互,表现问题领域中各实体之间的联系和业务往来活动。 业务Use Case用于建立问题领域的业务Use Case模型。
系统Use Case:指参与者与系统的交互,表现系统的功能需求和动 态行为。系统Use Case用于建立系统的Use Case模型。
例子:顾客在一个网上商店购买商品的过程的Use Case可用文字描 述如下:
购买商品: ( 1 )顾客浏览查询产品分类目录,找出所需要的产品。 ( 2 )顾客准备结算。 ( 3 )顾客填写购货信息(产品信息、数量、送货地址、送货日期)。 ( 4 )系统显示价格和应付款项。 ( 5 )顾客填写信用卡信息。 ( 6 )系统检查信用卡有效性,确认交易成功。 ( 7 )系统确认发货时间,发出发货通知。 ( 8 )系统发确认成交的电子邮件给顾客。 异动处理:信用卡有效性检查失败。(允许重做(5)-(8))
例如唐纳德以顾客身份操作时,他可以动用顾客
对象的方法;以经理身份操作时,他可以动用经
理对象的方法
11
谁是参与者?
一个参与者也可以由多个人来担任,行为(角色)
都是一样的。
12
2.1 Use Case概念
Use Case是对一个参与者使用系统的一项功能 时所进行的交互过程的一个文字描述序列。
Use Case是对系统的用户需求(主要是功能需 求)的描述, Use Case表达了系统的功能和所 提供的服务。