5 用例建模
用例建模目标
用例建模目标
用例建模的目标是描述系统的功能需求，通过使用用例图、用例描述和用例之间的关系来定义系统的行为和功能。
具体来说，用例建模的目的是：
1. 确定系统的功能需求：通过分析业务场景和角色与系统的交互，识别系统的功能需求。
2. 描述系统的行为：用例描述了系统在特定场景下的行为，包括前置条件、后置条件和系统与角色的交互等。
3. 定义系统边界：用例建模可以帮助确定系统的边界，明确系统与外部实体（如用户、其他系统等）的交互。
4. 建立需求基线：通过用例建模，可以建立一个清晰的需求基线，为后续的开发和测试提供依据。
5. 沟通工具：用例建模使用图形化的方式描述系统功能，便于开发人员、测试人员和业务分析师等不同角色之间的沟通。
6. 评估和验证：通过评估用例的完整性、正确性和可行性，确保系统功能需求的准确性和完整性。
7. 驱动开发：用例可以作为开发过程中的重要输入，指导开发人员实现系统的功能。
8. 测试依据：测试人员可以根据用例编写测试用例，确保系统功能的正确性和可靠性。
总之，用例建模是一种有效的需求工程方法，可以帮助团队更好地理解和管理系统需求，确保开发出符合业务需求的软件产品。
用例建模
用例（Use Case）是系统为特定的参与者提供的一个功能，它描述了参与者是如何使用系统实现其目标。
用例捕获被开发的系统（或子系统、类或接口）想要实现的行为，而不是说明这些行为是怎样实现的。
用例模型（Use Case Model）是表述用例和参与者所需的图及其描述的集合。
一个完整的用例模型并不是一次完成的。
每一个用例一般都要随着对系统需求认识的深入，有一个不断精化的过程。
随着对问题了解的深入，用例详述不断地添加细节。
因此用例详述可大致分为初始用例详述、基本用例详述和详细详述。
初始用例详述在需求分析开始阶段开发的用例详述，主要确定和粗略地描述由参与者初始化的系统行基本用例详述详细用例详述基本用例详述模板1、前置条件和后置条件应可验证和可测试的方式来记录。
2、前置条件必须反映用例执行前系统需要处于的状态。
3、前置条件和后置条件必须用现在时态记录。
4、给多个前置条件和后置条件分别编号。
5、可以用对象模型来补充前置条件和后置条件中的系统状态描述。
贷款申请活动图用例建模过程中主要包括以下活动组：1、准备用例建模并确定建模方法a)建立系统词汇的术语表。
b)进行涉众分析；选择团队成员并且识别所涉及的客户和用户。
c)选择及定制一个用例过程框架。
d)选择用例建模标准、模板和工具。
对粒度、语态和风格达成一致。
e)确定培训和顾问的需求。
2、进行初始用例建模a)创建初始用例模型图以及语境图。
b)识别主要参与者。
c)发现用例（初始用例详述描述）d)开始识别、精化候选的业务（领域）对象。
3、扩展用例模型a)开发基本用例详述。
b)迭代地细化基本用例详述并确定包含、扩展和泛化关系。
c)将用例映射到对象模型。
d)开发实例脚本4、组织用例a)开发业务功能包b)识别用例依赖流。
c)根据涉众的观点组织用例。
d)重构用例模型。
5、持续进行的用例管理a)让用户确认用例模型。
b)定义并执行测试案例。
c)跟踪持续进行的用例建模进展。
d)根据涉众的反馈更新并且定制框架。
5用例建模
– 是什么事件引起了与系统进行交互的序列？
能完成特定功能的每一项活动明确地是一个用例。这些 参与者参与的活动，通常会导致其它用例。
26
从系统功能角度捕获用例
• 一些简单的指导如下：
–一个用例描述一项功能，这项功能不能过大。
• 例如，把一个企业信息管理系统粗略第分为生产管 理、供销管理、财务管理和人事管理等几大方面的 功能，就显得粒度太大了，应该再进行细化。
7
场景是用例的一个实例
• P47
场景1:成功取款（在验证客户身份后） 1.客户输入提款金额 2.系统查询客户账户余额，并记录客户 提款金额，吐出现金 3.客户提取现金，完成取款 4.系统显示取款成功 场景2:成功取款，中途取款超限额（在验证客户身份后） 1.客户输入提款金额（超过2500元） 2.系统提示金额超过当笔取款限额2500元，并提示客户 重新输入 3.客户输入正确金额 4.系统查询客户账户余额，并记录客户提款金额，吐出 现金 5.客户提取现金，完成取款 6.系统显示取款成功
– 首先开发主要的、高层的用况模型。 – 然后使用该模型开发主要的、本质的用况模型。 – 进一步地，使用所得到的模型指导开发次要的、本质 的用况。 – …… – 最后，使用该模型开发次要的、具体的用况。
29
POS系统用例图
system boundary NextGen POS communication Process Sale Customer alternate notation for a computer system actor
描述软件需求?为后续的开发准备一个系统功能描述在事件流中描述更为详细的信息?参与者做了什么动作?系统是如何响应的?系统和参与者之间交换了哪些信息描述用例场景?成功场景?失败场景描述额外的用例信息?前置条件?后置条件33用例文本表示法?用例编写没有固定格式根据个人需要编写关键是详细编写主流程及备选流程?单栏分格?双栏格式分离参与者与系统的处理步骤不需要描述界面信息?不需要描述界面信息?编写黑盒用例不对系统内部工作构件或设计进行描述34pos系统处理销售用例?用例命名一般是动词名词结构?各小节含义范围?用例描述的是对一个系统的使用为系统用例?说明所要设计的系统说明所要设计的系统级别?用例的级别依据用例服务的对象分为用户目标级别和子功能级别主要参与者?调用此用例提供的服务完成目标的主要参与者35涉众及其关注点?此用例参与的对象关注点所在建议了系统必须要做的事情前置条件和成功保证?前置条件
用例建模
10 1-10
ATM例子 寻找参与者 – ATM例子
1）如果我们所要定义的系统边界仅限于ATM机本身， 如果我们所要定义的系统边界仅限于ATM机本身， ATM机本身 那么后台服务器就是一个外部的系统， 那么后台服务器就是一个外部的系统，可以抽象为一个 参与者。 参与者。
2）如果我们所要定义的系统边界扩大至整个银行系统， 如果我们所要定义的系统边界扩大至整个银行系统， ATM机和后台服务器都是整个银行系统的一部分 机和后台服务器都是整个银行系统的一部分， ATM机和后台服务器都是整个银行系统的一部分，这时 候后台服务器就不再被抽象成为一个参与者。 候后台服务器就不再被抽象成为一个参与者。
17 1-17
使用角色和用例图组织你的用例
用例图是在一个图上显示了多个用例, 用例图是在一个图上显示了多个用例 它是一组用例的 全景图. 有时候角色我们称呼为用户,但是常常会指定一 全景图 有时候角色我们称呼为用户 但是常常会指定一 个具体的角色名称(比如 顾客).用户或者说角色位于系 比如:顾客 个具体的角色名称 比如 顾客 用户或者说角色位于系 统边界之外. 而系统在边界内. 统边界之外 而系统在边界内 角色也可以指非人类的外 部系统,但有时候许多人对这一点迷惑不解 但有时候许多人对这一点迷惑不解,我们已经发 部系统 但有时候许多人对这一点迷惑不解 我们已经发 现使用机器人这种图标可以消除这种迷惑误解. 现使用机器人这种图标可以消除这种迷惑误解 在用例和角色之间的连线表示这个角色是用例的执行者. 在用例和角色之间的连线表示这个角色是用例的执行者 这根连线也表示责任.比如 一个Customer(顾客 指向用 比如:一个 顾客)指向用 这根连线也表示责任 比如 一个 顾客 表示这个顾客负责执行check out(结帐 结帐) 例check out,表示这个顾客负责执行 表示这个顾客负责执行 结帐 可以有多个角色指向同一个用例.表示这个用例与多个 可以有多个角色指向同一个用例 表示这个用例与多个 角色关联.同样的 一个用户可以拥有多个角色.同一个用 同样的,一个用户可以拥有多个角色 角色关联 同样的 一个用户可以拥有多个角色 同一个用 户可以是一个职员,也可能是一个管理员 也可能是一个管理员. 户可以是一个职员 也可能是一个管理员
用例建模步骤
三种模型的关系
4. 功能模型中的数据存储，以及数据的源点/终点， 通常是对象模型中的对象。 5. 功能模型中的数据流，往往是对象模型中的属性值， 也可能是整个对象。 6. 功能模型中的处理可能产生动态模型中的事件。 7. 对象模型描述了功能模型中的动作对象、数据存储 以及数据流的结构。
用例图：视图
在面向对象方法学中，对象模型是最基本的、最 重要的，它为其他两种模型奠定了基础，我们依靠对 象模型完成三种模型的集成。
1. 针对每个类建立的动态模型，描述了类实例的生命 周期或运行周期。 2. 状态转换驱使行为发生，这些行为在数据流图中被映 射成处理，它们同时与对象模型中的服务相对应。 3. 功能模型中的处理，对应于对象模型中类-&-对象所 提供的服务。
一般—特殊结构是一种分类结构，反映 了类间的一般与特殊的关系。一般类与特殊类 之间是一种“is a”的关系，如：汽车是一种交 通工具。同样，特殊类还可以分为更特殊的类， 这样可形成类的层次结构。
• 2. 组装结构 刻画整体—部分组织，表达了自然的整体和部分的结构 关系，从而把一些部分的聚合构造成整体。
计详细的动态模型来自阶详细的功能模型
段
面向对象技术是一个有全新概念 的开发模式,其特点是:
(1)方法是对软件开发过程所有阶段进 行综合考虑而得到的;
(2)从生存期的一个阶段到下一个阶段 所使用的方法与技术具有高度的连 续性;
(3)将OOA、OOD、OOP集成到生存
期的相应阶段.
面向对象分析 Object-Oriented Analysis
• 非正式分析法
用自然语言书写的需求陈述为依据确定的候选者 。
3. 定义类的结构和层次
类的结构主要有两种：一般—特殊 （generalization—specialization）结构和整 体—部分（whole—part）结构。
业务建模及用例建模
业务建模及用例建模1. 业务建模业务建模是指通过对企业业务流程的描述和分析，来描绘企业的运营过程和业务逻辑关系。
它可以帮助企业理清业务流程，优化业务流程，并对业务进行管理和改进。
在软件开发过程中，业务建模也起到了重要的作用。
1.1 业务建模的目的和意义业务建模的目的是帮助企业更好地了解自己的业务流程，找出其中的问题和瓶颈，提出解决方案，并设计出更加高效的业务流程。
通过业务建模，企业可以减少资源浪费，提高业务效率，提升客户满意度。
1.2 业务建模的方法和工具在进行业务建模时，可以采用多种方法和工具，常用的有以下几种：•流程图：用于描述业务流程中的各个步骤和流程之间的关系。
可以直观地展示业务流程，帮助人们理清业务逻辑。
•EPC图：由由事件、功能和控制流组成的图形结构，用于描述业务流程中的各个步骤和流程之间的依赖关系。
•UML：包括用例图、活动图、类图等多种图表，用于描述软件系统的需求和设计。
1.3 业务建模的实施步骤进行业务建模时，可以按照以下步骤来进行：1.确定建模范围：明确需要建模的业务过程范围，确定建模的目标和侧重点。
2.收集业务信息：收集相关业务信息，包括业务流程、业务规则等。
3.描述业务流程：使用合适的建模工具，如流程图、EPC图等，描述业务流程中的各个步骤和流程之间的关系。
4.分析业务流程：对业务流程进行分析，找出问题和瓶颈，并提出改进建议。
5.优化业务流程：根据分析结果，对业务流程进行优化，设计更加高效的业务流程。
6.审核和验证：对优化后的业务流程进行审核和验证，确保其符合实际需求。
7.实施和改进：根据实际情况，将优化后的业务流程付诸实施，并不断进行改进和优化。
2. 用例建模用例建模是指通过对系统的功能需求进行描述和分析，确定系统与用户之间的交互行为和功能。
它可以帮助开发人员更好地理解用户需求，设计出更符合用户期望的系统。
2.1 用例建模的目的和意义用例建模的主要目的是用于系统需求分析和系统设计。
用例建模
38
与系统交互的Actor
Registrar Professor
Student Billing System
39
寻找用例
• Actors的行为决定了他们的需求
– – – – 注册管理员：管理和维护课程表 教师：请求学生名单 学生：维护自己的课程安排 计费系统：从注册系统获取费用信息
Maintain Curriculum
27
功能：
订票
1. 2. 3. 4.
传输/接收 电源/基站 输入输出（显示、键盘） 电话簿管理
顾客 查询车次 用户观点
。。。。。。
用例：
1. 2. 3. 4. 呼叫某人 接听电话 发送短消息 记住电话号码
顾客
处理订票
显示车次 系统观点
。。。。。。
28
！！！在用例描述中不要包 含GUI设计，因为用例是针对 需求的，而界面设计是“设 计”，不要把设计的东西放 进需求里。
A T M 取 款 用 例 描 述
1, 储户插卡；
2. ATM机提示输入用户口令； 3.储户输入口令； 4.ATM机口令验证通过，提示输入钱数； 5.储户输入钱数； 6.ATM机进行钱数有效性检查，提示操作成功，吐出 卡和钱；
24
7.储户取走卡和钱；
8.ATM机屏幕恢复为初始状态。 扩展点 4a. ATM机验证用户口令不通过 4a1. ATM机给出提示信息，并吐出信用卡； 4a2. 储户取出卡； 4a3. ATM机屏幕恢复为初始状态.
30
顾客
<<extend>>
签订汽车购买合同
签订保险单
顾客
<<extend>>
下载软件
第五章 UML用例建模
8
用例图建模步骤
• 第一步：确定参与者(actor)
IT@ANY
• 确定使用该系统的各种人群，一种人群称为参与者(actor)，使用这 个系统或被这个系统使用的其他系统也是参与者。 • 参与者定义：指在某个系统的外部并和该系统交互的一群人或一个系 统。
• 例：下列小组都是参与者
• 银行客户和柜员分别是单独的参与者，因为他们有着不同的需求和权 限 • 大多数游戏系统中，男人和女人没必要分成单独的参与者 • 学生和登记管理员是单独的参与者，有不同的需求和访问
IT@ANY
第五章
UML用例建模
本课程的主要内容
UML用例建模 用例图 活动图 类图 时序图 组件图 部署图
IT@ANY
2
本章目标
了解UML用例建模的几种用例图 知道类图中的各种依赖关系 在实际工作中能够看懂用例图
IT@ANY
3
第一部分
UML用例建模 用例图 活动图 类图 时序图 组件图 部署图
• 例：
• 银行系统有输入帐号、选择帐号、取款、存款、选择源帐号、选择目标帐号、 资金转移等功能，如果将这些动作都作为用例则显得太细，不能满足独立条 件。比如，没有一个用户会在选择一个帐号后就满意的离开！但是，如果只 为一个用例---资金管理，则又显得太笼统。好的用例应提供一个具体的用途！ 取款、存款、转账等都可以是好的用例，均提供了具体的用途！
13
用例图举例
• 银行ATM机：
IT@ANY
• 1. 用户插入卡，输入PIN，系统显示包含用户名的欢迎信息，并提供 取款、存款、转账等选项 • 2. 用户选择取款，系统显示所有可供选择ห้องสมุดไป่ตู้户 • 3. 用户选择帐户，系统要求用户输入金额 • 4. 用户输入一个正整数，系统询问用户数额是否正确 • 5. 用户确定金额是正确的，系统显示感谢信息，取出钱、打印帐单 并返回客户的卡
用UML制作用例模型
昆明理工大学信息工程与自动化学院学生实验报告
（2010—2011学年第 2 学期）
课程名称：面向对象分析与设计开课实验室：计算中心208 2011年5月2日
一、实验目的
实验目的：实践用UML制作用例模型
二、实验原理及基本技术路线图（方框原理图）
实验原理：UML用例模型用于描述软件系统的功能行需求。
用例图包括用例、主角和事件流及用例的相互关系，其中用例代表系统的功能特点，主角代表使用这个功能的用户，事件流描述用户如何使用系统。
三、所用仪器、材料（设备名称、型号、规格等）
1.操作系统：windows xp
2.实验所用软件： PowerDesigner 15
四、实验内容
模型描述：1.会员可通过系统查找汽车型号，包括浏览车型、车辆索引。
2.会员预约车辆/车型，当这辆车可用时，或当有这个车型的汽车时，顾客得到通知。
3.非会员预约车辆/车型，当他缴纳了定金后，当这辆车可用时，或当有这个车型的汽车时，
顾客得到通知。
4.顾客到店提车，助手发车。
5.事后，顾客归还汽车。
五、实验步骤
用例图如下：
五、实验结果分析、经验总结或结论。
通过本次实验对用UML用例模型描述软件系统的功能性需求有了一定的了解，功能性需求是说有具体的完成的内容的需求,比如客户登陆,察看内容. 非功能性需求是说不包括具体的动作内容的需求,比如页面反映速度,系统稳定程度,等等这些内容.对于功能性的需求,实际上都是有非功能性的需求相伴随的.很多时候我们并不是不能完成一个功能,而是不能按照客户的要求在完成.，。
软件工程5 用例建模
系统必须知道哪些外部事件？参与者如何通知系统这 些事件？
系统需要进行哪些维护工作？
18
用例的描述
• 用例简述: 一段简洁的摘要，主要 描述用例的成功场景
• 下订单:
客户带着要购买的货物到收款处，收银员使用POS机
扫描记录每一种预购买的货物。系统计算总价并打印清
单。客户付款，系统验证并保存销售记录。系统更新库
界和范围； (2) 确定每一个参与者所期望的系统行为； (3) 把这些系统行为命名为Use Case； (4) 使用泛化、包含、扩展等关系处理系统行为的公共或
变更部分；
(5) 编制每一个Use Case的脚本； (6) 绘制Use Case图； (7) 区分主事件流和异常情况的事件流，可以把表示异常情况的事 件流作为单独的Use Case处理；
零售店销售管理系统
4
系统边界定义之一
5
系统边界定义之二
6
系统边界定义之三
7
用例图的主要元素
参与者（Actor） 与系统交互的人或外部系统 用例（Use case） 系统为参与者提供的有价值的服务功能 关联（Association） 用例图中用例与参与者之间的交互关系
Actor
Actor
Use Case
11
交互--关联（Association）
Actor 1
• 参与者与用例之间的交互通道 • 用一条直线表示交互——关联
Use Case
• 有箭头的关联指出是谁发起的交互 • 没有箭头则表明双方都可以发起交互
Actor 2
Actor 3
12
用例建型的步骤
(1) 找出系统外部的参与者和外部系统，确定系统的边
16
5-2 用户故事与用例建模
5-2 用户故事与用例建模
用户故事支持敏捷迭代计划
针对识别出的每一个故事，使用Story Point估算其工作量； – 故事点：一个达到共识的基本时间单位，例如1天； – 使用预定的值：1/2、1、2、3、5、8、13、20、40、80； 团队成员分别估计(而不是由项目经理一人决定)，差异较 大时面对面讨论，发现分歧，形成共识； 形成估算清单。
5-2 用户故事与用例建模
用户故事的描述
As a [user role] I want to [goal] so I can [reason] 作为一个<角色>, 我想要<活动>, 以便于<商业价值> Who (user role)
What (goal)
Why (reason) As a registered user I want to log in so I can access subscriberonly content. 作为一个“网站管理员”，我想要“统计每天有多少人访问了我的 网站”，以便于“赞助商了解我的网站会给他们带来什么收益”。
有时候需要在系统内部定时的执行一些操作，如检测系统资 源使用情况、定期生成统计报表等等； 但这些操作并不是由外部的人或系统触发的； 对于这种情况，可以抽象出一个系统时钟或定时器参与者， 利用该参与者来触发这一类定时操作； 从逻辑上，这一参与者应该被理解成是系统外部的，由它来 触发系统所提供的用例对话。 触发 系统时钟 周期性任务
用例模型容易构建、也容易阅读； 完全站在用户的角度上，从系统外部来描述功能； 帮助系统的最终用户参与到需求分析过程中来，其需求更容易 表达出来；Fra bibliotek软件工程
3 用例建模的基本过程
(七)第五章 用例建模
第五章用例建模5.1 用例的基本概念⒈什么是用例用例（use case）是一种建模技术，用于描述新系统应该具备的功能，或者描述一个已有系统已经具备的功能。
用例规定了一个动作序列（可以有多种实现），系统可以执行这些动作并产生出一个对于特定活动者有价值的可见结果。
⒉为什么使用用例①用例提供了一种捕获功能需求的系统而且直觉的方法。
②用例驱动整个开发过程。
5.2 用例中的有关概念用例模型的主要组件：用例、参与者以及被建模的系统。
创建用例模型的过程：①定义系统；②发现参与者和用例；③描述用例；④定义用例之间的关系；⑤对模型进行确认操作。
5.2.1 系统与系统边界系统边界是一个系统所包含的所有成分与系统以外的各种事物的分界线。
这里所说的系统是指被开发的计算机软硬件系统。
Insurance Business图5.1 在用例模型中的系统5.2.2 参与者⒈参与者的概念参与者（Actor）是与该系统打交道的人或者其他系统。
⒉参与者的分类主要参与者（Primary actor）：使用该系统基本功能的参与者。
次要参与者（Secondary actor）：使用该系统次要功能的参与者。
主动参与者（Active actor）：该参与者负责初始启动用例。
被动参与者（Passive actor）：该参与者永远不会初始启动用例，而只是参与系统中的一个或多个用例而已。
⒊发现参与者·谁将使用该系统的主要功能（主要参与者）？·谁将需要该系统的支持以完成他们的日常工作？· 谁将需要维护、管理该系统，以及保持系统处于工作状态（次要参与者）？· 系统需要处理哪些硬件设备？ · 系统需要与哪些其他系统打交道？ ·谁或什么系统对本系统产生的结果感兴趣？⒋ UML 中的参与者图5.2 参与者的表示方法⒌ 参与者之间的关系泛化关系Insurance Agent（a ）(b)图5.3 参与者之间的泛化关系Supplier ’s AgentRestockerCollectorCustomerPersonal Visit CustomerTelephone Customer5.2.3 用例⒈用例的定义UML中的用例定义是：系统执行的一组动作序列，这些动作可以产生一个特定参与者可观察的数值结果。
第7章_用例建模
参与者的特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系； ③.参与者与系统之间存在交互接口。
区分参与者和外部实体
• 只有在执行系统功能时与信息系统进行实时交 互的人员才能被当作参与者。
• 外部实体是指数据的来源和去向，提供数据的 人员不一定会执行系统功能
– 新生入学手工填写个人信息，然后由教务人员统一 将数据登记到学籍系统中，教务人员是参与者。
• 病人拿到挂号单后，到相应的科室进行 就诊。医生根据挂号的顺序号，依次给 病人看病开处方。
• 病人拿处方去收款处交费，并拿到发票。 • 病人拿已经收费的处方去药房拿药。
该系统潜在的参与者和用例有哪些？
用例图
用例图的作用：
用例图用来描述软件需求模型中的系统功能， 通过一组用例可以描述软件系统能够给用户提 供的功能。
⑤.从系统获取信息
有些参与者需要从系统获取必要的信息，例 如：
区分用例和用例完成的步骤
• 不能混淆用例和用例所包含的步骤。
– 比如“借出图书”功能要经过验证读者信息、检 查超出可借数量、保存借书记录、修改图书状态 等步骤
• 在系统中这些步骤通常不作为单独的功能提 供给参与者使用，它们只是一个用例所包含 的事件流，或者是用例的子功能。
– 如果学生直接通过Web方式提交个人信息，则认为 学生是参与者。
区分主要参与者和次要参与者
• 主要参与者（primary actor）是从系统中直 接获得可度量价值的用户。
• 次要参与者（secondary actor）的需求驱动 了用例所表示的行为或功能，在用例中起辅 助支持作用
• 用例分析的重点是要找到主要参与者。
3、用例与场景（Scenarios）
• 用例描述的是一组动作序列，在复杂的系统 中，用例细节可能存在多种不同的情节，称 为变体。
第5章 用例图
5.3 用例（Use Case）
描述用例 8.假设[可选]：假设描述的是系统在使用用例之前必须 满足的状态，这些条件并没有经过用例的检测，用 例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻辑 路径。操作流程描述了用户和执行用例之间交互的 每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径， 那些在变更工作方式、出现异常或发生错误的情况 下所遵循的路径。 11.修改历史记录[可选]：主要记录的是关于用例的修 改时间、修改原因和修改人的详细信息。
扩展关系也是一种依赖关系。 它指定了一个用例可以增强另一个用例的功 能，通过项基本用例添加动作来扩展该用例。 一个用例被定义为基本用例的增量扩展，这 称作扩展关系。 在扩展关系中，基本用例可以是独立的。在 一定条件下，基本用例的动作可由另外一个 用例扩展而来。基本用例提供了若干“扩展 点”，扩展用例只能在这些扩展点上增加一 个或多个新的动作。也就是说，扩展用例只 能发生在基本用例序列中的某个特定的点上。
用例的表示
在UML语言中，用例用一个椭圆来表示，并
且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示，可分为简单名和路径名。其中，路径名 引入了包的概念，在用例名前加上该用例所 属包的名字，两个名字之间用两个冒号分开。
AddBook
Libraian::LoanBook
5.3 用例（Use Case）
5.3 用例（Use Case）
描述用例 5.频率：记录参与者使用该用例的频率。 6.前置条件：前置条件以一个条件列表的形式进行记 录，用来描述执行用例之前系统所必须满足的条件。 这些条件必须在使用用例之前得到满足。前置条件 在使用之前，已经由用例进行过测试。如果条件不 满足，则用例不会被执行。 7.后置条件：后置条件将在用例成功完成以后得到满 足，它提供了系统的部分描述。即在前置条件满足 后，用例做了什么？以及用例结束时，系统处于什 么状态？
用例建模法
用例建模法用例建模法是一种常用的需求分析方法，通过描述系统与外部参与者之间的交互，帮助我们理解系统功能与行为。
在这种方法中，我们考虑系统能够提供给参与者的不同用例或场景，并描述了参与者与系统之间的交互。
以下是用例建模法的相关参考内容。
1. 用例建模的基本概念：用例：用例是一个有序的事件序列，用于描述参与者与系统之间的交互。
参与者：参与者是与系统进行交互的外部实体。
它可以是一个人、一个组织或另一个系统。
系统边界：系统边界是用于定义系统与外部参与者之间的界限。
主要成功场景：主要成功场景是该用例的典型执行路径，描述了系统如何响应参与者的请求并达到预期结果。
2. 用例建模的过程：(1) 识别参与者：确定系统的外部参与者，并理解他们对系统的期望。
(2) 确定用例：识别系统能够为参与者提供的用例或场景，并描述其目标和预期结果。
(3) 建立参与者与用例之间的关系：描述参与者与用例之间的交互方式和角色。
(4) 确定用例间的关系：通过识别用例间的相互作用和依赖关系来整理用例。
3. 用例建模的优点：(1) 用例建模通过描述用例和参与者之间的交互，帮助人们理解系统的需求和功能。
(2) 用例建模提供了一种可视化表示方法，使得分析和理解需求更容易。
(3) 用例建模强调用户的角色，有助于设计出更加用户友好的系统。
(4) 用例建模可以帮助团队成员进行有效的沟通和协作。
4. 用例建模的步骤：(1) 确定系统的边界：定义系统与外部参与者之间的边界。
(2) 识别参与者：确定与系统进行交互的外部参与者，并描述他们的期望和角色。
(3) 识别用例：确定系统需要提供的用例或场景，并描述它们的目标和预期结果。
(4) 建立参与者与用例之间的关系：描述参与者与用例之间的交互方式和角色。
(5) 确定用例间的关系：识别用例之间的相互作用和依赖关系。
以上是用例建模法的相关参考内容。
用例建模是一种常用的需求分析方法，通过描述系统与外部参与者之间的交互，帮助我们理解系统功能与行为。
用例建模
上海财经大学信息管理与工程学院
-19-
第7讲 用例建模
7.3 需求用例建模过程
构造需求用例模型的步骤：
1. 确定业务参与者. 2. 确定业务需求用例. 3. 构造用例模型图. 4. 记录业务需求用例描述.
上海财经大学信息管理与工程学院
-20-
第7讲 用例建模
7.3 需求用例建模过程
1 确定业务参与者:
-34-
第7讲 用例建模
7.4 用例和项目管理
用例分级与优先级矩阵Use用例分级与优先级矩阵Use-case ranking and priority Use matrix – 用来评估用例并决定其优先级的工具。
思考：用例主要解决什么问题？ 思考：用例主要解决什么问题？
系统开发最主要挑战：从关联人员那里提取正确的必要的系统需 求，并以关联人员可以理解的方式进行说明，以便需求可以得到 验证和证实。
问题：
软件需求说明容易混淆分析与设计的界限 数据和过程模型、原型、系统规格说明等工具，设计人员能够理 解但是用户很难理解。 导致范围蔓延、费用超支和进度蔓延等。
参与者Actor – 需要同系统交互以及交换信息的任 何事物。
上海财经大学信息管理与工程学院
-8-
第7讲 用例建模
7.2用例建模概念
四类主要参与者： 四类主要参与者： 主要业务参与者Primary 主要业务参与者Primary business actor 主要从用例中受益的关联人员。 e.g.收到发票的雇员 主要系统参与者Primary 主要系统参与者Primary system actor 直接与系统交互，发起或者触发业务或者系统事件的关联人员。 e.g. 银行出纳输入存款信息 外部服务参与者External 外部服务参与者External server actor 对用例请求进行响应的关联人员。 e.g. 信用卡部门认证一个信用卡支付。 外部接收参与者External 外部接收参与者External receiver actor 不是主要参与者但是可以从用例接收某些可度量的或者可观察的价值。 e.g. 接收打包单的仓库。
用例建模与分析PPT学习教案
3 GIS软件工程—用例建模与分析
❖人； ❖计算机硬件或设备； ❖外部系统。
参与者代表了用户可以扮演的角色，不是某个特定的用户，而是可以 扮演某个角色的一组用户。一个人可能是某个参与者的实例，多个人也 可能扮演某个参与者的同一角色。
识别用例的通用方法是与将要直接操作该系统的用户交谈，该过程有 助于设计满足用户需求的系统。而系统的其它涉众可能在关键的开发阶 段漏掉，导致系统可能不满足所有涉众需求。在同一个软件系统中，不 同涉众的需求可能存在冲突，开发小组的通行做法是召集所有涉众，以 确定所有需求，同时解决存在矛盾的需求。 2.表示参与者
第16页/共58页
3 GIS软件工程—用例建模与分析
用例可能还展现多个场景，普通场景以及可能的几个其他场景。基本用例 可以用来表示普通场景，而抽象用例则可以用来描述其他场景。
下图给出了一个ATM系统的用例模型，取款是一个基本用例，是用户成功 登录系统的普通场景，指定交易类型，并输入取款的有效金额。而处理超额属 于抽象用例，因为用户的银行账户中可能有足够的钱供其取出。
定义了开发中的系统范围，在UML中用矩形表示边界，所有用例都必 须放在边界以内。参与者放在系统边界以外，所有用例共同组成了系统的 总需求。
第5页/共58页
3 GIS软件工程—用例建模与分析
3.5 用例建模示例
1. ATM系统 ATM通过计算机化银行网络进行账户交易，银行网络包含一台中 心计算机，它连接着所有的ATM机和单个银行拥有的银行计算机， 每台银行计算机用来处理由其客户请求的交易。 在这个例子中，客户Customer是ATM系统的一组参与者。他们 操作ATM存款、取款或者检查账户余额等。可以将这些可观察的服 务作为用来。
取款
超额取款
五级建模步骤规则
五级建模步骤规则五级建模是一种常用的软件开发方法，它可以帮助开发者更好地理解需求、设计系统、编写代码。
下面将介绍五级建模的步骤规则。
一、需求分析1.1 确定需求在需求分析阶段，首先需要确定项目的需求。
这包括客户提出的功能要求、性能要求、安全要求等。
1.2 分析需求确定了项目的需求后，需要对其进行详细分析。
这包括确定每个功能的具体实现方式、确定系统各部分之间的关系等。
1.3 编写用例用例是描述系统行为的一种方法。
在需求分析阶段，需要编写用例来描述系统各个功能的使用场景和行为。
二、领域建模2.1 确定领域对象在领域建模阶段，需要确定系统中涉及到的领域对象。
这些对象包括实体、属性和关系等。
2.2 绘制类图类图是描述系统中类和类之间关系的一种方法。
在领域建模阶段，需要根据领域对象绘制类图，并确定类之间的关系。
三、设计架构3.1 确定架构类型在设计架构阶段，需要根据项目特点选择适合的架构类型。
常见的架构类型有MVC、MVP、MVVM等。
3.2 绘制系统结构图系统结构图是描述系统整体结构的一种方法。
在设计架构阶段，需要根据选定的架构类型绘制系统结构图。
四、详细设计4.1 设计模块在详细设计阶段，需要将系统分解为多个模块，并对每个模块进行详细设计。
这包括确定模块功能、接口和实现方式等。
4.2 绘制时序图时序图是描述系统中对象之间交互行为的一种方法。
在详细设计阶段，需要根据模块之间的交互关系绘制时序图。
五、编码实现5.1 编写代码在编码实现阶段，需要根据详细设计阶段确定的接口和实现方式编写代码。
5.2 单元测试单元测试是对代码进行测试的一种方法。
在编码实现阶段，需要对每个模块编写相应的单元测试用例，并进行测试。
以上就是五级建模步骤规则的详细介绍。
通过遵循这些步骤规则，可以帮助开发者更好地理解需求、设计系统、编写代码，从而提高软件开发效率和质量。
第5讲 用例建模
2 识别参与者(Actor)
从需求中识别参与者
参与者：在系统之外，通过系统边界与系统进 行有意义交互的任何事物
要点：任何事物
任何事物举例：小人与圣小猪-1
如果我开发一个猪圈自动供食供水系统 ，猪的 前蹄触发一个开关系统就供食或供水。很显然 这里的参与者是小猪。通常，用例图中的参与 者用一个小人表示。
场景1：某企业要求开发一个企业信息管理 系统，并与原来已有的库存系统相连接
系统之外，重点明确新老系统间的接口
场景2：某企业要求开发一个企业信息管理 系统，并把原来已有的库存管理系统加以 改造，成为企业信息管理系统的一部分
系统之内，新系统存在一个“改造库存系统” 用例，工作量要比上述大很多
参与者的命名
涉众无法直接提供需求的现象
涉众无法陈述自己的需要
涉众说的是解决方案而不是需求
涉众难以构想新的工作方法
涉众的利益矛盾
涉众抵制变更
“最好也要有”—过度的要求
需求引发新的需求
获取需求的技巧——需求启发技术
技巧 描述 直接观察个人工作的情况，以发现现存的实践方 实地观察 式和问题，提供最直观的业务细节，但耗时 访谈 从个人处收集特定信息，直接沟通，信息真实性 特定群体 对一组人员进行调查，以便了解工作态度和共同 看法 调查 收集详细数据和统计意义上比较重要的数据，可 问卷调查 以获得匿名答复 用户指导 让最终用户告诉你，他们是如何实现业务流程的 原型制作 模拟一个无法直接测试的系统，便于沟通 记录用户完成任务的方式，便于了解用户习惯， 统计版本 及时改进
多，反之则包含的功能越少。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Self-message 自关联消息
Time-out 超时等待 Uncommitted／Balking 阻塞
绘制顺序图
1. 在顺序图顶端绘制矩形框，定义参与交互的类实例（对象）名； 2. 在每个对象下面绘制竖直虚线，表示该对象的生命线；
3. 在对象间添加箭头表示各种类型的消息，跟踪对象间的控制流；
存，客户得到收条并带着货物离开。
19
用例的描述
20
用例的描述
客户代表
1. 收到一个取消订单的请求 2. 输入订单的标识号
系统
记帐系统
3. 显示订单内容 4. 选择取消
5. 给该订单打上取消标记
6. 向客户账号增加订单 支付的资金
21
用例建模过程中的检查项
• 用例建模是为了表示系统的行为。通过模型可以很容 易理解系统进行的操作 • 应该识别出所有的用例，用来表达所有的需求。
零售店销售管理系统
4
系统边界定义之一
5
系统边界定义之二
6
系统边界定义之三
7
用例图的主要元素
参与者（Actor） 与系统交互的人或外部系统 用例（Use case） 系统为参与者提供的有价值的服务功能 关联（Association） 用例图中用例与参与者之间的交互关系
Actor
Actor
Use Case
• 没有实际价值的用例 • 通过底层操作进行命名
• “操作”+“对象” • “功能” + “数据”
• 从一个用户的角度出发
• 例如：“插入卡片”
” ”
• “这个用例背后的用户故事是什么？
25
‹#›
‹#›
详细的用例规约
28
顺序图举例
• 顺序图用来刻画系统实现某个功能的必要步骤
小明: 学生
选课登记表
• 系统的任何一个特性都可以找到对应的用例
• 用例模型并不包含多余的行为；所有的用例可以追溯 到系统的功能性需求作为验证。 • 去掉所有的CRUD 类的用例
创建(Create),查找(Retrieve),更新(Update),删除(Delete)
22
功能分解
选择转入账号 选择“取款” 选择“查询余额”
• 包含状态入口或出口、行为描述
• 从不同的抽象层次分析对象，因此其状态是可嵌 套（组合）的 • 在给定的场景下，对象状态是确定的，可满足或 不满足某个状态
状态迁移
迁移包括五部分：
• 源状态(source state)、触发事件 (event trigger), 警戒条件(guard condition), 动作(action), 目标状态(target state).
状态的抽象表示
• 但往往状态空间中的局部更有探究的价值 • 有一些状态是不可能出现的状态 • 整数或实数值属性往往只在一定范围内取值 • 通常，我们只关注特定约束下的对象及其
行为
例如，对于年龄, 我们经常选择以下的范 围：
age< 18；18≤age≤65；age> 65
例如，对于费用信息,我们更关注的约束划分为： cost ≤ budget，cost=0，cost >budget，cost >(budget+10% )
简要描述：使用ATM系统提取现金、转移资金和存款的所有 用户，这些用户持有相应的银行卡且知道银行卡对应账号的密 码。
15
参与者建模的检查项
• 是否找全所有的参与者？是否对系统环境中所有的角
色进行了描述和建模？
• 每个参与者是否至少与一个用例发生了交互？ • 是否可以为每一个角色找到至少两个实例？ • 不同参与者与系统的交互是否一致，扮演的角色是否 相似？如果有，则应该要合并这些参与者作为同一种 角色
用例建模
1
用例建模 用例建模概念 用例建模过程 用例建模精讲
建模工具介绍
2
用例模型的表示--用例图
自动提款机(ATM)
取款
转账
银行客户
银联
存款
收取存款
柜员
日常维护
系统维护人员
3
系统
系统是指待开发的任何事物，包括软件、硬件或者过程。 系统边界:
一个系统所包含的所有系统成分与系统以外各种事物的分界线 • 系统边界会对用例以及Actor的定义有所影响 考虑用于零售店销售管理的系统的用例图 ：
状态图建模
• 状态图用来表示一个类的全生命周期过程
• 建模元素 • 状态 • 事件 • 状态转移 • 状态图的绘制
new() Push()
empty
Pop()
1item
…
状态（State）
定义： 一个对象生命期的一个阶段，该阶段中对象要满足 一些特定的条件、执行特定的活动或等待某个（些）事 件的发生 • 体现为对象属性的取值
提交成绩 教师
10
什么是用例
Use Case Name
一个用例
定义系统的一系列行为，通过此可为参与者提
供有价值且可观测的结果。
• 定义一个参与者要用到的系统功能 • 描述系统为实现参与者价值所开展的行为序列
• 对参与者与系统之间的交互活动进行建模
• 从特定的用户角度出发是完整的，实现特定用户价值的事件 流
• 例如. 完成工作，考试未通过，系统崩溃
• 在 OOD( 面向对象设计 )中通过传递消息的方式实现事件
• 在 UML 中，有四种类型的事件
• 变更事件(Change events) 当给定条件成立时就会发生变更事件
• 调用事件(Call events) 当给定对象的操作被调用执行时会发生调用事件 • 时间事件(Elapsed-time events) 表明时间段过去，或某个特殊时间点的触发
16
寻找用例
基本策略：把自己当作参与者，与设想中的系统进行交互。
我想通过这个系统达到什么目的？
目标 1
参与者
目标 2
注意：寻找用例和寻找参与者的过程是不能截然分开的
17
识别用例
参与者希望系统提供哪些功能？ 系统存储信息吗？参与者将要创建、读取、更新或删 除什么信息？ 系统是否需要把自身内部状态的变化通知给参与者？
11
交互--关联（Association）
Actor 1
• 参与者与用例之间的交互通道 • 用一条直线表示交互——关联
Use Case
• 有箭头的关联指出是谁发起的交互 • 没有箭头则表明双方都可以发起交互
Actor 2
Actor 3
12
用例建型的步骤
(1) 找出系统外部的参与者和外部系统，确定系统的边
1: 填写个人信息 2: 提交
选课管理员
线性代数
线性代数 A段
3: 将马小跳加入线代选课名单 4: 添加马小跳 5: 还有位置吗? 6: 如果有，添加马小跳
顺序图建模元素--对象（Object）及其生命线（Lifeline）
对象以某种角色参与交互
可以是人、物、其他系统或者子系统
生命线：表示对象存在的时间
控制焦点/激活期(Focus of Control/Activation)：表示对象 进行操作的时间片段
顺序图建模元素--消息（Message）
消息（Message）用于描述对象间的交互操作和值传递过程
消息类型:
Synchronous 同步消息（调用消息）
Asynchronous 异步消息 Return 返回消息
23
走出功能分解：正确的用例建模
转账 (Transfer Funds)
24
如何避免功能性分解
问题现象 • 非常细小的用例 修改思路 ： • 寻找更大的应用场景
“为什么要构建这个系统？ ”
• “用户希望达到什么目的？” • “这个用例可以满足谁的目标？” • “这个用例的意义是什么？有什么价值？
• 用例过多
Delivered
系统必须知道哪些外部事件？参与者如何通知系统这 些事件？
系统需要进行哪些维护工作？
18
用例的描述
• 用例简述: 一段简洁的摘要，主要 描述用例的成功场景
• 下订单:
客户带着要购买的货物到收款处，收银员使用POS机
扫描记录每一种预购买的货物。系统计算总价并打印清
单。客户付款，系统验证并保存销售记录。系统更新库
13
寻找参与者
• • • • 谁使用系统的功能？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其正常工作？ 哪些其他系统使用该系统？
•
• • •
系统需要与其他哪些系统交互？
系统需要控制哪些硬件？ 对系统产生结果感兴趣的是哪些人或物？ 是否有事情在预计的时间自动发生？
14
参与者的描述
参与者规格说明 参与者名称：顾客 是否抽象参与者：否
源状态
事件名[‘(’用逗号分隔的参数表‘)’][警戒条件 ]‘/’动作表达式
目标状态
• 对于给定的状态，最终只能产生一个迁移，因此从相同的 状态出来的、事件相同的几个迁移之间的条件应该是互斥 的。
事件（Events）
• 事件(Events)的意义在于系统需要了解正在发生什么
• 状态图中，事件仅需和系统或当前建模的对象相关 • 从系统角度出发，事件必须建模成一个瞬间可完成的动作
界和范围； (2) 确定每一个参与者所期望的系统行为； (3) 把这些系统行为命名为Use Case； (4) 使用泛化、包含、扩展等关系处理系统行为的公共或
变更部分；
(5) 编制每一个Use Case的脚本； (6) 绘制Use Case图； (7) 区分主事件流和异常情况的事件流，可以把表示异常情况的事 件流作为单独的Use Case处理；