用例间的三种关系:
(1)扩展(extends):用例B extends 用例A,表示用例B是用例A在某种特定情况下可能会出现的扩展用例。例如:老王进城办事,2小时就可以回去,在这2小时内内急时就会去上厕所。上厕所用例是进城用例的扩展,因为不上厕所老王进城办事也可完成。
(2)包含(includes):用例A includes 用例B,表示没有了用例B,用例A本身也就不完整了。例如:还是老王进城,他从海南来北京办事,3天才能回去,那么这种情况下进城用例与上厕所用例的关系就应该是包含关系了。
(3)泛化:泛化关系指的是同一业务目的的不同技术实现。例如:老王进城,他可以坐飞机,可以坐火车,还可以走路,那么进城用例就泛化为坐飞机、坐火车和走路三个用例了,它们之间存在层级关系。
总的来看,扩展可以“冻结”基本用例以保持稳定(因为扩展用例通常是不确定的);包含可以提供公共交互,提高“复用”;泛化是同一业务目的的不同技术实现。用例之间除了上述三种关系不再有其他关系,用例之间不能通讯。
======================================================
下面是另外一种解释,用例子来描述。
4.2 用例之间的关系
用例描述的是系统外部可见的行为,是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲,用例之间都是并列的,它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看,我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息,然后通后过不同的方法来重用这部公共信息,以减少模型维护的工作量。
4.2.1 包含(include)
包含关系是通过在关联关系上应用<<include>>构造型来表示的,如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion),具体地讲,就是将被包含用例的事件流插入到基础用例的事件流中。

包含关系是UML1.3中的表述,在UML1.1中,同等语义的关系被表述为使用(uses),如下图。

在ATM机中,如果查询、取现、转帐这三个用例都需要打印一个回执给客户,我们就可以把打印回执这一部分内容提取出来,抽象成为一个单独的用例"打印回执",而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时,就只需要改动一个用例,而不用在每一个用例都作相应修改,这样就提高了用例模型的可维护性。

在基础用例的事件流中,我们只需要引用被包含用例即可。
查询-基本事件流
1. 用户插入信用卡
2. 输入密码
3. 选择查询
4. 查看帐号余额
5. 包含用例"打印回执"
6. 退出系统,取回信用卡
在这个例子中,多个用例需要用到同一段行为,我们可以把这段共同的行为单独抽象成为一个用例,然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为,也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时,我们也只需要修改一个用例,避免同时修改多个用例而产生的不一致性和重复性工作。
有时当某一个用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中,将程序的某一段算法封装成一个子过程,然后再从主程序中调用这一子过程。
4.2.2 扩展(extend)
扩展(extend)关系如下图所示,基础用例(Base)中定义有一至多个已命名的扩展点,扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言,子用例中的事件流是一定插入到基础用例中去的,并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流,并且插入点可以有多个。

例如对于电话业务,可以在基本通话(Call)业务上扩展出一些增值业务如:呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。

在这个例子中,呼叫等待和呼叫转移都是对基本通话用例的扩展,但是这两个用例只有在一定的条件下(如应答方正忙或应答方无应答)才会将被扩展用例的事件流嵌入基本通话用例的扩展点,并重用基本通话用例中的事件流。
值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流,如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。但是基本通话用例已经是一个很复杂的用例了,选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂,并且把一些可选的操作独立封装在另外的用例中。
4.2.3 泛化(generalization)
当多个用例共同拥有一种类似的结构和行为的时候,我们可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。

以下是一个用例泛化关系的例子,执行交易是一种交易抽象,执行房产交易和执行证券交易都是一种特殊的交易形式。
用例泛化关系中的事件流示例如下:
分享到:
相关推荐
用例之间可能存在多种关系,包括扩展(Extension)、包含(Include)和泛化(Generalization)。这些关系有助于我们更有效地组织和理解用例,同时也使得用例图更加清晰。 - **扩展(Extension)**:表示一个基本...
- **关系**:参与者与用例之间、用例与用例之间通过关系线连接,用以表示它们之间的关联。 ##### 1.3 用例图的图形表示 - **系统边界**:通常用矩形框表示,用来界定系统的范围。 - **参与者**:用一个人形图标表示...
它以面向对象的方式描述系统的设计,提供了多种模型视图,其中包括用例图(Use Case Diagram),这是一种表示系统功能和外部交互者(即用户或其他系统)之间关系的模型。在面向对象建模和软件开发过程中,用例建模是...
- **用例图(Use Case Diagram)**:用例图展示了参与者与用例之间的关系以及用例之间的关系。它使用图形符号来表示这些元素: - 参与者(Actor):通常是人或者外部系统。 - 用例(Use Case):椭圆形符号代表...
5. **用例关系**:用例之间可能存在包含(Include)、扩展(Extend)等关系,这有助于整理和简化用例结构,提高模型的重用性和一致性。 三、面向对象用例分析 面向对象(Object-Oriented, OO)分析是用例分析的...
2. 建立状态转换树:状态转换树是一种图形化表示,显示了各个状态以及它们之间的转换关系。每个节点代表一个状态,而边线则表示状态间的转换。在播放器的例子中,我们可能会有“播放”状态到“暂停”状态的转换,...
3. 确定关系:分析用例之间的关联,如包含、扩展等。 4. 细化用例:完善用例描述,添加前置条件、后置条件和业务规则。 5. 修订和验证:与利益相关者讨论,确保用例的准确性和完整性。 六、用例在软件开发中的作用 ...
3. 关联关系:用例之间可能存在关联关系,如扩展(Extension)、包含(Include)和继承(Inheritance)。扩展表示一个用例在特定条件下执行另一个用例的行为;包含用于合并重复的步骤;继承则允许子用例重用父用例的...
本实验报告主要介绍了软件体系结构实验的整个过程,包括安装 PowerDesigner 5.X、熟悉 PowerDesigner 5.X 的常用功能、分析实例场景、识别执行者、识别用例及用例之间的关系、使用 PowerDesigner 5.X 绘制用例图、...
4. **定义用例间关系**:对用例模型进行进一步的分解,确定用例之间的“使用”关系和“扩展”关系。 5. **完善模型**:重复上述步骤,逐步形成完整的用例模型。 **在建立用例模型时应注意的问题**: - **执行者的...
4. **绘制用例图**:用图形方式表示参与者和用例之间的关系,帮助理解系统整体架构。 5. **用例关系**:包括扩展(Extends)、包含(Includes)关系,用于整合和复用用例。 四、实例解析 教程中的实例可能涉及一...
- **关联**:线状连接器,显示执行者与用例之间的关系,表明执行者可以执行哪些用例。 - **扩展关系**(扩展点):用带箭头的虚线表示,表明一个用例可以在特定条件下扩展另一个用例。 - **包含关系**(包含):表示...
4. **绘制用例图**:用图形方式表示参与者与用例之间的关系,便于理解。 5. **细化用例**:进一步细化每个用例,包括预条件、后条件、业务规则等。 在“图书管理系统用例”这个压缩包中,可能包含的是关于图书管理...
5. **用例关系**:关联(Association)定义了用例之间的依赖关系,这有助于识别和管理需求间的相互作用。例如,一个用例可能是另一个用例的前提或结果。 6. **用例场景与变种**:每个用例通常都有一个或多个场景,...
4. **建立用例关系**:通过建立用例之间的扩展和包含关系,整理用例之间的逻辑关系,使模型更加完整。 5. **验证和确认**:最后,与利益相关者一起验证和确认用例模型,确保它们准确地反映了系统需求。 #### 实践...
- **用例与用例关系**:用例之间可能存在包含、扩展等关系,这些关系可以帮助更清晰地定义系统的边界及其功能。 #### 业务用例与系统用例 - **业务用例**:描述了一个业务过程的具体工作流,可能包含手工和自动化的...
5. **分析用例之间的关系**:确定用例之间的包含、扩展等关系。 6. **评审和完善**:与其他团队成员一起评审用例图和用例描述,不断迭代完善。 #### 四、实例讨论——银行业务系统 假设我们正在设计一个银行业务...
- **识别用例**:通过与利益相关者的访谈,理解他们的需求并确定系统的核心功能。 - **描述用例**:编写简短的用例描述,包括基本流程、备选流程和异常流程。 - **绘制用例图**:用UML(统一建模语言)表示用例...