UML学习体会

zhenye1986

于 2024-03-17 10:32:05 发布

阅读量985

点赞数 14

分类专栏：项目管理文章标签： uml

本文链接：https://blog.csdn.net/zhenye1986/article/details/136774661

版权

项目管理专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1. 水在前面

本来写作的水平就很一般，平时写的也少。最近看到一些文章说学习最好的方式是输出，刚好又重温了一遍UML方面的基础，所以想记录点学习心得。而且说实话这玩意平时基本不怎么用（偶尔倒是看看别人的成果），所以一直以来只有基本的认知，没有深入，这段重温刚好理清了整个UML的学习脉络，写下来以后给自己温习。

这里要敲黑板提醒，这篇水文不能让你完全掌握UML，只是用来给我自己温习用的，或者也可以作为小伙伴的学习引路，别指望能读一篇文章就学会了。

2. 关于教材

总说学习要站在巨人的肩膀上，这里给推荐一本书《UML面向对象建模与设计(第2版)》Michael Blaha, James Rumbaugh 著，(wx号：zhenyeli86 添加好友请说明技术交流，5毛党)。该书的优点有3个：

网上能下电子版，适合我这种穷人。不过老对着电脑伤眼睛，建议还是支持下作者买本实体书或者去图书馆借本翻翻(这里吐槽下某一线城市某州图书馆，明明书籍检索有，到了图书馆找不着！)。
书上的习题有答案，这是我一贯选书的习惯。这本书配了一本原书习题答案，不过我只找到英文版的《answer key to Object-Oriented Modeling and Desgin with UML , Sencond Edition》。英文的基本也能用，UML主要的习题都是画图为主。
书籍的讲授方式很适合我。该书主要是目录编排的好，看完基本上知道了UML的脉络了，而且后面还写了几张UML的这些图怎么用在项目过程中，最重要的还是习题有答案。。。。

3. 关于工具

现在网上的在线画图工具很多了，而且很多免费的就基本够用，这里推荐一个process on吧，如果要单机版的用office的 viso就好了，不过项目上一本都是标配的用公家的吧。

4. 学习心得

水了这么多该进入正题了，下面从几个方面来理清UML的脉络。

4.1. UML的作用

总的来说，UML是用来给项目上不同岗位的人交流用的，经验告诉我最大的用处是作为“技术文档”（shuai guo zheng ju）。举个栗子，产品经理给搬砖小哥讲需求，配的就是交互模型相关的图表。再做个不太恰当的比喻，UML相当于建筑专业的设计图纸。

4.2. UML有那些图

学习UML说白了就是记住UML都有那些图，然后这些图怎么构成项目的设计文档，从而把项目的内容表达清楚。那对于基本不画图或者第一次接触UML的人来说怎么才能记住这么多图和概念呢？请看下图：

整个UML其实只用三种模型，对象模型（类建模）、状态模型（状态建模）、交互模型（交互模型）。每种类型对应1种或者几种图，通过这几种图的组合就可以画出产品经理那些看着貌似很高大上的设计图纸了。

至于说每种图干嘛用的，我觉得上面的这张图已经表的的很清楚的，要细品的画可以做几道习题就比较深刻了。

4.3. 重点说说状态图和活动图

以前老是把状态图和活动图搞混，这里记录一下体会吧。

4.3.1. 状态图

状态图是描述系统的状态，例如“待机”-》“运行”-》“关机”，状态机你懂吧，就是那玩意。每本书都说状态图只能表示一个对象的状态。这是怎么理解呢？你把对象这个词理解为一种包含了不同状态的系统就行，一个系统可以有多个状态，每个状态可能是由多个子系统组合表达，每个子系统也可能由自己的状态，那么这就是所谓的“嵌套状态了”。

4.3.2. 活动图

如果只是从文字上看，活动图和状态图确实有点相似。但是，如果我告诉你活动图是用来表示“流程和算法”的，那么是不是就一切的变得特别清晰了！如果你学过编程，那么你一定知道什么是流程和算法，你一定知道流程和状态的区别在于流程里面是包含多个对象的，还包含了分支！

4.4. UML画图

原理掌握了之后就是使用了，我认为UML最让人迷惑的地方是到底什么时候会用这玩意，特别是我们写代码的，老是奇怪到底这设计图是产品画的还是SE画的，怎么感觉这两哥们的图纸跟他们日常的表现不大相符（这是我意淫的，上游的兄弟们当我胡说就行）。

其实，图不是一个人画。工作后才发现，其实项目也不是一个人干的。好多人在为一个项目付出，同样的好多人在这个UML上增加设计图。在过程中的每个阶段，所有的图都可以根据对项目的深入认知而增加进去！

在编码阶段之前的每个环节，每个岗位的人都在为这份图纸增加过自己的理解和对应环节的设计。例如在系统构思阶段，产品经理就已经画出了最原始的交互模型，甚至可能连状态模型也搞出来了一两个了。然后在以后的每个环节中，随着项目组成员对需求的设计的不断深入认知，模型不段被修改和增加。直到文档交到搬砖的手上，就是一个比较完整的成果了。当然在后续的迭代中，文档还会发生变化，甚至有些图是搬砖的画上去的。

5. 水在最后

看出来了吧，我不是画图的那个，是看图的那个。。。今年终于是从搬砖的角度把UML这玩意理顺了。记得有本书说过，当个架构师还好意思连UML都说不清楚，我这水平应该够在架构面前吹吹牛不被鄙视了吧。

其实搬过砖的都知道，文档写的再好，还不如当面说的清晰和代码写的好，文档这玩意有用但是不能只依赖文档。敏捷宣言不是说了么，面面俱到的文档不如能工作的软件。