聊聊UML静态图-类图
Posted 与小婧同行
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了聊聊UML静态图-类图相关的知识，希望对你有一定的参考价值。
上一篇，我们聊到了对象图，聊了下什么是对象。
今天我们来聊聊一个挺重要的图——“类图”。
说明：因为类图涉及到实现层的内容，我这里主要是作为BA和产品的角色来聊聊类图，如果想要深入研究实现层类图，请移步。
顾名思义，类图中的主要元素就是类。
除了类之外，类图还包括：类名、属性和操作、关系、多重性。
看着有点复杂，但是我觉得对于我们做BA和产品的人来说，掌握类名、关系和多重性就可以了。属性和操作大都涉及到系统设计的部分，所以大致做一个了解，理解不了也没啥问题。
在上面那张图上，我们可以看到，每个类被一个方框框起来，这个方框一般会分成三个部分的内容：类名、属性、操作。
而类与类之间的关系通过不同的连线进行表示，在连线上可以标注“多重性”。
是不是有点晕？
那我们就逐一进行解释吧！
在方框框最上面一行的就是类名。
我们需要给每个类起个名字，在不同的层次上，类的名字可以不一样。
关于层级，之前我们在的文中提到，从现实世界到虚拟世界，其实不是一蹴而就的。
在概念层，类名更加贴近业务描述；而在实现层，类名更加贴近数据库及代码实现。
对于产品和BA来说，不怎么关注这个部分，因为这个涉及到实现的问题了。
我们主要是对业务进行分析，所以我在画类的时候基本上都只是写类名，标识出是哪个类。
至于属性和操作，我基本上最多会写关键属性。
类之间的关系是我们画类图的一个非常关键的点。
如果不建立类之间的关系，我们就仿佛只有乐高的基础块，却无法构建城堡。
类之间的关系也比较多，包括：继承（Inheritance），关联关系（Association），聚合关系 （Aggregation），复合关系（Composition），依赖关系（Dependency）,实现关系(Realization/Implementation)。
其中，聚合关系（Aggregation），复合关系（Composition）属于关联关系（Association）。
每种关系有不同的箭头表示，我找了一张网上的图，这张图比较齐全、清楚。
继承关系
表示为类与类之间的继承关系，接口与接口之间的继承，类对接口的实现关系。
表示方法： 用一个空心箭头+实线，箭头指向父类。
关联关系
类与类之间的联接。
表示方法：用 实线+箭头， 箭头指向被使用的类。有的时候我们也用直线表示。
聚合关系
是关联关系的一种，是强的关联关系。
聚合关系是整体和个体的关系。
关联关系的两个类处于同一层次上，而聚合关系两个类处于不同的层次，一个是整体，一个是部分。
表示方法：空心菱形+实线+箭头，箭头指向部分。
复合关系
是关联关系的一种，是比聚合关系强的关系。
它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期，合成关系不能共享。
表示方法：实心菱形+实线+箭头。
依赖关系
是类与类之间的连接，表示一个类依赖于另一个类的定义。
例如如果A依赖于B，则B体现为局部变量，方法的参数、或静态方法的调用。
表示方法：虚线+箭头 箭头指向被依赖的一方，也就是指向局部变量。
实现关系
一般用于表示接口实现。
表示方法：虚线+空心箭头，箭头指向实现的对象。
晕不晕？
我们简化处理一下，因为BA和产品其实不用考虑太多的实现的问题，所以我们并不需要对所有的关系都了若指掌。
根据二八原则，我们只用掌握最主要的1~2种关系即可。
其实吧，我觉得这么多的关系，我这么多年也差不多只用到了最常用的两种。
其他的也只是在程序猿做详设的时候偶尔看见。
这两种就是：继承和关联。
这个关系其实在讲用例图的时候提到过了。
在类图里，使用方法是一样的。
一般来说，比较常用的方法是：在描述一个基础类后，其他的类都是继承了这个基础类的属性和操作。
打个比方，我们可以抽象一个基础类拥有：ID和Name。因为大部分的类都有ID和Name，所以其他类在描述的时候就可以直接继承这个基础类，而不用每个都描述一遍ID和Name的属性。
如果不强调“聚合”还是“复合”，可以简单的用直线或者箭头来描述两个类之间是有关系的。
比如描述用户和订单的关系，订单和商品的关系。
而聚合和复合两者的关系往往会让人混淆。
其实说白了，聚合和复合都是一种整体与部分的关系，区别在于离开了整体，部分是否可以独立存在。
聚合：部门是整体，人是部分，部门就算不存在了，人还是存在的。
复合：母公司是整体，分公司是部分，母公司不存在了，分公司也不再存在。
我第一次看到多重性这个词，我就很无语，完全理解不能。
但是用多了，也就习惯了。
抛开这个翻译过来的词，多重性是我用的比较多的。
从我作为BA的角度来看，我画类图主要使用了标明类与类之间的关系，以及具体的多重性。
其实所谓的多重性就是标明对象与对象之间是多对多，还是1对多，还是多对多，还是巴拉巴拉对拉巴拉巴的关系。
这里有隐含的业务规则，所以作为BA和产品必须好好的掌握。
在你描述，一个订单必须至少包含一件商品的时候，其实你就是在描述多重性了。
我在网上找了个表，挺清楚的。
| 表示方式 | 多重性说明 |
| 1..1或者1 | 表示另一个类的一个对象只与该类的一个对象有关系 |
| 0..* | 表示另一个类的一个对象与该类的零个或多个对象有关系 |
| 1..* | 表示另一个类的一个对象与该类的一个或多个对象有关系 |
| 0..1 | 表示另一个类的一个对象没有或只与该类的一个对象有关系 |
| m..n | 表示另一个类的一个对象与该类最少m，最多n个对象有关系 (m≤n) |
由此可见，其实类图的阅读是非常重要的。
上面这个例子讲的其实是界面上可以有多少个按钮。
这里有两个类：界面、按钮。
之间是简单的关联关系：界面有按钮。
多重性就是标注在上面的数字，这个意思就是，一个界面上可以没有按钮，也可以有很多按钮；而一个按钮只能在一个界面上。
我们在制定很多规则的时候都可以使用多重性，再比如：每个读者证最多只能借4本书，每本书只能同时被一个人借。
在聊到类名的时候，我说到设计的三个层级。
类图的设计其实是遵循这三个层级的，而前两个层级是BA和产品主导，最后一个层级才是由技术人员主导。
这个层级的类图描述的是现实世界中问题域的概念理解，类图中表达的类与现实世界的问题域有着明显的对应关系。
在概念层，类图着重于对问题域的概念化理解，而不是实现。
因此，类名通常都是问题域中实际事物的名称。
——《Thinking in UML》
基本上我在进行业务调研和访谈后，如果发现其中有一些对象之间存在一些业务联系，那我在整理访谈结果的时候，肯定会画一张类图，后面找机会再和客户做进一步的确认。
所以，概念层类图是可以拿给客户进行解释的。
我们在需求分析和解决方案设计的时候，其实很强调逻辑性。
类图分析可以帮助我们寻找对象之间的逻辑性，防止一些前后矛盾的情况发生。
而基本上你在做用例图的时候，可以同时来做概念层的类图，两者是相关的。
因为每个Actor可以作为一个对象，而每个use case的主体也可以作为对象。
在这个层次的类图考察的是类的接口而不是实现，类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述。
说明层类图是搭建在现实世界和最终实现之间的一座桥梁。
——《Thinking in UML》
简单而言，在这个层级你需要考虑类还会与其他哪些类打交道，也就是我们说的接口。
但是这里并不会涉及到如何实现这些接口，是用什么语言进行编码的。
而是用业务的描述方式去描述实现。
这个部分很多时候是SA去做的，但是如果BA有兴趣我觉得可以多涉及一些，这样对于未来实现的部分可以更有信心。
这个层次的类图可以直接映射到代码，可以视为伪代码。
我们只要能大致看懂就好了，因为这里涉及到很多编程语言、数据库设计、设计规范等等。
其实在写这个部分的时候我和纠结，也咨询了不少小伙伴。
因为我在《Thinking in UML》里看到这个说法，但是在其他的书里，包括UML 2.5的官方规范中都没有看到类似的内容。
他在《Thinking in UML》里面特别提出了“分析类”和“设计类”。
而“分析类”包括三种：分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)。
“设计类”就是我们开篇看到的那个方框框，里面有类名、属性和操作。
我的疑惑是“分析类”并未在UML的标准中出现，而谭老师提到的这三种类，其实是作为“鲁棒图”的主要元素。
然鹅，鲁棒图并没有纳入UML的标准图中。
想了一想，我觉得我大概理解谭老师的用意了。
其实谭老师是想用鲁棒分析法去进行类分析，在经历了概念层类建模和说明层类建模后，最终可以得到设计类。
而在概念层，其实我们只会用到实体类，也就是业务实体。
到了说明层，我们还会使用到控制类和边界类。
如果大家对这个部分感兴趣的话，可以去百度一下“鲁棒分析法”。
我也在网上找了一段资料描述这三个“分析类”的：
(1) 实体类：实体类对应系统需求中的每个实体，它们通常需要保存在永久存储体中，一般使用数据库表或文件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。实体类来源于需求说明中的名词，如学生、商品等。
(2) 控制类：控制类用于体现应用程序的执行逻辑，提供相应的业务操作，将控制类抽象出来可以降低界面和数据库之间的耦合度。控制类一般是由动宾结构的短语（动词+名词）转化来的名词，如增加商品对应有一个商品增加类，注册对应有一个用户注册类等
(3) 边界类：边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类，如对话框、窗口、菜单等。
在聊完类图后，我们下一篇简单的聊一下包图。
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
以上是关于聊聊UML静态图-类图的主要内容，如果未能解决你的问题，请参考以下文章