【UML】--泛化和继承
【UML】--泛化和继承
一、泛化（generalization ）
1.定义：
表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。
一般化的关系是从子类指向父类的，与继承或实现的方法相反。
泛化(generalization)是指类(父类,superclass)与其一个或多个变体(子
类,subclass)之间的关系。泛化利用类的相似性和差异来组织类，同时描述对象的结
构。父类拥有公共属性、操作和关联；子类增加了特定的属性、操作和关联。每个子类
继承(inherit)了其父类的特征。泛化有时被称作“is-a”关系，因为子类的每个实例也
都是父类的实例。
大的中空箭头表示泛化。箭头指向父类。花括号表示UML注释。
泛化是可传递的，可以跨越任意层次。术语祖先(ancestor)和后代(descendant)指的
是跨越多层的类的泛化。子类实例同时也是其所有祖先类的实例。对于每个祖先类的每
个属性，实例都有一个值。
2.例图
3.表现
父类 父类实例＝new 子类();4.举例
class Animal{};
class Tigger : public Animal{};
class Dog : public Animal{};
Animal* pAnimal = new Dog;
当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象成为父用例，
其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特
殊形式，子用例继承了父用例所有的结构、行为和关系。例如下图中：用户注册有多种
方式，可以是“现场注册”也可以是“网上注册”。所以“用户注册”用例就是“现场
注册”和“网上注册”用例的泛化。其中三角箭头指向父用例。
继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化
从UML事物关系的本质上来看，包含关系和扩展关系都属于依赖关系（所以呢，都是虚
线啦）。对包含关系而言，抽象用例中的事件流是一定会插入到基本用例中取得，并且
插入点只有一个。扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关
系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的事件流
中，并且插入点可以有多个。在实际应用中，很少使用泛化关系，子用例的特殊行为都
可以作为父用例中的备选事件流而存在。
在实际工作中，要谨慎选用这些关系。从这些介绍可以看出，包含、扩展和泛化关系
都会增加用例的个数，从而增加用例模型的复杂度。另外，一般都是在用例模型完成之
后才对它进行调整，在用例模型建立之初不必急于抽象用例之间的关系。
二、继承
1.继承的思想:
当多个类出现部分相同的实例变量和方法时,就考虑用继承
继承的使用:将多个类中相同的实例变量的方法提出来写成一个公共的父类.
2、继承方法
（1）.保留父类 对该方法的实现,(不用重写)2.案子类重写之后的方式来实现,(重写,忽视父类的实现)3.既有父类对该方法的实现,又有子类对该方法的实现.继承的上层： 父类 ，继承的下层：子类
继承是单向的，不能相互继承。
子类能继承父类全部的特征和行为.
面向对象提供了的继承语法，能够大大简化代码，把公共的方法和实例变量写在父类
里，子类只需要写自己独有的实例变量和方法即可
继承既能保证类的完整，又能简化代码，让类与类之间的关系更加紧密。
3、继承特点
没有——父类的类称为根类,OC中的根类是NSObject(祖宗)。
继承的内容:所有实例变量和方法。
如果——子类不满意父类方法的实现,可以重写父类的方法。- (void)eat{ NSLog(@"%@在吃草",_name); }
eat方法是由子类继承自父类Person中的，如果自雷需要修改父类中的实现，则只需
在类的实现部分重新定义该方法即可。
注意：super 是编译器指令，并非对象。
作用：给super发消息，可以执行父类中实现的方法。
当子类重写父类方法时，通过super执行父类的实现，又拥有自己的实现，相当于对父
类已经定义的方法做扩展。
子类可以重写父类的方法，即子类既有自己的实现，又有父类继承下来的实现，如果想
使用父类的实现，向super发送消息。
三、对比泛化和继承：
1、继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的
泛化。
2、UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use
Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子
Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同
的。如下：
●泛化侧重表示子用例间的互斥性；●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生
的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；⒉有条件发生：未必发生，发生与否取决于系统状态；
小结：
针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而
扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服 务，但用例提供服
务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包
含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用
例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事
件的备选择流而存在。