最新精品UML中类图实例
- 格式:docx
- 大小:171.62 KB
- 文档页数:5
浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图(用例)4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图(Collaboration Diagram/communication Diagram)/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言(Unified Modeling Language,UML)又称标准建模语言,是始于1997年的一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。
‘UML感兴趣的可以阅读UML 1规范,包含了UML 的所有知识内容。
注:OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发,定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。
分类:面向对象动态建模,用于建立行为的实体间行为交互的四种图:状态图(Stage Diagram),序列图(Sequence Diagram),协作图(Communication Diagram),活动图(Activity Diagram) 。
“序列图”与“协作图”表述的是相似的消息,“活动图”是“状态图”的一种。
•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图(用例)用例图,展现了一组用例、参与者(actor)以及它们之间的关系。
UML对象图与类图的选择原则与对比分析详解UML(Unified Modeling Language)是一种用于软件开发过程中的标准建模语言,它提供了一套丰富的图形符号和规范,帮助开发人员更好地理解和描述软件系统的结构和行为。
在UML中,对象图和类图是两种常用的建模工具,它们各自有着不同的特点和适用场景。
本文将对UML对象图和类图进行选择原则和对比分析,帮助读者更好地理解它们的应用。
一、UML对象图UML对象图是描述系统中对象之间的静态关系的一种图形表示方式。
它主要用于展示系统中对象的实例以及它们之间的关系。
对象图通常用于详细描述系统的某个特定状态或者场景,它能够清晰地展示对象之间的交互和依赖关系。
对象图的主要特点是直观、具体,能够很好地展示对象的属性和方法。
它适用于需求分析和系统设计的初期阶段,帮助开发人员更好地理解系统的需求和设计方案。
对象图可以帮助开发人员发现系统中的潜在问题和矛盾,从而提前进行调整和优化。
然而,对象图的局限性在于它只能展示系统的某个特定状态或者场景,不能全面地描述系统的整体结构和行为。
因此,在系统设计的后期阶段,开发人员通常会使用类图来更全面地描述系统的结构和行为。
二、UML类图UML类图是描述系统中类之间的静态关系的一种图形表示方式。
它主要用于展示系统的整体结构和类之间的关系。
类图是UML中最常用的一种图形表示方式,它能够清晰地展示类的属性、方法和关联关系。
类图的主要特点是抽象、概括,能够很好地展示系统的整体结构和类之间的关系。
类图适用于系统的整体设计和架构描述,它能够帮助开发人员更好地理解系统的总体设计思路和模块划分。
与对象图相比,类图具有更高的抽象层次和更全面的描述能力。
它能够展示系统的整体结构和行为,帮助开发人员更好地理解和分析系统的复杂性。
因此,在系统设计的后期阶段,开发人员通常会使用类图作为主要的建模工具。
三、选择原则与对比分析在实际的软件开发过程中,开发人员需要根据具体的需求和场景选择合适的建模工具。
目录1.类图和对象图的概念2.类图的组成3.使用Rose创建类图4.对象图5.使用Rose创建类图案例分析类图和对象图详解对于类图和对象图来说我们需要了解的是类图和对象图的概念,类图的组成,使用Rose创建类图和对象图。
当然最重要的是如何使用Rose创建类图案例分析。
具体的创建通过选课管理系统的简单用例说明创建类图和对象图的方法和具体的过程。
下面是我对类图和对象图学习过程的一个整理,一些资料是直接拿过来直接用的。
希望能对你的学习有一点点的帮助吧。
类图和对象图的概念1. 类的含义类图(Class diagram)显示了系统的静态结构,而系统的静态结构构成了系统的概念基础。
类图,就是用于对系统中的各种概念进行建模,并描绘出它们之间关系的图。
在大多数的 UML 模型中,我们可以将这些概念的类型概括为以下四种,分别是:(1) 类(2) 接口(3) 数据类型(4) 构件在类图中,具体来讲它一共包含了以下几种模型元素,分别是:类、接口、依赖关系、泛化关系、关联关系以及实现关系。
类图可以创建约束、注释和包等。
2. 对象图的含义对象图中包含对象(Object)和链(Link)。
其中对象是类的特定实例,链是类之间关系的实例,表示对象之间的特定关系。
3. 类图在项目开发中的作用类图的作用是对系统的静态视图进行建模。
当对系统的静态视图进行建模时,通常是以以下三种方式来使用类图。
(1)为系统的词汇建模。
(2)模型化简单的协作。
(3)模型化逻辑数据库模式。
在设计数据库时,通常将数据库模式看作为数据库概念设计的蓝图,在很多领域中,都需要在关系数据库或面向数据库中存储永久信息。
系统分析者可以使用类图来对这些数据库进行模式建模。
4. 对象图在项目开发中的作用对象图作为系统在某一时刻的快照,是类图中的各个类在某一个时间点上的实例及其关系的静态写照,可以通过以下几个方面来说明它的作用:(1)说明复杂的数据结构。
对于复杂的数据结构,有时候很难对其进行抽象成类表达之间的交互关系。
UML类图及类与类之间的关系原⽂地址:类图⽤于描述系统中所包含的类以及它们之间的相互关系,帮助⼈们简化对系统的理解,它是系统分析和设计阶段的重要产物,也是系统编码和测试的重要模型依据。
1. 类类(Class)封装了数据和⾏为,是⾯向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。
在系统中,每个类都具有⼀定的职责,职责指的是类要完成什么样的功能,要承担什么样的义务。
⼀个类可以有多种职责,设计得好的类⼀般只有⼀种职责。
在定义类的时候,将类的职责分解成为类的属性和操作(即⽅法)。
类的属性即类的数据职责,类的操作即类的⾏为职责。
设计类是⾯向对象设计中最重要的组成部分,也是最复杂和最耗时的部分。
在软件系统运⾏时,类将被实例化成对象(Object),对象对应于某个具体的事物,是类的实例(Instance)。
类图(Class Diagram)使⽤出现在系统中的不同类来描述系统的静态结构,它⽤来描述不同的类以及它们之间的关系。
在系统分析与设计阶段,类通常可以分为三种,分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class),下⾯对这三种类加以简要说明:(1) 实体类:实体类对应系统需求中的每个实体,它们通常需要保存在永久存储体中,⼀般使⽤数据库表或⽂件来记录,实体类既包括存储和传递数据的类,还包括操作数据的类。
实体类来源于需求说明中的名词,如学⽣、商品等。
(2) 控制类:控制类⽤于体现应⽤程序的执⾏逻辑,提供相应的业务操作,将控制类抽象出来可以降低界⾯和数据库之间的耦合度。
控制类⼀般是由动宾结构的短语(动词+名词)转化来的名词,如增加商品对应有⼀个商品增加类,注册对应有⼀个⽤户注册类等(3) 边界类:边界类⽤于对外部⽤户与系统之间的交互对象进⾏抽象,主要包括界⾯类,如对话框、窗⼝、菜单等。
在⾯向对象分析和设计的初级阶段,通常⾸先识别出实体类,绘制初始类图,此时的类图也可称为领域模型,包括实体类及其它们之间的相互关系。
第3章统一建模语言UML简介本章目录第3章统一建模语言UML简介.............................................................. 错误!未定义书签。
3.1 UML概述 (1)3.1.1 UML的产生背景 (1)3.1.2 什么是UML (2)3.1.3 UML中的视图 (3)3.2 UML的构成 (4)3.2.1 UML的体系结构 (4)3.2.2 UML的模型元素 (5)3.2.3 UML的模型结构 (5)3.2.4 UML的模型图 (6)3.2.5 UML建模规则 (7)3.2.6 UML的公用机制 (8)3.3 一个UML的例子 (8)3.3.1 用例图 (9)3.3.2 活动图 (9)3.3.3 顺序图 (10)3.3.4 协作图 (11)3.3.5 类图 (12)3.3.6 状态图 (12)3.3.7 组件图 (13)3.3.8 部署图 (13)建模是为软件开发服务的,因此,如果模型所包含的信息足够完备,就可以以这些信息为基础,进行软件系统的建造。
统一建模语言UML是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模技术,利用UML表达的软件模型,可以直接和某种设计语言建立映射关系,通过UML建造工具,将UML模型转换为对应的程序设计语言源代码框架。
本章简要地回顾了UML的产生背景与UML的视图,重点介绍UML的体系结构和建模规则等内容。
3.1 UML概述UML是一个通用的可视化建模语言,是用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。
其中制品是指软件开发过程中产生的各种产物,例如模型、源代码、测试用例等。
UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域及各种开发工具。
3.1.1 UML的产生背景早在20世纪70年代就陆续出现了面向对象的建模方法,在80年代末到90年代中期,各种建模方法如雨后春笋般出现,从不到10种增加到50多种。
UML业务建模实例分析在我国十年前ATM(自动取款机)还是一个很新鲜的事物,现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机(ATM)系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的,只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性,均为private,其类型分别为char,int,double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance,除caculateBalance为protected其余均为public。
setType设置帐户类型,返回类型为void,参数类型为char,输入帐户类型。
getType获取帐户类型,返回类型为char,无参数。
setAccountNumbe设置帐户号,返回类型为void,参数类型为int,输入帐户号。
getAccountNumbe获取帐户号,返回类型为int,无参数。
caculateBalance计算余额,返回类型为void,参数为double,第一个参数为输入存取款数额,第二个参数为存款余额,既为输入也为输出。
getBalance获取帐户余额,返回类型为double,无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性,哪些操作,它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
【StarUML】类图类图是可视化地表现类的属性和⽅法,以及类与类之间的关系。
1、类a、类普通实体类,它有对应的属性和⽅法:双击类名,会弹出⼀些控制按钮:右边区域,各个图标的含义依次是:增加类的属性、增加类的操作(⽅法)、添加模板类类型参数、添加reception、添加⼦类、添加⽗类、添加已有的接⼝、添加需要的接⼝、添加关联、添加聚合、添加组合、添加端⼝、添加部件。
(1) 添加属性(2) 修改属性的属性属性的属性设置:stereotype:属性描述,类图上的表现是会在属性名的前⾯加上<<>>,中间插⼊属性描述;isstatic:表明该属性是否是静态属性,如果勾选了,属性下⾯会出现下划线;isleaf:表明该属性是否是叶⼦属性,通俗理解是否是final属性,勾选之后,类图不会发⽣变化;type:表明属性的类型,int、long等等,如果填写,会在属性名后⾯出现“:类型名”;multiplicity:这个代表该类实例与其他类实例连接时所需要的数量范围,是⼀个可编辑的下拉框,可以是具体数字,也可以是⼀个区间,⽐如0..1代表着是0到1个,* 代表着⽆数个。
如果填写,会在属性后⾯增加“[]”,中间插⼊填写的值:isReadOnly:代表该字段是否是只读字段,⼀般表⽰属性在对象创建的时候赋值,后续不再改变的变量,填写之后,会在图上增加{ReadOnly};isOrdered:说明属性是可排序的,和multiplicity联⽤,代表着与其他实例连接时,该属性已排序,在图中表现为{ordered};isUnique:说明属性是互斥性,和multiplicity联⽤,代表着与其他实例连接时,属性对象不会重复,在途中表现为{unique};defaultValue:默认值isDerived:代表该属性值是否是由⾃⼰运算出来,或者是由外界来设置,⼀般在编码中表现为⼀个setXXX⽅法,暴露给外⾯,让外⾯的对象设置该属性;在类图中的表现为“/”,放在属性名前⾯;aggregation:代表属性和类的关系,有三个选择:所代表的意思:shared 代表着这个属性对于类来说可有可⽆,属性值为NULL,对象也属于正常对象;composite 代表着这个属性值⼀定得存在,就像飞机(类)和机翼(属性),飞机离不开机翼,如果没有机翼,飞机就不能飞了,就不叫飞机了,顶多在地上跑,⼀辆⼤号的汽车⽽已。
类图及绘制工具StarUMLUnified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。
面向对象的分析与设计(OOA&D,OOAD)方法的发展在80年代末至90年代中出现了一个高潮,而UML就是这个高潮的产物。
OMG:对象管理组织(Object Management Group)UML由3个要素构成:UML的基本构造块、支配这些构造块如何放置在一起的规则和运用于整个语言的公用机制。
UML有3种基本的构造块:事物、关系和图。
事物是对模型中最具有代表性的成分的抽象,包括结构事物,如:类(Class)、接口(Interface)、协作(Collaboration)、用例(UseCase)、主动类(ActiveClass)、组件(Component)和节点(Node);行为事物,如交互(Interaction)、态机(Statemachine)、分组事物(包,Package)、注释事物(注解,Note)。
关系用来把事物结合在一起,包括:依赖、关联、泛化和实现关系。
UML中有九种建模的图标,即:用例图、类图、对象图、顺序图、协作图、状态图、活动图、组件图、配置图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。
强调这个系统是什么而不是这个系统怎么工作。
用例图与情节紧紧相关的。
情节scenario是指当某个人与系统进行互动时发生的情况。
用例图在三个领域很有作用:1.决定特征(需求)。
当系统已经分析好并且设计成型时,新的用例产生新的需求;2.客户通讯。
使用用例图很容易表示开发者与客户之间的联系;3.产生测试用例。
一个用例的情节可能产生这些情节的一批测试用例。
类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。
UML的九种模型图本⽂转⾃,仅供学习交流!⼀、作为⼀种建模语⾔,UML的定义包括UML语义和UML表⽰法两个部分。
UML语义:描述基于UML的精确元模型定义。
UML表⽰法:定义UML符号的表⽰法,为开发者或开发⼯具使⽤这些图形符号和⽂本语法为系统建模提供了标准。
这些图形符号和⽂字所表达的是应⽤级的模型,在语义上它是UML元模型的实例。
⼆、标准建模语⾔UML可以由下列5类图来定义。
⽤例图:从⽤户⾓度描述系统功能,并指出各功能的操作者。
静态图:包括类图和对象图。
类图描述系统中类的静态结构,不仅定义系统中的类,表⽰类之间的联系,如关联、依赖、聚合等,也包括类的属性和操作,类图描述的是⼀种静态关系,在系统的整个⽣命周期都是有效的。
对象图是类图的实例,⼏乎使⽤与类图完全相同的标识。
⼀个对象图是类图的⼀个实例。
由于对象存在⽣命周期,因此对象图只能在系统某⼀时间段存在。
⾏为图:描述系统的动态模型和组成对象间的交互关系,包括状态图和活动图。
状态图描述类的对象所有可能的状态以及事件发⽣时状态的转移条件,状态图是对类图的补充,活动图描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系,有利于识别并进⾏活动。
交互图:描述对象间的交互关系,包括时序图和协作图。
时序图显⽰对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显⽰对象之间的交互;协作图描述对象间的协作关系,协作图跟时序图相似,显⽰对象间的动态合作关系。
除显⽰信息交换外,协作图还显⽰对象以及它们之间的关系。
如果强调时间和顺序,则使⽤时序图;如果强调上下级关系,则选择协作图。
实现图:包括组件图和部署图。
组件图描述代码部件的物理结构及各部件之间的依赖关系,组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。
采⽤UML来设计系统时,第⼀步是描述需求;第⼆步根据需求建⽴系统的静态模型,以构造系统的结构;第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的,包括⽤例图、类图、对象图、组件图和部署图等5种图形,是标准建模语⾔UML的静态建模机制。
UML各种图总结-精华UML(UnifiedModelingLanguage)是一种统一建模语言,为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。
一、基本概念如下图所示,UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图,又可以静动分为静态视图和动态视图。
静态图分为:用例图,类图,对象图,包图,构件图,部署图。
动态图分为:状态图,活动图,协作图,序列图。
1、用例图(UseCaseDiagrams):用例图主要回答了两个问题:1、是谁用软件。
2、软件的功能。
从用户的角度描述了系统的功能,并指出各个功能的执行者,强调用户的使用者,系统为执行者完成哪些功能。
2、类图(ClassDiagrams):用户根据用例图抽象成类,描述类的内部结构和类与类之间的关系,是一种静态结构图。
在UML类图中,常见的有以下几种关系:泛化(Generalization),实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)。
各种关系的强弱顺序:泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何继承父类的所有特征和行为。
例如:老虎是动物的一种,即有老虎的特性也有动物的共性。
2.2.实现【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现。
2.3.关联【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。
双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。
【代码体现】:成员变量2.4.聚合【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。
UML 2.0共有10种图,分别为表示系统静态结构的静态模型(包括类图、组合结构图、部署图),以及表示系统动态结构的动态模型(包括用例图、序列图、对象图、协作图、状态图、活动图、组件图),它们各用以表现不同的视图,如表1-1所示。
用例之间也可以存在包含、扩展和泛化等关系:
(1)包含关系:用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为做为自身行为的一部分,这被称作包含关系。
(2)扩展关系:扩展关系是从扩展用例到基本用例的关系,它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。
它是以隐含形式插入的,也就是说,扩展用例并不在基本用例中显示。
在以下几种情况下,可使用扩展用例:
a.表明用例的某一部分是可选的系统行为(这样,您就可以将模型中的可选行为和必选行为分开);
b.表明只在特定条件(如例外条件)下才执行的分支流;
c.表明可能有一组行为段,其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
(3)泛化关系:用例可以被特别列举为一个或多个子用例,这被称做用例泛化。
当父用例能够被使用时,任何子用例也可以被使用。
如在图2.4中,订票是电话订票和网上订票的抽象。
软件工程的23种设计模式的UML类图0 引言谈到设计模式,绝对应该一起来说说重构。
重构给我们带来了什么?除了作为对遗留代码的改进的方法,另一大意义在于,能够让我们在写程序的时候能够不需事先考虑太多的代码组织问题,当然这其中也包含了应用模式的问题。
尽管大多数开发者都已经养成了写代码前先从设计开始的习惯,但是,这种程度的设计,涉及到到大局、到总体架构、到要紧的模块划分我觉得就够了。
换句话说,这时就能写代码了。
这就得益于重构的思想了。
假如没有重构的思想,有希望获得非常高质量的代码,我们就不得不在开始写代码前考虑更多事实上并非非常稳固的代码组织及设计模式的应用问题,那开发效率当然就大打折扣了。
在重构与设计模式的合理应用之下,我们能够相对较早的开始写代码,并在功能尽早实现的同时,不断地通过重构与模式来改善我们的代码质量。
因此,下面的章节中,在谈模式的同时,我也会谈谈关于常用的这些模式的重构成本的懂得。
重构成本越高意味着,在遇到类似的问题情形的时候,我们更应该提早考虑应用对应的设计模式,而重构成本比较低则说明,类似的情形下,完全能够先怎么方便,怎么快怎么写,哪怕代码不是很优雅也没关系,回头再重构也很容易。
1 创建型1.1FactoryMethod思想:Factory Method的要紧思想是使一个类的实例化延迟到其子类。
场景:典型的应用场景如:在某个系统开发的较早阶段,有某些类的实例化过程,实例化方式可能还不是很确定,或者者实际实例化的对象(可能是需要对象的某个子类中的一个)不确定,或者者比较容易变化。
如今,假如直接将实例化过程写在某个函数中,那么通常就是if-else或者select-case代码。
假如,候选项的数目较少、类型基本确定,那么这样的if-else还是能够同意的,一旦情形变得复杂、不确定性增加,更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时,这样的if-else代码就会变得比较不那么容易保护了。
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对象的一部分。
聚合关系用空
心的菱形+ 实线箭头表示。