本节向大家介绍一下UML类图教程， 类图(ClassDiagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。下面请看详细介绍。
UML类图教程
数千年以前,人类就已经开始采用分类的方法有效地简化复杂问题,帮助人们了解客观世界。在面向对象建模技术中,我们使用同样的方法将客观世界的实体映射为对象,并归纳成一个个类。类(Class)、对象(Object)和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统,其类模型和对象模型揭示了系统的结构。在UML中,类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。
(1)类图
类图(ClassDiagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。
(2)类和对象
对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例(Instance)。建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改、易理解和易交流。
UML类图教程中类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。图1中,"客户"就是一个典型的类。
类的获取和命名 最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的名字是名词。
类的属性 中间的格子包含类的属性,用以描述该类对象的共同特点。该项可省略。图1中"客户"类有"客户名"、"地址"等特性。属性的选取应考虑以下因素:
◆原则上来说,类的属性应能描述并区分每个特定的对象;
◆只有系统感兴趣的特征才包含在类的属性中;
◆系统建模的目的也会影响到属性的选取。
根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为:
可见性 属性名: 类型=缺省值 {约束特性}
(3)关联关系
UML类图教程中关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。
在图1中最上部存在一个"属于"/"签定"关联:每个"保险单"属于一个"客户",而"客户"可以签定多个"保险单"。除了这个关联外,图1中还有另外两个关联,分别表示每个"保险单"包含若干个"保险单上的项目",而每个"保险单上的项目"涉及单一的"保险类别"。
关联的方向 关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单向关联(Uni-directionalAssociation),在两个方向上都有导航表示的关联,称作双向关联(Bi-directionalAssociation)。图1中,"保险单"到"保险单上的项目"是单向关联。UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选择,因此,在图中应明确使用其中的一种选择。
关联的命名 既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字,可以用小黑三角表示名字的方向(见图1中最上部的"属于"/"签定"关联)。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。
角色 关联两头的类以某种角色参与关联。例如图2中,"公司"以"雇主"的角色,"人"以"雇员"的角色参与的"工作合同"关联。"雇主"和"雇员"称为角色名。如果在关联上没有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。在图2中,雇主(公司)可以雇佣(签工作合同)多个雇员,表示为"*";雇员只能与一家雇主签定工作合同,表示为"1"。多重性表示参与对象的数目的上下界限制。"*"代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单。"1"是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也可以用范围或者是数字和范围不连续的组合表示。#p#
关联类
一个关联可能要记录一些信息,可以引入一个关联类来记录。图3是在图2的基础上引入了关联类。关联类通过一根虚线与关联连接。图4是实现上述目标的另外一种方法,就是使雇用关系成为一个正式的类。
聚集和组成
UML类图教程中聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关系。聚集可以进一步划分成共享聚集(SharedAggregation)和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象方法与UML中所定义的聚集的差别。
(4)继承关系
人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。例如,动物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。
如图1中,将客户进一步分类成个体客户和团体客户,使用的就是继承关系。
在UML定义中对继承有三个要求:
◆ 特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有;
◆ 特殊元素还应包含额外信息;
◆ 允许使用一般元素实例的地方,也应能使用特殊元素。
(5)依赖关系
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的界面改变,它发出的任何消息可能不再合法。
(6)类图的抽象层次和细化(Refinement)关系
需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。UML类图教程中按照SteveCook和JohnDianiels的观点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出。
概念层 概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。事实上,一个概念模型应独立于实现它的软件和程序设计语言。
说明层 说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type)描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现。
实现层 只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。
理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。
下面介绍细化概念。细化是UML中的术语,表示对事物更详细一层的描述。两个元素A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细的描述,则称元素B细化了元素A,或称元素A细化成元素B。细化的图形表示为由元素B指向元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。细化主要用于模型之间的合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。
(7)约束
在UML类图教程中,可以用约束(Constraint)表示规则。约束是放在括号"{}"中的一个表达式,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。
【编辑推荐】
