`

【转】识别用例之间的关系

阅读更多

用例间的三种关系:
(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)

当多个用例共同拥有一种类似的结构和行为的时候,我们可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。



以下是一个用例泛化关系的例子,执行交易是一种交易抽象,执行房产交易和执行证券交易都是一种特殊的交易形式。

用例泛化关系中的事件流示例如下:



 

分享到:
评论

相关推荐

    软件工程一体化案例

    详细描述了“数字软件学院”的业务用例模型(3.4节),包括识别相关的业务执行者和业务用例,分析业务用例之间关系,对业务用例进行精化和结 需求的案例主要是门户网站和教务学分查询系统。详细介绍了这两个案例的...

    uml实验报告整合

    1.识别分析类之间的关系、类的属性和操作。 2.使用ROSE软件构建系统的分析类图。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 根据***系统开发进度,在完成对系统的需求建模,得到...

    uml rational rose

    1.识别分析类之间的关系、类的属性和操作。 2.使用ROSE软件构建系统的分析类图。 二、实验器材 1.计算机一台。 2.Rational Rose 工具软件。 三、实验内容 根据***系统开发进度,在完成对系统的需求建模,得到...

    《UML建模实例教程》【PPT】

    5.3.1识别用例 5.3.2绘制WebShop电子商城用例图 5.3.3通过包对用例进行合理规划 5.3.4WebShop电子商城用例图(不含关系) 5.3.5用例描述 5.4用例间的关系 5.4.1泛化关系 5.4.2使用关系 5.4.3包含关系 5.4.4...

    UML实验报告(3).doc

    识别用例及用例之间的关系; 5. 使用PowerDesigner15.1绘制用例图; 6. 撰写用例文档; 7. 模型检查; 8. 识别系统的类; 9. 识别类的属性和方法; 10. 识别类之间的关系; 11. 使用PowerDesigner15.1绘制类图; 12...

    GIS软件工程实验要求.doc

    实验一:系统分析(4课时) 一、实验目的 自选开发项目的题目,说明项目的需求,在此基础上完成系统的用例分析... 3、用例之间有哪几种关系?怎样表示? 4、怎样组织对该工作的评审? 实验二:软件开发系统设计(4课时

    面向对象与UML资料

    确定执行者和用例之间的关系 60 确定最初的分析对象 62 确定非功能性需求 63 从用户得到信息的方法 64 第六章 需求分析概述 64 需求分析的概念 65 概念模型 65 实体对象,边界对象,控制对象 67 回顾关系重数 68 ...

    大数据与人工智能的关系.docx

    人工智能 机器学习 深度学习 大数据平台 机器学习是人工智能的子集,深度学习是机器学习的子集,但是深度学习的影响是最大的,比如图像识别、语音识别、语义识别。 常用框架: Scikit-Learn: 基于 Python 语言的机器...

    UML基础、案例与应用(第三版)].施穆勒.扫描版_2分.pdf

    7.2 用例之间关系的可视化表示 70 7.2.1 包含 70 7.2.2 扩展 71 7.2.3 泛化 72 7.2.4 分组 73 7.3 用例图在分析过程中的作用 73 7.4 运用用例模型:举例 73 7.4.1 理解领域 73 7.4.2 理解用户 74 7.4.3 理解用例 75 ...

    UML和模式应用(架构师必备).part01.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part07.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part02.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part06.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part03.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part04.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part05.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    UML和模式应用(架构师必备).part08.rar

    10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考...

    仓库管理系统课程设计UML.doc

    这样可以得到相关的三种类关系: 人员信息包类图 接口信息包类图 系统事务信息包类图 2)确定类之间的关系 两个类之间的相互依赖就是关联,关联常用描述性动词或动词组来表示,其中有物理 位置的表示、传导的动作、...

    软件工程-理论与实践(许家珆)习题答案

    它还涉及到这些因素和系统的精确规格说明,以及系统进化之间的关系。 需求分析的基本任务包括: (1) 抽取需求 分析现行系统存在需要解决的问题。获取足够多的问题领域的知识,需求抽取的方法一般有问卷法、面谈法...

    数据工程师纳米学位项目Udacity:由Udacity.com在数据工程师纳米学位计划中完成的项目

    识别不同类型的数据库和数据存储技术的优缺点 在Postgres和Apache Cassandra中创建表 关系数据模型 了解何时使用关系数据库 了解OLAP和OLTP数据库之间的区别 创建规范化的数据表 实现非规范化模式(例如STAR,...

Global site tag (gtag.js) - Google Analytics