摘要：类图（Class Diagram）可能是用得最多的一种UML图。类图的基本语法并不复杂，你可能最多学习两三天就可以掌握，然而要真正做到活用类图则可能需要几年的功力。类图是锻炼面向对象分析（OOA：Object-Oriented Analysis）和面向对象设计（OOD：Object-Oriented Design）思想的重要的工具，是业务结构建模的重要工具。本章将会有大量的实战练习，你的OOA思想将会接受极大的考验和提升。
3.3 类之间的关系
表达类之间关系时，类只需要画出名字就可以了，属性和方法可以省略显示。
“直线”关系
A、B两个类，它们之间有关系，但又不能确定是怎样的关系，我们可以这样画：
图 3.4 “直线”关系
这个“直线”关系其实就是关联（Association）关系，“关联”是 UML中文术语的标准说法，但为了能让大家更容易理解和记忆，我会使用一些“老土”的说法。
做 软件 需求分析时，如果觉得两个业务概念之间有联系，但暂时不能确定具体是怎样的，那么就先画一条线将两者连起来再说。随着你对业务的理解，这条线条会进一步具体化，你可以为这条线添加更多的元素。
图 3.5 一对一关系
这个图C、D两个类有一条直线相连，但在直线两端各有一个数字1，表示一个C对应一个D。
图 3.6 一对多关系
这个图表示一个E对应0到多个F，*号的意思就是表示0到多个。
图 3.7 一对零到三个关系
这个图表示一个G对应0到3个M，“0..3”表示0到3个，“1..4”表示1到4个，“x..y”表示x到y个（x，y表示任意自然数，而且x < y），注意有两个点（“..”）而不是一个点（“.”）。
图 3.8 角色关系
这个图表示I和J之间有关系，在这个关系中I的身份是上司，J的身份是下属。我们可以在线条的两端标记在这个关系中，两者分别是处在怎样的角色。
你可能会留意到，为什么“上司”、“下属”前面有一个“+”号？“+”号表示这个角色的类型是public的，“-”号表示private，这些符号在 软件设计时才需要用到，我们做软件 需求分析时，不需要理会这些符号，全部画成“+”号就可以了。
这条直线如果变成带箭头的，又是表示怎样的意思呢？请看下图：
图 3.9 “导航”关系
这个图表示由A可找到B，箭头表示方向，由A可“导航”到B。
写代码时，如果A类有一个成员变量保存的是类B的引用，也就是说由类A可以找到类B，那么可以画成图3.9的样子。这是从软件设计的角度来解释这个箭头的意义，如果是 软件需求分析，这个箭头是怎样的意思呢？下面是一个实例：
图 3.10 请假单与请假者的关系
请假单上会列明是谁请的假，所以我们由请假单可以找到请假者。进行业务分析时，往往会发现由业务概念A可找到B，这时可以使用带箭头的线条。
直线关系是最常见的关系，最简单的直线关系就是两个类之间画条线就可以了。我们也可以进一步细化这条直线关系：在这条直线的两端，可以标记上数字和名称，数字表示是几对几的关系，名称则表示在这个关系中，直线两端的两个类分别是怎样的一个角色，而这条直线也可以变成带箭头的直线。直线、几对几的关系、角色、箭头可以搭配使用，只要能准确反应出业务关系就可以了。
直线关系只是一种老土的说法，UML中文术语标准是关联（Association）关系。另外要说明的是，有时候因为类太多，为了让 类图更容易阅读，需要将“直线”画成“折线”，如下图：
图 3.11 “折线”关系
“包含”关系
一个部门有多个员工，用类图可以这样表示：
图 3.12 “包含”关系
这里有两种表示法，一种是空心菱形，一种是实心菱形。两种菱形表示包含的强烈程度不同，空心菱形是“弱”包含，实心菱形则是“强”包含。你可以这样记忆：空心菱形是空心的，显得虚弱一点，这是“弱”包含；实心菱形是实心的，显得更加强壮，这是“强”包含。
“弱”包含表示如果部门没有了，员工也可以继续存在；“强”包含表示如果部门没有了，员工也不再存在。关于这两者的另外一个重要区别是：如果是“弱”包含关系，儿子可以有多个父亲（当然只有一个父亲也是可以的）；如果是“强”包含关系，则儿子只能有一个父亲。
做软件需求分析时，我往往会将所有的包含关系画成“弱包含”，如果后面发现某些关系可以表示为“强包含”时，我才转为实心菱形。
请留意包含的方向，谁包含谁，刚学习的朋友很容易把方向画反了。
在员工这边的“*”号表示零到多名的意思，如果是“1..100” 则表示1到100名；而部门这边没有具体的数字，则表示是“1”，则一名员工只能属于一个部门。如果一名员工同属于多个部门，那应该怎样画呢？
图 3.13 部门与员工的多对多关系
部门这边的“*”表示一名员工可同属于多个部门，请注意，在“强包含”关系中，一名员工只能属于一个部门。
“弱包含”、“强包含”的说法只是一种方便大家记忆和理解的老土说法而已，空心菱形的UML中文术语标准说法是聚合（Aggregation），实心菱形是组合（Composition）。以前看UML资料遇到聚合和组合两个词都会让我头晕一番，因为那些解释说得太复杂了，就算是现在我遇到这两个词也需要稍微停顿一下来想一想。刚学习包含关系的朋友，建议你只需要记住“弱包含”“强包含”的说法就可以了。
“继承”关系
我以前的公司有一个每日培训的制度，由公司内部员工做讲师，分享知识和经验。员工可以做学生，也可以上台做老师，下面是学生和老师的类图：
图 3.14 学生和老师
请思考，学生和讲师有什么共性呢？
学生和讲师不都是员工吗，凡是员工都有这样的属性了：
图 3.15 员工
说明：此图只列了三个员工的属性，仅作示意。
员工、学生、讲师可以表示为以下的关系：
图 3.16 员工、学生、老师关系
学生、讲师都“继承”了员工，他们具备员工的属性，同时也有自己特有的属性。另外一种说法是：学生、讲师是员工的一种。
“继承”的基本画法如下：
图 3.17 “继承”关系
这表示A继承了B，A具备B的特点，同时也有自己特有的特点，注意不要搞错继承方向。
“继承”同样是一种老土的说法，UML中文术语标准是泛化（Generalization），该图可这样读：A泛化为B。泛化这个词比较难理解，你可以理解为抽象、提炼等。
在实际的软件需求分析工作中，我们往往有两种认识事物的角度，我们以员工、学生、老师的关系为例子来说明。
角度一：在培训现场，我们看到的是学生和老师，后来你发现，原来老师是内部员工来的！于是你可以从学生和老师这两个类出发，发现学生和老师其实都是员工！
角度二：作为这个公司的领导，希望公司形成一种学习和进步的风气，促进公司的进步，于是领导希望员工之间能互相分享知识和经验。从这个角度看来，领导先想到的是员工，然后再进一步发现员工可以当学生也可以当老师。
在泛化关系中，以图1.17为例，我们有可能先发现A，然后导出B，这时可以说由A泛化为B；也有可能是先发现B，然后导出A，这时可以说A继承B。泛化（继承）是我们进行业务提炼的重要手段，后面我们将有更多的具体例子和练习。
依赖关系
如果一个烟鬼嗜烟如命，没有烟不能生活，用类图可以这样表示：
图 3.18 烟鬼与香烟的关系
这个虚线箭头就是依赖（Dependency）关系，这虚线箭头与导航关系的实线箭头很相似，注意不要搞混了，两者表示的意思是完全不一样的。
如果说类A依赖于类B，类图表示如下：
图 3.19 依赖关系
所谓的依赖关系，依赖的程度是相当而言的，不一定是A没有B就不能“生存”了。在具体的业务逻辑中，对于某个事情，A需要B来协助才能完成，这样也是一种依赖。
这个小节内容非常多，你可能有点消化不良了。上面介绍的内容其实在需求分析工作中是经常需要用到的，而其中最常用的是直线关系。
下面开始你将会通过一个个的练习来帮助你理解和巩固这些知识，强烈建议你看完题目后先独立思考完成，然后再继续看参考答案。
“包含”关系
一个部门有多个员工，用类图可以这样表示：
图 3.12 “包含”关系
这里有两种表示法，一种是空心菱形，一种是实心菱形。两种菱形表示包含的强烈程度不同，空心菱形是“弱”包含，实心菱形则是“强”包含。你可以这样记忆：空心菱形是空心的，显得虚弱一点，这是“弱”包含；实心菱形是实心的，显得更加强壮，这是“强”包含。
“弱”包含表示如果部门没有了，员工也可以继续存在；“强”包含表示如果部门没有了，员工也不再存在。关于这两者的另外一个重要区别是：如果是“弱”包含关系，儿子可以有多个父亲（当然只有一个父亲也是可以的）；如果是“强”包含关系，则儿子只能有一个父亲。
做软件需求分析时，我往往会将所有的包含关系画成“弱包含”，如果后面发现某些关系可以表示为“强包含”时，我才转为实心菱形。
请留意包含的方向，谁包含谁，刚学习的朋友很容易把方向画反了。
在员工这边的“*”号表示零到多名的意思，如果是“1..100” 则表示1到100名；而部门这边没有具体的数字，则表示是“1”，则一名员工只能属于一个部门。如果一名员工同属于多个部门，那应该怎样画呢？
图 3.13 部门与员工的多对多关系
部门这边的“*”表示一名员工可同属于多个部门，请注意，在“强包含”关系中，一名员工只能属于一个部门。
“弱包含”、“强包含”的说法只是一种方便大家记忆和理解的老土说法而已，空心菱形的UML中文术语标准说法是聚合（Aggregation），实心菱形是组合（Composition）。以前看UML资料遇到聚合和组合两个词都会让我头晕一番，因为那些解释说得太复杂了，就算是现在我遇到这两个词也需要稍微停顿一下来想一想。刚学习包含关系的朋友，建议你只需要记住“弱包含”“强包含”的说法就可以了。
“继承”关系
我以前的公司有一个每日培训的制度，由公司内部员工做讲师，分享知识和经验。员工可以做学生，也可以上台做老师，下面是学生和老师的类图：
图 3.14 学生和老师
请思考，学生和讲师有什么共性呢？
学生和讲师不都是员工吗，凡是员工都有这样的属性了：
图 3.15 员工
说明：此图只列了三个员工的属性，仅作示意。
员工、学生、讲师可以表示为以下的关系：
图 3.16 员工、学生、老师关系
学生、讲师都“继承”了员工，他们具备员工的属性，同时也有自己特有的属性。另外一种说法是：学生、讲师是员工的一种。
“继承”的基本画法如下：
图 3.17 “继承”关系
这表示A继承了B，A具备B的特点，同时也有自己特有的特点，注意不要搞错继承方向。
“继承”同样是一种老土的说法，UML中文术语标准是泛化（Generalization），该图可这样读：A泛化为B。泛化这个词比较难理解，你可以理解为抽象、提炼等。
在实际的软件需求分析工作中，我们往往有两种认识事物的角度，我们以员工、学生、老师的关系为例子来说明。
角度一：在培训现场，我们看到的是学生和老师，后来你发现，原来老师是内部员工来的！于是你可以从学生和老师这两个类出发，发现学生和老师其实都是员工！
角度二：作为这个公司的领导，希望公司形成一种学习和进步的风气，促进公司的进步，于是领导希望员工之间能互相分享知识和经验。从这个角度看来，领导先想到的是员工，然后再进一步发现员工可以当学生也可以当老师。
在泛化关系中，以图1.17为例，我们有可能先发现A，然后导出B，这时可以说由A泛化为B；也有可能是先发现B，然后导出A，这时可以说A继承B。泛化（继承）是我们进行业务提炼的重要手段，后面我们将有更多的具体例子和练习。
依赖关系
如果一个烟鬼嗜烟如命，没有烟不能生活，用类图可以这样表示：
图 3.18 烟鬼与香烟的关系
这个虚线箭头就是依赖（Dependency）关系，这虚线箭头与导航关系的实线箭头很相似，注意不要搞混了，两者表示的意思是完全不一样的。
如果说类A依赖于类B，类图表示如下：
图 3.19 依赖关系
所谓的依赖关系，依赖的程度是相当而言的，不一定是A没有B就不能“生存”了。在具体的业务逻辑中，对于某个事情，A需要B来协助才能完成，这样也是一种依赖。
这个小节内容非常多，你可能有点消化不良了。上面介绍的内容其实在需求分析工作中是经常需要用到的，而其中最常用的是直线关系。
下面开始你将会通过一个个的练习来帮助你理解和巩固这些知识，强烈建议你看完题目后先独立思考完成，然后再继续看参考答案。