类图之间的关系

合集下载

UML类图中关联关系的导航方式和选择原则

UML类图中关联关系的导航方式和选择原则

UML类图中关联关系的导航方式和选择原则在软件开发中,UML类图是一种常用的建模工具,用于描述系统中的类和它们之间的关系。

其中,关联关系是类图中最基本的关系之一,用于表示类之间的连接。

关联关系可以分为双向关联和单向关联两种。

双向关联表示两个类之间的连接是相互的,而单向关联表示连接只是单向的。

在类图中,关联关系通常用带箭头的实线表示。

在使用关联关系时,我们需要考虑如何进行导航,即如何通过一个类的实例找到与之相关联的其他类的实例。

导航方式的选择取决于系统的需求和设计的目标。

一种常见的导航方式是使用关联类的引用。

在这种情况下,一个类的实例可以通过它与其他类的关联关系中的引用来访问相关联的实例。

例如,考虑一个订单管理系统,订单类和客户类之间存在关联关系。

通过订单类的一个引用,我们可以访问与该订单相关联的客户实例。

另一种导航方式是使用关联类的操作。

在这种情况下,一个类的实例可以通过调用关联类中定义的操作来访问相关联的实例。

例如,在一个电子商务系统中,订单类和商品类之间存在关联关系。

通过调用订单类中的一个操作,我们可以获取与该订单相关联的商品实例的信息。

在选择导航方式时,我们应该考虑以下几个原则:1. 一致性原则:在整个系统中,应该保持一致的导航方式。

如果在一个关联关系中使用了引用导航,那么在其他关联关系中也应该使用引用导航,以保持一致性和统一性。

2. 依赖性原则:导航方式应该尽量减少类之间的依赖性。

如果一个类的实例通过关联类的引用或操作来访问其他类的实例,那么这个类就会对关联类产生依赖。

为了降低类之间的耦合度,我们应该尽量避免过多的依赖关系。

3. 效率原则:导航方式应该尽量高效。

在设计关联关系时,我们应该考虑到系统的性能需求和实际运行环境,选择合适的导航方式以提高系统的响应速度和效率。

4. 安全性原则:导航方式应该保证系统的安全性。

在设计关联关系时,我们应该考虑到数据的隐私和安全性要求,选择适当的导航方式以保护系统中的敏感信息。

UML类图中关联关系的三种导航方式

UML类图中关联关系的三种导航方式

UML类图中关联关系的三种导航方式在软件开发中,UML(统一建模语言)类图是一种常用的建模工具,用于描述系统中的类和它们之间的关系。

其中,关联关系是类图中最基本的一种关系,描述了类之间的连接。

在关联关系中,导航方式是指一个类如何访问与之相关联的其他类的对象。

在UML类图中,有三种常见的导航方式:单向导航、双向导航和自关联导航。

1. 单向导航单向导航是指一个类可以访问与之关联的其他类的对象,而被关联的类不能直接访问该类的对象。

这种导航方式常见于一对多的关联关系,其中一个类是主导类,而另一个类是从属类。

举个例子,考虑一个图书馆管理系统,图书馆类与图书类之间存在一种关联关系,一个图书馆可以管理多本图书。

在这种情况下,图书馆类可以通过关联关系访问图书类的对象,但是图书类无法直接访问图书馆类的对象。

2. 双向导航双向导航是指两个类可以互相访问对方的对象。

这种导航方式常见于一对一或多对多的关联关系,其中两个类都可以主动访问对方的对象。

继续以图书馆管理系统为例,考虑一个借阅记录类与读者类之间的关联关系。

一个借阅记录可以关联一个读者,同时一个读者也可以关联多个借阅记录。

在这种情况下,借阅记录类和读者类可以通过关联关系互相访问对方的对象。

双向导航可以提供更灵活的访问方式,但也需要注意双向关联的管理和维护。

在设计时,需要考虑到两个类之间的依赖关系和业务逻辑,避免出现循环依赖或不一致的情况。

3. 自关联导航自关联导航是指一个类与自身存在关联关系,可以访问自身的对象。

这种导航方式常见于树状结构或层级结构的模型。

举个例子,考虑一个组织机构管理系统,组织类与自身存在一种关联关系,一个组织可以包含多个子组织。

在这种情况下,组织类可以通过关联关系访问自身的对象,实现对组织结构的层级管理。

自关联导航可以用于描述递归结构或层级结构,提供了一种方便的方式来处理复杂的关系。

但是,在使用自关联导航时需要注意循环引用的问题,避免出现无限循环或死循环的情况。

类之间的几种关系

类之间的几种关系

类之间的⼏种关系类之间的关联关系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)是⼀种结构关系,说明⼀个事物的对象与另⼀个事物的对象相联系。

给定有关联的两个类,可以从⼀个类的对象得到另⼀个类的对象。

关联有两元关系和多元关系。

两元关系是指⼀种⼀对⼀的关系,多元关系是⼀对多或多对⼀的关系。

UML类图关系泛化、继承、实现、依赖、关联、聚合、组合

UML类图关系泛化、继承、实现、依赖、关联、聚合、组合

继承、实现、依赖、关联、聚合、组合的联系与区别分别介绍这几种关系:继承实现指的是一个class 类实现interface 接口(可以是多个)的功能;实现是类与接口之间最常 见的关系;在Java 中此类关系通过关键字implements 明确标识,在设计时一般没有争 议性;依赖可以简单的理解,就是一个类A 使用到了另一个类B ,而这种使用关系是具有偶然性的、、 临时性的、非常弱的,但是B 类的变化会影响到A ;比如某人要过河,需要借用一条船, 此时人与船之间的关系就是依赖;表现在代码层面,为类B 作为参数被类A 在某个method 方法中使用;Inte rfare指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可 以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java 中此类关系通过关键字extends 明确标识,在设计时一般没有争议性;b lnterface_BQlass_A ClaSs_B关联他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系,比如我和我的朋友;这 种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,一般是长期性的,而 且双方的关系一般是平等的、关联可以是单向、双向的;表现在代码层面,为被关联类B 以类属性的形式出现在关联类A 中,也可能是关联类A 引用了一个类型为被关联类B 的全 局变量;聚合聚合是关联关系的一种特例,他体现的是整体与部分、拥有的关系,即has-a 的关系,此 时整体与部分之间是可分离的,他们可以具有各自的生命周期,部分可以属于多个整体对象, 也可以为多个整体对象共享;比如计算机与CPU 、公司与员工的关系等;表现在代码层面, 和关联关系是一致的,只能从语义级别来区分;组合组合也是关联关系的一种特例,他体现的是一种contains-a 的关系,这种关系比聚合更强, 也称为强聚合;他同样体现整体与部分间的关系,但此时整体与部分是不可分的,整体的生 命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面,和关联 关系是一致的,只能从语义级别来区分;对于继承、实现这两种关系没多少疑问,他们体现的是一种类与类、或者类与接口间的纵向 关系;其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系,是比较难区 分的,有很多事物间的关系要想准备定位是很难的,前面也提到,这几种关系都是语义级别Cl3ss A 十 depend<Qlass.B classBJ ;:;;VoidClass_B的,所以从代码层面并不能完全区分各种关系;但总的来说,后几种关系所表现的强弱程度依次为:组合>聚合>关联》依赖;聚合跟组合其实都属于关联只不过它们是两种特殊的关联因为本是同根生所以它们之间难 免会有相似之处下面让我们一起来看一下它们之间有何不同聚合与组合的概念相信不用我在此赘述大家就已经了解了下面直接上例子 程老师的《大话》里举大那个大雁的例子很贴切在此我就借用一下大雁喜欢热闹害怕孤独所 以它们一直过着群居的生活这样就有了雁群每一只大雁都有自己的雁群每个雁群都有好多 大雁大雁与雁群的这种关系就可以称之为聚合另外每只大雁都有两只翅膀大雁与雁翅的关 系就叫做组合有此可见聚合的关系明显没有组合紧密大雁不会因为它们的群主将雁群解散 而无法生存而雁翅就无法脱离大雁而单独生存一一组合关系的类具有相同的生命周期聚合关系图:构造函数不同雁群类:[csharp] view plaincopypublic class GooseGroup { public Goose goose; public GooseGroup(Goose goose) { this .goose = goose;} 10. }[csharp] view plaincopy1. 2. 3.4.5. 6.7. 8.9. 组合关系图:从从代码上看这两种关系的区别在于:1.public class GooseGroup2.{3.public Goose goose;4.5.6.public GooseGroup(Goose goose)7.{8.this.goose = goose;9.}10.}大雁类:[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}聚合关系的类里含有另一个类作为参数雁群类(GooseGroup)的构造函数中要用到大雁(Goose)作为参数把值传进来大雁类(Goose)可以脱离雁群类而独立存在组合关系的类里含有另一个类的实例化大雁类(Goose)在实例化之前一定要先实例化翅膀类(Wings)两个类紧密耦合在一起它们有相同的生命周期翅膀类(Wings)不可以脱离大雁类(Goose)而独立存在信息的封装性不同在聚合关系中,客户端可以同时了解雁群类和大雁类,因为他们都是独立的而在组合关系中,客户端只认识大雁类,根本就不知道翅膀类的存在,因为翅膀类被严密的封装在大雁类中。

UML类图-关系数据库之间的映射

UML类图-关系数据库之间的映射

UML类图与关系数据库之间的映射策略摘要:UML是目前面向对象程序设计中的一种标准的建模技术。

在关系数据库系统的设计过程中,我们可先利用UML建立商业模型,然后将其映射成表。

本文主要讨论如何将UML 类图中的类映射成表的策略。

关键词:UML 类表关系建模映射一.概论在关系数据库设计中,用来创建数据库逻辑模型的标准方法是使用实体关系模型(ER 模型)。

ER模型的中心思想是:可以仅通过实体和它们之间的关系合理地体现一个组织的数据模型。

但这样做似乎对描述一个组织的信息过于简单化,并且词汇量也远远不足。

所以,迫切需要使用更加灵活、健壮的模型来代替ER模型。

标准建模语言UML是由世界著名的面向对象技术专家发起的,在综合了著名的Booch 方法、OMT方法和OOSE方法的基础上而形成的一种建模技术,它通过用例图、类图、交互图、活动图等模型来描述复杂系统的全貌及其相关部件之间的联系。

UML可以完成ER 模型的所有建模工作,而且可以描述ER模型所不能表示的关系。

在UML中,类图主要用于描述系统中各种类及其对象之间的静态结构。

在关系数据库领域中,类与表相对应。

本文主要讨论将UML类图中的类及其对象映射成关系型数据库中的表的策略。

二.UML类图中的类映射成表的策略UML中的类图主要由类及其关系组成,而类之间的关系又可以细分为:(1)泛化:在UML类图中,如果子类型的接口包括超类型的接口中的每个元素。

则超类与子类之间构成泛化关系。

泛化通常可以用继承或授权的方式实现。

(2)关联:在UML类图中,关联表示类的实例之间存在的某种关系。

它通常可以有1对1、1对多和多对多等情形。

(3)聚集:在UML类图中,聚集描述了部分与整体之间的关系。

(4)组成:在UML类图中,组成由聚集演变而成,它表示一个部分对象仅属于一个整体,并且部分对象通常与整体对象共存亡。

下面结合例子,分别讨论在将类映射成表的过程中这些关系的实现技术。

假设,有一个电脑公司专门从事软件开发,其项目主要由项目开发部门承担,它们之间构成多对多的关联(即一个项目可由多个部门承担,而一个部门又可以承担多个项目的开发工作);项目开发部门由经理及一般职员组成,项目开发部门和组成人员之间构成聚集关系,而人(抽象类)又可以进一步和一般职员及经理两个子类之间构成继承关系;每个项目具有一定的属性,它们之间构成组成关系。

UML图中类之间的关系_依赖,泛化,关联,聚合,组合,实现答辩

UML图中类之间的关系_依赖,泛化,关联,聚合,组合,实现答辩

UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现1.2.3.4.5.6.类与类图1 类(Class封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。

2 在系统中,每个类具有一定的职责,职责指的是类所担任的任务,即类要完成什么样的功能,要承担什么样的义务。

一个类可以有多种职责,设计得好的类一般只有一种职责,在定义类的时候,将类的职责分解成为类的属性和操作(即方法)。

3 类的属性即类的数据职责,类的操作即类的行为职责一、依赖关系(Dependence依赖关系(Dependence):假设A类的变化引起了B 类的变化,则说名B类依赖于A类。

• 依赖关系(Dependency 是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。

大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。

• 在UML中,依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方。

[java] view plaincopyprint?1. public class Driver2. {3. public void drive(Car car4. {5. car.move(;6. }7. ……8. }9. public class Car10. {11. public void move(12. {13. ......14. }15. ……16. }{car.move(;}……}public class Car{public void move({......}……}依赖关系有如下三种情况:1、A类是B类中的(某中方法的)局部变量;2、A类是B类方法当中的一个参数;3、A类向B类发送消息,从而影响B类发生变化;GeneralizationGeneralization A是B和C的父类,B,C具有公共类(父类)A,说明A是B,C的一般化(概括,也称泛化)• 泛化关系(Generalization也就是继承关系,也称为“is-a-kind-of”关系,泛化关系用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。

UML中的用例与类图之间的关联关系

UML中的用例与类图之间的关联关系

UML中的用例与类图之间的关联关系UML(Unified Modeling Language)是一种用于软件系统建模的标准化语言,它提供了一套丰富的图形符号和规范,用于描述和设计软件系统的结构和行为。

在UML中,用例图和类图是两个重要的建模工具,它们分别用于描述系统的功能需求和结构设计。

本文将探讨用例图和类图之间的关联关系,以及它们在软件开发过程中的应用。

一、用例图的作用和特点用例图是一种用于描述系统功能需求的图形表示方法。

它通过用例(Use Case)和参与者(Actor)之间的关系来描述系统的功能和行为。

用例图可以帮助开发团队和用户明确系统的功能需求,从而指导软件系统的开发和测试工作。

用例图的特点在于它强调系统与外部参与者之间的交互关系。

一个用例表示系统的一个功能需求,而参与者则表示与系统进行交互的外部实体,如用户、系统管理员等。

用例图通过箭头来表示参与者和用例之间的关系,例如,一个参与者可以执行多个用例,一个用例也可以被多个参与者执行。

二、类图的作用和特点类图是一种用于描述系统结构设计的图形表示方法。

它通过类(Class)、关联(Association)、继承(Inheritance)等元素来描述系统中的对象和它们之间的关系。

类图可以帮助开发团队明确系统的结构和组织,从而指导软件系统的设计和实现工作。

类图的特点在于它强调系统中对象之间的关联关系。

一个类表示系统中的一个对象,而关联则表示对象之间的关系。

类图通过线条和箭头来表示类和关联之间的关系,例如,一个类可以关联到另一个类,表示它们之间存在某种关联。

类图还可以使用继承关系来描述类之间的层次结构,例如,一个类可以继承自另一个类,表示它们之间存在父子关系。

三、用例图和类图的关联关系用例图和类图之间存在着紧密的关联关系。

用例图描述了系统的功能需求,而类图描述了系统的结构设计。

用例图中的用例可以通过类图中的类来实现,从而满足系统的功能需求。

具体来说,用例图中的用例可以通过类图中的类的操作来实现。

UML类图及类与类之间的关系

UML类图及类与类之间的关系

UML类图及类与类之间的关系原⽂地址:类图⽤于描述系统中所包含的类以及它们之间的相互关系,帮助⼈们简化对系统的理解,它是系统分析和设计阶段的重要产物,也是系统编码和测试的重要模型依据。

1. 类类(Class)封装了数据和⾏为,是⾯向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。

在系统中,每个类都具有⼀定的职责,职责指的是类要完成什么样的功能,要承担什么样的义务。

⼀个类可以有多种职责,设计得好的类⼀般只有⼀种职责。

在定义类的时候,将类的职责分解成为类的属性和操作(即⽅法)。

类的属性即类的数据职责,类的操作即类的⾏为职责。

设计类是⾯向对象设计中最重要的组成部分,也是最复杂和最耗时的部分。

在软件系统运⾏时,类将被实例化成对象(Object),对象对应于某个具体的事物,是类的实例(Instance)。

类图(Class Diagram)使⽤出现在系统中的不同类来描述系统的静态结构,它⽤来描述不同的类以及它们之间的关系。

在系统分析与设计阶段,类通常可以分为三种,分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class),下⾯对这三种类加以简要说明:(1) 实体类:实体类对应系统需求中的每个实体,它们通常需要保存在永久存储体中,⼀般使⽤数据库表或⽂件来记录,实体类既包括存储和传递数据的类,还包括操作数据的类。

实体类来源于需求说明中的名词,如学⽣、商品等。

(2) 控制类:控制类⽤于体现应⽤程序的执⾏逻辑,提供相应的业务操作,将控制类抽象出来可以降低界⾯和数据库之间的耦合度。

控制类⼀般是由动宾结构的短语(动词+名词)转化来的名词,如增加商品对应有⼀个商品增加类,注册对应有⼀个⽤户注册类等(3) 边界类:边界类⽤于对外部⽤户与系统之间的交互对象进⾏抽象,主要包括界⾯类,如对话框、窗⼝、菜单等。

在⾯向对象分析和设计的初级阶段,通常⾸先识别出实体类,绘制初始类图,此时的类图也可称为领域模型,包括实体类及其它们之间的相互关系。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

在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所示:图1 类的UML图示图1对应的Java代码片段如下:在UML类图中,类一般由三部分组成:(1) 第一部分是类名:每个类都必须有一个名字,类名是一个字符串。

(2) 第二部分是类的属性(Attributes):属性是指类的性质,即类的成员变量。

一个类可以有任意多个属性,也可以没有属性UML规定属性的表示方式为:可见性名称:类型 [ = 缺省值 ]其中:∙“可见性”表示该属性对于类外的元素而言是否可见,包括公有(public)、私有(private)和受保护(protected)三种,在类图中分别用符号+、-和#表示。

∙“名称”表示属性名,用一个字符串表示。

∙“类型”表示属性的数据类型,可以是基本数据类型,也可以是用户自定义类型。

∙“缺省值”是一个可选项,即属性的初始值。

(3) 第三部分是类的操作(Operations):操作是类的任意一个实例对象都可以使用的行为,是类的成员方法。

UML规定操作的表示方式为:可见性名称(参数列表) [ : 返回类型]其中:∙“可见性”的定义与属性的可见性定义相同。

∙“名称”即方法名,用一个字符串表示。

∙“参数列表”表示方法的参数,其语法与属性的定义相似,参数个数是任意的,多个参数之间用逗号“,”隔开。

∙“返回类型”是一个可选项,表示方法的返回值类型,依赖于具体的编程语言,可以是基本数据类型,也可以是用户自定义类型,还可以是空类型(void),如果是构造方法,则无返回类型。

在类图2中,操作method1的可见性为public(+),带入了一个Object类型的参数par,返回值为空(void);操作method2的可见性为protected(#),无参数,返回值为String类型;操作method3的可见性为private(-),包含两个参数,其中一个参数为int类型,另一个为int[]类型,返回值为int类型。

图2 类图操作说明示意图由于在Java语言中允许出现内部类,因此可能会出现包含四个部分的类图,如图3所示:图3 包含内部类的类图类与类之间的关系(1)在软件系统中,类并不是孤立存在的,类与类之间存在各种关系,对于不同类型的关系,UML提供了不同的表示方式。

1. 关联关系关联(Association)关系是类与类之间最常用的一种关系,它是一种结构化关系,用于表示一类对象与另一类对象之间有联系,如汽车和轮胎、师傅和徒弟、班级和学生等等。

在UML类图中,用实线连接有关联关系的对象所对应的类,在使用Java、C#和C++等编程语言实现关联关系时,通常将一个类的对象作为另一个类的成员变量。

在使用类图表示关联关系时可以在关联线上标注角色名,一般使用一个表示两者之间关系的动词或者名词表示角色名(有时该名词为实例对象名),关系的两端代表两种不同的角色,因此在一个关联关系中可以包含两个角色名,角色名不是必须的,可以根据需要增加,其目的是使类之间的关系更加明确。

如在一个登录界面类LoginForm中包含一个JButton类型的注册按钮loginButton,它们之间可以表示为关联关系,代码实现时可以在LoginForm中定义一个名为loginButton的属性对象,其类型为JButton。

如图1所示:图1 关联关系实例图1对应的Java代码片段如下:在UML中,关联关系通常又包含如下几种形式:(1) 双向关联默认情况下,关联是双向的。

例如:顾客(Customer)购买商品(Product)并拥有商品,反之,卖出的商品总有某个顾客与之相关联。

因此,Customer类和Product类之间具有双向关联关系,如图2所示:图2 双向关联实例图2对应的Java代码片段如下:(2) 单向关联类的关联关系也可以是单向的,单向关联用带箭头的实线表示。

例如:顾客(Customer)拥有地址(Address),则Customer类与Address类具有单向关联关系,如图3所示:图3 单向关联实例图3对应的Java代码片段如下:(3) 自关联在系统中可能会存在一些类的属性对象类型为该类本身,这种特殊的关联关系称为自关联。

例如:一个节点类(Node)的成员又是节点Node类型的对象,如图4所示:图4 自关联实例图4对应的Java代码片段如下:(4) 多重性关联多重性关联关系又称为重数性(Multiplicity)关联关系,表示两个关联对象在数量上的对应关系。

在UML中,对象之间的多重性可以直接在关联直线上用一个数字或一个数字范围表示。

对象之间可以存在多种多重性关联关系,常见的多重性表示方式如表1所示:表1 多重性表示方式列表例如:一个界面(Form)可以拥有零个或多个按钮(Button),但是一个按钮只能属于一个界面,因此,一个Form类的对象可以与零个或多个Button类的对象相关联,但一个Button类的对象只能与一个Form类的对象关联,如图5所示:图5 多重性关联实例图5对应的Java代码片段如下:(5) 聚合关系聚合(Aggregation)关系表示整体与部分的关系。

在聚合关系中,成员对象是整体对象的一部分,但是成员对象可以脱离整体对象独立存在。

在UML中,聚合关系用带空心菱形的直线表示。

例如:汽车发动机(Engine)是汽车(Car)的组成部分,但是汽车发动机可以独立存在,因此,汽车和发动机是聚合关系,如图6所示:图6 聚合关系实例在代码实现聚合关系时,成员对象通常作为构造方法、Setter方法或业务方法的参数注入到整体对象中,图6对应的Java代码片段如下:(6) 组合关系组合(Composition)关系也表示类之间整体和部分的关系,但是在组合关系中整体对象可以控制成员对象的生命周期,一旦整体对象不存在,成员对象也将不存在,成员对象与整体对象之间具有同生共死的关系。

在UML中,组合关系用带实心菱形的直线表示。

例如:人的头(Head)与嘴巴(Mouth),嘴巴是头的组成部分之一,而且如果头没了,嘴巴也就没了,因此头和嘴巴是组合关系,如图7所示:图7 组合关系实例在代码实现组合关系时,通常在整体类的构造方法中直接实例化成员类,图7对应的Java代码片段如下:类与类之间的关系(2)2. 依赖关系依赖(Dependency)关系是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。

大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。

在UML中,依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方。

例如:驾驶员开车,在Driver类的drive()方法中将Car类型的对象car作为一个参数传递,以便在drive()方法中能够调用car的move()方法,且驾驶员的drive()方法依赖车的move()方法,因此类Driver依赖类Car,如图1所示:图1 依赖关系实例在系统实施阶段,依赖关系通常通过三种方式来实现,第一种也是最常用的一种方式是如图1所示的将一个类的对象作为另一个类中方法的参数,第二种方式是在一个类的方法中将另一个类的对象作为其局部变量,第三种方式是在一个类的方法中调用另一个类的静态方法。

图1对应的Java代码片段如下:3. 泛化关系泛化(Generalization)关系也就是继承关系,用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。

相关文档
最新文档