当前课程知识点：软件工程与软件自动化 > 第三章 OO与UML > 3.6 主要UML模型图绘制技巧 > UML类图
嗨，大家好
今天我们来一起讨论UML类图
我们知道，用例图解决的是做什么的问题，就是
需求分析
进入设计阶段之后
我们的工作重心就开始解决“如何做”的问题
类图和序列图在一起就可以相对完整的刻画出一
个面向对象系统
类和类之间的关系构成了类图的基本元素
是整个面向对象系统的基础
因此，我们对类图务必要十分重视
多看优秀的设计，多练习画图，多思考，多迭代
很快就可以提高我们的面向对象设计能力
在UML中，类图表示为一个三段式的矩形框
从上到下依次是类名，属性和方法
一个类孤零零地放在类图中是没有意义的
同样，一群没有任何关系的类放在类图中也是没
有意义的
初学者在画类图的时候
往往喜欢一股脑把一个类的名字、属性和方法
全部写完之后再去画另外一个类
这种做法是错误的，反映了设计者设计思维的混
乱
要想画好类图，必须对类的职责进行合理正确的
划分
这是从“做什么”到“怎么做”转换过程当中非常核心
的一步
类的职责来源于用例，是为用例服务的
多个类的职责联合起来实现了用例所代表的用户
目标
那么怎么划分类的职责呢
要想划分类的职责，必须划分对象的职责
类和对象的关系，大家都清楚吧
一般来说，设计者仔细阅读流程图和活动图
甚至是文字描述的需求
都可以快速识别出一些主要的对象
然后对这些主要的对象画出它们的交互图
一般我们用序列图，通过序列图
一个个对象之间发送消息，协同完成用户目标
因此，序列图大家要好好使用，用的好了
类职责的划分就合理，就平衡了，有利于系统的
实现
在每次的迭代和重构过程中
不要忘了使用GRASP的那9种原则
来检验自己的职责划分是不是合理，是不是正确
如何绘制一个类图？
不仅仅是拿一个工具随手画几个矩形框
框里写几个名字那么简单
画图的过程其实是一个高速思考的过程
初学者要试着按照专家的经验来绘制类图
捋顺自己的思路，提高自己的设计水平
具体来说，就是从用例和用例描述当中
了解业务流程之后，把那些容易识别的主要对象
主要是一些名词，整理一下作为类的名字
写在一个一个独立的类的上部
这时候千万要忍住，不要写属性和方法
有时候你可能觉得这个类肯定是这个属性和方法
但我们在训练的时候
还是建议要忍住，不写
类的名字确定之后，如果从用例描述中
已经没有办法进一步地获取更多的更深入的信息
了
怎么办？开始画序列图
把这几个类之间的协作关系在序列图上画清楚
画清楚之后，就可以确定，在这么多孤零零的类
中
哪些类之间有关系，什么关系，赶紧把它们标出
来
这时候接着回去研究序列图，从中发现类之间的
职责划分
在这个过程中通过迭代，还可能发现新的类
需要把大类化成小类
类如何完成它的职责呢
就是通过方法，所以知道了职责也就知道了方法
有时候需要把一条职责分成几个方法
有对外提供服务的方法，也有仅供内部使
用的方法
这些方法需要哪些属性来配合？
于是属性也就应声而出了
这是方法驱动属性
有的时候是反过来的，是数据驱动方法
尤其是那些实体类
它的主要目的就是对数据进行封装
然后才考虑如何提供服务，这样的方法
下面我们来具体看类间关系有哪些
常用的关系有泛化，依赖和关联
随着接口编程的普及，UML也扩充了实现关系
就是类对接口的实现
大家一看就明白了，这里就不展开说了
泛化关系的语义最强，最容易理解，所以这里不
解释
语义弱一点的是依赖关系，没有你我活不了
我依赖你，这理解起来也不难
就像这个图中的window对象
只有在接到event消息之后才能激活和显示
所以我们说window对象依赖event对象
除此之外，所有的类间关系都可以归为关联关系
怎么样？简单吧
下面我们来快速的看一下泛化关系，就是子类继
承父类
子类复用了父类的结构和行为
在设计的时候，往往会设计出一个继承树
在这棵树中，树根叫基类，没有子类的类叫叶子
类
如果一个类有多个父类，这叫多继承
如果只有一个父类，就叫单继承
现代编程语言一般不建议使用多继承
多继承关系过于复杂，会有很多副作用
有的时候我们认为超出了程序员的智力水平
具有依赖关系的两个类虽然没有父类和子类那样
血浓于水的血缘关系
但也是亲密好朋友
它们可以获取对方的引用，访问对方的公共属性
和方法
在这里例子中，如果car类没有move方法
driver类的drive职责也就无法完成了
关联关系的语义最弱，为了标识这种关系，就需
要很多的修饰
为什么说关联关系语义最弱呢？
如果两个类之间存在着依赖关系或泛化关系
那么它们一定也隐含着某种关联关系
在这种情况下，描述这种关联关系已经没有意义
了
因为这时候关联关系已经被依赖关系或泛化关系
所取代
或者说所覆盖，都可以
这就是关联关系“语义最弱”的含义所在
关联关系具有方向性，它可以是单向的、双向的
或者是指向自身的
这在表达一个深度不确定的树状结构的时候就非
常适用了
除了方向之外，修饰还有名字、角色和角色重复
度
一般情况下，类间关系往往省略这个名字
这个名字经常用动名词来表示
两个类一个做主语，一个做宾语
加上中间这个动名词，就构成了一个完整的描述
加上中间这个动名词，就构成了一个完整的描述
有利于对系统的深入理解
角色是类在对方类里的标识
在编程的时候，程序员往往可以直接
把这儿的角色名当成一个属性名封装起来
角色重复度被定义为关联关系的实例的两端所连
接的对象的数目
星号代表可以有任意多个对象
聚合和组合也属于关联关系，但是有特殊的地方
这两种关系的语义比一般的关联关系要强一点
它表示一方拥有另外一方，是整体和部分的关系
聚合中部分可以独立于整体
整体不负责部分的生老病死，各过各的日子
而组合呢，整体负责部分的生老病死
整体对象销毁了，部分对象也随之销毁
既然聚合和组合这么像，设计的时候
到底应该用组合还是聚合？这要依赖于需求了
一般来说，如果部分对象是整体对象独自享用的
对其他对象没有用，这时候就可以设计成组合方
式
下面我们一起来看一个完整的类图
作为这部分的小结
首先从上往下看，动物是一个基类，这个基类依
赖于两个类，氧气和水
动物派生出了更具体的鸟类，然后进一步派生出
鸭子类
最后再次派生出唐老鸭
大家可以看出，这就构成了一个深度为4的继承树
这些类中，鸟和翅膀之间是组合关系
因为没有了鸟这个整体，翅膀这个部分也就不存
在了
而雁群和大雁之间是聚合关系，雁群散了，大雁
还活着呢
剩下的就是两个实现关系了
大雁实现了飞的接口，唐老鸭实现了讲话的接口
为什么飞翔不用继承而用接口呢？
因为这里我们不想所有继承飞翔的鸟都会飞
企鹅就不会飞，也就是说类继承会污染子类
一旦继承了，后代子类都必须拥有这个属性
而接口则比较灵活，需要的类就实现这个接口
不需要就不实现
好，UML类图今天就讨论到这里，下次再见
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么？
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
