UML–类详解

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

图片 1

单向关系 
在一个单向关系中,五个类是连锁的,不过唯有四个类知道这种关联的留存。图 7
呈现单向关系的透支财经报告的贰个实例。

双向(标准)的关联
论及是多个类间的连片。关联合国善后救济总署是被假定是双向的;那意味,八个类互相驾驭它们间的沟通,除非你限定一些别样类型的关系。回看一下Flight
的例证,图 6 显示了在Flight类和Plane类之间的八个正式项目标关联。

类操作列表

Donald : Person

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

比方来讲:

至于几时、以及怎么着快捷地在系统结构图中动用数据类型和接口的一体化商讨,不在本文的研究范围以内。既然那样,作者怎么要在这里谈起数据类型和接口呢?你或许想在结构图上效仿那个分类器类型,在今年,使用科学的号子来代表,可能至少知道这几个分类器类型是重大的。不得法地绘制这么些分类器,很有望将让你的组织图读者以为混乱,现在的体系将无法适应须求。

角色
建立模型类的实例一时比期望的尤为详细。临时,你只怕只是想要在一个较多的貌似档案的次序做类关系的模子。在这种景观下,你应有接纳
角色
暗记。剧中人物暗号类似于实例暗记。为了建设构造类的剧中人物模型,你画三个方格,并在其间放置类的剧中人物名及类名,作为实体暗号,不过在那状态你不能加下划线。图
18 显示叁个由图 14 中图描述的雇员类扮演的剧中人物实例。在图 1第88中学,大家得以以为,纵然雇员类与它自身有关,关系实在是有关雇员之间扮演主任及团队成员的剧中人物。

继承

最少存在七个了然类图的重要理由。第八个是它突显系统一分配类器的静态结构;第贰个理由是图为UML描述的其余协会图提供了宗旨暗记。开拓者将会以为类图是为她们特意成立的;然而其余的团体成员将开掘它们也是卓有成效的。业务解析师可以用类图,为系统的业务远景建模。正如我们将会在本连串有关
UML 基础的稿子中观望的,其他的图 —
包含活动图,体系图和状态图——参谋类图中的类建立模型和文档化。

图片 2

只能1个

表示

含义

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

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

图片 3

图 11:扩充关联类 MileageCredit

  • 接口

  • 数据类型

  • 组件

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

到此甘休,小编早已介绍了类图的根基,不过请继续往下读!在底下的某个中,小编将会指点你到你会使用的类图的更要紧的方面。那一个总结UML
2 专门的学问中的接口,其余的两种关系类型,可知性和其它补偿。

中间的结构
UML 2
结构图的更管用的意义之一是新的内部结构暗号。它同意你显示多个类或其它的一个分类器怎样在其间整合。那在
UML 1. x
中是不恐怕的,因为暗记限制你只可以彰显多少个类所具有的聚焦关系。未来,在 UML
2 中,内部的协会旗号让您更明亮地彰显类的相继部分如何保持关系。

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

在图中设有三种艺术表示软件包。并未规则供给选择哪个种类标记,除了用你个人的论断:哪一类更有利阅读你画的类图。三种办法都以由贰个相当的小的正方形(用于固定)嵌套在贰个大的长方形中初露的,如图
8 所示。可是建立模型者必须决定包的成员怎么样表示,如下:

图片 4

图片 5

图片 6

图片 7

由于对那二个在论及尾部恐怕现身的多种值描述以为纳闷,下边包车型大巴表3列出了部分多种值及它们含义的例子。

结论

比喻来讲:

5 当画一个类图时,在 UML
标准中,全体要做的只是把类放入圆锥形的最上部区域,而你同理处理接口;但是,UML
标准感觉,在这些区域放置“class”文本是可选的,假诺类未有显得,那么它应该被尽管。

比释迦牟尼佛讲,大家得以想象, 是贰个总体实体,而 车轮 轮胎是整辆车的一有个别。轮胎可以在安放到车时的前几个礼拜被塑造,并放置于旅舍中。在那一个实例中,Wheel类实例清楚地单独地Car类实例而留存。但是,某个景况下, 部分 类的生命周期并  独立于 整体 类的生命周期

那称之为合成聚合。举个例子来讲,思索公司与部门的涉嫌。 信用合作社和机构 都建立模型成类,在商家存在以前,部门无法存在。这里Department类的实例依赖于Company类的实例而存在。

让大家更进一步查究基本聚合和构成聚合。

骨干聚合 
有成团关系的涉及提议,某些类是此外有些类的一有个别。在多个凑合关系中,子类实例能够比父类存在更加长的时光。为了显示二个晤面关系,你画一条从父类到部分类的实线,并在父类的关联末端画贰个未填充棱形。图
12 显示车和轮胎间的集纳关系的事例。

图片 8

图 12: 四个群集关联的事例

结合聚合 
组成聚合关系是汇聚关系的另一种样式,可是子类实例的生命周期注重于父类实例的生命周期。在图第13中学,展现了Company类和Department类之间的结合关系,注意组合关系如聚合关系一致绘制,但是此番菱形是被填充的。

图片 9

图 13: 二个结合关系的例子

在图 13中的关系建立模型中,七个Company类实例至少总有贰个Department类实例。因为关乎是结合关系,当Company实例被移除/销毁时,Department实例也将活动地被移除/销毁。组合聚合的另三个关键成效是有个别类只可以与父类的实例相关(举例来讲,大家例子中的Company类)。

反射关联 
现行反革命大家曾经讨论了颇具的关联类型。就像你或者注意到的,大家的持有例子已经显得了五个分化类之间的涉及。可是,类也足以运用反射关联与它本人相关联。开头,那大概未有意义,可是切记,类是画饼充饥的。图
14 呈现二个Employee类怎么样通过manager /
manages脚色与它本人有关。当贰个类关联到它自己时,那并不表示类的实例与它自身有关,而是类的贰个实例与类的另三个实例相关。

图片 10

图 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。

图片 11

图 15:一个 BankAccount 类表达它的属性及操作的可知性


回页首

UML
2 补充

既是大家曾经覆盖了基础和高等大旨,大家将覆盖一些由UML 1.
x扩张的类图的新标记。

实例 
当二个系统结构建立模型时,呈现例子类实例一时候是行得通的。为了这种布局建立模型,UML
2
提供 实例标准 成分,它展现在系统中央银行使例子(或具体)实例的值得注意的信息。

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

Instance Name : Class Name

举例来说:

Donald : Person

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

图片 12

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

不过,仅仅呈现成个别实例而尚未它们的涉嫌不太实用;由此,UML 2
也同意在实体层的涉及/关联建立模型。绘制关联与一般的类关系的条条框框平等,除了在建立模型关联时有多少个叠合的供给。附加的限定是,关联关系必须与类图的涉嫌相平等,而且关乎的剧中人物名字也亟须与类图相平等。它的叁个事例呈现于图
17 中。在这些事例中,实例是图 6 中类图的例证实例。

图片 13

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

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

角色 
建立模型类的实例有的时候比期望的特别详细。有的时候,你或者唯有想要在七个较多的相似档期的顺序做类关系的模型。在这种景况下,你应有利用 角色 暗记。剧中人物暗记类似于实例暗记。为了树立类的剧中人物模型,你画贰个方格,并在个中放置类的剧中人物名及类名,作为实体暗记,不过在那状态你无法加下划线。图
18 彰显四个由图 14 中图描述的雇员类扮演的剧中人物实例。在图 18中,大家得以感到,纵然雇员类与它自个儿有关,关系真正是关于雇员之间扮演首席营业官及团伙成员的角色。

图片 14

图 18:一个类图展现图第114中学饰演差别剧中人物的类

专注,你不可能在纯粹类图中做类剧中人物的建立模型,即便图
18呈现你能够这么做。为了选择剧中人物暗号,你将会供给选拔下边商讨的内部结构记号。

内部的结构 
UML 2
结构图的更实用的功能之一是新的内部结构暗号。它同意你展现叁个类或别的的二个分类器如何在里面整合。那在
UML 1. x
中是不容许的,因为旗号限制你不得不突显四个类所全体的联谊关系。今后,在 UML
2 中,内部的布局暗号让您更掌握地出示类的依次部分如何保持关系。

让我们看三个实例。在图 18中大家有叁个类图以表现一个Plane类怎么着由多个引擎和三个调整软件对象组成。从这些图中省略的事物是展现关于飞机部件怎么样棉被服装配的局地音信。从图
18
的图,你不可能表达,是各样调控软件对象说了算五个引擎,依旧三个调整软件对象说了算多少个引擎,而另三个操纵一个斯特林发动机。

图片 15

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

绘制类的内在结构将会改正这种景象。开头时,你通过用一个区域画多少个方格。顶部的区域包涵类名字,而十分低的区域包罗类的内部结构,展现在它们父类中担负不一致剧中人物的局部类,剧中人物中的每一种部分类也涉嫌到其余类。图
19 展现了Plane类的内部结构;注意内部结构怎么样澄清混乱性。

图片 16

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

在图 20 中Plane有三个ControlSoftware 对象,而且每一个调整叁个引擎。在图左侧上的
ControlSoftware(control1)调节引擎 1 和 2 。在图右侧的
ControlSoftware(control2)调节引擎 3 和 4 。 

只能3个

当文书档案化操作参数时,你大概应用二个可挑选的指示器,以展现参数到操作的输入参数、或输出参数。这些可选用的提醒器以“in”或“out”出现,如图3中的操作区域所示。一般的话,除非将动用一种开始时代的次序编制程序语言,如Fortran
,这么些提醒器也许会怀有协理,不然它们是不须要的。可是,在
C++和Java中,全体的参数是“in”参数,而且根据UML标准,既然“in”是参数的暗许类型,大许多人将会遗漏输入/输出提醒器。

0个或四个

5..15

3

name : attribute type
flightNumber : Integer
  • 接口

  • 数据类型

  • 组件

类的 UML 表示是贰个星型,垂直地分为八个区,如图 1
所示。最上端区域显示类的名字。中间的区域列出类的性质。尾部的区域列出类的操作。当在叁个类图上画一个类成分时,你必供给有上面的区域,下面包车型客车贰个区域是可挑选的(当图描述仅仅用于显示分类器间事关的高层细节时,上边的七个区域是不供给的)。图
1 展现四个航行路线班机怎么样作为 UML
类建立模型。正如小编辈所能见到的,名字是 Flight,大家能够在个中区域看到Flight类的3个属性:flightNumber,departureTime

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

0..5

图 1: Flight类的类图


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

  • 只要建立模型者决定在大正方形中展示软件包的积极分子,则怀有的那多少个成员4急需被停放在长方形里面。此外,全数软件包的名字须求放在软件包的十分的小长方形之内(如图
    8 的显得)。

  • 假诺建模者决定在大的圆柱形之外显示软件包成员,则装有将会在图上展现的成员都亟待被内置星型之外。为了显得属于软件包的分类器属于,从每种分类器画一条线到个中有加号的圆圆,那个圆周粘附在软件包之上(图9)。

摸底基础主要性

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

关联类 
在关系建模中,存在一些场所下,你需求包蕴别的类,因为它涵盖了关于关联的有价值的音讯。对于这种状态,你会利用 关联类 来绑定你的大旨关系。关联类和一般类同样表示。分歧的是,主类和关联类之间用一条相交的点线连接。图
11 显示二个航空工业实例的关系类。

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

类名

至于何时、以及怎么样飞快地在系统结构图中运用数据类型和接口的一体化探究,不在本文的座谈范围之内。既然那样,小编为何要在这里谈起数据类型和接口呢?你只怕想在结构图上效仿那个分类器类型,在那年,使用正确的号子来代表,或然至少知道那个分类器类型是首要的。不得法地绘制那一个分类器,很有望将使您的布局图读者认为混乱,未来的系统将无法适应要求。

0个或多个

着力聚合
有汇聚关系的关系建议,有个别类是此外有些类的一有的。在多少个聚众关系中,子类实例能够比父类存在越来越长的大运。为了表现三个成团关系,你画一条从父类到有的类的实线,并在父类的涉嫌末端画一个未填充棱形。图
12 显示车和轮胎间的集纳关系的例证。

想必的多种值描述

图 1: Flight类的类图

balance : Dollars = 0

图片 17

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

图片 18

UML
为那个类别起了三个专程的名字:“分类器”。平时地,你能够把分类器当做类,但在技艺上,分类器是更加宽广的术语,它照旧引用下面的其余二种档案的次序为好。

抽象类及操作
密切的读者会专注到,在图 4 和 图5中的图中,类名BankAccount和withdrawal操作使用斜体。那表示,BankAccount
类是多少个抽象类,而withdrawal方法是虚幻的操作。换句话说,BankAccount
类使用withdrawal规定抽象操作,并且CheckingAccount 和 SavingsAccount
三个子类都分别地推行它们各自版本的操作。

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

绘制类的内在结构将会革新这种景况。早先时,你通过用三个区域画一个方格。最上方的区域包罗类名字,而相当低的区域包蕴类的内部结构,展现在它们父类中肩负分歧剧中人物的一部分类,剧中人物中的种种部分类也事关到此外类。图
19 来得了Plane类的内部结构;注意内部结构怎么样澄清混乱性。

图片 19

关联
当你系统建立模型时,特定的靶子间将会相互关系,而且那个关系自己须要被清晰地建立模型。有两种关系。在这一局地中,我将谈判谈它们中的七个– 双向的涉及和单向的涉及,而且小编将会在Beyond the
basics
局地探究剩下的二种关系类型。请留心,关于哪天该应用每类别型涉及的详细座谈,不属于本文的限定。相反的,笔者将会把关键聚焦在各个关系的用处,并证实什么在类图上画出涉嫌。

图片 20

或是的多种值描述

双向(标准)的关联 
关联是四个类间的交接。关联合国善后救济总署是被假定是双向的;那象征,多个类相互掌握它们间的关系,除非你限定一些其余项指标涉及。回想一下Flight
的例证,图 6 展现了在Flight类和Plane类之间的三个业内项目标关系。

类的 UML 表示是壹个正方形,垂直地分成多个区,如图 1
所示。最上部区域展现类的名字。中间的区域列出类的习性。尾巴部分的区域列出类的操作。当在贰个类图上画二个类成分时,你必需要有上边的区域,上边包车型地铁一个区域是可选拔的(当图描述仅仅用于展示分类器间事关的高层细节时,下边包车型地铁八个区域是不须要的)。图
1 来得贰个航道班机怎么着作为 UML 类建立模型。正如我辈所能见到的,名字是
Flight,我们可以在中等区域来看Flight类的3个属性:flightNumber,departureTime

flightDuration。在尾部区域中大家能够看出Flight类有多个操作:delayFlight
和 getArrivalTime。

在图中存在三种方法表示软件包。并不曾规则供给接纳哪一类标识,除了用你个人的推断:哪类更有益于阅读你画的类图。二种方法都以由八个极小的星型(用于固定)嵌套在三个大的圆柱形中早先的,如图
8 所示。然而建立模型者必须调节包的分子怎么样表示,如下:

1..*

接轨大家的Flight类的事例,大家能够使用性质类型消息来说述类的品质,如表 1
所示。

图片 21

在图 4 中,承接关系由各样超类的独门的线画出,那是在IBM Rational
罗丝和IBM Rational
XDE中使用的点子。可是,有一种名为 树标记的备选格局能够画出承接关系。当存在七个或更加多子类时,如图
4 中所示,除了继续线象树枝同样混在一块儿外,你能够应用树形暗号。图 5
是重绘的与图 4 同样的承继,但是这一次运用了树形暗记。

在图 11 中展现的类图中,在Flight类和 FrequentFlyer
类之间的涉及,发生了名称叫MileageCredit的关联类。那意味着当Flight类的贰个实例关联到 FrequentFlyer
类的四个实例时,将会产生 MileageCredit 类的四个实例。

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

UML 2 补充

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

  • 要是建立模型者决定在大长方形中显得软件包的分子,则持有的那么些成员 4 亟需被停放在长方形里面。其余,全数软件包的名字需求放在软件包的相当小星型之内(如图
    8 的显示)。

  • 一旦建立模型者决定在大的长方形之外展现软件包成员,则装有将会在图上展现的分子都亟待被放到正方形之外。为了浮现属于软件包的分类器属于,从种种分类器画一条线到中间有加号的圆圆,那些圆周粘附在软件包之上(图9)。

基础

可是,超类(父类)不必然若是抽象类。标准类作为超类是正规的。

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

1个或本身个

name : attribute type
flightNumber : Integer

图 5: 多个用到树形暗号的存在延续实例

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

基础

2可能看起来很意外, BankAccount 类不明白OverdrawnAccountsReport
类。这一个建立模型使报表类能够领略它们报告的业务类,可是职业类不清楚它们正在被报告。这解开多个指标的耦合,并为此使系统变得更能适应变化。

图片 22

比喻来讲,大家能够想像, 是四个完好无缺实体,而 车轮
轮胎是整辆车的一局地。轮胎能够在铺排到车时的前多少个礼拜被构建,并放置于饭店中。在那一个实例中,Wheel类实例清楚地单独地Car类实例而留存。然则,某个景况下,
部分 类的生命周期并 独立于 整体 类的生命周期 —
这称为合成聚合。举例来佛讲,挂念公司与单位的关系。 商铺和机关
都建立模型成类,在集团存在在此之前,部门无法存在。这里Department类的实例信赖于Company类的实例而留存。

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

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

0到5个

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

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

  name(parameter list) : type of value returned

图 11:扩充关联类 MileageCredit

当文书档案化操作参数时,你可能利用一个可挑选的提示器,以显示参数到操作的输入参数、或输出参数。那些可挑选的提醒器以“in”或“out”出现,如图3中的操作区域所示。一般的话,除非将使用一种开始时代的次序编制程序语言,如Fortran
,那些提示器或许会全部支持,不然它们是不须求的。不过,在
C++和Java中,全体的参数是“in”参数,而且依据UML规范,既然“in”是参数的暗中认可类型,大好些个人将会遗漏输入/输出提示器。

关联 
当你系统建立模型时,特定的目的间将会互相关系,而且这个关系本身需求被清楚地建立模型。有各个关系。在这一局地中,笔者将会谈论它们中的八个– 双向的涉及和单向的涉及,而且小编将会在Beyond the
basics
局部商讨剩下的二种关系类型。请留心,关于哪天该使用每种类型涉及的详细商议,不属于本文的范围。相反的,小编将会把首要集中在种种关系的用处,并表达如何在类图上画出涉及。

图 5: 三个应用树形暗记的延续实例

*

1

0..5

图片 23

如先前所涉及的,类图的指标是展现建立模型系统的类别。在大好多的 UML
模型中这几个体系包含:

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

在 UML 2中,精晓类图的底子更为主要。那是因为类图为具备的别样组织图提供基本的创设块。如组件或对象图(仅仅是举了些例子)。

UML
标准并不要求质量及操作可知性必须出示在类图上,可是它需求为各类属性及操作定义可知性。为了在类图上的显得可知性,放置可知性标识于属性或操作的名字在此以前。固然UML 内定三种可知性类型,可是实际的编制程序语言大概扩大额外的可知性,或不支持UML 定义的可知性。表4显示了 UML 帮忙的可知性类型的不一样标识。

更加多的涉及 
在上头,我谈谈了双向关联和单向关系。今后,作者将会介绍剩下的三系列型的涉及。

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

图片 24

回页首

软件包 
不可幸免,借使你正在为二个大的连串或大的政工领域建立模型,在你的模子师长会有过多两样的分类器。管理全数的类将是一件令人生畏的天职;所以,UML
提供二个名叫 软件包的集团成分。软件包使建立模型者能够组织模型分类器到名字空间中,那有些象文件系统中的文件夹。把三个类别分为三个软件包使系统成为轻松精通,尤其是在种种软件包都表现系统的叁个特定部分时。 3

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

在业务类图中,属性类型一般与单位符合,那对于图的或是读者是有含义的(比如,分钟,比索,等等)。不过,用于转移代码的类图,供给类的性质类型必须界定在由程序语言提供的门类之中,或含有于在系统中实现的、模型的品种之中。

超过基础

在面向对象的布置中一个要命重大的定义,继承,指的是贰个类(子类)继承其它的多个类(超类)的同样成效,并扩张它和煦的新职能(一个非本事性的比如,想象本人继续了作者老妈的形似的音乐力量,可是在自家的家里,笔者是有一无二三个玩电吉他的人)的力量。为了在多个类图上建立模型承袭,从子类(要承继行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。思念银行账户的等级次序:图
4 展现 CheckingAccount 和 SavingsAccount 类怎么样从 BankAccount
类传承而来。

UML
为那么些品种起了一个特地的名字:“分类器”。平常地,你能够把分类器当做类,但在技能上,分类器是尤为广大的术语,它照旧引用上面包车型客车其余三系列型为好。

一个类和一个接口不相同:二个类能够有它造型的忠实实例,不过三个接口必须至少有多少个类来落到实处它。在
UML 第22中学,二个接口被以为是类建立模型成分的特殊化。因而,接口就象类那样绘制,然而星型的最上部区域也可以有文件“interface”,如图
10
所示。 5

单向关系
在二个单向关系中,多个类是有关的,不过只有三个类知道这种关系的存在。图 7
展现单向关系的透支财经报告的多少个实例。

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

1个或自个儿个

1

脚注

图片 25

表 4:UML 援救的可知性类型的注明

图 8:在软件包的正方形内展现软件包成员的软件包成分例子

反射关联
今后大家曾经研讨了全数的关系类型。就像您大概注意到的,大家的享有例子已经显得了七个不相同类之间的关系。但是,类也得以接纳反射关联与它本人相关联。起头,这大概没风趣,但是切记,类是画饼充饥的。图
14 展现三个Employee类怎么着通过manager /
manages剧中人物与它本身有关。当二个类关联到它本人时,那并不意味着类的实例与它自己有关,而是类的三个实例与类的另一个实例相关。

抽象类及操作 
周全的读者会小心到,在图 4 和 图5中的图中,类名BankAccount和withdrawal操作使用斜体。那象征,BankAccount
类是几个抽象类,而withdrawal方法是空洞的操作。换句话说,BankAccount
类使用withdrawal规定抽象操作,并且CheckingAccount 和 SavingsAccount
三个子类都各自地实施它们分别版本的操作。

接口
在本文的日前,笔者建议您以类来设想分类器。事实上,分类器是贰个一发相似的概念,它包含数据类型和接口。

只能3个

在类图上海展览中心示全数暗中认可值的特定属性,不时是卓有成效的(例如,在银行账户应用程序中,一个新的银行账户会以零为起首值)。UML
标准允许在属性列表节中,通过使用如下的号子作为暗中认可值的标志:

1..*

图片 26

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

聚合
聚拢是一种专门类型的涉嫌,用于描述“总体到部分”的关联。在主导的汇合关系中,
部分类 的生命周期独立于 整体类 的生命周期。

含义

图片 27

聚合 
聚拢是一种极其类型的涉嫌,用于描述“总体到部分”的涉及。在宗旨的集合关系中, 部分类 的生命周期独立于 整体类 的生命周期。

鉴于对那多少个在关乎尾巴部分或然出现的多种值描述认为狐疑,上面的表3列出了有的多种值及它们含义的例证。

只能1个

在作业类图中,属性类型一般与单位符合,那对于图的大概读者是有含义的(比如,分钟,新币,等等)。可是,用于转移代码的类图,须要类的属性类型必须界定在由程序语言提供的花色之中,或含有于在系统中完成的、模型的体系之中。

在类图上体现全部暗中认可值的一定属性,有的时候是行得通的(比如,在银行账户应用程序中,多少个新的银行账户会以零为早先值)。UML
标准允许在属性列表节中,通过运用如下的标识作为暗中认可值的标志:

图 18:贰个类图突显图第114中学扮演不一样角色的类

接口 
在本文的日前,作者提出您以类来设想分类器。事实上,分类器是三个尤为相似的概念,它包罗数据类型和接口。

叩问基础重要性

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

0个或四个

5到15个

而是,仅仅显示一些实例而没有它们的关系不太实用;由此,UML 2
也同意在实体层的涉及/关联建立模型。绘制关联与一般的类关系的平整同样,除了在建立模型关联时有贰个外加的供给。附加的范围是,关联关系必须与类图的关系相平等,而且波及的剧中人物名字也务必与类图相平等。它的三个事例展现于图
17 中。在那么些例子中,实例是图 6 中类图的例证实例。

类属性列表

4
要明了主要一点,当作者说“全体的那三个成员”时,小编偏偏意味着在当前图中的类将突显出来。展现多少个有内容的软件包的图,没有需求出示它的富有内容。它能够依照一些轨道,展现包蕴成分的子集,那个规则正是不用全部的软件包分类器都以必不可少的。

name : attribute type = default value

举个例子来讲:

    name(parameter list) : type of value returned
balance : Dollars = 0

0个或多少个

0..*

跨越基础

*

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

在 UML 2中,精通类图的根底更为首要。那是因为类图为具备的任何组织图提供基本的塑造块。如组件或对象图(仅仅是举了些例子)。

图3展现,delayFlight 操作有一个Minutes类型的输入参数 —
numberOfMinutes。但是,delayFlight
操作未有重临值。 1 当叁个操作有参数时,参数被放在操作的括号内;每一个参数都使用那样的格式:“参数名:参数类型”。

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

图 2:突显默许为0欧元的balance属性值的银行账户类图。

在图 4 中,承继关系由各种超类的独自的线画出,那是在IBM Rational
罗丝和IBM Rational XDE中运用的点子。但是,有一种名为
树标记的预备方式能够画出承袭关系。当存在四个或更加的多子类时,如图 4
中所示,除了继续线象树枝同样混在协同外,你能够行使树形暗号。图 5
是重绘的与图 4 一样的存在延续,不过这一次运用了树形暗号。

类操作记录在类图圆锥形的第多个(最低的)区域中,它也是可选择的。和总体性同样,类的操作以列表格式显示,每一种操作在它自身线上。操作使用下列暗号表现:

再三再四大家的Flight类的事例,大家得以接纳质量类型音讯来说述类的习性,如表 1
所示。

在图 10中显得的图中,Professor和Student类都完结了Person的接口,但并不从它一连。我们知道这点是由于下边八个原因:1)
Person对象作为接口被定义 —
它在对象的名字区域中有“interface”文本,而且大家看到由于Professor和Student对象依照画类对象的平整(在它们的名字区域中尚无额外的分类器文本)标示,所以它们是 指标。
2) 我们清楚承接在那边未有被出示,因为与带箭头的线是点线而不是实线。如图
10
所示,一条带有闭合的单向箭头的 线意味着已毕(或推行);正如大家在图
4 中所见到的,一条带有闭合单向箭头的线意味着继续。

来得属性默许值是可选取的;图 2 呈现贰个银行账户类具备多少个名称为
balance的门类,它的私下认可值为0。

二个一派的涉嫌,表示为一条带有指向已知类的盛开箭头(不停业的箭头或三角形,用于标记承袭)的实线。如同规范提到,单向关系包含二个剧中人物名和八个多种值描述,然而与规范的双向关联分化的时,单向关系只包罗已知类的角色名和多种值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,而且知道
BankAccount
类扮演“overdrawnAccounts”的剧中人物。但是,和正式提到差异,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。 2


0..*

类属性列表


0..1

回页首

图 12: 三个会晤关联的例子

0个或1个

 

图片 28

图片 29

0..1

0个或1个

图片 30

5..15

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

回页首

3

图片 31

呈现属性暗中同意值是可选拔的;图 2
呈现贰个银行账户类具备三个名称为 balance的花色,它的暗中认可值为0。

上面包车型大巴表 2 中Flight类操作的投射。

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

类名

1
delayFlight未有重临值,因为自身作出了安顿决定,不要重回值。有好几得以争执的是,延迟操作应该回到新的到达时间,而且,假设是这种景观,操作属性将显得为
delayFlight(numberOfMinutes : Minutes) : Date。

关联类
在关系建立模型中,存在一些情况下,你须求包涵其余类,因为它包涵了有关关联的有价值的音讯。对于这种气象,你会选取
关联类
来绑定你的为主关系。关联类和一般类一样表示。不相同的是,主类和关联类之间用一条相交的点线连接。图
11 呈现八个航空工业实例的关联类。

在图 13中的关系建模中,七个Company类实例至少总有一个Department类实例。因为涉及是结合关系,当Company实例被移除/销毁时,Department实例也将电动地被移除/销毁。组合聚合的另多个器重职能是局地类只可以与父类的实例相关(比释尊讲,大家例子中的Company类)。

0到5个

继承

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

name : attribute type = default value

图片 32

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

图 14
描绘的涉嫌说飞鹤(Karicare)个Employee实例大概是其余三个Employee实例的经营。不过,因为“manages”的关联角色有
0..*的多种性描述;一个雇员只怕不受任何别的雇员管理。

回页首

三个双向关联用八个类间的实线表示。在线的任一端,你放置二个剧中人物名和多种值。图
6
突显Flight与三个一定的Plane相关联,而且Flight类知道那个涉及。因为角色名以Plane类表示,所以Plane承担关联中的“assignedPlane”剧中人物。紧接于Plane类后边的多种值描述0…1意味,当贰个Flight实体存在时,能够有一个或从不Plane与之提到(也即是,Plane恐怕还尚未被分配)。图
6
也显得Plane知道它与Flight类的关联。在那一个涉及中,Flight承担“assignedFlights”角色;图
6
的图告诉我们,Plane实体能够不与flight关联(举例,它是一架斩新的飞机)或与从不上限的flight(举个例子,一架已经当兵5年的飞机)关联。

在面向对象的宏图中二个不行主要的定义,继承,指的是三个类(子类)继承其它的贰个类(超类)的一致功效,并追加它本身的新作用(贰个非技巧性的举例,想象自个儿继续了自家母亲的一般的音乐力量,但是在自己的家里,小编是唯一贰个玩电吉他的人)的力量。为了在一个类图上建立模型承接,从子类(要承继行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。思索银行账户的品种:图
4 呈现 CheckingAccount 和 SavingsAccount 类如何从 BankAccount
类承继而来。

图3展现,delayFlight 操作有二个Minutes类型的输入参数 —
numberOfMinutes。可是,delayFlight
操作未有重返值。1当多个操作有参数时,参数被放在操作的括号内;各个参数都使用那样的格式:“参数名:参数类型”。

关于“UML 基础”的本类别的前面包车型大巴构件图。

Instance Name : Class Name

5到15个

图片 33

因为显示实例的指标是展示实价值得注意的或有关的消息,没要求在你的模型中富含全部实体性质及操作。相反地,仅仅展现感兴趣的品质及其值是一心适用的。如图16所描述。

更加多的涉嫌
在上面,笔者谈谈了双向关联和单向关系。未来,作者将会介绍剩下的三体系型的涉嫌。

实例
当三个系统结塑造立模型时,呈现例子类实例偶尔候是有效的。为了这种组织建立模型,UML
2 提供 实例规范
成分,它显得在系统中运用例子(或具体)实例的值得注意的音讯。

图片 34

类操作记录在类图圆柱形的第三个(最低的)区域中,它也是可选拔的。和总体性同样,类的操作以列表格式彰显,每一个操作在它和睦线上。操作使用下列记号表现:

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

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

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

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


软件包
不可防止,如若您正在为一个大的系统或大的事体领域建立模型,在您的模型上将会有成都百货上千差别的分类器。管理全体的类将是一件令人生畏的职务;所以,UML
提供三个称作
软件包的公司成分。软件包使建立模型者能够组织模型分类器到名字空间中,那有个别象文件系统中的文件夹。把贰个系统一分配为多个软件包使系统成为轻易领悟,越发是在各样软件包都表现系统的三个一定部分时。3

二个一方面包车型客车关系,表示为一条带有指向已知类的开放箭头(不安歇的箭头或三角形,用于标记承袭)的实线。仿佛典型提到,单向关系包罗贰个剧中人物名和二个多种值描述,然而与正统的双向关联不一样的时,单向关系只含有已知类的剧中人物名和多种值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,而且知道
BankAccount
类扮演“overdrawnAccounts”的剧中人物。但是,和正规提到不一样,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。2

图片 35

结缘聚合
结缘聚合关系是聚众关系的另一种样式,不过子类实例的生命周期正视于父类实例的生命周期。在图第13中学,展现了Company类和Department类之间的组合关系,注意组合关系如聚合关系同样绘制,但是本次菱形是被填充的。

图片 36

可见性
在面向对象的安插中,存在属性及操作可见性的号子。UML
识别各连串型的可知性:public,protected,private及package。

 

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

类操作列表

让大家更进一步追究基本聚合和构成聚合。

图片 37

图片 38

让大家看二个实例。在图 1第88中学大家有一个类图以彰显三个Plane类如何由多少个引擎和五个调整软件对象组成。从那几个图中省略的事物是彰显关于飞机部件如何棉被服装配的有的音信。从图
18
的图,你不可能表明,是种种调节软件对象说了算多少个引擎,依旧三个调控软件对象说了算八个引擎,而另贰个说了算三个汽油发动机。

只顾,你不能够在纯粹类图中做类剧中人物的建立模型,就算图
18显得你能够如此做。为了利用剧中人物记号,你将会需求运用上边研讨的内部结构记号。

图片 39

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

回页首

既是大家早已覆盖了基础和高档核心,大家将掩盖一些由UML 1.
x充实的类图的新标识。

三个类和一个接口不一样:贰个类能够有它造型的实在实例,然则一个接口必须至少有四个类来兑现它。在
UML 第22中学,八个接口被认为是类建立模型成分的特殊化。因而,接口就象类那样绘制,不过纺锤形的最上部区域也会有文件“interface”,如图
10
所示。5

图片 40

可是,超类(父类)不自然要是抽象类。标准类作为超类是例行的。

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

图 15:三个 BankAccount 类表明它的属性及操作的可知性

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

如先前所提到的,类图的指标是呈现建立模型系统的类型。在超过四分之二的 UML
模型中这么些项目包括:

表示

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

到此甘休,笔者已经介绍了类图的基础,不过请继续往下读!在下边包车型地铁有的中,作者将会引导您到您会动用的类图的更重视的方面。那几个包蕴UML
2 规范中的接口,另外的三种关系类型,可知性和其余补给。

3
软件包对于集体你的模型类是特大的,可是切记主要的一点是,你的类图应该是关于建立模型系统的轻便调换的音讯。在您的软件包有无数类的情景下,最棒使用多少个大旨类图,而不是不过爆发三个大的类图。

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

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