UML建模之类图学习笔记

UML建模的类图总结

在基于项目的软件工程面向对象研究中，类图作为系统的一个方面建模在项目中起着无可替代的作用。它为整个系统的架构做出了形象的模拟。类图是在分析和设计阶段中共用的元素，它在分析阶段中出现，在设计阶段中细化并加强。实现过程中，通过最初对类图的定义逐步继续接下来的开发过程。所以类图在接下来的开发阶段可能会一直被借鉴，被修改，被完善。这样类图功能作为一种机制结合了所有的软件开发阶段。当类定义被编码、测试并验证后，系统就完成了。

类图的目的是描述类的部分元素以及存在于类之间的重要关系。本文是根据UML建模的角度来着重分析类与类之间的关系，对于类的定义将会一笔带过。

类图在UML中的表示方法

首先我们看一下类的概念，类封装了一组相关的信息和行为，是具有相同属性、操作、关系的对象集合的总称。在UML中，类用下图表示：

Figure1 类图

类的上层表示类名，中层包括属性，下层包含操作。如果要简化框图，可以隐藏类的属性和操作。而且在大部分情况下由于受到屏幕大小的限制往往不能再一个图中将类的所有属性和操作都显示出来。在显示类图时可以只将感兴趣的属性和操作显示出来就可以了。ROSE系统可以用“…”表示没有显示出来的属性或方法。为了准确地描述属性或方法，可以在一组类型相同的属性或方法前加上一个描述的前缀（<<……>>），如图Figure 2。

Figure2 类模型

类之间存在的关系主要有这6种：关联（Association）、概括（Generalization）、聚合（Aggregation）、链接属性（LinkAttribute）、依赖或实例化（Dependency or Instantiates）和实现（Realizes）。下面通过UML的图形化方式详细介绍这6中关系。

关联（Association）

关联是一种结构化的关系，指一种对象和另一种对象有联系，使一个类的对象可以访问另一个对象类的公共属性和操作。关联有两元关系和多元关系。两元关系是指一对一的关系，多元关系是指一对多或多对一的关系。

在软件项目中，对于关联关系的具体实现是在一个类对象的函数或方法中调用另一个类对象的函数或方法。

一般用实线连接有关联的同一个类或不同的两个类。这里要指出的是，关联连接用的实线可以是有箭头的实线也可是无箭头的实线。当实线两端的类需要知道对方类的公共属性或操作时，此时这两个类之间的关系是双向关系，他们之间用无箭头的实线连接表示关联关系。图所示模型表示的是公司里面工作人员和公司两个类之间的关系，因为工作人员需要知道公司的名字属性，而公司也需要知道工作人员的姓名、家庭住址等情况。由于工作人员类知道公司类的公共属性和操作，公司类也知道工作人员的公共属性和操作，此时表示他们之间是双向关系。

Figure3 公司与人员对象关系模型

但是大多数关系应该调整为单向的，比如乘客与公交车的关系，此时公交车类需要知道乘客的公共属性，但是乘客类不知道汽车类的公共属性和操作，因此总是BUS对象可以向Customer对象发送消息。如图所示。

Figure4 公交车与乘客对象关系模型

概括（Generalization）

概括是一种继承关系，通常称之为“is-a-kind-of”的关系。它是指两个模型元素（如类、角色、用例和包）之间的继承关系。使一个类可以继承另一个类的公共和保护属性和操作。通常形象地称继承类为子类，而被继承类为父类。

这种关系通常在软件项目中，利用继承实现。单个的继承很容易实现，但是对于多重继承以及循环继承就需要小心对待了。另一点在UML建模中，父类是否被完全分类为子类？被分类后的子类是否有交叉？都需要我们去考虑，以及在图形中也需要我们给其注明。

Figure5 员工分类模型

聚合（Aggregation）

聚合实际上是一种特殊的关联关系，它指一种整体与部分之间的关系。

通常软件项目中实现聚合的方法是，将部分类对象作为整体类对象的一个属性。这样就充分展示了整体与部分的关系。

需要注意，在整体与部分的关系中，有些整体缺失了某个部分就不作为一个整体了，例如图汽车作为一个整体，轮胎、引擎、车门作为汽车的三个部分，一旦缺失了三个中的某一个，那么汽车便不能作为一个真正的汽车而存在。这种关系我们通常称之为整体和部分关系。

Figure6 整体和部分关系模型

有趣的是，有些整体即使缺失了某个部分，但它还是作为一个整体而存在，比如我们上课时的班级，我们知道班级由学生组成，可即使上课时某个学生请假了或者是由于其他原因没有到，可是我们还是会作为一个班级继续上课。像这种关系我们称之为组合关系。

Figure7 组合关系模型

对于两种关系在UML建模中更好区分，我们使用空心菱形来代表组合关系，实心菱形代表整体和部分关系。

 

链接属性（Link Attribute）

链接属性也称为Association类，它实际上是把链接关系看成了一个类，这样在这个Association类中可以存放与关联相关的属性。

例如，图中学生（Student）类和课程（Course）类，如果它们都具有年级（Grade）属性，那么Grade属性该如何放置。如果放置在Student类中，则需要对学生注册的每门课程加一个属性，这样会使Course类非常复杂。如果将属性加到Course类中，则需要对每个选课的学生加一个属性。要解决这个问题，我们就需要创建一个Association类。属性Grade与学生和课程的链接有关，而不是与两者各自相关，因此可以放在这个Association类中。

Figure8 属性关联模型范例

依赖或实例化（Dependency or Instantiates）

依赖关系是一种使用关系，显示了一个类使用另一个类，因此使用类的改变有可能会影响到使用该类的类，反之不成立。需要注意，关联是可以是双向的，而依赖性关系只能是单向的。通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数，这是软件项目中的常用的实现依赖关系的方法。

如图中Flight类与Customer类之间存在依赖关系，Flight类要设法知道Customer类的存在，因为在Flight类中addCustomer方法将Customer类作为其接口说明的一个形参类型。从编程角度可以想象，如果Customer累不存在，则Flight了在编译时就会出错。箭头方向表示Flight类依赖于Customer类。

Figure9 依赖关系模型范例

实现（Realizes）

实现关系中要求一方为供应元素（Supplier Element），另一方为客户元素（Client Element）。实现关系中的供应元素和客户元素是类和接口或者是组件与接口时，那么它指类实现了接口所提供的操作。

如果实现关系是指向接口的，那么关系显示为一条实线，然而如果实现关系是由包指向类的话，此时关系显示为一条虚线箭头。如图所示

Figure10 实现关系模型范例

另外对于接口和抽象类，我们知道接口是用来实现的，接口只能声明一些没有实现的操作。而抽象类不仅可以声明操作，而且可以对这些操作进行可选的实现，另外抽象类是可以有属性的，而接口不可以。