《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.4 演练类之间的关系

摘要：类图（Class Diagram）可能是用得最多的一种UML图。类图的基本语法并不复杂，你可能最多学习两三天就可以掌握，然而要真正做到活用类图则可能需要几年的功力。类图是锻炼面向对象分析（OOA：Object-Oriented Analysis）和面向对象设计（OOD：Object-Oriented Design）思想的重要的工具，是业务结构建模的重要工具。本章将会有大量的实战练习，你的OOA思想将会接受极大的考验和提升。

3.4 演练类之间的关系

练习1、2、3是简单的小练习，而练习4的难度会有所增加。这些练习不仅仅是让你巩固上小节学习的知识，中间还会穿插一些前面还没有介绍的基础知识，而且会让你体验什么是面向对象分析，领悟用类图分析需求的要诀。你准备好接受挑战没有？

练习1：你和你另外一半的关系

你结婚了吗？如果你已婚，那么请你用类图描绘你和你的另外一半的关系？

如果你是单身的，你有男朋友或女朋友吗？有的话，请你用类图画出你们两人的关系？

如果你还没有另外一半，而你又已经到了适合恋爱的年龄，那请你虚拟一位你的意中人，用类图画出你和你的虚拟意中人的关系。

如果你还没有到恋爱或结婚年龄，那么你不需要完成这个练习，直接看后面的参考答案。

如果你是已婚人士，那么你们的关系应该是：



图 1.20 你和你的另外一半关系1

如果你是男生，你在这个关系中的角色就是老公，如果你是女生你就是老婆。一个老公只能对应一个老婆，你应该不会画出1对多吧？

这个图也可以画成这样：



 

图 1.21 你和你的另外一半关系2

这个图在直线上面的“夫妻关系”表示这个关系的名称，你可以为关联关系命名，但这不是必须的，在需求分析工作中也很少有这种需要。

如果你未婚，但你同时有多个男朋友或者女朋友，那么你们的关系可以这样表示：



图 1.22 你和你的另外一半关系3

“1..*”表示1到多个，不要因为你能1对多个男朋友（或女朋友）就很开心，这是一种很不好的关系，强烈建议你将1对多的关系变为1对1，而且说不定有朝一日你会被别人1对多。

如果你还没有另外一半，你可以画成这样：



图 1.23 你和你的另外一半关系3

你的另外一半是作为“虚拟情人”存在的。

如果你很爱你的另外一半，你依赖于你的另外一半，没有她（他）你简直不能活，她（他）是你的生存必需品，你可以画成这样：



图 1.24 你和你的另外一半关系4

你可以跟你的另外一半画画这个图，跟她（他）解释一下是什么意思，你的另外一半一定开心死了。

用类图表达你和你的另外一半的关系，并没有固定的标准答案，你画出来的可能跟上述的参考答案不一样，只要你的逻辑正确，这个图也就是合适的。

下面介绍读图检查法，能帮助你检查类图画得是否合适。

你可以分别从左到右、从右到左来读图，看看有没有不合理的地方。以图1.22为例，从左到右读：1个你对应1个到多个你的另外一半。从右到左读：1个你的另外一半对应1个你，而不要读成：多个你的另外一半对应1个你。注意由“多”的一边往另外一边读时，仍然是1个什么对应多少个什么，无论你从哪边开始读起，都是以“1个……”开头。

练习2：公司与雇员的关系

前面学习了部门与员工的关系，公司与雇员是怎样的关系呢？请用类图画出来。



图 1.25 公司与雇员的关系

这个图表示公司“包含”多名员工，而公司这边也有一个“*”号，这表示一名雇员可受雇于多个公司。事实上很多公司是禁止员工同时受雇于另外一个公司或者是兼职的，这样公司这边就不能画“*”号。

这里的包含是弱包含，能不能画成强包含呢？公司如果不存在了，雇员还存在吗？一个公司没有了，这个公司应该就不会有任何雇员，但不代表原来的雇员都消失了，他们还是存在的。这个问题就比较纠结了，到底是弱包含还是强包含，每个人的标准可能不一样，我不建议在弱包含还是强包含上过于纠结，我做需求分析时绝大部分情况只会用弱包含，强包含只会在很明显的情况下才用。

练习3：香蕉、苹果、梨子的关系

你吃过香蕉、苹果和梨子吗？这三个东西有怎样的关系？请用类图画出来。

你可能觉得这个练习有点“无厘头”，这三种水果能有怎样的关系？它们无非都是可以吃的罗！



图 1.26 香蕉、苹果、梨子的关系

此图表示香蕉、苹果、梨子都是水果的一种，这就是这三者的关系。用专业一点的说法就是香蕉、苹果、梨子泛化为水果。和前面提到的老师、学生泛化为员工不一样，员工是确实存在的，而水果只是一种泛称，没有一样东西的名字直接叫水果的，我们见到的水果都是具体的一种水果。泛化以后的类，有可能是一种经过“抽象”后的东西，这个东西是看不到摸不着的，是我们脑袋里面提炼出来的一种概念。

香蕉、苹果、梨子泛化为水果，水果可以再泛化为食物，食物又可以进一步泛化。有没有必要不断泛化呢？泛化到怎样的程度才是合适的呢？一般来说，如果有A、B、C等两个或者以上的业务概念，我们发现它们有一些共同的特征，则可以考虑将它们泛化为另外一个东西， 这样能帮助我们发现食物的本质；但如果只有一个A时，就没有必要对A再进行泛化，例如：香蕉、苹果、梨子已经泛化为水果了，而水果则没有必要泛化为食物。当然这只是一般准则，具体要泛化到怎样的层次要看具体的业务分析需要，要靠你自己来把握。

练习4：公司的组织架构

这个练习开始有点复杂了，请你用类图描述你所在公司的组织架构。如果你们公司比较庞大，你不是很了解整个公司的组织架构，那么请你选择你熟悉的部分用类图来描述它的组织架构。如果你是学生，那么请你描述你所在大学、学院或学系的组织架构。

我们可以用组织架构图来描绘组织架构，为什么要用类图来表达呢？组织架构图画起来很方便，用类图的画反而觉得有点别扭，用类图来表达组织架构，是不是应该有更大的好处呢？请你带着这些问题来完成这个练习。

某公司只是一个中小型的公司，该公司由一个一个的部门组成，用类图表达其组织架构可能是这样的：



图 1.27 公司的组织架构1

该公司有一个行政人事部、一个研发部、一个服务部、一个销售部、一个财务部。这个图似乎公司有多少个部门，就多画一个包含就搞定了，这样画似乎一点都显示不出类图的优势。

下面这种画法又如何呢？



图 1.28 公司的组织架构2

注意图中抽象部门这四个字是斜体字，这表明这个类是抽象类（Abstract Class），抽象类表示这个类是提炼出来的一种概念，是不具体存在的，具体存在的是继承抽象部门的各个具体的部门。

前面提到的香蕉、苹果、梨子泛化为水果，水果其实也是一种抽象的概念，前面那个图的水果可以画成抽象类。

这个组织架构图已经一定程度地揭示了公司组织架构的本质，一个公司无非就是由一个个部门组成的，只是每个公司具体的部门可能不一样而已。这样的表达效果，用普通的组织架构图是表达不出来的，而类图就可以发挥抽象和提炼的优势。

下面这个图将更进一步揭示公司组织架构的本质：



图 1.29 公司的组织架构3

公司由一个个的部门组成，但要构成一个完整的公司，这些部门应该分为三类：

市场类部门：负责公司形象推广、产品营销方面的部门。

生产类部门：直接生产公司产品的部门。

支持类部门：不直接生产公司产品，但是支持产品生产或支撑公司运作必不可少的部门。

在这个图中，市场类部门有策划部、销售部，生产类部门有研发部、实施部、IT部，支持类部门有：IT部、质量部、财务部、行政人事部，其中IT部既是生产类部门，也是支持类部门。

下面对其中一些具体部门进行解释：

实施部是负责将软件系统安装到客户现场，保障系统上线运行的部门。

IT部主要负责两方面的职能，一方面要保障公司内部的办公软硬件环境，另一方面会承接一些外部的网络工程，为公司直接盈利。第一方面的工作是属于支持类方面的工作，而第二方面的工作则是生产类的工作。

质量部负责测试及过程保障的工作，这个部门是支援研发部和实施部工作的，故也属于支持类的部门。

将部门分为市场类、生产类和支持类，只是其中一种的抽象方法，每个人可能会有不同的标准，遇到不同情况可能会有不同的抽象办法。以上这个仅是一个例子，你千万不要将其当成一个固定的标准。

总体来说，上述三个用类图表示的公司组织架构，所针对的公司都不是大型的公司，大型的公司可能会有分公司、子公司、事业部等等不同的划分办法，组织架构异常复杂，想用类图准确地表达出来并且能揭示其本质相当不容易。希望通过上述三个例子，能让你初步体会用类图提炼业务的优势。

上面四个练习，基本覆盖了你在前面小节学习到的类之间关系的知识。在我的经验看来，直线（关联）关系、包含关系是最常用的，泛化（继承）关系用得也比较多，而依赖关系用得不是很多。而从使用的难度来说，泛化（继承）关系是最考验人的了，很考验你发掘事物本质的能力。

类图是不是很有意思呢？下面小节将会更加有意思，但同时难度也会进一步增大，喜欢挑战的你一定是不会退缩的了！

请看下一节……

作者：张传波

创新工场创业课堂讲师

软件研发管理资深顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创办人