4[1].用例图概述
UML用例图的基本概念
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求，通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计，通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一：简单登录系统用例图分析
总结词：简单明了
详细描述：简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中，可以清晰地表示出系统的主要功能和参与者的角色。
案例二：网上购物系统用例图分析
总结词：复杂多样
详细描述：网上购物系统涉及到多个参与者，如顾客、管理员和供应商等，以及多种复杂的业务功能，如商品展示、购物车 管理、订单处理和支付等。在UML用例图中，需要对各个功能进行详细的描述和分类，以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计，通过分析用例之间 的关系和交互，设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口，明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程，通 过分析用例的执行顺序和交互逻辑， 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示，可以作为沟通 工具，帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图，可以与利益相关者讨论和确认 系统的需求，确保对需求的理解和期望是一致的。
第三讲 用例图
用例描述——事件流
1、事件流
事件流描述了一个用例在执行时参与者 与系统之间的交互过程。 其中预期会成功的路线称为基本流，剩 下其他路线称为备选流。
基本流
• 基本流是对用例中常规和预期路径的描 述。
• 执行者通过这个路径来执行用例可以得 到一个有价值的结果。
用例描述——事件流
• 例如，银行自动取款机(ATM)系统中的 “提款”用例可以用事件流表述如下：
•提款─基本事件流 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡
备选流
在用例的执行过程中，不一定都按常规 和预期的路径进行。 由于受到其他一些因素的影响，这时可 能执行了其他的路径，这种路径叫做备 选流。
备选流
•提款─备选事件流：
1.a ：如果用户插入无效信用卡，系统显示错误并 退出信用卡，用例结束。
• 用例分析技术是一种用户需求获取、分 析和描述技术。
• 用例图主要用于需求分析阶段。 • 用例图描述了待开发系统的功能需求。 • 用例图从用户的角度来理解系统，不关
心系统的内部结构。 • 用例图是后继各阶段开发工作的基础。
用例图
• 用例图是显示一组用例、参与者以及它们之间 关系的图。
– 用例图从用户的角度而不是开发者的角度来描 述对软件产品的需求，分析产品所需的功能和 动态行为
用例或关联参与者？
用例之间的关系
泛化关系 包含关系 扩展关系
用例之间的关系
泛化：同一业务目的的不同技术 实现。 包含：表示一个用例使用了另一 个用例的行为或功能。通过包含 用例提取公共交互，提高复用。 扩展：描述某个用例的特殊情况。 “冻结”基用例以保持稳定。
*通过关系提高用例复用
软件工程中过程设计的工具(二)
引言：在软件工程领域，过程设计是一项重要的工作，它涉及到软件开发过程中的各个环节和方法，以确保项目的成功交付。
随着技术的不断发展，出现了许多工具来帮助软件工程师进行过程设计。
在本文中，我们将探讨几个在软件工程中常用的过程设计工具，包括流程图、时序图、状态转换图、数据流图和用例图。
概述：过程设计是软件工程中非常重要的一环。
它涉及到制定清晰的计划，确定所需的功能和特性，以及设计各个阶段的活动和过程。
在过程设计中，工具可以帮助软件工程师更好地理解和表达需求，优化项目进程并保证交付质量。
正文内容：1.流程图（Flowchart）1.1定义：流程图是一种图形表示方法，用于描述系统或程序的流程和控制逻辑。
1.2主要应用：流程图可以帮助软件工程师清晰地表示系统或程序中的各个步骤和分支，有助于发现潜在的问题和优化流程。
1.3示例：流程图的基本符号包括开始/结束符号、处理符号、判断符号和连接符号。
通过连接这些符号，可以构建一个清晰的流程图，展示系统或程序的流程和控制逻辑。
2.时序图（SequenceDiagram）2.1定义：时序图是一种用于描述对象之间交互的图形表示方法，特别适用于描述系统中的时序和消息传递。
2.2主要应用：时序图可以帮助软件工程师清晰地表示系统中各个对象之间的交互方式和时序关系，有助于分析系统的整体结构和优化通信过程。
2.3示例：时序图通过箭头表示消息的发送和接收，以及参与交互的对象。
通过时序图，软件工程师可以更好地理解系统中的对象之间的时序关系和通信过程。
3.状态转换图（StateTransitionDiagram）3.1定义：状态转换图是一种用于描述对象状态和状态之间转换的图形表示方法，特别适用于描述系统中对象的行为。
3.2主要应用：状态转换图可以帮助软件工程师清晰地表示系统中对象的状态和状态之间的转换，有助于分析系统的行为和优化状态转换过程。
3.3示例：状态转换图通过状态表示和过渡表示来描述对象的状态和状态之间的转换。
第4章Use_Case图
•使用案例的正常(主)流程
•其他事件流 •错误流
•使用案例如何结束
2013年2月28日
12 3
例如：客户用常客卡买票，客户信用卡无效或请求的航班没有。这些情形 是系统能够处理的合法情形，而不是系统中发生错误。最后，错误流表示 错误条件。例如，系统无法验证信用卡或航班有没有。(错误流表示系统本 身的问题。) 主事件流： 主事件流的步骤如下： 1、客户选择浏览航班信息的选项时，用例开始。 2、系统提示输入出发站和到达站，出发时间和返回时间。 3、用户输入出发站和到达站，出发时间和返回时间。 4、系统显示航班清单及票价。 A1：没有这个航班 5、用户选择要打的航班。
A5：没有常客免费票
5、票价设置为0美元。 2013年2月28日 15 3
6、返回主事件流第8步。 A3：常客卡号无效 (描述的是其他事件流的A3)
1、系统显示常客卡号无效的消息。
2、用户重输卡号或选择取消常客免费请求。 3、如果用户重输卡号则流转入其他事件流A2第1步。
4、如果选择取消常客户免费票请求，则流返回主事件流第6步。
2013年2月28日
14 3
其他事件流 A1：没有这个航班
1、系统显示消息，没有所输入出发站和到达站以及出发时间和返回时间的航班。
2、用户确认消息。 3、返回主事件流第2步。 A2：用户用常客卡选择免费机票 1、系统提示输入常客卡号。 2、用户输入常客卡号。 3、系统确认卡号有效。 A3：常客卡号无效 4、系统确认里程数足够兑换免费机票。 A4：里程数不够兑换免费机票
评价贸易
* **
交易估价
* * **
营销人员
*
进行交易
<<extends>>
用例图设计：根据需求,绘制用例图,明确系统功能和模块
用例图设计：根据需求，绘制用例图，明确系统功能和模块一、引言随着信息技术的快速发展，软件系统在各个领域得到广泛应用。
而在软件系统开发的过程中，需求分析是至关重要的一环。
其中，用例图作为一种常用的需求分析工具，能够帮助开发团队理解系统功能并明确系统模块。
本文将介绍用例图设计的基本概念和步骤，并结合一个实际案例进行说明。
二、用例图设计概述1. 用例图的定义用例图是一种描述系统功能和角色之间交互关系的图形化工具。
它能够帮助开发团队和用户理解系统的功能，并明确各个模块的职责和关系。
2. 用例图的组成元素用例图由用例、参与者和关系三个主要元素组成。
- 用例（Use Case）：用例是指系统提供给用户的功能需求，用一个椭圆形图标表示。
每个用例都有一个唯一的名称，用以描述其功能和目的。
- 参与者（Actor）：参与者是指与系统交互的用户、其他系统或外部设备，用一个小人形图标表示。
每个参与者都有一个唯一的名称，用以描述其角色和功能。
- 关系（Relationship）：关系是指用例与参与者之间或用例之间的交互关系，用实线、虚线或箭头表示。
常见的关系有包含关系、扩展关系和泛化关系。
三、用例图设计步骤用例图设计的步骤主要包括需求收集、用例识别、参与者识别、用例编写和关系建立。
1. 需求收集需求收集是用例图设计的第一步，开发团队需要与用户进行充分的沟通和交流，了解系统的功能需求和用户的期望。
通过与用户积极互动，收集尽可能多的信息，以便后续的用例识别和设计。
2. 用例识别用例识别是根据需求收集的结果，将系统的功能需求划分为不同的用例。
每个用例都应该描述一个具体的功能，并具有明确的输入和输出。
3. 参与者识别参与者识别是根据需求收集的结果，将与系统交互的用户、其他系统或外部设备识别出来，并为每个参与者定义明确的角色和功能。
4. 用例编写用例编写是将识别出来的用例进行详细描述。
每个用例应包含用例名称、前置条件、正常流程、异常流程和后置条件等内容。
面向对象的分析与设计——用例图实验
面向对象的分析与设计——用例图实验实验目的1、熟悉UML用例图的功能和元素2、学会识别参与者和用例3、掌握用例图的绘制方法4、学会编写用例描述实验内容：任务一：分析图书管理系统的登录模块，且绘制用例图用例图主要在系统需求分析阶段和系统设计阶段使用。
在系统需求分析阶段，用例图用来获取系统的需求，理解系统应当如何工作；在系统设计阶段，用例图用来规定系统要实现的行为。
1、分析用户登录模块的功能需求提供输入“用户名“和“密码“的文本框，验证用户身份的合法性。
2、识别参与者在用户登录模块中，根据工作内容和操作权限的不同，可细分为4类参与者：图书借阅员、图书管理员、系统管理员、图书借阅者。
图书借阅员必须先进行登录，然后才可以执行借出或归还图书的操作；图书管理员必须先进行登录，然后才可以执行编制书目、图书入库等操作；系统管理员必须先进行登录，然后才可以进行系统的维护操作；图书借阅者也必须先进行登录，然后才能查询图书借阅情况或查询图书馆藏书信息。
3、识别用例用户登录模块的主要功能是：输入“用户名“和“密码“，验证用户身份的合法性，故主要用例有两个：输入用户名和密码、验证用户身份。
4、绘制用例图操作步骤：1)运行Microsoft Office Visio 20072)选择“软件和数据库”中的“UML模型图”模板3)鼠标点击选择“UML用例”，展开UML用例图的图标4)用鼠标选拉图标进行绘图5、描述用例用例名称验证用户身份用例编号简要说明验证用户所输入的“用户名“和“密码“是否有效参与者图书管理员、系统管理员、图书借阅员、图书借阅者当前状态等待审查使用频率较高前置条件已输入有效的“用户名“和“密码“后置条件登录进入系统基本操作流到“用户信息“数据表中检索是否存在相应的“用户名“和“密码“备选操作流如果“用户名“和“密码“有误，显示提示信息。
任务二分析网上书店的业务需求，且绘制用例图站在客户的角度分析，网上书店要实现的基本功能主要有以下几种：（1）用户注册（2）用户登录（3）图书查询与浏览（4）用户订购图书（5）用户购物车管理（6）订单维护（7）个人信息维护当客户打开网上书店后，无需登录即可查询图书，还可查看图书的详细信息。
UML用例图介绍
UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用？ (1)3、UML用例图的目的 (2)4、如何画用例图？ (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。
用例图展示了一个外部用户能够观察到的系统功能模型图。
用例图由主角，用例和它们之间的关系组成。
2、用例图怎么使用？要了解一个系统的动态，我们需要使用不同类型的图表。
用例图就是其中之一，其具体目的是收集系统的的需求和参与者。
用例图指定系统的事件和他们的流向。
但从未用例图描述了他们是如何实现的。
可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。
在这些图中使用的设计在一个非常高的水平。
那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。
一个结构良好的用例，还介绍了前置条件，后置条件和例外。
而这些多余的元素在执行测试时被用来制造测试的情况下。
用例都不是正向和反向工程，但他们仍然使用略有不同的方式。
同样是真实的逆向工程。
仍用例图的使用方式不同，使其逆向工程的一个候选。
在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。
所以下面的地方使用用例图：2.1.需求分析和高水平的设计。
2.2.模拟系统的上下文。
2.3.逆向工程。
2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。
用例图是用来收集系统的要求，包括内部和外部的影响。
这些要求大多是设计要求。
所以，分析一个系统时要收集其功能用例和确定参与者。
简单来说，用例图的目的如下：3.1.用例图用来收集系统的要求。
3.2.用例图用于获取系统的外观图。
3.3.用例图识别外部和内部因素影响系统。
3.4.用例图显示要求之间的相互作用是参与者。
4、如何画用例图？用例图被认为是高层次的需求分析系统。
因此，当系统的要求，分析被捕获在用例的功能。
第7章_用例建模
参与者的特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系； ③.参与者与系统之间存在交互接口。
区分参与者和外部实体
• 只有在执行系统功能时与信息系统进行实时交 互的人员才能被当作参与者。
• 外部实体是指数据的来源和去向，提供数据的 人员不一定会执行系统功能
– 新生入学手工填写个人信息，然后由教务人员统一 将数据登记到学籍系统中，教务人员是参与者。
• 病人拿到挂号单后，到相应的科室进行 就诊。医生根据挂号的顺序号，依次给 病人看病开处方。
• 病人拿处方去收款处交费，并拿到发票。 • 病人拿已经收费的处方去药房拿药。
该系统潜在的参与者和用例有哪些？
用例图
用例图的作用：
用例图用来描述软件需求模型中的系统功能， 通过一组用例可以描述软件系统能够给用户提 供的功能。
⑤.从系统获取信息
有些参与者需要从系统获取必要的信息，例 如：
区分用例和用例完成的步骤
• 不能混淆用例和用例所包含的步骤。
– 比如“借出图书”功能要经过验证读者信息、检 查超出可借数量、保存借书记录、修改图书状态 等步骤
• 在系统中这些步骤通常不作为单独的功能提 供给参与者使用，它们只是一个用例所包含 的事件流，或者是用例的子功能。
– 如果学生直接通过Web方式提交个人信息，则认为 学生是参与者。
区分主要参与者和次要参与者
• 主要参与者（primary actor）是从系统中直 接获得可度量价值的用户。
• 次要参与者（secondary actor）的需求驱动 了用例所表示的行为或功能，在用例中起辅 助支持作用
• 用例分析的重点是要找到主要参与者。
3、用例与场景（Scenarios）
• 用例描述的是一组动作序列，在复杂的系统 中，用例细节可能存在多种不同的情节，称 为变体。
UML系统建模基础教程课后习题答案
UML 系统建模基础教程课后答案第一章面向对象设计与UML1．填空题（1）UML（2）封装继承多态（3）继承（4）瀑布模型喷泉模型基于组件的开发模型XP 开发模型2. 选择题（1）C（2）A B C D（3）A B C D（4）A B C（5）A1.试述对象和类的关系。
（1）类是具有相同或相似结构、操作和约束规则的对象组成的集合，而对象是某一类的具体化实例，每一个类都是具有某些共同特征的对象的抽象。
类与对象的关系就如模具和铸件的关系，类的实例化结果就是对象，而对一类对象的抽象就是类.类描述了一组有相同特性和相同行为的对象。
第二章UML 通用知识点综述（1）依赖泛化关联实现（2）视图图模型元素（3）实现视图部署视图（4）构造型标记值约束（5）规格说明修饰通用划分2. 选择题（1）D（2）C（3）A（4）A B（5）D（6）1）在UML 中面向对象的事物有哪几种？在UML 中，定义了四种基本的面向对象的事物，分别是结构事物、行为事物、分组事物和注释事物等。
（7）2）请说出构件的种类。
构件种类有：源代码构件、二进制构件和可执行构件。
（8）3）请说出试图有哪些种类。
在UML 中主要包括的视图为静态视图、用例视图、交互视图、实现视图、状态机视图、活动视图、部署视图和模型管理视图。
（9）4）请说出视图和图的关系。
视图和图是包含和被包含的关系。
在每一种视图中都包含一种或多种图。
（10）5）请简述UML 的通用机制。
UML 提供了一些通用的公共机制，使用这些通用的公共机制（通用机制）能够使UML 在各种图中添加适当的描述信息，从而完善UML 的语义表达。
通常，使用模型元素的基本功能不能够完善的表达所要描述的实际信息，这些通用机制可以有效地帮助表达，帮助我们进行有效的UML 建模。
UML 提供的这些通用机制，贯穿于整个建模过程的方方面面。
前面我们提到，UML 的通用机制包括规格说明、修饰和通用划分三个方面。
第三章Rational 统一过程（11）1 ）角色活动产物工作流（12）2 ）逻辑视图过程视图物理视图开发视图用例视图（13）3）设计开发验证（14）4 ）二维（15）5）周期迭代过程里程碑（16） A B C D（17） A C D（18） A C D（19） A B C（20） A B C D（21）1 ）请描述迭代过程有几个阶段。
用例和用例图
访客用例图
会员用例图
书店管理员用例图
3、用例描述 （1）细化用例描述----搭框架
用例名称：搜索图书 概述：用户根据关键字搜索图书 前置条件：无 事件流： 基本事件流 扩展事件流 后置条件: 无
3、用例描述 （2）细化用例描述----填＂血肉＂
事件流： •基本事件流 1 用户点击“搜索图书”，用例开始。 2 系统显示搜索图书商品界面，提示用户输入商品关键字。 3 用户输入图书关键字，选择提交。 4 系统访问数据库，根据关键字查询相关的图书商品信息， 并把查询出的图书信息显示搜索图书页面。 5 用例结束。 •扩展事件流 4a) 系统未查出所要商品相关信息，显示提示信息，用例 结束。 4b) 系统查出用户输入的关键字为空，显示提示信息并返 回基本事件流2。
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制； 从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例
为系统和部分系统中单个的、可标识的、合理的原子行为 命名。 将多个用例的公共的行为抽取出来放到一个被包含用例中。 对于变化部分，将其抽取出来，放到扩展用例中。 清晰的描述事件流。
扩展关系（Extend）
扩展关系表示基本用例在由扩展用例间接说明的一个位置 上隐式的合并了另一个用例（扩展用例）的行为。 基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例的特点(1)
用例用于描述系统的功能，这个功能是外 部使用者看到的系统功能，不反映功能的 实现方式 储蓄系统
√ √ √ 开户
存款
取款 转帐
华南理工大学
12
软件需求分析与建模
用例的特点(2)
用例描述用户提出的一些可见需求，对应一 个具体的用户目标。 储蓄系统 √
参与者可以表示为下面三种形式。
华南理工大学
22
软件需求分析与建模
参与者之间的关系
参与者之间可以有泛化关系。
当几种执行者所扮 演的角色可以被 泛化时，可以定 义一个更抽象的 角色。 执行者是一个类,代 表一种角色,而不 是具体某个人
客 户
门 市 客户
华南理工大学 23
电 话 客户
软件需求分析与建模
执行者的泛化：责任重叠
华南理工大学 8 软件需求分析与建模
用例分析的目的
1. 描述和决定系统的功能需求，帮助客户 和软件开发人员形成一致意见。 2. 给出系统应该做什么且与内容一致的可 视化描述，使之成为在开发全过程中研讨 系统需求和进行系统设计的依据。 3. 在软件测试阶段作为系统测试的基础。 建立系统实现的各个对象类和系统操作与 功能需求之间的可追踪关系。
华南理工大学 9 软件需求分析与建模
用例的一些基本特点
从本质上讲，一个用例是用户与计算机之间 为达到某个目的的一次典型交互。以字处理 程序为例，“将某些正文臵为黑体”和“创 建一个索引”便是两个典型的用例。从这两 个例子中可以了解用例的一些特点： 用例描述了用户提出的一些可见需求； 用例可大可小 例：10人年的项目，20-100个用例 用例对应一个具体的用户目标
第一种表示
华南理工大学
30
软件需求分析与建模
《扩展》关系 类似于泛化关系，但添加了一些新规则 扩展用例可以在基用例之上添加新的行 为，但是基用例必须声明某些特定的 “扩展点”，并且扩展用例只能在这些 扩展点上扩展新的行为。
第二种表示
罚款 还书 扩展点： 书到期
《extend》
<<extend>>
执行者可以通过泛化关系 来定义，在这种泛化关系 中，一个执行者的抽象描 述可以被一个或多个具体 的执行者所共享
如系统中经理可以参加 雇员的所有用例
经理 用例C 用例A 雇员 用例B
华南理工大学
24
软件需求分析与建模
用例之间的关系(1)
用例之间可以具有以下几种关系：
1. 关联关系
2. 泛化关系
3. 包含关系
华南理工大学 5 软件需求分析与建模
用例Use Cases
用例：一组场景，用以共同描述用户的某个特定的目标。 例：购买商品用例 主场景：
顾客浏览货单并选择要买的商品 顾客来付款 顾客填写采购信息（地址、隔天或3天送货） 系统显示价目信息 顾客填写信用卡信息 系统检查信用卡的合法性 系统确认销售 系统给客户发出确认电子邮件
15
软件需求分析与建模
用例图举例（UML1.1）
设置边界 贸易经理 更新帐目
记帐系统 风险分析 交易估价 营销人员 进行交易 销售人员 《扩展》 超越边界 -扩展点：大交易量
16 软件需求分析与建模
《使用》 《使用》 评 价
执行者
用例
华南理工大学
用例图举例（UML1.3）
设置边界 贸易经理 更新帐目
包含关系 两个用例之间，一个用例(基本用例)的行为 包含了另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型来 表示。
华南理工大学
29
软件需求分析与建模
用例之间的关系(5)
扩展关系
扩展关系表示基本用例在扩展点要增加新的行 为或功能，以扩展到新用例。
扩展关系用依赖关系的<<extend>>构造型来表 示。
华南理工大学 10 软件需求分析与建模
对用例模型关心的人员
客户：他关心如何使用系统的功能；充当 模型中的哪一个角色；如何调整模型可以 更好地适应他们的愿望。
开发人员：他需要理解系统的功能，以作 为今后工作的基础和依据；在系统集成测 试期间，可以使用这些用例测试系统。
其他人员：销售人员，技术支持人员，文 档编写人员等也关心用例图。
4. 扩展关系
华南理工大学
25
软件需求分析与建模
参与者与用例之间的关系
关联关系 参与者与用例之间是关联关系，表示参与者 与用例之间具有使用，交互信息的关联。
华南理工大学
26
软件需求分析与建模
用例之间的关系(3)
泛化关系
参与者与参与者之间，用例与用例之间存在 一般与特殊的关系。
华南理工大学
27
软件需求分析与建模
华南理工大学
6
软件需求分析与建模
候选场景
候选场景：信用卡失效
第6步，系统检查信用卡失败。允许客户重 新执行第5步
候选场景：固定客户
3a. 系统显示当前购物信息、价格信息、信用 卡的最后四位数字 3b. 顾客接受或修改这些隐含值。转至主场 景的第6步
华南理工大学
7
软件需求分析与建模
什么是用例？ 用例模型的意义；
用例分析的目的；
用例的属性；
对用例图关心的人员。
华南理工大学
3
软件需求分析与建模
什么是用例？ 确定需求： 软件开发中的一个致命的问题 为此，各有关方面需要大量的交流，以 增进对需求的了解。 然而，对各方所关心的事情的描述却都 是粗糙的（非形式化）、口头的或是一 些杂乱的草稿，没有文档 怎样描述用户所关心的事情？ 用例是对（用户）所关心的事情的描述。
系统边界：一个提供“用例”所需要的功 能的“黑盒 子”。系统的外部特性由系 统的功能来定义；整个系统的功能用一组 用例来描述。 执行者：需要使用系统的任何外部实体(例 如：人、其它系统或外部设备等)。
用例：用客户或用户的语言和词汇来描述 的系统的一个完整功能。
华南理工大学 19 软件需求分析与建模
记帐系统 风险分析 交易估价 营销人员 进行交易 销售人员 《包含》 《包含》 评 价
执行者 泛化 用例
华南理工大学
超越边界
17
软件需求分析与建模
用例图中的图符（UML1.3）
《包含》Βιβλιοθήκη 用例泛化《扩展》 执行者 注释体 系统
关联
华南理工大学 18
注释连接
软件需求分析与建模
用例图中的模型元素：系统边界、执行者和用例
华南理工大学
39
软件需求分析与建模
对与外界系统交互问题的看法
与外界系统的所有交互都应在图中表达。例 如，为了给一笔交易进行估价需要访问银行， 则应在用例“交易估价”与“银行”之间建 立连接关系。
只有当某个外界系统会引发信息交互时，才 在系统中建立相应的外界系统。此时除非记 帐系统会通过某种方式要求本系统做某件事 时，才在图中显示记帐系统。
Print Crop Marks
华南理工大学
Print Diagram
建议采用第二种表示，注意箭头指向
31 软件需求分析与建模
扩展关系有一系列的扩展点名称，其个数 与扩展用例中的片断数相等。每个扩展点 必须在基用例中定义。 使用扩展关系如下图：
华南理工大学
32
软件需求分析与建模
华南理工大学
33
软件需求分析与建模
III 建立用例模型的主要工作
定义系统；
找出执行者；
找出用例；
描述用例；
用例的整理与加工；
验证模型。
华南理工大学
34
软件需求分析与建模
用例图的作用
用例图用来描述软件需求模型中的系统功 能，通过一组用例可以描述软件系统能够给用 户提供的功能。 用例图可以作为整个系统开发过程中的开 发依据，指导和驱动其他模型。
华南理工大学 42 软件需求分析与建模
一个执行者代表一个角色，执行一个类； 因此一个执行者的名字不应使用该执行者 的某个具体实例的名字。 一个人在系统中的角色可以被限定为一个 角色；但也可以担任不同的角色，充当不 同类的执行者。
华南理工大学
43
软件需求分析与建模
执行者与系统和用例之间的关系
执行者与系统之间的交流是通过收发消息。 一个简单用例总是由一个执行者通过发消 息的方法(刺激)创建；一个复合用例总是由 一个或若干个执行者通过发消息的方法(刺 激)创建。 当执行一个(简单的或复合的)用例时，它会 发一些消息给一个或多个执行者。
用例图中的模型元素(续1)：关联、使用和 扩展
关联：连接执行者和用例，表示该执行者 所代表的系统外部实体与该用例所描述的 系统需求有 关。这是执行者和用例之间 的唯一合法连接。 包含：由用例A连向用例B，表示用例A中 使用了用例B中的行为或功能。
扩展：由用例 A连向用例 B，表示用例B描 述了一项基本需求，而用例A则描述了该基 本需求的特殊情况，即一种扩展。
华南理工大学
40
软件需求分析与建模
III.2
找出执行者
执行者的主要属性； 执行者与系统和用例之间的关系； 执行者的获取； 对执行者的描述。
华南理工大学
41
软件需求分析与建模
执行者的主要属性
执行者是与系统有交互作用的实体(人或其 它系统等)，它在执行用例时与系统之间有 信息的交流。 执行者的重要性可以分级：主要角色(执行 主要功能，如负责保险注册和管理的职员) 和次要角色(执行次要功能，如负责系统维 护、数据库管理、复制备份和其它系统管理 等工作的职员)。 执行者有主动和被动之分：主动执行者创 建用例；被动执行者不创建用例。