用例和用例图分析
02-用例和用例图

3.4.4 几种关系的比较
关系类型
说明
表示符号
关联
actor与use case之间
泛化
actor之间或use case之间
包含
use case之间
扩展
use case之间
用例图
用例图(use case diagram)是显示一组用例、角色以及它 们之间的关系的图.
在UML中, 一个用例模型若干个用例图描述.
角色
由于Actor实际上是一个特殊类, 因此它们之间可以 存在一定的关系,如:
脚本/场景
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况.
其它译名: 情景、情节、剧本.
每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
实例分析:语音邮箱系统----用例脚本
用例3: 登录系统 1. 邮箱用户完成邮箱号输入操作. 2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 3. 语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语.
实例分析:语音邮箱系统----用例脚本
用例4: 接收信息 1. 邮箱用户完成登录操作. 2. 邮箱用户选择 “接收信息”菜单选项. 3. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 4. 邮箱用户选择“收听当前信息”菜单选项. 5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 6. 语音邮件系统播放信息菜单. 7. 用户选择”删除当前信息”,则信息被永久删除. 8. 继续执行第3步.
用例及用例图案例

用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例:客房预订 ●参与者:柜台工作人员 ●说明:
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例:预订变更 ●参与者:柜台工作人员 ●说明:
A2:有冲突。
⑧系统添加新课程,并提示添加成功。
⑨系统回到管理主界面,显示所有课程,用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图,解决用例之间的冲突和重复。
15
案例3:
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例? (2) 用例图在软件建模中的作用是什么? (3) 用例之间存在那几种关系? (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式? (6) 什么叫事件流,作用是什么?
实验报告1--用例和用例图

中北大学软件学院实验报告
专业:软件工程
方向:软件开发与测试
课程名称: UML
班级:
学号:
姓名:
辅导教师:井超
2017年3月制
4.用例图如下所示
1).系统参与者
系统角色
2).图书管理
图书管理用例图3).图书借阅和还书用例图
图书的借阅和归还用例4).图书管理系统的整体用例图
图书管理系统的整体用例图
5.实验结论及心得
通过本次实验,我掌握了在课堂上学习的用例图等。
加深了对书本知识的认识和记忆。
在实验中我学会了去如何操作ro se工具图。
通过ro se工具图,可以去清晰的去展示一个关系等。
使用非常方便。
13种uml简介、工具及示例

13种uml简介、工具及示例UML(Unified Modeling Language)是一种用于软件开发的标准化建模语言,它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中,使用UML可以帮助开发人员更清晰地理解系统的结构和行为,从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式,其中每种模型都有各自的符号和语法规则。
通过使用这些模型,开发人员可以将系统分解成不同的部分,然后逐步细化这些部分的设计,以便更好地组织和管理项目。
在UML中,最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力,开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外,UML还定义了一系列的建模工具,这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍:1. 用例图(Use Case Diagram)用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例,用直线连接用例和参与者,展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求,从而指导系统的设计和实现。
示例:一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等,以及参与者“顾客”和“管理员”。
2. 类图(Class Diagram)类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类,用线连接类之间的关系,包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系,从而支持系统的设计和重构。
示例:一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等,以及它们之间的关系如“选修”、“授课”等。
权限管理用例图及用例分析

其他事件流:
管理员在执行基本事件流过程中点击”取消”按钮,系统关闭表单页
异常事件流:
管理员提交表单数据格式错误,系统提示错误信息
系统将数据写入数据库时失败,提示错误信息
后置条件:
无
注释:无
管理员提交表单数据格式错误系统提示错误信息系统将数据写入数据库时失败提示错误信息后置条件
用例图
用例描述
用例编号:006
用例名称:权限管理
优先级别:HIGH
参与者:管理员 一Biblioteka 用户用例描述:权限管理
前置条件:
1.用户成功登陆系统
基本事件流:
在权限管理的页面上,输入新员工信息
点击提交按钮
员工信息被修改、删除或被导出 个人可以查看自己的信息 登录
2.设计模式常用的UML图分析(用例图、类图与时序图)

2.设计模式常⽤的UML图分析(⽤例图、类图与时序图)1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况,⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求,判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中,参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务,于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中,⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者,从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供,并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰,椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信,任何⼀⽅都可发送或接受消息。
箭头指向:指向消息接收⽅:⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系,⼦⽤例和⽗⽤例相似,但表现出更特别的⾏为;⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为,也可以重载它。
⽗⽤例通常是抽象。
箭头指向:指向⽗⽤例2-类图描述系统中的类,以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系,⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝,则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图,类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性,则每⼀个属性都必须有⼀个名字,另外还可以有其它的描述信息,如可见性、数据类型、缺省值等2. 操作:如果有操作,则每⼀个操作也都有⼀个名字,其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类,则⼈类类中应包含头类及⾝体类这两个属性,则⼈类类与头类和⾝体的关系即为组合关系。
第2章用例和用例图

成绩管理
UML用例图组成( UML用例图组成(续) 用例图组成
饮料销售机
UML用例图组成( UML用例图组成(续) 用例图组成
用例与用例的扩展关联用来表示通过对已有用例增加步 用例与用例的扩展关联用来表示通过对已有用例增加步 扩展关联用来表示 骤创建一个新的用例,即对原有的用例进行了扩展。 骤创建一个新的用例 即对原有的用例进行了扩展。扩展只能 即对原有的用例进行了扩展 发生在基用例的序列中的某个具体指定点上。这个点叫做扩 发生在基用例的序列中的某个具体指定点上。 展点.在UML图中,使用带虚线箭头表示,并在线上标有构造 展点 在UML图中,使用带虚线箭头表示, 图中 带虚线箭头表示 如下图所示: 型<<extend>> 。如下图所示:
UML用例图组成( UML用例图组成(续) 用例图组成
包含关联与扩展关联的区别: 包含关联与扩展关联的区别:
存在包含关联的两个用例,在执行基本用例时 一定会执 存在包含关联的两个用例 在执行基本用例时,一定会执 在执行基本用例时 行包含用例;存在扩展关联的两个用例,在执行基本用例时 在执行基本用例时, 行包含用例;存在扩展关联的两个用例 在执行基本用例时 可以执行,也可以不执行扩展部分 可以执行 也可以不执行扩展部分. 也可以不执行扩展部分
UML用例图的作用( UML用例图的作用(续) 用例图的作用
• 用例图的主要作用: 用例图的主要作用:
– 用来描述待开发系统的功能需求和系统使用场景 – 作为开发过程的基础,驱动各阶段的开发工作 作为开发过程的基础, – 用于验证与确认系统需求
画好用例图是由软件需求到最终实现的第一步. 画好用例图是由软件需求到最终实现的第一步.
UML用例图的建模( UML用例图的建模(续) 用例图的建模
餐馆系统用例及用例图

•记录预约(Recork booking)事件路径:1接待员输入要预约的日期2系统显示该日的预约3有一张合适的餐桌可以使用:接待员输入顾客的姓名、电话、预约的时间、用餐人数和餐桌号4系统记录并显示新预约。
可选或例外的事件路径3a 没有可用的餐桌:1 没有合适的餐桌可以使用,用例终止3b 餐桌过小1 接待员输入顾客的姓名电话预约时间,用餐人数和餐桌号2 用餐人数多于餐桌容纳的人数,系统询问是否继续预约3 如果回答“否”, 用例将不进行预约而终止4 如果回答“是”, 预约将被输入,并附有一个警告标志。
•记录到达:(Record arrival)基本事件路径1领班输入当前日期2系统显示当天的预约3领班确认一个选定的预约已经到达4系统对此进行记录并更新显示器,将顾客标记为已经到达。
可选或例外的事件路径3a 没有提前预订:1 系统中没有记录该顾客的预约,领班输入预约时间、人数和餐桌号,创建一个未预约登记;2 系统记录并显示新预约//将红字的部分,独立为一个用例,用例描述如下:●记录未预约顾客(Record walk_in)基本事件路径1 侍者领班执行“显示预约”用例2 侍者领班输入时间、用餐人数和分配给顾客的餐桌3 系统记录并显示新预约●取消预约(Cancel booking)基本事件路径1 侍者领班执行“显示预约”用例2 接待员选择要求的预约3 接待员取消该预约4 系统询问接待员确认取消5 接待员回答“是”,系统记录取消并更新显示可选或例外的事件路径4a 预约的时间是在该现时间之前1 系统显示,预约的时间是在该查询时间之前,2 系统显示不能取消过去某段时间的预约4b 已经记录了顾客到来的预约1 系统显示不能取消该预约 调换餐桌(Table transfer)基本事件路径1 侍者领班选择需要的预约2 侍者领班改变该预约的餐桌分配3 系统记录改变并更新显示•显示预约(Display Bookings):1用户输入一个日期2系统显示当日的预约。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
QueryGrade
Student
ModifyGrade
学生成绩管理系统 注:visio画用例图系统边界用方框表示同时附上系统名称; rose无法画系统边框
3.5 例:金融贸易系统用例图
Trading Manager
Set Limits
Update Accounts
Accounting System
3.2 参与者
□ 参与者的3种表示形式
<<Actor>> actor2 actor1 Icon形式 Label形式 Decoration形式
actor3
3.2 参与者
□ 参与者之间的关系
泛化(继承)关系:一个一般 性的参与者(父参与者)与另 一个特殊的参与者之间的联系 (子参与者)。 UML图中用空心箭头的实线表 示泛化关系 子参与者继承了父参与者的行 为和含义,还可以增加自己特 有的行为和含义,子参与者可 以出现在父参与者出现的任何 位置上。
3.1 用例
UML建模: ① 静态建模 ② 动态建模 ◇ 静态建模:类图、对象图、构件图和 部署图 ◇ 动态建模:用例图、顺序图、协作图、 状态图和活动图。
3.1 用例
□ 理论上可以把一个软件系统的所有用例都 画出来,但实际开发过程中,进行用例分析 时只需把那些重要的、交互过程复杂的用例 找出来。
3.1 用例
□ 系统的需求大纲
· 系统的目的和范围 · 系统中的术语表 · 用例 · 系统采用的技术 · 开发过程中的参加人员、业务规则、系统 运行所依赖的条件、安全要求、文档要求等各 种其它需求 · 法律、政治、组织机构等方面的问题 See example
3.1 用例
□ 正确使用用例分析来做好领域建模,以确 保定义正确的需求,然后开发出正确的系统, 是保证OO软件开发成功的基础。 □对于初学者来说,掌握用例的概念并不难, 但要在具体的项目中灵活地使用用例来捕获 用户的需求,并不是一件容易的事情,往往 需要用户的经验、沟通能力、丰富的领域知 识等。
3.1 用例
□ 本质上,用例分析是一种功能分解的技术, 并未使用到面向对象思想。因而有人认为用 例分析只是面向对象分析与设计的先导性工 作,并非OOA/OOD过程的一部分,但也有 人视其为OOA/OOD的一环。 □用例是UML的一部分,确定系统的用例是 开发OO系统的第一步,用例分析做得好, 接下来的交互图分析、类图分析等才有可能 做的好,整个系统的开发才能顺利。
Smith
Lecturer
3.2 参与者
【例3.3】在一个银行业务系统中,可能会有以 下参与者: ·客户:从系统获取信息并执行金融交易 ·管理人员:开办系统的用户。获取并更新信息 ·厂商:接受作为转帐支付结果的资金 ·mail系统
3.2 参与者
客户给销售员发来传真订货,销售员下班前将当 然订货单汇总输入系统。谁是系统的参与者? 销售员 系统以外的,需要使用系统或与系统交互的实体
<<include>> Analyze Risk <<include>> Price Deal Valuation
Trader
<<extend>>
Capture Deal
SalesPerson
Limits Exceeded
3.3 脚本
脚本(scenario,情景、场景等)是用例执行 过程中发生的事件流的形式化描述 指贯穿用例的一条单一路径,用来显示用例 中的某种特殊情况 一个脚本使用具体的文字描述来表示 脚本是用例的实例(instance),如果与类和 对象之间的关系作比较,则脚本与用例的关 系相当于对象与类的关系
3.1 用例
□ 用例(use case) -微信: 发送消息给好友 -图书馆系统: 提醒还书日期;维护图书信息 -KFC订餐系统: 下订单 -淘宝系统: 浏览产品,购买产品 -某射击游戏: 开枪 …
3.1 用例
【例】在个人网上银行系统中,可能会有以 下哪些用例: · 浏览账户余额 · 转账 · 登录 · 更新个人信息 · 列出交易内容 · 打印交易内容 · 退出系统 · 设置个人密码
练习1
画出图书管理系统中的用例图。 提示: 系统使用者包括读者、图书管理员、系统 管理员。 读者可以查询图书 图书管理员可以完成图书管理、借阅管理 系统管理员可以完成图书管理、借阅管理 、读者管理、报表管理、系统管理。
练习2
在CarMatch汽车保险管理系统里, 保险公司员工可以基于 保险公司会员客户的年龄、职业及住址给他们搜索合适 的保险产品,然后向会员客户推荐一种或多种保险产品 ,将保险产品卖给会员客户。 1.分析CarMatch系统的用例有哪些?如何命名这些用例? 2.在每个CarMatch汽车保险分公司都有一个保险主管和一 个保险助理。他们的角色都是向CarMatch的客户卖保险 。使用相同的CarMatch系统用例。这个系统的参与者有 哪些,如何命名? 3.画出用例图
练习2
三个用例: 1. 查询保险产品 2. 推荐保险产品 3. 卖保险产品
查询保险产品
由于保险主管和保险助理 都是用相同的用例,所以 没有必要区分他们为不同 的参与者。因此只需要一 种参与者:员工。
员工
推荐保险产品
卖保险产品
3.2 参与者
□ 参与者(actor)是指系统以外的,需要使 用系统或与系统交互的实体(人、设备、外 部系统)例如: ATM系统的参与者是银行客户 超市的管理系统需要与外部信用卡程序建 立联系验证信用卡以便付款,其中外部信 用卡程序就是一个参与者
3.2 参与者
□注:参与者(actor)是一种角色,而不是 具体的人、设备和外部系统。某人可能有多 个角色。例如小王是银行的工作人员,工作 时间他使用银行管理系统,作为管理员这个 角色参与管理,他也可以作为银行用户这个 角色来取钱。
粒度越大,包含的功能越多,反之越少 如果用例粒度很小,那么得到的用例数就会很多,用 例模型过大,引入设计困难就很大 如果用例粒度很大,那么得到的用例数就会很少,不 便于进一步充分分析 建议:简单的系统,复杂度较低,可适当加大用例数; 复杂的系统,一个用例可包含较多的需求信息量。保 证整个模型易理解。
3.3 脚本
【例3.4】:在“订货”这个用例中,包含着 几个相关的脚本。 一个是订货进行顺利的脚本;一个是相关 货源不足的脚本;一个是涉及购物者的信用 卡被拒的脚本,等等。这些脚本的组合构成 了一个用例。
3.3 脚本
讨论:ATM系统中, “取钱”这个用例中, 包含着几个相关的脚本。 一个是取钱进行顺利的脚本;一个是余额 不足的脚本;一个是没有此面额纸币的脚本, 等等。
3.1 用例
□ 用例是与实现无关(implementation independent)的关于系统功能的描述。在 UML中,可以用协作(collaboration)来说 明对用例的实现。
Login realization Login Login realization (with security)
图3.3 用例及其实现
3.1 用例
□ 在UML中,协作用虚线椭圆表示。在图3.3中,对 用例Login共有两个实现,一个是简单的实现,另 一个是带有安全验证功能的实现,这里没有显示 协作的内部结构和行为方面的内容。 □协作的内部由两部分组成:一是结构部分,如类、 接口及其他一些建模元素等;另一部分是行为部 分,说明类、接口以及其他建模元素如何协同工 作,如协作图(collaboration diagram)、顺序图 (sequence diagram)、类图(class diagram)等。 □大多数情况下,一个用例由一个协作实现,这时 可以不用在模型中显式指明这种实现关系。
3.1 用例
□ 用例(use case) ○ 代表系统中各个项目相关人员之间就系统的行为 所达成的契约 ○ 把软件开发过程的需求分析、设计、实现、测试 阶段捆绑在一起 ○ 用例分析结果为预测系统的开发时间和预算提供 了依据,保证了项目的顺利进行。 ○软件开发过程是用例驱动的
3.1 用例
□ 使用用例进行需求分析的特点: 从使用者的角度描述系统中的信息,站在系 统外部看系统,不考虑系统内部对该功能的 具体实现方式 描述了用户提出的一些可见需求,对应一 个具体的用户目标。使用用例可以促进与 用户沟通,理解正确需求,同时也可以用 来划分系统与外部实体的界限 对系统行为的动态描述,属于UML的动态 建模部分
第3章 用例和用例图
Introduction
用例图:是显示一组用例、参与者以及他们之 间关系的图。 在UML中,一个用例模型由若干个用例图描 述。
3.1 用例
□ 用例(use case)--所需求的系统功能的描述 Ivar Jacobson于20世纪60-70年代在爱立信公司 开发AKE、AXE系列系统时发明的。 ○ 定义1:对一个活动者(actor)使用系统的一项功能 时所进行的交互过程的一个文字描述序列。 ○ 定义2:用例是系统、子系统或类和外部的参与者 (actor)交互的动作序列的说明,包括可选的动作序 列和会出现异常的动作序列。
如何确定用例
参与者需要从系统获取哪种功能?参与者 想要做什么? 参与者是否需要读取、产生、删除、修 改、存储系统中的某种信息?如果是, 参与者是如何完成这些操作的? 参与者是否会将外部的事件通知给系统? 系统发生的事件是否通知参与者?
用例图例子
RecordGrade
Teacher
Tutorial Questions
1. 用例图由哪几部分组成? 2. 用例的定义是什么?举例说明什么是用例。 3. 用例的颗粒度是否相同? 4. 用例是否可以表示出所有的系统需求? 5. 什么是参与者? 6. 一个参与者是否可以执行多个用例? 7. 一个用例是否可以由多个参与者使用? 8. 什么是参与者之间的泛化关系?举例说明参与 者之间的泛化关系。 9. 脚本定义是什么?脚本与用例的关系是什么?