UML 类图详解.docx
《UML 类图详解.docx》由会员分享，可在线阅读，更多相关《UML 类图详解.docx（27页珍藏版）》请在冰豆网上搜索。
UML类图详解
UML类图
在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。
建模工具也主要根据类图来产生代码。
类图在UML的9个图中占据了一个相当重要的地位。
JamesRumbaugh对类的定义是：
类是具有相似结构、行为和关系的一组对象的描述符。
类是面向对象系统中最重要的构造块。
类图显示了一组类、接口、协作以及他们之间的关系。
在UML中问题域最终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。
类加上他们之间的关系就构成了类图，类图中还可以包含接口、包等元素，也可以包括对象、链等实例。
接口在类图中通过版型来表示<>，下面的介绍将主要介绍类，接口和类类似。
A.类的UML表示
类的命名尽量应用领域中的术语，应明确、无岐义，以利于相互交流和理解。
类的属性、操作中的可见性使用＋、#、－分别表示public、protected、private。
B.类之间的关系
类之间的关系是类图中比较复杂的内容。
有关联、聚合、组合、范化、依赖。
关联：
是模型元素之间的一种语义联系，是类之间的一种很弱的联系。
关联可以有方向，可以是单向关联，也可以是双向关联。
可以给关联加上关联名来描述关联的作用。
关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个对象参与关联。
可以通过关联类进一步描述关联的属性、操作以及其他信息。
关联类通过一条虚线与关联连接。
对于关联可以加上一些约束，以加强关联的含义。
如下图所示：
聚合是一种特殊的关联，聚合表示整体与部分的关系。
通常在定义一个整体类后，再去分析这个整体类的组成结构。
从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。
例如舰队是由一系列的舰船组成。
需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。
组合也是一种特殊的关联，也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。
一旦整体对象不存在，部分对象也将不存在。
部分对象与整体对象之间具有共生死的关系。
聚合和组合的区别：
聚合关系是“has－a”关系，组合关系是“contains－a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。
组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。
泛化定义了一般元素和特殊元素之间的分类关系，类之间的这种泛化关系也就是继承关系。
泛化关系是“a－kind－of”关系，定义一般元素和特殊元素之间的分类关系。
下图是一个泛化关系的例子。
有两个元素如果修改X的定义可能会导致对Y的定义，则认为Y依赖X。
依赖关系可能由各种原因引起，如一个类向另一个类发送消息，或者一个类是另一个类的数据成员类型，或者一个类是另一个类的操作的参数类型等。
有时依赖关系和关联关系比较难区分。
如果类A和类B有关联关系，它们之间必然有依赖关系。
如果两个类之间有关联关系时不用再表示出这两个类之间的依赖关系。
C.建立类图
在软件开发不同阶段使用的类图具有不同的抽象层次，即概念层、说明层、和实现层。
使用UML进行应用建模也应该是一个迭代的过程，所以我们应该建立一个类图的层次的概念。
概念层类图描述应用领域中的概念，这些概念与实现它们的类有联系。
通常没有直接的映射关系。
画概念层类图时很少考虑或不考虑实现问题，因此概念层类图应独立于具体的编程语言。
下面是一个概念层类的表示。
说明层类图。
此时我们考察的是类的接口部分，而不是实现部分。
这个接口可能因为实现环境、运行特性等有多种不同的实现。
下面是一个说明层类的表示。
实现层类图才真正考虑类的实现问题，提供实现的细节。
此时的类的概念才应该是真正的严格意义上的类。
它揭示了软件实体的构成情况。
实现层的类是最常用的，在很多的时候说明层的类更有助于人们对软件的理解。
UML的最终目标是识别出所有必须的类，并分析这些类之间的关系，类的识别贯穿于整个建模过程，分析阶段主要识别问题域相关的类，在设计阶段需要加入一些反映设计思想、方法的类以及实现问题域所需要的类，在编码实现阶段，因为语言的特点，可能需要加入一些其他的类。
建立类图的步骤：
（1）研究分析问题领域确定系统需求。
（2）确定类，明确类的含义和职责、确定属性和操作。
（3）确定类之间的关系。
类的识别是一个需要大量技巧的工作，寻找类的一些技巧包括：
名词识别法；根据用例描述确定类；使用CRC分析法；根据边界类、控制类、实体类的划分来帮助分析系统中的类；参考设计模式确定类；对领域进行分析或利用已有领域分析结果得到类；利用RUP中如何在分析和设计中寻找类的步骤。
1.名词识别法：
这种方法的关键是识别系统问题域中的实体。
对系统进行描述，描述应该使用问题域中的概念和命名，从系统描述中标识名词及名词短语，其中的名词往往可以标识为对象，复数名词往往可以标识为类。
2.从用例中识别类：
用例图实质上是一种系统描述的形式，自然可以根据用例描述来识别类。
针对各个用例，可以提如下的问题辅助识别：
用例描述中出现了那些实体？
用例的完成需要哪些实体合作？
用例执行过程中会产生并存储哪些信息？
用例要求与之关联的每个角色的输入是什么？
用例反馈与之关联的每个角色的输出是什么？
用例需要操作哪些硬设备？
在面向对象应用中，类之间传递的信息数据要么可以映射到发送方的某些属性，要么该信息数据本身就是一个对象。
综合不同的用例识别结果，就可以得到整个系统的类，在类的基础上，我们又可以分析用例的动态特性来对用例进行动态行为建模。
3.使用CRC分析法：
CRC（Class,Responsibilities,Collaboration）卡的最大价值在于把人们从思考过程模式中脱离出来，更充分的专注于对象技术。
CRC卡允许整个项目组对设计做出贡献。
参与系统设计的人越多，能够收集到的好主意也就越多。
因为CRC会议是大家全力参与的，通常只需要很少的有类名的卡片，实际上没有写出完整的卡片。
CRC会议进行中，一些人模拟系统和对象交流，把消息传给其他的对象。
通过一步步处理，问题很容易地被解决。
它由三部分组成：
类（Class）、职责（Responsibility）、协作（Collaborator）。
下面是一个CRC卡的示例：
职责是类需要知道或做的任何事物。
这些职责是类自身所知的知识，或类在执行时所需的知识。
协作是指为获取消息，或协助执行活动的其他类。
创建CRC模型需要下面的步骤。
1） 建立团队，包括客户、设计人员、分析人员和一个导引者。
如果没有那么多人，那么可以是客户和你自己两个人。
2） 找出需求中存在的名词和名词词组，特别注意复数（通常是集合），他们对应的单数才是。
把你第一次想到的所有概念都写在白板或纸上。
不管看起来这些概念是如何荒谬，把他们都写下来。
3） 筛选。
把对象分为三类，核心对象（必须首先实现），可选的（目前不能确定），以及不需要的对象。
这之前最好确定一下你的项目范围。
某些不属于本项目范围的对象可以使用轻量的adapter或proxy实现。
这里可以加入对分析、设计模式的考虑和应用。
4） 建卡。
取出CRC卡，把核心类写在每一张卡上，把可选的类和排除的类分别写在不同的纸上。
5） 角色扮演。
最好是一个团队执行，一个人很难做。
每个人负责几个类。
对每一个Usecase其中的情景。
导引者指定从某一个人的类开始，某一个人看一看自己能够独立完成，如果不能完成，大家看一看手中的类，谁能完成，就站起来，宣布自己能够完成，以致继续这个过程，每个人完成自己的职责就坐下。
在这过程中不断修改类的责任，并写下协作者的名字。
4.根据边界类、控制类、实体类帮助分析系统中的类
UML中类有三种主要的版型：
边界类、控制类和实体类。
引入边界类、控制类及实体类的概念有助于分析和设计人员确定系统中的类。
边界类位于系统与外界的交界处，窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。
通过用例图可以确定需要的边界类，每个Actor/UseCase对至少要一个边界类，但并非每个Actor/UseCase对要唯一的边界类。
实体类保存要放进持久存储体的信息。
持久存储体就是数据库、文件等可以永久存储数据的介质。
实体类可以通过事件流和交互图发现。
通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。
控制类是控制其他类工作的类。
每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。
其他类并不向控制类发送很多消息，而是由控制类发出很多消息。
5.领域进行分析
建立类图的过程就是对领域及其解决方案的分析和设计过程。
类的获取是一个依赖个人创造力的过程，有时需要和领域专家合作，对研究领域进行仔细分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。
领域分析是：
通过对某一领域中的已有应用系统、理论、技术、开发历史等的研究，来标识、收集、组织、分析和表示领域模型及软件体系结构的过程，并得到结果。
D.使用类图
类图几乎是所有面向对象方法的支柱，应该如何使用类图呢？
以下提供了一些使用类图的一些建议。
不要试图在项目的初始阶段使用所有的符号，首先应该从简单概念开始。
比如类的关系等等，在需要的时候才使用。
在项目的不同开发阶段，应该使用不同的观点来画类图。
如果处于分析阶段应该画概念层类图，当开始着手软件设计时，应该画说明层类图，当针对某个特定的技术实现时应该画实现层类图。
不要为每个事物都画一个模型，应该把精力放在关键的领域。
使用类图的最大危险是过早的陷入实现的细节，为了避免这个问题，应该将重点放在概念层和说明层。
UML类图详解
（1）
第 [1] [2] [3] [4] [5] 页
这是关于统一建模语言、即UML里采用的基本图的文章。
在这篇文章中，我将会讨论结构图，这是已经在UML2中提出的一种新图种类。
由于本系列文章的目的是使人们了解记号元素及它们的含意，该文主要关注类图。
你很快就会知道这样做的理由。
随后的文章将会覆盖结构范畴中包含的其它图。
我也想提醒读者，这一系列文章是关于UML记号元素的，所以这些文章并不意味着为建模的最好方式提供指导方针，或是该如何决定哪些内容应该首先被建模。
相反的，该文及本系列文章的目的主要是帮助大家对于记号元素--语法和含义有一个基本的理解。
借由这些知识，你应该可以阅读图，并使用正确的记号元素创建你自己的图。
这篇文章假定你对面向对象的设计已经有了基本的理解。
你们当中如果有人需要一些面向对象概念的帮助，那么可以访问Sun公司关于面向对象编程的简短指导。
阅读“什么是类？
”和什么是继承？
”章节，将提供给你足够的理解，并对该文的阅读会有所帮助。
另外，DavidTaylor的书《Object-OrientedTechnologies:
AManager'sGuide》提供了面向对象设计的优秀，高水平的说明，而无需对计算机编程有高深的理解。
UML2中的阴和阳
在UML2中有二种基本的图范畴：
结构图和行为图。
每个UML图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类，组件和（或）对象图。
另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。
行为图的实例是活动图，用例图和序列图。
大体上的结构图
如同我所说的，结构图显示建模系统的静态结构。
关注系统的元件，无需考虑时间。
在系统内，静态结构通过显示类型和它们的实例进行传播。
除了显示系统类型和它们的实例，结构图至少也显示了这些元素间的一些关系，可能的话，甚至也显示它们的内部结构。
贯穿整个软件生命周期，结构图对于各种团队成员都是有用的。
一般而言，这些图支持设计验证，和个体与团队间的设计交流。
举例来说，业务分析师可以使用类或对象图，来为当前的资产和资源建模，例如分类账，产品或地理层次。
架构师可以使用组件和部署图，来测试/确认他们的设计是否充分。
开发者可以使用类图，来设计并为系统的代码（或即将成为代码的）类写文档。
特殊的类图
UML2把结构图看成一个分类；这里并不存在称为“结构图”的图。
然而，类图提供结构图类型的一个主要实例，并为我们提供一组记号元素的初始集，供所有其它结构图使用。
由于类图是如此基本，本文的剩余部分将会把重点集中在类图记号集。
在本文的结尾，你将对于如何画UML2类图有所了解，而且对于理解在后面文章中将涉及的其他结构图有一个稳固的基础。
基础
如先前所提到的，类图的目的是显示建模系统的类型。
在大多数的UML模型中这些类型包括：
类
接口
数据类型
组件
UML为这些类型起了一个特别的名字：
“分类器”。
通常地，你可以把分类器当做类，但在技术上，分类器是更为普遍的术语，它还是引用上面的其它三种类型为好。
类名
类的UML表示是一个长方形，垂直地分为三个区，如图1所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
图1显示一个航线班机如何作为UML类建模。
正如我们所能见到的，名字是Flight，我们可以在中间区域看到Flight类的3个属性：
flightNumber，departureTime和flightDuration。
在底部区域中我们可以看到Flight类有两个操作：
delayFlight和getArrivalTime。
图1:
Flight类的类图
类属性列表
类的属性节（中部区域）在分隔线上列出每一个类的属性。
属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。
该线用如下格式：
name:
attributetype
flightNumber:
Integer
继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表1所示。
表1：
具有关联类型的Flight类的属性名字
属性名称
属性类型
flightNumber
Integer
departureTime
Date
flightDuration
Minutes
在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。
在类图上显示具有默认值的特定属性，有时是有用的（例如，在银行账户应用程序中，一个新的银行账户会以零为初始值）。
UML规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：
name:
attributetype=defaultvalue
举例来说：
balance:
Dollars=0
显示属性默认值是可选择的；图2显示一个银行账户类具有一个名为balance的类型，它的默认值为0。
图2：
显示默认为0美元的balance属性值的银行账户类图。
类操作列表
类操作记录在类图长方形的第三个（最低的）区域中，它也是可选择的。
和属性一样，类的操作以列表格式显示，每个操作在它自己线上。
操作使用下列记号表现：
name（parameterlist）:
typeofvaluereturned
下面的表2中Flight类操作的映射。
表2：
从图2映射的Flight类的操作
操作名称
返回参数
值类型
delayFlight
Name
Type
numberOfMinutes
Minutes
N/A
getArrivalTime
N/A
Date
图3显示，delayFlight操作有一个Minutes类型的输入参数--numberOfMinutes。
然而，delayFlight操作没有返回值。
1当一个操作有参数时，参数被放在操作的括号内；每个参数都使用这样的格式：
“参数名：
参数类型”。
图3：
Flight类操作参数，包括可选择的“in”标识。
当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。
这个可选择的指示器以“in”或“out”出现，如图3中的操作区域所示。
一般来说，除非将使用一种早期的程序编程语言，如Fortran，这些指示器可能会有所帮助，否则它们是不必要的。
然而，在C++和Java中，所有的参数是“in”参数，而且按照UML规范，既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。
继承
在面向对象的设计中一个非常重要的概念，继承，指的是一个类（子类）继承另外的一个类（超类）的同一功能，并增加它自己的新功能（一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人）的能力。
为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。
考虑银行账户的类型：
图4显示CheckingAccount和SavingsAccount类如何从BankAccount类继承而来。
图4:
继承通过指向超类的一条闭合的，单箭头的实线表示。
在图4中，继承关系由每个超类的单独的线画出，这是在IBMRationalRose和IBMRationalXDE中使用的方法。
然而，有一种称为树标记的备选方法可以画出继承关系。
当存在两个或更多子类时，如图4中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。
图5是重绘的与图4一样的继承，但是这次使用了树形记号。
图5:
一个使用树形记号的继承实例
抽象类及操作
细心的读者会注意到，在图4和图5中的图中,类名BankAccount和withdrawal操作使用斜体。
这表示，BankAccount类是一个抽象类，而withdrawal方法是抽象的操作。
换句话说，BankAccount类使用withdrawal规定抽象操作，并且CheckingAccount和SavingsAccount两个子类都分别地执行它们各自版本的操作。
然而，超类（父类）不一定要是抽象类。
标准类作为超类是正常的。
关联
当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。
有五种关联。
在这一部分中，我将会讨论它们中的两个--双向的关联和单向的关联，而且我将会在Beyondthebasics部分讨论剩下的三种关联类型。
请注意，关于何时该使用每种类型关联的详细讨论，不属于本文的范围。
相反的，我将会把重点集中在每种关联的用途，并说明如何在类图上画出关联。
双向（标准）的关联
关联是两个类间的联接。
关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除非你限定一些其它类型的关联。
回顾一下Flight的例子，图6显示了在Flight类和Plane类之间的一个标准类型的关联。
图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:
单向关联一个实例：
OverdrawnAccountsReport类BankAccount类，而BankAccount类则对关联一无所知。
一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。
如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。
在图7中的例子中，OverdrawnAccountsReport知道BankAccount类，而且知道BankAccount类扮演“overdrawnAccounts”的角色。
然而，和标准关联不同，BankAccount类并不知道它与OverdrawnAccountsReport相关联。
2
软件包
不可避免，如果你正在为一个大的系统或大的业务领域建模，在你的模型中将会有许多不同的分类器。
管理所有的类将是一件令人生畏的任务；所以，UML提供一个称为软件包的组织元素。
软件包使建模者能够组织模型分类器到名字空间中，这有些象文件系统中的文件夹。
把一个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的一个特定部分时。
3
在图中存在两种方法表示软件包。
并没有规则要求使用哪种标记，除了用你个人的判断：
哪种更便于阅读你画的类图。
两种方法都是由一个较小的长方形（用于定位）嵌套在一个大的长方形中开始的，如图8所示。
但是建模者必须决定包的成员如何表示，如下：
如果建模者决定在大长方形中显示软件包的成员，则所有的那些成员4需要被放置在长方形里面。
另外，所有软件包的名字需要放在软件包的较小长方形之内（如图8的显示）。
如果建模者决定在大的长方形之外显示软件包成员，则所有将会在图上显示的成员都需要被置于长方形之外。
为了显示属于软件包的分类器属于，从每个分类器画一条线到里面有加号的圆周，这些圆周粘附在软件包之上（图9）。
图8：
在软件包
升级会员 