当前位置：文档之家 › 软件建模技术第6章用例图讲义

软件建模技术第6章用例图讲义

  • 格式：ppt
  • 大小：2.62 MB
  • 文档页数：47

下载文档原格式

  / 47

合集下载

04 第六章 用例图

04 第六章 用例图
第六章 用例图
主讲：XXX
本1
章 内
2
容3
4
5
6
用例图基本概念 用例图构成要素
用例的重要元素 用例之间的关系 使用Rose创建用例图 使用Rose创建用例图的步骤说明
6.0 用例图有什么用？
6.0 用例图有什么用？
1 软件行业现状
超预算
平均超出费用: 189%
推迟发布
平均超出时间: 222%
1. 参与者希望系统提供什么功能？ 2. 系统是否存储和检索信息，如果是，由哪个参与者触发？ 3. 当系统改变状态时，是否通知参与者？ 4. 是否存在影响系统的外部事件？ 5. 哪个参与者通知系统这些事件？
也可以通过一些与参与者无关的问题来发现用例。 同时注意，用例实际上描述的是系统需求，需要仔细、反复
要在用例图上显示某个用例，可绘制 一个椭圆，然后将用例的名称放在椭 圆的中心或椭圆下面的中间位置。
要在用例图上绘制一个参与者（表示 一个系统用户），可绘制一个人形符 号。
6.1 用例图基本概念
1 用例图的含义
参与者和用例之间的关 系使者和被动接受者
要得到正确的需求至少存在两个难 点：
1. 难以捕获； 2. 容易改变。
6.0 用例图有什么用？
4 从用例（图）开始
用例图是需求分析阶段的结果，是可视化描述软件系统功能 需求的重要方法。
用例图是从客户需求自然语言描述中得出的，是软件系统开 发的起点。
此外，用例图是全体开发人员沟通、开发系统功能的准确交 流途径。
第六章 用例图
6.1 用例图基本概念
用例图是Jacobson在1992年最先提出的， 它通过用例（Use Case）来捕获系统需求，再 结合参与者（Actor）进行系统功能需求的分 析和设计。

UML中文课件-用例图类图对象图包图

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 类图的构建步骤
类图的构建步骤 一个关于图书馆图书借阅管理的类图 一个实现旅游宾馆预订的类图

第6章UML用例图

第6章UML用例图

构建结构良好的用例图应做到：摆放元素时，应该避 免交叉线的出现；对于语义上接近的行为和角色，最 好使它们在物理上也更加接近；根据系统实际情况控 制粒度。
25
6.10 小
结
本章详细地阐述了参与者和用 例的概念，结合“ATM系统” 的用例图，讲解了系统边界、 包含关系、扩展关系以及泛化 关系，并在此基础上介绍了用 例描述的方法、格式及相关的 要点。
2
第6章 用 例 图
用例图描述了外部参与者所能 观察到的系统功能的模型图。
该图呈现了一些参与者和一些 用例，以及它们之间的关系。 用例图主要用于对系统、子系 统的功能行为进行建模。
3
6.1 什么是用例图
1．用例图
2．用例图的作用
3．用例图的组成元素
4
6.2 参与者与用例
多个用例组成一个系统， 参与者是系统外部的一个实 体，它以某种方式与系统交 互，请求系统执行用例，以 获得参与者需要实现的目标。
9
6.4 用例之间的关系
在需求分析时，当标识出参与者后， 下一步就是识别用例、组织用例。所 谓组织用例，就是首先识别用例之间 的关系，使系统中的用例构成一个用 例图。
UML有3种用例关系：包含、扩展和 泛化。下面将详细讨论这3种关系。
10
6.4.1 包含关系
在开发用例模型的过程中，我们会发现一些用 例包含了相同的一些行为；一些用例与其他用 例比较，多出了一些额外的行为。如图6-7所示， “取款”、“存款”、“查询余额”3个用例都 要求用户登录到ATM系统。
8
6.3.2 参与者之间的泛化关系
参与者是一种类，因此，可以 将参与者之间的关系进行泛化。 通过参与者泛化可以简化模型， 使模型更简洁。 例如，在软件系统开发过程中， 系统分析师(子类)和项目经理 (子类)都属于系统设计师(父 类)，他们都能承担系统设计 师的工作。用UML图表示他 们之间的关系，如图6-6所示。

第6章 用例图

第6章 用例图
• 图6-５ 参与者是泛化关系 • 对于参与者而言，泛化关系的引用可以有效地降低模型的复杂度。例
如：在图6－1所示的用例图中，我们希望引入一个“迎宾员”的角色， 并且为了缓解总台服务员的压力，希望让迎宾员也能完成“安排座位” 的职责，那么就可以通过泛化来更有效地组织这个用例图。 • 图6－6表述了：总台服务员是一种“特殊”地迎宾员，它不仅可以安 排座位，还能够办理结帐。 • 图6-6 参与者泛化
•图6-3 小刘取款场景
14
6．4 用例图的表示
• 开发者获取需求的步骤是：第一步，开发者首先将用户的工作流程表 示为场景，然后，将同一类场景抽象为用例，以描述系统的功能；第 二步，客户和用户通过审查场景，并测试开发者提供的原型系统，以 验证和确认需求规格说明书。第三步，当系统需求定义成熟和稳定后， 开发者和客户共同对需求规格说明进行确认，包括，系统的功能性需 求、非功能需求、用例和场景在内的需求确认。
统，定义系统．三种需求技术的特点见表6-1所示。
•表6-1 三种获取需求的技术
需求技术 描述 种类
用例(Use case)
描绘一个系统外在可见的需求情况，是代表系统中各个项 目相关人员(风险承担人，Stakeholder)之间就系统的行 为所达成的契约
用户故事 (user
story)
由客户参与编写，说明他们需要系统为他们做什么，一般 用客户的术语编写，其长度约为三句话左右
11
6．4 用例图的表示
• 按参与者重要性分： • 与某个用例交互的参与者可能有多个，按参与者对用例的重要性分为
以下两类： • 1）主要参与者：从系统获得可度量价值的用户，他的需求驱动了用
例所表示的行为或功能。 • 2）次要参与者：在系统中提供服务，并且不能脱离主要参与者而存

第6章(2)PIM建模技术资料

第6章(2)PIM建模技术资料
– PSM
Warm up: Use Case & Use Case
Realization
• Use Case是描述需求的工具，把系统看做黑盒子。 • Use Case Realization在分析设计阶段做，不在视系统
为黑盒子，而是白盒子。
– 用分析和设计出来的类及它们之间的Collaboration来描述系统 如何完成Use Case。
– 指南：推荐的做法，在其解释、实施或使用中，允许有一定 的自由度或回旋余地。
• 10.把用例规约中的路径直接粘贴在鲁棒图的左边，以 便一一对应，逐项对象化；
• 9.直接利用域模型中的业务对象实体；
– 也用鲁棒图补充和完善域模型
• 8.在画鲁棒图时，要完善用例规约(去掉歧义)
– 画鲁棒图迫使作者逐句斟酌用例规约
• 鲁棒图示例 • 初步设计审核
– 目的与参与者 – 初步设计审核指导原则、指南和常犯的错误
• 软件体系结构及其模式*
– 体系结构风格、设计原则与常见错误 – 鲁棒图与MVC模式 – 新课程：软件体系结构
Warm up:Analysis and Design
• Design
– Realization of a concept or idea into a model or specification
• 分析模型和设计模型最早在Jacobson的OOSE中提出 来了，并非RUP首创。这两个模型的本质差别在于：
– 分析模型是对问题域的描述，独立于实现技术。 – 设计模型在使用具体技术实现分析模型。设计模型可以立即
拿去实施。 – 区分两种模型的目的：当实现技术改变时，重用分析模型。
• 基础：问题域不会如计算机技术发展得那么快。

UML-6用例图

UML-6用例图

用例名 用例名 扩展点 扩展点名
用例名 扩展点
…
图6.4 用例的表示图形
Home
用例图 用例图
按照抽象层次，用例图可以划分为系统层（最高层）、 按照抽象层次，用例图可以划分为系统层（最高层）、 图可以划分为系统层 子系统层和对象类层（最低层）。 子系统层和对象类层（最低层）。 系统层用例图描述系统提供的全部服务。 用例图描述系统提供的全部服务 系统层用例图描述系统提供的全部服务。 子系统层用例 描述子系统提供的服务， 用例图 子系统层用例图描述子系统提供的服务，它的外部交互 者可以是其他的子系统或高一层的参与者。 者可以是其他的子系统或高一层的参与者。子系统层又 可以划分为多个层次。 可以划分为多个层次。 对象类层的用例 描述对象类提供的功能片或操作， 用例图 对象类层的用例图描述对象类提供的功能片或操作，它 的外部交互者可以是其它对象类或高一层参与者。 的外部交互者可以是其它对象类或高一层参与者。 自顶向下不断精化， 在系统的开发过程中，用例图可以自顶向下不断精化 在系统的开发过程中，用例图可以自顶向下不断精化， 抽象出不同层次的用例图。 抽象出不同层次的用例图。
Home
6.2.2 参与者
参与者运行用例，获得系统的某项服务。一个参与者可 参与者运行用例，获得系统的某项服务。 以运行多个用例，而一个用例可以由多个参与者运行。 以运行多个用例，而一个用例可以由多个参与者运行。 一个参与者与其他的参与者可以有泛化联系， 一个参与者与其他的参与者可以有泛化联系，即一个参 与者可以继承一个更一般的参与者的特性。 与者可以继承一个更一般的参与者的特性。 参与者的图形表示如图6.3所示 所示。 参与者的图形表示如图 所示。
Home
6.3 用例
6.3.1 用例的描述 81 6.3.2 用例与脚本 82 6.3.3 用例间的关系 83

第6章 用例图


•
基用例是可以独立于扩展用例存在的，只是在特定的条件下， 基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的 行为可以被另一个用例的行为所扩展
作者：冀振燕 《UML系统分析与设计教程》
23
泛化关系
作者：冀振燕 《UML系统分析与设计教程》
24
6.2 用例图建模技术
6.2.1 对语境建模 6.2.2 对需求建模
前置条件 后置条件 成功保证 基本事件流
[即启动该用例所应该满足的条件。] [即该用例完成之后，将执行什么动作。] [描述当前目标完成后，环境变化情况。] 步骤 1 2 活动 [在这里写出触发事件到目标完成以及清除的步骤。] ……(其中可以包含子事件流，以子事件流编号来表示) [1a表示是对1的扩展，其中应说明条件和活动] ……(其中可以包含子事件流，以子事件流编号来表示)
19
泛化关系
父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为 或覆盖、改变继承的行为。
作者：冀振燕 《UML系统分析与设计教程》
20
作者：冀振燕 《UML系统分析与设计教程》 含扩展和使用关系的用例图
21
• 图中的元素包括：参与者、用例、一个方框和一些表 图中的元素包括：参与者、用例、 • 所有的用例都位于方框之内，该方框称为“系统边界” 所有的用例都位于方框之内，该方框称为“系统边界” • 参与者与用例的关系：在参与者和用例之间的关联是 参与者与用例的关系： • 用例之间的关系： 用例之间的关系：
作者：冀振燕 《UML系统分析与设计教程》
14
例：新增图书用例
…… 3.事件流： 3.1 基本事件流 1）图书管理员向系统发出“新增书籍信息”请求； 2）系统要求图书管理员选择要新增的书籍是计算机类还 是非计算机类； 3）图书管理员做出选择后，显示相应界面，让图书管理 员输入信息，并自动根据书号规则生成书号； 4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、 开本、页数、定价、是否有CDROM； 5）系统确认输入的信息中书名未有重名； 6）系统将所输入的信息存储建档。 3.2 扩展事件流 5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理 …… 选择修改书名或取消输入； 5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2）图书管理员选择修改书名后，转到5） 4.非功能需求：无特殊要求 ……

用例图和类图课件

用例图中可以包含类图作为其组成部 分，用于描述用例中涉及的类及其关 系。
用例图和类图的区别
侧重点不同
用例图强调系统功能需求的描述 ，而类图更注重系统结构的描述
。
表达内容不同
用例图展示系统与外部实体的交互 ，而类图展示类的属性和方法。
适用阶段不同
用例图通常在需求分析阶段使用， 而类图在设计和实现阶段更为常用 。
StarUML
StarUML 是一个开源的、功能强大的 UML 工具，支持 多种类型的图表，包括用例图和类图。它提供了丰富的模 型元素库和灵活的定制功能。
建模技术介绍
用例驱动开发（UDD）
用例图是 UDD 的核心组成部分，用于描述系统的功能需求和行为。通过用例图，开发团队可以更好 地理解系统的需求，并确保开发出的系统满足用户的需求。
案例二：银行系统用例图和类图设计
总结词
详细描述了银行系统的用例图和类图设计， 包括用户登录、账户管理、转账和查询等用 例，以及对应的类图设计，如用户类、账户 类、交易类和查询类等。
详细描述
银行系统是一个复杂的软件系统，其用例图 设计需要考虑用户登录、账户管理、转账和 查询等核心功能。在类图设计中，需要定义 用户类、账户类、交易类和查询类等，并明 确它们之间的关系。通过用例图和类图的设 计，可以更好地理解银行的业务需求和业务
CHAPTER
类图基础
类图的定义
类图是用于描述系统中类以及类与类 之间关系的图形表示法。
类图是一种静态结构图，用于描述系 统中的类以及它们之间的关系。在类 图中，类被表示为矩形，而类之间的 关系则通过不同的线条来表示。
类图的用途
类图主要用于帮助开发人员理解和管理复杂系统中的对象和 它们之间的关系。

第6讲 用例图


UML建模与系统设计
三、用例的重要元素
4、用例
以前接触过的用例？ 用于需求的发现、记录及展示 简单示例： 登录系统：管理员向用户提交用户名和密 码，系统进行认证，系统向管理员显示登录成 功。 场景：是参与者和系统之间一系列特定的 活动和交互。
UML建模与系统设计
三、用例的重要元素
4、用例
用例的目地： 强调用户的目标与观点，除了表达功能外还表 达了场景。 用例编写的形式： 摘要：需求分析早期使用，通常用于主场景 非正式：早期使用，可覆盖不同的场景 详细：详细编写所有步骤及各种变化 用例的名称以动词开头 编写用例时尽量使用行业术语，不要用计算机 术语。
UML建模与系统设计
三、用例的重要元素
4、识别用例
任何用例都不能在缺少参与者的情况下独 立存在。同样，任何参与者也必须要有与之关 联的用例。所以识别用例的最好方法就是从分 析系统参与者开始，在这个过程中往往会发现 新的参与者。
UML建模与系统设计
三、用例的重要元素
4、识别用例
可以通过以下问题来寻找用例： 1 参与者希望系统提供什么功能？ 2 参与者是否会读取、创建、修改、删除、 存储系统的某种信息？如果是的话，参与者又 是如何完成这些操作的？ 3 参与者是否会将外部的某些事件通知给 系统？ 4 系统中发生的事件是否通知参与者？ 5 是否存在影响系统的外部事件。
UML建模与系统设计
四、用例之间的各种重要关系
3、泛化 泛化的示例：银行存款有两种方式，一种是银行柜台存 款，一种是ATM机存款。在这里，银行柜台存款和ATM机存款 都是存款的一种特殊方式，因此“存款”为父用例，“银行 柜台存款”和“ATM机存款”为子用例。
UML建模与系统设计
小结

第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. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

３、用例---Use Case
系统、子系统或类与外部的参与者（actor） 交互的动作序列的说明，包括各种序列及 出错序列。
用例分析可以认为是对系统功能的分解。
存款
Withraw Money
３、用例---Use Case
（1）用例的表示 简单名 路径名
３、用例---Use Case
４、关系--Relationship
四种基本关系： 关联（association） 包含（include） 扩展（extend） 泛化（generalization）
（1）关联
描述参与者与用例之间的关系； 用单向箭头，表示谁启动用例； 每个用例都有角色启动，除包含和扩展 用例；
6.2 用例图的组成
系统边界 参与者（活动者，Actor） 用例（Use Case） 关系（Relationship）

棋牌馆管理系统用例图
1、系统边界（主体）
系统边界是定义由谁或什么（即，参与者） 使用系统，系统能够为哪些参与者提供什 么特定利益（即，用例）。
系统边界在UML中绘制为方框，用系统的 名称作为标签，参与者绘制在边界外部， 用例绘制在边界内部。
（2）怎样确定用例的粒度？ 用例的粒度（用例的大小）可大可小， 一般一个系统易控制在20个用例左右。 用例是系统级的、抽象的描述，不是细 化的（是做什么，非怎样做） 对复杂的系统可以划分为若干个子系统 处理。
３、用例---Use Case
（3）怎样获取用例？ 参与者希望系统执行什么任务？ 参与者在系统中访问哪些信息（创建、 存储、修改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？
事件流：就是用执行时，由一序列活动组成的 控制流。 基本事件流：对用例中常规、预期路径的描述。 扩展事件流：主要是对一些异常情况、选择分支 进行描述。 前置条件：在用例启动时参与者（actor）与系统 应置于什么状态。 后置条件：用例结束时系统应置于什么状态。
6.4 用例描述
4、用例描述举例
第六章 用例图
6.1 用例图概述 6.2 用例图的组成 6.3 阅读用例图 6.4 用例描述 6.5 建立用例模型
6.1 用例图概述
用例图是获取需求的直接方法；
用例图是外部参与者所能观察到的系统功 能的模型图，它将系统、子系统和类的行 为可视化； 用例图还是软件测试人员进行测试的指导。
（2）包含

是指两个用例之间的关系。其中一个用例（基 本用例，base use case）的行为包含了另一个用 例（包含用例，inclusion use case）的行为。
（2）包含

如果两个以上用例有大量一致的功能，则可以 将这个功能分解到另一个用例中，其他用例可 以和这个用例建立包含关系。
•图6-7 包含用例
（2）包含
执行基用例时，必须执行被包含用例，被包含 用例也可单独执行。
（2）包含

如果一个用例的功能太多时，可用包含关系建 模成两个或多个小用例。
（3）扩展

也是指两个用例之间的关系。 一个用例可以被定义为基础用例的增量扩展， 称作扩展关系。 扩展关系是把新的行为插入到已有用例中的 方法。 基础用例即使没有扩展用例也是完整的。一 般情况下基础用例的执行不会涉及扩展用例， 只有特定条件发生，扩展用例才被执行。
2、参与者---Actor
（2）参与者间的关系
NewClass 超类参与者
NewClass
客户
特殊化参与者
NewClass2
特殊化参与者
NewClass3
电话客户
NewClass2
网上客户
NewClass3
2、参与者---Actor
（3）怎样识别参与者 谁向系统提供信息？ 谁从系统获取信息？ 谁操作系统？ 谁维护系统？ 系统使用哪些外部资源？ 系统是否和已经存在的系统交互？
选择谁？
6.4 用例描述
1、对用例的描述有两种方法 （1）用例图：只能描述系统的大概功能， 是一种视图； （2）用例描述：更详细地描述用例的功能。
用例概述
用例详述
6.4 用例描述
2、用例描述的组成 用例名称 简要说明/描述 优先级 参与者 前置条件 基本事件流 其他事件流 扩展点 后置条件
6.4 用例描述
（2）详细描述
基本事件流
① 图书管理员向系统发出“新增书籍信息”请求。 ② 系统要求图书管理员选择要新增的书籍是计算 机类还是非计算机类。 ③ 图书管理员做出选择后，显示相应界面，让图 书管理员输入信息，并自动根据书号规则生成书号。 ④ 图书管理员输入书籍的相关信息，包括：书名、 作者、出版社、ISBN号、开本。页数、定价。是否 有CD-ROM。 ⑤ 系统确认输入的信息中书名没有重名。 ⑥ 系统将所输入的信息存储建档。
2、参与者---Actor
参与者是系统外部的一个实体； 参与用例的执行过程；
通过向系统输入或请求系统输入某些事 件来触发系统的执行； 由参与用例时所担当的角色来表示；
每个参与者可以参与一个或多个用例。
2、参与者---Actor
（1）参与者的表示
2、参与者---Actor
强调： Actor不是指人，而是指参与用例时所担 当的角色。 如果一个角色的操作是由另一个角色代 理完成的，请建立该角色到另外角色之 间的依赖。
以用例UC01“新增书籍信息”为例，说明如何细化用 例描述。 （1）用例概要描述 ① 用例名称：新增书籍信息（UC01）。 ② 简要说明：录入新购书籍信息，并自动存储建档。 ③ 事件流：基本事件流和扩展事件流 ④ 非功能需求 ⑤ 前置条件：用户进入图书管理系统。 ⑥ 后置条件：完成新书信息的存储建档。 ⑦ 扩展点：无 ⑧ 优先级：最高（满意度 5，不满意度 5）


（3）扩展
（4）泛化

一个用例和其几种情形的用例间构成泛化关系。 往往父用例表示为抽象用例。 任何父用例出现的地方子用例也可出现。
6.3 阅读用例图
思考 假设有这样的需求，在学生档案管理中， 管理员经常需要做3件事： （1）增加一条学生记录； （2）修改一条学生记录 （3）删除一条学生记录。 如果要画出用例图，则以下两种方法哪种 更合适？