产品经理的思考利器——UML
PMCAFF
共 6422字,需浏览 13分钟
·
2021-12-23 03:01
本文由作者 罗文正雄 发布于社区
看到这个标题,产品的朋友们大概率会一头雾水,为什么一个产品要学这么“奇怪”的东西?产品把产品本职工作做好就行了吧?
且听我快速道来~
在我之前的产品经历里,经常会遇到一个场景,在我拆解(或调研)某个业务系统时,无法梳理出一个系统层面清晰的脉络,思考出整个业务和系统架构的融合方式,即使后期我梳理清楚了,也是一个“大力出奇迹”的方式,一步一步硬推出来的。
但这种蛮力的方式不是长久之计,如果我以后换了领域或者行业怎么办?我的业务线调整裁掉了该怎么办?都要硬啃吗?显然不行的
在工作中,我们接触新领域/产品的时候,都会“开头难”,这个难在于没有在这个新领域下有历史经验,以致于用最笨的方法去调研,验证,学习,然后积累出一点点优势,慢慢滚雪球,形成加速。但如果又换一个新领域,我们很大概率还依赖这种行为方式,这就会造成认知的低效率。
我其实一直想找到一个比较底层的方法工具,便于快速切换领域和习得经验。
我先后学习与应用了一些思考框架,如
用户体验要素五层框架(战略层/范围层/结构层/框/框架层/表现层)这套思考方式 需求蛋模型(一个集合里画一条线,两侧分别是自身的功能与用户的需求) 用户故事地图(按故事线去梳理一些用户完整的story,然后快速开发) 商业模式画布(一个梳理商业模式的框架图,可用来自己做商业规划,也可以用来调研分析竞品,在执行上顺序会略有不同)
01
UML到底是个什么?
它的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用,提出了一套IT专业人员期待多年的统一标准建模符号,支持面向对象的技术。
通过使用UML,这些人员能够阅读和交流系统架构和设计规划。(可以理解为想实现在不同世界的研发沟通时,达到车同轨书同文的效果)
02
为什么要学UML?我能得到什么?
好处1 思维方式的扩展
好处2 识别“领域知识”,跨领域沟通与学习能力的提升
当梳理出来之后,再去询问客户每个「类」的作用,客户会告诉你「类」的职责,这样就能快速了解该领域的基础逻辑。
好处3 完全是私货 对思考的习惯有很大影响
03
UML都包含哪些内容,如何快速上手?
主要可分为如下图两大类:
2、行为元素,图例右半部分,自上而下为状态图,时序图,协作图,活动图
结构元素
结构元素-类图
对象是类的实例,比如你和我都是“人”这个「类」的实例,对象具有自身的结构,属性和操作。
接触过数据库的同学对这个定义比较熟悉,基本等同于ER的思考逻辑
使用直线表示
听起来有点套娃,但这个就是核心的思考方式了,可以向上抽象思考,也可以向下实例思考
抽象,继承,泛化
这三个放到一块讲,是他们的联系可放到一块去思考,在设计游戏时,「计时器类」是从「投球计时类」和「游戏计时类」抽象出来的,对应的子类用空心实线箭头指向被继承的类,这个箭头就是泛化关系,代表“is a kind of……”
接口和实现
接口跟封装可以一起介绍,可以理解为你在使用冰箱的时候,不需要知道冰箱怎么制冷的。只需要插电和开关冰箱门就好了。冰箱把制冷的细节都封装在了里面,给你留下了开关和插电的接口
冰箱这个「类」对应的他的开关接口,这之间的关系就是实现,使用空心虚线箭头标识
用虚线单箭头表示,一个类使用了另一个类,比如在设计报表类系统时,会存在类似的关系。“展示报表”的功能,使用了“报表”这个类,有一个前置的逻辑,形成了依赖关系
这其中有点形似与混合物 与 化合物的区别。
聚集,用空心菱形剪头,从部分指向整体,一种混合物的关系
组成,用实心菱形剪头,代表强聚集关系,类似化合物的关系,桌子由桌面和桌腿组成。当然这只是为了没接触的同学好理解,如果有ETC精请克制自己不要自动抬杠……
结构元素-用例图
小人儿就是参与者
气泡就是用例
二者之间使用依赖线连接, 上面可以标记<< include>> 或 << extend>>
用例图只用来标识参与者和用例的关系,并不代表先后顺序
·发起用例的参与者
·用例的假设条件
·用例的前置条件
·场景中的步骤
·场景完成后的后置条件
·从用例中获益的参与者
行为元素
行为元素-状态图(状态机图)
行为元素-时序图
行为元素-活动图
04
实战应用
拆解与理解saleforce
此时应用UML不是还原到如何实现,而是为了理解它是怎么设计的。通过demo很难有机会能接触到更深层的实现细节
应用到工作
高频的疑问解答
我的个人建议是,如果自身喜欢这方面的思考,可以凭兴趣去学;
如果是B端从业且想继续发展的业务产品,建议去学,学了以后会有如虎添翼的功效,不过学习需要时间,建议收藏,或者转发给小号后续常看,我平时看到东西也这么干哈哈,最好能买书学,更系统
跟研发同事交流过,他们说UML其实就跟JAVA编程过程中的思考很接近,不断抽象和建模,平时也会用到。
数据库建模与UML有一定的联系,数据库建模的过程是逻辑层到物理层的逐层过程,都是构造模型,但侧重点不一样,数据库建模侧重数据层面逻辑效率,模型可用性等等。
除了上面的那些基本功能点以外,使用UML的本质目的就是为了多方理解,尽管UML有一些法则,也不要被禁锢,能达到沟通顺畅无歧义的目的,就足够了
·starUML。win/mac平台都有,win的平台有个版本很复古,但是功能很完善。mac有starUML4.0的版本,颜值很高,但是感觉画起来没win的好用。大家可以百度搜下。
·Visio。可以画的图很多,包含了UML的基础图例,不过看个人习惯,我Visio和starUML都用,Visio常用来画流程
·其他有用的也可以推荐下,工具嘛,趁手就行
·UML基础、案例与应用(入门)
·大象UML(进阶)
·大话设计模式(感兴趣可以看)
·系统架构(值得反复长期啃,我确实还没看完,太大了,不过是本神书)
另外其他的书,可以白嫖微信读书无限卡,香滴很!
结语
👇欢迎关注:
评论