uml|产品经理的思考利器——UML(7000字长文)( 三 )


UML都包含哪些内容 , 如何快速上手?引了这么多 , 直接看UML有啥东西吧!
主要可分为如下图两大类:
1、结构元素 , 图例左半部分 , 自上而下为类图 , 接口 , 用例图 , 关系 , 分组 , 注释
2、行为元素 , 图例右半部分 , 自上而下为状态图 , 时序图 , 协作图 , 活动图
可以理解为这就是咱们现实世界的粗暴分解 , 结构和过程组成了世界上的一切 , 形成了时空


再奉上一张网上超级经典的图 , UML拆解的样例 , 这里基本用上了UML中高频使用的图例类型 , 请保存好 , 后面会持续用到
那么 , 产品同学要掌握的图有哪些?结构元素结构元素-类图类 , 是一类或者一组具有类似属性和共同行为的事物 , 映射到现实中 , 可参考我上面的那个黄颜色的图
类图(Class Diagram)是面向对象系统建模中最常用和最重要的图 , 是定义其它图的基础 , 主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型
类图描述一个类的属性和操作 , 以及对系统的约束 。 它们是唯一的 , 可以直接映射到面向对象的语言的 UML图 。 请看详解
「类」的实例 , 叫做「对象」

类和类之间 , 也会存在相互关系 , 这个关系也有专门的标识方式 , 这里要先引入“面向对象”的一些相关概念了 , 如下图
面向对象的思考方式 , 是以开发出能够反映出现实世界某个特定片段为目标的 , 或者叫建模 。
对象是类的实例 , 比如你和我都是“人”这个「类」的实例 , 对象具有自身的结构 , 属性和操作 。
比如抽象 , 是过滤掉对象的一部分属性 , 保留解决问题所够用的属性和操作 , 因为现实生活中 , 解决问题不一定需要全部的信息
再就是继承 , 我们的电冰箱 , 电烤箱可以看成单独的「类」 , 都是电器这个「类」下的子类 , 继承了电器的“开”与“关” , 但冰箱有冷冻功能 , 烤箱有加热功能 。 对应的 , 电器这个「类」也是电冰箱电烤箱的「超类」
其他的可以看图 , 要解释下本图不是UML全部的内容 , 但足够本文章讲和使用了

好了 , 终于可以讲正题了!

「类」之间存在的关系 , 有如图几种 , 我们详细用图片展示
关联接触过数据库的同学对这个定义比较熟悉 , 基本等同于ER的思考逻辑使用直线表示就像「类」和「对象」的层级关系 , 「类」和「类」之间的“关联”关系 , 也是一个「类」 , 且这个「关联类」对应的「对象」叫做「链」 。
听起来有点套娃 , 但这个就是核心的思考方式了 , 可以向上抽象思考 , 也可以向下实例思考


关联讲完了 , 咱们来讲抽象 , 继承 , 泛化这三个放到一块讲 , 是他们的联系可放到一块去思考 , 在设计游戏时 , 「计时器类」是从「投球计时类」和「游戏计时类」抽象出来的 , 对应的子类用空心实线箭头指向被继承的类 , 这个箭头就是泛化关系 , 代表“is a kind of……”
好好琢磨下哈 , 然后咱们继续介绍下
接口和实现
接口跟封装可以一起介绍 , 可以理解为你在使用冰箱的时候 , 不需要知道冰箱怎么制冷的 。 只需要插电和开关冰箱门就好了 。 冰箱把制冷的细节都封装在了里面 , 给你留下了开关和插电的接口
冰箱这个「类」对应的他的开关接口 , 这之间的关系就是实现 , 使用空心虚线箭头标识


依赖用虚线单箭头表示 , 一个类使用了另一个类 , 比如在设计报表类系统时 , 会存在类似的关系 。 “展示报表”的功能 , 使用了“报表”这个类 , 有一个前置的逻辑 , 形成了依赖关系最后就是类图里的最后一块