在uml与java之间产生所谓阻抗,是因为uml的抽象程度已经不能涵盖住java等开发语言快速发展的新的实现技术了以及所产生的新理论。
uml是基于一般oo理论的图形化语言描述,java编译器原本也是基于一般oo理论去设计实现的,以至于泛化关系被两个简简单单的关键字extends, implements所涵盖,当然还有其他对象技术的实现。
所以当初在uml与java的匹配上还算不错。
随着java实现技术和理论的不断丰富,java的不同编码形式和粒度,以及命名,形成了面向模式,面向服务等分析和设计方法。标准uml是不能完全匹配这些方法的,因为新的元素和概念没有得到补充。
这也涉及到uml中modeling理论的是否只有oo理论构成的问题,能不能扩展面向模式,面向服务等理论?是不是能适应设计分析编程整个过程的需要?这些理论是否成熟?
在这个阶段,不匹配是肯定的,uml的统一是旧体制下的,而新的统一还未到来。有些东西我们还是要自己解决的。
大家也能看得到一些uml的工具提供商自己也在解决这些问题?