​弄懂UML本质，才不会误入歧途

最近，一些产品经理的朋友来问我，向他们推荐一些UML的书籍。推荐的书籍自然是有，不过看书的目的却不一样。

大部分人学习UML，主要目的是更好的书写产品文档，结构化的表达产品思路，或者方便与研发人员沟通。所以，看书的目的也是为了快速学习和掌握工具。

但是，如果没有技术背景的产品经理，只是看到UML包含有流程图、用例图等工具，就认为这是产品经理的必杀技，那就误入歧途了。

所以，我们要学习UML没有问题，但是要明白UML的本质是什么？才能更好的理解这个工具。了解一个本质，可以去它的历史。

UML的本质

UML是 Unified Modeling Language的简称，中文是统一建模语言。它是一个标准，主要用于为现实世界中的任何软件系统创建面向对象的、有意义的文档模型。它为我们提供了一种开发丰富模型的方法，这些模型描述了任何软件/硬件系统的工作。

是不是还有些看不懂？不着急，我们往下看。

20世纪90年代是面向对象语言(如 c + +)发展的时代。这些面向对象的语言被用来创建复杂而引人注目的系统。

由于所开发的系统难以理解，导致了系统部署后所产生了设计和分析问题。向其他人解释这个过程是困难的。

所以，既然开发软件的过程，很难让其他人理解。于是1994年到1995年间，Rational 软件公司的出色软件工程师 Grady Booch，Ivar Jacobson 和 James Rumbaugh 发明了这个软件。直到1996年，它一直处于开发阶段。

UML 的每个发明者，即 Grady Booch、 Ivar Jacobson 和 James Rumbaugh，都设计了一些工具来减低发表研发过程的复杂性。

UML 在1997年被Object Management Group (OMG) 认可为标准。OMG自从 UML 被采用作为标准以来就负责管理它。

2005年，美国国际标准化组织认可了 UML 作为 ISO 标准。它用于各种行业，用于创建面向对象的模型。

所以，UML这是一个广义的建模语言，是一种图形化的语言，可以用来做面向对象的设计和分析。

说得再直白点，UML是用画图的方式来表现代码是怎么一步步写出来的。所以，UML中的各种工具设计的使用者是程序员。UML中的每个图，都可以帮着程序员从宏观到微观的分析需求和技术架构。所以，如果用好UML，我们看到的每一行代码，都可以对应成为UML中的工具。

另外，要关注的是，UML背后的核心理论是面向对象编程。关于面向对象编程的理论，可以百度一下，网络上有很多深入浅出的文章进行介绍。

弄懂面向对象是弄懂UML的关键。

因此，UML本身就包含了一定的复杂性。

UML对于产品经理的意义

UML既然是图像化展示如何写代码。那就为不懂技术的产品经理打开了一扇门：能够用图形化的方式，来理解程序员是如何思考的，如何编写代码的。

不是一直担忧产品经理不懂技术吗？

来学习一下UML的工具，了解UML工具的使用顺序，以及每个UML工具的使用目的和意义。而且，还不用陷入花花绿绿的代码之中，岂不是一条捷径。

通过UML，产品经理可以建立一种意识，懂技术不等于会写代码，而是经过一些分析、思考和设计的过程。这要比懂得一个技术知识点要重要。

其次，才是产品经理使用UML中的一些工具来分析需求。

UML中的哪些工具适合产品经理使用

UML被发明的时候，就是给程序员提供的工具。

所以，对于没有技术背景的产品经理来说，这里面能够让产品经理得心应手使用的工具不多。

这些工具基本就是流程图、状态机图之类的。在我的书《B端产品经理必修课2.0》中，对这些工具做了通俗易懂的简化，以方便产品经理使用，在这里不再赘述。

所以，掌握UML不是学习UML的关键，关键是通过UML了解编程的思维。

如果你想基于了解UML本质目的来学习的话，可以看以下这些书。

1. 随便找1本介绍UML的工具书。把它当成字典就好，查查看UML的使用标准。
2. 可以看一下《大象》这本书。不要当成用UML怎么画图的工具，而是理解书中每个工具要解决的什么问题，以及使用的顺序。
3. 最后，从使用角度，可以看一下《火球》，UML对于需求分析有帮助的工具。
4. 或者，看一下《B端产品经理必修课2.0》。

以上，希望对你有帮助。