UML和Java的阻抗

玄铁重剑不能诠释武术的全部，我们练到“草木竹石皆可为剑”的地步就可以了，不用管用什么工具。

最近看MDA,不用profile是很难精确建模的.
如果不拿UML模型来生成代码,似乎也不需要care这些细节吧?

据说很多JAVA大师们是很喜欢Unix下的VI编程，所以不使用UML也是可以的。

重要的是粒度
不能指望uml什么都作
只要让uml帮助你思维和交流就可以
引入新的steorotype应该就可以把
然后为这个新类型写新的模板
用新的模板生成代码
可看看architecheware得生成器
可订制的生成器正擅长处理这类问题..

>只要让uml帮助你思维和交流就可以
完全同意，可惜现在steorotype/Profile流派太多，反而造成了很难交流，这就象金庸小说：总是有试图一统武林，可惜少林派、华山派等派别太多，各自注解不一样，除非出现一个身兼数家之长的郭哥哥，可惜这只是暂时现象，而不是机制，所有一统武林最终还是理想。

立场决定了看问题的角度。

如果我是uml设计者，我是源于现实问题域的进行抽象的，理论是基于OO的，我做得这种抽象只是在逼近某一种oo开发语言实现的，这种“逼近”当然不是“等于”，肯定会存在作者所说的阻抗。

要明白uml设计者的立足点是现实的问题域，从这点出发，我们并不能分得清楚Properties vs attributes。 setter, getter其实是attributes的一种实现罢了，properties已经进了一层。

假如以后定义attributes，它在一种开发语言中只用一个关键字(或一个名称前缀)标识一下，语言内部自己实现setter,getter方法，这不就结了。

对于Services vs Operations，我想说这是两个概念，他们的理论基础不一样。service编程，它已经引入了一套新的理论，而uml是不建立在这套基础之上的，它是为oo一般理论服务的，它的分析粒度也止于此。

为了维护uml的uniform，它也尽量不会对某种开发语言（或者说实现技术）采取跟随政策。阻抗由此而产生。

youway的论述比较客观，充分说明“立场决定看问题的角度”，youway是从一个业务分析者角度来看待UML，而不是从技术角度来看待UML，非常有道理。

youway的观点迫使我再次思考了UML里面到底有哪些东西，或者哪些东西有用？UML中需求分析部分比较有价值的，但是UML没有提供关键的建模方法，因此象四色图这样可操作性的方法只能成为一种stereotype了，这样造成了一个尴尬的局面：统一了不实用。

>为了维护uml的uniform，它也尽量不会对某种开发语言（或者说实现技术）采取跟随政策。阻抗由此而产生。

如果UML只定位再业务分析这个层次，这个观点是正确的，但是如果UML试图作为一种交流工具的话，就不要忘记，技术变革会产生社会推动力的，作为一种交流工具，产生技术革命的技术往往包含革命的思想，因此，作为交流工具就要积极引入新的思想表达，否则，我们能用文言文来进行21世纪的交流工具吗？

在uml与java之间产生所谓阻抗，是因为uml的抽象程度已经不能涵盖住java等开发语言快速发展的新的实现技术了以及所产生的新理论。

uml是基于一般oo理论的图形化语言描述，java编译器原本也是基于一般oo理论去设计实现的，以至于泛化关系被两个简简单单的关键字extends, implements所涵盖，当然还有其他对象技术的实现。

所以当初在uml与java的匹配上还算不错。

随着java实现技术和理论的不断丰富，java的不同编码形式和粒度，以及命名，形成了面向模式，面向服务等分析和设计方法。标准uml是不能完全匹配这些方法的，因为新的元素和概念没有得到补充。

这也涉及到uml中modeling理论的是否只有oo理论构成的问题，能不能扩展面向模式，面向服务等理论？是不是能适应设计分析编程整个过程的需要？这些理论是否成熟？

在这个阶段，不匹配是肯定的，uml的统一是旧体制下的，而新的统一还未到来。有些东西我们还是要自己解决的。

大家也能看得到一些uml的工具提供商自己也在解决这些问题？

>大家也能看得到一些uml的工具提供商自己也在解决这些问题
是的，以Borland Together architect为例子，如果你只会画UML，没有真正掌握UML背后代表的分析学派真谛（如四色图），你就可能不会使用together，together为每个类图属性提供的stereotype多达数十种。

其他UML工具如免费的ArgoUML也有自己解决方式：
http://www.devshed.com/c/a/Practices/Design-with-ArgoUML/6/

目前UML和Java阻抗也会MDA工具实现带来阻碍，ORG的MDA标准还不彻底....

这让我又想起另外一个非主题话题，以前国内UML曾经“热门”一阵，还有什么“UML十大硬伤”，好像大家都很知晓UML，但是UML精髓：分析思想的著名流派：四色图，却很少看到人提及，到今天在google上搜索四色图，也仅仅是Jdon网站提到，可见当时国内技术流于表面之现象严重阿。

我认为这些所谓阻抗都不能成其为阻抗。首先，UML是分析设计的建模工具，其粒度不应细化到代码级别，如果想从UML模型生成代码，那为何不自己来建立一套适合自己的代码生成工具呢？其次，一个团队（甚至一个公司内部）使用UML建模，应有自己的一套规则，比如，对于一个使用SessionBean的架构，多数情况下，从EJB->EJBBean->Business的方法都是一致的，这样的情况下，我们根本不需要把这些类都在类图上表达出来。
UML是工具，是死的，但人是活的。所有工具的目的都是用来构建好的软件系统，怎么用舒服就怎么用。

明白了UML与xUML之后，或许会豁然开朗