第三章 用例和用例图(UML)
第3章 用例图
为了保证系统正常运行，谁将对系统进行维护管理
（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
用例和用例图ppt课件
精选课件
6
参与者间的关系
▪ 在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
▪ 示例：
父参与者
子参与者
子参与者
▪ 子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
▪ 子参与者可以出现在父参
与者能出现的任何位置上
精选课件
7
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
使用扩展关系 ▪ 扩展用例总是在一个或多个扩展点处来扩展基本用例，或
处于特定条件下， 才扩展基本用例。
基本用例
扩展点 扩展点名称
<<extend>>
扩展用例
精选课件
21
扩展关系
使用情形
a.两个用例相似但不完全相同时 b.当要对多个额外情况逐一建模时，使用扩展关
系，用一个独立的用例替代每个额外的情况 c.如果用例涵盖了所有的情况变化，则该用例将
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始，考虑每个参与者是如何使用系统的。
➢ 参与者要向系统请求什么功能？
➢ 每个参与者的特定任务是什么？
➢ 参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
➢ 是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
会变得十分复杂，应该考虑使用扩展关系
精选课件
22
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]
管理任务
UML用例和用例图
25
UML用例图的建模
1. 找出系统中的角色和用例。
2) 如何从系统中识别出用例 基于这些角色及其需求，通过回答前面的问题，可以建立如下用 例： 记录成绩（Record grades） 更新成绩（update grades） 生成报告卡（generate report cards） 检查报告卡（check report cards) 分发报告卡（distribute report cards ） 浏览成绩（view grades)
15
UML用例图组成
3、用例图的关联
2)用例与用例的扩展关联 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而 言，能不能导出、打印查询都是一样的，导出、打印是不可见的。 导入、打印和查询相对独立，而且为查询添加了新行为。因此可以 采用扩展关系来描述：
16
UML用例图组成
3、用例图的关联
19
UML用例图的建模
1. 找出系统中的角色和用例。
创建用例图的第一项任务是找出要建立的系统模型中的角色和用例。 这项任务通常是由与潜在用户会见的系统分析员完成的。在某些情况 下，该任务还包括与顾客面对面的访谈，在访谈中可以提出问题，了 解他们的需求。访谈过程中，可以多做些记录以备后用。在另外一些 情况下，其他人会提供项目的业务需求列表。对于这些业务需求，需 要向提供者提出一些问题以得到所需要的答案。这些需求和得到的答 案将成为创建用例图的笔记。
22
UML用例图的建模
1. 找出系统中的角色和用例。
1) 如何从系统中识别出角色
23
UML用例图的建模
1. 找出系统中的角色和用例。
2) 如何从系统中识别出用例 用例的获取是需求分析阶段的主要任务之一。但对于一个大系统， 要直接列出用例清单常常是十分困难的。这时可先列出角色清单， 再对每个角色列出它的用例，问题就会变得容易得多。在识别出 了角色之后，就可以通过回答下述问题来帮助识别用例:
用例和用例图
用例
用例(use case)是Ivar Jacobson发明的. 其它的中 文译名有: 用况、用案等. 定义1: 用例是对一个活动者(actor)使用系统的一项 功能时所进行的交互过程的一个文字描述序列. 定义2: 用例是系统、子系统或类和外部参与者交互 的动作序列的说明, 包括可选的动作序列和会出现 异常的动作序列. 用例是代表系统中各个项目相关人员之间就系统的 行为所达成的契约, 软件开发过程是用例驱动的.
实例1：图书馆管理系统中的用例图
1.确定系统涉及的总体信息 图书馆管理系统是对书籍的借阅及读者信息进行统 一管理的系统，具体包括读者的借书、还书，书籍 预订；图书馆管理员的书籍借出处理、书籍归还处 理、预订信息处理；还有系统管理员的系统维护， 包括增加书目、删除或更新书目、增加书籍、减少 书籍、增加读者账户信息、删除或更新读者账户信 息、书籍信息查询、读者信息查询等。
用例图的作用
用例图展示了用例之间以及用例与参与者之间是怎样相互联 系的。用例图对系统、子系统或类的行为进行了可视化，使 用户能够理解如何使用这些元素，并使开发者能够实现这些 元素。 用例图主要用来描述用户的功能需求。UML侧重从最终用户 的角度来理解软件系统的需求，强调谁在使用系统、系统可 以完成哪些功能。用例分析技术已经是一种公认有效的用户 需求获取、分析和描述技术
情况二：假如机票购买者通过呼叫中心，由人工座席 操作订票系统购买机票，那么谁是参与者？
情况三：如果机票购买者通过呼叫中心的自动语音预 定机票而不是通过人工座席，那么谁是参与者？
情况四：如果扩大系统边界，让呼叫中心成为机票预 定系统的一个子系统，并且假设机票购买者将可以 自主选择是通过人工座席还是自动语音登录网站预 订机票，那么谁是参与者？
UML实践----用例图、顺序图、状态图、类图、包图、协作图
UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者：Randy Miller 来源：网络面向对象的问题的处理的关键是建模问题。
建模可以把在复杂世界的许多重要的细节给抽象出。
许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处。
UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接。
而且每个部分都有一个小问题，测试一下你对这个部分的理解。
为什么UML很重要？为了回答这个问题，我们看看建筑行业。
设计师设计出房子。
施工人员使用这个设计来建造房子。
建筑越复杂，设计师和施工人员之间的交流就越重要。
蓝图就成为了这个行业中的设计师和施工人员的必修课。
写软件就好像建造建筑物一样。
系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。
在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。
现在它已经成为了软件行业的一部分了。
UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。
UML被应用到面向对象的问题的解决上。
想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。
一个模型model就是根本问题的抽象。
域domain就是问题所处的真实世界。
模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。
记住把一个对象想象成“活着的”。
对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。
对象的属性的值决定了它的状态state。
类Classes是对象的“蓝图”。
一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。
对象是类的实例instances。
用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。
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用例图是软件产品外部特性描述的视图，它从用户的角度而不是开发者的角度来描述软件产品的需求，分析软件产品所需的功能和行为。
用例图主要描述了系统需要实现的功能，而忽略系统是如何实现这些功能的。
用例模型由用例图组成，它是系统用例图的集合，是对系统从宏观角度的确定描述。
用例模型主要用于需求分析阶段，该模型是系统开发者和系统使用者反复讨论的结果，表明了系统开发者和系统使用者对需求规格达成的共识。
首先，用例模型描述了待开发系统的功能需求；其次，用例模型将系统看作黑盒，仅从外部执行者的角度来理解系统；再次，用例模型驱动了需求分析之后各阶段的开发工作，影响到开发工作的各个阶段和UML的各个模型。
一、用例图元素用例图主要用于定义系统的功能需求，它描述了系统的参与者与系统提供的用例之间的关系。
用例图由以下几种元素组成：执行者、用例、关系、用例描述（1）执行者执行者（Actor）是系统的外部用户，它是与系统相关联的人或其它系统，可以是普通用户、外部硬件、其他系统。
在进行用例图绘制时，首先要找出系统的执行者。
一般可以从以下几个方面来考虑怎样找到系统的执行者：????????????谁使用系统的功能。
?????????谁向系统提供必要的信息。
?????????谁从系统获取信息。
?????????谁维护、管理系统工作。
?????????系统需要使用哪些外部资源。
?????????需要与系统交互的其它系统有哪些。
?????????其他对系统产生的结果感兴趣的人或事物。
（2）用例用例是指系统中的一个功能单元，也可以将用例理解为系统功能的分解。
用例的表示方法如下：（3）关系（1）关联????在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。
UML中三种常用的图
1.用例图：用例图是从用户的观点描述系统的功能，它由一组用例、参与者以及他们之间的关系组成他将系统的一个功能描述成一系列事件，这些事件最终对参与者产生有价值的可观测结果参与者（Actor）：代表与系统交互的外部实体用例（Use-Case）：表示系统能提供的功能，如：登录，查询等关联关系：当参与者与用列进行交互时，用例与参与者之间有关联关系，用一条直线表示这种关系参与者之间可能存在泛化关系，类似的参与者可以用泛化关系组成一般与特殊的层析结构如：经理初次之外，用例之间还存在一定的关系，具体包括包含（include）、扩展（extend）、泛化（Generalization）等3种关系（1）包含关系一个复杂系统中，不同用例之间可能存在一些相同的行为，这时可将这些相同的行为提取出来单独组成一个用例。
当其他用例使用该用例时，用例之间便形成了包含关系包含关系用带关键字<<include>>的虚线来表示，虚线指向被包含的用例注册新用户（2）扩展关系在用例的执行过程中，可能会出现异常行为，也可能在不同的流程分支中选择执行，这时可将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成扩展关系扩展关系用带关键字<<extend>>的虚线表示，箭头指向被扩展的用例注册（3）泛化关系与参与者之间的泛化关系一样，用例之间的泛化关系是描述用例之间一般与特殊关系的，不同的子用例代表了父用例的不同实现方法。
密码找回2.类图类图描述系统的静态结构，表示系统中的类、类与类之间的关系以及类的属性和操作类用一个矩形方框表示，方框被分成3部分，最上面显示类名，中间部分显示类的属性，最下面显示类的操作类之间的关系包括关联、聚合、泛化、依赖等类型关联（Association）是一种结构定义，表达模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义链的描述，使用一条连接在两个类之间的实线表示，关系的每一端用数字表示关系的重数。
uml相关的名词解释
uml相关的名词解释UML（统一建模语言）相关名词解释简介：在软件工程中，统一建模语言（UML）是一种标准化的、通用的建模语言，用于描述和构建软件系统。
被广泛应用于软件开发过程中的需求分析、系统设计、代码生成等环节，UML具备描述问题领域、定义软件结构和行为的能力，以及促进开发者之间的交流和沟通。
本文将对与UML相关的一些关键名词进行解释与阐述。
1. 用例图（Use Case Diagram）用例图是UML中最常用的图形之一，用于描述系统与用户之间的交互。
用例图通过显示系统的功能和角色之间的关系，来帮助开发者理解和定义系统的需求。
用例图中的参与者代表系统的用户、外部组织或其他系统，而用例则代表系统的功能或交互场景。
用例图可以帮助团队更好地理解系统的需求，从而指导系统的设计和开发过程。
2. 类图（Class Diagram）类图是用于描述系统中的类、接口、关系和结构的图形化工具。
在类图中，类被表示为矩形框，类之间的关系以及类的属性和方法则通过箭头连接来表示。
类图可以帮助开发者理解、设计和组织系统中的类与对象之间的结构关系，从而更好地进行系统设计和编码。
3. 时序图（Sequence Diagram）时序图用于描述对象之间的交互，尤其是强调交互的顺序和时序逻辑。
时序图中的对象以及它们之间的消息传递被表示为垂直的时间轴和消息顺序。
时序图可以帮助开发者理解和描述系统中对象之间的交互过程，以及时间上的先后关系。
4. 活动图（Activity Diagram）活动图用于描述系统中的行为和流程，强调系统中的活动和动作。
活动图以节点和边的形式描述活动的流程和顺序，用于展示系统中各个活动之间的流转和控制。
活动图可以帮助开发者分析和设计系统中的流程，以及理解系统的行为逻辑。
5. 组件图（Component Diagram）组件图用于描述系统的组件和它们之间的关系，关注系统的组织结构和组件之间的依赖关系。
在组件图中，组件被表示为矩形框，组件之间的关系以及组件的接口则使用箭头表示。
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中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
UML用例和用例图
只书写“可观测”的
书写用例文档
——路径交互步骤的描述(2)
系统从会员处获取用户名和密码 会员提交用户名和密码 用户名和密码被验证 系统验证用户名和密码
使用主动语句
书写用例文档
——路径交互步骤的描述(3)
执行者××××× 系统××××× 系统××××× 执行者×××××
句子必须以执行者或系统作为主语
UML用例和用例图
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系 Use Case 分析技术 案例讲解
Use Case 定义
➢ 定义1：用例是对一个活动者(actor)使用 系统的一项功能时所进行的交互过程的一 个文字描述序列。
➢ 定义2：用例是系统、子系统或类和外部的 参与者（actor）交互的动作序列的说明， 包括可选的动作序列和会出现异常的动作 序列。
有足够库存 …….（后续描述省略）
主要内容
基本概念：Use case、Actor、Scenario
Use case间的关系 Use Case 分析技术 案例讲解
案例1：ATM系统
建立一个具有基本功能的ATM机软件
客户可以存钱，取钱 客户可以查询帐户余额 客户可以修改密码 客户可以进行转帐
需求建模—用例图
互图分析和类图分析必不可少的部分。
用例的描述
一般说来，用例采用自然语言描述参与 者与系统进行交互时双方的行为，不追求 形式化的语言表达（面向不同人员）。
用例描述的内容
用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径外，其他路径是什么 用例结束后的系统状态 其他需要：参与者是指系统以外的、需要使用系统 或与系统交互的东西，包括人、设备、外部系 统等。通过系统边界与系统进行有意义交互。
uml第03章 用例和用例图
3.8 用例的描述
ATM系统“取款”用例的两个错误描述： 系统“取款”用例的两个错误描述： 系统
Use case: Withdraw cash Actor: customer 主事件流： 主事件流： (1) 储户插入 储户插入ATM卡,并输入密码 卡 并输入密码 Use case: Withdraw cash Actor: customer 主事件流： 主事件流： • ATM系统获得 系统获得ATM卡和密码 系统获得 卡和密码
例：一个银行业务系统中的参与者 例：一个银行业务系统中的参与者 1. 客户：从系统获取住处并执行金融交易 客户： 2. 管理人员：创建系统的用户, 获取并更新信息 管理人员：创建系统的用户 3. 厂商：接受作为转账支付结果的资金 厂商： 4. Mail系统：与系统交互, 发送或接收邮件 系统：与系统交互 系统
右图的例子演示了 包含关系
注意: 箭头方向为基本用例到包含用例. 注意 箭头方向为基本用例到包含用例
14 面向对象分析与设计 & UML
3.4.2 包含关系
15
面向对象分析与设计 & UML
3.4.3 扩展关系
扩展关系的基本含义与泛化关系类似, 扩展关系的基本含义与泛化关系类似 但对扩展用例 有更多限制, 即基本用例必须声明若干”扩展点” 有更多限制 即基本用例必须声明若干”扩展点”, 扩展用例只能在扩展点上增加行为和含义. 扩展用例只能在扩展点上增加行为和含义 扩展关系是依赖关系版型. 扩展关系是依赖关系版型
例：在“订货”用例中包括几个相关脚本： 订货”用例中包括几个相关脚本： • 订货顺利进行的脚本 订货顺利进行的脚本; • 相关货源不足时的脚本 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本 购货者的信用卡被拒绝时的脚本; • ……
第3章 信息系统分析与设计 用例及用例图
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
● ② 确定各参与者所期望的系统行为。
第49页，共87页。
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
①.泛化关系 ②.包含关系 ③.扩展关系
第31页，共87页。
1. 泛化关系
参与者与参与者之间，用例与用例之间存在一般与 特殊的泛化关系。
第32页，共87页。
2. 包含关系
两个用例之间，一个用例(基用例)的行为要用到 另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型来 表示。
②.在基用例执行的过程中，被包含的用例一定要被执行；
扩展关系如果条件不为真，扩展用例可以不执行。
③.包含关系中的基用例必须依赖被包含的用例，它不能
独立存在；扩展关系中的基用例可以独立存在。
第37页，共87页。
3.6 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能，通 过一组用例可以描述软件系统能够给用户提供的功 能。
3. 参与者的表示 参与者可以表示为下面三种形式。
第23页，共87页。
4. 参与者之间的关系 参与者之间可以有泛化关系。
第24页，共87页。
5. 参与者的特性 参与者具有以下特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系 ③.参与者与系统之间存在交互接口
第25页，共87页。
3.4 参与者与用例之间的关系
3.5 用例之间的关系 3.6 用例图
uml用例与用例之间的关系
UML用例与用例之间的关系1. 引言在软件系统开发过程中，需求分析是一个至关重要的环节。
用例是一种常用的需求表示工具，用来描述系统与用户之间的交互过程。
用例图是一种在统一建模语言（UML）中常用的图形化表示工具，它能够清晰地描述不同角色之间的交互以及系统的功能。
在用例图中，用例之间存在着不同的关系，这些关系能够帮助我们更好地理解和分析需求，从而有助于正确地设计系统。
2. 用例与用例之间的关系用例与用例之间的关系主要体现在用例图中的连接关系，以下是用例与用例之间可能存在的几种关系：2.1 包含关系（include）包含关系描述了一个用例（被包含用例）在执行过程中调用了另一个用例（包含用例）的场景。
被包含用例是包含用例的一部分，它们之间有一个可选的包含关系，即被包含用例可以选择是否执行包含用例。
包含关系在用例图中用带箭头的虚线表示。
举例来说，如果一个系统中有一个支付用例和一个生成订单用例，那么支付用例可以调用生成订单用例来创建订单。
但是在某些情况下，比如采用现金支付时，生成订单用例就可以不执行，所以这个关系是可选的。
2.2 扩展关系（extend）扩展关系描述了一个用例（扩展用例）在某个基本场景（基础用例）的执行过程中可以选择性地插入另一个场景（扩展用例）。
扩展关系使得系统的功能可以按需进行扩展，而不会影响基础用例的执行。
扩展关系在用例图中用带箭头的虚线表示。
以在线购物系统为例，基础用例是购物，而扩展用例可以是添加到购物车、查看商品详情等。
这些扩展用例可以根据用户的需求来选择性地应用，从而实现购物功能的扩展。
2.3 泛化关系（generalization）泛化关系描述了一个用例（子用例）继承了另一个用例（父用例）的属性和行为。
子用例可以复用父用例的功能，并在其基础上进行扩展或修改。
泛化关系在用例图中用带空心箭头的实线表示。
例如，一个系统有多种角色，比如管理员和普通用户，它们都可以登录系统，所以可以有一个登录用例作为父用例，而管理员登录和普通用户登录可以作为子用例，从而实现用例的复用。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
第三章 用例和用例图
系统边界
… 参与者透过系统边界直接与系统交互，参与者的确定代表
系统边界的确定
有意义交互
任何事物
人、外部系统、外部因素等
武汉大学国际软件学院
12
3.2.2 识别参与者：参与者要点
•
参与者指在系统中所扮演的角色。即在确定参与者时， 应主要考虑他的角色，而不是这个角色的实例。
•
• • •
某些组织中可能有很多营销人员，但他们均起着同 一种作用，扮演着相同的角色。 … 一个用户也可以扮演多种角色：一个高级营销人员
经理
用例C
•
如系统中经理可以参加雇员 的所有用例
武汉大学国际软件学院
21
3.2.2 识别参与者：泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
武汉大学国际软件学院
22
3.2.3 识别用例（use case） 分析典型用例是开发者准确迅速地了解用户要求的最常用 也是最有效的方法，是用户和开发者一起深入剖析系统功 能需求的起点。 “用例”是Ivar Jacobson于20世纪60~70年代在爱立信公 司开发AKE、AXE系列时发明的。
武汉大学国际软件学院
29
用例要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
武汉大学国际软件学院
30
用例 VS. 功能
•呼叫某人
•传输/接收 •电源/基站 •输入输出（显示、键盘） •电话簿管理 •……
•接听电话
•发送短信 •记住电话号码
•…… 用户观点
第3章用例和用例图
3.1 用例
用例(use case)是Ivar Jacobson发明的. 其它的中文译 名有: 用况、用案等. 它是站在用户的角度看待系统、 定义系统 ；使用用户能够看懂的语言来表述
定义1: 用例是对一个活动者(actor，角色，参与者)使用 系统的一项功能时所进行的交互过程的一个文字描述序 列. 定义2: 用例是系统、子系统或类和外部参与者交互的动 作序列的说明, 包括可选的动作序列和会出现异常的动 作序列. 用例是代表系统中各个项目相关人员之间就系统的行为 所达成的契约, 软件开发过程是用例驱动的.
18
面向对象分析与设计 & UML
3.4.1 泛化关系
泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子 用例也可以增加新的行为和含义或覆盖父用例中的行 为和含义.
右图的例子演示了 泛化关系
19
面向对象分析与设计 & UML
3.4.1 泛化关系
•
可以用来表示参与者与参与者之间，用例与用例之间的 特殊/一般化关系
33
面向对象分析与设计 & UML
3.6 用例的描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了主路径外, 其它路径是什么 用例结束后系统的状态 其它需要描述的内容
描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
柜员机系统中，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在 开发IC卡门禁系统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
用例和用例图
如何绘制用例图 1、用例分析技术步骤（不固定，可根据需要调整）：
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ 找出系统外部的参与者和外部系统，确定系统的边界和范围。 确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 编制每一个用例的脚本 绘制用例图 区分基本事件流和异常情况的事件流，如有需要可以把表示异常 情况的事件流作为单独的用例来处理 ⑻ 细化用例图，解决用例间的重复与冲突。
用例之间的关系 4、参与者与用例之间的关系：关联关系Association
关联关系描述参与者与用例之间的关系，在UML中它是 两个或多个类元之间的关系，它描述了类元的实例间的 联系。(类元，一种建模元素，常见类元包括类、参与者 、构件、数据类型、接口、结点、子系统以及用例等， 其中类是最常见的类元) 关联关系表示参与者和用例之间的通信。在UML中，关 联关系用直线或箭头表示。如果参与者启动了用例，箭 头指向用例；如果参与者利用了用例提供的服务,箭头指 向参与者。如果二者是互动的，则是直线。 例：汽车租赁系统用例图(部分)。显示的是“客户”参与者以 及与他交互的3个用例，“预定”、“取车”、“还车” 。
FEAT01.新增书籍信息 FEAT03.书籍信息按计算机类、非计算机类分别建档 FEAT04.录入新书时能够自动按规则生成书号 FEAT05.计算机类与非计算机类书籍采用不同的书号规则 FEAT06.录入新书时如果重名将自动提示 FEAT02.修改已有的书籍信息 FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍 FEAT08.列出所有书籍信息 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT09.记录外借情况 FEAT10.外借状态能够自动反应在书籍信息中 FEAT11.按人、按书查询外借情况 FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行 FEAT13.按特定时间段统计购买金额、册数 FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行
《面向对象分析与设计UML》课程教学大纲
《面向对象分析与设计(UML)》课程教学大纲一、课程与任课教师基本信息二、课程简介《面向对象分析与设计(UML)》是一门是软件工程专业重要的、实践性很强的一门必修课。
UML是一种定义良好、易于表达、功能强大且适用于各种应用领域的建模语言，已被OMG采纳为标准。
目前UML已成为面向对象技术领域内占主导地位的标准建模语言。
掌握UML 语言，不仅有助于理解面向对象的分析与设计方法，也有助于对软件开发全过程的理解。
通过该课程的学习，使学生能基本掌握面向象技术基本概念和面向对象分析与设计方法，能够使用UML 语言来进行初步的系统分析与设计。
三、课程目标结合专业培养目标，提出本课程要达到的目标。
这些目标包括：1．知识与技能目标通过本课程的学习，使学生掌握面向对象分析与设计基本理论和使用统一建模语言（UML）实现软件生命周期模型的六大阶段（需求分析，概要设计，详细设计，编码，测试，维护）的一般性原理、主要思想、关键技术；了解和掌握各阶段的规范文档书写格式，通过实验项目实践活动，培养学生理解和应用相关的知识技能，开发软件项目。
2．过程与方法目标了解面向对象分析与设计的发展历史及趋势，掌握运用UML 理论及方法解决实际问题的分析步骤。
通过具体方法的学习与运用，理解它们的优势与不足，从而锻炼和提高思维分析能力（归纳能力，演绎能力，对比分析能力，变通能力，总结能力，抽象能力）。
3．情感、态度与价值观发展目标通过本课程的学习，培养作为一个软件工程技术人员必须具备的坚忍不拔的学习精神，严谨治学的科学态度和积极向上的价值观念，为未来的学习、工作和科研奠定良好的理论基础和实践基础。
四、与前后课程的联系本课程是软件工程专业的重要专业课程。
其内容是软件测试概论、软件质量保证与管理、软件需求工程、小组软件工程、软件测试管理及工具、软件配置管理及工具等后续课程的基础，对学好上述后续课程的影响很大。
五、教材选用与参考书1．选用教材《面向对象分析与设计(UML)》，侯爱民、欧阳骥、胡传福编著，清华大学出版社，2015 年，第1 版。
UML系统用例及用例关系.ppt
用户 收邮件
时间
提醒新邮件
下一讲内容
用例规约
历史ⅱ岳麓版第13课交通与通讯 的变化资料
精品课件欢迎使用
[自读教材· 填要点] 一、铁路，更多的铁路 1．地位
铁路是
交通运输 建设的重点，便于国计民生，成为国民经济
发展的动脉。 2．出现 1881年，中国自建的第一条铁路——唐山 路建成通车。 1888年，宫廷专用铁路落成。 至胥各庄铁 开平
统一建模语言
11软件工程
CH4 用例图 系统用例及用例关系
知识回顾—需求获取
需求工程
需求管理
需求开发
问题获取
分析
编写规格说明
验证
教学目标
掌握用例图的地位作用及定义
重 点 掌握用例图模型元素 能够根据需求分析使用用例图建模
难 点
确定用例及用例间的关系
教学内容
用例图建模应用 用例图 需求获取
需求获取及分析 需求的基本方法 什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的各种重 要关系 识别参与者 确定用例
客户
商业客户
个体客户
用例1
定义：Use Case 用例表示系统的一项外部
用例
功能，它从用户的角度分析 所得的需求。为完成一个相 对完整的一种功能，系统执 行的一系列动作的集合
是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作
用例2
用例捕获某些角色可见的需求，实现 一个具体的角色需求 用例由其用户角色使用，并提供确切 的输出给角色 用例可大可小，但它必须是对一个具 体的角色目标实现的完整描述 用例的动态执行过程可以用UML的交互 作用来说明，可以用状态图、顺序图、 协作图或非正式的文字描述来表示
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例和用例视图
3.3 用例间的关系
泛化（generaliaztion）关系
例：学校查询系统
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
35
用例和用例视图
3.3 用例间的关系
36
用例和用例视图
3.3 用例间的关系
包含（include）关系
例：学校信息系统中的修改个人信息、删除个人 信息、查看个人信息三个事件
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
37
用例和用例视图
3.3 用例间的关系
扩展（extend）关系
扩展关系是把新行为插入到已有用例（基础用例） 的方法。基础用例提供了一组扩展（Extension Point）点，在这些扩展点中可以添加新的行为， 而扩展用例提供了一组插入片段，这些片段能够 插入到基础用例的扩展点。
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
5
用例和用例视图
3.1 用例
用例的表示：
在UML中,用例表示为一个椭圆。下面是一些 简单的用例。“设置边界”,“评价贸易”,“更 新帐目”等都是用例的实例。用例名一般为动宾 结构 或者主谓结构
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
•把商品移送到销售部门
•销售部门把商品移送到仓库
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 19
用例和用例视图
3.1 用例
仓库管理信息系统的用例模型(续)
•管理员盘点仓库
•供应商提供各种货物
•用户查询销售部门的营销记录
•用户查询仓库中的所有变动记录
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
3.3 用例间的关系
泛化（generaliaztion）关系
泛化代表一般与特殊的关系，在OOA/OOD中用 的比较多。子用例表示父用例的特殊形式，子用 类从父用例出继承行为和属性，还可以添加行为 或覆盖、改变已继承的行为。和类间的泛化关系 比较接近。
表示方式：用带空心箭头的实线表示，由子用例 指向父用例
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
31
用例和用例视图
3.2 脚本
脚本指贯穿用例的一条单一路径，用来显示 用例中的某种特殊情况.(也有些书籍叫情景、场 景、情节、剧本等) 脚本由一个主要脚本和多个次要脚本组成。
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
包含（include）关系
包含（include）关系指一个用例（base use case）的行为包含了另一个用例（inclusion use case）的行为。是一种特殊的依赖关系。 表示方式：用带虚线的实心箭头表示，有基本用 例指向包含用例
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
一个用例可能有多个扩展点，每个扩展点也可以 出现多次。 由基础用例指向扩展用例
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 38
用例和用例视图
3.3 用例间的关系
扩展（extend）关系
例：图书馆信息系统
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
32
用例和用例视图
3.3 用例间的关系
用例除了与参与者发生关联外，还可以与系 统的其他部分存在泛化（generaliaztion）关系、 包含(include)关系、扩展(extend)关系.
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
33
用例和用例视图
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 9
用例和用例视图
3.1 用例
参与者：指系统以外的、需要使用系统或与 系统交互的东西。 参与者的表示形式
《Actor》 《Actor》
LaWUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
用例和用例视图
3.1 用例
案例1： 图书管理系统的用例模型 •图书馆工作人员 •读者 •图书馆管理系统维护人员
图书管理系统的参与者：
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
12
用例和用例视图
3.1 用例
案例1： 图书管理系统的用例模型 •还书 •借书 •预留书籍 •取消预留书籍
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 14
用例和用例视图
3.1 用例
案例1： 图书管理系统的用例模型
工作人员登录查询信息的用例说明：
•书籍归还 •书籍借阅处理 •删除书籍预定信息 •还书超期收取罚金 •核对读者借阅凭证
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 15
辅助事 件 2
用例和用例视图
Note:思考的问题: 1.什么是用例和参与者 2.是不是人才是参与者
3.用例图能描述完成的需求吗?
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
3
用例和用例视图
3.1 用例
从本质上讲,一个用例是用户与计算机之间的 一次典型交互作用。 以字处理软件为例,“将某些正文置为黑体” 和“创建一个索引”便是两个典型的用例。
在UML中,用例被定义成系统执行的一系列动 作,动作执行的结果能被指定执行者察觉到。
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
4
用例和用例视图
3.1 用例
用例的两种定义：
定义一：用例是对一个活动者（actor）使用系统 的一项功能时所进行的交互过程的一个文字描述 序列。 定义二：用例是系统、子系统或类、和外部的参 与者(actor)交互的动作序列说明，包括可选的动 作序列和会出现异常的动作序列。
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
22
用例和用例视图
3.1 用例
仓库管理信息系统的用例 •仓库进货 •仓库退货 •仓库领料 •仓库退料 •商品调拨 •仓库盘点 •库存查询 •业务分析 •仓库历史记录查询 •供应商信息维护 •仓库信息维护 •用户登陆 •用户注销 •退出系统
系统管理员的用例图
删除或更新读者信息
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 18
用例和用例视图
3.1 用例
案例2:仓库管理信息系统的用例模型
通过与系统用户的勾通，需求分析师可以把 该软件系统要实现的功能归结为以下几个问题：
•购买新商品入库
•积压商品退给供应商
用例和用例视图
3.1 用例
参与者：指系统以外的、需要使用系统或与 系统交互的东西。 参与者通过向系统输入或请求输入对某些事 件来触发系统的执行。包含了人、设备、外部系 统等
Note: 1、一个参与者可以执行多个用例 2、一个用例可以有多个参与者使用 3、参与者不是系统的一部分，但是也有继承和泛化关系
39
用例和用例视图
3.3 用例间的关系
泛化关系、包含关系、 扩展关系的使用范围
当处理正常行为的变型，而且只是偶尔描述时， 一般用泛化关系
在包含关系中，如果执行了基本用例，就必须执 行包含用例，如果要重复处理两个或多个用例时， 可以考虑使用包含关系，实现一个基本用例对另 一个用例的引用
7
用例和用例视图
3.1 用例
在识别用例的过程中，通过以下几个问题可 以帮助识别用例： （1）、特定参与者希望系统提供什么功能 （2）、系统是否存储和检索信息，如果是， 这个行为由哪个参与者触发 （3）、当系统改变状态时，通知参与者吗？
（4）、存在影响系统外的事件吗？
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING 8
第三章 用例和用例图
教学目标:了解用例间的各种关系，熟悉用 例描述 教学要求:能建立简单用例
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
1
用例
包含关系
泛化关系:表明一般和特 殊的关系 用例和用例视图
关联关系
参与者
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
20
用例和用例视图
3.1 用例
仓库管理信息系统的用例模型(续)
操作的分类：
•仓库信息的管理 •仓库信息的维护 •各种信息的分析查询
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
21
用例和用例视图
3.1 用例
仓库管理信息系统的用例模型
参与者：
•操作员 •管理员 •供应商 •商品领料人 •商品退料人
23
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING
用例和用例视图
3.1 用例
仓库管理信息系统的用例图
退出系统
业务分析
24
WUHAN UNIVERSITY OF SCIENCE AND ENGINEERING