顶部区域展现类的名字,在底层区域中大家得以看来Flight类有四个操作

0..1

刺探基础主要性

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

含义

皇冠现金app 1

图 5: 一个应用树形记号的继承实例

软件包 
不可防止,如若您正在为一个大的系统或大的业务领域建模,在你的模子大校会有过多不比的分类器。管理所有的类将是一件令人生畏的职务;所以,UML
提供一个称作 软件包的集体元素。软件包使建模者可以协会模型分类器到名字空间中,那有些象文件系统中的文件夹。把一个系统分为多少个软件包使系统成为简单通晓,尤其是在各样软件包都表现系统的一个一定部分时。 3

皇冠现金app 2


皇冠现金app 3

皇冠现金app 4

*

皇冠现金app 5

在图中留存二种办法表示软件包。并不曾规则要求采纳哪个种类标志,除了用你个人的判断:哪类更便宜阅读你画的类图。三种方法都是由一个较小的长方形(用于固定)嵌套在一个大的长方形中初叶的,如图
8 所示。可是建模者必须控制包的分子怎么样表示,如下:

皇冠现金app 6

绘制类的内在结构将会立异那种景色。开首时,你通过用二个区域画一个方格。最下边的区域蕴含类名字,而较低的区域包涵类的内部结构,展现在它们父类中承受差异角色的局地类,角色中的每个部分类也波及到其余类。图
19 浮现了Plane类的内部结构;注意内部结构怎么样澄清混乱性。

5到15个

图 14
描绘的关联说爱他美个Employee实例可能是此外一个Employee实例的老板。然则,因为“manages”的涉嫌角色有
0..*的多重性描述;一个雇员可能不受任何其余雇员管理。

抽象类及操作 
仔细的读者会注意到,在图 4 和 图5
中的图中,类名BankAccount和withdrawal操作使用斜体。那意味着,BankAccount
类是一个抽象类,而withdrawal方法是空虚的操作。换句话说,BankAccount
类使用withdrawal规定抽象操作,并且CheckingAccount 和 SavingsAccount
八个子类都各自地推行它们分别版本的操作。

皇冠现金app 7

表示

皇冠现金app 8

皇冠现金app 9

举例来说,大家可以设想, 是一个完好实体,而 车轮
轮胎是整辆车的一局地。轮胎可以在安放到车时的前多少个礼拜被创设,并放置于仓库中。在那么些实例中,Wheel类实例清楚地单独地Car类实例而存在。可是,有些境况下,
部分 类的生命周期并 独立于 整体 类的生命周期 —
那称之为合成聚合。举例来说,考虑集团与部门的涉嫌。 商厦和机构
都建模成类,在公司存在以前,部门不可能存在。那里Department类的实例依赖于Company类的实例而留存。

在图中设有三种格局表示软件包。并没有规则须求运用哪类标志,除了用你个人的论断:哪一种更利于阅读你画的类图。二种方法都是由一个较小的长方形(用于固定)嵌套在一个大的长方形中初露的,如图
8 所示。不过建模者必须控制包的分子怎么着表示,如下:

接口
在本文的后边,我提议你以类来考虑分类器。事实上,分类器是一个尤为相似的定义,它包涵数据类型和接口。

回页首

足足存在八个精晓类图的第一理由。首个是它显得系统分类器的静态结构;第一个理由是图为UML描述的其它协会图提供了基本记号。开发者将会觉得类图是为他们专门建立的;可是任何的团体成员将发现它们也是实用的。业务分析师可以用类图,为系统的业务远景建模。正如我们将会在本连串有关
UML 基础的文章中看到的,其他的图 —
包含活动图,序列图和状态图——参考类图中的类建模和文档化。

聚合 
聚集是一种更加类型的关联,用于描述“总体到有的”的关系。在宗旨的集纳关系中, 部分类 的生命周期独立于 整体类 的生命周期。

图3突显,delayFlight 操作有一个Minutes类型的输入参数 —
numberOfMinutes。然则,delayFlight
操作没有再次回到值。1当一个操作有参数时,参数被放在操作的括号内;每个参数都应用那样的格式:“参数名:参数类型”。

更加多的关联 
在地点,我谈谈了双向关联和单向关系。现在,我将会介绍剩下的二种档次的关系。

Donald : Person

类名

1个或自己个

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

在图 4 中,继承关系由各样超类的独门的线画出,那是在IBM Rational
罗丝和IBM Rational XDE中应用的不二法门。可是,有一种叫做
树标记的预备方式可以画出继承关系。当存在五个或愈来愈多子类时,如图 4
中所示,除了连续线象树枝一样混在一起外,你可以利用树形记号。图 5
是重绘的与图 4 一样的持续,可是本次使用了树形记号。

关于哪一天、以及怎么着连忙地在系统结构图中运用数据类型和接口的完全研究,不在本文的座谈范围之内。既然那样,我为何要在这边提及数据类型和接口呢?你恐怕想在结构图上模拟这个分类器类型,在那一个时候,使用正确的标记来表示,或者至少知道那一个分类器类型是生死攸关的。不科学地绘制这一个分类器,很有可能将使您的布局图读者感到混乱,未来的系统将不可能适应要求。

举例来说来说:

含义

name : attribute type
flightNumber : Integer

图 5: 一个使用树形记号的延续实例

  • 比方建模者决定在大长方形中彰显软件包的分子,则有着的那个成员4内需被停放在长方形里面。其余,所有软件包的名字要求放在软件包的较小长方形之内(如图
    8 的来得)。

  • 如若建模者决定在大的长方形之外突显软件包成员,则拥有将会在图上显示的成员都须要被停放长方形之外。为了显得属于软件包的分类器属于,从各种分类器画一条线到里头有加号的圆圆,这个圆周粘附在软件包之上(图9)。

    name(parameter list) : type of value returned

皇冠现金app 10

在类图上突显所有默许值的一定属性,有时是实惠的(例如,在银行账户应用程序中,一个新的银行账户会以零为初步值)。UML
规范允许在属性列表节中,通过运用如下的标志作为默许值的标识:

类属性列表

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

关联类
在论及建模中,存在部分状态下,你必要包含其它类,因为它包蕴了有关关联的有价值的信息。对于那种情状,你会采用
关联类
来绑定你的中央关系。关联类和一般类一样表示。不一样的是,主类和关联类之间用一条相交的点线连接。图
11 突显一个航空工业实例的关联类。

类操作记录在类图长方形的第多少个(最低的)区域中,它也是可挑选的。和性质一样,类的操作以列表格式展现,每个操作在它自己线上。操作使用下列记号表现:

皇冠现金app 11

当文档化操作参数时,你恐怕选择一个可挑选的指示器,以展现参数到操作的输入参数、或输出参数。那些可接纳的提醒器以“in”或“out”出现,如图3中的操作区域所示。一般的话,除非将选择一种早期的先后编程语言,如Fortran
,这几个提示器可能会怀有协理,否则它们是不须要的。可是,在
C++和Java中,所有的参数是“in”参数,而且根据UML规范,既然“in”是参数的默许类型,半数以上人将会遗漏输入/输出提示器。

1

0个或1个

  name(parameter list) : type of value returned

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

实例的记号和类一样,不过代表顶端区域中仅有的类名,它的名字是经过拼接的:

接口 
在本文的前头,我提出你以类来设想分类器。事实上,分类器是一个更为相似的概念,它概括数据类型和接口。

UML
为那么些连串起了一个特其余名字:“分类器”。常常地,你可以把分类器当做类,但在技术上,分类器是尤为宽广的术语,它依旧引用上边的其他三种类型为好。

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

在 UML 2
中,明白类图的根基更为首要。那是因为类图为具备的其余社团图提供基本的营造块。如组件或对象图(仅仅是举了些例子)。

只是,超类(父类)不肯定若是抽象类。标准类作为超类是健康的。

1
delayFlight没有再次回到值,因为自身作出了规划决定,不要再次回到值。有几许足以争辩的是,延迟操作应该回到新的到达时间,而且,如若是这种景况,操作属性将显得为
delayFlight(numberOfMinutes : Minutes) : Date。

balance : Dollars = 0

5 当画一个类图时,在 UML
规范中,全体要做的只是把类放入长方形的顶部区域,而你同理处理接口;不过,UML
规范认为,在那一个区域放置“class”文本是可选的,借使类没有显得,那么它应有被倘若。

类的 UML 表示是一个长方形,垂直地分为多少个区,如图 1
所示。顶部区域突显类的名字。中间的区域列出类的性质。底部的区域列出类的操作。当在一个类图上画一个类元素时,你无法不要有上边的区域,上边的二个区域是可接纳的(当图描述仅仅用于显示分类器间事关的高层细节时,上边的七个区域是不需要的)。图
1 显得一个航线班机怎样作为 UML
类建模。正如我辈所能见到的,名字是 Flight,大家得以在中游区域来看Flight类的3个特性:flightNumber,departure提姆e

flightDuration。在底层区域中大家能够看看Flight类有三个操作:delayFlight
和 getArrival提姆e。

UML
规范并不要求品质及操作可知性必须出示在类图上,可是它须求为各种属性及操作定义可知性。为了在类图上的展现可知性,放置可知性标志于属性或操作的名字从前。就算UML 指定多种可知性类型,然而事实上的编程语言可能增加额外的可知性,或不帮忙UML 定义的可知性。表4展现了 UML 协助的可知性类型的例外标志。

继承

0个或多个

皇冠现金app 12

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

如先前所涉及的,类图的目的是浮现建模系统的品类。在大部的 UML
模型中这个种类蕴涵:

可见性
在面向对象的设计中,存在属性及操作可见性的标志。UML
识别三种档次的可知性:public,protected,private及package。

关联类 
在关系建模中,存在一些情况下,你须要包蕴其余类,因为它包括了关于关联的有价值的新闻。对于那种景观,你会采取 关联类 来绑定你的中央关系。关联类和一般类一样表示。分裂的是,主类和关联类之间用一条相交的点线连接。图
11 突显一个航空工业实例的关联类。

既是大家曾经覆盖了根基和高档要旨,大家将掩盖一些由UML 1.
x增加的类图的新标志。

UML
为这一个项目起了一个特地的名字:“分类器”。寻常地,你可以把分类器当做类,但在技术上,分类器是越来越宽泛的术语,它仍旧引用上面的其他三体系型为好。

结合聚合
结缘聚合关系是会聚关系的另一种形式,可是子类实例的生命周期重视于父类实例的生命周期。在图13中,彰显了Company类和Department类之间的咬合关系,注意组合关系如聚合关系一样绘制,可是本次菱形是被填充的。

举例来说来说,我们得以设想, 是一个全部实体,而 车轮 轮胎是整辆车的一有的。轮胎能够在计划到车时的前多少个星期被营造,并放置于仓库中。在那几个实例中,Wheel类实例清楚地独自地Car类实例而留存。不过,有些情况下, 部分 类的生命周期并  独立于 整体 类的生命周期

那称之为合成聚合。举例来说,考虑公司与机关的涉及。 公司和机构 都建模成类,在店铺存在此前,部门不可以存在。那里Department类的实例爱抚于Company类的实例而存在。

让大家更进一步探究基本聚合和烧结聚合。

焦点聚合 
有汇集关系的涉嫌提出,某个类是此外某个类的一片段。在一个汇集关系中,子类实例能够比父类存在更长的年月。为了突显一个聚集关系,你画一条从父类到一些类的实线,并在父类的涉及末端画一个未填充棱形。图
12 展现车和轮胎间的集合关系的事例。

皇冠现金app 13

图 12: 一个相会关联的例子

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

皇冠现金app 14

图 13: 一个重组关系的例子

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

反射关联 
近年来我们早就研究了具有的涉嫌类型。似乎你也许注意到的,大家的保有例子已经显得了多个分歧类之间的关系。不过,类也足以动用反射关联与它自己相关联。先导,那可能没有意义,可是切记,类是空洞的。图
14 突显一个Employee类怎样通过manager /
manages角色与它自己有关。当一个类关联到它自己时,那并不意味着类的实例与它自身有关,而是类的一个实例与类的另一个实例相关。

皇冠现金app 15

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

图 14
描绘的涉嫌说多美滋个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。

皇冠现金app 16

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


回页首

UML
2 补充

既然大家早就覆盖了根基和高级宗旨,我们将掩盖一些由UML 1.
x日增的类图的新标志。

实例 
当一个系统结打造模时,展现例子类实例有时候是实用的。为了那种社团建模,UML
2
提供 实例规范 元素,它显得在系统中行使例子(或具体)实例的值得注意的音讯。

实例的记号和类一样,但是代表顶端区域中仅局地类名,它的名字是通过拼接的:

Instance Name : Class Name

举例来说:

Donald : Person

因为显示实例的目的是突显值得注意的或相关的信息,没必要在您的模子中蕴藏全部实体性质及操作。相反地,仅仅彰显感兴趣的性质及其值是全然适用的。如图16所讲述。

皇冠现金app 17

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

而是,仅仅突显一些实例而从未它们的涉及不太实用;因而,UML 2
也同目的在于实体层的关联/关联建模。绘制关联与一般的类关系的平整一样,除了在建模关联时有一个增大的需求。附加的限量是,关联关系必须与类图的关联相平等,而且关乎的角色名字也不能不与类图相平等。它的一个事例彰显于图
17 中。在这一个例子中,实例是图 6 中类图的例证实例。

皇冠现金app 18

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

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

角色 
建模类的实例有时比期望的愈益详细。有时,你恐怕一味想要在一个较多的相似层次做类关系的模子。在那种场馆下,你应当利用 角色 记号。角色记号类似于实例记号。为了树立类的角色模型,你画一个方格,并在其间放置类的角色名及类名,作为实体记号,可是在这一场馆你不可能加下划线。图
18 显示一个由图 14 中图描述的雇员类扮演的角色实例。在图 18
中,我们得以认为,尽管雇员类与它自身有关,关系真正是关于雇员之间扮演首席执行官及团体成员的角色。

皇冠现金app 19

图 18:一个类图显示图14中饰演不一样角色的类

在意,你不可以在纯粹类图中做类角色的建模,即使图
18体现你可以如此做。为了利用角色记号,你将会须要利用上边探讨的内部结构记号。

其中的构造 
UML 2
结构图的更有效的效率之一是新的内部结构记号。它同意你出示一个类或别的的一个分类器怎么样在中间整合。那在
UML 1. x
中是不能的,因为记号限制你只能够显示一个类所兼有的聚合关系。现在,在 UML
2 中,内部的结构记号让你更明了地出示类的一一部分怎么着有限支撑关系。

让我们看一个实例。在图 18
中我们有一个类图以显示一个Plane类怎么着由七个引擎和五个控制软件对象组成。从这么些图中省略的事物是呈现关于飞机部件怎样被装配的部分新闻。从图
18
的图,你无法表明,是每个控制软件对象说了算多少个引擎,依然一个控制软件对象说了算几个引擎,而另一个操纵一个引擎。

皇冠现金app 20

图 19: 只突显对象时期涉及的类图

绘制类的内在结构将会立异那种景色。起首时,你通过用二个区域画一个方格。最下边的区域包蕴类名字,而较低的区域包蕴类的内部结构,显示在它们父类中担负差异角色的有的类,角色中的每个部分类也波及到任何类。图
19 浮现了Plane类的内部结构;注意内部结构怎样澄清混乱性。

皇冠现金app 21

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

在图 20 中Plane有五个ControlSoftware 对象,而且每个控制二个引擎。在图左侧上的
ControlSoftware(control1)控制引擎 1 和 2 。在图左边的
ControlSoftware(control2)控制引擎 3 和 4 。 

皇冠现金app 22

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

皇冠现金app 23

5..15

瞩目,你不可以在纯粹类图中做类角色的建模,即便图
18展现你可以那样做。为了选用角色记号,你将会要求动用下边琢磨的内部结构记号。

皇冠现金app 24


皇冠现金app 25

图 18:一个类图突显图14中饰演不一样角色的类

*

表 2:从图 2 炫耀的Flight类的操作

在事情类图中,属性类型一般与单位符合,这对于图的恐怕读者是有含义的(例如,分钟,美金,等等)。但是,用于转移代码的类图,需要类的品质类型必须界定在由程序语言提供的门类之中,或含有于在系统中落到实处的、模型的项目之中。

比喻来说:

关联 
当您系统建模时,特定的目的间将会互相关系,而且那一个涉嫌本身需求被清楚地建模。有多种关系。在这一有的中,我将会探究它们中的三个– 双向的关联和单向的关系,而且自己将会在Beyond the
basics
部分研商剩下的二种关系类型。请留心,关于哪天该采纳每系列型涉及的详尽座谈,不属于本文的限制。相反的,我将会把重大集中在每种关系的用处,并表达怎么样在类图上画出涉及。

在图 13
中的关系建模中,一个Company类实例至少总有一个Department类实例。因为关乎是结合关系,当Company实例被移除/销毁时,Department实例也将活动地被移除/销毁。组合聚合的另一个最首要意义是部分类只好与父类的实例相关(举例来说,我们例子中的Company类)。

皇冠现金app 26

皇冠现金app 27

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

UML 2 补充

皇冠现金app 28

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

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

3
软件包对于集团你的模子类是特大的,不过切记紧要的一些是,你的类图应该是有关建模系统的不难沟通的音信。在你的软件包有不少类的情形下,最好使用三个主旨类图,而不是一味暴发一个大的类图。

在图 4 中,继承关系由各样超类的独门的线画出,那是在IBM Rational
罗斯和IBM Rational
XDE中行使的方法。不过,有一种叫做 树标记的备选方式可以画出继承关系。当存在四个或越来越多子类时,如图
4 中所示,除了继续线象树枝一样混在一起外,你可以行使树形记号。图 5
是重绘的与图 4 一样的接轨,不过这一次运用了树形记号。

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

图 1: Flight类的类图

在面向对象的筹划中一个万分首要的定义,继承,指的是一个类(子类)继承除此以外的一个类(超类)的一模一样作用,并追加它自己的新效用(一个非技术性的比方,想象自己三番五次了我丈母娘的一般的音乐力量,可是在自己的家里,我是唯一一个玩电吉他的人)的力量。为了在一个类图上建模继承,从子类(要持续行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。考虑银行账户的连串:图
4 显示 CheckingAccount 和 SavingsAccount 类怎么着从 BankAccount
类继承而来。

在 UML 2
中,了解类图的功底更为主要。那是因为类图为具有的任何社团图提供基本的打造块。如组件或对象图(仅仅是举了些例子)。


图 11:伸张关联类 MileageCredit

 

在面向对象的规划中一个可怜主要的概念,继承,指的是一个类(子类)继承其它的一个类(超类)的同样功能,并追加它自己的新成效(一个非技术性的比方,想象自己连续了自我姨妈的相似的音乐力量,可是在我的家里,我是绝无仅有一个玩电吉他的人)的能力。为了在一个类图上建模继承,从子类(要继承行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。考虑银行账户的类型:图
4 显示 CheckingAccount 和 SavingsAccount 类怎样从 BankAccount
类继承而来。

皇冠现金app 29

显示属性默许值是可挑选的;图 2
显示一个银行账户类具有一个名为 balance的品类,它的默许值为0。

4
要明了紧要一点,当自身说“所有的那个成员”时,我只是意味着在现阶段图中的类将显示出来。突显一个有内容的软件包的图,不须要出示它的保有内容。它可以遵从一些章法,显示包涵元素的子集,这么些规则就是永不所有的软件包分类器都是不可或缺的。

  • 只要建模者决定在大长方形中显示软件包的积极分子,则拥有的那些成员皇冠现金app, 4 亟需被放置在长方形里面。其它,所有软件包的名字需求放在软件包的较小长方形之内(如图
    8 的来得)。

  • 如果建模者决定在大的长方形之外突显软件包成员,则怀有将会在图上显示的积极分子都必要被内置长方形之外。为了突显属于软件包的分类器属于,从每个分类器画一条线到内部有加号的圆圆,那些圆周粘附在软件包之上(图9)。

回页首

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

角色
建模类的实例有时比期望的更是详细。有时,你恐怕可是想要在一个较多的相似层次做类关系的模型。在那种意况下,你应该利用
角色
记号。角色记号类似于实例记号。为了建立类的角色模型,你画一个方格,并在里边放置类的角色名及类名,作为实体记号,不过在那情形你无法加下划线。图
18 显示一个由图 14 中图描述的雇员类扮演的角色实例。在图 18
中,大家能够认为,即便雇员类与它自己有关,关系真正是关于雇员之间扮演老总及协会成员的角色。

0个或两个

软件包
不可避免,若是您正在为一个大的种类或大的事情领域建模,在你的模型中将会有不少见仁见智的分类器。管理所有的类将是一件让人生畏的职分;所以,UML
提供一个称作
软件包的团伙元素。软件包使建模者可以协会模型分类器到名字空间中,那有些象文件系统中的文件夹。把一个种类分为四个软件包使系统成为简单驾驭,尤其是在每个软件包都表现系统的一个特定部分时。3

0到5个

5..15

基础

继承

1

3

只能3个

当文档化操作参数时,你或许应用一个可挑选的提示器,以呈现参数到操作的输入参数、或输出参数。那么些可挑选的提醒器以“in”或“out”出现,如图3中的操作区域所示。一般的话,除非将使用一种早期的次序编程语言,如Fortran
,这一个提示器可能会有着援救,否则它们是不必要的。可是,在
C++和Java中,所有的参数是“in”参数,而且依据UML规范,既然“in”是参数的默许类型,大多数人将会遗漏输入/输出提示器。

0..5

皇冠现金app 30

一个单向的涉嫌,表示为一条带有指向已知类的开放箭头(不停歇的箭头或三角形,用于标志继承)的实线。就如标准提到,单向关系包涵一个角色名和一个多重值描述,然则与正统的双向关联区其余时,单向关系只包罗已知类的角色名和多重值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,而且知道
BankAccount
类扮演“overdrawnAccounts”的角色。但是,和业内提到差距,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。 2

里头的构造
UML 2
结构图的更使得的功用之一是新的内部结构记号。它同意你出示一个类或其余的一个分类器怎么着在里边整合。那在
UML 1. x
中是不容许的,因为记号限制你不得不呈现一个类所持有的汇集关系。现在,在 UML
2 中,内部的布局记号让您更领悟地出示类的依次部分如何保持关系。

举例来说来说:

单向关系
在一个单向关系中,八个类是有关的,但是唯有一个类知道那种关联的留存。图 7
突显单向关系的透支财务报告的一个实例。

持续大家的Flight类的事例,我们得以动用品质类型音信来描述类的属性,如表 1
所示。


打探基础紧要性

1..*

当先基础

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

name : attribute type
flightNumber : Integer

现今,让大家看一个类,以证实属性及操作的可知性类型。在图 15
中,所有的属性及操作都是public,除了 updateBalance 操作。updateBalance
操作是protected。

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

balance : Dollars = 0

恐怕的多重值描述

不过,仅仅突显一些实例而没有它们的关系不太实用;由此,UML 2
也同意在实体层的涉嫌/关联建模。绘制关联与一般的类关系的平整平等,除了在建模关联时有一个附加的渴求。附加的界定是,关联关系必须与类图的涉嫌相平等,而且关系的角色名字也务必与类图相平等。它的一个例证突显于图
17 中。在那么些例子中,实例是图 6 中类图的例子实例。

0..*

皇冠现金app 31

表 2:从图 2 炫耀的Flight类的操作

可是,超类(父类)不自然假设抽象类。标准类作为超类是正常的。

一个双向关联用三个类间的实线表示。在线的任一端,你放置一个角色名和多重值。图
6
突显Flight与一个特定的Plane相关联,而且Flight类知道那些关系。因为角色名以Plane类表示,所以Plane承担关联中的“assignedPlane”角色。紧接于Plane类后边的多重值描述0…1象征,当一个Flight实体存在时,可以有一个或没有Plane与之提到(也就是,Plane可能还一直不被分配)。图
6
也显示Plane知道它与Flight类的涉及。在这些关系中,Flight承担“assignedFlights”角色;图
6
的图告诉大家,Plane实体可以不与flight关联(例如,它是一架全新的飞行器)或与没有上限的flight(例如,一架已经当兵5年的飞行器)关联。

图 13: 一个整合关系的例证

1..*

聚合
聚集是一种越发类型的涉及,用于描述“总体到有些”的关联。在着力的汇集关系中,
部分类 的生命周期独立于 整体类 的生命周期。

图 8:在软件包的长方形内展现软件包成员的软件包元素例子

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

表 3: 多重值和它们的意味

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

上面的表 2 中Flight类操作的投射。

0..5

1个或自己个

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

一个类和一个接口差异:一个类能够有它造型的真正实例,但是一个接口必须至少有一个类来已毕它。在
UML 2
中,一个接口被认为是类建模元素的特殊化。由此,接口就象类那样绘制,可是长方形的顶部区域也有文件“interface”,如图
10
所示。 5

皇冠现金app 32

0个或八个

如先前所提到的,类图的目标是突显建模系统的花色。在一大半的 UML
模型中那么些体系包涵:

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

上面的表 2 中Flight类操作的照射。

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


类操作列表

双向(标准)的关联
涉及是三个类间的连片。关联总是被假定是双向的;那象征,四个类彼此精通它们间的维系,除非您限定一些其余门类的关系。回顾一下Flight
的事例,图 6 突显了在Flight类和Plane类之间的一个正规项目的涉及。

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

皇冠现金app 33

3

脚注

name : attribute type = default value

皇冠现金app 34

皇冠现金app 35

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

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

 

  • 接口

  • 数据类型

  • 组件

5到15个

只能1个

一个一方面的关联,表示为一条带有指向已知类的怒放箭头(不关门的箭头或三角形,用于标志继承)的实线。如同标准提到,单向关系包含一个角色名和一个多重值描述,不过与业内的双向关联不一样的时,单向关系只包括已知类的角色名和多重值描述。在图
7 中的例子中,OverdrawnAccountsReport 知道 BankAccount 类,而且知道
BankAccount
类扮演“overdrawnAccounts”的角色。不过,和业内提到分歧,BankAccount
类并不知道它与 OverdrawnAccountsReport
相关联。2

到此停止,我一度介绍了类图的根底,不过请继续往下读!在下边的片段中,我将会指点您到您会利用的类图的更首要的方面。这几个概括UML
2 业内中的接口,其余的三种关系类型,可知性和任何补给。

图 2:展现默许为0日元的balance属性值的银行账户类图。

双向(标准)的关联 
关联是多个类间的连通。关联总是被假定是双向的;那意味着,多个类相互精通它们间的维系,除非你限定一些其余品类的涉及。回看一下Flight
的事例,图 6 突显了在Flight类和Plane类之间的一个正规项目标关系。

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

图3呈现,delayFlight 操作有一个Minutes类型的输入参数 —
numberOfMinutes。不过,delayFlight
操作没有再次来到值。 1 当一个操作有参数时,参数被放在操作的括号内;每个参数都利用那样的格式:“参数名:参数类型”。

一个双向关联用多少个类间的实线表示。在线的任一端,你放置一个角色名和多重值。图
6
显示Flight与一个特定的Plane相关联,而且Flight类知道这么些涉及。因为角色名以Plane类表示,所以Plane承担关联中的“assignedPlane”角色。紧接于Plane类前面的多重值描述0…1象征,当一个Flight实体存在时,可以有一个或尚未Plane与之提到(也就是,Plane可能还尚未被分配)。图
6
也显得Plane知道它与Flight类的关联。在那个涉及中,Flight承担“assignedFlights”角色;图
6
的图告诉我们,Plane实体可以不与flight关联(例如,它是一架全新的飞行器)或与从不上限的flight(例如,一架已经服役5年的飞行器)关联。

是因为对那多少个在事关底部可能出现的多重值描述感到迷惑不解,上面的表3列出了部分多重值及它们含义的例子。

骨干聚合
有会聚关系的涉嫌提出,某个类是其它某个类的一片段。在一个会合关系中,子类实例可以比父类存在更长的日子。为了突显一个汇集关系,你画一条从父类到有的类的实线,并在父类的涉嫌末端画一个未填充棱形。图
12 突显车和轮胎间的成团关系的事例。

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

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

类属性列表

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

基础

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

皇冠现金app 36

图 8:在软件包的长方形内显示软件包成员的软件包元素例子

回页首

到此停止,我曾经介绍了类图的底子,可是请继续往下读!在上边的有的中,我将会指点您到您会动用的类图的更体贴的上边。这些概括UML
2 正式中的接口,其余的三种关系类型,可知性和此外补给。

在图 20 中Plane有三个 ControlSoftware
对象,而且每个控制二个引擎。在图左侧上的
ControlSoftware(control1)控制引擎 1 和 2 。在图左侧的
ControlSoftware(control2)控制引擎 3 和 4 。

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

类的 UML 表示是一个长方形,垂直地分成多个区,如图 1
所示。顶部区域展现类的名字。中间的区域列出类的性质。尾部的区域列出类的操作。当在一个类图上画一个类元素时,你必须求有上面的区域,上边的二个区域是可选择的(当图描述仅仅用于体现分类器间关系的高层细节时,下边的多少个区域是不需求的)。图
1 显得一个航路班机如何作为 UML 类建模。正如我辈所能见到的,名字是
Flight,我们能够在中间区域看到Flight类的3个属性:flightNumber,departure提姆e

flightDuration。在尾部区域中大家可以看看Flight类有三个操作:delayFlight
和 getArrival提姆e。

图 1: Flight类的类图

类操作记录在类图长方形的第多少个(最低的)区域中,它也是可接纳的。和质量一样,类的操作以列表格式突显,每个操作在它自己线上。操作使用下列记号表现:

只能1个

图 11:增添关联类 MileageCredit

来得属性默许值是可选用的;图 2 彰显一个银行账户类具有一个名为
balance的门类,它的默许值为0。

让大家看一个实例。在图 18
中大家有一个类图以表现一个Plane类怎么着由三个引擎和八个控制软件对象组成。从那一个图中省略的事物是呈现关于飞机部件如何被装配的有些信息。从图
18
的图,你不可以表明,是种种控制软件对象说了算四个引擎,照旧一个控制软件对象说了算多个引擎,而另一个操纵一个发动机。

0..1

只能3个

或许的多重值描述

皇冠现金app 37

因为体现实例的目标是显得值得注意的或相关的音信,没要求在您的模子中涵盖全部实体性质及操作。相反地,仅仅显示感兴趣的属性及其值是一心适用的。如图16所讲述。

name : attribute type = default value

2恐怕看起来很奇怪, BankAccount 类不知底
OverdrawnAccountsReport
类。那些建模使报表类可以驾驭它们报告的业务类,不过工作类不通晓它们正在被告知。那解开五个目的的耦合,并据此使系统变得更能适应变化。

一个类和一个接口分化:一个类可以有它造型的诚实实例,然则一个接口必须至少有一个类来兑现它。在
UML 2
中,一个接口被认为是类建模元素的特殊化。因而,接口就象类那样绘制,可是长方形的顶部区域也有文件“interface”,如图
10
所示。5

结论

反射关联
现今咱们早就商讨了具备的涉嫌类型。就像你也许注意到的,大家的有着例子已经展现了八个分化类之间的关系。可是,类也得以选择反射关联与它本身相关联。开始,那也许没有意义,不过切记,类是虚幻的。图
14 突显一个Employee类如何通过manager /
manages角色与它本身有关。当一个类关联到它自己时,那并不意味着类的实例与它自身有关,而是类的一个实例与类的另一个实例相关。

皇冠现金app 38

Instance Name : Class Name

0到5个

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

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

关于曾几何时、以及怎样疾速地在系统结构图中选用数据类型和接口的完全探究,不在本文的议论范围以内。既然那样,我为何要在这里提及数据类型和接口呢?你也许想在结构图上效仿那些分类器类型,在那个时候,使用正确的标志来表示,或者至少知道那些分类器类型是生死攸关的。不科学地绘制那一个分类器,很有可能将使您的布局图读者感觉混乱,将来的系统将不可能适应须要。

回页首

出于对这一个在事关底部可能出现的多重值描述感到怀疑,上面的表3列出了部分多重值及它们含义的例子。

表示

超过基础

在工作类图中,属性类型一般与单位符合,那对于图的恐怕读者是有意义的(例如,分钟,美金,等等)。不过,用于转移代码的类图,要求类的特性类型必须界定在由程序语言提供的花色之中,或带有于在系统中落到实处的、模型的种类之中。

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

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

0..*

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

在类图上突显所有默许值的一定属性,有时是实惠的(例如,在银行账户应用程序中,一个新的银行账户会以零为开端值)。UML
规范允许在属性列表节中,通过运用如下的标记作为默许值的标识:

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

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

关联
当您系统建模时,特定的目的间将会相互关系,而且那几个关乎本身必要被清晰地建模。有三种关系。在这一局地中,我将会谈论它们中的多少个– 双向的关联和单向的关系,而且我将会在Beyond the
basics
一些探究剩下的二种关系类型。请小心,关于曾几何时该行使每体系型涉及的详实谈论,不属于本文的界定。相反的,我将会把重点集中在每种关系的用途,并表明如何在类图上画出涉及。

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

类操作列表

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

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

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

一而再我们的Flight类的例证,大家得以运用性质类型音讯来叙述类的性质,如表 1
所示。

越多的关系
在地点,我谈谈了双向关联和单向关系。现在,我将会介绍剩下的三种档次的涉嫌。

0个或七个

0个或1个

在图 11 中显示的类图中,在Flight类和 FrequentFlyer
类之间的关联,爆发了名叫
MileageCredit的关系类。那意味着当Flight类的一个实例关联到 FrequentFlyer
类的一个实例时,将会爆发 MileageCredit 类的一个实例。

实例
当一个系统结创设模时,展现例子类实例有时候是实用的。为了那种结营造模,UML
2 提供 实例规范
元素,它突显在系统中行使例子(或具体)实例的值得注意的音信。

  • 接口

  • 数据类型

  • 组件

回页首

图 12: 一个成团关联的例证

皇冠现金app 39

类名

皇冠现金app 40

相关文章