UML是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize） 、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件。从这个定义来看，我们可以理解UML的维度主要有三个：可视化-图形的维度；文档化-文字的维度；构造-MDA的维度，很多时候我们迷信的图可以直接生成代码。

　　UML+OOAD是现在研发人员必须掌握的知识点，那学习UML的要点是什么,下面谈谈我的想法。

　　1 软件工程=过程+方法+工具，从软件工程的角度看，UML属于工具的范畴，学习UML不要为了画图而画图，应该要面对问题，解决问题的思路与方法才是关键，所以学习UML一定要在一定的过程与方法的知道下，有取舍的运用。   ICONIX是一个很有意思的过程，只用很少UML来辅助解决整个研发过程的问题，可以拿来完善敏捷开发过程。

　　2  不要迷信UML建模工具，跟很多客户讨论，大家经常谈的是我们用了什么工具，比如Rational Rose或Enterprise Architect。诚然，工欲善其事，必先利其器，但是，如果研发团队没有真正理解方法和工具，用什么好的建模软件也只是摆设，就像国内很多企业的CMMI、ISO等认证一样，起到最大的作用可能是证明公司的实力，让公司具备这样的资质，以利于项目招标罢了。所以我更认同很多时候绘制UML图表在白板上最好。

　　3  不要迷信绘制图表直接生成代码，也就是所谓的正向工程与反向工程，我接触数百家客户，从世界500强到几十人的小企业，未曾见过真正能使用类图做详细设计，然后程序员生成代码框架然后填充代码。我见过非常美的详细设计，可谓让人叹为观止，但是仅仅是摆设，程序员开发代码的时候并没有使用，分析原因当然很多，有管理的问题，人员技能与素质的问题，单单抹杀程序员的创作思维这一条罪状就可以把他打入死牢，软件首先是人件。当然企业开发的应用系统中功能可以分为业务相关与业务无关，业务无关的功能设计越详细越好，MDA我觉得也很好，因为我觉得这个应该是架构设计的范畴。对于业务相关功能的设计，实现它然后重构的敏捷设计来的更实际。

　　4 关于UML无用论的说法。一次跟客户讨论时，客户说到有一种观点认为UML无用。本人完全不认同这种观点。使用UML做研发的各种工件等同于建筑行业使用AutoCAD做设计图纸，很难想想盖一座高楼大厦没有任何图纸，一层一层向上垒。持这种说法的人应该不太关注软件质量，所以“如果建筑工程师用软件工程师的方法盖房子，第一只飞来的啄木鸟足以摧毁整个人类文明。”

　　5 关于惟UML论的说法。UML的U是Unified的意思，可能Rational三位大师当初的想法是统一软件建模。虽然使用一种工具比使用乱七八糟的工具成本更低，但是“尽信书则不如无书”，如果因为大师的话就舍弃我们习惯用的工具，就是教条了。比如谈到流程图，很多研发人员使用他来表述业务流程，非常好！我们要使用活动图代替他吗，因为要统一吗。看到一些人谈流程图与活动图使用不同点等等，实际项目与研究不同，让这些说法停留在学院里面吧，如果你已经用惯了流程图，非常好，继续用好了。

　　本来想总结一下学习UML的要点，提笔不禁兴起一堆感想，姑且下次再写了。

　　最后总结与强调一下，学习UML首先要面对问题，并且在一定的过程与方法的指导下有取舍的运用。

本站技术原创栏目文章均为中睿原创或编译，转载请注明：文章来自中睿，本站保留追究责任的权利。