目前国内对UML版本没有什么概念，包括我也是，UML1.1版和现在的UML1.4版本我没有感到什么不同，但在使用Rational Rose过程中仅仅也是类、关联、职责、活动、接口、use case、包、顺序、协作和状态机等等简单的应用，没有认真考虑过具体的、细节的问题。OMG正在致力推进UML2.0版本，我也深感"迷惑"。
原先在软件工程专家网上刊贴的关于UML的论述仅仅限于对UML概念的简单论述，现在一直在忙不知其然的事情，把UML的推广职责放在一边了，实在是不好意义，幸好张博士之邀，才发现UML在国内的推广还有很多的工作要做，我先初步打算把原UML的没有说明问题深入讨论下去，另外再介绍一些好的实施经验。
在这里我不再叙述UML的概念和用法，这个将在以后在软件工程网向大家介绍，在这里和大家简单聊一下UML的现实的状况和目前存在的问题。
{文章字少意浅，旨在抛砖引玉。}
1．思维上方向
人类在认识思维的发展史上存在诸多记忆符号，这是人类在认识上一次一次进步，人类的大脑因为无法把所有的逻辑一步想到位，固然采用符号记忆、推导。UML在符号标识上也是一次历史的跃进，我们在设计项目，在把业务模型设计成为领域模型的过程一次又一次在整理各个对象间的关联。所以Dugguan说，"要记住，UML只是一种符号，并不是什么方法论"。我在大学期间选修哲学时，其课程的论文就是关于符号在实现中应用的讨论，所以还颇有些领悟地方。
我在认识UML后，坚持使用Rational Rose进行领域建模，也和同事或软件设计领域上的人士进行这方面的讨论，深感Rational Rose也存在诸多不完善的地方，比如，在设计过程中没有过程跟踪，在版本UML1.4才加入。现在使用的UML2.0版本没有项目变更再设计的过程、BUG的修复等等，这样只能依靠其他的工具来弥补该工具的缺陷，我一般采用microsoft Project来对项目进行过程跟踪和资源分配。
从应用的本身来看，UML是Large enterprise applications，而我接触的是中小企业（中国还没有大型软件企业，接触大企业也难为我了），中小企业的UML应用的实际情况实在令人担忧，一是理论基础更不上，二是实际操作一团糨糊。
为什么有上面这个说法，umlchina是中国最早一家介绍UML，我也从中学得东西，但很零星，为此在软件工程网上开了UML的专栏，但文章数量也是寥寥，如此的东西如何让我们有很好的资料以学习呢？UML理论是OO的基础，无论采用什么模式来设计我的软件，UML是基础的基础，Rational 公司在此也付出大量的努力（商业目的不再讨论之列）。
大家都知道：建模是编码前的软件设计（Modeling is the designing of software applications before coding）。但对于中小软件，建模的必要性相对大软件是弱了很多，基本上无须建模，所以大部分软件开发小组喜欢"打腹稿"，即使有幸把文档写出来了，也不能按照文档上计划来执行，固然，建模的实质性受到了损害，UML在使用中岂不是一团糨糊？
实际情况如此，令人堪忧，但如此才能把如此的问题避开，首先解决理论问题和解决如何运用，能提高工作效率和管理能力的方面。
2．UML实际操作
Rose是基于UML最好的建模、设计工具，业界人士在使用的过程中也是满声赞口，没有实际应用的人，对于工具的好坏是不好评说的（既然大家都说好，我也．．．）。
去年年底，我和做电信、金融行业的人士谈起Rose的应用，大家有一致的看法，Rose确实是个好东西，但各类人士使用的目的不同，一如采用Rose面向对象的建模，有些注重业务领域的建模，有些做数据库方面的建模。我不采用Rose进行数据建模，我选择CA Erwin。
在UML之前的建模语言也是很多的，相反这些语言还在各大公司存在，加快UML的进程是件好事，但我们连之设计理论还没有完全掌握，难哉。
我并非是如此悲观看法，正视如此差距，方能找到最佳的切入点，和国际一道进行建模标准的制定（这个是我的想法）。
在UML的使用过程中，人们选用的还是Rational的产品，还是以Rose为主，在业务领域的建模是UML所擅长的，Microsoft公司的Voiso也是一个好工具，其中也包含也UML及相关的软件建模的工具，Microsoft公司东西很人性化，但在UML这一块显十分的单薄，但把Voiso作为Rose的补充是好之不过的，毕竟Microsoft的东西我们太熟悉了，另一方面也是和Word等文档编辑器易于集成。
大概在去年，有几个网友Mail来问几个关于UML设计的问题，问题涉及到工业自动化，当时我在出差，没有给出具体内容，只是大概得说一下建模的方法和过程。但事后我想，在中国各个行业快速发展的今天，技术的渗透是神速的，当时很是高兴看见UML的建模深入到工业自动化领域，之前高展先生也在制造行业采用UML之类的建模语言进行模型分析，解剖了大量的事例，并且还自行开发了建模工具，实在是难得。
再看上面对国内建模现象的评判出现的悲观情况，现在看来只是一个过渡期，但缩短这个过渡期是我们应该考虑的事情（兄弟们加强呀！）。
我在年初的时候参加公司的几次招聘工作，有很多的求职者在询问公司内有没培训，当时我的回答是我们的公司一直在培训，因为我认为培训存在于工作过程的中，所以采用UML建模与否，或采用UML建模的过程中有那些实际操作都将我们推向学习UML的风口。
3．建模的必要性
模型是软件开发之根本，无论软件之大小、涉及的范围，还是建模的本身都是系统化认识所开发软件的一个初步的途径。在需求分析的当儿，我们和客户一边喝茶一边聊天的时候，有没有在心里构架系统，是的，那个时候我们已经在做了，系统的模型在喝茶的同时渐显在我们的面前，这是一个初步的模型，随着工作的开展和时间推移，基本需求就是把一个大的模型的模型存放你的方案里，我在很多的时候叫系统的架构。
在现在软件开发的过程中，其中必须经历的几个过程是需求分析、系统设计、初步实现、系统实现、系统运行、系统维护。在这几个阶段，迭代式的开发模式让我们每个阶段都经历一次系统建模的洗礼，现在的Rational公司的RUP在系统的开发过程中也约束我们性情的自由发展（软件开发必须遵循某中模式，而不是我们在体现高尚的情操）。
原先的系统建模的形式是初步，不完善的，为什么？原因如此：系统建模是初步阶段的，随着系统实施向前推进，系统模型必须随之改变，但建模没有跟踪过程的过程，但RUP提供一个合理的机制-迭代，我们解决系统级建模的所有问题。
迭代式是开发过程的描述，实质就是在各个阶段对模型的描述更新，重新认识系统，并把握系统发展趋向，从而有效地控制开发和系统的架构。
当需求分析进行到一个合理化的阶段，系统模型就出现了，但是目前几乎所有的企业都在"多快好省"开发系统，这是一个大忌，有时需求必须在一定的阶段才会暴露出来，所以急于求成不是个开发系统的方法。
耐心、合理、系统建模才是开发软件之路。
UML给我们一个系统的标准（关于标准的问题，我在软件工程网有专门文章论述），标准是规范操作、约束行为的准则。有此，我们就没有必要在开发软件之时手忙脚乱了。
企业合理化建模是有效控制软件开发的进程，保证软件质量的基础。是不是所有的企业都在关心这件事？是不是所有企业都是有效的、自始至终贯彻这件事？
[下一页]
4、采用UML建模的过程
前日给公司内部员工培训软件开发过程，有人说这个我们在学校都是学习过的，我是知道，计算机专业毕业的学生如果没有学习过软件工程那才是令我吃惊的事，但他们告诉我他们在学校学习那阶段并不能结合实际来分析系统，但（我）如此一分析，哦，原来建模的过程是如此的简单（这个"哦"让我感到我的三次两个小时的培训没有白费）。
我既然知道UML的好处，我在培训的过程中，自然采用UML的建模方法，至少是UML设计的理念，从业务模型到应用程序(具体分析我正在着手来描述，将不久后在
WWW.51CMM.COM.com网上与大家见面)，该过程是一个基本定型的过程。
我从个人角度来考察业界对UML的态度有些偏颇，偏颇点在那里？在思想上，人们在学习UML或其他建模语言的时候，陷入一个思维的定态，就是用之而用之，其实不然。具体是为提高工作的效率而学习使用工具的，但不为使用工具而去学习使用工具。这个观点也澄清我的"我不建议先学Rose，再学UML"观点，我不排除先学习Rose可能给学UML带来的好处，但概念的误区我不建议去进入。
"统一软件开发过程"是UML软件开发的具体实施，说明UML的益处，就要分析RUP(Rational Unified Process),它为软件开发的小组指出了如何正确使用UML,采用UML建模的过程不同我们在国内使用各个阶段的文档（比如：需求文档、概要设计文档或详细设计文档），若采用UML建模，然以文字说明之，我总觉得多做了些事情，但这样的事情我一直在多做着。
唯一的原因，是我们的开发小组对UML的表示方法不太理解，就如我一样，可以照葫芦画瓢的，但离开葫芦，瓢就不知道如何来画，我在这里表示，我愿意和大家一道把UML这个交流工具学会。
单独的UML是没有用的，就如我告诉你UML各类的图，那么你如何理解该类的图在什么地方使用、如何使用？
一个贯穿整个系统的线索不存在，如何抛开UML的语言的本身，进入UML实质性的使用空间，我们在思想仅仅存在一件事，就是以UML的方法、思路、分析过程，沿着系统的框架逐步细化以达到解剖系统的目的。
若解剖系统的过程，在什么样环节采用什么样的"刀"技，什么时候使用多大的力度，若能够做到游刃有余，还会在系统的分析、设计、实现上存在困难？这些东西在什么地方可以学习，兴许RUP可以做你的向导。
5、UML补充
UML并不是万能的，固然存在些缺憾。
在软件的设计过程中，应该存在一个项目和另外一个项目雷同的地方，那么UML在两个项目如何处理，过程是很重要，若有这样的一个过程自然会有好的结果，但这样好的过程给开发厂商带来的成本太大，甚至是巨大，无法用承受的。技术人员在一次一次精化系统的架构、分析系统模型、定义各个部件间的接口，枯燥！
枯燥！一定是，在我认识的软件开发人员，每个人都"喜欢"加班，这是工作，为什么？
智能的设计是我们需要。
UML没有智能库可以识别简单比如接口定义、类的定义，建立相关的模板，这样也是中间件技术发展的一个入口点。
UML捆绑中间件进行程序的设计，当设计过程到部件或子系统的时候，下面的工作可以有UML的模板供我们选择，那样我们开发者进行概要的分析就可以得出程序本身？
随着社会分工进一步细化，人们关心仅仅是一段，从程序开发者的角度来说，程序开发仅仅是系统设计的一步，比如，A公司仅仅做用例模型、B公司仅仅分析用例模型到设计模型，C…这样各级的承包将如何实施？是否会出现这类情况，按合同设计(Design By Contract)是否是这类情况。
在Jacobson 访问中国之际，《程序员》访问了这位UML专家，他强调"设计模式"对以后建模的影响，同时也提及AOP的前景，他说："当你编完用例之后，你需要将用例变成系统中的若干个对象，今后，我们也许可以借助AOP直接对用例编程，不是对类编程，而是对用例进行编程"。
他的想法，我在去年曾经提出过，没有他这样深刻，可是在BBS上被骂的"体无完肤"。有些事情只要你感想，就有可能将做出来。
UML的发展也可谓任重而道远，国内的使用能力我们都希望努力跟上。
6.总结
但愿这次主题网友在骂我前能仔细思量一下自己和你周围的现状……
