搜档网
当前位置:搜档网 › 类与类之间的关系

类与类之间的关系

类与类之间的关系
类与类之间的关系

类与类之间的关系对于理解面向对象具有很重要的作用,下面进行总结!

一、类与类之间存在以下关系:

`

UML图与应用代码例子:

1.泛化(Generalization)

[泛化]

表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。

[简单理解]

是一个is a 的关系。如老虎是一个动物

[具体表现]

父类父类实例=new 子类()

[UML图](图1.1)

图1.1 Animal类与Tiger类,Dog类的泛化关系

[代码表现]

1. class Animal{

2.

3. }

4. class Tiger extends Animal {

5.

6. }

7. public class Test

8. {

9. public void test()

10. {

11. Animal a=new Tiger();

12. }

13. }

2.依赖(Dependency)

[依赖]

对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。

[具体表现]

依赖关系表现在局部变量,方法的参数,以及对静态方法的调用

[简单理解]

一个类使用了另外一个类作为局部变量和方法参数。是一个use a关系!

[现实例子]

比如说你要去拧螺丝,你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作

[UML表现](图1.2)

有时在uml图中不出现箭头只是虚线

图1.2 Person类与Screwdriver类的依赖关系

理解:

指Person类可能要用到Screwdriver的一些方法,也可以这样说,要完成Person里的所有功能,一定要有Screwdriver的方法协助才行。Person依赖于Screwdriver的定义。

ROSE对依赖关系不产生属性。

注意,要避免双向依赖。一般来说,不应该存在双向依赖

[代码表现]

1. public class Person

2. {

3. /** 拧螺丝 */

4. public void screw(Screwdriver screwdriver)

5. {

6. screwdriver.screw();

7. }

8. }

3.关联(Association)

[关联]

对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。

[具体表现]

关联关系是使用实例变量来实现

[现实例子]

比如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;

再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司

[UML图] (图1.3)

图1.3 公司和员工的关联关系

[代码表现]

1.public class Company

2. {

3. private Employee employee;

4. public Employee getEmployee()

5. {

6. return employee;

7. }

8. public void setEmployee(Employee employee)

9. {

10. this.employee=employee;

11. }

12. //公司运作

13. public void run()

14. {

15. employee.startWorking();

16. }

17. }

18.

(4)聚合(Aggregation)

[聚合]

当对象A被加入到对象B中,成为对象B的组成部分时,对象B和对象A之间为聚集关系。聚合是关联关系的一种,是较强的关联关系,强调的是整体与部分之间的关系。

[具体表现]

与关联关系一样,聚合关系也是通过实例变量来实现这样关系的。关联关系和聚合关系来语法上是没办法区分的,从语义上才能更好的区分两者的区别。

[关联与聚合的区别]

(1)关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系,而不是聚合关系,因为人不是由自行车组成的。

聚合关系涉及的两个对象处于不平等的层次上,一个代表整体,一个代表部分。比如电脑和它的显示器、键盘、主板以及内存就是聚集关系,因为主板是电脑的组成部分。

(2)对于具有聚集关系(尤其是强聚集关系)的两个对象,整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在,它的生命周期依赖于整体类的对象的生命周期,当整体消失,部分也就随之消失。比如张三的电脑被偷了,那么电脑的所有组件也不存在了,除非张三事先把一些电脑的组件(比如硬盘和内存)拆了下来。

[UML图](图1.4)

图1.3 电脑和组件的聚合关系

[代码表现]

1.public class Computer{

2. private CPU cpu;

3. public CPU getCPU(){

4. return cpu;

5. }

6. public void setCPU(CPU cpu){

7. this.cpu=cpu;

8. }

9. //开启电脑

10. public void start(){

11. //cpu运作

12. cpu.run();

13. }

14. }

那依赖和聚合\组合、关联等有什么不同呢?

关联是类之间的一种关系,例如老师教学生,老公和老婆,水壶装水等就是一种关系。这种关系是非常明显的,在问题领域中通过分析直接就能得出。

依赖是一种弱关联,只要一个类用到另一个类,但是和另一个类的关系不是太明显的时候(可以说是“uses”了那个类),就可以把这种关系看成是依赖,依赖也可说是一种偶然的关系,而不是必然的关系,就是“我在某个方法中偶然用到了它,但在现实中我和它并没多大关系”。例如我和锤子,我和锤子本来是没关系的,但在有一次要钉钉子的时候,我用到了它,这就是一种依赖,依赖锤子完成钉钉子这件事情。

组合是一种整体-部分的关系,在问题域中这种关系很明显,直接分析就可以得出的。例如轮胎是车的一部分,树叶是树的一部分,手脚是身体的一部分这种的关系,非常明显的整体-部分关系。

上述的几种关系(关联、聚合/组合、依赖)在代码中可能以指针、引用、值等的方式在另一个类中出现,不拘于形式,但在逻辑上他们就有以上的区别。

这里还要说明一下,所谓的这些关系只是在某个问题域才有效,离开了这个问题域,可能这些关系就不成立了,例如可能在某个问题域中,我是一个木匠,需要拿着锤子去干活,可能整个问题的描述就是我拿着锤子怎么钉桌子,钉椅子,钉柜子;既然整个问题就是描述这个,我和锤子就不仅是偶然的依赖关系了,我和锤子的关系变得非常的紧密,可能就上升为组合关系(让我突然想起武侠小说的剑不离身,剑亡人亡...)。这个例子可能有点荒谬,但也是为了说明一个道理,就是关系和类一样,它们都是在一个问题领域中才成立的,离开了这个问题域,他们可能就不复存在了。

组合和聚合的区别:

当类之间有整体-部分关系的时候,我们就可以使用组合或者聚合。

聚合:表示C9聚合C10,但是C10可以离开C9而独立存在(独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解,请看下面组合里的解释)。

组合(也有人称为包容):一般是实心菱形加实线箭头表示,如上图所示,表示的是C8被C7包容,而且C8不能离开C7而独立存在。但这是视问题域而定的,例如在关心汽车的领域里,轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就可以用聚合了。在《敏捷开发》中还说到,A组合B,则A需要知道B的生存周期,即可能A负责生成或者释放B,或者A通过某种途径知道B的生成和释放。

类与类之间的关系

类与类之间存在以下关系: (1)泛化(Generalization) (2)关联(Association) (3)依赖(Dependency) (4)聚合(Aggregation) 1.泛化(Generalization) [泛化] 表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。 父类父类实例=new 子类() [UML图](图1.1) 2.依赖(Dependency) [依赖] 对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。 依赖关系表现在局部变量,方法的参数,以及对静态方法的调用 [现实例子] 比如说你要去拧螺丝,你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺

丝(screw)的工作 [UML表现](图1.2) 3.关联(Association) [关联] 对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。[具体表现] 关联关系是使用实例变量来实现[现实例子] 比如客 3.关联(Association) [关联] 对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。 [具体表现] 关联关系是使用实例变量来实现 [现实例子] 比如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司 [UML图] (图1.3) (4)聚合(Aggregation) [聚合] 当对象A被加入到对象B中,成为对象B的组成部分时,对象B和对象A之间为聚集关系。聚合是关联关系的一种,是较强的关联关系,强调的是整体与部分之间的关系。 [具体表现] 与关联关系一样,聚合关系也是通过实例变量来实现这样关系的。关联关系和聚合关系来语

一、关联句分为8种类型:

一、关联句分为8种类型: 1并列句.各分句间的关系是平行并列的,如:“这衣裳既漂亮,又大方.”常用的关 联词语有:又……又……、既……又……、一边……一边……、那么……那么……、是…… 也是……(不是)、不是……而是……等. 2承接句.各分句表示连续发生的事情或动作,分句有先后顺序,如:“看了他的示范动作后,我就照着样子做.常用的关联词语有:……接着……、……就……、……于是……、……又……、……便……等. 3递进句.分句间是进一层的关系,如:“海底不但景色奇异,而且物产丰富.”常用 的关联词语有:不但(不仅)……而且……、不但……还……、……更(还)……、……甚至……等. 4选择句.各分句列出几种情况,表示从中选出一种,如:“我们下课不是跳橡皮筋, 就是踢毽子.”常用的关联词语有:不是……就是……、或者……或者……、是……还是……、要么……要么……、宁可(宁愿)……也不……、与其……不如……等. 5转折句.后一个分句与前一个分句的意思相反或相对,或部分相反.如:“虽然天气已晚,但是老师仍在灯下伏案工作.”常用的关联词语有:虽然……但是……、尽管……可是……、……然而……、……却……等. 6因果句.分句间是原因和结果的关系,如:“因为这本书写得太精彩了,所以大家都喜欢看.”常用的关联词语有:因为(由于)……所以……、……因而(因此)……、既然……就……、之所以……是因为……等. 7 假设句.一个分句表示假设的情况,另一个分句表示假设实现后的结果.如:“如 果明天下雨,运动会就不举行了.”常用的关联词语有:如果……就……、即使……也……等. 8条件句.一个分句说明条件,另一个分句表示在这一个条件下产生的结果,如:“只要我们努力,成绩就会不断地提高.”常用的关联词语有:只要……就……、无论(不管、不论)……也(都)……、只有……才……、凡是……都……、除非……才……等. 一、给下面的句子填上恰当的关联词。 1、()地球有吸引力,()树上的苹果往地上掉,不往天上飞。 2、()我们坚持改革开放,道路()越走越宽。 3、这种地板砖()坚固,()美观。 4、()我们走到哪儿,()不会忘记培养我们的小学老师。 5、妈妈()吃多少苦,()不会动摇她供我上大学的念头。 6、妈妈买的这条毛巾()漂亮()便宜。 7、()我没有去学校,()我生病了。

类之间的关系(C++)

类之间的关系在大体上分为两种,一种是纵向的,另一种是横向的。 一、纵向的就是继承,它是OO的三个特征之一。 在UNL中称作: 泛化(Generalization) 表示为: 实现(Realization) 表示为: ◆泛化 泛化关系: 是一种继承关系, 表示一般与特殊的关系, 它指定了子类如何特化父类的所有特征和行为。表示类与类之间的继承关系,接口与接口之间的继承关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。 // Animal.h class CAnimal { public: // implement virtual HRESULT EatSomething() { // Do something } }; // Tiger.h #include "Animal.h" class CTiger : public CAnimal { // Do something }; ◆实现 实现关系: 是一种类与接口的关系, 表示类是接口所有特征和行为的实现。

// Animal.h class CAnimal { public: // interface virtual HRESULT EatSomething() = 0; }; // Tiger.h #include "Animal.h" class CTiger : public CAnimal { // Do something }; 注: 泛化和实现的区别就在于子类是否继承了父类的实现, 如有继承则关系为泛化, 反之为实现. 二、横向关系,按UML关系分为4种, 依赖(Dependency),表示为:--------→即虚线+箭头 关联(Association),表示为:实线+箭头 聚合(Aggregation),表示为:空心菱形+实线 组合(Composition),表示为:实心菱形+实线 它们的强弱关系是:依赖< 关联< 聚合< 组合, ◆依赖 依赖就是某个对象的功能依赖于另外的某个对象,而被依赖的对象只是作为一种工具在使用,而并不持有对它的引用。 对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。 是一种使用的关系, 即一个类的实现需要另一个类的协助, 所以要尽量不使用双向的互相依赖. 类A使用到了另一个类B,而这种使用关系是具有偶然性的、、临时性的、非常弱的,但是B类的变化会影响到A;比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖;表现在代码层面,为类B作为参数被类A在某个method方法中使用;

类与类之间的关系

一、继承关系 继承指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力。在Java中继承关系通过关键字extends明确标识,在设计时一般没有争议性。在UML类图设计中,继承用一条带空心三角箭头的实线表示,从子类指向父类,或者子接口指向父接口。 二、实现关系 实现指的是一个class类实现interface接口(可以是多个)的功能,实现是类与接口之间最常见的关系。在Java中此类关系通过关键字implements明确标识,在设计时一般没有争议性。在UML类图设计中,实现用一条带空心三角箭头的虚线表示,从类指向实现的接口。 三、依赖关系 简单的理解,依赖就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、临时性的、非常弱的,但是类B的变化会影响到类A。比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖。表现在代码层面,为类B作为参数被类A在某个method方法中使用。在UML类图设计中,依赖关系用由类A指向类B的带箭头虚线表示。 四、关联关系 关联体现的是两个类之间语义级别的一种强依赖关系,比如我和我的朋友,这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,一般是长期性的,而且双方的关系一般是平等的。关联可以是单向、双向的。表现在代码层面,为被关联类B以类的属性形式出现在关联类A中,也可能是关联类A引用了一个类型为被关联类B的全局变量。在UML类图设计中,关联关系用由关联类A指向被关联类B的带箭头实线表示,在关联的两端可以标注关联双方的角色和多重性标记。 五、聚合关系 聚合是关联关系的一种特例,它体现的是整体与部分的关系,即has-a的关系。此时整体与部分之间是可分离的,它们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享。比如计算机与CPU、公司与员工的关系等,比如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力

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拥有不同的生命周期。

第二节 概念的种类和概念间的关系

第二节概念的种类和概念间的关系 有这么一个诡辩:“鲁迅的小说不是一天能读完的,《孔乙已》是鲁迅的小说,所以《孔乙已》不是一天能读完的。”结论显然是荒谬的,但是推理似乎又无懈可击,毛病到底出在哪里呢?这就涉及到概念的种类问题。 概念是反映事物本质属性的思维形式。什么是事物的本质属性?就是该事物不同于其他事物的属性。举个例子说,“人”这种事物具有多种属性:有五官四肢,会行走,会说话,会思维……其中,“人”区别于其他动物的属性,就是人会说话、能思维。 概念有两个重要的逻辑特征:概念的内涵和外延。前者指的是事物的本质属性在概念中的反映,后者指的是具有概念所反映的特有属性的事物在概念中的反映。比如:“三角形”这个概念的内涵就是“有三条边、三个角,内角和是180度的多边形”,它的外延包括“各种规则的和不规则的三角形”,即所有的三角形。 根据不同的标准可以把概念分为不同的种类。概念一般有以下三类: 1、单独概念和普遍概念(根据概念外延的数量) 单独概念:是反映某一个别事物的概念。它的外延外延只有一个,是独一无二的。一般以专有名词或摹状词表达。 如长江、地球、雷锋、孔乙已 普遍概念:是反映由两个或两个以上的个别事物组成的一类事物的概念。普遍概念是指外延包含两个或两个以上的事物的概念。如树木、学校、作品 2、集合概念和非集合概念(群体,非群体) 根据概念外延的性质(群体,非群体),所指称的对象是集合体,还是非集合体而作出的分类,可以分为集合概念和非集合概念。 集合概念是反映集合体的概念(以事物的群体为反映对象)。 集合体:指由若干个体组成的统一整体,不一定能反映其中的个体 如:森林、书籍、群岛、车队、中国女子排球队、党、词汇、阶级 非集合概念是反映非集合体的概念(不以事物的群体为反映对象)。与集合体不同,非集合体所具有的属性,组成它的个体一定具有。 树、书、岛、汽车、党员、词、工人 例如:森林是有广泛用途的。树是植物 怎样区别集合概念与非集合概念? 1、集合概念所反映对象的属性只是集合体具有,其中的个体不具有。 集合词项的特征:构成整体的分子不具有整体的属性。车队由车构成,但车不具有车队的属性,我们看见停车场里有停有许多的车,我们并不就认为停车场里有一支车队。 2、非集合概念所反映的对象的属性不仅这类事物具有,其中的个体也具有。 例如(1)中国人是黄种人中国人是亚洲人 (2)中国人是有骨气的(集合概念) (1)非集合概念--鲁迅是中国人的一个个体,鲁迅是黄种人。 (2)集合概念--并非每一个中国人张三、李四都是有骨气的。 判断方法:加上全称量词是否改变原来判断的含义。 所有中国人都是有骨气的。所有中国人都是亚洲人。 3、同一个语词既可以表达集合概念也可以表达非集合概念 例1、人是由猿进化而来的。集合概念例2、人是有理性的。非集合概念 “鲁迅的著作不是一天能读完的”(集合概念) “《祝福》是鲁迅的著作”非集合概念

学科门类、专业类和专业之间的关系

学科门类、专业类和专业之间的关系 我国高等学校本科教育专业设置是按“学科门类”“专业类”“专业”三个层次来设置。即一个学科门类下面设置若干专业类,一个专业类下面设置若干专业。 学科是高校教学、科研等的基本功能单位,是对高校人才培养、教育教学、科学研究等隶属范围的相对界定。新专业目录中把学科划分为12大门类:哲学、经济学、法学、教育学、文学、历史学、理学、工学、农学、医学、管理学、艺术学。不同的学科就是不同的科学知识体系。如经济学学科门类包含经济、财政、金融、贸易等领域的知识,工学学科门类包含机械、仪器、材料、电子、土建、地矿、化工、轻工纺织、航空航天、环境安全、食品科学等领域的知识。 专业类是在同一学科知识体系下,根据知识面侧重的不同而分解出来的不同专业类别。如理学分为数学类、物理学类、化学类、天文学类、地理科学类、大气科学类、海洋科学类、地球物理学类、地质学类、生物科学类、心理学类、统计学类。这些专业门类具有相同的理学特性,但相互之间又侧重不同的知识范畴。 专业比专业类更加具体,是在一个专业门类里派生出来的具体方向。在一个学科,可以组成若干专业。如土木类就包含土木工程、建筑环境与能源应用工程、给排水科学与工程、建筑电气与智能化四个专业。在不同学科之间也可以组成跨学科专业。如过程装备与控制工程,横跨机械工程和化学工程两个学科。 学科和专业的核心区别在于其构成和目标不同。学科的构成要包含研究的对象或研究的领域,即独特的、不可替代的研究对象;理论体系,即特有的概念、原理、命题、规律等所构成的严密的逻辑化的知识系统;方法论,即学科知识的生产方式。专业的构成要素主要包括:专业培养目标、课程体系和专业人员。培养目标即专业活动的意义表达。课程体系是社会职业

类与类之间的关系及代码表现

类与类之间的关系对于理解面向对象具有很重要的作用,以前在面试的时候也经常被问到这个问题,在这里我就介绍一下。 类与类之间存在以下关系: (1)泛化(Generalization) (2)关联(Association) (3)依赖(Dependency) (4)聚合(Aggregation) UML图与应用代码例子: 1.泛化(Generalization) [泛化] 表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。 [具体表现] 父类父类实例=new 子类() [UML图](图1.1) 图1.1Animal类与Tiger类,Dog类的泛化关系 [代码表现] 1.class Animal{} 2.class Tiger extends Animal{} 3.public class Test 4.{ 5. public void test() 6. { 7. Animal a=new Tiger(); 8. } 9.} 2.依赖(Dependency) [依赖] 对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。 [具体表现]

依赖关系表现在局部变量,方法的参数,以及对静态方法的调用 [现实例子] 比如说你要去拧螺丝,你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作 [UML表现](图1.2) 图1.2 Person类与Screwdriver类的依赖关系 [代码表现] 1.public class Person{ 2. /** 拧螺丝 */ 3. public void screw(Screwdriver screwdriver){ 4. screwdriver.screw(); 5. } 6.} 3.关联(Association) [关联] 对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。 [具体表现] 关联关系是使用实例变量来实现 [现实例子] 比如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司 [UML图] (图1.3) 图1.3 公司和员工的关联关系 [代码表现] 1.public class Company{ 2. private Employee employee;

UML类图画法及其之间的几种关系

UML类图画法及其之间的几种关系 最近做重构项目,需要画一下类图,发现类图的画法及其之间的几种关系已经淡忘了很多,所以整理总结一下,有问题的地方大家可以一起讨论下。 文章目录如下: 类图画法 类之间的几种关系:泛化(Generalization)、实现(Realization)、关联(Association)(又分一般关联、聚合(Aggregation)、组合(Composition))、依赖(Dependency) 一、类图画法 1、类图的概念 A、显示出类、接口以及它们之间的静态结构和关系 B、用于描述系统的结构化设计 2、类图的元素 类、接口、协作、关系,我们只简单介绍一下这四种元素。 同其他的图一样,类图也可以包含注解和限制。 类图中也可以包含包和子系统,这两者用来将元素分组。 有时候你也可以将类的实例放到类图中。 3、类 A、类是对一组具有相同属性、操作、关系和语义的对象的抽象,它是面向对象系统 组织结构的核心,包括名称部分(Name)、属性部分(Attribute)和操作部分(Operation),见下图。 B、类属性的语法为: [可见性] 属性名[:类型] [=初始值] [{属性字符串}] 可见性:公有(Public)“+”、私有(Private)“-”、受保护(Protected)“#” 类操作的语法为: [可见性] 操作名[(参数表)] [:返回类型] [{属性字符串}] 可见性:公有(Public)“+”、私有(Private)“-”、受保护(Protected)“#”、 包内公有(Package)“~” 参数表: 定义方式:“名称:类型”;若存在多个参数,将各个参数用逗号隔开; 参数可以具有默认值; 属性字符串: 在操作的定义中加入一些除了预定义元素之外的信息。 4、接口 在没有给出对象的实现和状态的情况下对对象行为的描述。 一个类可以实现一个或多个接口。 使用两层矩形框表示,与类图的区别主要是顶端有<>显示:

学科门类专业类和专业之间的关系

学科门类专业类和专业 之间的关系 公司内部档案编码:[OPPTR-OPPT28-OPPTL98-OPPNN08]

学科门类、专业类和专业之间的关系 我国高等学校本科教育专业设置是按“学科门类”“专业类”“专业”三个层次来设置。即一个学科门类下面设置若干专业类,一个专业类下面设置若干专业。 学科是高校教学、科研等的基本功能单位,是对高校人才培养、教育教学、科学研究等隶属范围的相对界定。新专业目录中把学科划分为12大门类:哲学、经济学、法学、教育学、文学、历史学、理学、工学、农学、医学、管理学、艺术学。不同的学科就是不同的科学知识体系。如经济学学科门类包含经济、财政、金融、贸易等领域的知识,工学学科门类包含机械、仪器、材料、电子、土建、地矿、化工、轻工纺织、航空航天、环境安全、食品科学等领域的知识。 专业类是在同一学科知识体系下,根据知识面侧重的不同而分解出来的不同专业类别。如理学分为数学类、物理学类、化学类、天文学类、地理科学类、大气科学类、海洋科学类、地球物理学类、地质学类、生物科学类、心理学类、统计学类。这些专业门类具有相同的理学特性,但相互之间又侧重不同的知识范畴。 专业比专业类更加具体,是在一个专业门类里派生出来的具体方向。在一个学科,可以组成若干专业。如土木类就包含土木工程、建筑环境与能源应用工程、给排水科学与工程、建筑电气与智能化四个专业。在不同学科之间也可以组成跨学科专业。如过程装备与控制工程,横跨机械工程和化学工程两个学科。

学科和专业的核心区别在于其构成和目标不同。学科的构成要包含研究的对象或研究的领域,即独特的、不可替代的研究对象;理论体系,即特有的概念、原理、命题、规律等所构成的严密的逻辑化的知识系统;方法论,即学科知识的生产方式。专业的构成要素主要包括:专业培养目标、课程体系和专业人员。培养目标即专业活动的意义表达。课程体系是社会职业需要与学科知识体系相结合的产物,是专业活动的内容和结构。课程体系的合理设置与否、质量高低、实施效果好坏直接影响人才培养目标的实现状况。 学科发展的目标是知识的发现和创新。专业的目标是为社会培养各级各类专门人才。专业是学科承担人才培养职能的基地;学科是专业发展的基础。一所高校的人才培养质量如何,取决于其学科、专业水平的高低。

UML中几种类间关系

UML中几种类间关系:继承、实现、依赖、关联、聚合、组合的联系与区别 继承 指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java中此类关系通过关键字extends明确标识,在设计时一般没有争议性; 实现 指的是一个class类实现interface接口(可以是多个)的功能;实现是类与接口之间最常见的关系;在Java中此类关系通过关键字implements明确标识,在设计时一般没有争议性;

依赖 可以简单的理解,就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、临时性的、非常弱的,但是B类的变化会影响到A;比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖;表现在代码层面,为类B作为参数被类A在某个method 方法中使用; 关联 他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系,比如我和我的朋友;这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,一般是长期性的,而且双方的关系一般是平等的、关联可以是单向、双向的;表现在代码层面,为被关联类B 以类属性的形式出现在关联类A中,也可能是关联类A引用了一个类型为被关联类B的全局变量;

聚合 聚合是关联关系的一种特例,他体现的是整体与部分、拥有的关系,即has-a的关系,此时整体与部分之间是可分离的,他们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享;比如计算机与CPU、公司与员工的关系等;表现在代码层面,和关联关系是一致的,只能从语义级别来区分; 组合 组合也是关联关系的一种特例,他体现的是一种contains-a的关系,这种关系比聚合更强,也称为强聚合;他同样体现整体与部分间的关系,但此时整体与部分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面,和关联关系是一致的,只能从语义级别来区分; 对于继承、实现这两种关系没多少疑问,他们体现的是一种类与类、

类图之间的关系

在UML 2.0的13种图形中,类图是使用频率最高的UML图之一。Martin Fowler在其著作《UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition》(《UML 精粹:标准对象建模语言简明指南(第3版)》)中有这么一段:“If someone were to come up to you in a dark alley and say, 'Psst, wanna see a UML diagram?' that diagram would probably be a class diagram. The majority of UML diagrams I see are class diagrams.”(“如果有人在黑暗的小巷中向你走来并对你说:‘嘿,想不想看一张UML图?’那么这张图很有可能就是一张类图,我所见过的大部分的UML图都是类图”),由此可见类图的重要性。 类图用于描述系统中所包含的类以及它们之间的相互关系,帮助人们简化对系统的理解,它是系统分析和设计阶段的重要产物,也是系统编码和测试的重要模型依据。 1. 类 类(Class)封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。在系统中,每个类都具有一定的职责,职责指的是类要完成什么样的功能,要承担什么样的义务。一个类可以有多种职责,设计得好的类一般只有一种职责。在定义类的时候,将类的职责分解成为类的属性和操作(即方法)。类的属性即类的数据职责,类的操作即类的行为职责。设计类是面向对象设计中最重要的组成部分,也是最复杂和最耗时的部分。 在软件系统运行时,类将被实例化成对象(Object),对象对应于某个具体的事物,是类的实例(Instance)。 类图(Class Diagram)使用出现在系统中的不同类来描述系统的静态结构,它用来描述不同的类以及它们之间的关系。 在系统分析与设计阶段,类通常可以分为三种,分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class),下面对这三种类加以简要说明: (1) 实体类:实体类对应系统需求中的每个实体,它们通常需要保存在永久存储体中,一般使用数据库表或文件来记录,实体类既包括存储和传递数据的类,还包括操作数据的类。实体类来源于需求说明中的名词,如学生、商品等。 (2) 控制类:控制类用于体现应用程序的执行逻辑,提供相应的业务操作,将控制类抽象出来可以降低界面和数据库之间的耦合度。控制类一般是由动宾结构的短语(动词+名词)转化来的名词,如增加商品对应有一个商品增加类,注册对应有一个用户注册类等 (3) 边界类:边界类用于对外部用户与系统之间的交互对象进行抽象,主要包括界面类,如对话框、窗口、菜单等。 在面向对象分析和设计的初级阶段,通常首先识别出实体类,绘制初始类图,此时的类图也可称为领域模型,包括实体类及其它们之间的相互关系。 2. 类的UML图示 在UML中,类使用包含类名、属性和操作且带有分隔线的长方形来表示,如定义一个Employee 类,它包含属性name、age和email,以及操作modifyInfo(),在UML类图中该类如图1所示:

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图与应用代码例子: 1.泛化(Generalization) [泛化] 表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。 [简单理解] 是一个is a 的关系。如老虎是一个动物 [具体表现] 父类父类实例=new 子类() [UML图](图1.1) 图1.1 Animal类与Tiger类,Dog类的泛化关系 [代码表现] 1. class Animal{ 2. 3. } 4. class Tiger extends Animal { 5. 6. } 7. public class Test 8. { 9. public void test() 10. { 11. Animal a=new Tiger(); 12. } 13. }

2.依赖(Dependency) [依赖] 对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。 [具体表现] 依赖关系表现在局部变量,方法的参数,以及对静态方法的调用 [简单理解] 一个类使用了另外一个类作为局部变量和方法参数。是一个use a关系! [现实例子] 比如说你要去拧螺丝,你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作 [UML表现](图1.2) 有时在uml图中不出现箭头只是虚线 图1.2 Person类与Screwdriver类的依赖关系 理解: 指Person类可能要用到Screwdriver的一些方法,也可以这样说,要完成Person里的所有功能,一定要有Screwdriver的方法协助才行。Person依赖于Screwdriver的定义。 ROSE对依赖关系不产生属性。 注意,要避免双向依赖。一般来说,不应该存在双向依赖 [代码表现] 1. public class Person 2. { 3. /** 拧螺丝 */ 4. public void screw(Screwdriver screwdriver) 5. { 6. screwdriver.screw(); 7. } 8. }

Java类之间的关联关系

Java类之间的关联关系 UML类图中的关系分为四种:泛化、依赖、关联、实现;关联关系又可以细化为聚合和组合。 一、泛化(Generalization) 泛化是父类和子类之间的关系,子类继承父类的所有结构和行为。在子类中可以增加新的结构和行为,也可以覆写父类的行为。 一般用一个带空心箭头的实线表示泛化关系,UML图如下: 泛化对应Java中继承关系,即子类继承父类中出private修饰外的所有东西(变量、方法等)。示例代码: public class Animal { } public class Tiger extends Animal { } Tiger继承Animal,因此Tiger与Animal之间是泛化(继承)关系。这个很好理解。 二、依赖(Dependency) 依赖关系是一种使用关系,特定事物的改变有可能会影响到使用该事物的事物,反之不成立。在你想显示一个事物使用另一个事物时使用。 一般用一条指向被依赖事物的虚线表示,UML图如下: 通常情况下,依赖关系体现在某个类的方法使用另一个类作为参数。代码示例:public class Screwdriver { //螺丝刀,作为人类的工具,是用来被人类使用的} public class Person{ public void screw(Screwdriver src){ //拧螺丝,需使用螺丝刀 } }

Person类的screw()方法在使用时就得传入一个Screwdriver类型的参数,这样Screwdriver的改变就会影响到Person,因此Person与Screwdriver之间就是依赖关系(Person依赖于Screwdriver)。 三、关联(Association) 是一种结构关系,说明一个事物的对象与另一个事物的对象相联系。给定有关联的两个类,可以从一个类的对象得到另一个类的对象。关联有两元关系和多元关系。两元关系是指一种一对一的关系,多元关系是一对多或多对一的关系。两个类之间的简单关联表示了两个同等地位类之间的结构关系。当你想要表示结构化关系时使用关联。(可以想想Hibernate的关联关系) 一般用实线连接有关联的同一个类或不同的两个类。UML图如下: 通常情况下,关联关系是通过类的成员变量来实现的。代码示例: public class Company { //公司 private Employee emp ; //一个公司雇员,公司与雇员之间就是一种关联关系。} public class Employee{ } 雇员作为公司的属性,不同于上面的依赖。依赖的话,雇员的改变会影响公司,显然不是。在这里雇员仅仅作为公司的一个属性而存在。因此Employee与Company之间是关联关系。关联关系还可以细分为聚合和组合两种。 3.1聚合(Aggregation) 聚合是一种特殊的关联。它描述了“has a”关系,表示整体对象拥有部分对象。关联关系和聚合关系来语法上是没办法区分的,从语义上才能更好的区分两者的区别。聚合是较强的关联关系,强调的是整体与部分之间的关系。例如,学校和学生的关系。聚合的整体和部分之间在生命周期上没有什么必然的联系,部分对象可以在整体对象创建之前创建,也可以在整体对象销毁之后销毁。 一般用带一个空心菱形(整体的一端-学校)的实线表示。UML图如下: 与关联关系一样,聚合关系也是通过类的成员变量来实现的。示例代码:

物种之间的相互关系类型

物种之间的相互关系 邓焜耀记录互惠:指对双方都有利的一种种间关系,但这种关系并没有发展到相依为命的地步,如果解除这种关系,双方都能正常生存。如海葵和寄居蟹;蚜虫和蚂蚁。{号外!我个人认为,物种的共生,人类学学才行,否则战争真的要人的命啊!} 共生:是物种之间一种相依为命的一种互利关系,如果失去一方,另一方便不能生存。如地衣(是单细胞藻类和真菌的共生体);丝兰和法兰蛾;白蚁和多鞭毛虫。 共栖:是指对一方有利,对另一方无利夜无害的一种种间关系,又称偏利。如双锯鱼和海葵,偕老同穴和俪虾。 植食:指动物吃植物,是生物相互关系中最常见的现象。 捕食:指动物吃动物,也是生物相互关系中最基本的现象之一。 寄生:生活在一起的两种生物,一方获利,而另一方遭受损害。寄居在别种生物上并获利的一方称寄生物,被寄居并受害的一方被称为寄主。如寄生在人体内血吸虫、蛔虫。

类寄生:类似寄生,但寄生物导致寄主死亡。所有昆虫对昆虫的寄生都是类寄生,如寄生蝇和寄生蜂。 竞争:当两个物种利用同一确定短缺资源时就会发生竞争,竞争的结果时一个物种战胜另一物种,甚至导致一种物种完全被排除。如大草履虫和双小核草履虫的竞争;欧洲百灵被引进北美后与当地百灵的竞争。{人类竞争残烈,动物也是啊!} 抗生:指一个物种通过分泌化学物质抑制另一个物种的生长和生存。青霉就是著名的一例。 互抗:指两个物种相互作用使双方都受害或引起死亡。当两种致病生物同时侵入一个寄主而导致寄主死亡时,这两种致病生物就是对抗关系。 中性:指两个或更多物种经常一起出现,但彼此互相无利也无害。如一个水源总是吸引很多动物前来饮水,这些动物之间就是中性关系。 总结:生物与环境是一个统一不可分割的整体。环境能影响生物,生物适应环境,同时也不断的影响环境,如同“水能载舟,也能覆舟”。例如:在沙漠中生活的仙人掌,因为在此环境中缺水使得仙人掌的叶变成刺,同时也能说明仙人掌能适应环境。

类与类之间的关系(继承、实现、依赖、关联、聚合、组合)

类与类之间的关系继承 接口 依赖 关联 聚合 组合

继承 继承是一个类(子类,子接口)继承另一个类(父类,父接口)。 当父类为抽象时,该类不能够在实例化。当父类中有抽象方法时。 该类就必须为抽象类。其抽象方法没有方法体。当子类继承该父类时,抽象方法必须重写。 public class abstract Parents{ public abstract void method(); } public class Child extends Parents{ public void method(){ } }属性方法

接口 接口就是在接口中写出方法,然后在调用接口类 时实现所有接口类中方法。java中通过 interface来表示接口。其一个类可以实现多个 接口,用implement来实现接口,用“,”来连 接多个接口。接口不能够被实例化。 public interface iner{ public void print(); } public class Test implement iner{ public void print(){ System.out.print("接口"); } }

依赖 依赖就是要实现类A的功能必须引用到类B,而这种关系具有偶然性、临时性、非常弱的。同时B 类的变化会影响到A类。 人船类渡河 实例: 当你要渡河时,就必须要调用船类中的渡河方法。这就是依赖

关联 两个相对独立的对象,当一个对象的实例与另一个对象的特定实例存在固定关系时,就存在关联。亦是一种强的依赖性。不存在依赖的偶然性、临时性。是长时性的。而且双方是平等的。 可以是单向的、也可以是双向的。 单向关联 类A认识类B,类A知道类B的存在,类A可以调用类B的方法。 代码表现:类A中有类B的变量或引用。 public class Order{ public void addOrder(Product product ){ order.Add(product); } } public class Product{ }

类间关系

依赖关系 依赖指的是类之间的调用关系。 (1)类A访问类B的属性或方法 (2)类A负责实例化类B 凡是符合以上两种的就说类A依赖于类B。 和关联关系不同的是,无需在类A中定义类B类型的属性。例如自行车和打气筒,自行车通过打气筒来充气,那么就需要调用打气筒的充气方法。对应的UML图如下所示: 依赖关系用虚线+箭头表示。上图显示Bicycle和Pump是依赖关系,Bicycle 依赖于Pump。 聚合关系 聚合是整体与部分之间的关系。 例如计算机和主板,计算机是一个整体,主板是其中的一部分,主板、显卡、显示器等部件组成了计算机。对应的UML图如下所示: 聚合使用空心菱形+实线表示。上图显示Computer是由MainBoard和DisplayCard等组成的。 组合关系

组合中的类也是整体与部分的关系。 与聚合不同的是,其中的类不能独立出来。例如一个人由头、手、腿和躯干等组成,如果这个头离开了这个人,那么这个头就没有任何意义了。对应的UML 图如下所示: 组合使用实心菱形和实线表示。上图表示People是由Head、Hand、Leg等组成。 聚合和组合的代码几乎相同,单凭代码是无法区分两个类之间是聚合还是组合的关系的。所以就需要结合实际的业务环境来区分。 例如汽车和轮胎,车主买了一辆汽车,上边肯定是由轮胎的,在这个业务中,轮胎和汽车是组合关系,它们分开就没有实际意义了。在汽车修理店,汽车可以更换轮胎,所以在汽修店的业务环境中,汽车和轮胎就是聚合的关系,轮胎离开汽车是有业务意义的。 泛化关系 泛化比较好理解,就是两个类之间具有继承关系。 例如人和学生,学生继承了人,除过具有人的一般的属性和方法之外,他还要有学习的方法。对应的UML图如下所示:

相关主题