UML那些事儿：六类UML图

UML那些事儿：六类UML图来源：天极网作者：邱郁惠2.1类图2.2对象图2.3包图2.4活动图2.5序列图2.6用例图本章介绍六类UML图的主要用途，以及常见的概念及图示，以便对这六类图有一个初步的认识。2.1类图如果投票选最重要的UML图，我一定会把票投给类图(classdiagram)。类图是一款结构图(structurediagram)，如图2-1所示，我们可以用它来表达系统内部重要的组成结构。一个稳定且具弹性的内部结构可以同时支撑系统对外提供的各式服务，以及系统内部复杂的运作，所以我认为类图特别重要。接下来的各小节会谈到类图中最常见的概念及图示。2.1.1类一群对象(object)享有相同的结构、行为、约束和语义时，称它们是同类(class)的对象。换句话说，定义一个类就相当于描述了一群对象。在类中，使用属性(attribute)表达对象的结构，使用操作(operation)表达对象的行为。如图2-2所示，定义员工(worker)类之后，便可以依据此类的描述产生一群对象。这些:Worker对象不仅可以共用类所定义的属性，拥有自己的属性值，还可以共用类所定义的操作，或者共用约束。图2-1类图图2-2类与对象类采用三格的矩形图示，顶格放置类名称，中格放置属性名称，底格放置操作名称。不过，也可以将类的属性格或操作格隐藏起来，节省空间，如图2-3所示。大多数的UML工具都有隐藏功能。以StarUML为例，点选任何一个类图示都可以选择是否隐藏属性或操作，如图2-4所示。图2-3类图示图2-4隐藏属性或操作2.1.2可见性对象具有封装(encapsulation)属性，可以把数据结构和行为细节封装起来，外界无法随意存取。对应UML的类概念，我们会看到类中有属性和操作，同时可以设定这些成员是否能被外界存取的可见性(visibility)。以图2-5为例，单笔申购(purchase)封装了一个外界无法存取的私有属性—金额(amount)，以及一个外界可以调用的公开操作—计算(calculate)。图2-5私有属性与公开操作目前，UML预设了四种可见性，分别为公开(public)、私有(private)、保护(protected)和包(package)。公开和私有可见性最常见，也最容易懂，如图2-5所示，减号(-)为私有可见性，加号(+)为公开可见性。私有可见性滴水不漏，就连子类也无法看见超类的私有成员，这样，其实不利于继承机制。所以，UML设置保护等级的可见性，特别开放子类可以看见超类的保护等级的属性及操作，以便提供更方便的继承机制。保护可见性的符号是井号(#)，如图2-6所示。图2-6保护等级的属性最后来谈包可见性。顾名思义，它是为了包而设置的，它的符号是否定号(~)，如图2-7所示。同包的类可以看见其他类内部的包属性及操作。所以，从图中可以得知，账户可以看见顾客类的姓名和地址，但是分行(branch)却无法看见，因为分行不是S包的成员。图2-7包等级的属性2.1.3关联关联(association)是对象之间最常见的关系，用来连接有结构关系的对象。请看图2-8的例子，关联的图示为实线，实线两端可以连接两个不同的类，如图中的个人(person)类和公司(company)类。不过，关联的两端也可以连接相同的类，如图2-8中的个人类。虽然，关联两端连接相同的类，但它的链接(link)其实是连接两个不同的实例(instance)，只不过这两个实例诞生自相同的类。图2-8关联关联不一定是二元关联(binaryassociation)，也可以是多元关联(n-aryassociation)。多元关联的图示是连接大菱形的实线，如图2-9所示为三元关联(ternaryassociation)。图2-9三元关联有时候会看到带箭头实线，那是在标示导航性(navigation)，意味着可以由来源端(sourceend)导航到箭头所在处的目标端(targetend)。如图2-10所示，:Member对象可以链接到:Password对象，但是反向则不成立，也就是说，无法从:Password对象链接到:Member对象，因为两者之间是单向的关联。图2-10导航性特别注意，关联端的标记在UML2中有所变动，与UML1版略有不同，如图2-11所示。在UML2中，关联的箭头端代表具有导航性。打个小叉就是不可导航;单纯直线代表还未指定可导航或不可导航。所以，回到图2-11的例子中，可以看到•AB是双向关联。•CD两端都不具有导航性。•EF尚未指定两端是否具导航性。•GH为单向关联，可由G导航到H。•I端还未决定可否导航，可以确定的是，可由I导航到J。图2-11关联图示2.1.4多重性多重性元素(multiplicityelement)主要包含一组上下限数，用来指出可被允许生成的实例(instance)数量，即最多可以生成多少数目(上限)，最少不得低于多少数目(下限)。关联的两端以“下限..上限”的格式标示出多重性，如图2-12中的1..*。星号(*)代表无指定上限，下限最低为0。如果上下限数相同，标示出一个数目就可以了。因此，可以解读为：一个顾客(customer)可以拥有一个到多个的账户(account)，但是一个账户只能由一个顾客所拥有。图2-12多重性2.1.5聚合与组合关联的两端是平等的，没有孰轻孰重的分别。若想表达整体-部分(whole-part)关系，可以改用聚合关系(aggregation)或组合关系(composition)。聚合与组合都具有整体-部分的特性，唯一的差别在于可否分享(share)。聚合关系中的部件(partobject)可以与其他整体(wholeobject)分享，但是组合关系中的部件则由整体独自拥有。先来看聚合关系，聚合端为空心小菱形，如图2-13所示。图2-13聚合关系因为船(boat)和引擎(engine)之间采用聚合关系，意味着船为整体，而引擎为它的部件。而且，倘若a船被删除了，或者a船不再需要这个引擎而删除之间的链接，b船可以接手使用这个引擎部件，如图2-14所示。图2-14部件可重用但是，如果图2-14改成组合关系，b船就无法重用引擎部件了。因为组合关系中的整体不会分享部件，所以一旦a船被删除，或者a船不再需要这个引擎时，a船都会负责将引擎销毁掉。请看图2-15的例子，组合端为实心小菱形，意味着视窗(window)被删除时，构成视窗的部件都会连带被删除，这是常见的组合关系。图2-15组合关系2.1.6泛化实际上，常用继承(inheritance)一词，但是UML没有使用继承这个词汇，不过UML提供了泛化(generalization)，来达到子类(subclass)继承超类(superclass)的目的。泛化将类分为较为泛化的类和较为特化的类，如图2-16所示。通过泛化，子类可以继承超类预先定义好的声明。泛化的图示为带有大三角形箭头的实线，由特化的子类连接指向泛化的超类。图2-16泛化2.1.7依赖某一模型元素需要另一个模型元素所提供的规格(specification)或实现(implementation)时，两者之间的关系称为依赖(dependency)。也就是说，少了供应者元素(supplierelement)的话，依赖元素(dependingelement)在语义上(semantically)或者结构上(structurally)可能会不完整(imcomplete)。因此，一旦供应者元素变动，很可能会影响到依赖元素。例如，结账时需要用到信用卡，所以结账(checkout)类依赖信用卡(creditcard)类，如图2-17所示。依赖的图示是带箭头虚线，由依赖元素指向供应者元素。图2-17依赖2.1.8接口接口(interface)如同契约，负责的类必须负责实现它的公开操作，以及负责维护它的公开属性。以图2-18为例，ProximitySensor类负责实现ISensor接口内部的active操作与read操作，而TheftAlarm类则可以使用ISensor接口。实际上，可能会先设计出接口与实现者，这种接口特别称为供给接口(providedinterface)，指由实现类所供给的接口，也可以改用接口独特的圆形图示，如图2-19所示。也可以先设计出使用者以及所需要的接口，这时称这类的接口为需求接口(requiredinterface)，其图示为半圆形，如图2-20所示，以便能够一眼区分出该接口为供给接口或需求接口。图2-18接口图2-19供给接口图2-20需求接口如果把实现者、使用者、需求接口和供给接口全都凑在一起，可以使用图2-21的简图，以节省图面空间。图2-21简图2.1.9注释注释(comment)可以附加在任何元素上，其内放置说明文字，就像3M的便利贴(Post-it)一样。注释可以用在任何图中，不局限于类图。注释的图示是右上角有折角的矩形，通过虚线连接被注释的元素，如图2-22所示。图2-22注释的图示2.2对象图对象图(objectdiagram)也是一种结构图，如图2-23所示，用来呈现系统在特定时刻的对象(object)，以及对象之间的链接(link)。图2-23对象图常说的实例(instance)也会使用对象(object)一词来替换，两者为同义词。系统运行期间，会依据类的定义创建对象，如图2-24所示。图2-24类与对象对象和类共用矩形图示，不过对象名称下方有底线，类名称下方没有底线，如图2-25所示。对象名称经常被省略，所以常见带有冒号的类名称，这其实是个缺名的对象。图2-25:Worker是缺名的对象两个对象之间的关系线称为链接(link)，如图2-26所示。图2-26链接2.3包图类图、对象图和包图(packagediagram)，如图2-27所示。包图主要用来为相关的元素分组。对于拥有大量繁杂元素的项目而言，适合用包图来维护管理元素。图2-27包图2.3.1包包(package)就像一般的纸箱，可以将相关、欲放置在一起的东西打包成箱。包的图示是上小下大的两个重叠矩形，可以将元素放置其内，如图2-28a所示。也可以将包的内容隐藏起来，形成如图2-28b所示，以节省图面空间。a)b)图2-28包2.3.2元素导入元素导入(elementimport)可以将包内的任一元素导入到另一个包中。如图2-29所示，元素导入采用带箭头的虚线表示，旁边标上关键字，意味着Program包导入了Time数据类型。图2-29元素导入2.3.3包导入如果一次导入整个包里的所有元素，可以使用包导入(packageimport)。如图2-30所示，OrderSystem与DomainDataType之间有包导入的关系，所以OrderSystem内的Employee和Order可以直接使用DomainDataType里的Address和Date。图2-30包导入2.3.4包合并顾名思义，包合并(packagemerge)可将一个包的内容全部合并到另一个包中。换言之，可以经由合并目标包(targetpackage)的内容来扩展来源包(sourcepackage)。这好比合并公司，原公司合并了另一家公司，所以原公司就成为一家拥有更多资产的公司了。如图2-31所示，包合并的图示为带箭头虚线，且于虚线旁标记，并由来源包指向目标包，意指将目标包的内容并入来源包。图2-31包合并图示再看图2-32和图2-33所示的例子，会更加清楚。图2-32中的S包合并了Q包之后，形成图2-33。下面一一解释新的S包的内容：图2-32包合并图2-33S包•A—原先的A，加上Q::A。假设原先的A有一个名为name的属性，而Q::A拥有一个名为address的属性，合并后的新A将同时拥有name和address两个属性。•B—没有变化。•C—原先在S包中并不存在C，合并了Q::C。特别是Q::C与Q::A的关联，也会一块并入。•D—没有变化。2.4活动图活动图是一款行为图(behaviordiagram)，如图2-34所示，