弄懂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本介绍UML的工具书。把它当成字典就好,查查看UML的使用标准。 可以看一下《大象》这本书。不要当成用UML怎么画图的工具,而是理解书中每个工具要解决的什么问题,以及使用的顺序。 最后,从使用角度,可以看一下《火球》,UML对于需求分析有帮助的工具。 或者,看一下《B端产品经理必修课2.0》。
以上,希望对你有帮助。
我的新书《B端产品经理必修课2.0》已经开售了。
这是对我的第一本书的全新改版,也是关于B端产品的方方面面。
查看具体内容:我的《B端产品经理必修课》升级了
推荐阅读: