>只要让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标准还不彻底....