再看包括、扩展和泛化、继承

我们知道包括和扩展是用例图中所特有的关系,而泛化和继承则不仅用于用例图,同一时候也适用于其它图,如类图。这两对概念相信对于学习面向对象中的我们来说是非常easy混淆的,非常多时候自己都不知道包括和扩展箭头究竟该指向哪里,是虚线还是实线,泛化究竟跟继承什么关系?常常为此大家争

得面红耳赤,以下我就来捋一捋(本篇博客想要表达的意思已经用红色标出,假设有什么不妥之处欢迎批评不吝赐教~)。

(1)   包括(include)关系

当能够从两个或两个以上的用例图中提取公共行为时,应该使用包括关系来表示它们。当中这个提取出来的公共用例成为抽象用例,而把原始用例成为基本用例或基础用例。比如,图1中的“登记外借信息”和“查询外借信息”两个用例都须要登陆,为此,能够定义一个抽象用例“用户登录”。用例“登记外借信息”和“查询外借信息”与用例“用户登录”之间的关系就是包括关系。当中<<include>>是包括关系的构造型,箭头指向抽象用例。

当多个用例需用使用同一段事件流时,抽象成为公共用例,能够避免在多个用例中反复地描写叙述这段事件流,也能够防止这段事件流在不同用例中的描写叙述出现不一致。当须要改动这段公共的需求时,也仅仅要改动一个用例,避免同一时候改动多个用例而产生的不一致性和反复性工作。另外,当某个用例的事件流过于复杂时,为了简化用例的描写叙述,也能够将某一段事件流抽象成为一个被包括的用例。

(2)   扩展(extend)关系

假设一个用例明显的混合了两种或两种以上的不同场景,即依据情况可能发生多种分支,则能够将这个用例分为一个基本用例和一个或多个扩展用例,这样使描写叙述可能更加清晰。如上图中的图书管理员进行“查询书籍信息”操作时,假设发现书籍信息有误,他能够使用“改动书籍信息用例来完毕错误的改动。所以用例“查询书籍信息”和“改动书籍信息”之间的关系就是扩展关系。当中<<extend>>是扩展关系的构造型,箭头指向基本用例。

(3)   泛化和继承

当多个用例共有一种类似的结构和行为时,能够将它们的共性抽象成为父用例,其它的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例全部的结构、行为和关系。比例如以下图中:用户注冊有多种方式,能够是“现场注冊”也能够是“网上注冊”。所以“用户注冊”用例就是“现场注冊”和“网上注冊”用例的泛化。当中三角箭头指向父用例。

而继承关系是泛化关系的反关系,也就是说子类是从父类继承的,而父类则是子类的泛化。

从UML事物关系的本质上来看,包括关系和扩展关系都属于依赖关系(所以呢,都是虚线啦)。对包括关系而言,抽象用例中的事件流是一定会插入到基本用例中取得,而且插入点仅仅有一个。扩展用例的事件流往往能够抽象为基本用例的备选事件流,在扩展关系中,能够依据一定的条件来决定是否将扩展用例的事件流插入到基本用例的事件流中,而且插入点能够有多个。在实际应用中,非常少使用泛化关系,子用例的特殊行为都能够作为父用例中的备选事件流而存在。

在实际工作中,要慎重选用这些关系。从上面的介绍能够看出,包括、扩展和泛化关系都会添加?用例的个数,从而添加?用例模型的复杂度。另外,一般都是在用例模型完毕之后才对它进行调整,在用例模型建立之初不必急于抽象用例之间的关系。

再看包括、扩展和泛化、继承

时间: 2024-10-17 23:08:51

再看包括、扩展和泛化、继承的相关文章

再看属性查找

再看属性查找 结合python继承的实现原理+元类重新看属性的查找应该是什么样子呢??? 属性查找的原则:对象->类->父类 切记:父类 不是 元类 在学习完元类后,其实我们用class自定义的类也全都是对象(包括object类本身也是元类type的 一个实例,可以用type(object)查看), 我们学习过继承的实现原理,如果把类当成对象去看,将下述继承应该说成是:对象StanfordTeacher继承对象Foo,对象Foo继承对象Bar,对象Bar继承对象object class Mym

用例图中的三种关系包括、扩展、泛化

用例图使用户 与开发者交流的一种重要的方式,是对用户需求的一种描写叙述.开发者从用户的角度总体上理解系统的功能. 用例图主要有三种元素:參与者(Actor).用例.以及用例图中对象间到的关系.当中关系有包括.扩展是用例图中特有的,泛化在其它类图中相同存在. 包括:当能够从两个或两个以上的用例中提取公共行为时,应该使用包括的关系来表示它们.当中这个提取出来的公共用例成为抽象用例.而把原始用例成为基本用例或基础用例.当中"<<include>>"是包括关系的构造型,

再看Ajax

再回顾Ajax相关的内容,再次梳理学习还是很有必要的,尤其是实际的开发中,ajax更是必不可少,仔细学习以便避免不必要的错误. 文章导读: --1.使用XMLHttpRequest---------- 1.1 必备知识点 1.2 send()方法 1.3  再看CORS --2.HTTP请求和响应---------------- 2.1 Request Header中的参数 2.2 Response Header中的参数 2.3 GET请求和POST请求的区别 --3.jQuery中的Ajax-

用例图中的三种关系包含、扩展、泛化

用例图使用户 与开发人员交流的一种重要的方式,是对用户需求的一种描述.开发人员从用户的角度整体上理解系统的功能. 用例图主要有三种元素:参与者(Actor),用例,以及用例图中对象间到的关系.其中关系有包含.扩展是用例图中特有的,泛化在其他类图中同样存在. 包含:当可以从两个或两个以上的用例中提取公共行为时,应该使用包含的关系来表示它们.其中这个提取出来的公共用例成为抽象用例,而把原始用例成为基本用例或基础用例.其中"<<include>>"是包含关系的构造型,

再看ftp上传文件

前言 去年在项目中用到ftp上传文件,用FtpWebRequest和FtpWebResponse封装一个帮助类,这个在网上能找到很多,前台使用Uploadify控件,然后在服务器上搭建Ftp服务器,在本地测试程序上传到ftp服务器一点问题都没有,奇怪的是当发布Web和ftp到同一个IIS下,上传文件时程序直接卡死,然后页面卡死,后来我又发现把Web和ftp分开发布在两台机器上问题又得到解决,所以当时放弃了这个方案. 再看ftp上传文件 前几天偶然看到Wolfy写到一个项目总结,其中提到了用Ser

再看数据库——(7)游标

背景: 其实<再看数据库>系列博客本没有计划写这么多,但最近确实接触数据库比较多,又接触了这些东西,在之前很少用到,因此就整理下,和大家分享. 简介: 游标,是一个数据缓冲区,用来存放SQL语句的执行结果.与一般的执行过程不同的是,游标是从结果集中每次提取一条记录. 与关系数据库的区别: 关系数据库--面向集合,一般执行结果都是一个集合,如果要选择其中一条或几条记录,就要用where子句. 游标     --面向单条记录.游标可以对查询语句返回的结果集中的每一行进行相同或不同的操作. 因此说,

再看Cassandra 之NOSQL 数据库

Cassandra或许不会因为是NoSQL而得到关注,但是它在完成某些特定工作上,有迷人的魅力,这Netflix和Instagram两家公司一定知道. 过去的这些年,NoSQL的参与者,例如MongoDB已经得到了快速发展,受到了非常多的关注,但是 Apache Cassandra的光环褪去,作为创造了Cassandra的Facebook已经放弃了它,Cassandra的社区也好像过时了快.但 是Cassandra的命运迎来的转机,Netflix近来决心把他们自己的数据中心的oracle改成Ca

再看数据库——(3)触发器

概念: 触发器,顾名思义,它是由事件来触发的.比如当我们对表进行操作时就会激活它执行. 说到触发器,还要提一个关键点,那就是"保持数据完整性".什么意思呢?比如业务需求是,当我们注销一个卡号时,把该卡的充值.上机等信息也一并删除.这时如果是一个一个操作执行,就会是:注销卡--删除卡的充值信息--删除卡的上机信息(两个删除操作不分先后).这样做的弊端是,我们很容易把其中的一个步骤遗漏了,业务也不完整.用了触发器以后,当我们注销卡时激活触发器执行删除操作. 用触发器的好处就是很大程度上有利

UML用例图中包含、扩展和泛化的区别

在软考复习下午题的时候,涉及UML图时会有一个知识点就是用例图中包含.扩展和泛化的区别.这里我们就来总结一下. 1.包含<<include>> 包含是指当多个用例中存在相同的事件流时,可以把这些公共事件流抽象成公共用例,这个公共用例称之为抽象用例(跟类的概念有点相像,类是多个对象的抽象定义),而原始用例称为基础用例,基础用例与抽象用例之间就是包含关系.但是值得注意的是,对于包含关系而言,基础用例是抽象用例执行中不可缺少的一部分,基础用例一般不单独存在且基础用例不知道抽象用例的存在而