难点讲解-业务用例与系统用例的区别以及include和extend的使用

业务用例和系统用例在软件开发中，业务用例和系统用例是两个关键概念。

本文将从不同的角度介绍这两个用例类别。

一、业务用例业务用例是指描述业务需求的用例。

业务用例通常与实际业务过程中的角色、事件和功能有关。

通俗地说，业务用例就是对于业务人员来说，软件需要做些什么事情。

具体而言，业务用例的特点如下：1.业务用例是面向业务人员的，其中的术语和业务流程需要清晰易懂。

2.业务用例描述的是“是什么”，而不是“怎么做”。

3.业务用例通常与现有业务流程紧密相关，与系统实现方式无关。

4.业务用例需要由业务人员参与编写和审查。

除了以上特点，业务用例还具有一些构成要素。

例如：用例名称、参与角色、前置条件、流程步骤、后置条件、异常流程等。

这些要素可以帮助编写人员更加清晰地描述业务需求。

二、系统用例系统用例是针对软件系统的用例。

系统用例描述的是对系统的输入、处理和输出。

通俗地说，系统用例就是对于软件开发人员来说，软件如何实现业务需求。

具体而言，系统用例的特点如下：1.系统用例是面向开发人员的，其中的术语和技术细节需要精准明确。

2.系统用例描述的是“如何做”，而不是“做什么”。

3.系统用例与现有的技术环境和开发方式密切相关，但不必考虑业务流程。

4.系统用例需要由开发人员参与编写和审查。

系统用例也有一些构成要素。

例如：用例名称、参与者、输入、处理、输出等。

这些要素可以帮助开发人员更好地实现业务需求。

三、业务用例与系统用例之间的关系业务用例和系统用例往往对应着同一个业务流程。

从业务人员的角度来看，他们需要的是一个能够高质量完成业务流程并达到业务目标的系统。

从技术人员的角度来看，他们需要用系统用例来说明如何实现业务流程。

因此，业务用例和系统用例可以说是互相依存的关系。

在实际软件开发中，业务用例往往是与用户需求相关的，它们通常是在需求分析阶段编写的。

通过编写业务用例，我们可以更好地理解用户需求和业务流程。

而系统用例则是在需求分析后，进入系统设计阶段才开始编写。

浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图（用例）4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图（Collaboration Diagram/communication Diagram）/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言（Unified Modeling Language，UML）又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

‘UML感兴趣的可以阅读UML 1规范，包含了UML 的所有知识内容。

注：OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发，定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。

分类：面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。

“序列图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。

•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图（用例）用例图，展现了一组用例、参与者（actor）以及它们之间的关系。

一、业务用例与系统用例的区别系统用例是从使用者的角度定义“软件系统”需求。

而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。

系统用例研究软件系统，借助用例定义软件系统需求。

而业务用例是以业务组织外部业务参与者的角度定义业务组织提供的服务。

业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。

业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。

也就是对于actor 来说，他所负责的业务需要由一系列的业务目标组成。

比如一个档案管理员，他的业务目标就是维护档案。

比如论坛管理员，他的业务目标有维护用户、维护帖子等。

这些业务目标构成actor职责的全部。

业务用例体现了需求。

而需求的实现有多种方式。

如何实现它，是由系统用例来体现的。

系统用例和业务用例并不是一个简单的细分关系。

就说维护档案吧，这样一个业务目标，会有多种不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案……对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪些部分是要纳入系统建设范围的。

比如维护档案业务用例中，假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就有增加档案，删除档案，而没有修改档案。

业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。

业务用例不是接近，而是完全的直接需求，系统用例是系统对需求的实现方式，它只是说，要建设的系统功能性需求由这些系统用例构成。

业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。

它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。

业务用例仅包含客户“感兴趣”的内容。

二、业务活动图1.为什么要画业务活动图？完成了业务用例图后，需要为每个业务用例绘制一个活动图。

业务活动图描述了在这个业务用例中，用户可能会进行的操作序列。

⽤例间的三种关系⽤例间的三种关系：（1）扩展(extends)：⽤例B extends ⽤例A，表⽰⽤例B是⽤例A在某种特定情况下可能会出现的扩展⽤例。

例如：⽼王进城办事，2⼩时就可以回去，在这2⼩时内内急时就会去上厕所。

上厕所⽤例是进城⽤例的扩展，因为不上厕所⽼王进城办事也可完成。

（2）包含(includes)：⽤例A includes ⽤例B，表⽰没有了⽤例B，⽤例A本⾝也就不完整了。

例如：还是⽼王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城⽤例与上厕所⽤例的关系就应该是包含关系了。

（3）泛化：泛化关系指的是同⼀业务⽬的的不同技术实现。

例如：⽼王进城，他可以坐飞机，可以坐⽕车，还可以⾛路，那么进城⽤例就泛化为坐飞机、坐⽕车和⾛路三个⽤例了，它们之间存在层级关系。

总的来看，扩展可以“冻结”基本⽤例以保持稳定（因为扩展⽤例通常是不确定的）；包含可以提供公共交互，提⾼“复⽤”；泛化是同⼀业务⽬的的不同技术实现。

⽤例之间除了上述三种关系不再有其他关系，⽤例之间不能通讯。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝下⾯是另外⼀种解释，⽤例⼦来描述。

⽤例描述的是系统外部可见的⾏为，是系统为某⼀个或⼏个参与者提供的⼀段完整的服务。

从原则上来讲，⽤例之间都是并列的，它们之间并不存在着包含从属关系。

但是从保证⽤例模型的可维护性和⼀致性⾓度来看，我们可以在⽤例之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这⼏种关系。

这⼏种关系都是从现有的⽤例中抽取出公共的那部分信息，然后通后过不同的⽅法来重⽤这部公共信息，以减少模型维护的⼯作量。

4.2.1 包含(include)包含关系是通过在关联关系上应⽤<<include>>构造型来表⽰的，如下图所⽰。

它所表⽰的语义是指基础⽤例(Base)会⽤到被包含⽤例(Inclusion)，具体地讲，就是将被包含⽤例的事件流插⼊到基础⽤例的事件流中。

《软件工程》实验指导书计算机学院2017年2月软件工程实验指导前言软件工程实验是为计算机相关专业本科《软件工程》课程配套设置的，是《软件工程》课程讲授中一个重要的、不可或缺的实践环节。

其目的是使学生能够针对具体软件工程项目，全面掌握软件工程管理、软件需求分析、软件初步设计、软件详细设计、软件测试等阶段的方法和技术，通过该课程设计使学生进一步理解和掌握软件开发模型、软件生命周期、软件过程等理论在软件项目开发过程中的意义和作用，培养学生按照软件工程的原理、方法、技术、标准和规范，进行软件开发的能力，培养学生的合作意识和团队精神，培养学生对技术文档的编写能力，从而使学生提高软件工程的综合能力，提高软件项目的管理能力。

按该课程的特点，实验内容包括软件开发的两大方法学的专题训练，即结构化（生命周期学）的方法学和面向对象的方法学，通过对一个简单项目，要求学生利用结构化软件开发技术或面向对象的软件开发技术完成对该项目的开发。

因此设置五个实验项目，从项目发的准备工作，系统分析过程，系统设计过程，软件测试到系统实施，覆盖软件开发的整个过程，此外又引入我国国家《计算机开发规范》，以规范技术文档的书写标准，提高实验教学质量。

通过实验训练，达到如下目的：使学生进一步了解和掌握软件工程原理，提高对实际项目的分析和设计能力，通过实验课程，熟悉和基本掌握软件工程方法学、软件开发的过程，文档资料的编写格式及规范，全面领会和贯通所学习的理论知识，从而培养学生综合运用所学课程知识，分析解决问题的能力，培养学生理论联系实际作风，实事求是，严肃认真的科学态度和良好的工作作风，为今后从事科学研究工作打下基础。

实验要求软件工程实验具体要求如下：每个项目小组必须按照《软件工程实验指导书》附录中给定的文档规范标准提供项目文档；题目自定或采用附录二中的题目；软件开发的方法自定（结构化或面向对象的方法学）。

实验一用Visio进行功能分析和建模1. 实验目的掌握结构化分析的方法。

软件工程导论作业解析软件工程导论作业Chapter11.1 什么是软件危机?它有哪些典型表现?为什么会出现软件危机?答：软件危机是指在计算机软件开发和维护过程中所遇到的一系列的严重问题。

它的典型表现：1.软件开发成本高，成本难以控制。

2.研究周期长，软件开发进度难以控制，周期拖得很长。

3.正确性难以保证，软件质量差，可靠性难以保证。

4.软件维护困难，维护人员和维护费用不断增长。

5.软件发展跟不上硬件的发展和用户的要求。

它出现的原因一方面是由于软件生产本身存在着复杂性，另一方面是与软件开发所使用的方法和技术有关。

软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。

管理和控制软件开发工程相当困难，软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

目前相当多的软件专业技术人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成为软件危机的主要原因。

1.2 什么是软件工程?它有哪些本质特性?怎样用软件工程消除软件危机?答：软件工程是将系统化的，规范化的，可度量的方法应用于软件开发，运行和维护的过程，即将工程化应用于软件中。

它的本质特性：1.软件工程关注于大型程序的构造2.软件工程的中心课题是控制复杂性3.软件经常化4.开发软件的效率非常重要5.和谐地合作是开发软件的关键6.软件必须有效地支持它的用户7.在软件工程领域中是由一种文化背景的人替具有另一种文化背景的人创造产品。

基本原理: 1.用分阶段的生命周期计划严格管理2.坚持进行阶段评审3.实行严格的产品控制4.采用现代程序设计的技术5.结果应能清楚地审查6.开发小组的人员应该少而精7.承认不断改进软件工程实践的必要性。

1.3 什么是软件？它有什么特点？答：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据结构及其相关文档的完整集合。

它的特点是：1.抽象而非具体2.开发而非制造3.退化而非磨损4.定制而非基于构件 5.不可见 6.复杂 7.易改变 8.易复制1.4 什么是软件过程?它与软件工程方法学有何关系?答：软件过程是为了开发出高质量的软件产品所需完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。

用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。

用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。

当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。

它将系统功能划分成对参与者（即系统的理想用户）有用的需求。

而交互部分被称作用例。

用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。

用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。

用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。

有时，可以将用例的实例引入到图中。

用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。

一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。

参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。

参与着由参与用例时所担当的角色来表示。

在UML中，参与者用名字写在下面的人形图标表示。

每个参与者可以参与一个或多个用例。

它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。

参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。

第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。

命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。

第二类参与者是其它的系统。

业务用例和系统用例
业务用例和系统用例是软件开发过程中经常用到的两种用例，它们有着不同的定位和功能。

业务用例主要关注用户需求和业务流程，用于描述用户的行为和系统响应。

它通常由业务人员或产品经理编写，它能够帮助开发团队更好地理解用户需求，从而开发出符合用户期望的系统。

业务用例通常以用户故事的形式呈现，它包括用户的角色、用户的目标、用户所需的功能和系统的响应等。

系统用例则更加关注系统的功能和行为，用于描述系统的操作流程、数据流和操作者之间的交互。

它通常由开发人员编写，它能够帮助开发团队更好地理解系统的设计和实现，从而确保系统能够满足用户需求。

系统用例通常以用例图、活动图、时序图等形式呈现，它包括系统的参与者、系统的功能、系统的输入和输出等。

业务用例和系统用例之间存在一定的联系和关系。

业务用例是系统用例的基础，系统用例则是业务用例的实现。

在软件开发过程中，业务用例和系统用例的编写和分析是非常重要的，它能够帮助开发团队更好地了解用户需求和系统设计，从而开发出高质量的软件系统。

- 1 -。

um中用例讲的include什么是"include"？在软件开发领域中，"include"是一种关键字，用于表示一个测试用例中包含了另一个测试用例。

它是一种测试用例组织的方法，可以有效地减少用例的冗余编写，提高测试用例的可维护性和可重用性。

为何需要"include"？1. 测试用例的重复编写：当我们在编写一系列测试用例时，经常会发现有一些用例的部分内容是相同的，比如用例的前置条件或后置操作。

如果没有"include"的机制，那么我们将不得不为每个用例都重复编写这些相同的内容。

这样不仅效率低下，而且一旦有任何修改或更新，需要逐个修改每个用例，容易出现疏漏和错误。

2. 用例的可维护性：测试用例的维护是一个重要的任务，需要及时跟踪和更新。

如果一个用例在多个地方使用，一旦需要更新，我们将不得不逐个去修改这些用例，非常繁琐且容易出错。

而使用"include"，我们只需要修改被包含的用例即可，所有引用了该用例的地方都会自动更新，大大提高了用例的可维护性。

3. 用例的可重用性：在软件测试中，有很多常用的测试用例模块，比如登录模块、注册模块等。

使用"include"，我们可以将这些模块单独编写成用例文件，然后在需要的地方引用。

这样一来，我们可以复用这些模块化的用例，减少重复编写相似代码的工作量，提高测试用例的可重用性。

如何使用"include"？在大多数测试框架中，使用"include"非常简单。

下面以Python中的unittest为例，给出一步一步的说明：步骤1：导入所需的模块首先，我们需要导入unittest模块，该模块提供了编写测试用例的基本类和方法。

import unittest步骤2：编写被包含的测试用例我们需要编写一个或多个测试用例作为已存在的用例，然后将这些用例写入一个独立的类中。

解析UML用例图中include与extend的区别UML用例图有很多值得学习的地方，这里向大家简单介绍一下UML用例图中include与extend的区别，希望本文的介绍对你有所帮助。

本文和大家重点讨论一下UML用例图中include与extend的区别，include是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分，而extend则恰好相反。

下面请看本文详细介绍。

UML用例图中include与extend的区别最近上论坛，看到在争论UseCase中include与extend的区别。

其实这两者是很容易区分的。

include是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样），例如UseCaseA中包括了a和b两个流程，而UseCaseC中包含了c和b两个流程。

为了提高复用性，可以把b提取出来，形成另一个用例UseCaseB，此时，UseCaseAincludeUseCaseB（表现为一条指向UseCaseB的虚线，箭头在UseCaseB侧），UseCaseC也includeUseCaseB。

因而，当有include关系时，被include的用例通常会被两个以上的其他用例include（否则就不需要重用，也就不需要提取出来了），UML用例图如下：在include关系中，“UseCaseA和UseCaseC知道UseCaseB的存在，而UseCaseB根本不知道有UseCaseA和UseCaseC）；extend则恰好相反。

假设UseCaseA的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种，例如通过邮件发送、通过短信发送等。

在需求分析阶段，可能无法明确到底有多少种方式，在用例分析阶段，UseCaseA需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如UseCaseB是“通过短信发送”，而UseCaseC是“通过邮件发送”，此时，UseCaseB和UseCaseCextend了UseCaseA，表现为两根虚线，箭头指向UseCaseA，UML用例图如下：在extend关系中，UseCaseA不知道UseCaseB和UseCaseC的存在，但UseCaseB和UseCaseC 却是知道UseCaseA并且知道如何在UseCaseA中作扩展的。

业务用例与系统用例的关系绝大多数构架师都认为业务建模是开发软件解决方案中到一个专门重要的活动。

成功的解决方案会支持那个业务，它们能够解决业务咨询题并确保业务目标的实现。

当开发一个合理的业务模型以后，业务流程分析员能够探究不同业务改进的选项，例如取消余外的任务，使重复且平凡的任务或者容易显现的错误实现自动化操作。

IBM®Rational Unified Process®，或者RUP®，以及Unisys 3D Visual Enterprise，或者3D-VE，或者3D-VE,提供了一个系统化的方法，利用统一建模语言（UML）能够直观地表现业务模型，同时还能够派生出一个一致的且能够追溯到那个业务模型的起点系统用例模型。

这篇文章提供了RUP 业务建模的概述，并解决了以下的咨询题：业务用例模型与系统用例模型有如何样的相似之处？业务用例模型与系统用例模型有什么不同之处？构建业务模型应该使用哪个UML 图？业务用例模型与系统用例模型之间有什么关系？背景在谈论那个咨询题之前，我想讲明一下什么原因要选择那个专门的话题来写。

自从1990年我就作为一名软件构架师从事系统用例的工作。

当我是一名由Unisys Global Public Sector 开发的Integrated Justice Informati on Sharing (IJIS) 框架解决方案的总构架师时，还没有接触到业务用例，直到2002年。

IJIS 现在差不多进展成为Unisys Information Sharing Manage ment Framework (ISM)。

ISM 是一套支持信息共享的总体业务过程的可重用的组件。

ISM Fra mework 利用Service Oriented Architecture (SOA) 技术整合了不同类型的司法与公共安全系统，从而在关键决定点时分配关键的数据，文档以及图片。

如何区分业务⽤例和功能⽤例？
昨天有同事问到“如何区分业务⽤例和功能⽤例”，现把当初的解释内容记下来：
业务⽤例：业务部门或组织（业务⼯⼈）为其外部客户或内部特定⼈员（业务主⾓）提供有价值的服务（业务⽤例）
系统⽤例：我们的⽤户部门中的各种岗位⼈员（⾓⾊）⾯对我们的系统时，所进⾏的⼀次⽐较完整的交互，并得到了有价值的结果不是功能⽤例，功能是站在系统内部的静态概念，没有考虑什么⼈在什么时候如何使⽤。

区别1：范围
业务⽤例涉及的范围更⼤，可能有各种⼈、部门、各种系统，甚⾄包含⼿⼯操作、讨论等
系统⽤例只涉及我们⾃⼰系统与操作⼈员的交互，对应于业务⽤例中某些活动步骤，不包含其他系统及⼿⼯操作
区别2：⽤途
业务⽤例建模是为了明确业务组织是如何运作的
系统⽤例是明确各种⾓⾊⾯对我们的系统时，双⽅各⾃要做的事和交互反馈，简⾔之就是明确我们究竟要做哪些事、给谁⽤
区别3：执⾏者
业务⽤例的执⾏者为外部客户或组织，各种领导或操作⼈员为内部业务⼯⼈，如果是为员⼯提供福利的话则执⾏者为公司内部员⼯系统⽤例的执⾏者为操作⼈员所代表的岗位⾓⾊
业务⽤例的执⾏者⼀般是⼈或组织，例如⼴告客户、⽹民、市政机关、教委、图书馆；
系统⽤例的执⾏者为实际与系统交互的操作⼈员或不是⼈的东西（外部衔接系统、⾃动服务、定时器）
区别4：建模的必要性
业务⽤例：仅当业务活动复杂、涉及⼈员多、需要长期深⼊某个⾏业时才需要业务建模
对于专业性⼯具软件、偏重⾼深技术的软件（例如飞腾排版系统、图像处理软件），则不需要业务建模。

UML用例中的包含、扩展、泛化关系的理解在用例关系中有有三种关系，一是包括，"include" 一是扩展"extend"一是泛化，当然还有最基本的关系，“关联”.其中，包含关系：包含关系用于将部分工作流程分离出去，对这部分工作流程来说，基本用例只取决于结果，与获得结果的方法无关。

如果这种分离可以简化对基本用例的理解（隐藏详细的行为），或者可以在其他基本用例中复用被分离的行为，您就可以将这部分工作流程分离出去。

基本用例通过包含关系连接到包含用例。

包含用例总是抽象的。

它描述在执行基本用例的用例实例中插入的行为段。

基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但是基本用例和包含用例都不能访问对方的属性。

从这种意义上来讲，包含用例是被封装的，它代表可以在各种不同的用例中复用的行为。

包含关系用于：（１）从基本用例中分解出来这种的行为：它对于了解基本用例的主要目的不是必需的，只有它的结果才比较重要。

（２）分解出两个或者多个用例所共有的行为。

扩展关系：扩展关系将扩展用例与基本用例连接了起来，通过在基本用例中引用扩展点，可以定义在基本用例的哪些位置插入扩展用例，扩展用例通常是抽象的，但是不是必须抽象。

扩展的目的在于：（１）表明用例的某一部分是可选的（或者可能可选）的系统行为。

这样，你就可以将模型中的可选行为和必选行为分开。

（２）表明只有在特定条件下（有时候是异常情况下）才执行的分支流，如触发警报。

（３）表明可能有一组行为段，其中的一个或者多个段可以在基本用例中的扩展点处插入。

所插入的行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互。

扩展是有条件的，它是否执行取决于在执行基本用例时所发生的事件。

基本用例并不控件执行扩展的条件，这些条件在扩展关系中进行说明。

扩展用例可以访问和修改基本用例的属性。

但是基本用例看到到扩展用例，也无法访问它们的属性。