如果不拿UML模型来生成代码,似乎也不需要care这些细节吧?
不能指望uml什么都作
只要让uml帮助你思维和交流就可以
引入新的steorotype应该就可以把
然后为这个新类型写新的模板
用新的模板生成代码
可看看architecheware得生成器
可订制的生成器正擅长处理这类问题..
完全同意，可惜现在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的观点迫使我再次思考了UML里面到底有哪些东西，或者哪些东西有用？UML中需求分析部分比较有价值的，但是UML没有提供关键的建模方法，因此象四色图这样可操作性的方法只能成为一种stereotype了，这样造成了一个尴尬的局面：统一了不实用。
>为了维护uml的uniform，它也尽量不会对某种开发语言（或者说实现技术）采取跟随政策。阻抗由此而产生。
如果UML只定位再业务分析这个层次，这个观点是正确的，但是如果UML试图作为一种交流工具的话，就不要忘记，技术变革会产生社会推动力的，作为一种交流工具，产生技术革命的技术往往包含革命的思想，因此，作为交流工具就要积极引入新的思想表达，否则，我们能用文言文来进行21世纪的交流工具吗？
uml是基于一般oo理论的图形化语言描述，java编译器原本也是基于一般oo理论去设计实现的，以至于泛化关系被两个简简单单的关键字extends, implements所涵盖，当然还有其他对象技术的实现。
所以当初在uml与java的匹配上还算不错。
随着java实现技术和理论的不断丰富，java的不同编码形式和粒度，以及命名，形成了面向模式，面向服务等分析和设计方法。标准uml是不能完全匹配这些方法的，因为新的元素和概念没有得到补充。
这也涉及到uml中modeling理论的是否只有oo理论构成的问题，能不能扩展面向模式，面向服务等理论？是不是能适应设计分析编程整个过程的需要？这些理论是否成熟？
在这个阶段，不匹配是肯定的，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是工具，是死的，但人是活的。所有工具的目的都是用来构建好的软件系统，怎么用舒服就怎么用。