软件工程用例图共27页文档
软件工程用例图实验报告
华北水利水电学院 实用软件工程学 实验报告_2009_～_2010_学年 第 二 学期 2009级 计算机科学与技术专业学号：200915320 班级 ： 2009153 姓名： 李晓娜实验五 用例图一、实验目的1、掌握一种画图工具。
2、学会分析、建立用例图。
二、实验内容根据某公司办公自动化系统的功能体系结构来建立业务用例图。
功能体系结构图如下所示：三、实验步骤（一）系统中业务用例和确定根据系统的功能体系结构，可以很容易地确定出此系统的业务用例有公文管理、会议管理、财务管理、工作管理、客户管理、系统管理、个人办公管理、公共信息管理、资产设备管理和人力资源管理用例。
（二）系统中业务角色和业务工人的确定根据业务角色和业务工人指向的不同以及对系统的需求分析，可以找到办公自动化系统的业务角色有潜在的员工、客户、供应商、办事处和分公司。
业务工人有办公人员和系统管理人员。
根据不同的模块，事实上与系统交互的办公人员又可以继续被分类。
（三）业务用例图的建立在对系统进行了业务用例、业务角色和业务工人的确定之后，建立业务用例图，来反映整个机构的业务。
如图1所示。
办公自动化系统 公 文 管 理会 议 管 理财 务 管 理工 作 管 理客 户管 理系 统 管 理个人 办 公 管 理公共 信 息管 理资产设备管 理 人力 资源 管 理图1 业务用例图（四）子系统业务分析及用例图。
1、公文管理业务分析这个子系统包括发文管理和收文管理。
发文管理的工作是要根据预先设置的发文管理流程和权限设置，实现发文的各项办理工作：文件输入、提交、审核、签发、发放、存档、作废、打印；收文管理的工作有接收外来文件、编号登记、发放、存档、打印。
发文管理流程中的一系列工作都与系统文件信息管理相连接，对文件信息进行各种操作和更新，其用例图如图2所示。
图2 公文管理用例图2、资产设备管理业务分析资产设备管理包括办公用品管理和资产管理两个功能。
其中，办公用品管理指的是一般的低值易耗品的管理，它为库存管理员提供办公用品的库存、采购、领用的查询统计功能和库存报警功能，办公用品的领用申请在个人办公管理中进行；资产管理实现对公司固定资产的管理，在该企业中是由行政部的库管员进行管理的。
第三讲用例图
3.3 用例图的概念
• 1. 用例图
• 用例图是描述用例、参与 者及其关系的图。与所有 UML的其它图一样，用例 图可以包括注释、约束。 图3-1是棋牌管理系统对应 的用例图。 • 图中的元素包括：参与者、 用例、一个方框和一些表 示关系的连接线，所有的 用例都位于方框之内，该 方框称为“系统边界”。 方框内是棋牌管理系统的 多个用例，方框外是外部 参与者。
第3章 用例图
目录
3.1 需求技术
3.2 RUP开发过程
3.3 用例图的概念 3.4 用例图的表示 3.5 参与者之间的关系
目录
3.6 用例之间的关系
3.7 参与者与用例之间的关系
3.8 阅读用例图 3.9 用例图应用 3.10 建模要点
第3章 用例图
• 用例图是外部参与者所能观察到的系统功能的模型图，该 图呈现了一些参与者和一些用例，以及它们之间的关系， 主要用于对系统、子系统或类的功能行为进行建模。
3.3.2 标识用例间的关系
• ２．包含关系 • 在UML中，包含关系用构造型《include》表示，它是指基用例（base use case）在它内部的某一个位置上显式地合并了另一个用例的行为。 • (1) 包含用例的表示 • 包含是指一个用例被另一个用例使用，被使用的用例就是包含用例， 使用包含用例的是基用例。 • 图3-7说明：查询、提款、转帐三个是基用例，它们都包含打印回执用 例．基用例执行时必须执行包含用例，否则，基用例是不完整的，包 含用例不是孤立存在的，它仅作为基用例的一部分出现．图中，包含 关系的箭头是从基用例指向包含用例． • 只有当某个事件流片断在多个用例中出现时，才将这个事件流片段抽 取出来，放在一个单独的用例中，把这个用例用作包含用例。
用例图
顾客顾客用户2.1 用例建模技术2.1.1 参与者和用例参与者（actor ）是系统外部与系统有交互的任何事物，是为了完成一个事件而与系统交互的外部实体。
参与者主要用于描述系统的边界。
例如，向银行提交贷款申请的顾客；通过因特网访问预订系统查询座位情况的旅行社，等等。
在UML 中，参与者经常用人形符号表示，或者用类的构造型《actor 》表示，如图2-3所示。
图2-3 参与者的UML 表示符号参与者并不一定是系统的用户。
它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。
图2-4展示参与者是外部系统的例子。
图2-4参与者是外部系统的例子当参与者是人时，它是指一个与系统有交互的用户所扮演的角色。
一个参与者并不是指一个特定的人或一个特定的实体。
例如，参与者“顾客”是对顾客的概念建模，而不是对张三这个特定的顾客建模。
一个用例并不仅局限于一个参与者; 参与某用例的参与者可能是多个。
然而，一个用例况必须向至少一个参与者提供可度量的价值。
参与某用例的多个参与者各有不同的角色和职责：一些负责接收用例提供的价值，一些则负责向用例提供服务，其它则负责触发或初始化用例。
Ivar Jacobson[1992]将参与者划为两类：主要的和次要的。
主要参与者(primary actor)是从系统获得可度量价值的用户。
主要参与者的需求驱动了用例所表示的行为或功能。
如果他们的需求或角色发生了变化，那么系统将必须有重大的修改。
次要参与者(secondary actor)在用例中提供服务，并且不能脱离主要参与者而存在。
在图2-4所示的例子中，顾客是主要参与者，而客户关系系统则是次要参与者。
顾客<<Actor>>顾客 客户关系管理系统 （已有） 网上商店系统（要开发） 问卷调查系统 （已有）图2-5 抽象参与者的例子一些参与者只扮演概念上的角色，而另一些则更具体。
如图2-5所示，顾客共享用户的属性。
软件工程,论文 用例图 需求分析 项目流程图 实例图 RE图 属性图讲解
药品管理系统1.简要这次是C#考试答辩程序改写有不足望老师见谅:经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理，药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程，数据库等进行研究，分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义。
2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等。
3需求3.1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额，所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算，为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率，在我们购买药品的时候也就方便了起来。
信息管理系统的出现，改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3.2 医药销售管理系统数据库医药销售管理系统是基于网络应用，根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况，完全采取面向对象的系统开发方法，进行严格设计而成的专业医药销售管理软件。
第4章_用例及用例图(同济大学软件工程硕士面向对象技术)
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
课堂练习
对图书馆的图书管理系统进行用例分析：
1. 2. 3. 4. 5. 6. 7. 确定图书管理的参与者； 参与者所看到的图书管理功能； 把这些功能分解为用例； 确定用例之间的关系； 画用例图； 优化用例图； 描述事件流。
储蓄系统
√ √ √ 开户
存款
取款 转帐
用例的特点(2)
用例描述用户提出的一些可见需求，对应一个 具体的用户目标。
储蓄系统
√
√ √ √
开户 存款
取款
转帐
×
数据上传
用例的特点(3)
用例反映系统与用户的一次交互过程 ，应该具有交互的信息的传递。
帐户，密码，金额数 确认信息，帐户余额
取款
用例的特点(4)
用例之间的关系(3)
泛化关系
参与者与参与者之间，用例与用例之间存在一般 与特殊的关系。
参与者的泛化关系
用于简化用例图 销售系统用例图：
- 销售人员和客户用的基本上 相同的用例图
- 计算回扣是例外
Customer OrderProducts Sales system
ListProducts
用例图过于复杂（太多的交叉线 ） 采用一个公共的参与者（购买者 ） 原来的角色由此导出
④储户输入取款金额，按确认键。 ⑤ATM把帐号和取款金额传递给银行系统，取回确认信息和帐户 余额。 ⑥ ATM输出现金，并显示帐户余额。
⑦ATM记录事务到日志文件。
取款用例描述另一种描述
● 用例：取款 ●参与者：储户
储户
插入ATM卡
ATM系统行为
从卡上读取银行ID、帐号、并验 证帐号
软件工程9种图
软件工程9种图软件工程9种图本文档旨在介绍软件工程中常用的9种图，包括需求分析图、用例图、活动图、类图、状态图、序列图、通信图、部署图和物理架构图。
每个章节将详细说明各种图的定义、特点和使用方法。
1.需求分析图需求分析图主要用于描述系统的需求和功能，并将其转化为可视化的图形表示。
它包括用例图、活动图、状态图等多种子图。
用例图用于展示系统的功能、用户以及各功能之间的关系；活动图则表示系统中的各种活动以及它们之间的关系；状态图则描述系统中对象的不同状态和状态之间的转移。
2.用例图用例图是描述系统功能和用户之间交互的图表。
它展示了系统的功能性需求，包括系统的主要功能和参与者（用户）之间的关系。
用例图由参与者、用例和关系构成，通过参与者和用例之间的关系来表示用户与系统的交互。
3.活动图活动图用于描述系统中的活动或业务流程，以及这些活动之间的顺序关系。
它展示了系统的业务流程，包括活动、决策、并行和合并分支。
活动图通过节点、边和分支条件来表示活动之间的关系。
4.类图类图用于描述系统中的类、对象以及它们之间的关系。
它展示了系统的结构，包括类的属性、方法、关联关系、继承关系等。
类图通过类、对象、关联和继承等元素来表示系统的结构。
5.状态图状态图用于描述系统中对象的不同状态和状态之间的转移。
它展示了系统中对象的状态及其变化，包括对象的初始状态、中间状态以及最终状态。
状态图通过状态、转移和条件来表示对象的状态和状态之间的转移。
6.序列图序列图用于描述系统中对象之间的交互顺序和消息传递。
它展示了系统中对象之间的交互流程，包括对象的创建、销毁、方法调用等。
序列图通过对象、消息、生命线等元素来表示对象之间的交互和顺序关系。
7.通信图通信图用于描述系统中对象之间的交互和消息传递。
它展示了对象之间的通信方式，包括消息的发送和接收。
通信图通过对象、消息、连接线等元素来表示对象之间的交互和通信关系。
8.部署图部署图用于描述系统中软件和硬件组件的部署布局。
软件工程课件之第4章用例和用例图
4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
2、软件工程网上图书销售系统用例模型及用例图.
四、用例模型及用例图：
4.1 用户需求
1、非注册用户查看搜索商品，进行注册。
2、注册用户查看搜索商品，下订单，查看修改订单。
对个人资料进行修改。
3、管理员查看、修改商品信息，查看订单，对订单进行处理，管理用户信息，对网站维护。
4.2 执行者
非注册用户
注册用户
管理员
执行者“非注册用户”：搜索浏览商品信息，进行注册。
执行者“注册用户”：注册用户查看搜索商品，下订单，查看修改订单。
对个人资料进行修改。
执行者“管理员”：管理员查看、修改商品信息，查看订单，对订单进行处理，管理用户信息，对网站维护。
软件工程-论文-用例图-需求分析-项目流程图--实例图---RE图--属性图
药品管理系统1。
简要这次是C＃考试答辩程序改写有不足望老师见谅：经过市场调研，初步了解到药品销售管理系统在现实生活中的应用，现行的医药管理系统在现实中的应用主要是药品的收费管理和药品销售的账目管理,药品的库房管理（药品的进库，药品的出库）其中，最常用的是，销售管理和库房管理。
此系统操作性相对简单，只要对电脑有一定操作基础的人员都可以使用，系统对用户的提示性较好，可以提醒和引导用户对系统的操作。
本课题通过对现行医药管理信息系统的组织结构，业务流程,数据库等进行研究,分析系统的实际运行情况，并提出新的逻辑设计方案，以此来完善改进现有的系统，这对于医药企业提高经营管理具有一定的积极意义.2.简要说明本用例是一个医药超市管理系统，只有管理员和销售员有管理权限，其中管理员和销售员可以对自己的密码进行修改。
用用自己的管理账号对医药进行管理，进货销售等等.3需求3。
1医药销售管理系统需求分析以往到药店购买药品的时候，销售人员都要手写单据和人工结账，而且每天都要统计当日的销售额，月末要统计一个月的销售额,所以要管理大量的单据，而且在统计的时候需要大量的时间，并且是人工操作，比较容易出错。
医药管理系统的出现，使得这一切变得简单起来。
以往需要算一个小时的账目现在只需点一下鼠标就可以得到，而且得到的结果还是精确的，不用担心有错误，用电脑代替人脑计算,为使用者节省了大量时间。
另外消费者也得到了便利，因为键盘录入取代了手写的单据增加了效率,在我们购买药品的时候也就方便了起来.信息管理系统的出现,改变了企业的管理模式，药品销售管理系统则改变了医药行业的管理模式。
在当今医药行业，一套好的销售管理系统成为众多企业的得力助手。
3。
2 医药销售管理系统数据库医药销售管理系统是基于网络应用,根据医药销售系统的长期开发研究经验和各医药公司现实中存在的实际业务情况,完全采取面向对象的系统开发方法,进行严格设计而成的专业医药销售管理软件。
第4章用例及用例图(同济大学软件工程硕士面向对象技术)精品PPT课件
取款 用例的动态事件流
a 通过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM记录事务到日志文件。
Sales system ListProducts OrderProducts AcceptPayment CalcualteCommission
用例的泛化关系
父类用例
- 查找产品
两个子类：
- 查找书籍 - 查找CD
Sales system
Customer
FindProduct
FindBook
FindCD
发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ● ⑤ 绘制用例图。
发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。 ● ⑥ 编制用例说明。
① 通过读卡机，储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号。 ③ 储户键入密码，系统检验密码。 ④储户输入取款金额，按确认键。 ⑤ATM把帐号和取款金额传递给银行系统，取回确认信息和帐户
余额。 ⑥ ATM输出现金，并显示帐户余额。 ⑦ATM记录事务到日志文件。
取款用例描述另一种描述
软件工程领域分析用例图和活动图PPT课件
• 通过UML中的活动图，可以帮助我们进行用户业务流程建模，帮助我们站 在用户的视角上进行业务分析。
• 在业务流程建模中，我们关注的是用户进行某项业务的执行步骤。
第41页/共75页
可行性研究 领域分析 需求分析
设计
编码
测试
交付
我们的进度，在这里
活动图（Activity Diagram）
• 1 什么是活动图 • 2 活动图的用途 • 3 活动图的组成元素 • 4 活动图的建模技术
第42页/共75页
1 什么是活动图
• 活动图是UML中描述系统动态行为的图之一，是描述系统或业务的一序列活动构成的控制流，它描述了系 统从一种活动转换到另一种活动的整个过程。
第43页/共75页
2 活动图的用途
• 活动图用于对系统的动态行为建模。 • 活动图常用来描述业务或软件系统的活动轨迹，描述了系统的活动控制流程。我们常用活动图对业务过程、
第9页/共75页
如何建立用例模型
建立系统用例模型的过程就是对系统进行功能需求分析的过 程。
定义 系统
确定执行 者和用例
描述执行者 和用例关系
确认 模型
●确定系 统范围； ●分析系 统功能。
●执行者通常是使 用系统功能的外部 用户或系统。 ●用例是一个子系 统或系统的一个独 立、完整功能。
各模型元素 之间有：关 联、使用、 扩展及泛化 等关系。
第34页/共75页
例：自动售货机
客户
买饮料 供货
供货人
取货款
收银员 自动售货系统
顾客 供货人 收银员
自动售货机系统
售货 <<扩展>> <<包含>>
供货 <<包含>>
03-用例图
出纳员
吃饭
系统需要处理的，由系统生成
要点：业务语言而非技术语言
用户词汇，而不是技术词汇
如：发票，商品，洗衣机 而不是：记录，字段，COM，C++等
要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
识别手机系统的用例
用例 •呼叫某人 •接听电话 •发送短消息 •记住电话号码 •...... 用户观点
<<include>> <<include>>
填写注册信息
验证注册信息充分 <<include>> 潜在会员 注册 <<include>> 生成用户名和密码
保存注册信息
扩展关系（extend）
扩展用例是在原用例的基础上增加新的步骤 序列形成的。 原用例被称为基用例（base use case）。 扩展只能发生在基用例的序列中的某个具体 制定点上，这个点叫做扩展点（extension points）。
修改用户
管理员
“系统就是数据的增 删改查” 关心数据的存储和维 护，反而忽略了用户 的目的
删除用户
要点：用例的粒度(3)
如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即 可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示
Use Cases 把所有这些过程绑到一起
用例图的组成
用例（Use Case） 参与者（Actor） 关系(Relationship)
软件工程用例图题目
2
包含(include)、扩展(extend)和泛化(generalization)三种联系和区别
共性： 都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通 后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
2021/6/18
3
1 、包含(include)
包含关系：使用包含（Include ）用例来封装一组跨越多个用例的相似动作（行为片 断），以便多个基（Base ）用例复用。基用例控制与包含用例的 关系，以及被包含用 例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但 是双方都不能访问对方的属性。
2021/6/18
4
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流 过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的 用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。 这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从 主程序中调用这一子过程。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用
例事件的备选择流而存在。
2021/6/18
19
谢谢观赏
软件工程用例图题目
一 售票系统
参与者包括售票员、监督员和公用电话亭。公用电话亭是另一个系统，它接收顾客的订 票请求。顾客不直接与售票系统交互。用例包括通过公用电话亭或售票员购票，购预约 票（只能通过售票员）以及售票监督（应监督员的要求）。购票和购预约票包括一个共 同的部分，即通过信用卡来付钱。
2021/6/18
2021/6/18
17
既然用例是系统提供服务的UML 表述，那么服务这个过程在所有用例场景中是必然发 生的，但发生按照发生条件可分为如下两种情况： ⒈ 无条件发生：肯定发生的； ⒉ 有条件发生：未必发生，发生与否取决于系统状态；