程序员眼中的UML

程序员眼中的UML

UML1997年诞生以来,受到无数厂商、组织、专家学者的追捧和拥护,短短几年时间,便有一统天下之势。提起建模语言,舍UML其谁?

UML相关标准

OMG组织作为影响力最大的面向对象技术的机构,早早便将UML收入囊中,力捧其为标准建模语言。OMGCORBA取得成功之后,最大的着力点便是MDA架构,而MDA架构的四大标准UMLMOFXMICWM中,围绕着UML的技术便有三种:UML本身自不必说,版本已经到了2.0MOF作为“建模语言的语言”,似乎就是为UML量身定做的,虽说MOF有能力创建出与UML并驾齐驱的建模语言,但是似乎没有看到谁这么干,大家只是在努力的发展UML的“方言”,例如UML Profile for CORBAUML Profile for EJB等等;XMI是“模型的标准存储交换格式”,为了解决不同的建模工具创建的模型不能互用的问题,OMG创建了XMI作为模型的存储交换标准。这样一来,UML工具更加可以大行其道,使用不同的建模工具创建的UML模型可以互相交流,只要它们都基于XMI

UML相关工具

工具的多寡与优劣可以看出某个技术的受欢迎程度,在建模工具中,不说100%,大概也有90%支持了UML语言。最出名的UML工具Rational Rose,被IBM收购了;Eclipse下面的UML工具EclipseUML让开发它的小公司Omondo也出名了;国内也有一个UML工具,听说效果也不错,就是楚凡科技的Trufun Plato 2005。至于其他国际上有点名气的UML工具,更是不胜枚举,几乎有点软件实力的国家,都有自己的UML工具。

当然,UML不仅仅出现在专用的UML工具中,它也频繁出现在最新的各种开发环境中。例如编程开发环境JBuilder,具有将代码转换为UML类图的功能;Together就更进一步,直接实现了代码和类图的同步转换;Eclipse作为最优秀的开放式开发平台,拥有众多的UML相关插件,除了前面提到的EclipseUML,比较有名的还有EMFUML2

UMLMDA出现之后,在OMG的概念中,成为了MDA的一个子集(虽然UML的名气远远大于MDA)。因此众多的MDA工具中,几乎都少不了UML功能。我认为很多MDA工具就是从UML工具直接改过来的。

UML使用现状

照理说来,如火如荼的标准和工具应该催生出如火如荼的应用才对,可是UML的使用状况实在不尽如人意。无论是身边的还是网络上的朋友,在项目中使用UML的都是凤毛麟角,即便使用了UML,也是在很小的范围内,完全没有发挥出1%的功效。现在总结一下目前我所知道的UML使用现状:

l         读代码时,用UML工具进行逆向工程,可以清晰的观察代码结构,方便理解代码。

l         写代码时,由于开发平台可以自动生成UML类图,因此有时观察UML类图得到比较清晰的代码结构。例如Together或者JBuilder等工具。当然,如果没有自动生成的UML图,大部分人也不会寻找其他工具去生成UML类图的。

l         撰写科技论文时,使用UML来表达系统架构或者系统流程等。

l         部分对UML非常熟悉的程序员,在开始写代码时,先画UML类图,然后利用工具生成代码,最后对代码进行扩展。

从上面的使用现状可以看出,很多人把UML当成一种可有可无的技术。即使使用了UML,也只是围绕着UML中的类图,其他的UML图都抛到一边去了。造成这种状况的原因,一方面固然是因为国内的正规大型软件项目比较少,软件工程技术起步很晚;另一方面是由于国内不管是架构师、系统分析员、软件工程师、程序员、测试人员等等实质上都是程序员而已,很多人是赶着鸭子上架成了架构师或者系统分析员的。这种状况下,软件工程的概念难以深入人心,UML更加成了一个国内项目的鸡肋。

看看国外的架构师、UML专家们,往往都是满脸大胡子,在计算机领域中浸淫了340年;而中国最古老的程序员,也只有十几年经验,除去在黑暗中摸索的几年,有十年以上开发经验的程序员少之又少。不经历几个大型项目,要使用软件工程技术是不可能的,也是不能起到什么效果的。因此,有人堂而皇之的撰文“UML的三大硬伤”,将UML驳斥得一无是处。高喊口号打倒某东西是很容易的,关键是打倒了UML何以取而代之?

程序员眼中的UML

既然国内90%以上的软件开发人员都是程序员,那么程序员眼中的UML到底应该是什么样子的呢?我很期望有一本好书能够让程序员们快速的掌握自己所需的UML知识,遗憾的是目前还没有看到这样的一本书。无论是“三友”的UML经典教材还是国内的一些“xx天精通UML”都不符合这样的要求。没有一本是“有中国特色的UML教材――一本写给程序员的UML入门书”。

作为一个程序员,我很了解其他同僚的心理,如果拿到一本书,翻了一个小时还没有找到可以runHelloWorld90%的人会大叫一声“去nmd”,然后把书扔进废纸堆。不能怪我们急功近利,在这个技术术语满天飞,连底层平台都动荡不安的年代,谁还有时间和兴趣看一些与自己无关的东西呢?

我很能想象一个程序员,好不容易空出时间来看看最近很热的UML技术,当他拿到一本UML入门以后,开始寻找对自己有用的东西。在开始的一个小时,满篇都是需求分析,use case,甚至书的作者还在饶有兴趣的介绍use case有六种译法:用例、用况、用案……对不起,老子一百年都没做过需求分析了,也不想知道这个狗屁的use case到底叫什么。于是开始后悔在china-pub上又白花了这么多银子。

还有些书上信誓旦旦的说“学好UML,走遍天下都不怕”,如果你做需求分析,你可以用UML和客户交流;如果你做系统分析员,你可以用UML设计系统;如果你做程序员,你可以用UML生成程序;如果你做测试员,你可以基于UML设计测试用例。而实际情况是什么呢?国内的客户有几个懂UML?懂UML的人差不多自己都可以把软件写出来了,还需要请你做需求分析么?别说客户了,上次听同学说和北京某大科研所的工程师们交流,无意中说起了UML,在场的竟然只有一个稍微了解,而且坚持认为那是一种画图工具(那位仁兄其实也没错,Visio不就是一个画图工具么)。

虽然状况如此不堪,但是UML确实是一个很优秀的“交流语言”、“代码生成工具”和“系统设计工具”。让我们擦干身上的献血,掩埋战友的尸体,睁大迷蒙的双眼来看清UML对程序员的作用。UML有九种图,作用各自不同,基本上涵盖了软件工程的各个方面,很多人就是不堪于忍受知识不足的困惑与“侮辱”(很多程序员认为一种技术自己看不懂就是对自己的侮辱),从而放弃了整片UML森林。他们怕的不是在UML这棵树上吊死,而是怕在UML森林里面迷路。但是我想说,知识学习的过程就是去芜存精,找出对自己有用的东西,然后掌握之。对于程序员来说,UML的价值就体现在三个方面:

一、UML是最好的交流语言,无论是与其他程序员交流,还是与领域专家、测试员或者用户交流。原因只有一点,UML是标准的,就像英语一样,无论多么该死,大家还是忙着把自己的论文改成英文的。当然,在小的领域可能有更好的交流方言,但是在大而长远的交流中,使用标准的交流语言是稳妥的。

二、UML是很好的代码生成工具,其实代码生成功能并不是由UML语言和规范提供的,而是由UML工具提供的,而且不同的UML工具提供的代码生成功能还不尽相同。例如Rose提供简单的代码框架生成,而Eclipse插件EMF可以生成功能丰富,提供了各种设计模式的代码包。无论如何,如果程序员可以从UML入手来写程序,比直接敲代码要高级那么一点点。从文档、版本控制、维护、测试等各方面来说,画UML类图比直接写代码都要高那么一点点。

三、UML是很好的系统设计工具。对于程序员来说,很少用到“设计”这个词,大部分时候我们都是在“编写”或者“实现”。但是勿庸置疑,程序员的许多工作中还是需要“设计”的。包和组件之间的依赖关系、复杂操作的流程、对象之间的关联和状态、程序的部署等等,都经常是程序员的工作。那么上面的四种情况可以用UML的组件图、序列图、对象图和部署图来设计。虽然,不同的程序员有不同的设计方法或者设计图例,不过,UML是标准的。不要忽视标准的力量,标准的东西意味着在全世界范围内都有可能会被看懂,不标准的东西可能出了你的办公室就没人能够清晰、准确的理解了。

后记

Blog好久没有更新,因为最近一直忙于一些俗物,于是想写点清高的东西。但是写完之后再看,好像也不怎么清高,反而更俗了。

前段时间写论文时,需要用到UML2.0的类图元模型,在UML2.0的规范中寻觅了好久,发现类图元模型已经被拆分到三个包里面了,因为UML2.0的规范实在是太大太繁琐了。于是有感于UML之博大精深,说好听是博大精深,难听点就是乱七八糟。不过OMG历来如此,当初的CORBA如果更简约一点,也许J2EE根本就没有立足之地。

感慨之后就是想把UML中对自己有用的部分整理出来,在整理之前免不了到处翻资料,这篇文档就是翻资料的一些感触了。希望能够将UML的有用部分都整理出来,形成一个系列的文档。

你可能感兴趣的:(程序员眼中的UML)