最上端区域展现类的名字,类图的指标是显得建立模型系统的档期的顺序

图 5: 三个施用树形暗记的持续实例

双向(标准)的关联
事关是五个类间的对接。关联合国善后救济总署是被假定是双向的;那表示,多个类互相掌握它们间的联系,除非你限定一些任何项指标涉及。回看一下Flight
的例子,图 6 彰显了在Flight类和Plane类之间的一个职业项目标涉嫌。

5到15个

然则,超类(父类)不自然要是抽象类。标准类作为超类是健康的。

聚合 
集中是一种特地类型的关系,用于描述“总体到一些”的涉嫌。在大旨的汇聚关系中, 部分类 的生命周期独立于 整体类 的生命周期。

UML
为这一个项目起了三个特意的名字:“分类器”。平日地,你能够把分类器当做类,但在技艺上,分类器是进一步普及的术语,它还是援用上边的另外两种档期的顺序为好。

含义

比喻来讲:

类的 UML 表示是一个圆锥形,垂直地分为多个区,如图 1
所示。最上端区域突显类的名字。中间的区域列出类的习性。尾巴部分的区域列出类的操作。当在两个类图上画七个类成分时,你必供给有上面包车型地铁区域,上边包车型地铁三个区域是可挑选的(当图描述仅仅用于体现分类器间事关的高层细节时,上面包车型地铁七个区域是不要求的)。图
1 显得贰个航程班机如何作为 UML
类建立模型。正如笔者辈所能见到的,名字是 Flight,大家能够在中间区域看到Flight类的3个特性:flightNumber,departureTime

flightDuration。在底层区域中大家能够看来Flight类有四个操作:delayFlight
和 getArrivalTime。

图 11:扩张关联类 MileageCredit

在面向对象的安排性中贰个极其主要的概念,继承,指的是多少个类(子类)继承其它的叁个类(超类)的一律作用,并追加它自个儿的新职能(一个非技能性的举例,想象小编三番五次了本身老母的相似的音乐力量,不过在自身的家里,作者是天下无双三个玩电吉他的人)的本领。为了在七个类图上建立模型承继,从子类(要三番五次行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。思考银行账户的种类:图
4 展现 CheckingAccount 和 SavingsAccount 类怎样从 BankAccount
类承继而来。

类的属性节(中部区域)在分隔线上列出每三个类的品质。属性节是可挑选的,假设一用它,就带有类的列表彰显的种种属性。该线用如下格式:

*

在图中设有三种办法表示软件包。并不曾法规供给选取哪一种标识,除了用你个人的剖断:哪一种更便于阅读你画的类图。二种格局都以由二个不大的长方形(用于固定)嵌套在三个大的正方形中初步的,如图
8 所示。不过建立模型者必得决定包的积极分子怎样表示,如下:

来得属性暗许值是可挑选的;图 2
显示一个银行账户类具有五个名称叫 balance的花色,它的暗中同意值为0。

关联类
在事关建立模型中,存在一些场馆下,你需求满含另外类,因为它富含了关于关联的有价值的新闻。对于这种意况,你会使用
关联类
来绑定你的为主关系。关联类和一般类同样表示。分歧的是,主类和关联类之间用一条相交的点线连接。图
11 突显贰个航空工业实例的关系类。

balance : Dollars = 0

图 12: 贰个群集关联的例子

图 3:Flight类操作参数,包含可选择的“in”标志。

在作业类图中,属性类型一般与单位符合,那对于图的恐怕读者是有含义的(比如,分钟,韩元,等等)。然则,用于转移代码的类图,必要类的属性类型必得界定在由程序语言提供的项目之中,或含有于在系统中实现的、模型的花色之中。

类操作列表

  • 假如建立模型者决定在大长方形中体现软件包的积极分子,则兼具的那一个成员4内需被放置在纺锤形里面。别的,全数软件包的名字需求放在软件包的十分小星型之内(如图
    8 的显得)。

  • 万第一建工公司模者决定在大的圆锥形之外展现软件包成员,则有所将会在图上呈现的分子都亟需被放置长方形之外。为了呈现属于软件包的分类器属于,从各样分类器画一条线到当中有加号的圆圆,那么些圆周粘附在软件包之上(图9)。

基础

3

表 2:从图 2 光彩夺目的Flight类的操作


关联类 
在关系建立模型中,存在有的场合下,你要求包罗其他类,因为它含有了关于关联的有价值的消息。对于这种情景,你会选用 关联类 来绑定你的着力关系。关联类和一般类同样表示。差别的是,主类和关联类之间用一条相交的点线连接。图
11 显示二个航空工业实例的涉及类。

UML
规范并不供给质量及操作可知性必需出示在类图上,可是它必要为每一种属性及操作定义可知性。为了在类图上的浮现可知性,放置可知性标记于属性或操作的名字从前。尽管UML 钦点七种可知性类型,不过事实上的编制程序语言或许扩张额外的可知性,或不扶助UML 定义的可知性。表4展现了 UML 帮忙的可知性类型的不等标记。

在作业类图中,属性类型一般与单位符合,那对于图的只怕读者是有意义的(举例,秒钟,法郎,等等)。可是,用于转移代码的类图,要求类的性质类型必需界定在由程序语言提供的档案的次序之中,或包括于在系统中贯彻的、模型的品类之中。

类操作列表

譬世尊讲,我们得以想像, 是三个总体实体,而 车轮 轮胎是整辆车的一片段。轮胎能够在安顿到车时的前多少个星期被制作,并放置于酒店中。在这么些实例中,Wheel类实例清楚地单独地Car类实例而存在。不过,有个别情形下, 部分 类的生命周期并  独立于 整体 类的生命周期

那名为合成聚合。譬释迦牟尼说,思考集团与机关的关联。 厂家和机构 都建立模型成类,在公司存在从前,部门无法存在。这里Department类的实例重视于Company类的实例而留存。

让大家更上一层楼切磋基本聚合和构成聚合。

主干聚合 
有成团关系的关系提出,某些类是其它有个别类的一有些。在一个集结关系中,子类实例能够比父类存在更加长的年华。为了表现八个集合关系,你画一条从父类到有些类的实线,并在父类的关系末端画三个未填充棱形。图
12 显示车和轮胎间的聚合关系的例证。

图片 1

图 12: 一个凑合关联的事例

组成聚合 
构成聚合关系是汇聚关系的另一种情势,然而子类实例的生命周期注重于父类实例的生命周期。在图第13中学,突显了Company类和Department类之间的咬合关系,注意组合关系如聚合关系同样绘制,可是本次菱形是被填充的。

图片 2

图 13: 三个构成关系的事例

在图 13中的关系建立模型中,三个Company类实例至少总有多个Department类实例。因为关乎是组成关系,当Company实例被移除/销毁时,Department实例也将自行地被移除/销毁。组合聚合的另一个注重效能是局部类只可以与父类的实例相关(举个例子来讲,大家例子中的Company类)。

反射关联 
当今我们曾经研讨了具备的关系类型。就如您恐怕注意到的,大家的具有例子已经显得了三个差异类之间的关系。但是,类也能够选拔反射关联与它本身相关联。起初,那说不定未有意义,不过切记,类是用空想来欺骗别人的。图
14 展现二个Employee类如何通过manager /
manages剧中人物与它自个儿有关。当贰个类关联到它自己时,这并不意味类的实例与它自身有关,而是类的贰个实例与类的另贰个实例相关。

图片 3

图 14:一个反光关联关系的实例

图 14
描绘的涉嫌说圣元(Nutrilon)个Employee实例恐怕是别的二个Employee实例的经营。可是,因为“manages”的涉嫌剧中人物有
0..*的多种性描述;二个雇员只怕不受任何其他雇员处理。

可见性 
在面向对象的宏图中,存在属性及操作可知性的号子。UML
识别五类别型的可知性:public,protected,private及package。

UML
标准并不供给质量及操作可知性必得出示在类图上,不过它须求为各个属性及操作定义可知性。为了在类图上的显得可知性,放置可知性标记于属性或操作的名字此前。虽然UML 钦定各种可见性类型,然则其实的编制程序语言恐怕扩充额外的可知性,或不支持UML 定义的可知性。表4展现了 UML 援救的可知性类型的两样标记。

表 4:UML 帮忙的可见性类型的标记

标志 可见性类型
+ Public
# Protected
Private
~ Package

现行反革命,让我们看一个类,以表达属性及操作的可知性类型。在图 15中,全体的本性及操作都以public,除了 updateBalance 操作。updateBalance
操作是protected。

图片 4

图 15:三个 BankAccount 类表达它的性质及操作的可见性


回页首

UML
2 补充

既然如此我们早已覆盖了基础和高端核心,大家将覆盖一些由UML 1.
x扩张的类图的新标识。

实例 
当三个系统结营造立模型时,展现例子类实例不时候是可行的。为了这种布局建立模型,UML
2
提供 实例标准 成分,它突显在系统中接纳例子(或具体)实例的值得注意的音讯。

实例的标志和类一样,不过代表最上部区域中仅局地类名,它的名字是经过拼接的:

Instance Name : Class Name

比喻来讲:

Donald : Person

因为浮现实例的指标是显示实价值得注意的或有关的消息,没须求在你的模型中包罗全体实体性质及操作。相反地,仅仅显示感兴趣的个性及其值是一丝一毫适用的。如图16所描述。

图片 5

图 16:Plane类的三个实例例子(只展现感兴趣的属性值)

不过,仅仅显示存个别实例而从未它们的关联不太实用;因而,UML 2
也同目的在于实体层的涉及/关联建立模型。绘制关联与一般的类关系的条条框框一样,除了在建立模型关联时有二个增大的供给。附加的界定是,关联关系必得与类图的关系相平等,何况关系的剧中人物名字也不可能不与类图相平等。它的叁个事例显示于图
17 中。在那么些例子中,实例是图 6 中类图的事例实例。

图片 6

图 17:图 6 中用实例代替类的事例

图 17
有Flight类的二个实例,因为类图提议了在Plane类和Flight类之间的涉嫌是 0或多。由此,大家的事例给出了四个与NX0337
Plane实例相关的Flight实例。

角色 
建立模型类的实例有的时候比期望的更加的详细。不时,你或然仅仅想要在一个很多的相似档期的顺序做类关系的模型。在这种场馆下,你应当运用 角色 暗号。角色暗记类似于实例暗记。为了构建类的剧中人物模型,你画贰个方格,并在在这之中放置类的剧中人物名及类名,作为实体暗记,可是在那景况你不能够加下划线。图
18 显示四个由图 14 中图描述的雇员类扮演的角色实例。在图 1第88中学,我们能够认为,尽管雇员类与它本人有关,关系着实是有关雇员之间扮演老董及团体成员的剧中人物。

图片 7

图 18:三个类图展现图第114中学扮演不一致剧中人物的类

留意,你不可能在纯粹类图中做类剧中人物的建模,即便图
18显得你能够那样做。为了利用角色旗号,你将会须求使用上边钻探的内部结构记号。

当中的布局 
UML 2
结构图的更实惠的效能之一是新的内部结构暗记。它同意你来得五个类或别的的二个分类器如何在内部整合。那在
UML 1. x
中是不可能的,因为暗号限制你只好展现贰个类所全体的联谊关系。今后,在 UML
2 中,内部的构造暗记让你更明亮地展现类的相继部分怎么着有限帮助关系。

让我们看三个实例。在图 18中大家有三个类图以表现二个Plane类怎么着由三个引擎和三个调节软件对象组成。从那几个图中省略的东西是显得关于飞机部件怎么样棉被服装配的一些新闻。从图
18
的图,你不恐怕表明,是各样调节软件对象说了算五个引擎,照旧二个调控软件对象说了算八个引擎,而另三个决定一个引擎。

图片 8

图 19: 只呈现对象时期涉及的类图

绘制类的内在结构将会改正这种场馆。起初时,你通过用三个区域画八个方格。最上边的区域饱含类名字,而好低的区域包括类的内部结构,呈现在它们父类中顶住不相同剧中人物的片段类,剧中人物中的每种部分类也提到到其他类。图
19 体现了Plane类的内部结构;注意内部结构怎么着澄清混乱性。

图片 9

图 20:Plane类的内部结构例子。

在图 20 中Plane有四个ControlSoftware 对象,何况每种调控三个引擎。在图左边上的
ControlSoftware(control1)调整引擎 1 和 2 。在图右侧的
ControlSoftware(control2)调控引擎 3 和 4 。 

让咱们看贰个实例。在图 18中大家有一个类图以表现二个Plane类如何由多少个引擎和五个调整软件对象组成。从那几个图中省略的事物是显得关于飞机部件怎样棉被服装配的片段新闻。从图
18
的图,你不可能表明,是各样调整软件对象说了算八个引擎,照旧二个调节软件对象说了算四个引擎,而另一个调整一个斯特林发动机。

图片 10

0个或四个

图 10:Professor类和Student类实现Person接口的类图实例

结论

关联 
当您系统建立模型时,特定的对象间将会相互关系,何况这么些关系自个儿要求被清楚地建立模型。有三种关系。在这一有的中,笔者将交涉谈它们中的四个– 双向的关系和单向的涉嫌,何况作者将会在Beyond the
basics
局地商讨剩下的三种关系类型。请留心,关于哪一天该利用每体系型涉及的详细冲突,不属于本文的界定。相反的,作者将会把入眼集中在每个关系的用处,并证实什么在类图上画出涉嫌。

二个类和三个接口不一致:八个类能够有它造型的实事求是实例,然则三个接口必得至少有贰个类来兑现它。在
UML 第22中学,叁个接口被感觉是类建立模型成分的特殊化。由此,接口就象类那样绘制,可是圆锥形的最上端区域也可以有文件“interface”,如图
10
所示。5

图 2:展现默感到0美元的balance属性值的银行账户类图。

图片 11

在类图上出示全部暗中认可值的特定属性,不经常是平价的(比如,在银行账户应用程序中,二个新的银行账户会以零为初阶值)。UML
标准允许在属性列表节中,通过动用如下的暗记作为暗许值的标志:

图片 12

大概的多种值描述

标志 可见性类型
+ Public
# Protected
Private
~ Package
操作名称 返回参数 值类型
delayFlight
Name Type
numberOfMinutes Minutes
N/A
getArrivalTime N/A Date

图片 13

有关什么时候、以及如何高效地在系统结构图中使用数据类型和接口的完好切磋,不在本文的座谈范围以内。既然那样,小编为啥要在那边聊到数据类型和接口呢?你或者想在结构图上模仿那一个分类器类型,在那一年,使用准确的暗记来代表,或然至少知道那些分类器类型是重视的。不科学地绘制那一个分类器,很有望将使您的构造图读者认为混乱,以后的系列将不能够适应需要。

图 17
有Flight类的叁个实例,因为类图建议了在Plane类和Flight类之间的关联是
0或多。因而,大家的事例给出了多个与NX0337 Plane实例相关的Flight实例。

1..*

图 14
描绘的关联说惠氏(WYETH)个Employee实例可能是别的叁个Employee实例的经营。可是,因为“manages”的关联剧中人物有
0..*的多种性描述;二个雇员可能不受任何其余雇员管理。

图 8:在软件包的纺锤形内呈现软件包成员的软件包成分例子

上面包车型地铁表 2 中Flight类操作的照耀。

1个或笔者个

图 7: 单向关系三个实例:OverdrawnAccountsReport 类 BankAccount 类,而
BankAccount 类则对关系一窍不通。

在图 11 中显示的类图中,在Flight类和 FrequentFlyer
类之间的涉及,爆发了名为MileageCredit的关系类。那意味当Flight类的贰个实例关联到 FrequentFlyer
类的一个实例时,将会生出 MileageCredit 类的壹个实例。

属性名称 属性类型
flightNumber Integer
departureTime Date
flightDuration Minutes

软件包 
不可幸免,借使您正在为贰个大的系统或大的作业领域建立模型,在你的模型中将会有成都百货上千不及的分类器。管理全体的类将是一件令人生畏的职分;所以,UML
提供一个誉为 软件包的组织成分。软件包使建立模型者可以协会模型分类器到名字空间中,那有个别象文件系统中的文件夹。把叁个种类分为多个软件包使系统成为轻巧掌握,特别是在各类软件包都表现系统的贰个一定部分时。 3

超过基础

表 1:具有关联类型的Flight类的性质名字

0个或1个

类名

图 3:Flight类操作参数,包涵可挑选的“in”标记。

只是,超类(父类)不确定假诺抽象类。标准类作为超类是正规的。

0到5个

只能1个

图片 14

类属性列表

  • 接口

  • 数据类型

  • 组件

图片 15

图 20:Plane类的内部结构例子。

name : attribute type = default value

图 16:Plane类的贰个实例例子(只体现感兴趣的属性值)

图片 16

name : attribute type = default value
  • 如果建立模型者决定在大正方形中体现软件包的积极分子,则有所的那么些成员 4 内需被停放在长方形里面。别的,全部软件包的名字供给放在软件包的相当小长方形之内(如图
    8 的来得)。

  • 一旦建立模型者决定在大的正方形之外呈现软件包成员,则具备将会在图上展现的分子都急需被放到长方形之外。为了彰显属于软件包的分类器属于,从各个分类器画一条线到里头有加号的圆圆,那一个圆周粘附在软件包之上(图9)。

回页首

5..15

回页首

图片 17

1

类操作记录在类图正方形的第多少个(最低的)区域中,它也是可接纳的。和属性一样,类的操作以列表格式呈现,每种操作在它和煦线上。操作使用下列暗号表现:

图 13: 三个构成关系的例子

    name(parameter list) : type of value returned

表 2:从图 2 辉映的Flight类的操作

回页首

图片 18

刺探基础首要性

图 1: Flight类的类图

属性名称 属性类型
flightNumber Integer
departureTime Date
flightDuration Minutes

组成聚合
构成聚合关系是集合关系的另一种格局,然而子类实例的生命周期注重于父类实例的生命周期。在图第13中学,呈现了Company类和Department类之间的咬合关系,注意组合关系如聚合关系一样绘制,不过此番菱形是被填充的。

图 6:在叁个Flight类和Plane类之间的双向关联的实例

反射关联
前段时间大家早已研讨了富有的涉嫌类型。就好像你大概注意到的,大家的富有例子已经呈现了四个不一致类之间的涉嫌。但是,类也足以行使反射关联与它本身相关联。开始,那大概未有趣,可是切记,类是空洞的。图
14 展现七个Employee类如何通过manager /
manages角色与它本人有关。当三个类关联到它本人时,那并不表示类的实例与它自个儿有关,而是类的一个实例与类的另贰个实例相关。

表示

图片 19

表 3: 多种值和它们的代表

3
软件包对于团队你的模子类是天崩地坼的,可是切记首要的一点是,你的类图应该是关于建立模型系统的轻松交换的新闻。在你的软件包有无数类的情景下,最棒使用多个宗旨类图,实际不是仅仅发生一个大的类图。

贰个一边的关联,表示为一条带有指向已知类的盛开箭头(不闭馆的箭头或三角形,用于标识承继)的实线。就好像规范提到,单向关系包涵三个剧中人物名和两个多种值描述,不过与正统的双向关联不一致的时,单向关系只满含已知类的角色名和多种值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,并且知道
BankAccount
类扮演“overdrawnAccounts”的剧中人物。然则,和业内提到不一致,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。 2

有关何时、以及哪些高效地在系统结构图中采纳数据类型和接口的欧洲经济共同体斟酌,不在本文的座谈范围以内。既然那样,笔者为何要在那边聊起数据类型和接口呢?你可能想在结构图上效仿这个分类器类型,在那个时候,使用科学的旗号来表示,也许至少知道那一个分类器类型是非常重要的。不准确地绘制这个分类器,很有希望将使您的构造图读者感到混乱,以往的连串将不能够适应须要。

0..*

只能1个

图 9:几个由此连接线表现软件包成员的软件包例子

类名

一个类和壹个接口分歧:二个类能够有它造型的真正实例,但是多个接口必需至少有二个类来落到实处它。在
UML 2中,二个接口被认为是类建立模型成分的特殊化。由此,接口就象类那样绘制,但是星型的顶上部分区域也可能有文件“interface”,如图
10
所示。 5

让大家更上一层楼探求基本聚合和组合聚合。

图片 20

主干聚合
有成团关系的关系提出,有个别类是别的有些类的一有些。在二个聚焦关系中,子类实例能够比父类存在更加长的年月。为了展现二个成团关系,你画一条从父类到有个别类的实线,并在父类的关系末端画四个未填充棱形。图
12 展现车和轮胎间的汇聚关系的例证。

当文书档案化操作参数时,你恐怕应用三个可挑选的提醒器,以体现参数到操作的输入参数、或输出参数。这一个可选择的提醒器以“in”或“out”出现,如图3中的操作区域所示。一般的话,除非将利用一种前期的前后相继编制程序语言,如Fortran
,那个提示器只怕会怀有扶助,不然它们是不需要的。但是,在
C++和Java中,全部的参数是“in”参数,况兼依照UML标准,既然“in”是参数的暗许类型,大多数人将会遗漏输入/输出提醒器。

Instance Name : Class Name

抽象类及操作 
紧凑的读者会注意到,在图 4 和 图5中的图中,类名BankAccount和withdrawal操作使用斜体。那意味着,BankAccount
类是二个抽象类,而withdrawal方法是画饼充饥的操作。换句话说,BankAccount
类使用withdrawal规定抽象操作,况且CheckingAccount 和 SavingsAccount
多个子类都分别地实施它们各自版本的操作。

  name(parameter list) : type of value returned

在图 4 中,传承关系由种种超类的独门的线画出,这是在IBM Rational
罗斯和IBM Rational
XDE中选拔的主意。然则,有一种叫做 树标记的预备格局能够画出承袭关系。当存在七个或越来越多子类时,如图
4 中所示,除了继续线象树枝同样混在同步外,你能够使用树形暗号。图 5
是重绘的与图 4 一样的接续,可是这一次运用了树形暗号。

*

到此甘休,笔者曾经介绍了类图的底蕴,不过请继续往下读!在底下的一些中,作者将会教导你到您会使用的类图的更要紧的上边。那几个总结UML
2 职业中的接口,别的的三种关系类型,可知性和其他补给。

在面向对象的陈设性中四个那些主要的定义,继承,指的是二个类(子类)继承别的的三个类(超类)的一样成效,并扩展它自身的新效用(三个非能力性的举个例子,想象笔者接二连三了自己老妈的相似的音乐力量,但是在自身的家里,作者是独一叁个玩电吉他的人)的才能。为了在一个类图上建立模型承继,从子类(要再三再四行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。怀恋银行账户的门类:图
4 显示 CheckingAccount 和 SavingsAccount 类怎么着从 BankAccount
类承继而来。

在 UML 第22中学,领会类图的底蕴更为主要。那是因为类图为持有的其他协会图提供基本的创设块。如组件或对象图(仅仅是举了些例子)。

关联
当您系统建立模型时,特定的靶子间将会相互关系,并且这么些涉及本身须求被明晰地建立模型。有多种关系。在这一片段中,笔者将商谈论它们中的七个– 双向的涉及和单向的关联,而且本人将会在Beyond the
basics
部分钻探剩下的三种关系类型。请留心,关于哪一天该采纳每种类型涉及的详实座谈,不属于本文的限量。相反的,我将会把主要集中在每一种关系的用处,并证实什么在类图上画出涉嫌。

继承

在类图上出示全体默许值的特定属性,不时是可行的(比方,在银行账户应用程序中,三个新的银行账户会以零为开首值)。UML
规范允许在属性列表节中,通过利用如下的符号作为默许值的标志:

图 1: Flight类的类图

0..5

双向(标准)的关联 
论及是七个类间的对接。关联总是被假定是双向的;那意味,多个类互相掌握它们间的联络,除非您限定一些别的门类的关联。回想一下Flight
的例证,图 6 展现了在Flight类和Plane类之间的一个标准项目标涉及。

回页首

只能3个

到此截至,作者曾经介绍了类图的基础,可是请继续往下读!在底下的片段中,小编将会指点您到您会利用的类图的更要紧的上边。这几个归纳UML
2 行业内部中的接口,其余的三种关系类型,可见性和别的补给。

在图 第10中学彰显的图中,Professor和Student类都达成了Person的接口,但并不从它继续。大家清楚那或多或少是出于上面多少个原因:1)
Person对象作为接口被定义 —
它在对象的名字区域中有“interface”文本,何况我们见到由于Professor和Student对象依据画类对象的条条框框(在它们的名字区域中并未有额外的分类器文本)标示,所以它们是 目的。
2) 我们知晓承袭在这里未有被显示,因为与带箭头的线是点线并非实线。如图
10
所示,一条带有闭合的单向箭头的 线意味着完毕(或实施);正如我们在图
4 中所见到的,一条带有闭合单向箭头的线意味着继续。

表示

0个或七个

2只怕看起来很想获得, BankAccount 类不驾驭OverdrawnAccountsReport
类。那些建立模型使报表类能够掌握它们报告的业务类,但是专业类不晓得它们正在被告知。那解开七个指标的耦合,并据此使系统变得更能适应变化。

鉴于对那个在关乎尾巴部分或许出现的多种值描述以为猜疑,上面包车型客车表3列出了一些多种值及它们含义的事例。

呈现属性默许值是可选用的;图 2 呈现三个银行账户类具有三个名称叫
balance的类型,它的暗中认可值为0。

图片 21

一个一派的涉及,表示为一条带有指向已知类的怒放箭头(不闭馆的箭头或三角形,用于标识承接)的实线。就像标准提到,单向关系包涵三个剧中人物名和一个多种值描述,不过与业内的双向关联不一样的时,单向关系只包涵已知类的剧中人物名和多种值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,何况知道
BankAccount
类扮演“overdrawnAccounts”的剧中人物。可是,和正式提到差异,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。2

0..5

可能的多种值描述

  • 接口

  • 数据类型

  • 组件

专一,你不能够在纯粹类图中做类角色的建模,尽管图
18出示你能够这么做。为了利用剧中人物暗记,你将会需求动用上面切磋的内部结构记号。

如先前所提到的,类图的目标是体现建立模型系统的类型。在一大半的 UML
模型中这么些品种包括:

图片 22

承袭大家的Flight类的例证,大家能够行使质量类型新闻来汇报类的习性,如表 1
所示。

至少存在五个精通类图的首要理由。第3个是它显得系统一分配类器的静态结构;第4个理由是图为UML描述的别的组织图提供了焦点暗记。开采者将会认为类图是为他们特意制造的;不过任何的集体成员将开采它们也是立竿见影的。业务深入分析师能够用类图,为系统的事体远景建立模型。正如我们将会在本种类有关
UML 基础的小说中观望的,别的的图 —
包涵活动图,类别图和状态图——仿照效法类图中的类建立模型和文书档案化。

0个或四个

5 当画二个类图时,在 UML
规范中,全部要做的只是把类放入圆锥形的顶端区域,而你同理管理接口;不过,UML
标准认为,在这么些区域放置“class”文本是可选的,即使类未有出示,那么它应该被要是。

图 4: 承继通过指向超类的一条闭合的,单箭头的实线表示。

4
要掌握主要一点,当本身说“所有的那么些成员”时,笔者不过表示在当下图中的类将展现出来。呈现多个有内容的软件包的图,无需展现它的装有剧情。它能够依据一些准则,呈现包涵成分的子集,那几个规则正是毫无全体的软件包分类器都是至关重要的。

接口 
在本文的眼下,笔者指出您以类来思索分类器。事实上,分类器是四个越发相似的概念,它包罗数据类型和接口。

name : attribute type
flightNumber : Integer

图片 23

可是,仅仅展现一些实例而并未有它们的关系不太实用;由此,UML 2
也同目的在于实体层的涉及/关联建立模型。绘制关联与一般的类关系的平整同样,除了在建立模型关联时有二个外加的供给。附加的限定是,关联关系必需与类图的涉嫌相平等,而且涉嫌的角色名字也必需与类图相平等。它的四个事例展现于图
17 中。在那一个例子中,实例是图 6 中类图的事例实例。

图片 24

单向关系
在二个单向关系中,多少个类是城门失火的,不过独有叁个类知道这种沟通的存在。图 7
突显单向关系的透支财务报表的一个实例。

3

是因为对那么些在关乎尾巴部分或许出现的多种值描述认为纳闷,上边包车型地铁表3列出了有个别多种值及它们含义的事例。

0个或1个

基础

http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/bell/

在图 10中显得的图中,Professor和Student类都落到实处了Person的接口,但并不从它继续。我们掌握那或多或少是由于上边多少个原因:1)
Person对象作为接口被定义 —
它在目的的名字区域中有“interface”文本,况且大家来看由于Professor和Student对象依照画类对象的法规(在它们的名字区域中并未有额外的分类器文本)标示,所以它们是
对象。 2)
我们知道承袭在那边未有被出示,因为与带箭头的线是点线实际不是实线。如图 10
所示,一条带有闭合的单向箭头的 线意味着实现(或进行);正如大家在图
4 中所见到的,一条带有闭合单向箭头的线意味着继续。

单向关系 
在多个单向关系中,八个类是连锁的,可是唯有三个类知道这种关联的存在。图 7
展现单向关系的透支财务报告的贰个实例。

图片 25

超越基础

其间的布局
UML 2
结构图的更使得的成效之一是新的内部结构暗号。它同意你体现八个类或别的的一个分类器如何在中间整合。那在
UML 1. x
中是非常小概的,因为暗记限制你只好显示二个类所兼有的聚合关系。未来,在 UML
2 中,内部的组织暗记让你更了然地显示类的逐个部分怎么样保证关系。

譬如来讲:

图片 26

图片 27

UML 2 补充

0到5个

图片 28

图 7: 单向关系三个实例:OverdrawnAccountsReport 类 BankAccount 类,而
BankAccount 类则对关系一窍不通。


一个双向关联用三个类间的实线表示。在线的任一端,你放置二个剧中人物名和多种值。图
6
展现Flight与三个一定的Plane相关联,而且Flight类知道这么些涉及。因为角色名以Plane类表示,所以Plane承担关联中的“assignedPlane”剧中人物。紧接于Plane类前边的多种值描述0…1意味着,当三个Flight实体存在时,能够有四个或未有Plane与之提到(约等于,Plane也许还从未被分配)。图
6
也显得Plane知道它与Flight类的关系。在那个涉及中,Flight承担“assignedFlights”角色;图
6
的图告诉大家,Plane实体能够不与flight关联(举例,它是一架斩新的飞行器)或与未有上限的flight(比如,一架已经当兵5年的飞机)关联。

图片 29

更加多的涉嫌 
在地方,笔者谈谈了双向关联和单向关系。未来,作者将会介绍剩下的三种档案的次序的涉嫌。

图 8:在软件包的星型内呈现软件包成员的软件包成分例子

图 11:扩张关联类 MileageCredit

0..*

图3显得,delayFlight 操作有三个Minutes类型的输入参数 —
numberOfMinutes。然而,delayFlight
操作未有再次回到值。 1 当四个操作有参数时,参数被放在操作的括号内;每一个参数都采纳那样的格式:“参数名:参数类型”。

 

上面包车型地铁表 2 中Flight类操作的照射。

图3展现,delayFlight 操作有多少个Minutes类型的输入参数 —
numberOfMinutes。然则,delayFlight
操作未有重回值。1当八个操作有参数时,参数被放在操作的括号内;每一种参数都接纳那样的格式:“参数名:参数类型”。

1

关于“UML 基础”的本体系的背后的预制构件图。

图片 30

图片 31

在图中设有两种方法表示软件包。并未法规供给运用哪个种类标识,除了用你个人的判定:哪一种更利于阅读你画的类图。三种艺术都以由一个十分的小的纺锤形(用于固定)嵌套在贰个大的纺锤形中初露的,如图
8 所示。但是建立模型者必得调控包的积极分子怎样表示,如下:

软件包
不可幸免,假设您正在为二个大的系统或大的事情领域建立模型,在您的模型司令员会有过多例外的分类器。管理全数的类将是一件令人生畏的任务;所以,UML
提供二个誉为
软件包的团伙成分。软件包使建立模型者能够组织模型分类器到名字空间中,这有个别象文件系统中的文件夹。把七个体系分为多少个软件包使系统成为轻巧理解,特别是在各类软件包都表现系统的一个一定部分时。3

图片 32

继承


图片 33

类的属性节(中部区域)在分隔线上列出每三个类的习性。属性节是可挑选的,若是一用它,就隐含类的列表呈现的种种属性。该线用如下格式:

1..*

name : attribute type
flightNumber : Integer

表 4:UML 协助的可知性类型的标识

UML
为那几个项目起了多个特其他名字:“分类器”。平常地,你可以把分类器当做类,但在技能上,分类器是尤为广泛的术语,它依旧援用上边的另外二种档案的次序为好。

1个或自身个

0..1

于今,让大家看三个类,以证实属性及操作的可知性类型。在图 15中,全体的天性及操作都以public,除了 updateBalance 操作。updateBalance
操作是protected。

在图 4 中,承继关系由各样超类的独立的线画出,这是在IBM Rational
罗斯和IBM Rational XDE中采用的不二秘籍。可是,有一种叫做
树标记的希图格局能够画出承继关系。当存在多个或更加多子类时,如图 4
中所示,除了继续线象树枝同样混在一同外,你能够动用树形记号。图 5
是重绘的与图 4 同样的存续,不过此番运用了树形暗号。

类的 UML 表示是三个长方形,垂直地分为八个区,如图 1
所示。最上端区域呈现类的名字。中间的区域列出类的性质。底部的区域列出类的操作。当在贰个类图上画三个类成分时,你要求求有上边的区域,上边包车型客车一个区域是可选择的(当图描述仅仅用于体现分类器间事关的高层细节时,上边包车型地铁七个区域是不需要的)。图
1 显示一个航道班机怎么着作为 UML 类建模。正如小编辈所能见到的,名字是
Flight,大家得以在中游区域看到Flight类的3性格情:flightNumber,departureTime

flightDuration。在底层区域中大家能够见见Flight类有七个操作:delayFlight
和 getArrivalTime。

图片 34

在图 11 中显得的类图中,在Flight类和 FrequentFlyer
类之间的涉嫌,发生了称得上MileageCredit的涉及类。那象征当Flight类的二个实例关联到 FrequentFlyer
类的贰个实例时,将会发生 MileageCredit 类的二个实例。

图片 35

图 4: 承袭通过指向超类的一条闭合的,单箭头的实线表示。


比喻来讲:

只能3个

实例
当四个系统结创设立模型时,展现例子类实例偶尔候是立竿见影的。为了这种结创设立模型,UML
2 提供 实例标准
成分,它显得在系统中央银行使例子(或具体)实例的值得注意的新闻。

如先前所涉嫌的,类图的指标是呈现建立模型系统的类型。在大部的 UML
模型中那个品种包含:

回页首

抽象类及操作
留神的读者会小心到,在图 4 和 图5中的图中,类名BankAccount和withdrawal操作使用斜体。那表示,BankAccount
类是四个抽象类,而withdrawal方法是聊以自慰的操作。换句话说,BankAccount
类使用withdrawal规定抽象操作,并且CheckingAccount 和 SavingsAccount
四个子类都各自地实践它们分别版本的操作。

当文书档案化操作参数时,你只怕使用叁个可接纳的提醒器,以呈现参数到操作的输入参数、或输出参数。那些可挑选的提示器以“in”或“out”出现,如图3中的操作区域所示。一般的话,除非将应用一种开始时期的顺序编制程序语言,如Fortran
,那么些提醒器只怕会怀有补助,不然它们是不供给的。但是,在
C++和Java中,全部的参数是“in”参数,何况依照UML标准,既然“in”是参数的暗中同意类型,大大多人将会遗漏输入/输出提醒器。

1
delayFlight未有再次回到值,因为本人作出了设计决定,不要重回值。有一点能够争执的是,延迟操作应该回到新的达到时间,而且,假如是这种状态,操作属性将显得为
delayFlight(numberOfMinutes : Minutes) : Date。

表 1:具备关联类型的Flight类的习性名字

脚注

图片 36

图 17:图 6 中用实例取代类的例子

含义

角色
建立模型类的实例有的时候比期望的愈发详细。有的时候,你恐怕仅仅想要在多个非常多的形似档案的次序做类关系的模型。在这种情形下,你应该选取
角色
暗号。角色暗号类似于实例暗记。为了树立类的剧中人物模型,你画二个方格,并在在那之中放置类的剧中人物名及类名,作为实体记号,然则在那情况你不能够加下划线。图
18 显示二个由图 14 中图描述的雇员类扮演的剧中人物实例。在图 1第88中学,我们得以认为,就算雇员类与它本人有关,关系真便是关于雇员之间扮演总裁及集体成员的脚色。

图 6:在贰个Flight类和Plane类之间的双向关联的实例

图片 37

图片 38

多个双向关联用四个类间的实线表示。在线的任一端,你放置一个剧中人物名和多种值。图
6
呈现Flight与叁个一定的Plane相关联,并且Flight类知道那一个关系。因为角色名以Plane类表示,所以Plane承担关联合中学的“assignedPlane”角色。紧接于Plane类前边的多种值描述0…1代表,当三个Flight实体存在时,能够有多个或未有Plane与之提到(约等于,Plane大概还并未有被分配)。图
6
也出示Plane知道它与Flight类的涉及。在那一个关系中,Flight承担“assignedFlights”剧中人物;图
6
的图告诉大家,Plane实体能够不与flight关联(譬喻,它是一架全新的飞行器)或与未有上限的flight(譬如,一架已经当兵5年的飞行器)关联。

图 9:二个透过连接线展现软件包成员的软件包例子

 

图 18:一个类图显示图第114中学扮演不相同角色的类

操作名称 返回参数 值类型
delayFlight
Name Type
numberOfMinutes Minutes
N/A
getArrivalTime N/A Date

接口
在本文的先头,小编提议你以类来考虑分类器。事实上,分类器是贰个进一步相似的定义,它总结数据类型和接口。

在图 20 中Plane有多少个 ControlSoftware
对象,並且各样调节贰个引擎。在图左侧上的
ControlSoftware(control1)调控引擎 1 和 2 。在图右侧的
ControlSoftware(control2)调整引擎 3 和 4 。

图 5: 贰个行使树形记号的接轨实例

持续我们的Flight类的事例,大家能够选用质量类型音讯来说述类的属性,如表 1
所示。

图 10:Professor类和Student类完结Person接口的类图实例

更加多的关联
在上头,笔者谈谈了双向关联和单向关系。今后,笔者将会介绍剩下的三种档案的次序的关系。

实例的符号和类同样,但是代表最上端区域中仅部分类名,它的名字是透过拼接的:

图片 39

因为体现实例的目标是呈现值得注意的或有关的新闻,没供给在你的模型中隐含全部实体性质及操作。相反地,仅仅显示感兴趣的本性及其值是一丝一毫适用的。如图16所描述。

可见性
在面向对象的宏图中,存在属性及操作可知性的号子。UML
识别七种类型的可知性:public,protected,private及package。

类属性列表

5到15个

绘制类的内在结构将会改革这种景观。最早时,你通过用二个区域画三个方格。最顶上部分的区域包括类名字,而异常的低的区域满含类的内部结构,突显在它们父类中顶住差别角色的一对类,剧中人物中的各种部分类也涉及到其余类。图
19 展现了Plane类的内部结构;注意内部结构怎样澄清混乱性。

在图 13中的关系建立模型中,三个Company类实例至少总有多个Department类实例。因为关乎是整合关系,当Company实例被移除/销毁时,Department实例也将机关地被移除/销毁。组合聚合的另一个根本意义是局地类只好与父类的实例相关(举个例子来讲,大家例子中的Company类)。

图 19: 只呈现对象期间涉及的类图

既然如此我们曾经覆盖了基础和高等主旨,我们将掩盖一些由UML 1.
x日增的类图的新标识。

0..1

0个或多少个


图 14:二个反光关联关系的实例

5..15

图片 40

表 3: 多种值和它们的象征

比喻来讲,大家得以想像, 是三个总体实体,而 车轮
轮胎是整辆车的一部分。轮胎能够在布署到车时的前多少个礼拜被创设,并放置于仓库中。在这么些实例中,Wheel类实例清楚地独自地Car类实例而留存。但是,某个意况下,
部分 类的生命周期并 独立于 整体 类的生命周期 —
那称为合成聚合。比释迦牟尼讲,思量集团与部门的涉嫌。 同盟社和部门
都建立模型成类,在店肆存在以前,部门无法存在。这里Department类的实例依赖于Company类的实例而留存。

聚合
聚焦是一种特意类型的关系,用于描述“总体到一些”的涉嫌。在着力的聚众关系中,
部分类 的生命周期独立于 整体类 的生命周期。

Donald : Person

图 2:显示默以为0澳元的balance属性值的银行账户类图。

图 15:贰个 BankAccount 类表明它的性子及操作的可见性

在 UML 第22中学,精晓类图的基本功更为首要。那是因为类图为具备的别的协会图提供基本的营造块。如组件或对象图(仅仅是举了些例子)。

询问基础首要性

类操作记录在类图长方形的第多个(最低的)区域中,它也是可选拔的。和属性同样,类的操作以列表格式突显,每一种操作在它和煦线上。操作使用下列暗记表现:

balance : Dollars = 0