UML中扩展和泛化的区别
用例图:
用例图主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作,通俗地理解用例就是软件的功能模块,所以是设计系统分析阶段的起点,设计人员根据客户的需求来创建和解释用例图,用来描述软件应具备哪些功能模块以及这些模块之间的调用关系,用例图包含了用例和参与者,用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户),对应的是软件的结构和功能分解。
用例是从系统外部可见的行为,是系统为某一个或几个参与者(Actor)提供的一段完整的服务。从原则上来讲,用例之间都是独立、并列的,它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系,提高可维护性和一致性,用例之间可以抽象出包含(include)、扩展(extend)和泛 (generalization)几种关系。
共性:都是从现有的用例中抽取出公共的那部分信息,作为一个单独的用例,然后通后过不同的方法来重用这个公共的用例,以减少模型维护的工作量。
1、包含(include)
包含关系:使用包含(Inclusion)用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基(Base)用例复用。基用例控制与包含用例的关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用,也就是定义中说的情景。但是有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。这种情况类似于在过程设计语言中,将程序的某一段算法封装成一个子过程,然后再从主程序中调用这一子过程。
例如:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend)
扩展关系:将基用例中一段相对独立并且可选的动作,用扩展(Extension)用例加以封装,再让它从基用例中声明的扩展点(Extension Point)上进行扩展,从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
对于一个扩展用例,可以在基用例上有几个扩展点。
例如,系统中允许用户对查询的结果进行导出、打印。对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。导入、打印和查询相对独立,而且为查询添加了新行为。因此可以采用扩展关系来描述:
4、泛化(generalization)
泛化关系:子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
例如,业务中可能存在许多需要部门领导审批的事情,但是领导审批的流程是很相似的,这时可以做成泛化关系表示:
上面是我参考的一篇文章,觉得将三种关系的区别讲得很清晰,在此基础上结合自己的系统,对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1)系统整体用例图
(商品用例图)
(购买信息用例)
(用户资料用例)
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case,并将不可合并部分单独成各自的子Use Case;包含以及扩展过程与泛化过程类似,但三者对用例关系的优化侧重点是不同的。如下:
●泛化侧重表示子用例间的互斥性;
●包含侧重表示被包含用例对Actor提供服务的间接性;
●扩展侧重表示扩展用例的触发不定性;详述如下:
既然用例是系统提供服务的UML表述,那么服务这个过程在所有用例场景中是必然发生的,但发生按照发生条件可分为如下两种情况:
⒈无条件发生:肯定发生的;
⒉有条件发生:未必发生,发生与否取决于系统状态;
因此,针对用例的三种关系结合系统状态考虑,泛化与包含用例属于无条件发生的用例,而扩展属于有条件发生的用例。进一步,用例的存在是为Actor提供服 务,但用例提供服务的方式可分为间接和直接两种,依据于此,泛化中的子用例提供的是直接服务,而包含中的被包含用例提供的是间接服务。同样,扩展用例提供的也是直接服务,但扩展用例的发生是有条件的。
另外一点需要提及的是:泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
分享到:
相关推荐
在 UML 用例图中,包含、扩展和泛化是三种基本关系,它们之间的区别和联系对正确理解 UML 用例图至关重要。 包含关系(Include) 包含关系是一种基本关系,它允许将一个用例拆分为多个小的用例,以便重用和简化...
用例的关系有泛化(generalization)、扩展(extend)和包含(include)。其中include和extend最易混淆。下面我们结合实例彻底理清三者的关系。基本概念用例图(UseCaseDiagram):用例图显示谁是相关的用户,用户希望系统...
"UML.rar_dependent UML_uml _软件工程泛化"这个标题表明了压缩包的内容主要关注UML中的泛化关系,以及与之相关的其他概念,如依赖、关联、聚合和合成。接下来,我们将深入探讨这些概念。 首先,泛化是UML中的一种...
在 UML 用例图中,包含、扩展和泛化是三种基本关系,它们之间的区别和应用场景是开发者需要掌握的重要知识。本文将对 UML 用例图的包含、扩展和泛化进行详细阐述,并探讨它们之间的区别和应用场景。 包含关系...
### UML中依赖、泛化、关联、聚合与组合的Java实现详解 #### UML基础知识概览 统一建模语言(UML)作为一种图形化的标准化建模语言,为软件开发提供了强大的可视化工具,帮助开发者理解、设计和记录软件系统。UML...
UML 类图关系大全中有多种关系,包括泛化、关联、依赖、聚合、组合等。 1. 关联关系 关联关系是类图中最基本的关系类型。它描述了类之间的相互关系,可以是单向的,也可以是双向的。双向关联关系表示两个类之间的...
【UML类与构件及扩展】深入探讨 UML(统一建模语言)是一种标准化的图形建模语言,用于软件工程和其他领域中的系统建模。它包括类、对象、用例、关系等概念,帮助开发者理解和设计系统的结构和行为。在本章中,我们...
用例图显示了参与者与用例之间的关系,以及用例之间的包含、扩展和泛化关系。用例分析是需求理解的关键步骤,有助于确定系统的边界和功能。 7. **状态图**:状态图用于描述对象在其生命周期中的状态变化和转换。它...
UML(统一建模语言)是软件工程中用于标准化软件系统模型的图形化语言,而Java是一种广泛使用的面向对象的编程语言。...理解UML与Java之间的对照关系对于构建高质量、可维护和可扩展的软件系统是至关重要的。
《UML2软件建模入门与提高》是一个涵盖了软件开发中的统一建模语言(Unified Modeling Language,简称UML)的全面教程。UML是软件工程领域广泛应用的一种可视化建模工具,用于描述、构造和文档化软件系统的设计。本...
2. **元素与关系**:在UML中,有多种基本元素,如类、接口、对象、用例、关联、依赖、泛化(继承)、实现等。这些元素通过不同的关系相互连接,形成了复杂的系统模型。 3. **注释与约束**:UML允许添加注释...
### UML元模型Specification知识点详解 #### 一、UML元模型概述 统一建模语言(Unified Modeling ...此外,了解UML元模型的规范与标准也有助于确保在实际应用中能够正确地遵循这些规范,避免潜在的问题和误解。
1. **UML的扩展机制**:例如 stereotypes( Stereotypes)用于定制和增强UML的语义,以及 tagged values 和 constraints 的使用。 2. **包和命名空间**:如何组织和管理UML模型,以保持模型的清晰性和可维护性。 3. ...
本文将深入解析UML中的四种基本关系:泛化(Generalization)、关联(Association)、依赖(Dependency)和聚合(Aggregation),并提供具体的实例和代码示例。 #### 泛化(Generalization) 泛化关系体现了类之间的...
其中,关联表示两个或多个类之间的连接,聚合和组合是特殊的关联,分别表示整体与部分的关系,区别在于组合关系中部分对象的生命期与整体紧密相连;依赖关系表示一个类对另一个类的依赖性;泛化关系表示继承关系,即...