banq
2006-04-03 16:10

>只要让uml帮助你思维和交流就可以

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

youway
2006-04-11 15:18

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

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

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

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

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

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

banq
2006-04-12 12:37

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

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

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

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

youway
2006-04-14 00:20

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

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

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

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

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

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

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

banq
2006-04-14 12:02

>大家也能看得到一些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标准还不彻底....