在底层区域中我们得以见见Flight类有四个操作

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

基础

如先前所涉及的,类图的指标是彰显建立模型系统的花色。在大多数的 UML
模型中那些项目饱含:

  • 接口

  • 数据类型

  • 组件

UML
为那一个品种起了多个专程的名字:“分类器”。日常地,你能够把分类器当做类,但在技术上,分类器是更为普及的术语,它照旧引用上面包车型地铁任何三连串型为好。

类名

类的 UML 表示是一个星型,垂直地分成八个区,如图 1
所示。顶端区域展现类的名字。中间的区域列出类的属性。尾部的区域列出类的操作。当在三个类图上画二个类成分时,你必得求有上边的区域,上边包车型地铁贰个区域是可选用的(当图描述仅仅用于展示分类器间事关的高层细节时,上面包车型地铁七个区域是不需要的)。图
1 彰显二个航路班机怎么样作为 UML
类建立模型。正如作者辈所能看见的,名字是 Flight,大家得以在此中区域见到Flight类的3本个性:flightNumber,departureTime

flightDuration。在尾巴部分区域中大家得以见见Flight类有三个操作:delayFlight
和 getArrivalTime。

图片 1

图 1: Flight类的类图

类属性列表

类的属性节(中部区域)在分隔线上列出每三个类的属性。属性节是可选拔的,假如一用它,就包涵类的列表呈现的各样属性。该线用如下格式:

name : attribute type
flightNumber : Integer

持续大家的Flight类的例证,我们得以行使性质类型新闻来陈诉类的性质,如表 1
所示。

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

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

在业务类图中,属性类型日常与单位适合,那对于图的大概读者是有意义的(比方,分钟,法郎,等等)。可是,用于转移代码的类图,要求类的性格类型必得界定在由程序语言提供的种类之中,或带有于在系统中落实的、模型的品类之中。

在类图上海展览中心示全体暗许值的特定属性,不常是一蹴而就的(举个例子,在银行账户应用程序中,八个新的银行账户会以零为初步值)。UML
标准允许在属性列表节中,通过动用如下的标识作为暗中同意值的标志:

name : attribute type = default value

比如来佛讲:

balance : Dollars = 0

展现属性暗中同意值是可选用的;图 2
呈现一个银行账户类具有多个名称为 balance的门类,它的私下认可值为0。

图片 2

图 2:彰显默感觉0美金的balance属性值的银行账户类图。

类操作列表

类操作记录在类图纺锤形的第两个(最低的)区域中,它也是可选取的。和性质同样,类的操作以列表格式展现,各个操作在它协调线上。操作使用下列暗号表现:

    name(parameter list) : type of value returned

下边包车型客车表 2 中Flight类操作的映射。

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

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

图3显得,delayFlight 操作有贰个Minutes类型的输入参数 —
numberOfMinutes。可是,delayFlight
操作没有重临值。 1 当二个操作有参数时,参数被放在操作的括号内;每一种参数都利用那样的格式:“参数名:参数类型”。

图片 3

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

当文书档案化操作参数时,你恐怕利用贰个可挑选的提示器,以呈现参数到操作的输入参数、或输出参数。那个可挑选的提醒器以“in”或“out”出现,如图3中的操作区域所示。平时的话,除非将选取一种开始时代的次第编制程序语言,如Fortran
,那么些提醒器只怕会有所援救,否则它们是不须求的。不过,在
C++和Java中,全体的参数是“in”参数,并且依照UML标准,既然“in”是参数的私下认可类型,大相当多人将会遗漏输入/输出提示器。

继承

在面向对象的安顿性中一个可怜关键的概念,继承,指的是贰个类(子类)继承除此以外的四个类(超类)的如出一辙作用,并追加它本人的新效率(三个非才具性的比如,想象自个儿继续了我阿妈的日常的音乐力量,不过在自个儿的家里,笔者是独一二个玩电吉他的人)的力量。为了在多少个类图上建立模型传承,从子类(要持续行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。考虑银行账户的门类:图
4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount
类承继而来。

图片 4

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

在图 4 中,承袭关系由各样超类的单身的线画出,那是在IBM Rational
罗斯和IBM Rational
XDE中央银行使的法门。但是,有一种叫做 树标记的备选格局能够画出承接关系。当存在五个或越来越多子类时,如图
4 中所示,除了一连线象树枝一样混在同步外,你能够动用树形暗号。图 5
是重绘的与图 4 同样的继续,可是此次运用了树形记号。

图片 5

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

抽象类及操作 
紧凑的读者会注意到,在图 4 和 图5中的图中,类名BankAccount和withdrawal操作使用斜体。那象征,BankAccount
类是一个抽象类,而withdrawal方法是虚幻的操作。换句话说,BankAccount
类使用withdrawal规定抽象操作,並且CheckingAccount 和 SavingsAccount
七个子类都各自地推行它们各自版本的操作。

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

关联 
当你系统建立模型时,特定的目的间将会相互关系,并且那一个涉嫌本身要求被清楚地建立模型。有多样关系。在这里一片段中,我将会研商它们中的三个– 双向的关系和单向的关系,何况笔者将会在Beyond the
basics
部分商量剩下的二种关系类型。请留心,关于几时该利用每种类型涉及的详实钻探,不属于本文的界定。相反的,作者将会把主要集中在各样关系的用处,并证实什么在类图上画出涉嫌。

双向(标准)的关联 
事关是多少个类间的联网。关联合国善后救济总署是被假定是双向的;那代表,多少个类互相精晓它们间的沟通,除非您限定一些此外项目标关联。回看一下Flight
的事例,图 6 彰显了在Flight类和Plane类之间的多少个正式项指标涉嫌。

图片 6

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

一个双向关联用两个类间的实线表示。在线的任一端,你放置贰个剧中人物名和多种值。图
6
显示Flight与三个一定的Plane相关联,並且Flight类知道这几个关系。因为剧中人物名以Plane类表示,所以Plane承担关联合中学的“assignedPlane”角色。紧接于Plane类后边的多重值描述0…1意味着,当贰个Flight实体存在时,能够有一个或尚未Plane与之提到(约等于,Plane或许还一直不被分配)。图
6
也显示Plane知道它与Flight类的关联。在此个关系中,Flight承担“assignedFlights”剧中人物;图
6
的图告诉大家,Plane实体能够不与flight关联(举例,它是一架全新的飞机)或与未有上限的flight(举个例子,一架已经服兵役5年的飞行器)关联。

由于对那三个在论及后面部分恐怕出现的多种值描述感觉纳闷,下边包车型客车表3列出了有个别多种值及它们含义的例子。

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

或许的多种值描述

表示

含义

0..1

0个或1个

1

只能1个

0..*

0个或多少个

*

0个或四个

1..*

1个或本身个

3

只能3个

0..5

0到5个

5..15

5到15个

单向关系 
在三个单向关系中,三个类是城门失火的,可是只有一个类知道这种联系的存在。图 7
展现单向关系的透支财务报表的三个实例。

图片 7

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

一个单方面包车型地铁关联,表示为一条带有指向已知类的盛放箭头(不关门的箭头或三角形,用于标识继承)的实线。就像是标准提到,单向关系富含七个角色名和三个多种值描述,但是与正式的双向关联区别的时,单向关系只富含已知类的角色名和多种值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,何况知道
BankAccount
类扮演“overdrawnAccounts”的剧中人物。不过,和典型提到不一致,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。 2

软件包 
不可防止,若是你正在为三个大的系列或大的政工领域建立模型,在您的模子司令员会有为数不菲差异的分类器。管理全体的类将是一件令人生畏的天职;所以,UML
提供五个称为 软件包的团体成分。软件包使建立模型者能够协会模型分类器到名字空间中,那有些象文件系统中的文件夹。把二个系统一分配为五个软件包使系统成为轻巧明白,非常是在每一个软件包都表现系统的二个特定部分时。 3

在图中留存二种办法表示软件包。并从未法则须要采纳哪个种类标记,除了用你个人的判定:哪一类更平价阅读你画的类图。二种方法都以由一个极小的正方形(用于固定)嵌套在一个大的正方形中初叶的,如图
8 所示。可是建立模型者必得调控包的分子怎样表示,如下:

  • 假若建立模型者决定在大长方形中突显软件包的分子,则有着的那一个成员 4 亟待被放置在星型里面。别的,全数软件包的名字必要放在软件包的不大星型之内(如图
    8 的体现)。

  • 假如建立模型者决定在大的长方形之外显示软件包成员,则具备将会在图上展现的积极分子都急需被停放纺锤形之外。为了显示属于软件包的分类器属于,从每种分类器画一条线到内部有加号的圆圆,这个圆周粘附在软件包之上(图9)。

图片 8

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

图片 9

图 9:贰个通过连接线表现软件包成员的软件包例子

问询基础主要性

在 UML 第22中学,理解类图的基本功更为首要。那是因为类图为具备的别的组织图提供基本的创设块。如组件或对象图(仅仅是举了些例子)。


回页首

超越基础

到此结束,笔者一度介绍了类图的基础,可是请继续往下读!在底下的一部分中,作者将会教导你到你会利用的类图的更首要的下边。那几个回顾UML
2 规范中的接口,此外的三种关系类型,可知性和任何补偿。

接口 
在本文的后面,笔者提出您以类来思量分类器。事实上,分类器是三个尤其相似的定义,它归纳数据类型和接口。

至于哪天、以至哪些神速地在系统结构图中使用数据类型和接口的一体化商讨,不在本文的探究范围之内。既然这样,笔者干什么要在此边提起数据类型和接口呢?你也许想在结构图上模仿这个分类器类型,在这里个时候,使用正确的标志来代表,只怕起码知道那一个分类器类型是尤为重要的。不准确地绘制那个分类器,很有相当大希望将使您的布局图读者以为混乱,以后的系统将无法适应供给。

二个类和一个接口不相同:二个类能够有它造型的真人真事实例,但是二个接口必需至罕有贰个类来兑现它。在
UML 2中,多个接口被认为是类建立模型成分的特殊化。因而,接口就象类那样绘制,可是正方形的最上部区域也是有文件“interface”,如图
10
所示。 5

图片 10

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

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

越来越多的涉及 
在地点,作者谈谈了双向关联和单向关系。现在,笔者将会介绍剩下的二种档案的次序的关联。

关联类 
在论及建立模型中,存在一些处境下,你须要富含别的类,因为它饱含了有关关联的有价值的信息。对于这种情景,你会选拔 关联类 来绑定你的中央关系。关联类和平日类一样表示。差异的是,主类和关联类之间用一条相交的点线连接。图
11 展现一个航空工业实例的涉嫌类。

图片 11

图 11:扩大关联类 MileageCredit

在图 11 中显得的类图中,在Flight类和 FrequentFlyer
类之间的涉嫌,产生了名为MileageCredit的涉嫌类。那代表当Flight类的贰个实例关联到 FrequentFlyer
类的三个实例时,将会时有发生 MileageCredit 类的二个实例。

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

比喻来讲,大家能够想像, 是二个完好无缺实体,而 车轮 轮胎是整辆车的一片段。轮胎能够在安排到车时的前多少个星期被制作,并放置于饭店中。在这里个实例中,Wheel类实例清楚地单独地Car类实例而存在。然则,有些情形下, 部分 类的生命周期并  独立于 整体 类的生命周期

那名为合成聚合。比方来讲,考虑公司与机关的涉及。 厂商和单位 都建立模型成类,在小卖部存在在此之前,部门无法存在。这里Department类的实例正视于Company类的实例而留存。

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

主导聚合 
有成团关系的关系提议,某些类是别的有个别类的一片段。在八个成团关系中,子类实例能够比父类存在更加长的时日。为了表现一个凑合关系,你画一条从父类到有些类的实线,并在父类的关系末端画二个未填充棱形。图
12 显示车和轮胎间的聚焦关系的例证。

图片 12

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

结缘聚合 
组合聚合关系是聚众关系的另一种样式,不过子类实例的生命周期信赖于父类实例的生命周期。在图第13中学,突显了Company类和Department类之间的三结合关系,注意组合关系如聚合关系一致绘制,可是此次菱形是被填充的。

图片 13

图 13: 一个构成关系的例证

在图 13中的关系建立模型中,贰个Company类实例起码总有三个Department类实例。因为涉嫌是结合关系,当Company实例被移除/销毁时,Department实例也将自行地被移除/销毁。组合聚合的另三个要害作用是一些类只好与父类的实例相关(例如来佛讲,我们例子中的Company类)。

反射关联 
明日大家曾经钻探了装有的关系类型。就好像您或然注意到的,大家的兼具例子已经展现了多个分化类之间的涉及。不过,类也得以行使反射关联与它本身相关联。初步,那恐怕未有意义,然则切记,类是聊以自慰的。图
14 展现三个Employee类怎样通过manager /
manages剧中人物与它自己有关。当三个类关联到它本人时,那并不代表类的实例与它自个儿有关,而是类的四个实例与类的另四个实例相关。

图片 14

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

图 14
描绘的涉及说澳优个Employee实例恐怕是别的一个Employee实例的COO。但是,因为“manages”的关系剧中人物有
0..*的多种性描述;贰个雇员可能不受任何另外雇员管理。

可见性 
在面向对象的打算中,存在属性及操作可知性的暗号。UML
识别三种类型的可以预知性:public,protected,private及package。

UML
规范并不须求质量及操作可以见到性必需出示在类图上,不过它必要为种种属性及操作定义可以见到性。为了在类图上的呈现可以预知性,放置可以预知性标识于属性或操作的名字以前。即使UML 钦赐多样可以知道性类型,但是实际上的编制程序语言恐怕扩大额外的可以预知性,或不帮衬UML 定义的可知性。表4展现了 UML 帮衬的可以见到性类型的例外标识。

表 4:UML 协理的可以知道性类型的注脚

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

于今,让我们看一个类,以证实属性及操作的可以见到性类型。在图 15中,全数的质量及操作都以public,除了 updateBalance 操作。updateBalance
操作是protected。

图片 15

图 15:三个 BankAccount 类表明它的品质及操作的可以见到性


回页首

UML
2 补充

既是大家早就覆盖了根基和高等主旨,大家将覆盖一些由UML 1.
x扩展的类图的新标识。

实例 
当贰个系统结创设立模型时,展现例子类实例一时候是立见作用的。为了这种布局建立模型,UML
2
提供 实例标准 成分,它展现在系统中利用例子(或具体)实例的值得注意的新闻。

实例的标志和类同样,可是代表顶上部分区域中仅部分类名,它的名字是通过拼接的:

Instance Name : Class Name

比方来讲:

Donald : Person

因为呈现实例的目标是显得值得注意的或有关的新闻,没须求在你的模型中包括全部实体性质及操作。相反地,仅仅展现感兴趣的质量及其值是完全适用的。如图16所描述。

图片 16

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

可是,仅仅展现一些实例而从未它们的关系不太实用;由此,UML 2
也同意在实体层的涉嫌/关联建立模型。绘制关联与平时的类关系的平整一样,除了在建模关联时有一个附加的渴求。附加的限量是,关联关系必需与类图的涉嫌相平等,并且关系的角色名字也不能够不与类图相平等。它的四个例证突显于图
17 中。在此个例子中,实例是图 6 中类图的例子实例。

图片 17

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

图 17
有Flight类的二个实例,因为类图提出了在Plane类和Flight类之间的涉及是 0或多。因而,大家的例证给出了八个与NX0337
Plane实例相关的Flight实例。

角色 
建模类的实例有的时候比期待的越来越详细。有的时候,你或然一味想要在一个很多的形似档案的次序做类关系的模型。在此种情状下,你应当采用 角色 暗号。剧中人物暗记类似于实例暗记。为了树立类的剧中人物模型,你画一个方格,并在内部放置类的剧中人物名及类名,作为实体暗号,不过在此场合你不能够加下划线。图
18 突显贰个由图 14 中图描述的雇员类扮演的角色实例。在图 18中,大家得以以为,尽管雇员类与它自己有关,关系实在是关于雇员之间扮演首席营业官及团体成员的剧中人物。

图片 18

图 18:三个类图呈现图第114中学饰演不一样角色的类

在意,你不可能在纯粹类图中做类剧中人物的建立模型,尽管图
18出示你能够这么做。为了采取剧中人物暗记,你将会须要采纳下边琢磨的内部结构暗记。

里面包车型地铁布局 
UML 2
结构图的更有效的效益之一是新的内部结构灯号。它同意你来得贰个类或其他的二个分类器如何在里面整合。这在
UML 1. x
中是不只怕的,因为暗号限制你不得不显示三个类所怀有的聚合关系。现在,在 UML
2 中,内部的构造暗号令你更精晓地彰显类的顺序部分怎么着保险关系。

让大家看一个实例。在图 18中大家有一个类图以展现三个Plane类怎么样由四个引擎和七个调整软件对象组成。从这几个图中省略的东西是显示关于飞机部件怎么着棉被服装配的一对消息。从图
18
的图,你无法表明,是各种调节软件对象说了算四个引擎,依旧三个调控软件对象说了算八个引擎,而另二个调控贰个引擎。

图片 19

图 19: 只彰显对象之间关系的类图

绘制类的内在结构将会革新这种状态。初叶时,你通过用三个区域画多少个方格。最上部的区域满含类名字,而十分的低的区域富含类的内部结构,突显在它们父类中承受区别剧中人物的一些类,角色中的各个部分类也涉及到别的类。图
19 来得了Plane类的内部结构;注意内部结构怎么着澄清混乱性。

图片 20

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

在图 20 中Plane有几个ControlSoftware 对象,并且种种调整一个引擎。在图左边上的
ControlSoftware(control1)调节引擎 1 和 2 。在图左侧的
ControlSoftware(control2)调控引擎 3 和 4 。