UML学习——简述类以及类之间的关系
UML学习——简述类以及类之间的关系
计算机所实现的各种程序，本身就是对现实世界的一种真实性模拟，无论是小程序，还是大程序，都不可避免地依照现实世界尽可能模拟甚至通过模拟超越现实。真实世界是由各式各样的事物所组成，每种事物都有它特有的结构和行为，而且在联系起不同事物之后，还能够展现出丰富多元的能力；在面相对象的编程思想中，将事物以类的形式定义，类和类之间的关系就是不同事物的联系，由类和类之间的关系将真实世界以计算机程序来模拟真实世界。
面向对象概念是UML的基础，在学习使用UML的同时，也就是在应用面向对象概念；头脑里装有面向对象的概念，才能将需求文件内容以UML图的形式表述出来，UML与面向对象概念两者互为表里。
类是面向对象的基础，包括属性和方法两部分，属性表述类的特征，方法表证了类的行为；不同类之间的关系共同模拟了复杂的真实世界，实现了计算机程序对现实世界的真实模拟。
在面向对象和UML的概念中，类和类之间的关系，主要有：泛化关系、依赖关系、关联关系、聚合关系、组合关系。
1、泛化关系（Generalization）表现为继承或实现关系（is a），具体形式为类和类
之间的继承关系、接口和接口之间的继承关系、类和接口之间的实现关系。
2、依赖关系（Dependency）表现为函数中的参数（use a）；是类和类之间的连接，
表示一个类依赖另一个类的定义，其中一个类的变化将影响另外一个类，如果
A类依赖于B类，则B类体现为局部变量，方法的参数、或静态方法的调用。
3、关联关系（Association）表现为变量（has a）；类和类之间的联接，它使一个类
知道另一个类的属性和方法，如果A关联于B，则B体现为A的全局变量，即作为A的属性。
4、聚合关系（Aggregation）是关联关系的一种，是强的关联关系，强调整体与个
体的关系；普通关联关系的两个类处于同一个层次上，而聚合关系的两个类处于不同的层次，一个是整体（Whole），一个是部分（Part），是一种弱的“拥有”
关系。体现的是A对象可以包含B对象，但B对象不是A对象的组成部分，即A和B的生命周期不一样；具体表现为，如果A由B聚合成，表现为A包含有B的全局对象，但是B对象可以不在A创建的时刻创建，A和B拥有不同的生命周期。
5、组合关系（Composition）是关联关系的一种，是比聚合关系强的关系，是一种
强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一致。如果A由B组成，表现为A包含有B的全局对象，并且B对象在A创建的时刻创建，A和B拥有相同的生命周期，二者一毁俱毁。
6、类和类之间关系的小总结：
泛化关系：表现为类和类之间、接口和接口之间的继承，类和接口的实现关系依赖关系：A依赖于B，则B作为A方法的参数或者静态方法对B的调用
关联关系：A关联于B，则B作为A的全局属性出现，但A和B属于同一层次聚合关系：A由B聚合，则B作为A的全局变量出现，强调B是A的部分，A 和B的生命周期不相同
组合关系：A由B组合，则A包含有B的全局对象，B对象在A创建的时刻创建，A和B拥有相同的生命周期，强调A全然拥有B，多为内部类
UML中各种图的画法(全)
UML中各种图的画法(全) 一、UML中基本的图范畴： 在 UML 2 中有二种基本的图范畴：结构图和行为图。每个 UML 图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类，组件和（或）对象图。另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。行为图的实例是活动图，用例图和序列图。 二、UML中的类图： 1.类图的表示： 类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。 描述： 顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。 ·类名：如果是抽象类，则采用斜体 ·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式 n ame : attribute type = default value 如balance : Dollars = 0，这是带有默认值的表达形式 ·类方法列表：name(parameter list) : type of value returned
注意： 在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。 2.继承的表示： 为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。 类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount 类使用withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。 3.接口的表示： 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。
UML类图符号简介
UML类图符号简介 1. 类（Class）：使用三层矩形框表示。 第一层显示类的名称，如果是抽象类，则就用斜体显示。 第二层是字段和属性。 第三层是类的方法。 注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。 2. 接口：使用两层矩形框表示，与类图的区别主要是顶端有<
UML中继承实现依赖关联聚合组合的联系和区别_线条箭头
UML中几种类间关系：继承、实现、依赖、关联、聚合、组合的联系与区别 继承 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性； 实现 指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性； 依赖 可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过
河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用； 关联 他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我与我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量； 聚合 聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，与关联关系是一致的，只能从语义级别来区分； 组合
UML用例图三种关系详解
1UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend) 扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。 对于一个扩展用例，可以在基用例上有几个扩展点。 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
UML各种图详解
父用例通常是抽象的。
1 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。 2》UML 支持的可见性类型的标志 3》多重值和它们的表示
4》类图之间的关系有：泛化（继承），依赖，关联，聚合/组合。 1.聚合/组合 聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。 举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期-- 这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。 ·基本聚合（聚合） 有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。 图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。 ·组合聚合（组合） 组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。 注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。 2.依赖 依赖可以说是要完成C5里的所有功能，一定要有C6的方法协助才行 3.关联 可以分为单向关联，双向关联
uml中的关系
uml中的关系 1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。 单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下：
class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。 自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下： class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。
聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。 代码如下： class C9 ...{ public: C10 theC10; }; class C10 ...{ }; 组合（也有人称为包容）：一般是实心菱形加实线箭头表示，如上图所示，表示的是C8被C7包容，而且C8不能离开C7而独立存在。但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里，就算轮胎离开了汽车，它也是有意义的，这就可以用聚合了。在《敏捷开发》中还说到，A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B 的生成和释放。 他们的代码如下： class C7 ...{ public: C8 theC8; }; class C8 ...{ }; 可以看到，代码和聚合是一样的。具体如何区别，可能就只能用语义来区分了。 3、依赖
UML中的六大关系
在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency) 1. 泛化（Generalization） 【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头指向】：带三角箭头的实线，箭头指向父类 2. 实现（Realization） 【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现. 【箭头指向】：带三角箭头的虚线，箭头指向接口
3. 关联（Association) 【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】：成员变量 【箭头及指向】：带普通箭头的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 下图为自身关联：
4. 聚合（Aggregation） 【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。 聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。 【代码体现】：成员变量 【箭头及指向】：带空心菱形的实心线，菱形指向整体 5. 组合(Composition) 【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。 组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
UML中类图实例
UML中类图实例 接口：空心圆+直线（唐老鸭类实现了…讲人话?）； 依赖：虚线+箭头（动物和空气的关系）； 关联：实线+箭头（企鹅需要知道气候才迁移）； 聚合：空心四边形+实线+箭头（雁群和大雁的关系）； 合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化/继承：空心三角形+实线（动物和鸟的继承关系）；实现：空心三角形+虚线（实现大雁飞翔的接口）； UML类图 解释UML类图：
1. 首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称，如果 是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。 注意前面的符号，…+?表示public, …—? 表示private, …#?表示protected. 2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第 一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。 interface IFly interface Ilanguage { { void Fly(); void Speak(); } } 3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表 示。
4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中应为 空心三角形） class Bird:Animal class WideGoose:IFly { { //继承动物类 //实现飞翔接口 } } 5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。当一 个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。 class Penguin :Bird { private Climate climate;//在企鹅Penguin中，引用到气候Climate对象 } 6. “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个雁群可 以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有” 关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+ 实线箭头表示。
UML类图关系大全
1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在 GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。
单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下： class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。 自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下：
class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。 聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。 代码如下： class C9 ...{ public: C10 theC10; }; class C10 ...{
UML用例图三种关系详解
. 和泛化(extend)(include)、扩展1UML用例图中包含(generalization）三种关系详解 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。 ;. . (extend)、扩展2 ）用扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）上进行扩展，Extension Point例加以封装，再让它从基用例中声明的扩展点（扩展扩展用例为基用例添加新的行为。从而使基用例行为更简练和目标更集中。因此它能根据基用例中扩展点的当前状态来判断是用例可以访问基用例的属性，但
UML用例图中的包含、扩展、泛化关系
UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend) 扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。 对于一个扩展用例，可以在基用例上有几个扩展点。 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
UML中类图实例
创作编号： GB8878185555334563BT9125XW 创作者：凤呜大王* UML中类图实例 接口：空心圆+直线（唐老鸭类实现了‘讲人话’）； 依赖：虚线+箭头（动物和空气的关系）； 关联：实线+箭头（企鹅需要知道气候才迁移）； 聚合：空心四边形+实线+箭头（雁群和大雁的关系）； 合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化/继承：空心三角形+实线（动物和鸟的继承关系）； 实现：空心三角形+虚线（实现大雁飞翔的接口）； UML类图
解释UML类图： 1. 首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称， 如果是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。 注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected.
2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显 示，第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。 interface IFly interface Ilanguage { { void Fly(); void Speak(); } } 3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实 现来表示。 4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中 应为空心三角形）
class Bird:Animal class WideGoose:IFly { { //继承动物类 //实现飞翔接口 } } 5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。 当一个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。 class Penguin :Bird { private Climate climate;//在企鹅Penguin中，引用到气候Climate对象 } 6. “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个 雁群可以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+ 实线箭头表示。
Uml 类图中六种关系
Uml 类图中六种关系 1.泛化（继承） 泛化也就是继承，A是父类，B是子类，就称B泛化（继承）了A。在这里泛化可以理解成，是功能的一种延伸，因为B拥有A的特性，并且可以在自己的类中增加新的方法。 2. 实现 这个关系用于定义接口和实现类之间的关系。 3. 关联 关联关系表示两个类之间有持久的联系,会增加被依赖对象的成员变量（如下代码），不过关联对象的赋值是在调用某种方法的时候。
class A{ B b; public void XXX(B b){ this.b=b; }; } 上述代码表示：A关联B。例子：关联关系就好像电脑和鼠标，电脑的配置是包括鼠标的，但是到了具体需要鼠标的时候，才会用到鼠标。所以说：类A 关联类B，B则是A中不可或缺（成员变量）但是不急着使用（延迟赋值）的一部分。 4. 依赖 依赖关系不会产生成员变量，往往就是某个方法调用的时候，传入的参数会有被依赖的对象。 class A{ public void XXX(B b){}; } 上述代码表示：A依赖B 例子：依赖关系就好比人和鼠标，人的配置当然不可能包括鼠标，但是人要玩电脑的时候，就需要鼠标。 所以说：类A依赖类B，则B不是A的配件（成员变量），但是A在需要实现某个功能的时候需要B（作为参数传递进来）。
5. 聚合 class A{ B b; A(B b){ this.b=b } } 聚合可以称作为强关联关系，当一个类聚合另一个类的时候，这个类A在自己实例化时就会给关联的这个对象B赋值。不过，这里关联对象B的实例化不是在A中，所以，B的生存与否，不是由A决定。 例子：汽车和轮胎，汽车必须有轮胎才能跑，但是轮胎的生产，可以不在汽车厂而是在别处，轮胎离开这辆汽车，也可以安到其他同型号的汽车上。 所以说：类A聚合类B，B则是A不可或缺的一部分，B的赋值在A实例化的时候，但是B的实例化在A的外部，B的生存周期与A无关。 6.组合 class A{ B b; A(){ this.b=new B() }
UML如何描述类之间的关系
UML中类之间的关系 UML(The Unified Modeling Language)就是统一建模语言，不论它是怎么发展来的，也不论最新的官方Specification或工业标准是哪个版本，我想总结一下工作中最常用的一些知识：用UML语言描述类的关系。 1，关联关系(Association) 关联关系是类(也可以说是对象)之间特定的对应关系。按照对象的数量对比，可以分为： A 一对一 比如公民和公民身份卡之间的对应关系。 B 一对多 一个部门对应0或者多位员工，一般而言一位员工只能属于某一个部门。 C 多对多 用户和服务是多对多的关系，一个用户可以注册0个或多个服务，一个服务则可以被0个或者多个用户复用。比如Windows Live用户可以激活邮件服务、Space服务等，而这些服务不是被一个用户所专有的。
关联的实质 从A类型到B类型的关联是指在A类型中定义了B类型作为属性。如下列代码：package uml; public class Citizen { private CitizenshipCard card; //其他属性 public CitizenshipCard getCard() { return card; } public void setCard(CitizenshipCard card) { this.card = card; } } 上述代码演示了从Citizen 到CitizenshipCard 的关联。注意下图箭头方向： 同样可以建立CitizenshipCard 到Citizen 的关联： 代码表示为： package uml; public class CitizenshipCard { private Citizen citizen; //其他属性
UML类图中的几种关系总结
UML 类图中的几种关系 区分 UML 类图中的几种关系 UML 类图中的”关联关系(association) “、”聚合关系(aggregation) “、”合成关系(compostion)“ 和”依赖关系(dependency)“ 不是很容易区分清楚，《UML distilled》对这几个关系也没有解释的特别清楚。近日翻阅《Java 与模式》，发现其中对这些关系有较为清晰的描述，特摘录如下： 关联关系 (association)： (1)关联关系是类与类之间的联结，它使一个类知道另一个类的属性和方法。 (2)关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 (3)在 Java 或 c++ 中，关联关系是通过使用成员变量来实现的。 class 徒弟 { }; class 唐僧 { protected: list<徒弟> tdlist; }; 聚合关系 (aggregation)： 1、聚合关系是关联关系的一种，是强的关联关系。 2、聚合是整体和部分之间的关系，例如汽车由引擎、轮胎以及其它零件组成。 3、聚合关系也是通过成员变量来实现的。但是，关联关系所涉及的两个类处在同一个层次上，而聚合关系中，两个类处于不同的层次上，一个代表整体，一个代表部分。 4、关联与聚合仅仅从 Java 或 C++ 语法上是无法分辨的，必须考察所涉及的类之间的逻辑关系。 class 引擎 { }; class 轮胎 { };
class 汽车 { protected: 引擎 engine; 轮胎 tyre[4]; }; 合成关系 (composition)： 1、合成关系是关联关系的一种，是比聚合关系还要强的关系。 2、它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。 1 class 肢 { }; class 人 { protected: 肢 limb[4]; }; 依赖关系 (dependency)：
UML中的4种关系
UML中的4种关系 在UML中共有四种关系，这些关系主要描述类和类之间的联系，当然也可以表示用例和用例之间，角色和角色之间的联系。 这四种关系分别是： 关联，依赖，泛化，实现。 下面对这几种关系分别进行介绍。 关联 普通关联 普通关联是最常见的关联关系，如下图所示
注：其中job叫做关联名，employee和employer是角色名；这些都是对关联的修饰 关联关系在具体编程中通常这样表示：一个类作为另一个类的一个属性，如下图所示 关联按照相互性又可分为单向关联（A类是B类的一个属性，而B类却不是A类的属性）和双向关联（A是B得属性，B也是A的属性）
两个类之间可以有多种关系，一个类也可以与多个类发生关系 如果一个类的一个实例对象和另一个实例对象有关联关系，那么我们称之为内部关联
除了普通关联外，还有两种关联是表示整体与部分之间的关系的，他们分别叫做聚合和组合 聚合 聚合表示的总体和部分之间的关系比较弱，部分可以脱离总体而单独存在，二者在时间先后上没有必然关系。
在上图中书和书架都是单独存在的。 组合 组合表示的整体和部分之间的关系比较强，部分不能脱离总体而单独存在，在时间上先有整体才能有部分。
上图中人上提上的任何一部分都不能脱离整体而单独存在，所有的部分都必须属于一个整体。 依赖 依赖关系用一个英文单词可以形象的表示，这个单词是“Using”，即依赖描述的是一种使用关系。 在代码实现时，通常是一个类是另一个类的某个方法的形参，或者在方法的具体实现中用到了那个类。 1中通过“Course”类作为“Professor”类“teach”方法的参数类型来实现
UML中的五种关系
UML中的五种关系（转） 关于设计模式的总结没有落实到代码上，而且设计模式自己确实动手实现的非常少。所以在这一周里，除了看网站开发的视频，着手开始对设计模式进行实现以下。设计模式非常经典，每次看都有不同的收获，写一下自己的收获吧，请大家指正。 在实现设计模式之前，首先来复习以下UML中的五种关系图 <1>依赖 依赖关系用虚线加箭头表示,如图所示: 上图表示:Animal类依赖于Water类（动物依赖于水）。 依赖是类的五种关系中耦合最小的一种关系。因为依赖关系在生成代码的时候，这两个关系类都不会增加属性。这种微弱的关系可以用类之间的相互了解的程度来说明。(下图为代码生成图) 由上图可见生成的代码中Animal类的属性中没有增加Water类。那么Animal 类如何使用Water类呢，有三种方式： 依赖关系的三种表现形式： ①Water类是全局的，则Animal类可以调用它 ②Water类是Animal类的某个方法中的变量，则Animal类可以调用它。代码演示如下：
PS：Animal有一个长大（GrownUp）方法，Water类作为该方法的变量来使用。请注意Water类的生命期，它是当Animal类的GrounUp方法被调用的时候，才被实例化。 持有Water类的是Animal的一个方法而不是Animal类，这点是最重要的。 ③Water类是作为Animal类中某个方法的参数或者返回值时。代码演示如下 无用多说，Water类被Animal类的一个方法持有。生命期随着方法的执行结束而结束。 在依赖关系中，必须采用这三种方法之一。 <2>关联 关联是实线加箭头表示。表示类之间的耦合度比依赖要强。 例：水与气候是关联的，表示图如下 生成代码如下：
UML类图关系(泛化、继承、实现、依赖、关联、聚合、组合)
继承、实现、依赖、关联、聚合、组合的联系与区别 分别介绍这几种关系： 继承 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java 中此类关系通过关键字extends明确标识，在设计时一般没有争议性； 实现 指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性； 依赖 可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method 方法中使用；
关联 他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量； 聚合 聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分； 组合 组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联关系是一致的，只能从语义级别来区分； 对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别的，所以从代码层面并不能完全区分各种关系； 但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖；
UML类之间的关系总结
在UML图中，类之间的关系有如下几种： ①关联关系：Association ②聚合关系：Aggregation ③组合关系：Composition ④依赖关系：Dependency ⑤泛化关系：Generalization ⑥实现关系：Realization 下面对每个关系做简要说明并配上UML类图： ①关联关系：关联关系是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。在UML类图中，用实线连接有关联的对象所对应的类，在使用C#、C++和Java等编程语言实现关联关系时，通常将一个类的对象作为另一个类的属性。下面是UML类图： Person类拥有自行车Bicycle，两个类之间为关联关系 ②聚合关系：聚合关系表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。在聚合关系中，成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。在UML中，聚合关系用带空心菱形的直线表示。UML类图如下： 雁群里面包含了大雁，所以大雁与雁群间是聚合关系 ③组合关系：组合关系也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。在组合关系中，成员类是整体类的一部分，而且整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。在UML中，组合关系用带实心菱形的直线表示。UML类图如下：
人由大脑组成，所以人跟大脑是组合关系。 注意：聚合关系和组合关系非常类似，他们都表示类与类之间部分与整体的关系，但是区别也很明显：聚合关系中成员对象类可以脱离整体类而独立存在（如上面的例子中，大雁可以脱离雁群而独立存在），但组合关系中，成员类与整体类具有相同的声明期，如大脑不可以脱离人独立存在。 ④依赖关系：依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。UML类图如下： 动物的生存离不开氧气，所以动物类与氧气类之间为依赖关系 ⑤泛化关系（继承关系）：泛化关系也就是继承关系，也称为“is-a”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。 在代码实现时，使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C++ 、C#中使用冒号“：”来实现。UML类图如下： 鸟是动物的子类，所以鸟和动物类之间是泛化关系。 ⑥实现关系：接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。UML类图如下： 鸟可以叫，所以鸟实现了叫的接口，则鸟和叫之间是实现关系。 下面给出一个综合了上面六大关系的类图：